[Bug]: G30 S-2 does not as advertised in the Docs

[blaggacao]

Duet Forum Discussion Thread

Thanks, but no thanks: I've dug through the source code and feel confident enough not to waste your time

Firmware Version

3.6.0

Duet Web Control Version

3.6.0

Are you using a Single Board Computer (RaspberryPi) with your Duet?

• Yes I use a SBC.
• No I do not use a SBC.

Please upload the results of sending M122 in the gcode console.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0 (2025-05-25 08:04:38) running on Duet WiFi 1.02 or later
Board ID: 0JD6M-99APT-NU4SN-6JKD4-3SD6J-14P1L
Used output buffers: 1 of 26 (18 max)
=== RTOS ===
Static ram: 24016
Dynamic ram: 67804 of which 360 recycled
Never used RAM 27600, free system stack 122 words
Tasks: NETWORK(1,ready,14.8%,239) HEAT(3,nWait 5,0.0%,378) Move(4,nWait 5,0.0%,264) MAIN(1,running,85.2%,801) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 01:34:36 ago, cause: power up
Last software reset at 2025-08-15 21:25, reason: User, Gcodes spinning, available RAM 27744, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 41.2, current 41.6, max 43.0
Supply voltage: min 23.3, current 24.0, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/9, heap memory allocated/used/recyclable 2048/232/64, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2025-08-16 01:15:49
Slowest loop: 29.02ms; fastest: 0.18ms
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 6.6ms, write time 7.8ms, max retries 0
=== Move ===
Segments created 9, maxWait 228535ms, 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: 40000.00/40000/0.00 40000.00/40000/0.00 45108.00/45107/0.45 40000.00/40000/0.00
No step interrupt scheduled
Driver 0: standstill, SG min 88
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 31, completed 31, LaErrors 0, Underruns [0, 0, 0]
Segments left 0
Code queue is empty
=== Heat ===
Bed heaters -1 -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
=== Network ===
Slowest loop: 35.52ms; 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.33, flash size 2097152, free heap 39376
MAC address 48:55:19:09:49:23
IP address 192.168.88.229
Signal strength -43dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Please upload the content of your config.g file.

; Configuration file for Duet
; executed by the firmware on start-up
; WorkBee Firmware Version 1.1

global systemSettingsVersion={1.2}

; Configuration files
M98 P"config-network.g"
M98 P"config-drives.g"
M98 P"config-axes.g"
M98 P"config-axes-limits.g"
M98 P"config-axes-calibration.g"
M98 P"config-axes-endstops.g"
M98 P"config-probe.g"
M98 P"config-spindle.g"
M98 P"config-laser.g"
M98 P"config-pendant.g"

; Other Settings
M453 ; Put the machine into CNC Modes
G90 ; Set absolute coordinates
M140 H-1 ; Disable heated bed
M564 S1 H1 ; Disable jog commands when not homed
M911 S21.0 R23 P"G91 G1 Z3 F1000" ; Configure power loss resume

; User Configuration files
M98 P"config-user-settings.g"

M501 ; Load Stored Parameters

G31 K1 P500 X0.0 Y0.0 U0.0 Z20.51

Please upload the content of any other releveant macro files.

; This is kind of a reproducer

G53 G0 Z{move.axes[2].max}

; Move to tool park position
G53 G0 X{global.toolChangePositionX} Y{global.toolChangePositionY}

G30 S-2  ; Probe to K0 and store tool offset
M500 P10 ; Persist trigger height [THIS DOES NOT WORK see object model state]
G91
G1 Z10 F500 ; Retract
G90

Details specific to your printer.

No response

Links to additional info.

No response

What happened?

RepRapFirmware/src/GCodes/GCodes4.cpp

