G30 during G28 issue

Phaedrux

@Leonard03 said in G30 during G28 issue:

G1 H1 Z-405 F240
G92 Z0

You also have a z endstop?

Please post your full config.g and the results of M122 and M98 P"config.g"

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