Mid Air Prints unless I Restart
-
@jasperkm said in Mid Air Prints unless I Restart:
@p40whk could you check if there is a G10 command at the end of the .gcode file that you're running? (just before the end gcodes will run)
0_1550429099237_3030_filament_guide_v2.gcode
I've attached the file I'm currently printing. Checked a few others as well and there is no G10 command present.
-
I was just told that GitHub is not very much looked at when it comes to firmware issues (posted the issue here just in case: https://github.com/dc42/RepRapFirmware/issues/266) ...so just want to check with @dc42 if there's anything else I could contribute to this ? I know you asked for Gcode...so just not to leave any unanswered questions, it was:
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusionG1 Z0.100 F18000.000
G1 X50 Y50 F18000.000
G1 F2000
G1 X150 Y150
G1 X50 Y150
G1 X150 Y50With pause.g having
G10
G1 Z+20 F6000 -
Here's a quick video of the end of the first print and start of the second print.
-
@randomfactoid said in Mid Air Prints unless I Restart:
@dc42 thanks to your suggestion about the simple gcode, I think I found the problem.
Apparently if you have G10 in your pause.g (or, I suppose anywhere in your Gcode) and have Z hop defined in M207, after cancelling the print (or, I'd guess, finishing it without unretracting), after starting a new print, z=0 becomes the value of the Z hop height in M207, because it zhops, the print gets cancelled or finishes and never actually zhops down to previous height.
I tested this by uncommenting G10 from my pause.g and the problem disappeared. I also tried setting M207 Z(random number) and after starting a new print, Z=0 is at a height of (random number) and actually you can jog the nozzle into negative numbers after stopping the print...and it goes right to the negative height of M207 Z value.
This seems like a bug in the firmware as Zhop height doesn't get cancelled after the print finishes without unretracting.
Thanks for the report. I've added this to the development list for the next 2.03beta release. Meanwhile you can work around this issue by putting G11 commands in appropriate places, for example in cancel.g and stop.g. Perhaps also in your slicer start GCode and in homeall.g. A G11 command will be ignored unless there is a G10 command that has not already been undone using G11.