@Mythbear74 I did, it seemed for me not at all relevant for your issue. Maybe try to explain here, I do not see why continue to talk on Discord...

Yes my printer is an IDEX,
the reason the BL-touch is K0 is because K1 is a 3-axis tool offset probe mounted in the back of the machine

; Z-Probe M558 P8 C"!io7.in" H10 F120 T1200 A15 S0.005 K1 G31 P500 X-73 Y-298.8 Z23.336 U0 K1

If I set an X offset on the probe won't the X axis also move when i perform a calibration?

Here is the way U is used in my printer, the BL-touch is mounted beside T1

; Tools M563 P0 S"E0+E1" D0:1 ; define tool 0 G10 P0 X0.0 Y0.0 Z21.5 U0.000 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C M567 P0 E0.5:0.5 ; set tool 0 mix ratio M563 P1 S"E2" D2 X3 ; define tool 1 G10 P1 X0 Y-0.40 Z24.95 U1.50 ; set tool 1 axis offsets G10 P1 R0 S0 ; set initial tool 1 active and standby temperatures to 0C

@alankilian said in LIDAR Bed Leveling:

@3Dreamer The sensor being discussed is not a LIDAR sensor, it's a LASER triangulation sensor, so it's nothing special technology-wise.

People use triangulation sensors for bed leveling all the time and it has it's good and bad points.

Hi alankilian,
you are right. I'll quote a paper in order to introduce readers to the differences:

3D ranging technologies generally fall into either position-based (triangulation) or time-based (LIDAR) approaches. Triangulation can provide much higher precision at close to mid-range but degrades quickly with the square of distance. LIDARs can provide reasonable precision over much longer distances but, unlike triangulation, they do not improve in capabilities at short range where precision and speed are critical for many applications such as autonomous rendezvous and docking, guidance and navigation, obstacle avoidance, and inspection.

So let's us speak about those technologies!

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

And just for the sake of completeness. Examples and instructions here: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

@phaedrux Thank you for your help. 3Z auto leveling is working now

Yes maybe backlash. @sungod3k can you provide a screen shot showing an isometric view?

@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?

sorry i just realized how the setup is one.

are the switches NO or NC?

i would try to wire them in parallel and use M558 P5

they will need to be connected to the z probe port.

but a construct would allow the printhead to move. this would not be beneficial for the print quality.

Hi @Gary,
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

@dc42
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)