XY shift after power fail
-
@tomf said in XY shift after power fail:
Here is the start code from my slicer.
Looking at your slicer's start code, I suggest you to retry the procedure I proposed in a previous post - with one additional step:
Append this line from the slicer's start script to your resurrect-prologue.g:
M564 S0
I'm really curious what happens
Edit: Another thing worth trying is to remove the priming block (enclosed by the
M564gcodes) from the start code before you slice the test print. I still don't know from where the offset originates: from the initial setup or from the retry after power failure. -
@infiniteloop said in XY shift after power fail:
M564 S0
Sorry, that didn't make any difference.
Neither did moving the home & levelling routines from the slicer to a start.g file
Neither did changing the purge line on the slicer's start gcode to be entirely within the axis boundary.
EDIT: Neither did commenting out the prime line block of the slicer start code.All these give a consistent XY offset of (-0.3, -3.5).
Not sure what to do from here.
-
@tomf said in XY shift after power fail:
@infiniteloop said in XY shift after power fail:
M564 S0
Sorry, that didn't make any difference.
Neither did moving the home & levelling routines from the slicer to a start.g file
Neither did changing the purge line on the slicer's start gcode to be entirely within the axis boundary.
EDIT: Neither did commenting out the prime line block of the slicer start code.All these give a consistent XY offset of (-0.3, -3.5).
Not sure what to do from here.
If the offset is consistent as a temporary fix could you not add a relative G1 move somewhere to adjust for it?
Frederick
-
@fcwilt Yes I may end up doing that but I would much rather get to the root cause.
-
@tomf said in XY shift after power fail:
G32 ; MESH BED LEVELLING
Can you post your bed.g file as well?
-
@tomf said in XY shift after power fail:
M280 P0 S160 ; Precautionary alarm release M280 P0 S90 ; Ensure the pin is raised
You may need to add a G4 S1 delay between these commands.
@tomf said in XY shift after power fail:
G29 S1 ; Set Units to Millimeters
The command doesn't match the comments here. You should remove that G29 S1 from config.g. You don't want to load the mesh until you've established Z0 with the probe anyway. Load it in your start gcode after homing and leveling.
@tomf said in XY shift after power fail:
M552 P192.168.1.144 S1
Remove the S1, it's already on the previous line.
@tomf said in XY shift after power fail:
; Tools
M563 P0 D0 H1 F1 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0CM950 H1 C"out1" T1 ; create nozzle heater output on out2 and map it to sensor 1
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M143 H1 S280 ; set the maximum temperature in C for heaterYour tools are defined before the heater is created. The tool definition should come after.
That should take care of the errors in your config.g
-
@phaedrux said in XY shift after power fail:
@tomf said in XY shift after power fail:
G32 ; MESH BED LEVELLING
Can you post your bed.g file as well?
Here is my bed.g file:
; this script compensates for what the Z offset is
; so if G31 P500 X-30 Y-15 Z1.7 then first probe will be at
; X30 Y20 (when G30 P0 X0 Y5)M561 ; clear any bed transform
G30 P0 X10 Y10 Z-99999 ; probe near a leadscrew
G30 P1 X150 Y280 Z-99999 ; probe near a leadscrew
G30 P2 X270 Y10 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors -
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?
