-
@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.
