I upgraded to 3.5.2 and it seems the issue is gone.

Thanks for the help

It is working now
thank you

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.

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.

I upgraded to 3.5.2 and it seems the issue is gone.

Thanks for the help

Some time ago I noticed that while printing the printer would sometimes stop all moves while the status said it was still printing. I ran the M122 command with the printer stuck and the diagnostic said that the number of segments left was way too high to be correct. (I think I saw a post on this forum of someone having a similar issue)
The first solution I found was to pause the print and resume it.

My current solution was to set segmentsLeft to be signed and check that it was greater than zero instead of different than zero in the LockMovementAndWaitForStandstill function.
With this fix in place the Duet now moves randomly to the edge of the build volume, generates a "G1/G2/G3: intermediate position outside machine limits" message before coming back to the print in progress instead of stopping all moves.

I have the following questions:

• Do you have a cleaner fix to this issue available for the RepRapFirmware 3.4.6 or an idea of where in the code the variable would become negative and why.
• Do you know if this issue has been fixed in the RepRapFirmware 3.5.2 release ?

Thanks

I was indeed initializing the LED class before the initialisation of the shared SPI device

Thank you for your answer

Hello,
I am trying to add support for a custom SPI controlled LED on a Duet2 Ethernet
and a Duet3 MB6HC. But whenever i try to configure the LED output the Firmware reboots with an assertionFailed error.

I have copied the configuration steps of the SPI bus from the PT100 temperature sensor as good a I can but it seems that the device is not declared correctly
LynxMod.h
LynxterLED.cpp

I tried to comment out certain lines to see which ones causes the error to occur so far it seems that it's the mutex that seems to fail to lock. Am I missing an important step or just way out from my approach.

Also could you give me some pointers on how to debug such issues from now on?

Thanks in advance for the help

Yes my printer is an IDEX,
the reason the BL-touch is K0 is because K1 is a 3-axis tool offset probe mounted in the back of the machine

; Z-Probe
M558 P8 C"!io7.in" H10 F120 T1200 A15 S0.005 K1
G31 P500 X-73 Y-298.8 Z23.336 U0 K1

If I set an X offset on the probe won't the X axis also move when i perform a calibration?

Here is the way U is used in my printer, the BL-touch is mounted beside T1

; Tools
M563 P0 S"E0+E1" D0:1            ; define tool 0
G10 P0 X0.0 Y0.0 Z21.5 U0.000    ; set tool 0 axis offsets
G10 P0 R0 S0                     ; set initial tool 0 active and standby temperatures to 0C
M567 P0 E0.5:0.5                 ; set tool 0 mix ratio

M563 P1 S"E2" D2 X3              ; define tool 1
G10 P1 X0 Y-0.40 Z24.95 U1.50    ; set tool 1 axis offsets
G10 P1 R0 S0                     ; set initial tool 1 active and standby temperatures to 0C

Hello,
I am trying to perform a manual bed leveling with a BL-Touch on my cartesian 3D printer but for space reasons I need the probe to be on the U axis.
I followed the instruction here and while everything works on the Y axis the tool refuses to move on the U axis when executing the G30 commands could anyone give me pointers on how to fix this.
If not is there a better solution than the one in bed.g?

config.g (edited to share the least information possible)
bed.g

Hardware :

• Duet3 6HC in standalone mode
• Tool distribution board
• Toolboard 1LC

Software:

• Firmware: RepRapFirmware for Duet 3 MB6HC 3.4.5 (2022-11-30)
• Duet Web Control 3.4.5