Stepper stalling, but only during certain deceleration moves
-
My machine uses two bowden extruders which feed into a y-splitter, which then feeds into a direct-drive extruder on the print head. This way i can print with dual extrusion. I have a simple macro which I use to load filament into one extruder or the other before a print.
At any given point in time, there are two extruders pushing the filament in series. So in the macro, one of the bowden extruders grabs the filament, feeds it for a while through the bowden tube, and decelerates a little ways before the hobbed gear in the print head. At this slower speed, the direct drive extruder can more easily grab onto the filament. Once this has been achieved, the extruders speed up again to advance the filament up to the nozzle, decelerating again as the filament approaches it.
The direct drive extruder always stalls during the first deceleration move of the macro, but nowhere else. At this point there is no load on it, since the filament hasn't reached it yet. The second deceleration move doesn't cause a stall, and it never stalls during an actual print.
Since this might be important for figuring out what's going on, that direct drive extruder is a NEMA 11 with a 9-to-1 gear ratio.
This is the gcode for the load macro:
M201 E10
G1 E10 F120; grab filament
G1 E600 F1200; quickly advance
G1 E13 F120; slowly advance past extruder 2
G1 E55 F1200; quickly advance up to nozzle
G1 E20 F120; slowly extrude
M201 E500Video of the phenomenon on imgur:
Here is my config.g file:
What's causing this stall, and how to I prevent it?
Thanks y'all!
-
If you run M122 after one of these stalls do you see a hiccup count? Post the results here.
M350 X32 Y32 Z32 E32:32:32 I1 ; Configure microstepping with interpolation M92 X200.00 Y200.00 Z800.00 E300.00:300.00:2700.00 ; Set steps per mmYour 9:1 geared extruder has a very high steps per mm, and you're using 32x microstepping on all axis. I suspect that at some point you're exceeding the step rate and getting some hiccups to the point of a long pause.
I suggest reducing microstepping to x16 and using interpolation to x256. You'll have quieter operation and the step load will be reduced. If that still doesn't help, you may need to reduce the speed at which you run the 9:1 extruder.
-
@Phaedrux thanks for the reply!
Here's the output from the M122 command:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.05 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LL3T0-6JKD6-3S86P-TV22P
Used output buffers: 3 of 24 (8 max)
=== RTOS ===
Static ram: 19804
Dynamic ram: 87332 of which 24 recycled
Exception stack ram used: 324
Never used ram: 23588
Tasks: NETWORK(ready,1220) HEAT(blocked,1272) MAIN(running,4192) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:01:11 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 23544 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04418000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 38.3, current 38.9, max 39.5
Supply voltage: min 0.0, current 12.7, max 12.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, read errors 0, write errors 1, ifcount 124, reads 16064, timeouts 0
Driver 1: standstill, read errors 0, write errors 1, ifcount 124, reads 16062, timeouts 2
Driver 2: standstill, read errors 0, write errors 1, ifcount 179, reads 16063, timeouts 1
Driver 3: standstill, read errors 0, write errors 1, ifcount 127, reads 16062, timeouts 0
Driver 4: standstill, read errors 0, write errors 1, ifcount 254, reads 16062, timeouts 1
Driver 5: standstill, read errors 0, write errors 1, ifcount 109, reads 16062, timeouts 0
Driver 6: standstill, read errors 0, write errors 1, ifcount 120, reads 16064, timeouts 0
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.72ms; fastest: 0.05ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 156, MaxWait: 12706ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 5, completed moves: 5, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 7.06ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplexAfter the diagnostic I did go ahead and change the microstepping, and it seems to have solved the problem, although I don't understand why. My understanding was that the drivers on the Maestro interpolated x256 anyway. Am I missing something?
Also, why didn't it skip steps at full speed, but then it did during the deceleration phase of the move?
Thanks again!
Edit: Just to clarify, the diagnostic was performed before changing the firmware, right after witnessing the motor stall.
-
No hiccups in that one. Was that after a stall had occurred?
Yes the maestro will interpolate to 256 from any microstepping value but the base microstepping of 32 is still higher than recommended. This is especially so for the maestro which has a slightly less powerful CPU.
Perhaps the deceleration phase is more affected due to pressure advance and the coordination with the other axis. Pure speculation.
-
@Phaedrux yes that was immediately after running the macro and seeing the motor stall.
I don't understand why the fix works, but it works, so I'm happy (enough)!
