G30 during G28 issue

[Leonard03]

@Phaedrux Thank you for the replay

@Phaedrux said in G30 during G28 issue:

You also have a z endstop?

Yes, is there, so why not use it When homing Z I lower the gantry until that switch is triggered and then do a G30 in the center of the bed.

@Phaedrux said in G30 during G28 issue:

Please post your full config.g

This is my full config, but it uses some additional macros

; Configuration file for Duet WiFi (firmware version 3.5)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.2.0 on Tue Dec 29 2020 16:23:44 GMT+0200 (Eastern European Standard Time)

global MMUmode = true										; enable or disable Multi Material Unit

if global.MMUmode = true
	global spoolJoin = false								; enable or disable the SpoolJoin feature of the Multi Material Unit
	global useCutter = true									; enable or disable the CUT feature of the Multi Material Unit

	global statusBondtech = 0
	global statusFinda = 0
	global currentSlot = {null, null}						; [0]last loaded slot, [1]last tool temperature
	global loadNext = false
	global pause = false
	global tcBlock = false
	global counter = {0,0,0}								; [0]extruder count, [1]fails, [2]total attempts
	
global errQueue = {null,null}								; first two elements are reserved

; General preferences
G90															; send absolute coordinates...
M83															; ...but relative extruder moves

if global.MMUmode = false
	M550 P"Creality CR-10L"									; set printer name
else
	M550 P"Creality CR-10L+MMU3"

; Network
M552 S1														; enable network
M586 P0 S1													; enable HTTP
M586 P1 S0													; enable FTP
M586 P2 S0													; disable Telnet

; Drives
M569 P0 S1													; physical drive 0 goes forwards (X)
M569 P1 S1													; physical drive 1 goes forwards (Y)
M569 P2 S0													; physical drive 2 goes backwards (Z1)
M569 P3 S0													; physical drive 3 goes forwards (E)
M569 P4 S0													; physical drive 4 goes backwards (Z2)

if global.MMUmode = true
	M569 P5 S1												; physical drive 3 goes forwards (U)
	M569 P6 S0												; physical drive 3 goes backwards (V)
	M569 P7 S1												; physical drive 3 goes backwards (W)

M584 X0														; set drive mapping for X axis
M584 Y1														; set drive mapping for Y axis
M584 Z2:4													; set drive mapping for Z axis (dual independent)
if global.MMUmode = true
	M584 E3:3:3:3:3											; set drive mapping for virtual extruders
	M584 U5													; set drive mapping for U axis (MMU selector)
	M584 V6													; set drive mapping for V axis (MMU pulley)
	M584 W7 R1 S1											; set drive mapping for W axis (MMU idler)
else
	M584 E3													; set drive mapping for extruder

M350 X16 Y16 Z16 E16 I1										; configure microstepping with interpolation
if global.MMUmode = true
	M350 U16 V16 W16 I1

M92 X80.00 Y80.00 Z400.00 E415.00							; set steps per mm
if global.MMUmode = true
	M92 U400 V167.13 W8.89

M566 X600.00 Y600.00 Z24.00 E3000.00						; set maximum instantaneous speed changes (mm/min)
if global.MMUmode = true
	M566 U60 V240 W6

M203 X18000.00 Y18000.00 Z1200.00 E7200.00					; set maximum speeds (mm/min)
if global.MMUmode = true
	M203 U2700 V5700 W18000

M201 X3000.00 Y3000.00 Z100.00 E3000.00						; set accelerations (mm/s^2)
if global.MMUmode = true
	M201 U200 V800 W1000

M201.1 X500 Y500 Z50 E500									; set reduced acceleration for special move types (mm/s^2)
if global.MMUmode = true
	M201.1 U100 V400 W500

M906 X1000 Y1000 Z800 E600 I40								; set motor currents (mA) and motor idle factor in per cent
if global.MMUmode = true
	M906 U700 V700 W700

if global.MMUmode = true									; set idle timeout
	M906 T60
else
	M906 T30

; Axis Limits
M208 X4 Y-2 Z0 S1											; set axis minima
if global.MMUmode = true
	M208 U0 V-1000 W0 S1

M208 X315 Y308 Z400 S0										; set axis maxima
if global.MMUmode = true
	M208 U75 V1000 W225 S0


; Endstops
M574 X1 S1 P"^xstop"										; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"^ystop"										; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S1 P"^zstop"										; configure active-high endstop for low end on Z via pin zstop
if global.MMUmode = true
	M574 U2 S3
	M574 V2 S3
	M574 W1 S3

