[3.6.0-rc.1] Z-probe starts untriggered even when the probe is.

tcamguil

Hello,

I am running a 3D-printer with a klicky as the Z-probe.
Meaning the Z-probe is not on the toolhead most of the time

When I boot up the printer the Z-probe value is at 0 even if the Z-probe is not on the toolhead (ie: open-circuit, ie: should be triggered).
But as soon as I load and unload the probe once the Z-probe value is now correctly set to 1000.
I tried to set the Z-probe as a scanning probe and it correctly displays a value of 65000 as soon as the printer boots.

I haven't updated the config.g file after upgrading from 3.5.4 and it was working fine

extract from the config.g file

[...]
;Kliky
M558 P8 C"11,io0,in" H2:0.25 F1200:120 T18000 K0 R0.0 A15 S0.005 ; set Z probe type to bltouch and the dive height + speeds
(the forum thinks this is an URL hence the commas)
G31 P500 X-42.00 Y0.00 Z-25.000 K0 ; set Z probe trigger value, offset and trigger height
M556 S50 X0 Y0 Z0 U0 ; set orthogonal axis compensation parameters
M557 X0:300 Y0:250 S50 ; define mesh grid
[...]

Board Name:

Duet3-6HC
Toolboard1LC

Firmware Version:

MB6HC: 3.6.0-rc.1 (2025-02-28 15:00:13)
Toolboard1LC: 3.6.0-rc.1 (2025-02-28 15:03:36)

DWC Version: 3.6.0-beta.2
Raspberry Pi: No

I have looked for threads already mentioning this issue and not found any.

jay_s_uk

@tcamguil this has already been fixed in the source a couple of days ago.
See here https://github.com/Duet3D/RepRapFirmware/commit/85d692da97158febf620a891fa7dca4814e62db3
Not sure if there has been a subsequent test release made available that includes this fix

FYI, you should update your DWC version to be the same as the firmware version

0

dc42 committed to Duet3D/RepRapFirmware

Fixed initial value of digital remote Z probes when they are created

Thanks to Andy Shaw for this one

tcamguil

Thanks for the fast response.
No, it has not yet been made available for the public as I re-downloaded the files this morning before posting.

I will then wait patiently for the next update.

gloomyandy

@tcamguil There is a test build in this thread that may have the fix in it... https://forum.duet3d.com/topic/37610/3-6-0-beta1-rc1-laser-not-working/4

tcamguil

It is working now
thank you

dwuk3d

I've had a few issues with probes showing up as triggered when they aren't and I'm fairly sure that this happens in 3.5.4 too on a 1LC tool board (with 6HC main board).

I've found you need to move through the trigger point up to 2 times to get the problem to clear.

Glad it is being fixed in a later release.

My workaround is to add this to Bed.g before every probe

   M400
    if sensors.probes[0].value[0] > 0
        M98 P"0:/macros/probefix.g"

;probefix.g
if exists(global.mms) == true
    M596 P0
G1 Z0.5
M400
G1 Z5
M400
G1 Z0.3
M400
G1 Z7
M400
echo "probe after error handler:",sensors.probes[0].value[0]

dc42

@dwuk3d this particular bug was new in 3.6.0-rc.1.