Motor problems on RatRig V-Core 3
-
-
Hello @juliann @fcwilt @Nurgelrot @oliof
Hate to resurrect this thread, but was hoping you had seen this before:
Have started to commission my RatRig V-Core 3 (404x400) and have also run into some unusual issues:
SuperSlicer was adding in all kinds of Klipper based commands in the print GCode...so I reluctantly went back to Simplify3D 5.12 just to get something to slice and do test prints with.
First prints were dismal...nozzle was way too close to the bed, so I re-ran true bed leveling, mesh calibration, cleared all prior mesh data and proceeded to do some basic test prints.
After baby stepping a bit whilst printing I could def see an improvement in surface finish of the layers; not so dull looking and a bit shinier, which to me means close to proper height.
Halfway through I got a ton of driver overheating alarms...so I shut down and printed up a new backer plate for the Duet3 Mini 5+ which is now mounted with an increased backplate space of 20mmvs the 5 that were there originally.
Today I fire it all up and do my normal home axes, but the back Z stepper motor has gone all wonky....it is trying to lower itself while the front 2 are raising? Hit emergency stop and repeat...same thing. Ugh.
What could cause my steppers to go out of phase like this by itself? I checked my config.g for the steppers section and that has not changed.
I think this RatRig V-Core 3 has promise...if I can just get rid of the quirks that seem to come with it.
Any help from you Core X-Y Gurus is ALWAYS appreciated!
-
@Electriceye if a vertical axis lowers when commanded to raise, and it also lowers when commanded to lower, that usually means that only one motor phase is working. Typically caused by a bad crimp connection or a blown driver.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Uh oh...that doesn't sound good. At all.
So....If a driver is blown, how repairable is that? If it's just a MOSFET or cap I can probably desolder and repair that.
If a logic circuit is toast, that means a chip and with the age of this board(even though it's only been out of the original package for a month) what are the chances of warranty? Hmm...
Any schematics or board level information I can use to test against? My FLUKE meter awaits...
Thanks for the information...albeit concerning.
- Cheers!
-
I remembered that this board had the ability to drive 6 motors, so I re-mapped my rear Z to my open 6th driver circuit on the extension board. It works there, but my front stepper is out of phase:
Warning: Driver 0.2 warning: phase B may be disconnected
So...that's not good, looks like 2 drivers may be toast. What a way to start a build.
Here's my M122 results:
1/18/2025, 3:25:46 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.4 (2024-11-24 10:44:24) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: W64JZ-X296U-D65J0-40KM8-1213Z-7VWNL
Used output buffers: 1 of 40 (27 max)
=== RTOS ===
Static ram: 103496
Dynamic ram: 107784 of which 12 recycled
Never used RAM 30456, free system stack 198 words
Tasks: SBC(2,ready,1.4%,839) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,1.5%,110) MAIN(2,running,95.6%,762) IDLE(0,ready,0.6%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:05:21 ago, cause: power up
Last software reset at 2025-01-18 22:14, reason: User, Gcodes spinning, available RAM 30480, slot 2
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 241089, completed 241087, timed out 0, errs 0
MCU temperature: min 25.3, current 31.2, max 31.4
Supply voltage: min 24.0, current 24.1, max 24.2, 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: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 29176, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 29174, writes 12, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2025-01-18 22:27:00
Cache data hit count 719104473
Slowest loop: 3.98ms; fastest: 0.09ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, 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, 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 doing "M122" 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 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2763, received 0, lost 0, errs 1517266, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 1607/0/0
Tx timeouts 0,0,1606,0,0,1155 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 12382/12382
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0cd20
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.4 (2024-11-25 17:29:06, 32-bit)
HTTP+Executed:Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 29.53, max time between full transfers: 88.3ms, max pin wait times: 79.3ms/22.8ms
Codes per second: 0.15
Maximum length of RX/TX data transfers: 4359/864 -
@Electriceye said in Motor problems on RatRig V-Core 3:
Warning: Driver 0.2 warning: phase B may be disconnected
So...that's not good, looks like 2 drivers may be toast. What a way to start a build.
Before you worry about the drivers being blown, provide photos of the stepper connections on the board and motor side, and of the drivers. The error above may very well be about a wiring issue (either phases not being AA BB, or bad connection).
<>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>
-
Thanks for the reply- I'm hoping for the best, but preparing for the worst.
Going to pull the board off the printer today and look at it real close with my digital Microscope and also continuity test all the Z Stepper motors wire runs.
The weird thing is, the rear Z motor seemed to be working when I moved to a spare driver (Out 6) on the mini expansion board. That tells me that both the stepper motor AND wiring to that motor are intact and functional.
I also have a Duet 2 I could test with, but not really as it only supports 5 drivers and I need a minimum of 6 for this Rat Rig V-Core 3 printer, as you are well aware.
This may be a good time to print up the V-Core 3.1 upgrade printed parts, since my RatRig is down and I still have my trusty little Flash Forge Creator Pro to print on. It's horribly slow...but it still prints really nice prints.
-
I ended up pulling the board from the printer as I want to see if I can do any multi-meter testing.
The resistance should look different for a normal circuit vs a blown one, yes? Is there any documentation anywhere on what the values might be for those? Bueller? Anyone?
In the meantime I have a BTT Octopus Pro v 1.1 that I'm going to throw on there and get operational again.
One thing I really like about the BTT stuff is the drivers have large heatsinks on them, and they are replaceable...vs wave soldered to the PCB. I'm mounting it with a large 120mm Noctua fan to cool it all...not taking any chances THIS time!- Cheers!
-
@Electriceye to check drivers to work you cant just use a multimeter, you need to use an oscilloscope to see whether they properly generate steps. Alternately you can use a stepper driver analyzer (search the forum for more info), but in the end that's more or kess an oscilloscope with sone predefined settings.
Blown drivers usually exhibit "craters" or little blow holes, so inspecting them visually is another option. Posting high resolution, focussed photos of drivers here allows us to help determine whether a driver is blown or not.
If a driver looks good, the next most likely culprits are still motor wiring/crimps (testable with a pull test holding the housing and tugging on the wires and solder defects for the pins (also visually detectable).
Regarding the Octopus board: The heatsinks on the plastic housing act much less as a proper heat dissipator than the vias designed into duet boards and the high copper content on the duet board.
The duet boards are best cooled by blowing a bit of air above and below the board along the drivers.Another drawback of the stepstick format is the inherent current limitation and the usual arrangement making proper cooling on top and bottom of the stepsticks difficult, especially with banks of jumpers blocking airflow.
-
@oliof said in Motor problems on RatRig V-Core 3:
The duet boards are best cooled by blowing a bit of air above and below the board along the drivers.
Hindsight IS def 20/20 here...If I only saw that in the documentation from RatRig when I built it. They did mention that passive cooling should be enough...but the standoffs they provided to mount the Duet 3 Mini 5+ were simply not up to par.
My brother has a real nice O-Scope, so will prob send to him to check it out.
Many thanks again, for your sage advice. You are a credit to the forum here more certainly!
I did post pictures of my wiring and even some FLIR thermal pictures, which did show the drivers getting hot, so I should have realized to check the thermal limits before trying to run some test prints. Doh!Regarding the Octopus drivers, I agree that the duet PCB wicks better, but with the 120mm Noctua PWM fanmounted directly above the board, I think it will cool down fairly well.
Thanks again for the reply- duly noted.