; Z-Probe
M950 S0 C"!exp.heater7"										; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H4:2 F240:120 T9000 A20 S0.01			; set Z probe type to bltouch and the dive height + speeds S0.005
G31 P500 X-27.4 Y-28.6 Z2.00								; set Z probe trigger value, offset and trigger height
M557 X8.0:285.0 Y21.6:279.4 P10								; define mesh grid

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4092				; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0										; create bed heater output on bedheat and map it to sensor 0
M307 H0 B1 S1.00											; enable bang-bang mode for the bed heater and set PWM limit
M140 H0														; map heated bed to heater 0
M143 H0 S110												; set temperature limit for heater 0 to 110C

M308 S1 P"spi.cs1" Y"rtd-max31865"							; configure sensor 1 as thermocouple via CS pin spi.cs1
;M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.060000e-8	; E3D V6 thermistor (Semitec 104-GT2)
M950 H1 C"e0heat" T1										; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 B0 S1.00											; disable bang-bang mode for heater and set PWM limit
M143 H1 S400												; set temperature limit for heater 1 to 400C

; Fans
M950 F0 C"fan0" Q10000										; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 L0.3 C"Tool"									; set fan 0 value. Thermostatic control is turned off
M950 F1 C"fan1+^exp.pb6" Q25000								; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T45 C"Heatsink"								; set fan 1 value. Thermostatic control is turned on

; Tools
if global.MMUmode = false
	M563 P0 D0 H1 F0										; define tool 0
	G10 P0 X0 Y0 Z0											; set tool 0 axis offsets
	M568 P0 R0 S0 A0										; set initial tool 0 active and standby temperatures to 0C

elif global.MMUmode = true
	M563 P0 S"Slot 1" D0 H1 F0										; define tool 0
	G10 P0 X0 Y0 Z0											; set tool 0 axis offsets
	M568 P0 R0 S0 A0										; set initial tool 0 active and standby temperatures to 0C

	M563 P1 S"Slot 2" D1 H1 F0										; define tool 1
	G10 P1 X0 Y0 Z0											; set tool 1 axis offsets
	M568 P1 R0 S0 A0										; set initial tool 1 active and standby temperatures to 0C

	M563 P2 S"Slot 3" D2 H1 F0										; define tool 2
	G10 P2 X0 Y0 Z0											; set tool 2 axis offsets
	M568 P2 R0 S0 A0										; set initial tool 2 active and standby temperatures to 0C

	M563 P3 S"Slot 4" D3 H1 F0										; define tool 3
	G10 P3 X0 Y0 Z0											; set tool 3 axis offsets
	M568 P3 R0 S0 A0										; set initial tool 3 active and standby temperatures to 0C

	M563 P4 S"Slot 5" D4 H1 F0										; define tool 4
	G10 P4 X0 Y0 Z0											; set tool 4 axis offsets
	M568 P4 R0 S0 A0										; set initial tool 4 active and standby temperatures to 0C

; Custom settings
M81 C"pson"													; ATX in stadby mode at boot

M308 S2 Y"mcu-temp" A"MCU"									; MCU temperature sensor (sensor 2)
M912 P0 S-7.2												; set temperature monitor adjustment (MCU)

M308 S3 Y"drivers" A"SD Duet"								; duet drivers temperature sensors (sensor 3)

if global.MMUmode = true									; duet drivers temperature sensors, only when MMU is used (sensor 4)
	M308 S4 Y"drivers-duex" A"SD DueX"

M308 S5 P"e1temp" Y"thermistor" T100000 B4092 A"Ambient"	; Ambient teperature sensor (sensor 5)

M307 H0 R0.135 C783.5 D0.39 S1.00 V12.2						; set the process parameters (bed 60degC)
M307 H1 R1.757 K0.275:0.139 D6.31 E1.35 S1.00 B0 V12.2		; set the process parameters (hotend 210degC)

M207 S0.8 F1800												; set retract length (PLA)
M404 N1.75													; set filament width

if global.MMUmode = false
	M591 D0 P2 C"^e0stop" S0								; filament monitor connected to E0 endstop (Drive 0), not enabled

M950 J1 C"^e1stop"											; Input 1 uses e2stop pin, pullup enabled (EmergencyStop button)
M581 P1 T0 S1 R0											; external trigger 1, trigger occurs on the active-to-inactive edge, trigger at any time

M950 J2 C"^duex.e3stop"										; Input 1 uses e2stop pin, pullup enabled (power feedback for UPS)
M581 P2 T2 S1 R1											; external trigger 1, trigger occurs on the inactive-to-active edge, trigger at any time (UPS Backup power)
M581 P2 T3 S0 R2											; external trigger 1, trigger occurs on the active-to-inactive edge, trigger only when not printing from SD card (AC back, resume prompt)

