kantlivelong / octoprint-setandwait Goto Github PK

M108 while waiting for temperature should break out of the wait loop leaving target temperatures in place but allowing command queue to continue. However it is not processed by the plugin and this is ignored.

What were you doing?

1. Run gcode using M190 with SetAndWait enabled

What did you expect to happen?

All gcode being executed with M190 substituted appropriately

What happened instead?

A communication error

Version of OctoPrint-SetAndWait

0.0.1

Operating System running OctoPrint

OctoPi 0.17.0

Printer model & used firmware incl. version

Prusa MK3S with MMU2S, firmware version 3.9.0 and 1.0.6, respectively

Link to octoprint.log with octoprnt.plugins.setandwait set to DEBUG

https://gist.github.com/rafl/fc671ea57e25db04e5bac8c9bc7ad355

My initial reason for wanting this plugin was to be able to override the temperature during a wait like I could do from Marlin UI on printer, for example lowering bed temp from 60 to 40 for a print that doesn't really need a hot bed for adhesion, to get the print to start right away, and for making overrides for printing an existing sliced file with different material (e.g. switching from PLA temps to PETG or ABS temps). But it hangs everything just like the firmware handling M109 or M190 would, and does not allow any commands until the heating completes; the only advantage I've found is that job cancellation works.

Can the plugin be modified not to block the logical gcode queue going to the printer, but instead just block advancement in the file being printed, while waiting for heating? And to use new values from any M104, M140, M109, or M190 commands received as the new wait targets, so that raising/lowering the temp can truncate/extend the wait, and so M108 terminates the wait?

The condition to end the heating wait is "current_temp >= requested_temp", which is easily hit with a PID loop that oscillates around the requested temp, but may never be hit with a highly stable loop that holds temp, for example, between 39.94 and 39.99 when 40 was requested. The condition should probably be current_temp >= requested_temp - 0.5 so that it accepts anything that rounds (with no decimal places, typical printer UI display) to the requested temperature.

Should this support the G4 wait command as well?

This blocking call also stops cancelling from happening, and stops polling of temperatures (at least on my model printer). For example I have to implement long waits in this way:

G4 S60
M105
G4 S60
M105
G4 S60
M105
G4 S60
M105
G4 S60
M105

So that I can cancel and get feedback. If the G4 command could be processed locally, then the printer would continue to be responsive during the period.

See #2 & #3

It seems like the gcode change by SetAndWait adds the tool that's used, but without checking if it's a single extruder system.

Send: M190 S85
Send: N124 M104 S250.0 T4*59
Send: M109 S250
Send: N125 G28 W*98
Recv: ok
Send: N126 M105*34
Recv: echo:M104 Invalid extruder 4
T4 reported as invalid, reverting to T3
Recv: ok
Not queuing T3, that tool doesn't exist according to the printer profile or was reported as invalid by the firmware
Send: N127 G80*21

Original gcode is "M104 S250.0" without the Tx.

The effect is OctoPrint removing filament switches after this trigger.