execution of GCODE macro, does not take into account waiting for commands to finish

[ruedli]

I am using the GCODE macro script to run an end-sequence of the job, ensuring cooling down, shutdown Pi and poweroff. Shutdown and poweroff are done by the Tasmota plugin and work (using the M81 gcode)..

I have the following GCODE when finishing (a single line):

@shutdown_power

Shutdown power is defined as follows (also a single line):

{% include "shutdown_tasmota.gcode" %}

The content of the gcode file is:

cat shutdown_tasmota.gcode

M117 Cooling down
;
M109 S50 ; wait for extruder temp (cooling)
M109 R50 ; wait for extruder temp (cooling)
G4 S1
;
M104 S0  ; turn off temperature

M117 Shutdown/poweroff

M81 MK3S 1
;======================= Stop printer

Strictly speaking only one M109 R50 is needed, but I used both just to be sure the firmware is not causing a problem.

The problem is that "M81 MK3S 1" is executed, without waiting for the printer to cooldown. It looks like it is "just" executing", but not waiting for the command to complete.

By contrast: if I add the M109 to the endcode, everything works, so whithout the scipt altered, these three lines work as a workaround:

M109 S50 ;
M109 R50 ;
@shutdown_power

ALSO: If I split the commands over TWO MACROS, it works:

@cooldown
@shutdown_power

It can be reproduced by having multiple M117 messages in a script: before and after heating / wait mode. The progress can be seen on the terminal comand: the M117 AFTER the M109 R50comes immediately. (also shown in the octoprint daskboard).

Using a prusa MK3S+, latest firmware 3.12.2 System bundle included.

octoprint-systeminfo-20230613195238.zip

In case you are wondering WHY I did this macro setup:

I can now even during the print replace the macro content, by just copying another file into it. Thus I can change the behaviour after a printjob finishes. The printer can either stay on, or do a controlled cooldown/shutdown/power off.

In order to conveniently swap the gcode, I placed both variant in the gcode directory and involke a cp command to copy the desired file over it, from a pulldown in the octoprint bar, using the plugin "system command editor". (For the menu where also the other power / reboot options are).

Sliced GCODE files, do not need ANY alteration: everything is done from octoprint settings and plugin configuration. The two workarounds work for me now, but the behaviour that "busy processing" responses from the printer are not considered, was troublesome to debug.

[cp2004]

I'll need a serial.log to look at this. My suspicion is that the printer is just OK'ing the commands so OctoPrint sends the next one - this plugin doesn't do any handling of the sending, just puts them in OctoPrint's queue. If you enable serial.log, reproduce the issue then either share a new systeminfo bundle or just the individual log file.

[cp2004]

Any news on the serial log here?

[cp2004]

No serial log, so I can't say why this is happening :/

[ruedli]

I gave away the printer, so I don't have the printer anymore, cannot provide desired information

Op wo 27 dec 2023 om 14:19 schreef Charlie Powell @.***

:

No serial log, so I can't say why this is happening :/

— Reply to this email directly, view it on GitHub https://github.com/cp2004/OctoPrint-GCodeMacros/issues/15#issuecomment-1870301150, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGGYOB2TFRP4THZEQVJ7JTYLQN7RAVCNFSM6AAAAAAZFOAITCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGMYDCMJVGA . You are receiving this because you authored the thread.Message ID: @.***>

-- Ruud Rademaker prefered mail: @.***