Mixing stepper drivers on SKR 3 EZ

[gloomyandy]

Not something I've ever looked at as the 2130 is a pretty old design these days not offering any advantages over 2209/5160/2240 drivers. You may be able to modify the 5160 driver to support them, but that driver is already fairly complex (which is another reason I've never wanted to add 2130 support). You may just be better selling the 2130s and buying either more 5160s or 2240s (if they are available in the ez format).

[justGuner]

@gloomyandy 2240's are only available as stepsticks for now, I don't see how that would create an issue though.

The angel on my right shoulder is telling me to sell or return the 2130's and buy compatible drivers, while the devil on my left is whispering to my ear to find the schematics of the board, cut and solder the appropriate tracks in order to select uart mode.

Now that I think about it, how does the board know to use uart or spi if you can't "install the proper jumpers"?

Guess this is what you get for not reading the documentation properly.

Sidenote: on the TeamGloomy page at the skr 3 ez general information section it shows the driver ports for the skr 3, not the EZ variant.

[justGuner]

Hypothetically speaking, would it be possible to just bridge the correct pins in order to select uart for the z drivers?

[justGuner]

Well, well, look what I found in the user's manual for the skr 3 EZ:

You might wanna add this to the TeamGloomy page.

[jay_s_uk]

@justGuner

That's why we have this note. I should probably update it anyway to lump 2240s in with 5160s and mention it only applies to stepsticks

And I'll look at updating the driver image

[gloomyandy]

@justGuner I'm still not sure what you are intending to do.

My understanding is that the problem with this board is that the SPI bus used for the drivers is always connected to the pins on the step stick sockets. This means that if that bus is in use (to talk to spi based drivers) then these pins will be active. Typically stepstick based UART based modules use these pins to configure things like microstepping and other functions and the active spi pins will cause problems for the driver. The EZ style modules for UART based drivers avoid this issue by simply not connecting the SPI pins to the driver chip (which is fine as they are not used for UART based drivers). I think that in theory this means you can mix spi and uart based drivers so long as the UART based drivers are EZ modules, but that is not something I've ever tested.

So I do not think you will be able to use your 2209 drivers if they are stepstick modules. You may be able to get them to work by cutting/removing the pins that would normally connect the stepstick to clk/mosi/miso (do not remove the CS pin as that is used for the UART signal) on the stepstick modules.

None of this impacts 2130 support, we just don't currently support those drivers.

[justGuner]

@gloomyandy yeah, I should have been more clear, all of the messages above were for trying to get the 2209's to work in uart mode. I've changed the title of this topic to better reflect my current situation.

@jay_s_uk said in Accidentally bought tmc2130:

That's why we have this note. I should probably update it anyway to lump 2240s in with 5160s and mention it only applies to stepsticks

I was referring to the last part that mentiones the mixing of EZ drivers.

[justGuner]

I might be onto something:

I cut off the pins that I don't need on the 2209 from the J3 column (pins 2, 3 & 5).

After declaring the drivers in the board.txt file this is the status of the drivers from m122:

(I think my driver 1 socked is broken, no matter what I put in there it sais that there is no driver, I will look into it some other time)

Now I need to reconnect the cables to the board as before so that I can go on with testing.

Update:
Succes! All axis moving as they should.

[justGuner]

Small update regarding modifying uart drivers:

DON'T DO IT YET

I have been getting constant short to vin / short to ground errors ever since installing the EZ drivers and the modified 2209's. I have tried the following setups:

• only EZ drivers: getting random short to vin errors (with no apparent cause), still able to move motors
• EZ and modified drivers: getting random short to vin errors on EZ drivers (with no apparent cause), still able to move motors; getting short to vin errors when trying to move motor connected to driver
• only modified drivers: getting short to vin errors when trying to move motor connected to driver
• only stock drivers: everything works fine

Before anyone asks, I can confirm that the issue isn't with the wiring or motors, since the error message would appear on the EZ drivers even when the motors or cables weren't connected to the board. Using 24v or 48v didn't do a difference.

