Fysetc F6 <-> TMC2130 No Communication

towe96 commented 5 years ago

After some amazing time with Klipper running on my MKS Gen v1.3, I got an Fysetc F6 to declutter the wiring a bit.

For testing, I'm using two TMC2130 drivers on X and Y. Z, Z2 and E are driven by DRV8825's.

Using "dump_tmc stepper=stepper_x" and the attached config, I am however unable to read the driver registers using SPI, and, subsequently, the drivers do not move.

When using this Marlin (without any hardware changes), Fysetc F6 Marlin with TMC, M122 reads out the drivers just fine, leading me to believe it's an issue with the Chip Select pins.

In the Marlin file, Arduino Pin "70" is used. Using the "ar70" in Klipper results in an error. I've both traced the CS pin on the Gerber files as well as looked it up in the schematic .pdf, and the CS pin should have the hardware name "PG4", as I configured it. The CS for the Y stepper also does not work, even when using the normal Arduino pin number (which does not result in an error here).

Attached is the klippy.log as well as the config I used (rename to printer.cfg). printer_f6.txt klippy.log

towe96 commented 5 years ago

Update: After some tests today... the drivers work. I can set currents, I can change microstep settings, sensorless homing works flawlessly.

However, DUMP_TMC still reports "0xFF FF FF FF" for all queried registers. Is there a change the MISO line / pin has been botched in the firmware somehow? Or the way the received data is being processed?

trevjonez commented 5 years ago

all F's on the dump is indicitive of bad SPI. you MUST disable the cs pin on any unused spi drivers.

Also I noticed you have arduino mapped pin names in your config. here is a map of pins for the board necessary for 2130's on all 6 slots.

   4   │ # FYSETC F6 v1.3 Pin Map
   5   │ # --------------------------------------------------------
   6   │ # X  step: PF0, dir: PF1, enable: PD7, cs: PG4, diag: PK1
   7   │ # Y  step: PF6, dir: PF7, enable: PF2, cs: PG2, diag: PJ1
   8   │ # Z  step: PL6, dir: PL1, enable: PF4, cs: PJ7, diag: PB6
   9   │ # E0 step: PA4, dir: PA6, enable: PA2, cs: PL2, diag: PH6
  10   │ # E1 step: PC1, dir: PC3, enable: PC7, cs: PC5, diag: PJ0
  11   │ # E2 step: PF5, dir: PF3, enable: PG1, cs: PL7, diag: PK2

I don't use E2 stepper driver for anything so I have to add this to get DUMP_TMC to work

 260   │ [static_digital_output extruder2_cs_pin]
 261   │ pins: !PL7

I suspect what is happening is it queries the SPI bus and the default on state of a pin is causing multiple drivers to respond.

towe96 commented 5 years ago

I will update the Arduino names with the proper hardware pin names, thank you.

X and Y are the only two SPI drivers on the board, and the only slots where the jumpers are set to connect the pins to the MCU. Should I still disable the other CS pins? I suspect no "cross-talk" should happen in that case even without doing so.

I find it odd that SPI works for writing to the driver, but not for reading.

trevjonez commented 5 years ago

yea I wouldn't expect any cross talk if you adjusted all the jumpers correctly. here is the rest of my config if you want to poke around. https://github.com/trevjonez/klipper-configs/blob/master/fysetc_f6_bear.cfg

towe96 commented 5 years ago

Thanks for the config, very comprehensive. I could have saved myself the hour or so of tracing all the pins on the board to their ATmega hardware name then.

I've set the CS pins as disabled in my config now, and replaced all the pin names with their hardware ones - even tried disabling my display. Still, I can't seem to read anything from the drivers. At least Klipper is still usable since I can write to them and I only use the dump_tmc for debugging current limitations. Guess I'll have to wait until I have my scope back.

How old is your host software? I've just "git pull"ed it, but I don't see what else this could be if not some sort of firmware issue on the MISO line.

trevjonez commented 5 years ago

I am on commit da68da7a63322c300acf574f0068bb09b8073916

KevinOConnor commented 5 years ago

To the best of my knowledge, the tmc2130 and spi code works correctly. I'd say double/triple check the wiring.

-Kevin

towe96 commented 5 years ago

TIL my DSO138 is not capable of handling SPI speeds.

I've meanwhile checked the wiring again - all the jumpers are perfectly fine, and I've flashed Marlin on it again, and SPI works flawlessly there. I have absolutely no clue what could be causing this.

KevinOConnor commented 5 years ago

