Pausing print for the night
-
The Resurrection file is a macro so you could set it up to function however you want. In the section where you would home the printer you could insert a M291 dialogue with an axis jog control to manually position the print head and then set that as whatever you need it to be before resuming the rest of the print.
However I think microswitch repeatability will probably work fine. You can also use baby stepping during that first resumed layer to make fine adjustments. Might be helpful to reduce the print speed a lot for that layer as well so you have time to react and adjust.
Inter layer adhesion probably won't be the same for that resume layer compared to normal consecutive layers but it shouldn't be too bad.
When I was testing power loss resume I didn't notice any visible difference between the last printed layer and the resumed layer. I didn't do any destructive testing though.
Alternatively if you didn't mind leaving the printer powered up you could just configure the pause and resume macros to turn off the heaters, retract a bit, move the head aside and then sit idle until you resume it.
-
@phaedrux
Sooo Does the DWC pause button create a resurrection file? or is there any way / gcode command to trigger the creation of one other that killing the power?I cannot really leave the psu on for the night, because it's quite noisy.
-
The link I included above goes over setting up for power loss. The resurrection file is updated with current position constantly.
-
@phaedrux
Thanks! -
@denke said in Pausing print for the night:
@phaedrux
Sooo Does the DWC pause button create a resurrection file? or is there any way / gcode command to trigger the creation of one other that killing the power?I cannot really leave the psu on for the night, because it's quite noisy.
Yes, in all recent firmware versions the pause button creates a resurrect.g file. So to do a planned power down in the middle of a print you should pause the print (preferably while it is doing infill), turn the heaters off, wait for the hot end to cool down (so that it is safe to stop the heatsink fan), then turn the power off. That's what we did at the TCT show last year to print the submarine on the SCARA printer.
-
@dc42
Thanks!
Iis there a way to set the head position and engage "idle hold" instead of homing the printer to be able to continue from a known position? -
@denke said in Pausing print for the night:
@dc42
Thanks!
Iis there a way to set the head position and engage "idle hold" instead of homing the printer to be able to continue from a known position?You mean leave the motors in idle hold overnight? The motors will go into idle hold after 30 seconds of inactivity anyway. So you can just pause the print and turn the heaters off. Remember to turn the heaters on and let them reach operating temperature before resuming.
-
@dc42
No, I mean command the printer to a known location, and power it down there. When it's powered on again, then <if there is a way> I could set the current nozzle position back to the duet, so I could resume the print without the need for homing. Maybe this way I could acheive more accuracy compared to homing? -
When you power down and up again, the motors will jump to the nearest multiple of 4 full steps that matches the motor positions. So you really need to home the printer after powering on again.
If it helps, you could home just X and Y, then "manually" home Z by jogging the nozzle to be a known height above the bed and using a G92 Z command to tell the firmware what that position is.
-
So the microswitch should be more precise than 0.04 mm? (100 mm / step setup)
BTW the gcode database seems to be incorrect when stating: "A G92 without coordinates will reset all axes to zero." At least for a delta with fw 2.0 "stable" it seems to do nothing, while G92 X0 Y0 Z0 works as expected.Again, thank You for your help!!
-
@denke said in Pausing print for the night:
BTW the gcode database seems to be incorrect when stating: "A G92 without coordinates will reset all axes to zero." At least for a delta with fw 2.0 "stable" it seems to do nothing, while G92 X0 Y0 Z0 works as expected.
I think that behaviour applies to some other firmwares, but not to RRF. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_G92_Set_Position.