G30 during G28 issue

Leonard03

@fcwilt Thank you for the extensive response. I will try to answer your ideas an questions in order so:

Those G1 H2 Z# commands are not needed if you simply home Z first and leave it at a safe position for then homing X and Y.

Homez.g I tried to keep it as simple as possible. Most of the time I don't use individual homing files, and every time I home XY and after Z and if MMU is enabled W V and U in that order.
I use the H2 parameter in home X and Y only because it allow movement of Z.

@fcwilt said in G30 during G28 issue:

Now is is just my personal preference but I forgo the minor optimizations that can be done in homeALL.g by just invoking the individual homing routines:

I use this approach only for the MMU part (UV and W) The only reason I don't use this for main axis is because I like the motion of both X and Y during homing, in tandem Running both as separate M98 calls will separate that motion, that I don't like. Aesthetics, only reason :)) Ah, and I set the Z offset only during a print using G28 because the homez.g I can use it for another thing: rough leveling the bed after disassembly. After that I use the BL touch for more accurate Z0.
Before any print and before bed tramming (G32) and mesh (G29) yes, i use the sensor. for anything else, the switch is good enough (another example is NonLinear Extrusion calibration. Extruding in mid air)

@fcwilt said in G30 during G28 issue:

As to the original issue I am still stumped - something is being overlooked I imageine.

I am pretty sure that is the case..

@fcwilt said in G30 during G28 issue:

One thing to remember is the some errors in config.g can cause the processing of config.g to be cut short.

Very good point! And I have a dumb answer to this :)) Apart of the last command regarding the config-override.g.. If my config.g gets in trouble, I know it because the PanelDue will remain not connected :)) So.. if PanelDue is is not connecting, I know that I messed something up in the config

@dc42 said in G30 during G28 issue:

did you ever test this system using RRF 3.6.0-rc.2; and if so, did that have the same issue?

Thank you for your replay. I tried rc.2 now with the same result... Sadly I don't know when this behavior started. I will try with rc.1 as well and report back

fcwilt

@Leonard03

Thanks for the reply.

Since you have a Z end-stop homing Z first means you have no need to use G1 H2 commands.

Why not use the simplest code possible?

I understand it may be satisfying in some sense to optimize homing by coding homeALL.g discretely but that again makes the code more complicated. Also it means if you find a flaw in homing X or Y you have to makes changes in multiple places.

In any case it's your printer to configure as you please, just offering advice based on many years of programming experience and several years for using Duet hardware.

Now back to the original issue.

If you don't set the Z=0 Datum in the homing code, it all homes correctly?

When you set the Z=0 Datum in some separate code is the X position the same before and after executing the code?

Frederick

Leonard03

@dc42 Found when! Tried now old binaries that I have saved.
This particular issue occurred between 3.6.0-beta.2+4 (2024-12-01 18:14:39) and 3.6.0-beta.2+5 (2025-01-04 14:18:24).
In +4 version the X axis homes in the same location regardless of the G30. In the +5 version.. well.. is the present topic. I also have the .map files for them if they help you in any way

Leonard03

@fcwilt Now, back on the 3.6.0-rc.3
You pointed out some very interesting things, I admit!

@fcwilt said in G30 during G28 issue:

Since you have a Z end-stop homing Z first means you have no need to use G1 H2 commands.

Now looking at that particular macro.. I wonder the same.. Why?

@fcwilt said in G30 during G28 issue:

Why not use the simplest code possible?

For those two points, I don't have an answer, just an excuse :)) This macro most likely is the original generated by the RRF configurator for the version 3.2. So is quite old. But if it is not broken, don't fix it This is the excuse. But now I'm releasing that it makes no sense now.
This part, done. Removed the line that contained the G1 H2 command from homez.g.

@fcwilt said in G30 during G28 issue:

just offering advice based on many years of programming experience and several years for using Duet hardware.

