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?
-
Why not do the homing before the heating?
-
I home after heating as many do. But to answer the OPs question there are a number of ways you could tackle this.
-
as elmoret said home before heating then z probe after heating
-
In your pause file just home x and y instead of using coordinates
-
you can setup your endstops to execute an estop to prevent a crash but this will cancel your print if you pause before warming without one of the above two methods
-
-
I had thought about #2 but microswitches being what they are, if I pause during an actual print, it may not resume in the same place.
I guess the best answer unless there is an automated way to do this is just to do as was suggested above and just do a home all whenever I start the machine.
-
Why not start the bed heating up using M140, and then home? You can re-home just Z if necessary after heating.
-
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.
-
If I want to cancel during bed heating I send emergency stop, and as soon as it starts up again, manually set the bed temp active to prevent it cooling down too much while I get the right file loaded.
My start sequence is: G28 then heat bed, then heat nozzle to 130, then probe (with the nozzle), then nozzle to layer 1 temp, then purge at the side of the bed, then print.
-
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!
Jorma
-
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
-
Are you using a mixing hot end with mixing enabled for that tool, or a single-extruder hot end?
What happens if you put a M226 command at the very end of bed.g? Does it pause, and if so, are you able to resume?
It would be helpful if you can try the 1.19beta11 firmware, to see if it fixes either of these issues.
-
Are you using a mixing hot end with mixing enabled for that tool, or a single-extruder hot end?
What happens if you put a M226 command at the very end of bed.g? Does it pause, and if so, are you able to resume?
It would be helpful if you can try the 1.19beta11 firmware, to see if it fixes either of these issues.
I'm using a single extruder T3dP3d Kossel Mini.
The M226 pauses alright, but the only way to get out using the web interface is the Emergency Stop.
I'll load 1.19beta11 and report back.
Thanks! -
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.
