Posts made by tcamguil

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