Lines 1555 to 1565 in d7937bd

	else if (g30SValue == -2)
	{
	// Adjust the Z offset of the current tool to account for the height error
	if (ms.currentTool == nullptr)
	{
	gb.LatestMachineState().SetError("Tool was deselected during G30 S-2 command");
	}
	else
	{
	ms.currentTool->SetOffset(Z_AXIS, -g30zHeightError, true);
	ToolOffsetInverseTransform(ms); // update user coordinates to reflect the new tool offset

Contrary, the docs state (https://docs.duet3d.com/User_manual/Reference/Gcodes#g30-single-z-probe):

G30 S-2 probes and adjusts the tool Z offset to make the actual stop height match the configured value. A tool must be selected first when using G30 S-2.

This supports that #487 was actually closed in error.

Since I don't understand in detail the innerworkings of g30zHeightError I'm not really confident to propose as suggested earlier in that same file in this code comment:

RepRapFirmware/src/GCodes/GCodes4.cpp

Lines 1430 to 1433 in d7937bd

	if (g30SValue == -1 || g30SValue == -2 || g30SValue == -3)
	{
	// G30 S-1 command taps once and reports the height, S-2 sets the tool offset to the negative of the current height, S-3 sets the Z probe trigger height
	gb.SetState(GCodeState::probingAtPoint7); // special state for reporting the stopped height at the end

It could still be that the intent of g30zHeightError at L1555-L1565 is to actually be the "negative of the current height" (+- some error compensation). In that case g30zHeightError is wrongly construed.

---

The problem I observe is that after running G30 K1 S-2 from seemingly all possible angles, I never get a tools[n].offset[2] different from something like 2.874e-16 mm, i.e. nothing.

That is not what I expect from a Tool Offset with reference to the HRP, which is the Collet rim of my tool holder of my CNC spindle.

Note, I have a simple ERC11 collet system, so each toolchange (even back to a previously used tool) inevitably produces an offset that needs to be corrected for.

[dc42]

My tests indicate that G30 S-2 works as expected. This is what I ran, with a ~30mm high block placed on the bed in the way of the probe:

20/08/2025, 16:30:13 	t0
20/08/2025, 16:30:30 	g10 p0
Tool 0: offsets X0.000 Y0.000 Z0.000, active/standby temperature(s) 0.0/0.0
20/08/2025, 16:30:38 	g30 s-2
20/08/2025, 16:30:48 	g10 p0
Tool 0: offsets X0.000 Y0.000 Z-30.573, active/standby temperature(s) 0.0/0.0

Please try a similar test and report your results.

[blaggacao]

@dc42 if this works, it clearly doesn't trigger the error condition and an obscure side condition, which ultimately might potentially be actual obscure user error, is required.

I remember that it sometimes worked (say after resetting everything, on the first tool probing), but then stopped reliably down the workflow of a job involving tool changes.

Maybe run this:

• twice (that should be legal, including after calls to M500 and reloading from them)
• full example (touch probe offset ~30mm of the block you used against the HRP, then tool offset against the HRP trigger point, e.g. to represent the stickout) - potentially multiple times in a row or changing for different tools before and after a M500 + reload?

There seems to be a case where it internally only loads an error (not a trigger height! - see code) into the object model. This is the described error condition.

Maybe you could help me understand the anlyzed g30zHeightError ? Then I might be able to more precisely pin down the exact error condition in an independently reproducable manner. At this point, I'm just highly confident that there's an issue from my (granted: non-controlled) incidential tests and analysis.

[blaggacao]

Addendum: I hypothezise that on a first-ish (the exact condition is tbd) said g30zHeightError happens to be the absolute value of the trigger point, whereas after some initialization (the exact condition tbd), it does not so any more. The latter is the described error condition of this issue.

[T3P3]

@blaggacao we need a set of steps to reproduce this similar to what @dc42 did above (but that actually shows the issue):

My tests indicate that G30 S-2 works as expected. This is what I ran, with a ~30mm high block placed on the bed in the way of the probe:

20/08/2025, 16:30:13 	t0
20/08/2025, 16:30:30 	g10 p0
Tool 0: offsets X0.000 Y0.000 Z0.000, active/standby temperature(s) 0.0/0.0
20/08/2025, 16:30:38 	g30 s-2
20/08/2025, 16:30:48 	g10 p0
Tool 0: offsets X0.000 Y0.000 Z-30.573, active/standby temperature(s) 0.0/0.0

Please try a similar test and report your results.