Posts made by tcamguil

@effnish

Have you tried downgrading the Toolboard1LC firmware to the version 3.6.0-rc.1 (2025-02-28 15:03:36).
I was having a similar issue, except the Klicky did not trigger, and found that it solved my issue.

[3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh

@darylprice said in G29 Not working correctly:

M558 K0 P9 C"io4,in" H0 F120 T6000

Your dive height is null (the H parameter in bold above). You may want to try the command below where the probe will attempt to probe from Z7.5 (10mm from the M558 command minus the 2,5mm from the probe offset)

M558 K0 P9 C"io4.in" H10 F120 T6000

@dc42, it is working now. Thank you for the quick update.

I guess it could be a bad connection.But why does it happens at random points on the buildplate. And why can't I reproduce the issue on RRF 3.6.0-RC.1 or before. Could it be an issue with the debouncer ?

I switched to a NO sensor and the issue is now flipped the error is now "Error: G29: Probe already triggered before probing move started". and the Z-probe status is stuck in the triggered state until I trigger/un trigger it manually.

@dc42
The good news is the points seems to be taken in the "right" order now.
But the toolhead connected to the U motor needs to be active while the mesh is running for the U axis to move.
Which was not needed for RRF3.6.0-rc1 and before.
The points are being recorded in the right order in the heightmap file.

But the Klicky triggering was not detected again about midway through the second mesh calibration breaking it.

@droftarts
After hours of trying to debug this issue here are the three files left on my printer

config.g
homeall.g
mesh.g

@droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

I'd guess it's looking for a response from the wrong probe. Are you using G29 with a K parameter? Also check that any deployprobe#.g, retractprobe#.g and tool change macros (tpre#.g, tpost#.g and tfree#.g) are all numbered appropriately for the correct tool and probe. If you leave off the number (the #), that macro will be running for ALL probes/tools.

G29 is using K1. I don't use / don't like using the deployprobe/retractprobe pair as it has a tendency to pickup/drop the probe too frequently when running a full machine calibration. tfree-tpre-tpost macros are all correctly numbered

@droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

For the heightmaps, @dc42 is looking into this. However, to me it looks like the order of the axes are incorrect when doing a mesh bed on the tool with U mapped to X, because it is listing the Y axis before U, when it should be U first. Can you post your full config.g, so I can see how you've set up your tools?

For the heightmap I suppose the machine is configuring the mesh in the order of the axes in the firmware (ie: XYZUVWABC...) so it will select Y then U when calibrating, I may be wrong here but it seems logical to me maybe the firmware is selecting Y as both the first axis and the default Y axis (I could not quite understand how the mesh is working under the hood).

@droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

I also think the mesh is being applied correctly (though not in the correct order), ie a mesh that has been made on the XY axes affects the XY axes but not U, and a mesh made on the UY axes affects the X when U is mapped to it, and UY axes. You generally wouldn't command a U axis move during a job, so this seems sensible.

That is also my point of view I think the Heightmap is correctly applied, Both toolheads were applying the compensation while the XY heightmap was active.
The fact that the Heightmap is rotated when displayed on the DWC is an old issue as is the points being meshed and saved in the "wrong" order. It was for me just a quirk of the Firmware (the spacing has to be declared backwards Y then U).

@droftarts, I have quickly tested a few things with the following handmade heightmap.

heightmap_X.csv

RepRapFirmware height map file v2 generated at 2025-04-08 11:22, min error -0.041, max error 0.001, mean -0.020, deviation 0.020
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,0.00,250.00,0.00,300.00,-1.00,249.97,299.97,2,2
 -4.000,  4.000
 -4.000,  4.000

heightmap_U.csv (the points are rotated to match the probing order)

RepRapFirmware height map file v2 generated at 2025-04-08 11:22, min error -0.041, max error 0.001, mean -0.020, deviation 0.020
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
Y,U,0.00,250.00,0.00,300.00,-1.00,249.97,299.97,2,2
  4.000,  4.000
 -4.000, -4.000  

here are my results

With heightmap_X active,

• If no tool is active the heightmap is applied on G1 moves using the G1 Xaaa command but not the G1 Uaaa command.
• If T0 (connected to X motor) is active the heightmap is applied on G1 moves using the G1 Xaaa command but not the G1 Uaaa command.
• If T1 (connected to U motor) is active the heightmap is applied on moves using the G1 Xaaa command but not the G1 Uaaa command.

With heightmap_U active,

• If no tool is active the heightmap is applied on G1 moves using the G1 Uaaa command but not the G1 Xaaa command.
• If T0 (connected to X motor) is active the heightmap is applied on G1 moves using the G1 Uaaa command but not the G1 Xaaa command.
• If T1 (connected to U motor) is active the heightmap is applied on both moves using the G1 Uaaa command and the G1 Xaaa command.

I hope this can help you diagnose the issue.

On the other hand do you have an idea about what could be causing the toolboard to fail to detect the status change of the klicky thus attempting to push it through the bed?

@tcamguil said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

The first one is that during the G29 calibration the machine will sometimes fail to detect the "status change" of the Z-probe and will go all the way down breaking the Z-probe before generating a "Error: G29: Probe was not triggered during probing move" message.
I have tried increasing the Z lift to 0.5mm in between two probes without success. H2:0.25 => H2:0.5
I also tried to increase the recovery time to 0.5s thinking the Z-probe "status" was not updated in time. R0.0 => R0.5

@droftarts said in [3.6.0-rc.2] Z-probe hits bed and U not moving running Mesh:

Do you have one Klicky probe, or two? You seem to be defining two, on different IO inputs. Or is it the same Klicky, but it depends which tool head picks it up?

You have K1 set as the probe number for both probes, [...]

I have one Klicky probe that can be loaded by both heads.
I was playing with the macros before posting here and forgot to change back the first probe to K0 but yes both probes are declared. So as far as the Duet is concerned it has two probes, K0 is on T0 (CAN '10' board on the X motor) and K1 is on T1 (CAN '11' board on the U motor).

As far as I'm aware, the mesh should be applied to both tools. Please post your full config.g, maybe it's a config issue.

After experimenting with the mesh and both toolheads I realized that the mesh is being applied to both tools as expected. The mesh XY simply does not affect raw U moves which is the expected result. So I think this solves my second issue and may render my third issue moot.

There is an issue running mesh probing on the U axis, it has been reported before, and your third issue sounds similar to this: https://forum.duet3d.com/topic/37165/issue-with-szp-on-secondary-idex-toolhead

I also noticed that the mesh is probed along Y first then U (in every version of RRF 3.6) only in RRF 3.6.0-rc2 does the U axis not move at the end of each row.

For example, if I run the 3 commands below U moves to the center of the buildplate (U150, Y125), to the front (U150, Y0), then to the back (U150, Y250) where it probes twice (performing one probing move from Z5 and 2-3 probes from Z0.5 each time) and finally to the front again (U150, Y0) instead of probing each corner once.

M557 U0:300 Y0:250 P2  ; define mesh grid
G1 U150 Y125 F15000    ; Move to the center
G29 S0 K1              ; Proceed mesh compensation

But the resulting heightmap is "correct" here is the heightmap.csv file generated

RepRapFirmware height map file v2 generated at 2025-04-08 11:22, min error -0.041, max error 0.001, mean -0.020, deviation 0.020
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
Y,U,0.00,250.00,0.00,300.00,-1.00,249.97,299.97,2,2
 -0.038,  0.001
 -0.041, -0.000

Downgrading the Toolboard1LC firmware to the version 3.6.0-rc.1 (2025-02-28 15:03:36) seems to have solved the first issue.
Even increasing the probing speed does not seems to be able to reproduce the issue with the old firmware.

Hello,

I am running an IDEX 3D-printer with a klicky as the Z-probe and two toolheads one on the XY axis and the other one on the UY axis.

I have three issues :

• The first one is that during the G29 calibration the machine will sometimes fail to detect the "status change" of the Z-probe and will go all the way down breaking the Z-probe before generating a "Error: G29: Probe was not triggered during probing move" message.
  I have tried increasing the Z lift to 0.5mm in between two probes without success. H2:0.25 => H2:0.5
  I also tried to increase the recovery time to 0.5s thinking the Z-probe "status" was not updated in time. R0.0 => R0.5

• The second one is that the XY mesh calibration is only applied to the Left toolhead (the one connected to the X motor).
  Is there a way to apply it to the U axis without having to run the mesh calibration twice?

• The third issue is that while the mesh calibration is almost running as expected when the G29 is running on the left toolhead. When I try to run the mesh calibration with the right one (the one using the U axis) the mesh is advancing along the Y axis as expected but it does not advances along the U axis, the toolhead stays at the last position the U axis was moved to before starting the G29 command and is simply going back and forth.
  I have tested every release between 3.5.4 and 3.6.0-rc2 and it seems this is a new issue to 3.6.0-rc2:

  • 3.5.4 is moving the toolhead diagonally (U and Y are moving)
  • 3.6.0-beta.3 - 3.6.0-rc1 is running fine
  • 3.6.0-rc2 is not moving along U

extract from the config.g file

[...]
;Kliky L
M558 P8 C"10.io0,in" H2:0.25 F1200:120 T18000 K1 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 X42.00 Y0.00 Z-25.000 K1 ; 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

;Kliky R
M558 P8 C"11.io0,in" H2:0.25 F1200:120 T18000 K1 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 U-42.00 Y0.00 Z-25.000 K1 ; set Z probe trigger value, offset and trigger height
M556 S50 X0 Y0 Z0 U0 ; set orthogonal axis compensation parameters
;M557 U0:300 Y0:250 S50 ; define mesh grid
[...]

; run mesh.g

; Mesh compensation
T-1
M290 R0 X0 Y0 Z0 U0    ; clear babystepping
G28    ; Home all towers

;pickup the klicky
M98 P"0:/sys/pickupprobe.g"
M558 F120 K1    ; Reduce probing speed to prevent scares
M556 S50 X0 Y0 Z0 U0    ; set orthogonal axis compensation parameters
M557 U0:300 Y0:250 S25:30    ; define mesh grid

G1 Z5 F1200    ; Approach tool - BL Touch
G1 U-42 Y0 F15000
G29 S0 K1    ; Proceed mesh compensation by probing, saving heightmap.csv correction map file and displaying the matrix
if result != 0     ; If the Mesh failed
    abort    ;  cancel the calibration process
G29 S1    ; Activate meshgrid compensation
G29 S3 P"0:/sys/heightmap_U.csv"    ; Save meshgrid U
M376 H{max(5,(move.compensation.liveGrid.deviations.max-move.compensation.liveGrid.deviations.min)*20)} ; Set the mesh bed compensation taper to 10% of a layer height.

;drop
M98 P"0:/sys/dropprobe.g"
G28                                               ; Home all towers

Board Name:

Duet3-6HC
Toolboard1LC
Firmware Version:

MB6HC: 3.6.0-rc.2 ( 2025-03-31 12:17:13)
Toolboard1LC: 3.6.0-rc.2 (2025-03-31 12:22:41)
DWC Version: 3.6.0-rc.1
Raspberry Pi: No

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