XY shift after power fail
-
Have you tested yet with a file that doesn't have object cancelation ?
-
@tomf said in XY shift after power fail:
Not sure what to do from here.
Well, look where the weird offset originates from. At least, we now can exclude some culprits:
- config.g - this file is run by the MCU after each reset of power-off, setting the system into a consistent state
- homex.g and homey.g - these cannot produce the offsets, a fact you have verified with your "double power failure" experiment.
- start.g (and the purging section in the slicer's start code). You've tested and modified that as well.
That's a lot of gcodes we now can ignore. Furthermore, resurrect.g does a pretty good job in freezing the state of all imaginable parameters it holds in its object model - it works as expected (see your second "power failure).
Which brings me to the following thesis: from the view of RepRap, the x/y coordinates prior to a power failure are "wrong" (i.e. unknown to the object model). Either you execute a macro I'm not aware of before starting the print - must then be something very special
ā¦ Or the slicer "knows" something about your printer's geometry which the object model of the Duet isn't aware of, i.e. nozzle offsets etc. When resurrect.g is called, it jumps right into the middle of the print file, thus ignoring the foreplay which the slicer celebrates at the beginning.To verify my thesis, you could strip-off the intro from the .gcode file - use a bare text editor, look for the first G1 codes with X, Y and E parameters. But caution: the nozzle height must be prepared to fit for the first layer, so set Z to something like 0.2 mm before running the stripped .gcode file.
If you think this is too risky, go through the prefs of your slicer (can't give you hints, I have no knowledge of SuperSlicer) and look for any X/Y offsets you inserted for your printer: nozzle, center of printhead, Z-probe, etc. Maybe you get a clue? Then, slice again.
Good luck!
-
@phaedrux said in XY shift after power fail:
Have you tested yet with a file that doesn't have object cancelation ?
Yes. In the test in reply to @infiniteloop from 25 Jan @07:40 EST I commented out the M486 lines and it didn't help.
-
Might be onto something... but how to fix??
Having done lots of tests I wondered if I had missed something so I decided to re-run some again. Photo for test #5 is the interesting one but I'll run through the others.
-
Superslicer with all normal start gcode, inclusive of XYZ homing, mesh levelling and prime line, but no going outside the XY boundaries for the prime line. Power off mid print, move head out the way manually and restart using M916. Result is that the offset is the same as before (X-.3, Y-3.5)
-
As 1 but comment out the M486 'cancellation' lines in ressurect.g. Same result.
-
As 1 but delete the M564 S0 code from ressurect-prologue.g (I had left it in from previous tests). Same result
-
Comment out the home and mesh levelling routines from the slicer. Manually home, but no mesh levelling. No change.
-
As 4 but also comment out the prime lines. NO LAYER SHIFT, hooray!
-
Repeat 5. Unfortunately this time the layer shift was back as before.
Clearly very odd, but I noticed something that had been happening but that I was ignoring. I was getting error messages (2 examples below, the second relates to test 6) EXCEPT that there was no error message associated with test 5.
"
Error: in file macro line 31 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3B 0.4n_0.2L_PLA_15m_4g.gcode selected for printingressurect.g line 31:
M486 S0 A"M-test 3 id:0 copy 0"
"
"
Error: in file macro line 31 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode selected for printingressurect.g line 31:
M486 S0 A"M-test 3 id:0 copy 0"
"
I have no idea what might be going on, but the fact that this seems intermittent is concerning. Any suggestuins? -
-
Have you tried with a different slicer?
-
-
@tomf @Phaedrux is right: try some other slicer. And here's why: the errors you cite refer to object cancellation - me as well as @Phaedrux asked early to test a sliced object without that extra complication. Now that's back for reasons I don't know.
Maybe you have even fed the slicer with a single stl, and it generated the object cancellation code by itself (or by default). That's something you should clarify, I have no idea how SuperSlicer works internally.
Second, as I tried to explain in my last comment, I suspect some mechanism in the slicer to produce errant coordinates. At least, your numerous tests have proved that: "something" in the first lines of the .gcode file provides this mysterious offset.
Another note: there must have been a difference between tests #5 and #6. The errors are reported from resurrect.g, which is generated each time at the event of a power failure. That is, it's contents and line count will vary. If you continue testing, it would be helpful to copy the particular resurrect.g into a folder ("test#7" ā¦), perhaps together with a second document containing the lines you strip off the .gcode file in each case.
One last thing: I know that your chase for a mysterious offset is a nightmare, but up to now, you have done a good job to narrow down on the reasons behind that. Don't give up!
-
Thanks guys! I'll try different slicers tomorrow. Your help is much appreciated.
-
Can you also test homing and moving to a position and then homing again and seeing if returning to that position moves to the same place?
-
@phaedrux Hi @Phaedrux, I think that works fine. @tomf has run a test with two power outages, which means two calls of resurrect.g including homing of X and Y - the coordinates were consistent. The coordinate offset is wrong in the first place, not after power-off, when resurrect.g reflects the data of the Duet's object model. There is something in the slicer's .gcode file which Duet's firmware isn't aware of.
-
@phaedrux That's it! I was in agreement with @infiniteloop but did the test anyway and it showed up the problem.
In my firmware, there's a homeall.g routine that homes XYZ and separate homex and homey routines. When the print is first started, homeall.g runs from the slicer start code, but after a power outage, homex.g and homey.g are run. @Phaedrux test showed that there's a difference.
Examining homeall.g there are some things I didn't understand for the X&Y axes. At my level, most gcode is fairly incomprehensible and I just accept it but here I commented out those and pasted the relevant sections from homex and homey codes. And it worked! the original homing routines are pasted near the start of this topic.
Thank you both for the excellent advice and support to resolve this, which is a firmware bug I think, since all the home sequences used were 'as received'.
There is still the matter of the M486 errors, so I collected a couple during testing today. The last sequence, (labeled 3) is when I was confident the XY shift was eliminated and I copied all console messages of the test (start print, switch printer off, switch printer on, run M916 resurrect, pause print, cancel print). It is curious that line 30 is sometimes called as the error line although it doesn't not contain an M486 code.
'1'
1/27/2022, 8:26:26 AM Error: in file macro line 31 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3 0.4n_0.2L_PLA_15m_4g.gcode selected for printing
lines 30 to 33:
M82
M486 S0 A"M-test 3 id:0 copy 0"
M486 S0G17
M23 "0:/gcodes/rr_M-test 3 0.4n_0.2L_PLA_15m_4g.gcode"'
'
'2'
1/27/2022, 8:44:31 AM Error: in file macro line 30 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3 0.4n_0.2L_PLA_15m_4g.gcode selected for printing
lines 29 to 32:
G92 E0.30789
M82
M486 S0 A"M-test 3 id:0 copy 0"
M486 S0G17
'
'3'
CONSOLE MESSAGES ON FINAL PRINT:
1/27/2022, 11:54:21 AM Cancelled printing file 0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode, print time was 0h 2m
1/27/2022, 11:54:20 AM Printing paused at X110.2 Y5.2 Z11.9
1/27/2022, 11:54:13 AM Resume state saved
1/27/2022, 11:51:45 AM Error: in file macro line 30 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode selected for printing
1/27/2022, 11:50:07 AM Connection established
1/27/2022, 11:50:06 AM Connection interrupted, attempting to reconnect...
HTTP request timed out
1/27/2022, 11:49:52 AM Connection established
1/27/2022, 11:49:31 AM Connection interrupted, attempting to reconnect...
HTTP request timed out
1/27/2022, 11:44:50 AM Leadscrew adjustments made: 0.104 0.069 0.145, points used 3, (mean, deviation) before (0.105, 0.026) after (0.000, 0.000)
1/27/2022, 11:44:20 AM M32 "0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode"
File 0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode selected for printing
'
lines 29 to 32:
G92 E0.64877
M82
M486 S0 A"M-test 3 id:0 copy 0"
M486 S0G17 -
Yep, @Phaedrux is a champ in online debugging.
Concerning the error "M486: non-empty string expected": depending on the state of the object model at power-off, the line count of ressurrect.g might vary. So to be sure which M486-statement is the culprit, you should run some tests again. Same object, no need to re-slice it. Just switch power off mid-print, then comment-out one of the M486 gcodes before you continue the print. Does the error message still pop up? My "favourite" is M486 S0G17, as it makes no sense to me.
-
@infiniteloop said in XY shift after power fail:
Yep, @Phaedrux is a champ in online debugging.
Concerning the error "M486: non-empty string expected": depending on the state of the object model at power-off, the line count of ressurrect.g might vary. So to be sure which M486-statement is the culprit, you should run some tests again. Same object, no need to re-slice it. Just switch power off mid-print, then comment-out one of the M486 gcodes before you continue the print. Does the error message still pop up? My "favourite" is M486 S0G17, as it makes no sense to me.
When I comment out the M486 S0G17 the restart goes okay but there is still an error. This time it included the M916 code (I hadn't seen that before):
1/27/2022, 2:06:47 PM M916
Error: in file macro line 30 column 12: M486: non-empty string expected
File 0:/gcodes/rr_M-test 3C 0.4n_0.2L_PLA_15m_4g.gcode selected for printingAdditionally, after the final cancelling of the print (having restarted and competed the test), the BL Touch flashes and the status displays the Z probe senor as 1000 in red. I had to switch off to clear that.
'
Next up was to re-run the test, this time commenting out the "M486 S1 A"M-test 3 id:0 copy 0"" line. Again, the print restarted okay and ran normally. This time there were no errors and the BL Touch was in a normal state. That probably means the M486 S1 A"M-test 3 id:0 copy 0" line is the problem.However none of this affects restoring the print after power fails and it seems safe to ignore it. So I feel much happier now thanks to both @infiniteloop and @Phaedrux since we do get occasional power outages that makes overnight prints a cause for concern.
However it seems to be a bug in the way the ressurect file is configured.
Can you suggest how & where I should report the bugs found in the homeall.g and ressurect.g files?
-
@tomf said in XY shift after power fail:
Can you suggest how & where I should report the bugs found in the homeall.g and ressurect.g files?
As @Phaedrux follows your thread, he will already have registered that there's something wrong with object cancellation in resurrect.g
Personally I don't think homeall.g is buggy. What you get with a Duet are templates which have to be adjusted for each printer: bed size, printable area, axis origins etc., and in cases like yours, the homing of Z with a probe. It's another case if you buy a Duet-controlled printer from an OEM - he is then responsible for macros to meet his printer's specs.
-
I don't really see why there would be a difference in behavior between the homeall and homex and homey other than the use of H2 moves in the homeall and x and not in the homey.
Can you test removing the H2 from the X Y moves in home all? They shouldn't be needed anyway because all the do is allow a move when the axis hasn't been homed yet, but in that case the axis should already be homed. This can actually lead to a case of the homing failing and not being detected.
The H2 option should only be used on the Z axis moves for when you want to raise and lower the Z axis for clearance for XY moves even though the Z axis may not have been homed yet.
-
@phaedrux said in XY shift after power fail:
I don't really see why there would be a difference in behavior between the homeall and homex and homey other than the use of H2 moves in the homeall and x and not in the homey.
Can you test removing the H2 from the X Y moves in home all? They shouldn't be needed anyway because all the do is allow a move when the axis hasn't been homed yet, but in that case the axis should already be homed. This can actually lead to a case of the homing failing and not being detected.
The H2 option should only be used on the Z axis moves for when you want to raise and lower the Z axis for clearance for XY moves even though the Z axis may not have been homed yet.
Yes, that's it. I removed the H2 from X axis sequence in homeall and it worked correctly and repeatably. Also removed the H2 from homex where I had been noticing a strange Y move of about 3mm just after the X axis home. This would be negated by then homing the Y axis. But if I homed Y and then X, there was an offset. Those 2 corrections have done the job, thanks! Below is the working version of homeall.g (I think the comments need some work though!)
; BLTouch
M280 P0 S160 ; Precautionary alarm release
M280 P0 S90 ; Ensure the pin is raisedG91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current positionG1 H1 X-625 Y605 F3600 ; move quickly to X and U axis endstops and stop there (first pass)
G1 H1 X-625 F1800 ; move quickly to X and U axis endstops and stop there (first pass)
G1 H1 Y605 F1800 ; move quickly to X and U axis endstops and stop there (first pass)
G1 X5 Y-5 F6000 ; go back a few mm
G1 H1 X-625 Y605 F360 ; move slowly to X and U axis endstops once more (second pass)
G1 H1 X-625 F360 ; move slowly to X and U axis endstops once more (second pass)
G1 H1 Y605 F360 ; move slowly to X and U axis endstops once more (second pass)G90 ; absolute positioning
G1 X150 Y150 F10000 ; go to first probe point
G30 ; home Z by probing the bedG91 ; relative positioning
G1 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning
