G30 during G28 issue

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
c9125daa-c730-472a-bc3d-7b3573f6191a-20250516_191104.jpg

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:

Start a print normally.
Pause the print, or 'simulate a power failure'
Send M556 to show the current skew compensation setting
Copy the 'resurrect.g' file from /sys and post it
resume the print and see if it shifts
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

Leonard03

@droftarts I also thank you for the continued help with this issue
Those are fair questions, and I will split my answer in two parts:
How it works and what actually happens

My printer has two power plugs (one and a half actually )
First, is the main power plug. Is the power plug for the UPS. Then, in the UPS is plugged the printer's ATX power supply and from it the Duet and DueX are powered.
The second, is a phone charger. A 5V 500mA power supply that serves as a power feedback.
From it I powering a 5V simple relay. The switching contacts of that relay (two of them) are wired to duex.e3stop

On that input, I have defined two triggers in config.g:

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)

Trigger2.g senses if that relay has power to it, so if a print is in progress, it will be executed.
It's macro is this:

; Called when mains power is intrerrupted and UPS battery is in use

M118 S"Running on backup power !" L0	; display warning message when using UPS battery
M25										; Pause printing process
M400
M0										; cancel current job
M568 P0 A0								; turn off nozzle heater

G91
; G1 Z-5

M18 X Y E0								; Disable steppers to conserve battery power, but leave Z stepper energized

M552 S-1								; Disable Wi-Fi adapter

if global.MMUmode = true
	echo >>"0:/sys/MMU Control/errLog.txt" state.time, ",", "Blackout occured", "Z="^move.axes[2].machinePosition-5	; -5 is the Z lift in pause.g
	M18 UVW								; disable MMU steppers

If the power goes out, the printer will continue to run on the UPS's battery, in the end safely shutting down the printer.
From what I intended to happen.. is as follows:

Show a dialog that the power is lost (really this never shows because of the pause dialog that is shown after that; not a problem)
list itemPause the print (using the M25), stage that the ressurect is created (if I'm not mistaken)
Cancel the print (M0) (stop.g behaves a bit differently in this case, compared with a normal job end, I will describe it later)
Turn off the nozzle heater, for a safe shutdown if the power is not restored in time
Disable X, Y and extruder steppers to conserve power
Disable the WiFi adapter (if the power goes out, the router will be also powered off, so to prevent the board from continuing to search for the network and flood the PanelDue interface with dialogs complaining that it can't find the network)
If the MMU is enabled, disable its steppers as well (to conserve power) and log this event to a file.

As stated above, regarding the M0 or stop.g in this scenario:

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
;
; generated by RepRapFirmware Configuration Tool v3.2.0 on Tue Dec 29 2020 16:23:44 GMT+0200 (Eastern European Standard Time)

G91
G1 Z10 F6000										; lift z by 10mm

if global.MMUmode = false
	M221 S100 D0
	T-1
	M106 P0 S0
else
	M221 S100 D0
	M221 S100 D1
	M221 S100 D2
	M221 S100 D3
	M221 S100 D4

	M572 D{state.currentTool} S0
	G1 E3 F800

	M106 P0 S0

	T-1
	M98 P"0:/sys/MMU Control/moveIdler.g" S5
	M98 P"0:/sys/MMU Control/counterCheck.g"
G90
G0 X0 Y300 F3600																; go to the back left corner

M18 X Y E0																		; disable X, Y and E steppers

if global.MMUmode = true														; if MMU is enabled
	M18 U V W																	; disable MMU steppers
	if state.status = "processing"
		echo >>"0:/sys/MMU Control/errLog.txt" state.time, ",", "Print complete!"

M568 P0 A0																		; turn off tool 0 heater

if sensors.gpIn[1].value = 1
	M140 S-273.15																; turn off bed heater
	if move.axes[2].machinePosition < 150
		G1 Z150
	M400
	M18 Z
	M81 S1																		; turn off ATX after nozzle cooldown

In normal operation, at the end of the print, I lift the nozzle above the print, reset extrude factor override percentage just in case it was modified during the print, disable pressure advance, and an attempt to give the filament end a nice, sharp tip , so it can be loaded easily next time, then unload the filament.
Then move the bed forward, park the tool carriage to endstop, disable the MMU steppers and turn off the nozzle heater.

Now, if the power feedback says that there is no mains power (the charger, relay and duex.e3stop input), keep the bed at the print temperature, so the print will not detach from the print surface, and don't rise the Z too much but keep the Z steppers energized, so they keep their positions set by the G32 at the start of the print. Also, keep the power supply turned on (opposite to the M81 S1 if there are no power related issues)

After this is completed, the printer will wait until the power is recovered. The UPS cand provide almost one and a half time to resume.

How I resume after a power failure:
If the printer is still powered on using the UPS and the mains power comes back, the phone charger will receive power again, turning on the relay. The relay, will tell the bord that power is back, so in the rising edge of the duex.e3stop will use the trigger3.g:

; Called when mains power is back

M118 S"Back on AC power" L0									; display warning message when using UPS battery
M552 S1														; Enable Wi-Fi adapter again

if fileexists("0:/sys/resurrect.g")
	M291 P"Back on AC power. Resume print ?" R"UPS Status" S3	; Prompt if printing can be resumed
	M916														; Resume print after power loss

	if global.MMUmode = true
		echo >>"0:/sys/MMU Control/errLog.txt" state.time, ",", "Blackout recovered"

Now that everything is good to go:

Reenable the WiFi module and reconect to the router
Search for the ressurrect.g and if it is found, ask if the print can be resumed.
If I confirm, run the M916 command to go ahead.

Resurrect-prologue.g is this:

M17 E0

G28 X Y						; home X and Y, hope that Z hasn't moved
if global.MMUmode = true
	M98 P"0:/sys/MMU Control/homeMMU.g"

G91
G1 Z-5

Reenable the extruder stepper (this is a very old bug in RRF. I can't use the MMU to load filament if the extruder stepper is disabled, so enable it before anything else)
Home X and Y axis (Z axis has never been disabled)
Rehome the MMU (UVW axis)
Lower the Z axis (I can't remember exactly why this is necessary, but it works)
And after, RRF executes ressurrect.g.

Until now, is anything that seems out of place?

Pause.g is this, but is complicated:

; pause.g
; called when a print from SD card is paused
;
; generated by RepRapFirmware Configuration Tool v3.2.0 on Tue Dec 29 2020 16:23:44 GMT+0200 (Eastern European Standard Time)

if global.MMUmode = false
	M83							; relative extruder moves
	G10
	G91							; relative positioning
	G1 Z5 F600					; lift Z by 5mm
	G90							; absolute positioning
	G1 X0 Y0 F6000				; go to X=0 Y=0
	M591 D0 S0

else
	if state.status != "paused"
		echo >>"0:/sys/MMU Control/errLog.txt" state.time, ",", "Pause"

	set global.pause = false

	if state.status = "pausing"
		if global.errQueue[#global.errQueue-1] = "SELECTOR_CANNOT_HOME" || global.errQueue[#global.errQueue-1] = "SELECTOR_CANNOT_MOVE" || global.errQueue[#global.errQueue-1] = "INSPECT_FINDA"
			M18 U
		elif global.errQueue[#global.errQueue-1] = "PULLEY_CANNOT_MOVE"
			M18 V
		elif global.errQueue[#global.errQueue-1] = "IDLER_CANNOT_HOME" || global.errQueue[#global.errQueue-1] = "IDLER_CANNOT_MOVE"
			M18 W

	if global.spoolJoin = false && global.loadNext = false
		M83						; relative extruder moves
		G10
		G91						; relative positioning
		G1 Z5 F600				; lift Z by 5mm
		G90						; absolute positioning
		G1 X0 Y0 F6000			; go to X=0 Y=0
		M98 P"0:/sys/MMU Control/moveIdler.g" S5

	elif global.spoolJoin = true
		if global.loadNext = false
			M83					; relative extruder moves
			G10
			G91					; relative positioning
			G1 Z5 F600			; lift Z by 5mm
			G90					; absolute positioning
			G1 X0 Y0 F6000		; go to X=0 Y=0
			M98 P"0:/sys/MMU Control/moveIdler.g" S5
		else
			M83
			G10					; retract
			G91					; relative positioning
			G1 Z5				; lift
			G90
			G1 X310 Y0			; go outside bed
			G11					; unretract

			if state.currentTool = #tools - 1
				T0
			else
				T{state.currentTool + 1}
			
			if global.errQueue[#global.errQueue-1] = null
				G1 E30 F300		; purge air from the nozzle
				G10				; retract

During normal operation, or at least for now, commands after line 21 are not used
Pausing and resuming a print (not a power failure) works without problems, and the skew compensation has its normal value.
M556 is defined only in config.g, and for testing purposes I comment or uncomment it.
So I can do a power failure simply by unplugging the charger from its mains socket

Both cubes in the photo above, had a "power failure", the only difference between them is the skew compensation

A side note: the ressurect.g contains a resume command, but it behaves like a M24 P0 because it don't run the resume.g

Leonard03

Started now a print. Pause and resume works as expected, skew compensation is active

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

Inducing a "power failure" and resuming:

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

So skew compensation is still active and correctly applied, but the shift is there

dc42

@Leonard03 please post your resurrect.g file (after pausing) and your resurrect-prolog.g file.

Leonard03

@dc42 This a ressuregt.g after a print that had a shift, that I cancelled

; Resume printing file "0:/gcodes/xyzCalibration_cube,0.2mm,PLA,Anycubic PLA Pantone Spring Leaf,25m.gcode" after print paused at 2025-05-19 21:06
M140 P0 S60.0
G29 S1
M568 P0  A0 S210 R170
M568 P1  A0 S210 R170
M568 P2  A0 S210 R170
M568 P3  A0 S210 R170
M568 P4  A2 S210 R170
G21
M98 P"resurrect-prologue.g" X144.359 Y141.863 Z3.400 U57.000 V0.000 W17.998
M290 R0 X0.000 Y0.000 Z0.000 U0.000 V0.000 W0.000
M205 X10.00 Y10.00 Z0.40 U1.00 V4.00 W0.10
; Workplace coordinates
G10 L2 P1 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P2 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P3 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P4 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P5 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P6 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P7 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P8 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
G10 L2 P9 X0.00 Y0.00 Z0.00 U0.00 V0.00 W0.00
M486 S-1
T4
G54
M106 S0.99
M116
G92 E1.83369
M83
G94
G17
M23 "0:/gcodes/xyzCalibration_cube,0.2mm,PLA,Anycubic PLA Pantone Spring Leaf,25m.gcode"
M26 S54031
G0 F6000 Z5.400
G0 F6000 X144.359 Y141.863 U57.000 V0.000 W17.998
G0 F6000 Z3.400
G1 F1871.0 P0
M204 P1000.0 T2000.0
G21
M106 P0 S0.99
M302 P0
M24

And this is resurrect-prologue.g

M17 E0

G28 X Y						; home X and Y, hope that Z hasn't moved
if global.MMUmode = true
	M98 P"0:/sys/MMU Control/homeMMU.g"

G91
G1 Z-5

Please have a look at this description

@Leonard03 said in G30 during G28 issue:

Reenable the extruder stepper (this is a very old bug in RRF. I can't use the MMU to load filament if the extruder stepper is disabled, so enable it before anything else)
Home X and Y axis (Z axis has never been disabled)
Rehome the MMU (UVW axis)
Lower the Z axis (I can't remember exactly why this is necessary, but it works)
And after, RRF executes ressurrect.g.
Until now, is anything that seems out of place?

droftarts

@Leonard03 We are homing in on a bug, related to applying the skew compensation when axes are homed at the same time. In 3.5.4, this worked correctly, but now doesn't seem to.

The difference is in how the skew compensation is applied. "resurrect-prologue.g" needs to run just X and Y homing, it runs home X, then home Y. Skew compensation is applied to X once Y is homed. In homeall.g, X and Y are homed at the same time, but doesn't seem to apply skew compensation until after the first move, which is when the axes move to resume the print, so will be in the wrong place.

A workaround for now is to modify your homeall.g so it homes X, then Y, rather than both at the same time. Either replace the X and Y homing lines with the lines from homex.g and homey.g, or as @fcwilt mentioned earlier in this thread, replace them by calling the homex.g and homey.g macros, eg

M98 P"homex.g"
M98 P"homey.g"

Then it should resurrect in the same place. @dc42 is working on a fix.

Ian

Leonard03

@droftarts Interesting point of view. All right, I'm trying this now and report back