[shuckc]

Z0 sensor probing lifted out of #3 by @btingle so it can be tested and reviewed separately from the jogging / move-to changes. The commit keeps btingle as author.

What it does

• b in the TUI, then Y to confirm, runs the firmware's Z0 sensor cycle for the User (RML-1) coordinate system; Esc requests a stop.
• New rollingmill/probing.py (ZProbe) drives the cycle from a captured VPanel session: sensor pre-checks via 0x2001, then SET 0x3902. The TUI keeps polling; a cancelled, lost or timed-out cycle is reported as unverified rather than success.
• decode.py knows the two new wValues; docs/z-probing.md records the protocol evidence; README documents the key.

What is deliberately not included

Everything else in #3: the pulse/hold jogging rework, keyrelease.py, the move-to rewrite (move_active etc.) and the setuptools<81 pin. The TUI changes here are only the probe hooks (key handling, polling, dialog, cleanup on exit).

Test plan

• pytest -q: new tests/test_probing.py replays the captured status samples and checks the exact USB bytes and TUI interlocks
• Hardware test with a Z0 sensor (not yet run, per the docs)

Credit: @btingle, #3.

🤖 Generated with Claude Code

[shuckc]

Op 0x3900 / 0x3901 hold the Z0 sensor thickness, not the spindle RPM.

To verify I parsed the Setup page's dialog template out of VP_MDX40A.exe (resource 4050, the "Modeling Machine" tab):

• The "Thickness of Z0 Sensor:" label sits at y=147.
• The edit box directly below it is ID 0x0FD9, at y=157.
• The unit label next to it is 0x0FDA. It reads "inch" in the template, and setup_dlg_on_init sets it to "mm" or "inch".
• The data-exchange routine at 0x402c10 isn't defined as a function in Ghidra, so I decoded its bytes by hand.
  • It binds 0xFD9 to this+0xC0.
  • It range-checks the value against this+0xB8 (14000) and this+0xBC (16000).
  • It applies a mm/inch flag from this+0xDC.

What fills and saves it:

• Open the dialog read_nc_mode_tool_radius_settings calls get_uint32_0x3900 and stores it in +0xC0. Pattern B: SET 0x3900, then GET 0x0003, 4 bytes, big-endian uint32
• Click OK write_ncode_settings calls MdxAction_x3901_p1(+0xC0). On the wire: SET 0x3901, big-endian uint32, then wait for ping bit 21 to clear

• Units and range: the value is in 1/1000 mm. Default is 15000, which matches the 15 in your screenshot. The dialog limits it to 14.000 to 16.000 mm.
• No other users: the Setup page loader is the only reader of 0x3900, and the OK path is the only writer of 0x3901.
• Not verified: I didn't decode the exact mm/inch conversion helper. The 1/1000 mm scaling is inferred from the default and the range, so it's worth one live read to confirm.
• Not verified: the firmware's own accepted range. The 14000–16000 limit is enforced by the dialog, not necessarily by the machine.

What this means for rollingmill:

• The labels are wrong. docs/usb-protocol.md, machine.py, tui.py and decode.py all call 0x3900 / 0x3901 the "spindle target RPM". The "range 4500–15000" in our docs came from observing a stored value of 15000. That was the thickness.
• Nothing writes the setting. The TUI never sends 0x3901. spindle_on_rpm only has a wrong docstring, and it sends the speed with SET 0x3006.
• There is a read bug. On connect, get_spindle_rpm() reads 0x3900 and accepts it as the target RPM because 15000 is inside 4500 to 15000. A mill with a 15 mm sensor therefore starts with a 15000 RPM target. The trace decoder also labels SET 0x3901 as SPINDLE_RPM_WRITE.

Proposed changes

1. Rename to get_z0_sensor_thickness_mm(), with no RPM semantics and the connect-time RPM read removed. That changes the initial target RPM to SPINDLE_RPM_MIN.
2. Fix the docs and the decode.py labels.
3. Show the stored thickness in the probe confirm dialog (PR Add Z0 sensor probing (b key), extracted from #3 #8).
4. Add a guarded setter limited to 14.0–16.0 mm, but only after you've tried it on the machine.

[shuckc]

I've verified the first argument to op 3902 is the coordinate system slot number, so it was easy enough to extend this to work for the G54-G59 coordinates, which I verified in hardware.

[Copilot]

🟡 Changes recommended

Failed stop commands are not retried after cancellation, allowing the probe to keep moving despite a stop request, while stale origin and thickness caches can misrepresent machine state.

3 open issues

• Retry failed stop commands until fresh idle is observed · New
• Clear cached thickness when write verification fails · New
• Refresh the target origin after probe cancellation · New

What changed in this PR

Adds firmware-driven Z0 sensor probing to Rollingmill’s TUI, extracted from #3 without the jogging and move-to changes. It also adds sensor-thickness editing and corrects registers previously identified as spindle RPM settings.

Changes:

• Adds a probe dialog with target selection, thickness editing, polling, cancellation and command interlocks.
• Implements the probe cycle and corrects sensor-thickness handling in the machine API and trace decoder.
• Adds captured-status replay tests, failure-path coverage and protocol documentation; hardware validation remains pending.

File	Description
tests/​test_z0_thickness.py	Tests thickness reads, writes, validation and dialog controls.
tests/​test_probing.py	Tests probe packets, cycle handling and TUI interlocks.
tests/​fixtures/​mdx40a_zprobe_status.json	Supplies captured probe status samples for replay.
rollingmill/​tui.py	Adds probe controls, thickness editing and polling integration.
rollingmill/​probing.py	Implements probe initiation, monitoring, cancellation and cleanup.
rollingmill/​machine.py	Adds thickness accessors and corrects spindle-target initialization.
rollingmill/​decode.py	Recognizes probe commands and decodes thickness values.
README.md	Documents the probe keybinding and feature availability.
docs/​z-probing.md	Describes operation, protocol evidence and validation limits.
docs/​usb-protocol.md	Corrects register descriptions and documents sensor commands.
docs/​machine-state.md	Corrects the thickness-command acknowledgement description.

_{Review effort: Balanced}