I don't have a spare Pi @ the mo, but I do have a Rock64 / Rock64Pro spare both running Mate, so will the Duet SBC software run on them ??
I suppose it comes down to what the Voron recommendations were, also I originally tried a Duet2 ethernet (not on this 'Voron' but a previous iteration), in non SBC mode, which was an abject failure, so I was hoping that a Duet3-SBC, would be better....
I don't know if will help, but here's my motor configs & mappings
; Configure Drives
M569 P0.1 S1 ; physical drive 0.0 goes forwards - A
M569 P0.0 S1 ; physical drive 0.1 goes forwards - B
M569 P0.2 S0 ; physical drive 0.0 goes backwards - Z0
M569 P0.3 S1 ; physical drive 0.1 goes forwards - Z1
M569 P0.4 S0 ; physical drive 0.2 goes backwards - Z2
M569 P0.5 S1 ; physical drive 0.3 goes forwards - Z3
M569 P1.0 S0 ; physical drive 1.0 goes backwards - Extruder
; set drive mappings X, Y, Z
M584 X0.0
M584 Y0.1
M584 Z0.2:0.3:0.4:0.5
M584 E1.0 ; set drive mapping E (extruder on 3HC)
@wdenker Why 2 sets of drive mappings (lines 19 & 29) ??
@gloomyandy
no hardware changes, & just the normal software updates pre & post the problems ...
@gloomyandy
yes it used to work fine, and even now it can still produce some great prints !! but it also wastes filament & time when it just stops at some point during a print
no motor cables come anywhere near the SPI connection, or any other cables, apart from the case fans, which come on/off at the start and end, of a print.
All 0v lines are bonded to earth, I don't believe the problem is environmentally connected, as I have multiples printers running concurrently, with no problems
Hi Chris,
Yes everything is fully earth bonded, and I've also replaced the interconnections....
Warning: SPI connection has been reset
Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)
Warning: Lost connection to Duet (SPI connection reset because the number of maximum retries has been exceeded)
M122.txt 
Errors.txt
config.g.txt
I've been having a number of print failures with the above errors, but usually after a successful print (the same object), where the print just stops (all motors off) and the heaters are all switched off, but he SBC still shows the active temperatures....
To recover the machine I have to go through a full power recycle.
I've checked all connections, power supplies etc. and all good, so any ideas on what I can check for, before I try enabling diagnostic mode ??
As I said, I'm using Edge, that is already set for dark theme, there are no configurations settings for these pages ....
So it's not possible to undo this rubbish??
BTW, for me, even this page is virtually unreadable, unless I can't find the settings to be able to set a 'dark' theme...
Sorry yes, I got my left & right swapped 
and in my browser (M$ Edge) the individual windows are fixed & not flexible !!
Is there any way to undo/customise the site pages as they relate to the GCode Dictionary page ?? especially for those of us that wear glasses, and are light sensitive, as the pointless blue section on the right, offers nothing but taking up screen space....
@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.
Note that the bed is fixed, and only the XY gantry moves in the Z axis using four motors/belts.
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.
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 ??
@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:
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 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
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.
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