XY shift after power fail
-
@infiniteloop said in XY shift after power fail:
@tomf The result of your double power fail is interesting: seems that resurect.g shifts X and Y consistently. I propose to try this:
Comment-out any homing commands from your start.g and from the start section (if any) of your slicer. Instead, before starting the test print, home X/Y withG28 X Y(home Z as usual, that doesn't matter here). If you still see the layer shift after power-off, we have to look where the origin of X/Y might eventually be re-defined. In case the layer shift is gone, we can focus on your homing macros.That made a difference! There's still an offset, but this time X-1.7, Y-2.0 so it suggests something's going on there. I don't know what but I really appreciate your input!
I don't have a start.g, instead I have homng and bed levelling in the slicer start code. I will change that and move the homing commands to to a start.g. I'll run again and report the findings. -
Can you post your slicer start gcode or better yet the first 50 lines or so of your sliced gcode file?
I can see some oddities in your config.g but nothing I think would cause the offset.
-
@phaedrux said in XY shift after power fail:
Can you post your slicer start gcode or better yet the first 50 lines or so of your sliced gcode file?
I can see some oddities in your config.g but nothing I think would cause the offset.
I don't know how to see the code lines in the gcode file, but here is the sliced file of the updated test part. rr_Macro test 2.1 0.4n_0.2L_PLA_16m_6g.gcode
I would appreciate knowing any 'oddities' in my config.g as I'm fairly new at this and trying to get it running smoothly.
Here is the start code from my slicer. I'm not using a start.g file
G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
G28; HOME ALL
G32 ; MESH BED LEVELLING
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
M572 D0 S0.04 ;set PRESSURE ADVANCE;;PRIME LINE
G4 P1000; Pause
M300 S500 P800; Beep and we're off!
G4 P1000; PauseM564 S0 ; allow movement outside boundary
G1 X190.0 Y-2.0 Z0.4 F1000.0 ; go outside print are
G92 E0.0 ; set extruder position
G1 X170.0 E9.0 F1000.0 ; intro line
G1 X120.0 E12.5 F1000.0 ; main prime
G92 E0.0; reset extruder
M564 S1 ; limit movement within axis boundaries -
@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.