Thank you very much for this, I really appreciate this ^_^

@fcwilt said in G30 during G28 issue:

f you don't set the Z=0 Datum in the homing code, it all homes correctly?

Let me see if I understand the question correctly:
You are referring to the G92 Z0 command, right?
I use it in both homez and homeall.

Removing it from homez.g: no change, so another line deleted
Removing it from homeall.g: no change, so another line deleted as well
The original issue is still present, sadly..
As for this

@fcwilt said in G30 during G28 issue:

When you set the Z=0 Datum in some separate code is the X position the same before and after executing the code?

I don't understand your question, I apologize. Plese give me a little more details so I can try out

fcwilt

@Leonard03 said in G30 during G28 issue:

I don't understand your question, I apologize. Plese give me a little more details so I can try out

Let's assume the current Machine Position is X=20 Y=20.

To verify this you will need to check in the Object Model as the DWC user interface shows User Position, not Machine Position.

Then execute the G30 at that position.

Then check the Machine Position to see if it has changed.

Frederick

Leonard03

@fcwilt Right, got the point!
I've made this little macro:

; printer is homed using G28 X Y Z prior to executing this macro

G90
G1 Z10 F600 ; space for the BLTouch pin to extend

echo "User " ^ move.axes[0].letter ^ " position is: ", move.axes[0].userPosition
echo "Machine " ^ move.axes[0].letter ^ " position is: ", move.axes[0].machinePosition
echo "User " ^ move.axes[1].letter ^ " position is: ", move.axes[1].userPosition
echo "Machine " ^ move.axes[1].letter ^ " position is: ", move.axes[1].machinePosition

This is the result after G28 X Y Z:

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

Now, moving the nozzle 100mm in X and Y, so, G1 X100 Y100 F2400

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 and the result:

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

Not exactly, but they seems to be pretty close. The physical position is way bigger

fcwilt

@Leonard03

Good job.

Very strange.

I'm wondering at this point if there is a problem in the firmware.

If I was using RC firmware (which I never do) I would resort to the last stable version prior to the RC version and see if the problem goes away.

Frederick

Leonard03

@fcwilt Thank you ^_^
Digging deeper, I got something:

@Leonard03 said in G30 during G28 issue:

This particular issue occurred between 3.6.0-beta.2+4 (2024-12-01 18:14:39) and 3.6.0-beta.2+5 (2025-01-04 14:18:24).

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

fcwilt

@Leonard03 said in G30 during G28 issue:

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

There was a time when I would install beta or rc firmware - but no longer - I have things to print.

So I am still using 3.5.4.

Frederick

dc42

@Leonard03 said in G30 during G28 issue:

@dc42 Found when! Tried now old binaries that I have saved.
This particular issue occurred between 3.6.0-beta.2+4 (2024-12-01 18:14:39) and 3.6.0-beta.2+5 (2025-01-04 14:18:24).
In +4 version the X axis homes in the same location regardless of the G30. In the +5 version.. well.. is the present topic. I also have the .map files for them if they help you in any way

Thanks for pinning this down to that version increment. I will review the commit history and work out the cause. It may be specific to Duet 2.

dc42

@Leonard03 are you able to reproduce this issue other than in the homing file?

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?

PS - one more test please: if you temporarily set the probe X and Y offsets to 0 in your G31 command, does the issue still occur?

PPS - created https://github.com/Duet3D/RepRapFirmware/issues/1116

dc42 created this issue in Duet3D/RepRapFirmware

open G30 changing X coordinate #1116

Leonard03

@dc42 said in G30 during G28 issue:

Thanks for pinning this down to that version increment. I will review the commit history and work out the cause. It may be specific to Duet 2.

I'm glad I can help

@fcwilt @davidjryan Sorry for the delay.. Thank you guys for your help. I managed to modify my configuration, cleaned up some macros, renamed some others to make them easy to follow so now I can use the command M98 P"config.g" and you both were right. Is way better now, thank you again ^_^

