When a print is paused, Z is reduced by 0.03/0.04 mm on restart
-
-
@jens55 in your config you are doing calculations instead of putting in the value, it may be a rounding issue , you could try putting in fixed values .
-
@moth4017, what in specific are you referring to?
Yes, I calculate motor current but that has no bearing on the issue.
I calculate z steps but that is an even number (no rounding) and besides, we are not talking actual height error (if the steps per mm are wrong) but we are talking what DWC 'thinks' is the z height. -
I just looked at the object model during a pause and the Z height is correct. It would appear that the printer goes back to the right position and then reduces Z height somehow. This is confirmed by the DWC Z height display where, during the resume, z height goes to 0.2 (first layer height) and then drops down to 0.16.
It sure looks like there is some macro someplace that somehow changes the height on resume .... but where would this happen ... is there something that automatically runs after pause.g has executed ???? -
@jens55 just a question are you doing the pause from DWC or in the slicer software ? eg pause at height x "do something" then resume?
-
How does resurrect.g fit in the big picture? I thought it only applies when there was a power outage?
The reason I bring this up is because the resurrect.g file contains this line:G92 X266.207 Y126.771 Z-0.036 U0.000
and the z-0.036 seems very much like the error I am seeing.
-
@jens55 Any time you pause a print from SD card, the state of the print is saved to a special file on the SD card, sys/resurrect.g
-
@jens55 set value to 0 sys/resurrect.g and test
-
@moth4017, I need a bit more than that .... resurrect.g has a whole bunch of lines. Are you suggesting to set the Z portion of the G92 line to 0? BTW, on the other two printers the Z portion of the G92 command is 0.2.
Also, when I enter M911, the printer reports that auto save is disabled .... why would resurrect.g be run if auto save is disabled?
-
@jens55 just change this line G92 X266.207 Y126.771 Z0 U0.000
you will have to try and work out when it happens
you can add the :-
echo "this just happened"
in the *.g files to give you a pointer to when the move happens. and then monitor it in the DWC console
-
@moth4017, thanks for your help! I am giving up for today. I am pretty sure that the issue is related to the resurrect.g file but I have no clue why this file would be run when auto save is not enabled. The file is generated by the system and I do not know where it gets the Z offset value from.
I am hoping that somebody with more knowledge can explain to me how resurrect.g is generated, where the Z offset in resurrect.g comes from and why the resurrect.g file would be run if no autosave is enabled.
BTW, resurrect.g calls to execute resurrect-prologue.g but that file does not exist on this printer. -
@jens55 hi, did a test when you press "pause" in DWC it does the following
12/25/2023, 2:20:58 PM Printing paused at X153.7 Y153.2 Z2.7
12/25/2023, 2:20:57 PM Resume state saved
pause
12/25/2023, 2:20:56 PM M25
Resume state saved -
@moth4017, yes, my setup does the same thing .... everything works just like it should with the exception of DWC reporting a slightly lower Z (but only after it has gone to the correct Z)
-
@jens55 this is a long shot but i think worth doing, do the pause , but then run the resume.g lines of code one by one in the command line and see if this works correctly
-
@jens55 said in When a print is paused, Z is reduced by 0.03/0.04 mm on restart:
I am hoping that somebody with more knowledge can explain to me how resurrect.g is generated,
I thinks it's best to raise an official question in the beta firmware section.
Now that you know what to look for, it would be helpful to test the various 3.5rc_ candidates first -
@o_lampe, thanks for weighing in.
I am wildly guessing at this point and grasping at straws. Although the height issue 'seems' to coincide with something in resurrect.g, that file shouldn't actually run according to what I believe.I did another test by modifying pause.g and resume.g with an M291at the end of each file. I could then see what the head position is at each stage. As it turns out, after resume.g has executed, the nozzle is exactly where it is supposed to be. After I dismiss the message, Z immediately changes from 0.2 to 0.17 (when printing first layer of 0.2 mm) and then it continues printing. I do not know if the nozzle position has actually changed at this point or if the Z display in DWC has just been reset for some reason or other.
So what happens between resume.g finishing and the print process starting back up? Something is obviously telling Z to change.
I checked to see if bed compensation somehow enters the picture but bed compensation, according to the height map, is in the 0.1 range in the area where all this is happening.
-
I am still hoping that someone can shed some light on my issue of Z dropping between 0.03 and 0.04 after every pause/resume sequence.
To summarize, during a print, if I pause the print and then resume the print, the printer (jubilee tool changer on 3.5.0 RC2) performs pause.g and resume.g correctly. After the printhead has reached it's location where the pause had originally been activated and after resume.g has finished but before actual printing starts again, the nozzle drops (or at least DWC reports a drop in Z position) by between 0.03 and 0.04 mm. This happens every time a pause/resume cycle is performed. No tool change is involved.
I tested two single nozzle printers that run 3.5.0RC1 and neither printer does this. -
@jens55 A couple of questions that I couldn't find the answers to above:
What board are you running on this printer? Is it the same board as in the other printers that have only one tool?
What are the tool offsets for the tool you are using?
-
@gloomyandy, I am using a Duet3 6HC board and the other printers use Duet2wifi boards. From my config-override.g:
G10 P0 X-4.250 Y43.060 Z-0.248 U0.000
G10 P1 X-4.700 Y42.480 Z0.108 U0.000
G10 P2 X-4.590 Y43.030 Z-0.194 U0.000
G10 P3 X-4.064 Y43.567 Z0.125 U0.000The issue was first noticed on tool 0 but then testing moved to tool 2 (lower temperatures) as it was displaying the same issue.
-
@jens55 Do you allow Z-moves below "0" in your printer limits?
I just thought, that Z-moves below zero would be ignored if not, but on other occasion RRF thinks it has been there.
Safest strategy would be to adjust the tool with the attached z-probe the lowest and all other tools above or equal.
Or is it the other way round? Those tool offsets always confuse me...