I have contacted btt support and waiting for an answer. If I don't receieve anything useful in the following days, I will buy a new board with 2209 EZ drivers for troubleshootind purposes, as I can't rule out my board being the issue; considering that I have a nonfunctional driver slot there might be other issues with it that I don't know.

I will keep you updated when I will get a response / receive the new board.

[gloomyandy]

@justGuner A few points that may or may not help....

1. It's not a good idea to operate drivers without a motor attached, you will get various "random" errors reported.
2. If SPI based drivers are reporting random errors it may be because of noise or other devices on the spi bus, there is no checksum or crc checks of errors reports over spi. Take particular care with drivers that are external to the board and extend the spi bus via cables.
3. It is very unusual to get spurious error reports from UART based drivers as the messages from the board are protected by a crc (which is checked by RRF). If you get an error from a UART driver there is a good chance that the driver module is reporting that fault (for whatever reason).
4. Remember that the spi signals are always connected to all driver sockets on this board, so it is important when testing to remove any driver modules that are not being using or they may cause problems with the spi bus signals.
5. When using external drivers it is important to keep any wiring to the modules as short as possible and to route it away from any motor wiring.

So it is important to distinguish which drivers are reporting the errors (and the type of driver).

We have had reports of errors being reported with external ez drivers before over on our discord server. Unfortunately the thread is not easy to follow and I'm not sure if it was ever fully resolved. See: https://discord.com/channels/711873626080804914/711873626080804917/1309486826146238474

What drivers are "stock" in your above post? Are they unmodified 2209 stepstick modules? If so I'm surprised that they work, but your modified 2209 modules do not.

[justGuner]

I have done some more testing and here are my results:

Board is SKR 3 EZ H743. I am not using external drivers; all drivers are mounted on the sockets on the mainboard.

@gloomyandy said in Mixing stepper drivers on SKR 3 EZ:

What drivers are "stock" in your above post? Are they unmodified 2209 stepstick modules

Yes, modified drivers are the ones with the pins cut, unmodified are regular stepstick

Case 1. One or two 5160 EZ drivers: I get short to VIN errors randomly at irregular intervals regardless of powering steppers, having steppers connected, executing a move etc. The driver to report an error is usually always the first one declared (i.e if slots 1 and 3 are occupied, driver in slot 1 will report an error), but sometimes it also comes from the second driver. I'm still able to move the steppers after clearing the error message.

Case 2. One or two 5160 EZ and one or two 2209 stepstick drivers: EZ drivers show the same behavior as above, 2209's have a 80/20 chance of moving as they should or reporting an error and vibrating in place. I can't move the stepper worked to it after clearing the error message. No error reporting from 2209's when there are no steppers connected.

Case 3. One to three modified 2209 stepstick drivers: same behavior as 2209's in case 2

Case 4. Stock 2209 mixed with modified 2209 drivers: same behavior as 2209's in case 2, regardless of stock or modified driver. There were a few instances where I received a driver overheating shut down message, and checking the temperature graph showed a spike for a second, but as far as I can tell from touching the driver it was not overheating.

Case 5. Two stock 2209 stepstick drivers: Same behavior as in case 4.

I don't think it is an overheating problem as I tried cooling the board by blasting it with a hairdryer in cold mode and it didn't do a difference.

Only other connections to the board are two endstops, temp sensor for the bed, connection from the heatbed output for an external heated module, esp32 wifi adaptor in the wifi socket and canbus.

All other functions (heaters, fans, etc) are working fine.

[gloomyandy]

@justGuner I'm a little confused, you said earlier that with just "stock" drivers installed you had no problems is that not the case? Has this board with drivers ever worked correctly? When you get these errors does the m122 output show the drivers are being detected correctly? In your case 1 above are you saying that you only had two 5160 EZ drivers in the board with no other drivers installed and no other drivers configured, but still got errors?

How quickly do you see these errors, it sounds from your later report that you are seeing some of them as soon as the board is used? Has this always been the case (because your earlier posts seemed to indicate that things were working)?

