My profuse apologies for:

my (very) late answer digging up this old topic (Halloween trick or treat ?!)

but my answer is still relevant (based on the code base of the RRF 3.5.0 rc1 and 3.4.6).

@dc42 said in G30: unexpected probe dive motion range:

If you set the dive height to some value H [...] the code starts the dive at (trigger_height + H) and ends it if the probe is not triggered first at (trigger_height - H)

That is my expectation, but not what the G30 command currently does.

You will notice in the code of G30 command the mention of platform.AxisMinimum(Z_AXIS), variable which I can't make sense of:

ms.coords[Z_AXIS] = (IsAxisHomed(Z_AXIS)) ? platform.AxisMinimum(Z_AXIS) - zp->GetDiveHeight() + zp->GetActualTriggerHeight()

This is in contrast to the probing code of the G29 command, which works as you described without ever using platform.AxisMinimum(Z_AXIS):

ms.coords[Z_AXIS] = -zp->GetDiveHeight() + zp->GetActualTriggerHeight();

Hence my (old yet still relevant) pull request.

Hopefully this patch would not bring any regression, however it might save multiple RRF user from less than desirable unexpected nozzle crashes.

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

@fcwilt its an anycubic chiron ultrabase

@jmshep That may have been the case in 3.0 because there were still some default pin associations, but in 3.1.1 all default associations are removed and you no longer need to use nil to undefine them. Rather you now must define the pins being used.

If anyone is interested, my friend and I developed a Cura post processing script.

You pass it a single parameter (mesh spacing), and it parses the first layer gcode for min/max X and Y coordinates, and then replaces the M557 line in your start gcode.

LevelingMeshOptimizer.py.txt

Just remove the .txt, and drop it here: C:\Program Files\Ultimaker Cura 4.5.0\plugins\PostProcessingPlugin\scripts\

You must have a static mesh leveling command in your start gcode, like: M557 X0:200 Y0:200 S20

@dc42 said in Probe Accuracy Test Macro [Issues]:

@CCS86 said in Probe Accuracy Test Macro [Issues]:

@dc42: Does it sound like a bug for the probe offset to be applied over and over on repeated G30 P3 X0 Y180 Z-99999 F2000 calls?

That doesn't sound right. Please post the complete macro file you are running, and your config.g file, and tell us which firmware version you are running.

I was originally on 3.0, and now on 3.01-RC4

Unfortunately, I did not save the macro before modifying it. That is my fault.

I did find one error in my code, in asking it to probe at X0, when my probe has a +12mm offset. I feel like the firmware should catch this more gracefully though. It appears that it ignores the endstop switch and the X0 minimum designation, and tries to aggressively get the probe to X0 anyway, which hard crashes into the machine limit and jumps the belts.

Also, it appears that I can't probe more than 32 points before I am "out of range"

f5cb5f29-c4cd-481d-8a66-404810d82659-image.png

@dc42 said in PINDA Z-Probe Configuration:

The reading needs to be around 0 when not triggered (no metal under the probe) and 1000 when triggered. Try removing the i1 parameter from your M558 command in config.g.

well, that did the trick. Thanks a lot.

It's not as easy to work with Duet, being used to Marlin for years...

@icy_snake said in BLTouch Not Probing Multiple Times:

I have different Alu beds and glass beds. but all of them look close. That can´t be.
Also if I rotate them the drop stays always at the same back corner. Thats not possible!

It is possible, if the beds are flat but the gantry height varies with XY position. I test bed probing by deliberately putting a thin item (e.g. a microscope slide, or thin piece of plastic) on part of the bed.

You may also find these wiki pages useful:

https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_BLTouch
https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe
https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_Z_using_a_Z_probe