Mid Air Prints unless I Restart
-
Does the printer not home itself when starting the new print?
What firmware version are you using? DWC version?
-
It does home itself, and DWC is at 1.21.
-
@p40whk is the firmware at 1.21 as well?
There was a bug around that version that would stack the z offset causing problems like you describe. I suggest you upgrade your firmwares.
-
Thanks but I misspoke, I wasn't at the computer where my printer is but I am up to date on firmware
-
I've seen at least 3 posts of this kind (one from myself) about this exact issue - Z height increment between subsequent prints. Don't think there was ever a solution but to babystep for the 1st layer (in my case for instance the Z babystepping required would be around 0.4-0.5mm) and then reset babystepping for the 2nd layer and magically 2nd layer comes back to normal layerheight. Interestingly, even though it prints in air, stopping the print and sending G1 Z0 sends the nozzle to the bed as it should be. I ended up migrating to klipper for this very reason, but reverted back as DWC/PanelDue were too much of a sacrifice
Can't wait for a solution. Btw, if it'd help with debugging, i'm happy to post my configs.
-
When the G32 leadscrew bed levelling runs at the start of your print, does it run correctly at the start of the second print, and what corrections does it report?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@randomfactoid said in Mid Air Prints unless I Restart:
I've seen at least 3 posts of this kind (one from myself) about this exact issue - Z height increment between subsequent prints. Don't think there was ever a solution but to babystep for the 1st layer (in my case for instance the Z babystepping required would be around 0.4-0.5mm) and then reset babystepping for the 2nd layer and magically 2nd layer comes back to normal layerheight. Interestingly, even though it prints in air, stopping the print and sending G1 Z0 sends the nozzle to the bed as it should be. I ended up migrating to klipper for this very reason, but reverted back as DWC/PanelDue were too much of a sacrifice
Can't wait for a solution. Btw, if it'd help with debugging, i'm happy to post my configs.
Are you able to construct a short GCode file that demonstrates this if I run it twice? Preferably without involving heating or extrusion.
Are you also using G32 leadscrew bed levelling?
-
@dc42 will try to do that asap...maybe today.
I am using G32 gantry leveling on Voron 2.1 using 4 z steppers with corrections of 0.0x or 0.00x on each one after 3 passes.
-
@dc42 said in Mid Air Prints unless I Restart:
When the G32 leadscrew bed levelling runs at the start of your print, does it run correctly at the start of the second print, and what corrections does it report?
Yes, it does run correctly at the start of the second print however, I didn't note what it reported, I'll set up a couple of jobs today and check that.
-
@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.
-
@randomfactoid So I just checked and don't have G10 anywhere in my code and am not using M207 yet I still have this issue. So, my problem even though related does not seem to be the same.
-
@p40whk what values does M207 return ?
-
@randomfactoid said in Mid Air Prints unless I Restart:
@p40whk what values does M207 return ?
I'm in the middle of a print right now, where/when would I use the M207 command?
-
Overall - at any point, but it'll probably be hard to see the output while printing. Although try that in console - it might work.
Tbh your issue sounds exactly like mine, but, you're right, it's different if you aren't using G10 anywhere. -
@p40whk said in Mid Air Prints unless I Restart:
@randomfactoid said in Mid Air Prints unless I Restart:
@p40whk what values does M207 return ?
I'm in the middle of a print right now, where/when would I use the M207 command?
M207 sets the parameters for firmware retraction. If you haven't set it up in the slicer to use it, it won't tell you anything. If you were using it, you'd know.
-
@phaedrux said in Mid Air Prints unless I Restart:
@p40whk said in Mid Air Prints unless I Restart:
@randomfactoid said in Mid Air Prints unless I Restart:
@p40whk what values does M207 return ?
I'm in the middle of a print right now, where/when would I use the M207 command?
M207 sets the parameters for firmware retraction. If you haven't set it up in the slicer to use it, it won't tell you anything. If you were using it, you'd know.
That's kind of what I thought, it's not set up in my slicing program.
I'm waiting for the first print to be done and I'll take a video of what it does when I go to print a new print.
-
@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)
-
@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.