I've really no idea what is causing the faults you are seeing they all sound pretty odd and we have not had any other reports of those sorts of issues. Note: With this board it never makes sense to mix unmodified stepstick 2209 drivers with 5160 drivers as the spi signals will be connected to pins that are not intended to have spi signals connected to them.

[justGuner]

@gloomyandy

@gloomyandy said in Mixing stepper drivers on SKR 3 EZ:

you said earlier that with just "stock" drivers installed you had no problems is that not the case?

I guess I hadn't tested the board thoroughly enough before, but from trying to run a print job with any of the cases above I would eventually receive a short to vin error.

@gloomyandy said in Mixing stepper drivers on SKR 3 EZ:

Has this board with drivers ever worked correctly?

Yes, it worked fine with stepstick 2209's before (driver 1 slot was always not working but it didn't afect the functionality of the board)

@gloomyandy said in Mixing stepper drivers on SKR 3 EZ:

In your case 1 above are you saying that you only had two 5160 EZ drivers in the board with no other drivers installed and no other drivers configured, but still got errors?

In the board.txt file I had stepper.DriverType = {TMC2209,TMC2209,TMC2209,TMC5160,TMC5160}. For the cases with only 2209's i would just change 5160 to 2209.

@gloomyandy said in Mixing stepper drivers on SKR 3 EZ:

How quickly do you see these errors, it sounds from your later report that you are seeing some of them as soon as the board is used? Has this always been the case (because your earlier posts seemed to indicate that things were working)?

I wasn't able to determine a pattern; sometimes it takes a while, other times it comes up imediately. The board was working before I tried to use 5160's.

[gloomyandy]

@justGuner I'm still confused are you saying that if you go back to a setup that only has 2209 drivers (which was working before) you still get errors? Also when you run these tests are you removing the drivers you are not using from the board? So as I asked above, in test one did you only have the two 5160 drivers installed in the board and you still got errors.

[justGuner]

I modified board.tx with stepper.DriverType = {unknown,unknown,TMC2209,TMC5160,TMC5160}, hoping that it would solve the issue. It didn't.

Here is the output of m122 after turning on the printer and waiting for a couple minutes (I did receive a short error in the meantime for driver 3):

m122
=== Diagnostics ===
RepRapFirmware for STM32H7 based Boards (skr3_h743) version 3.5.3 (2024-09-18 20:53:33) running on STM32H743 (standalone mode)
Board ID: H10W1-0W0K2-D6MW8-6PTFW-GGLWV-70000
Used output buffers: 3 of 40 (36 max)
=== RTOS ===
Static ram: 48816
Dynamic ram: 109268 of which 1292 recycled
Never used RAM 251856, free system stack 151 words
Tasks: NETWORK(2,nWait 7,10.8%,244) HEAT(3,nWait 6,0.0%,371) Move(4,nWait 6,0.0%,339) CanReceiv(6,nWait 1,0.0%,300) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,332) TMC22xx(4,nWait 6,0.5%,133) TMC51xx(4,delaying,5.3%,157) FSWRITE(2,nWait 4,0.0%,561) MAIN(1,running,83.0%,113) IDLE(0,ready,0.3%,29), total 100.0%
Owned mutexes: WiFi(NETWORK) BITIO(TMC22xx)
=== Platform ===
Last reset 00:04:02 ago, cause: software
Last software reset at 2025-01-04 19:16, reason: User, Gcodes spinning, available RAM 248812, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 41.2, current 41.4, max 50.1
Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: not present
Driver 1: not present
Driver 2: standstill 2209, SG min 2, reads 48287, writes 12, error r/w 0/1, ifcnt 46, timeout 0
Driver 3: standstill 5160, SG min n/a, mspos 824, reads 44919, writes 16
Driver 4: standstill 5160, SG min n/a, mspos 72, reads 44919, writes 16
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Driver 12: 
Driver 13: 
Date/time: 2025-01-04 19:20:38
Slowest loop: 2.81ms; fastest: 0.05ms
=== Storage ===
Free file entries: 20
SD card 0 detected
SD card longest read time 1.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2190, received 4848, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6053, peak Tx sync delay 204 free buffers 50 (min 49), ts 1209/1208/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 43.89ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0)
HTTP sessions: 1 of 8
Uploads/Errors: 0/0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Bad header: 0/0
Firmware version 2.1.0
MAC address 0c:dc:7e:9a:2d:10
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 188636
WiFi IP address 192.168.1.6
Signal strength -39dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00003043
Socket states: 0 0 0 0 0 0 0 0

