G30 during G28 issue

[Leonard03]

And a thought occurred now: what about the offsets set by M208 S0?
I reverted my config.g and config-override.g.
Changing M208 X4 Y-2 Z0 S1 to M208 X0 Y0 Z0 S1 restart, homing with individual files, and G1 X50 Y50

User X position is:  50.000
Machine X position is:  50.005
User Y position is:  50.000
Machine Y position is:  50.000

G30

User X position is:  49.630
Machine X position is:  49.630
User Y position is:  50.000
Machine Y position is:  50.000

G1 X100 Y100

User X position is:  100.000
Machine X position is:  99.997
User Y position is:  100.000
Machine Y position is:  100.000

G30

User X position is:  99.285
Machine X position is:  99.285
User Y position is:  100.000
Machine Y position is:  100.000

G1 X150 Y150

User X position is:  150.000
Machine X position is:  150.003
User Y position is:  150.000
Machine Y position is:  150.000

G30

User X position is:  148.940
Machine X position is:  148.940
User Y position is:  150.000
Machine Y position is:  150.000

G1 X200 Y200

User X position is:  198.595
Machine X position is:  198.595
User Y position is:  200.000
Machine Y position is:  200.000

G30

User X position is:  197.195
Machine X position is:  197.195
User Y position is:  200.000
Machine Y position is:  200.000

G1 X0 Y0, G92 X0 and G1 H4 X-50 the result is X = -14.38
Looks like the M208 S1 has nothing to do with this issue

[Leonard03]

@dc42 said in G30 during G28 issue:

For example: suppose you home the printer, then send G1 X150 Y150. Ignore any error that this point. Then send G30 zero or more times; then send G1 X160 Y160. Does the head position at this point (relative to where the head was after the G1 X150 Y150) depend on how many times you sent G30?

First I'll go X120 Y120 without probing the Z.

User X position is:  120.000
Machine X position is:  119.997
User Y position is:  120.000
Machine Y position is:  120.000

And the results:

Probe #1
User X position is:  119.147
Machine X position is:  119.147
User Y position is:  120.000
Machine Y position is:  120.000

Probe #2
User X position is:  119.147
Machine X position is:  119.147
User Y position is:  120.000
Machine Y position is:  120.000

Probe #3
User X position is:  117.447
Machine X position is:  117.447
User Y position is:  120.000
Machine Y position is:  120.000

Probe #4
User X position is:  116.597
Machine X position is:  116.597
User Y position is:  120.000
Machine Y position is:  120.000

Probe #5
User X position is:  115.747
Machine X position is:  115.747
User Y position is:  120.000
Machine Y position is:  120.000

You're right. Repeating G30 without moving the toolhead, actually is altering the coordinates

Repeating the same procedure, this time at X160 Y160 without rehoming

User X position is:  160.000
Machine X position is:  159.996
User Y position is:  160.000
Machine Y position is:  159.988

And the results:

Probe #1
User X position is:  158.896
Machine X position is:  158.896
User Y position is:  159.988
Machine Y position is:  159.988

Probe #2
User X position is:  157.796
Machine X position is:  157.796
User Y position is:  159.988
Machine Y position is:  159.988

Probe #3
User X position is:  156.696
Machine X position is:  156.696
User Y position is:  159.988
Machine Y position is:  159.988

Probe #4
User X position is:  155.596
Machine X position is:  155.596
User Y position is:  159.988
Machine Y position is:  159.988

Probe #5
User X position is:  154.496
Machine X position is:  154.496
User Y position is:  159.988
Machine Y position is:  159.988

Now,
G1 X0 Y0 goes to X4 Y0 (correct offsets)
G92 X0 Y0 goes to X4 Y0
G1 H4 X-50
And the result

User X position is:  -24.837
Machine X position is:  -24.837
User Y position is:  0.00
Machine Y position is:  0.00

Well.. wow.. this is the biggest shift so far

[fcwilt]

@Leonard03

Just FYI - G92 is not a movement command, it merely sets the current axis position to whatever value present.

So G92 X123 Y456 sets the logical X position to 123 and the logical Y position to 456.

Frederick

[Leonard03]

@fcwilt Yes. In this case I only used G92 to measure the distance between logical and physical positions
Hmm.. I did it wrong?
I'm referring to G1 H4 command. It was better to measure from let's say X80 to the endstop?

[fcwilt]

@Leonard03 said in G30 during G28 issue:

I'm referring to G1 H4 command. It was better to measure from let's say X80 to the endstop?

I'm not sure what you mean by "measure".

Frederick

[Leonard03]

@fcwilt Since every G30 command alters the X coordinate without physically moving the stepper, after the initial homing, I don't know where the toolhead is.

By setting its physical position to X0 Y0, using G92, I can measure the distance between the reported and actual positions relative to endstop.
Let's say I move the nozzle to X80 and perform 10 probes at that point; the reported coordinate is no longer X80, regardless of the actual physical position. If I set that position as the zero position and perform a G1 H4 move toward the endstop, the reported X position afterward is the offset amount. I want to obtain that value from a theoretical zero point.
Normally, if I move to X80 and return by pressing the endstop blade, the actual and reported coordinates should be close (accounting for endstop accuracy), but currently, they are not. I do this out of curiosity to see "how much."
Hope this make sense

[droftarts]

@Leonard03 said in G30 during G28 issue:

M556 S100 X0.69

I just noticed you have axis skew compensation enabled in your config.g. Can you try with this disabled?

Ian

[Leonard03]

@droftarts Sure, why not
Starting with this:

Axis compensations - XY: 0.00000, YZ: 0.00000, ZX: 0.00000

