V3.4 SBC - G32 not working correctly ??

Dr_Ju_Ju

Morning Peeps,

Printer: Voron 2.4, CoreXY M122 output below

Following on from my query regarding a method for rolling back the installed version to 3.3, which I found to be non workable, as the software would not recognise/communicate with the Duet post rollback ?? (a side issue)

Therefore I decided to try and persevere with 3.4, but no matter what I do, I cannot get a reliable and repeatable automatic bed levelling system working !!

I know its probably something I've done / not-done, but I can't see it, so I come asking for pointers....

To highlight the issue, I printed up 4 identical pillars, which I physically placed adjacent to each of the motors, to provide a reasonably accurate starting position, and then ran a macro which homes the printer then loops through 5 iterations of G32 / G29 to 'level' and create individual height maps, but as can be seen, running through each iteration makes the problem worse and not better !!

18/05/2022, 09:08:36 M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0 (2022-03-15 18:57:24) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J1D2-3S86Q-9V9QT
Used output buffers: 1 of 40 (21 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 66216 of which 192 recycled
Never used RAM 133192, free system stack 124 words
Tasks: SBC(ready,6.9%,466) HEAT(notifyWait,0.1%,321) Move(notifyWait,0.0%,254) CanReceiv(notifyWait,0.3%,772) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.1%,339) TMC(notifyWait,99.2%,58) MAIN(running,111.5%,923) IDLE(ready,0.1%,30), total 218.2%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 17:15:10 ago, cause: power up
Last software reset at 2022-05-17 15:22, reason: AssertionFailed, GCodes spinning, available RAM 133264, slot 2
Software reset code 0x4923 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x2041b53c Task MAIN Freestk 1685 ok
Stack: 0000019a 004a3b08 00484267 00000000 004847ff 2042b928 00000000 20429870 2042ba98 37cb458f 2042ba9c 20419a8c 00000000 37cb458f a5a5a5a5 a5a5a5a5 0048491b 00000001 2041b59c 20429f48 0048229d 2042ba98 0045c82b 20419a8c 2042ba9c 20418101 2041b5ac
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 136
MCU temperature: min 26.0, current 48.2, max 48.5
Supply voltage: min 23.8, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 104, reads 49231, writes 19 timeouts 0
Driver 1: standstill, SG min 0, mspos 88, reads 49231, writes 19 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 49231, writes 19 timeouts 0
Driver 3: standstill, SG min 0, mspos 1000, reads 49231, writes 19 timeouts 0
Driver 4: standstill, SG min 0, mspos 264, reads 49231, writes 19 timeouts 0
Driver 5: standstill, SG min 0, mspos 120, reads 49231, writes 19 timeouts 0
Date/time: 2022-05-18 09:08:35
Slowest loop: 63.65ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 3, maxWait 60557188ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 385, completed 385, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 559051, received 1242075, lost 0, boc 0
Longest wait 1ms for reply type 6018, peak Tx sync delay 388, free buffers 50 (min 49), ts 310554/310553/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 6492/6492
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 34.51, max time between full transfers: 178.7ms, max pin wait times: 62.1ms/13.5ms
Codes per second: 0.02
Maximum length of RX/TX data transfers: 3156/752

M122.txt Console.txt Bed_Leveling_Loop.txt config.g.txt Height-Maps.zip.txt

jay_s_uk

@dr_ju_ju you probably don't have the M584 mapping and M671 in the same order.
Lets say you've mapped the Z motors clockwise starting front left, using drivers 0.2 to 0.5 respectively, M584 would look like M584 Z0.2:0.3:0.4:0.5
The M671 should be in the same order. So M671 X0:0:300:300 Y0:300:0:300
If you don't map them in the same order then G32 won't work

Dr_Ju_Ju

@jay_s_uk

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.