When a print is paused, Z is reduced by 0.03/0.04 mm on restart
-
@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?
-
@gloomyandy, I did two pause/resume cycles. Starting at 0.2 mm for Z, it went to 0.23 mm and then 0.27 mm.
I am happy to run more tests as long as I know that they are in furtherance to locating the issue. I don't mind if it takes a while to get sorted.
Re commenting out the line in resume.g - I just want to make sure that you understand the sequence of events that occur if I halt execution by putting a M291 as the last line in resume.g, The printer stops, Z is still at a 'move' height of 2 mm above printing, When I acknowledge the message and execution continues, Z drops to the correct height but then changes to the new (wrong) height. I want to say that sometimes there is no change in z right away but it happens later on after the print has continued but I have run so many tests that I can't be sure I recall things correctly.
-
@jens55 I'm a bit confused as to why if you put the M291 as the last line in resume.g it would be at 2mm above the print height. The line:
G1 R1 X0 Y0 Z0
Should have moved the print head to the saved position. Are you sure you had your M291 after that line and not before it? Having said that there have been so many issues with M291, that I tend to avoid using it if at all possible. You might want to try using a large dwell instead if you want to see what the situation is at the end of the macro.The reason I want you to remove that line is that the firmware will try and return to the pause after executing resume.g. However the way it does that will be different if you are already at the "correct" Z height, so I want to see if just letting the firmware follow the "normal" path produces a different result to what you have been seeing.
-
@gloomyandy, no idea why it does what it does. I was thinking that possibly the DWC display is lagging for an odd reason (I am not sitting in front of the printer). I just did as you suggested and put in a G4 S120. First pause it went to 0.27, second pause to 0.34. In both cases the indicated Z position was 2 mm above the bed when the pause command was pausing. It then dropped to the starting hight and then added the offset. Note that for reasons unknown, the offset is different from before even though it is the same model at the exact same bed position (I just did a 'print again').
Since the question came up, the offset disappears at the next layer (z becomes 0.40). I did another pause cycle and the z hight becomes 0.43 (hovering at 2.40 during the pause, going to 0.43 after the pause), next cycle height becomes 0.49 mm, next layer is 0.60 and after a pause becomes 0.63. During the last few pause cycles the height went directly from the position 2 mm above the start position to the new height without going to the actual start height (or at least DWC did not display the in-between step).My resume.g file during this set of tests was:
; Resume macro file
M116 ; make sure all temperatures are rightG1 R1 X0 Y0 Z2 F5000 ; go to 2mm above position of the last print move
; R1 X0 Y0 Z0 ; go back to the last print move
;G1 R1 X0 Y0 ; go back to the last print move
M83 ;relative extruder mode
G1 E3 F3600 ; extrude 3mm of filament
M82 ; reversal of M83 above
;M291 P" resume has finished executing" S2
;m122
G4 S120 -
Another interesting point that I seem to have discovered ...
I dial in babysteps for a perfect first layer, all is well.
If I do a print and pause, I see a change in Z height on resume (0.24 mm). If I repeat this a number of times I now longer get adhesion to the print bed ... in other words the nozzle has moved up. I can correct this with babysteps to re-establish proper adhesion.If I abandon that print and start a new print, without any pause or anything else but with babysteps set for what should give me a proper first layer based on the babysteps I discovered in the very beginning, the nozzle appear to now be too high even though Z indicates 0.20. I have to drop Z with babysteps to achieve adhesion to the print bed.
Note that as part of the print, in the start-gcode section of my slicer I do a G30. According to my probably limited understanding, that should reset Z zero .... but it appears to not do that based on the fact that, to get proper bed adhesion, I need to correct the nozzle height with babysteps.
If I now do an M999 to reset things and start printing the same model without any changes whatsoever and using the babystep setting that I established at the very beginning of this whole process (to get a good first layer without any pausing), I get a perfectly good first layer. In other words I no longer needed to correction for whatever happened during the previous pause cycle.
It would appear (even though I find this conclusion to be almost unbelievable) that whatever happens in the pause cycle to throw z off seems to survive past the current print and into the next print job even though a G30 is one of the first things of the next print job. Only an M999 seems to erase whatever was screwed up in the pause cycle.First layer adhesion seems a rather fickle thing for me so this whole thing needs to be taken with a grain of salt .... but I have repeated this testing several times and it seems to be repeatable.
-
@jens55 if the issue persists between print attempts, some adjustment isn't properly re-set.
I would try the following:
-
store the established baby stepping value in a global variable
-
in start.g,
- reset all compensation factors with M561
- home z
- load bed mesh if applicable,
- apply the baby stepping with the global variable.
Let me know if that addresses carry over effects from print to print (I am aware this doesn't help with your pause/resume issue).
Finally be aware that babystepping can be applied relative or absolute. Make sure you use absolute when setting it for a print (the reset procedure above would account for that but is strictly a workaround).
-
-
@oliof, thanks for your input. At this point it is much easier for me to do a m999 than anything else. I only mentioned that to possibly help with the pause/resume issue. I am also still not 100% certain that I believe what I saw.
M56 ???? there is no such thing based on the G code reference. I assume you mean M561?
Interesting re babystepping being available both absolute and relative - I was not aware. I only use babystepping via DWC. A read through the G code reference of M290 explained the situation to me. Learn something new every day ......
-
@jens55 yes, M561, post amended.