One thing to be aware of is that Marlin dumps a ton of information even if it is not successfully communicating with the driver. So, you might want to double check that Marlin is in fact reading data from the driver. You could try posting your marlin config and the marlin output here to see if anyone spots an issue.

-Kevin

KevinOConnor commented 5 years ago

And further update on this?

-Kevin

towe96 commented 5 years ago

I'll try Marlin again tomorrow and see if I can trigger some overtemp warnings to check if "inbound" data transfer works. But as Marlin showed the same info as on the old MKS Gen 1.4, I still think there's some very odd issue with Klipper on the / my F6.

JRSax commented 5 years ago

Hello,

Mr.Weiß from the facebook group said i should submit my setup here because it seems to be the same/related issue.

Im using a new Fysetc F6 1.3 with their TMC2130 drivers. i got the printer to home X and Y sensorless. However i cannot home Z with my BLTouch clone (which is also from Fysetc). When i enter "G28" in the terminal X and Y will home alright. Z is going up 20mm and stops after this move.

Terminal states: Recv: !! Endstop z still triggered after retract even when QUERY_PROBE and QUERY_ENDSTOPS tell me everything is "open".

Pin up, down and reset work just fine.

Also "dump_tmc stepper=stepper_x" returns:

Recv: // ========== Write-only registers ========== Recv: // IHOLD_IRUN: 00081919 IHOLD=25 IRUN=25 IHOLDDELAY=8 Recv: // TPWMTHRS: 00000082 TPWMTHRS=130 Recv: // TPOWERDOWN: 00000000 Recv: // PWMCONF: 00050480 PWM_AMPL=128 PWM_GRAD=4 pwm_freq=1 pwm_autoscale=1 Recv: // COOLCONF: 00040000 sgt=4 Recv: // ========== Queried registers ========== Recv: // GCONF: 00000000 Recv: // GSTAT: 00000000 Recv: // IOIN: 00000000 VERSION=0x0 Recv: // TSTEP: 00000000 Recv: // XDIRECT: 00000000 Recv: // MSCNT: 00000000 Recv: // MSCURACT: 00000000 Recv: // CHOPCONF: 00000000 MRES=0(256usteps) Recv: // DRV_STATUS: 00000000 Recv: // PWM_SCALE: 00000000 Recv: // LOST_STEPS: 00000000

I hope this will help to solve the problem.

klippy.log

KevinOConnor commented 5 years ago

@JRSax - if you want to home with the bltouch, then you should change the [stepper_z] endstop_pin to "probe:z_virtual_endstop". See config/sample-probe-as-z-endstop.cfg for further details.

It's unclear why your dump_tmc command is not returning data. Common issues are broken/incorrect wiring. It's also necessary to make sure every device on the spi bus is configured in Klipper (or at least that every CS pin is disabled).

-Kevin

JRSax commented 5 years ago

Today i removed the BLTouch clone, i ordered a genuine one yersterday evening. So i installed a Z endstop and for now this is working alright.

Also i did a fresh Octoprint and Klipper install, following the instructions on the GitHub. Installation and config check did go without any problems.

The Printer was wired new a few days ago (because Tevo Tornado stock wiring is dangerous). Every single wire and crimp connection was tested before connection and they should be alright.

As far as i understand "every device on the spi bus" means every driver? i got the 4 TMC drivers i need in the board and left the remaining two slots open. Do i still need to disable the two remaining CS pins?

The dump_tmc command is still returning the same as yesterday.

Here is a fresh klippy log. klippy.log

KevinOConnor commented 5 years ago

I do not know why some people report being unable to communicate with the tmc2130 (and/or tmc2208) drivers. A large number of users are running the code successfully. My guess is that the issue is a wiring and/or connectivity issue on the boards exhibiting the problem.

Some useful troubleshooting steps:

remove all drivers but one and try communicating with that driver. Try different sockets / different drivers.
for the tmc2130, one must ensure that every device on the given spi bus is configured in Klipper (or at least has its CS pin manually raised high). If a device is not physically plugged in then this is not needed. If a device is plugged in, then it needs to be configured even if it is not being used.
it's common for the tmc2208 and tmc2130 drivers to require manual modifications (eg, bridging solder jumpers) before they will communicate. Make sure all those modificaitons have been completed and double/triple check that they were done correctly.
make sure the right pins are routed to the stepstick - some stepstick devices use different pin assignments than others (particularly on the tmc2208).
make sure the board has "motor power" enabled when performing the tests. The trinamic drivers, in general, always require motor power in order to communicate.
make sure the code is running the latest version of Klipper. Specifically, there were recent changes (20190404) to help identify inadvertent pin conflicts in the config.

