Print aborted after resume
I'm getting this weird behaviour from my printer:
When resuming after the print was paused through a M226 command which was inserted into the gcode at a layerchange,
the printer throw's a the error "G0/G1: target position not reachable from current position" and aborts the print.
This however is only the case if I also insert an additional M400 and M28 after the M226.
Leaving only the M226 in, the printer pauses, but doesn't execute pause.g, which leaves the nozzle touching the unfinished print.
How can I make the printer pause properly through gcode injected at a layerchange?
Thanks for your help everyone!
You're calling M28 to start a print from within a print?
M226 would be the correct gcode to use: https://duet3d.dozuki.com/Wiki/Gcode#Section_M226_Synchronous_Pause
Can you share a sample of actual sliced gcode that you are executing?
What firmware version and Duet board?
What is the overarching goal you're trying to achieve?
Sorry, my bad, I meant G28 instead of M28.
The overarching goal I am trying to archive is to pause the print at a certain height to insert a magnet into the print.
I use a Duet3 mini with SBC, RRF, DSF and WDC are all version 3.2.2
This gcode snippet results in a paused print that I CANNOT resume afterwards but it moves the nozzle away (homes the printer (I have a delta))
G1 X3.714 Y33.368 E0.06560 G1 X2.359 Y33.489 E0.04991 G1 X0.344 Y33.572 E0.07401 ; stop printing object FOOD CAN 0pt1mm layer 100pct inf 1pt5 mm wallth.STL id:0 copy 0 ;LAYER_CHANGE ;Z:20.6 ;HEIGHT:0.15 ;WIPE_START G1 F9600.000 G1 X-0.787 Y33.565 E-0.26866 G1 X-3.116 Y33.433 E-0.55391 G1 X-3.927 Y33.347 E-0.19380 G1 X-5.232 Y33.144 E-0.31363 ;WIPE_END G1 E-0.07000 F2400.000 G1 Z20.650 F12000.000 ;CUSTOM_GCODE M226 M400 G28 ; printing object FOOD CAN 0pt1mm layer 100pct inf 1pt5 mm wallth.STL id:0 copy 0 G1 X-0.789 Y33.647 G1 Z20.600 G1 E1.40000 F2400.000 ;TYPE:Perimeter ;WIDTH:0.5625 G1 F4200.000 G1 X-3.936 Y33.426 E0.09808 G1 X-7.049 Y32.910 E0.09808 G1 X-10.098 Y32.106 E0.09802
This gcode snippet results in a paused print that I CAN resume afterwards but the nozzle doesn't move away from the print.
G1 X3.215 Y33.673 E0.00938 G1 X1.158 Y33.810 E0.01379 G1 X0.075 Y33.827 E0.00724 ; stop printing object 1mmFood 27 apr 2021.STL id:0 copy 0 ;LAYER_CHANGE ;Z:20.6 ;HEIGHT:0.15 ;WIPE_START G1 F9600.000 G1 X-2.306 Y33.753 E-0.56569 G1 X-3.216 Y33.677 E-0.21688 G1 X-5.501 Y33.376 E-0.54742 ;WIPE_END G1 E-0.07000 F2400.000 G1 Z20.650 F12000.000 ;CUSTOM_GCODE M226 ; printing object 1mmFood 27 apr 2021.STL id:0 copy 0 G1 X0.000 Y33.657 G1 Z20.600 G1 E1.40000 F2400.000 ;TYPE:Perimeter ;WIDTH:0.5625 G1 F4200.000 G1 X-3.199 Y33.504 E0.09957 G1 X-6.370 Y33.048 E0.09957 G1 X-9.482 Y32.293 E0.09957
Another thing (Bug?) that I noticed is that when I press resume after the pause, the status in DWC is 'resuming' and I can't abort the print via the 'cancel' button, I get an error instead.
nikscha last edited by nikscha
@phaedrux I solved the issue.
The root problem was that pause.g wasn't executed after M226.
No idea why, but after changing to the unstable release channel and running 'sudo apt-get update/upgrade',
pause.g is now properly executed.
Weirdly enough, M122 still reports RRF 3.2.2 ....
should I file a bug report?
The issue seems fixed in the latest unstable release, BUT I can't find the issue mentioned on the update notes/channel log.
So apparently noone's aware of the bug?
nikscha last edited by nikscha
=== Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus WiFi (SBC mode) Board ID: YD4DK-V296U-D65J0-40KM0-4503Z-HUP34 Used output buffers: 1 of 40 (40 max) === RTOS === Static ram: 98732 Dynamic ram: 95260 of which 48 recycled Never used RAM 51176, free system stack 122 words Tasks: Linux(ready,95) HEAT(blocked,291) CanReceiv(blocked,947) CanSender(blocked,358) CanClock(blocked,362) TMC(blocked,97) MAIN(running,152) IDLE(ready,20) AIN(blocked,260) Owned mutexes: HTTP(MAIN) === Platform === Last reset 07:33:22 ago, cause: software Last software reset at 2021-05-14 11:45, reason: User, GCodes spinning, available RAM 51176, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task Linu Freestk 0 n/a Error status: 0x04 Aux0 errors 0,0,0 Aux1 errors 0,0,0 Supply voltage: min 23.6, current 24.2, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 134598, standstill, SG min/max 0/48, read errors 0, write errors 0, ifcnt 123, reads 26797, writes 1, timeouts 20, DMA errors 0, failedOp 0x6a Driver 1: position 134600, standstill, SG min/max 0/50, read errors 0, write errors 0, ifcnt 123, reads 26908, writes 1, timeouts 20, DMA errors 0, failedOp 0x06 Driver 2: position 134602, standstill, SG min/max 0/52, read errors 0, write errors 0, ifcnt 123, reads 26923, writes 1, timeouts 4, DMA errors 0, failedOp 0x01 Driver 3: position 0, standstill, SG min/max 0/510, read errors 0, write errors 0, ifcnt 94, reads 26084, writes 1, timeouts 20, DMA errors 0, failedOp 0x06 Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 71, reads 26928, writes 0, timeouts 0, DMA errors 0 Driver 5: position 0, assumed not present Driver 6: position 0, assumed not present Date/time: 2021-05-14 19:18:59 Cache data hit count 4294967295 Slowest loop: 188.14ms; fastest: 0.08ms === Storage === Free file entries: 10 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, maxWait 200ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 150511, completed moves 150511, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 933, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.7 === GCodes === Segments left: 0 Movement lock held by 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 0, running macro Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 209763, send timeouts 209763, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16 === SBC interface === State: 4, failed transfers: 0 Last transfer: 1ms ago RX/TX seq numbers: 2931/2931 SPI underruns 0, overruns 0 Number of disconnects: 1, IAP RAM available 0x10eec Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.2 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 37.52 Maximum length of RX/TX data transfers: 2960/1664
Looks like you're up to date on the stable branch, but nothing from unstable has been applied. 3.3 final should be coming soon though.
What is the status of the original problem though?
everything works as expected now, the M226 command now invokes pause.g as expected.
And the only thing I changed (that I am aware of) is the switch to the unstable release. When executing apt update/upgrade, files were downloaded and installed as well....
When executing apt update/upgrade, files were downloaded and installed as well....
Perhaps you were on an older version before and have now updated to the latest stable. I don't think you're on the unstable branch at all, or if you are it hasn't actually updated any of your software as it reports both the firmware and DCS running 3.2.2
But it definitely says unstable release here...
Hmm, also says 7 not upgraded.
@phaedrux lol! You're right I didn't see that at all.
Do you happen to know how I can force an update?
Well if things are working now I'd say maybe wait for 3.3 final next week rather than updating to a release candidate unless you really want to do some testing.
If you do, I'd go through the steps for adding the unstable branch again and see if it will update after.
@phaedrux will do, thank you for your help I appreciate it!