V3.4 SBC - G32 not working correctly ??

Phaedrux

@dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

Yes, I tried that method, and I also created another SD card (using Raspberry Pi Imager) with 3.3 from the original stable version, I downloaded last year. In both instances, the hardware was not recognised, so DWC service would not start...

In this case you may need to manually flash the board to 3.3 to get it in line with the Pi version. Either USB and Bossa, or place the required bin files on the SD card and send M997 to flash. This can be complicated by the change to a /firmware folder in 3.3 so you may need to place the files in both /firmware and /sys. Using Bossa and USB is a bit more straightforward. Can also be done from the Pi via command line bossac.

@dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

I believe I've defined the Z endstop to be the Precision Piezo Probe (M558 command) and then selecting it using the M574 Z1 S2 command ??

This is a very bizarre way to use a probe. M574 Z1 S2 is actually not necessary to use a probe for Z at all. S2 actually intended for axis other than Z where you may want to use a probe.

So yes you have a probe defined with M558 but your macro is using an endstop homing command for Z instead of G30 which you have commented out. When doing this I think you're skipping the entire G31 probe configuration, which is what's causing you problems.

G1 H1 Z-100 F400
; G30                     ; Calibrate Z-axis

So when you want to use the probe to home Z, you must use G30.

Dr_Ju_Ju

@phaedrux

Yea, that's what I was thinking about re-flashing the firmware, but I didn't want to go down that route until I've exhausted everything else in trying to get the current 3.4 setup working.

Now I'm getting totally confused as per (https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_endstops) Firmware configuration paragraph, that is exactly how it should be configured (M574 Z1 S2)

I've re-enabled the G30 setting, but unless I've enabled the M574 setting I only get "Error: Failed to enable endstops" when trying to home the Z axis.

And still, after setting the above, the system still does not give a reliable/repeatable solution, and worsens through iterations.

Phaedrux

@dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

Firmware configuration paragraph, that is exactly how it should be configured (M574 Z1 S2)

Sure, but to actually use the probe as a probe, you must use G30. You can remove the M574 Z1 S2 line entirely and still use G30 to home Z.

@dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

I've re-enabled the G30 setting, but unless I've enabled the M574 setting I only get "Error: Failed to enable endstops" when trying to home the Z axis.

This is likely because you still have the G1 H1 Z move to home the Z axis with an endstop seeking move. Comment that out. G1 H1 Z-100 F400

@dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

And still, after setting the above, the system still does not give a reliable/repeatable solution, and worsens through iterations.

I ask again: "Have you tested the probe trigger height at the different points on the bed? Is it basically the same, or does it vary with position?"

Dr_Ju_Ju

@phaedrux Thanks for all your help...

After removing the M574, and additional Z move settings, the system now uses the probe as the end-stop correctly.

Yes, I have checked that the probe trigger heights are the same at various points on the bed..

But after all that, the system still does not give consistent results, and worsens through multiple iterations:

Console.txt

HeightMaps.zip.txt

Phaedrux

worsens through multiple iterations

That almost always indicates the order of z drivers doesn't match the order of the defined positions.

Dr_Ju_Ju

@phaedrux

Maybe getting somewhere....

To ensure that the Z motor mapping were/are correct, I plugged in each motor it turn, leaving the others unplugged, and ensured that only the appropriate motor moved.

I then re looked at the mappings in the config files etc. and all appeared to be ok. Re-ran the levelling loop with no change.

On a whim, I decided to change the defined positions of the Z motors using M671, from their true positions to the bed co-ordinates i.e.:

M671 X-80:-80:380:380 Y-70:390:390:-70 S10
to
M671 X0:0:300:300 Y0:300:300:0 S10

Re-running the bed levelling loop, after the update, produced a significant improvement in repeatability etc. console.txt

This then me thinks that either I didn't have the settings correct in the first place ?? or that the system doesn't like negative numbers ??

gloomyandy

@dr_ju_ju The coordinates you use in M671 should be the location of the pivot points of the bed support, this may or may not be the same as the location of the motors.

Dr_Ju_Ju

@gloomyandy

my bad for not stating things correctly, within a few mm, i had configured the positions of the belts that raise/lower the Z axis as defined at https://docs.duet3d.com/User_manual/Reference/Gcodes, which are outside of the bed coordinates. for a Voron2.4 printer.

dc42

@dr_ju_ju to check that G32 true bed levelling is working correctly, run G32 several times and see how the reported initial error changes. Ideally the reported initial error would be zero on the second iteration, because the first iteration will have levelled the bed. In practice it's more likely that the errors will have reduced (perhaps by 75%) but not been completely eliminated.

If the reported errors increase, this usually means that you haven't defined the bed support coordinates in the M671 command in the same order as you declared the Z motors in the M584 command.

If the errors diminish on each iteration but by less than 75% then it may mean that there is insufficient give in the coupling between the leadscrews and the bed for the bed to adopt the flat plane defined by the leadscrew positions.

After running G32 one or more times, it's a good idea to do a single G30 probe at bed centre before using G29 to construct a height map.

Dr_Ju_Ju

@dc42 Thank you for the suggestion of running G30 (Z home) before running G29, as it now looks like I may be close to a workable solution...

But that is only if I have M671 set, to the bed coordinates, if it is set to the motor/belt coordinates, then errors keep increasing i.e.

Bed-Coords.zip.txt

Belt-Coords-results.zip.txt

Note that the bed is fixed, and only the XY gantry moves in the Z axis using four motors/belts.