-
@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.
-
Update:
New board and 2209 EZ drivers arrived. I tried some basic tests (homing and m122 output) with both ez and modified stepstick drivers. As soon as I tried 5160's, I received a short to vin error, leading me to think that I got sent faulty drivers. As for the stock and modified 2209's, I don't think they are damaged. More testing to come, I still need to finish a print first in order to give the green light to cutting the pins on a stepstick driver.I also received a reply from biqu support regarding the skr 3 ez board, saying that I might have damaged the board with static electricity, short circuits or wiring errors.
edit: there was a small glitch that almost made my heart stop where after plugging in a 2209 in the slot where there was previously a 5160, the slot would become unresponsive, and I had to powercycle the board and change the order of the drivers a few times in order to make it working again.
2nd edit: I am now thinking that I just caused the same error on this brand new board aswell. I started receieving short to vin errors again on all ez drivers. Just great.
-
undefined T3P3Tony moved this topic from Duet Hardware and wiring
-
I might have figured it out:
When I first installed 5160 drivers I noticed that the steppers were pretty loud even at standstill, at which point I realised that I was using spreadcycle on all drivers; after which I changed it all to stealthchop.Well, I am currently runing a print job (with no filament, just to see if the movement is ok) with 2209's in spreadcycle, and now it's working again just like before.
Does anyone know why changing from stealthchop to spreadcycle would fix the issue?
I will try 5160's in spreadcycle after the print finishes to confirm that this is the issue.
-
I can confirm that the issue only appears when running drivers in stealthchop, no mather the speed. Sitting at idle with stealthchop on 5160's is enough to summon short to vin errors, while 2209's will throw an error only before a random move.
-
@justGuner That's very odd, it must be something specific to your board/driver/wiring/steppers/config because we must have loads of users running with stealthchop and not getting random short to vin errors.