And here it is after trying to home the machine: X and Y homed ok, Z vibrated and was slowly dropping the bed while trying to raise it

m122
=== Diagnostics ===
RepRapFirmware for STM32H7 based Boards (skr3_h743) version 3.5.3 (2024-09-18 20:53:33) running on STM32H743 (standalone mode)
Board ID: H10W1-0W0K2-D6MW8-6PTFW-GGLWV-70000
Used output buffers: 18 of 40 (36 max)
=== RTOS ===
Static ram: 48816
Dynamic ram: 109300 of which 1260 recycled
Never used RAM 248788, free system stack 132 words
Tasks: NETWORK(2,nWait 7,10.4%,244) HEAT(3,nWait 6,0.0%,356) Move(4,nWait 6,0.0%,244) CanReceiv(6,nWait 1,0.0%,300) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,332) TMC22xx(4,delaying,0.5%,133) TMC51xx(4,delaying,5.4%,157) FSWRITE(2,nWait 4,0.0%,561) MAIN(1,running,83.7%,113) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:08:29 ago, cause: software
Last software reset at 2025-01-04 19:16, reason: User, Gcodes spinning, available RAM 248812, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 41.2, current 41.3, max 41.5
Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/16/16, gc cycles 0
Events: 2 queued, 2 completed
Driver 0: not present
Driver 1: not present
Driver 2: phase A short to Vin, standstill 2209, SG min 0, reads 53464, writes 2
Driver 3: standstill 5160, SG min 0, mspos 808, reads 5188, writes 3
Driver 4: standstill 5160, SG min 0, mspos 104, reads 5188, writes 3
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Driver 12: 
Driver 13: 
Date/time: 2025-01-04 19:25:06
Slowest loop: 6.96ms; fastest: 0.05ms
=== Storage ===
Free file entries: 20
SD card 0 detected
SD card longest read time 1.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 9, maxWait 494162ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 3, on retry 0, too short 0, wrong shape 4, maybepossible 0
=== DDARing 0 ===
Scheduled moves 12, completed 12, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2417, received 5364, lost 0, errs 0, boc 0
Longest wait 1ms for reply type 4012, peak Tx sync delay 6 free buffers 50 (min 49), ts 1337/1337/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 20.58ms; fastest: 0.07ms
Responder states: MQTT(0) HTTP(2) HTTP(2) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0)
HTTP sessions: 1 of 8
Uploads/Errors: 0/0
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Bad header: 0/0
Firmware version 2.1.0
MAC address 0c:dc:7e:9a:2d:10
Module reset reason: Power up, Vcc 0.00, flash size 4194304, free heap 182500
WiFi IP address 192.168.1.6
Signal strength -41dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00003043
Socket states: 0 5 0 0 0 0 0 0

[justGuner]

@gloomyandy Yes, when I revert back to 2209's I still get errors. And yes, in test one I only had 5160 drivers installed.

[gloomyandy]

@justGuner Sorry I really have no idea. As I said previously it is very unusual to have 2209 drivers report spurious errors, that almost certainly means that the driver is actually signalling that fault (for whatever reason). If these errors were the result of some sort of random data from the 2209 I would expect to see many read errors being reported and that does not seem to be the case.

If going back to your previously working setup of all 2209s is showing problems that is not a good sign. Has anything else changed? Is there any chance that the 2209 drivers have been supplied with 48V?

[justGuner]

@gloomyandy 100% sure they weren't super with 48v.

I guess I will buy a new board with drivers. Ironically, it is cheaper to buy the board with 5 EZ 2209's then just the board itself on aliexpress. I can test if the problem is with the old board or not when it arrives.