M593 P"ZVD" F30.1 S0.05										; use MZV input shaping to cancel ringing at 26.35Hz, damping factor 0.1, minimum acceleration 20mm/s^2

;M204 P600 T800												; set printing and travel accelerations (mm/s^2) - original Creality CR-10S
;M204 P1000 T2000											; set printing and travel accelerations (mm/s^2) - Artillery SW-X2, https://github.com/MarlinFirmware/Configurations/tree/import-2.1.x/config/examples/Artillery/Sidewinder%20X2
M204 P1250 T1250											; Prusa MK4
;M204 P1500 T2000

M671 X-25:334 Y0:0 S2.5 F1.6								; adjusting screws at front left, back left, back right and front right. Thread pitch M4 corse: 0.7mm

M556 S100 X0.69												; axis skew compensation, diagonal method

if global.MMUmode = true
	M98 P"0:/sys/MMU Control/settingsPrinter.g"
	M98 P"0:/sys/MMU Control/settingsDefaultFilament.g"
	M98 P"0:/sys/MMU Control/currentSlot.g"
	M98 P"0:/sys/MMU Control/currentSlotReset.g"

; Miscellaneous
M575 P1 S1 B115200											; enable support for PanelDue
M501														; load saved parameters from non-volatile memory

This is the full SD card: https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=drive_link

@Phaedrux said in G30 during G28 issue:

M98 P"config.g"

This is failing short because of global variables defined at startup..

M98 P"config.g"
Error: in file macro line 6 column 17: meta command: variable 'MMUmode' already exists

[davidjryan]

@Leonard03
I don't have an answer for your original issue, but...

If you want to get your config.g to run with M98 without the error after startup, you can use the exists() function to check if the global already exists and use the result to skip defining the globals again.
https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

So this,

global MMUmode = true					; enable or disable Multi Material Unit
 
if global.MMUmode = true
	global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
	global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
 
	global statusBondtech = 0
	global statusFinda = 0
	global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
	global loadNext = false
	global pause = false
	global tcBlock = false
	global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
	
global errQueue = {null,null}

becomes this,

if !exists(global.MMUmode)
        global MMUmode = true

if global.MMUmode = true
        global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
        global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
         
        global statusBondtech = 0
        global statusFinda = 0
        global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
        global loadNext = false
        global pause = false
        global tcBlock = false
        global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
        	
if !exists(global.errQueue)
        global errQueue = {null,null}

Then just change the true to false on line 2 to achieve the mode your desire between reboots.

You only need to check MMUmode because if MMUmode doesn't exist, then none of the globals can exist because MMUmode is used to create all of the other globals.

[Leonard03]

@davidjryan Thank you for the suggestion. I might modify all the startup in the near future. I'm still thinking about M505 to split my printer in two separate configurations. Anyway, you gave me a very good idea. Is way easy at least for now to comment out all global variables and macros that create them. So, the response is this:
@Phaedrux

M98 P"config.g"
HTTP is enabled on port 80
FTP is disabled
TELNET is disabled

[fcwilt]

@Leonard03 said in G30 during G28 issue:

Yes, is there, so why not use it When homing Z I lower the gantry until that switch is triggered and then do a G30 in the center of the bed.

Using it makes perfect sense.

What is odd, at least to me, is that your homing code is written as if there is not a Z end-stop. 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.

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:

M98 P"homeZ.G"
M98 P"homeX.G"
M98 P"homeY.G"

One other minor difference is that I don't set the Z=0 Datum during homing but only:

• when creating a height map
• when loading a height map
• when starting a print

Doing this ensures that any possible variations due to thermal changes are taken into account.

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

Frederick

[fcwilt]

@Leonard03

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

I dealt with this by tracing the processing of config.g to make sure that it ran to completion:

At the start of config.g I have this local variable declared:

var trace = "config_trace.txt"

Then I create the first line of the file:

echo >{var.trace} "trace begun"

Then I add additional lines as seem appropriate at appropriate locations:

echo >>{var.trace} "network config"

echo >>{var.trace} "motor config"

Finally at the end of config.g I have this:

echo >>{var.trace} "trace done"

It's not much work and can save time in the long run.

Frederick

[dc42]

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

I made a change to the way G30 probe coordinates are calculated between rc.2 and rc.3. It's possible that this change may have introduced a fault that is specific to Duet 2 boards.

[Leonard03]

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

@fcwilt said in G30 during G28 issue:

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

closed 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