-Kevin

JRSax commented 5 years ago

Today i tried the same drivers after some pin soldering with a new MKS GEN L (got it cheap) board. And what should i say... everything is working flawlessly. I did everything the same way as before exept i now have to use DYI jumper wires for SDI, SCK, CS, SDO and DIAG1. Even Sensorless homing does work as it should but i had to use different DRIVE_SGT values (before 4 now 6).

Maby in 2 - 3 weeks i will try again with the F6 board (because i want it to work :/ and i dislike MKS somehow ).

Thanks for all the help :)

JRSax commented 5 years ago

Got the F6 board and TMC2130 working with SPI.

I traced every connector on every driver to the ATMega chip with my multimeter and wrote it all down and edited my config file accordingly. I noticed that SCK, SDI and SDO are on PB1, PB2 and PB3, so i inserted these pins in my config like this:

spi_software_sclk_pin: PB1 spi_software_mosi_pin: PB2 spi_software_miso_pin: PB3

SPI communication is now working as it should be. Jumpers are as described in the Fysetc wiki for TMC2130 and there are only four drivers on the board, two driver slots left open.

Here is my config: printer.txt

But i still need to get my BLTouch working ....

Thank you for helping me out :)

jakep82 commented 5 years ago

@JRSax You shouldn't need to define the SPI pins. Those are the hardware SPI pins which should work by default.

https://www.arduino.cc/en/Hacking/PinMapping2560

JRSax commented 5 years ago

@jakep82 Thats what i thought. But unless i defined them there it would not work. Are there any drawbacks in defining them as i did?

towe96 commented 5 years ago

I can confirm that the TMC2130s communicate perfectly with those software SPI pins added to each TMCs config.

Very odd. Thank you for your solution.

KevinOConnor commented 5 years ago

Super strange. Could you provide the Klipper log using a software spi config (start klipper with a software spi config, run DUMP_TMC STEPPER=stepper_x) and with a hardware spi run (remove the software spi pins from the config, issue a RESTART command, then run DUMP_TMC STEPPER=stepper_x)? Also, could you try a third run using hardware spi but with an additional setting of spi_speed: 100000 in the config (add the setting to the config, issue a RESTART command, then run DUMP_TMC STEPPER=stepper_x)?

Attach the resulting klipper log file here.

-Kevin

towe96 commented 5 years ago

Done. I did an M112 after each dump_tmc and downloaded the current log file from the Pi. Names should be self-explainatory.

klippysoftware.log klippyslowhardware.log klippyhardware.log

KevinOConnor commented 5 years ago

Thanks.

That's very puzzling! I've reviewed the code and run local tests - the avr hardware spi support works normally for me. I have no explanation for why hardware spi reads aren't working for you.

-Kevin

KevinOConnor commented 5 years ago

If you completely disconnect the exp2 header (which goes to the display), and retry the "slow hardware spi" config, does it start working for you?

If you add the following to your config:

[static_digital_output sdcard_cs]
pins: PB0

Does that allow hardware spi to work?

-Kevin

towe96 commented 5 years ago

Success!

Adding

[static_digital_output sdcard_cs]
pins: PB0

has fixed hardware SPI, even at default speeds (without spi_speed: 100000). I'll check if it still works once I plug the display back in when I get home.

Disconnecting the display and trying "slow hardware SPI" had not worked on its own.

towe96 commented 5 years ago

Works fine with the display reconnected.

JRSax commented 5 years ago

I can confirm that adding:

[static_digital_output sdcard_cs] pins: PB0

made hardware SPI working.

KevinOConnor commented 5 years ago

Okay - that's strange. I'd say an sdcard was messing with the spi transmissions (the sdcard is on the spi bus), but I don't see how that's possible if there isn't an sdcard in the machine. I guess it's possible that the fysetc f6 board is isolating the spi miso line when PB0 is low, but that's a very strange thing to do.

-Kevin

towe96 commented 5 years ago

So, if I used an SD card in Marlin, it shouldn't be able to communicate with the drivers?

KevinOConnor commented 5 years ago

Well, Marlin will enable the PB0 pin for its sdcard support, so I doubt you'd notice it there.

-Kevin

KevinOConnor commented 5 years ago

FYI, I added the PB0 pin to the example Fysetc F6 config file (commit 61530138).

-Kevin

Klipper3d / klipper

Fysetc F6 <-> TMC2130 No Communication #1368