-
I wanted to upgrade my corexy printer from tmc2209 to tmc5160 EZ drivers for 48v operation. Mainboard is a SKR 3 EZ. According to the documentation on the TeamGloomy website, this board does not support mixing SPI with UART drivers, so I decided to also buy two tmc2130 EZ drivers for the z axis. Guess my suprise when I learn that there is no native suport for tmc2130 in rrf.
Does anyone know if I can operate the EZ drivers in step/dir mode? If yes, how do I change the stepper driver current? Should I just plugin the 2209's (stepstick format) and modify the config to drive them with step/dir comands?
Is it possible to modify rrf to support 2130 drivers? I'm willing to spend some time tinkering with compiling rrf.
-
@justGuner it's a limitation of that board I'm afraid as there is no way to set SPI and UART.
You could operate them in "stepdir" mode but being unable to turn off the UART/SPI pins may lead to difficulties.
And as you've pointed out, there no way to set the current or even the microstepping on the driver so you may be out of luck there.
We haven't added TMC2130 drivers as they tend to run hot and don't add anything that 2208/2209 drivers are missing. I'm not sure how easy it would be to add support yourself. Maybe @gloomyandy can comment. -
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).
-
@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.
-
Hypothetically speaking, would it be possible to just bridge the correct pins in order to select uart for the z drivers?
-
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.
-
@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 stepsticksAnd I'll look at updating the driver image
-
@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.
-
@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.
-
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. -
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.
-
@justGuner A few points that may or may not help....
- It's not a good idea to operate drivers without a motor attached, you will get various "random" errors reported.
- 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.
- 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).
- 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.
- 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.
-
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.
-
@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.
-
@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.
-
@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.
-
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 0And 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 -
@gloomyandy Yes, when I revert back to 2209's I still get errors. And yes, in test one I only had 5160 drivers installed.
-
@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?
-
@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.