@dc42 said in G30 during G28 issue:

@Leonard03 are you able to reproduce this issue other than in the homing file?

So far, no. Is only related to homing, with or without a probe.

@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?

I will use every time the individual homing files, do some G30s at some points (I think they will change) and report back. I will use the macro above to keep track of the coordinates

Leonard03

So, using my actual probe offsets, G28 X Y Z. Using the endstops, the X carriage is homed with the endstop blade pressed.
G1 X50 Y50

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

G30

User X position is:  49.618
Machine X position is:  49.618
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:  200.000
Machine X position is:  199.995
User Y position is:  200.000
Machine Y position is:  200.000

G30

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

Now, if I do G1 X0 Y0 the result is

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

but the x carriage is far away in the X+ direction
G92 X0 sets the X at 4. This is the correct offset set in config.
G1 H4 X-50 here:

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

So, after 4 G30s at different coordinates, the X0 Y0 is set at 9.475mm from where it should been, right?

Leonard03

Now, G31 P500 X-27.4 Y-28.6 Z2.00 from config.g and G31 K0 P500 X-27.4 Y-28.6 Z1.92 in config-override.g, both set to G31 K0 P500 X0 Y0 Z2.00 and restart.
Homing with individual files:

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

This is the fresh start.
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:  200.000
Machine X position is:  199.995
User Y position is:  200.000
Machine Y position is:  200.000

G30

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

Going back 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 again G1 H4 X-50 the position now is: (but I forget the G92 X0 command.. )

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

After those tests, opening the config.g lead to a board reset
this is the M122:

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-rc.3 (2025-04-30 14:41:53) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7JKDG-3S06M-9ZSWD
Used output buffers: 2 of 26 (22 max)
=== RTOS ===
Static ram: 24016
Dynamic ram: 70576 of which 0 recycled
Never used RAM 25404, free system stack 206 words
Tasks: NETWORK(1,ready,12.3%,217) HEAT(3,nWait 5,0.1%,330) Move(4,nWait 5,0.0%,359) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,86.8%,733) IDLE(0,ready,0.9%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:01:24 ago, cause: software
Last software reset at 2025-05-14 20:03, reason: StuckInSpinLoop, Platform spinning, available RAM 24852, slot 1
Software reset code 0x4080 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20002968 Task NETW Freestk 1073741462 ok
Stack: 00000000 20001414 10000000 e000e000 000000a4 0045e705 0045dd8a 610f0000 0000019e ffffffff 00000000 000f8dd6 00000000 2000045c ffffffff 20002e90 00000001 0045de27 20002a18 2000022c 38f5edae 0045b27b 20001088 004056a5 a5a5a5a5 a5a5a5a5 2000045c
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 20.8, current 22.2, max 28.1
Supply voltage: min 1.3, current 1.3, max 4.9, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 99/41, heap memory allocated/used/recyclable 2048/1200/480, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2025-05-14 20:05:05
Slowest loop: 9.52ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, requested/actual speed: 25.0/20.0MBytes/sec
SD card longest read time 48.9ms, write time 53.8ms, max retries 0
=== Move ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
No step interrupt scheduled
Driver 0: ok, SG min n/a
Driver 1: ok, SG min n/a
Driver 2: ok, SG min n/a
Driver 3: ok, SG min n/a
Driver 4: ok, SG min n/a
Driver 5: ok, SG min n/a
Driver 6: ok, SG min n/a
Driver 7: ok, SG min n/a
Driver 8: ok, SG min n/a
Driver 9: ok, SG min n/a
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
=== DueX ===
Read count 3, 2.13 reads/min
=== Network ===
Slowest loop: 13.67ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.1
Module reset reason: Power up, Vcc 3.40, flash size 4194304, free heap 39332
MAC address b4:e6:2d:52:f5:47
IP address 192.168.0.107
Signal strength -34dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

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