V3.4 SBC - G32 not working correctly ??

Dr_Ju_Ju

Thanks Jay, but from my config.g. file in order:

; Axis Limits

; Z Motor Layout
; ----------- X-Y (A-B) Homing Position
; Z1 | Z2
; -----+-----
; Z0 | Z3
; 0,0 -----------
; Front

M584 X0.0 ; set drive mapping X
M584 Y0.1 ; set drive mapping Y
M584 Z0.2:0.3:0.4:0.5 ; set drive mapping Z
M584 E1.0 ; set drive mapping E (extruder on 3HC)

M557 X5:295 Y5:295 P3 ; define G29 mesh probe grid

M671 X-80:-80:380:380 Y-70:390:390:-70 S5 ; leadscrews at Front left, Rear left, Rear right and Front right, S - Maximum error allowed before system rejects, Note Motor Connections MUST Match

So I think I have it the right order, the M671 mappings are outside of the bed area as they are the actual motor positions

jay_s_uk

@dr_ju_ju I would also check that you've got the motors plugged in in the right order. The motor connections on the 6HC are in a funny order (see here https://forum.duet3d.com/topic/28388/only-one-driver-working/10?_=1652863946598)

Dr_Ju_Ju

Jay,

I flipped the printer over & re-checked the connections, and all is as it should be....

The main reason I wanted to go back to v3.3.is that everything worked as expected, i.e. multiple G32 iterations, made things better not worse, The only physical changes have been to change the extruder to a Revo & setting the Precision Piezo to be under bed as opposed to extruder mounted, but both changes were successful.

Phaedrux

M566 X900.00 Y900.00 Z900.00:900.00:900.00:900.00 E120.00
The Z jerk value should only be set a single time.

Can you send M98 P"config.g" and report any errors?

To roll back to 3.3 using an SBC you'd need to follow these steps.

https://docs.duet3d.com/en/User_manual/Machine_configuration/DSF_RPi#downgrade-packages

Is that what you tried?

; Z Axis
;G91                    ; relative positioning
;G1 H1 Z25 F1000        ; lift Z relative to current position
G90                     ; absolute positioning
G1 X150 Y150 F6000      ; Go to the bed centre & probe point and home the Z axis
G1 H1 Z-99999 F1000       ; move Z down until the endstop is triggered
G1 H0 Z25 F1000         ; lift Z 25mm
G1 H1 Z-100 F400
; G30                     ; Calibrate Z-axis
; G92 Z0                  ; set Z position to axis minimum (you may want to adjust this)
G1 H0 Z25 F6000         ; lift nozzle

What Z endstop are you using here? Your config.g doesn't seem to show one configured.

; Z-Probe
M558 P1 C"!^io6.in" H10 F500 R1 A3 S0.03 T5000                         ; set Z probe type to unmodulated and the dive height, speeds, pause inter point travel speed
G31 P500 X0 Y0 Z0                                                      ; set Z probe trigger value, offset and trigger height

; Endstops
M574 X2 S1 P"^io1.in"                                                  ; configure switch-type (e.g. microswitch) endstop for high end on X via pin ^io1.in
M574 Y2 S1 P"^io2.in"                                                  ; configure switch-type (e.g. microswitch) endstop for high end on Y via pin ^io2.in
M574 Z1 S2                                                             ; Configure Z to use Probe

How are you setting the Z0 point? 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?

Can you post your homing files?

Dr_Ju_Ju

@phaedrux Thanks for your suggestions, to answer:

I've set M566 command to a single value, not multiple for each motor, my bad.

M98 just runs with no errors/output etc.

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...

My homing files are attached, X & Y are ok but Z is still a "work in progress" till I can get repeatable
HomeFiles.zip.txt

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 ?? Note: once again the G31 command will be "fine tuned" when things are stable.

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

Have you tested the probe trigger height at the different points on the bed? Is it basically the same
Yes, I'm using under bed piezo sensor and I get the same results no matter where I probe..

And after making the changes to config.g (above), and re-running the "start up" macro, I still get the same results with worsening height maps on each iteration HeightMaps-new.zip.txt

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.