@signpostman it literally is as simple as adding S2 to the end of your M671 line (replacing the S1 if you have it). You'll have probably put your M671 command in your config.g file, but might be in your bed.g file instead as @tecno suggests
@phaedrux It seems to be working at this moment. I printed the STL that you sent over and seems to be behaving, although I'm still seeing very very slight variations in layer width across the bed, it's good enough for the time being to move forward and work on pinpointing some of these issues in getting my Z=0 datum set correctly.
@Red-Sand-Robot I see you've got a M561 in your bed.g file so all good there. Your probe points and leadscrew positions look sensible if your origin is in the middle of your bed. Doesn't really matter where the bed is in reality, as long as everything is correct to where the Duet thinks the origin is.
Other ideas, prepare for a brain fart...
If you run autotramming (G28) on it's own from console, does it run okay? Does it have issues with needing too much correction (S parameter in M671 which defaults to 1mm)? If you repeat it, do the results converge quickly?
If you then do a paper test at either end of the x-axis, does it show the same high-nozzle-issue at one end? this might show whether it is G28 or G29 related
Just to double check, the motor connected to your left leadscrew (at X -158) is on Driver 4 whilst the right one (at X 152) is on Driver 2? Been there, done that, got the bent leadscrew... 😛
On your heightmap, have you tried running a more detailed one to see what the bed surface actually looks like? Maybe also post a screenshot of a typical heightmap? I've had some weird results when probing a dimple in my bed from a few nozzle crashes.
You may get better results if you just do one detailed heightmap (e.g. 400 points) and keep reloading it with G29 S1? This is what I do on my coreXY (I only rerun if I disassemble parts) but it is pretty rigid...
Would definitely recommend rehoming Z after bed.g, though I think this will mainly cause an offset in the heightmap, not a tilt. I just call 'G28 Z' as the last line in bed.g
Edit: one final thought... Is there any play in your x-carriage bearings/rails? this might cause some error in your probe measurements depending on the travel direction?
I forgot to upload my solution to this thread, because luckily I've been able to solve it.
It turned out to be simpler then I first assumed. Basically, the error occurred due to another error in the measurements in calibration. This was then stored in the override.g file. I was suspecting that there might have been an error there, but each time I tried deleting it, it was already stored in the machines RAM.
Here is a step by step guide, explaining how I fixed it:
Temporarily delete/comment out the M500 command in the bed.g file. (It causes the machine to store the new values after calibration)
Delete the config-override.g file and do an emergency stop of the machine.
Restart it, (hopefully there shouldn;t be a config-override.g file) and add the M500 command back in, then perform a delta calibration.
This should have: removed your previously stored values in config-override.g for good --> allowing for new values to replace them, so the printer will home properly.
Also, you don't need the G92 command, it was only a temporary fix
Right now it is a little bit blank - it is the magnetic part of one of those aliexpress magnetic print surface - Will try with the print surface on when i get back (the Matt print surface you print on the magnetic sheet)
For the BLTouch the slower the better. I use a faster probe first to save time in case the bed is far from the nozzle, and then a final probe at F100 for greater accuracy.
M558 A1 F350 ; Set single probing at faster feed rate
G30 ; Do a single probe to home our Z axis
M558 A10 F100 ; Set tripple probing at slower feed rate
G30 ; Probe again to get a more accurate position
I can't say for other probes, but I think that would generally hold true. A piezo probe may have a minimum speed to register cleanly though.