G28 X Y Z, again, using individual homing files, no G30 involved for now.
Axis positions:

User X position is:  4.000
Machine X position is:  4.000
User Y position is:  -2.000
Machine Y position is:  -2.000

Move to G1 X120 Y120

Probe #1
User X position is:  120.000
Machine X position is:  120.000
User Y position is:  120.000
Machine Y position is:  120.000

Probe #2 
User X position is:  120.000
Machine X position is:  120.000
User Y position is:  120.000
Machine Y position is:  120.000

Probe #3
User X position is:  120.000
Machine X position is:  120.000
User Y position is:  120.000
Machine Y position is:  120.000

Probe #4
User X position is:  120.000
Machine X position is:  120.000
User Y position is:  120.000
Machine Y position is:  120.000

Well.. this is something in the right direction
Now, G1 X160 Y160

Probe #1
User X position is:  160.000
Machine X position is:  160.000
User Y position is:  160.000
Machine Y position is:  160.000

Probe #2
User X position is:  160.000
Machine X position is:  160.000
User Y position is:  160.000
Machine Y position is:  160.000

Probe #3
User X position is:  160.000
Machine X position is:  160.000
User Y position is:  160.000
Machine Y position is:  160.000

Probe #4
User X position is:  160.000
Machine X position is:  160.000
User Y position is:  160.000
Machine Y position is:  160.000

From X160 Y160, going to X0 Y0

User X position is:  4.000
Machine X position is:  4.000
User Y position is:  0.00
Machine Y position is:  0.00

And the toolhead parked against the endstop blade! As it should
So @droftarts, you are right. Skew compensation is involved in this
Update: homeall.g works as expected without the skew compensation

[droftarts]

@Leonard03 Okay, thanks for testing! I'll highlight this to @dc42, hopefully it gives him something to focus on fixing.

I guess a follow up question is: do you need skew compensation enabled?

Ian

[Leonard03]

@droftarts Thank you

@droftarts said in G30 during G28 issue:

I guess a follow up question is: do you need skew compensation enabled?

This a very good question. I can answer with a maybe. But since in normal operation I don't encounter this bug, I think I leave skew compensation enabled for now.
Only time when this bug presents itself (and how I discovered it) is after "Resume after power loss". In that case I can rehome only the X and Y (Z axis remains enabled) without the probe. This gives a pretty substantial layer shift in the printed model after resume.

As a background: I use UPS and a mains power feedback thru a phone charger, a relay powered by the charger and two of the switching contacts of the relay connected to the duex.e3stop
This way, if power is out, I stop the print, disable nozzle heater, X and Y (and the UVW) but keep the bed up to temperature and Z steppers active as long as the UPS can provide power (about an hour). If the mains power comes back, I call M916 to do the resume. At this stage problems with this occurred.

[dc42]

@Leonard03 can you confirm that if you disable skew compensation, the original problem that occurred during homing no longer occurs?

[droftarts]

@dc42 I'm pretty sure he did:

@Leonard03 said in G30 during G28 issue:

And the toolhead parked against the endstop blade! As it should
So @droftarts, you are right. Skew compensation is involved in this
Update: homeall.g works as expected without the skew compensation

Ian

[Leonard03]

@dc42 @droftarts yes, I can confirm. Without skew compensation enabled the issue is solved

[dc42]

@Leonard03 thanks.

I found a bug that may account for this issue. Please try the new firmware build at https://www.dropbox.com/scl/fo/dumsdufoej44q97ek9joo/AIBRnU-wtKfMrbWPzZwH_XY?rlkey=idmyinvvcuiwmycbb1l2obz38&dl=0.

[Leonard03]

@dc42 Thank you very much. I tested the new binary.
The issue is still there, but is way better.
Now, if I resume a print, the shift in X- direction got smaller - from 10mm to ~2mm. Not quite there, but much better

[Leonard03]

As a visual representation; all 3 prints had a "power failure" occurred to them

[gloomyandy]

@dc42 It seems that the latest change has helped with this problem: https://forum.duet3d.com/topic/37913/3-6-0-rc2-error-g30-z-probe-readings-not-consistent

[dc42]

@Leonard03 thanks for your feedback.

Please try the new frmware build at https://www.dropbox.com/scl/fo/xk6t4cibc602j0s3qmp48/AGouwT4mDySsLdBItGjDUcM?rlkey=k8j1rrfx18ixoyvizvs0hbehz&dl=0 and report whether it is better/same/worse.

[Leonard03]

@dc42 Thank you for the update
Sadly, is still the same. 2mm shift in X-
The left is without M556
The right with M556

[droftarts]

@Leonard03 Thanks for your continued testing. Was the calibration cube on the right caused by a pause/resume, or by a "power failure" (please explain how you did this!)?

I've just been testing this too, and find that I was able to provoke the bug when using G30 and skew compensation in 3.6.0-rc.3, but that it works correctly in 3.6.0-rc.3+1.

With one bug resolved, I think there's something else going on when you pause and/or 'simulate a power failure', then resume/resurrect. It would seem that skew compensation is not applied, or the position is reset. When a print is paused, or there is a power failure, RRF creates a 'resurrect.g' file in the /sys folder, which is then used to return the tool to the correct position a resume the job. It could be that it is not applying skew compensation at the correct point during this.

Could you:

1. Start a print normally.
2. Pause the print, or 'simulate a power failure'
3. Send M556 to show the current skew compensation setting
4. Copy the 'resurrect.g' file from /sys and post it
5. resume the print and see if it shifts
6. Post your pause.g, resume.g and the output of M556 (in case it has changed, or isn't being applied any longer)

Thanks!

Ian