When a print is paused, Z is reduced by 0.03/0.04 mm on restart
-
@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... -
@o_lampe It is interesting that both tools that (so far) have shown the problem have a negative Z offset.
@jens55 If possible can you try and see if you see a problem with the other two tools (the ones that have a positive offset).
If they do can you go back to your current setup (tool 2) and try commenting out the following line from your resume.g
G1 R1 X0 Y0 Z0My understanding of the RRF code is that it will restore the position without you needing to do it, but the code path will be different between the two cases, so I'd like to see if this changes things.
Also FYI the code for handling pause and restore is different between the Duet 2 and Duet 3 versions so the problem you are seeing may not be anything to do with having multiple tools.
-
@o_lampe, I allow z movement to -0.5. In the case of this printer, the z-probe is located on the carriage and not with the tool. I do not understand what you are trying to say.
-
@gloomyandy, I will do the test a bit later this morning and post my results.
Interesting re pause and restore being different between Duet2 and Duet3 ... but please note that both the pause.g as well as the resume.g code executes correctly. The unexplained Z movement happens after the last line of code of resume.g has executed and before the printer starts printing again. It seems to be a distinct code execution as in 'printhead stops at correct point after last line of resume.g, printhead then moves down a bit (or DWC reports the shift to a lower z), a distinct but very brief pause, the printer starts moving x,y and e'. -
@jens55 It would be useful if you can identify if the print head actually moves or if it is just the DWC display that changes.
Also are you able to test to see if the same problem exists with your two other tools?
-
I think I may have found a smoking gun ....
Given a particular print job with first layer height being 0.2 mm:
If I print the first layer without a pause, DWC always reports a layer height of 0.2 mm (for the entire first layer)
If I print WITH a pause, DWC will report a height that may or may not differ from 0.2 mm after the pause/resume cycle. This height appears to be dynamic as in 'it changes during the print of the first layer'. Oddly, even at higher layers where there should be no bed mesh compensation, DWC still reports odd heights if a pause/resume cycle was executed.
If I turn off the bed mesh, a pause cycle will always continue at 0.2 mm.So, it would appear that during the pause/resume cycle, something changes in how DWC reports Z height. While normally DWC will not report the corrections due to mesh bed compensation (ie this happens in the background without the user being made aware), once the pause/resume cycle has run, DWC will report the actual height of the nozzle including bed compensation. In other words it shows the user the compensation that is applied.
I hope that makes sense, I am having difficulty describing this.
What is still throwing me is that there seems to be no correlation between the mesh bed compensation that the mesh bed graph displays and the z deviation that becomes visible after the pause/resume cycle.At this point I am thinking that there is a subtle bug that shows up when the pause/resume cycle happens. The issue is independent of the tool selected and has been observed in 3.5.0 beta 2 (I think) and 3.5.0 RC2.
-
@jens55 When you get this error, what happens when your print moves to the next layer? Does the small offset continue to show or does it disappear?
You might also want to try making a note of the X, Y, Z position that the pause takes place at, then (when not printing) return the nozzle to that location and run M122 that report should tell you what mesh correction is being applied at the current nozzle position. That way you can compare the mesh correction with any offset that was introduced (you may want to do this for several different points in the print).
I think you need to run more tests with the mesh disabled to confirm that the problem does not happen without the mesh. In a previous post you said that your other printers which do not show the problem also have a mesh in use.
-
@gloomyandy, i did several pause/resume cycles on layer one (0.2 mm) and every time I went through a pause/resume sequence the z height crept up. Eventually it ended up at 0.39 mm (while still on the 0.2 mm layer. When the next layer started to print, it did so at 0.4 mm and that did not change over a number of pause/resume cycles.
I am questioning my assertion that DWC is showing the raw z because it stepped up by 0.02/0.03 mm this time and that was repeated. No clue what is going on.I introduced an M122 command as the first line in pause.g and as the last line in resume.g. I got an offset of -0.083 but I question that figure because I did several pause cycles and that figure never changed. During the first cycle, z increased by 0.04mm, there was no increase in the second cycle but the third cycle showed an increase of 0.01mm. This is the 'move' section of M122:
=== Move ===
DMs created 125, segments created 21, maxWait 2429ms, bed compensation in use: mesh, height map offset -0.083, max steps late 1, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 38, on retry 0, too short 0, wrong shape 25, maybepossible 0Both of the Duet2 printers that do not show the issue report mesh bed compensation to be active with an offset of 0.0.
-
I have given up on trying to make sense of the issue.
One reason this issue is so perplexing is that the height correction when the printer resumes is different all the time. I have also observed that sometimes the issue only happens on the first layer but sometimes doing a pause on a higher layer also gets me a height correction. There are just too many inconsistencies for me to draw any conclusions.
Of course there is the distinct possibility that I am doing something to screw things up but I am unable to figure out what I could possibly screw up here. The entire thing is weird and my only solution at this point is to avoid pausing the printer.
I would be happy to test specific scenarios for a developer ( @DC42 ?) to assist in tracing the issue but will no longer try random things.
-
@jens55 I understand you frustration, I do intend to try and reproduce this problem on my toolchanger, but I'm pretty busy at the moment so it may take a while. I look after the STM32 version of RRF and would like to make sure that this problem is understood and fixed. If you can face running more tests, then I would really like to know the answer to the following question (from the thread above):
What happens if you comment out the following line from your resume.g file:
G1 R1 X0 Y0 Z0Do you still see the offset?
