Calling M25 from within nested macro doesn't pause till return
-
I have some code that checks if the filament nominated in the slicer gcode output matches that which is currently loaded in RRF. The slicer filament name is loaded to a dummy fan name.
My intention was to immediately pause the print job and carry out a filament change.
It all works, except that the printer state doesn't change to paused until after all the (nested) macros finish and the input stream returns to the main print job.
I tried putting M25 in a macro on its own to see if the state would update after the return of each macro without success.
This makes it less easy to make conditional choices in the subsequent nested macros based on the machine state.
Is there any way to force the update/action?
It seems in contrast to what happens when a filament sensor is activated, which appears to cause an immediate pause (maybe after queued moves)Running RRF 3.2 rc2
if move.extruders[state.currentTool].filament!= fans[3].name if job.file.fileName!=null M25 M291 R"Incorrect filament loaded" P{"Incorrect filament loaded - (" ^ move.extruders[state.currentTool].filament ^ "). Print calls for (" ^ fans[3].name ^ ")." } S0 T3 G4 S3 M291 R"Change filament?" P"Press OK to begin filament change or CANCEL to abort job" S3 M564 S0 H0; allow movement without homing M591 P1 C"e0stop" S0 D0 ; disable filament sensor for now M291 R"Incorrect Filament" P{"Move head and press OK to begin unloading " ^ move.extruders[state.currentTool].filament} S3 Z1 M702 ; unload current filament M291 R"Ready to load" P{"Move head and press OK to begin loading " ^ fans[3].name} S3 Z1 M701 S{fans[3].name} ; load new filament M564 S1 H1 ; do not allow movement unless homed. M591 P1 C"e0stop" S1 D0 ; enable filament sensor if job.file.fileName!=null M291 R"Filament loaded" P"Print ready to be resumed" S3 -
@OwenD What hardware are you using? Are you using an SBC? M122 may be of use.
-
@gloomyandy
No SBC
Here is M122
Or do you mean execute it during macro?03/01/2021, 7:45:41 am M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-RC2 running on Duet WiFi 1.02 or later Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD Used output buffers: 3 of 24 (20 max) === RTOS === Static ram: 23460 Dynamic ram: 74792 of which 256 recycled Never used RAM 13572, free system stack 99 words Tasks: NETWORK(ready,169) HEAT(blocked,295) MAIN(running,304) IDLE(ready,19) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 11:57:09 ago, cause: power up Last software reset at 2020-12-31 14:49, reason: User, GCodes spinning, available RAM 13608, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x08 Aux0 errors 0,0,0 MCU temperature: min 23.8, current 36.9, max 39.9 Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 0, standstill, SG min/max 0/454 Driver 1: position 19800, standstill, SG min/max 0/294 Driver 2: position 15314, standstill, SG min/max 0/1023 Driver 3: position 0, standstill, SG min/max 0/26 Driver 4: position 0, standstill, SG min/max 0/1023 Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2021-01-03 07:45:36 Cache data hit count 4294967295 Slowest loop: 161.42ms; fastest: 0.19ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 2.0ms, write time 82.7ms, max retries 0 === Move === DMs created 83, maxWait 2356387ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 6], 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 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 1 is on, I-accum = 0.6 === GCodes === Segments left: 0 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 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 461.54ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.25beta0 WiFi MAC address bc:dd:c2:89:a0:bb WiFi Vcc 3.38, reset reason Power up WiFi flash size 4194304, free heap 24392 WiFi IP address 192.168.1.163 WiFi signal strength -56dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 === Filament sensors === Extruder 0 sensor: ok -
That's fine. You may want to try using M226 instead of M25 looking at the docs https://duet3d.dozuki.com/Wiki/Gcode#Section_M25_Pause_SD_print it seems you should not use M25 from a print job, I'm not sure if that also applies to macros run from a print job, but may be worth trying?
-
@gloomyandy
Thanks, I should have mentioned I did M226 as well, both in a seperate macro and in the one above.
It's a little confusing which to use as the docs say use M25 in macros.
Anyway, neither cause the status to change immediately.
Seems to be queued until return to main job stream -
Looking at the code it seems that what you are seeing is by design. Executing M25/M226 from a macro simply sets a flag that is not acted upon until the macros are complete. So the pause will not happen until the main gcode file resumes.
-
@gloomyandy
Thanks for confirmation
