Pausing before print starts

If I execute a Pause while the heaters are warming up but before the homing prior to the print starting, since the X and Y positions are not set yet, the printhead crashes on the Y axis because it is set to go to the back of my bed.

Is there a way in the pause.g file to tell it to not move if the print has not started yet?

Usually the reason I have to cancel during warmup is because I either selected the wrong file to print or forgot to make a change to the file gcode or forgot to upload an updated gcode file. I don't want to have to wait for it to finish heating before cancelling. I can just switch off the machine but that is so inelegant.

I have a little bit different pause issue that surfaced after 1.16 -> 1.18.2 upgrade (Duet 0.85).

My mode of operation has been to let the calibration run (13 points in bed.g) and then hit Pause just before the print starts to clean the nozzle of all ooze.
With 1.16 and prior this has worked perfectly but now it seems the firmware looses track that I'm using absolute mode in extrusion and the extruder goes berserk right when the print starts.

I was hoping to sneak by this by putting a pause in the end of bed.g, but no suck luck. It pauses alright, but there is no way to get the job to continue. What I don't want to do is to edit all my existing gcode files to put the pause there, so is there any way to make the resume work if there is a pause in the bed.g, please?
Of course I can delay hitting the pause a little bit and let the print start first but it would be nicer to clean the nozzle when it's higher from the bed (like it is after the calibration).

Thanks for all the great work to David and Chris, lots of new features so you have been seriuosly busy!

I have a little bit different pause issue that surfaced after 1.16 -> 1.18.2 upgrade (Duet 0.85).

My mode of operation has been to let the calibration run (13 points in bed.g) and then hit Pause just before the print starts to clean the nozzle of all ooze.
With 1.16 and prior this has worked perfectly but now it seems the firmware looses track that I'm using absolute mode in extrusion and the extruder goes berserk right when the print starts.

Are you certain that it is the pause command that causes it to set the extrusion mode to relative? The behaviour you describe is not expected.

Are you certain that it is the pause command that causes it to set the extrusion mode to relative? The behaviour you describe is not expected.

Obviously the pause.g sets it to relative to retract during the pause but this has not caused issues before. The absolute extrusion has continued after the resume right after where it left.
Something has changed regarding timing of things and there seems to be a race condition somewhere.
It used to work so that when I hit Pause right after the final calibration point, the hotend came up as per the final line in bed.g:
G1 X0 Y0 Z150 F15000 ; get the head out of the way of the bed
and then moved to the side as per the pause.g:
G1 X0 Y85 F5000 ; move head out of the way of the print
and when resumed, the print started normally.
Now it seems that the pause is somehow delayed and the hotend goes down ready to start printing and only after that moves to the side and it's a bit hit and miss what happens to the extruder. Mostly it goes berserk, so I guess the mode changes to relative (there is an M82 in the beginning of the gcode file as generated by the MatterControl slicer).

This is not a big deal, but for me the best solution would be if Resume could be made to work if there is a pause in the end of bed.g

I did the upgrade to 1.19beta11 and with the first initial tries the problem did not manifest. This does not mean it's gone, however as it did not happen every time with 1.18.2 either. I will repeat the tests some more.

What did happen was that during one try the extruder came up as per the G1 X0 Y0 Z150 F15000 in bed.g and then paused right there as if there would have been a M226 in the end of the file and I had to Emergency Stop to get out.
I repeated the test with the M226 in the file and the 1.19beta11 also gets stuck there.

For now I will add a pause in the prologue for new files produced by the slicer, but the best solution would be if the web interface could be made to resume after a pause in bed.g and of course it would be good to find the root cause. How does the system know to go back to absolute extrusion after a pause retraction anyway? Maybe that is being missed and the relative extrusion set in pause.g is sometimes left in effect?

Thanks for checking that. Let me know if you manage to get the extruder misbehaving with 1.19beta11.

The system goes back to absolute extrusion after a pause because each gcode source has its own absolute/relative flag. Also, after executing a macro, the absolute/relative state of the gcode source that invoked the macro is restored to what it was before the macro was run.

The sole exception to this is that when config.g is run at startup, after config.g ends the relative/absolute extrusion flag is copied to all gcode sources from the current value. This is so that a M82 or M83 command in config.g has the desired effect.

The same considerations apply to the G90/G91 absolute/relative movement mode and to the feed rate.

I'll look at making a change so that a pause command during execution of a macro file (whether caused by M226 in the gcode or externally using M25) is deferred until execution of the macro file ends.