Probing... the finer details

So I recently had somewhat of an epiphany wrt how probing works on our machines. After some digging around github and other forums, I found out that the G38.2 command we all use has an inherent problem. Our machines have to decelerate to a stop after contact, and most of us (like 99% from what I’ve seen online) are using the point where the machine stops for our zero, not the actual contact point. So the common thing ppl do to get more accuracy is a second, slower probing. That basically reduces the distance to come to a stop is all it does, but there is still that annoying finite distance that will always be there. It should not be this way, and it absolutely piques my OCD…

Then I thought, WTF are we using an interrupt for if we aren’t even using the value from it?

This is where I realized that the way grbl and marlin are setup assumes if we want to use the accurate value, we have to write it down from the terminal “PRB:xxx” report and use it with some knowledge to setup the machine precisely for a cut. That seems like a method out of the 70’s, tbh… but it is there to be used (curious how many ppl are doing it this way?). Chamnit, lead grbl dev, said adding a retract to the contact point is not desirable as it can’t be removed if needed (for whatever reason that would be?.. 1% use case?), but can be added later by the user (99% of users doing this?). IDK about that logic TBH… seems like having it retract to the contact point would make probing work much more accurately for everyone, and adding the retract in is not so easy without the proper software to help.

Fortunately there exists a streamlined way to use contact point probing… it requires using bCNC gcode macros (AFAIK it’s the only sender that has a macro language ATM). I already posted about this in the GRBL category, but wanted to add it here to get a broader audience (this is a thing that affects both fw’s). Here is the script that hides under one of my bCNC macro buttons:

(Z probe script: precise contact point using bCNC macros)
G91
G38.2 Z-20 F100
G10 P0 L2 Z[prbz]
G0Z5
G90

As I mentioned in the other posting, this method uses the actual contact point which is recorded using an interrupt (single microstep accuracy guaranteed). So you get better accuracy than the more common method, and you don’t have to do any silly stuff like slowing down and second probing (except staying slow enough to prevent breaking expensive bits on hard materials during decel).

1 Like

I get the gist of what is happening here, but looking at the Marlin reference for G10, I don’t see an L2 or a Z parameter.

2 Likes

Have you asked Marlin about it? Most Marlin users don’t even enable G38, so we may get more traction asking for the feature there. Marlin is also more flexible historically.

“The feature” being reversing to the point where ut was triggered.

Although didn’t I read something today about how Marlin doesn’t decelerate after it triggers? Or did I read that wrong?

Ah, you are correct. To be honest I have never used marlin for Cnc, and assumed it’s g38.x worked the same way… it is a thing brought over from Cnc land after all. I retract my comment about marlin above.

I have not found any docs about what if anything marlin reports after probing. If it doesn’t decel, there is the answer to all of it… theoretically anyways.

Edit: I noticed when homing z my grbl mpcnc sounds like it is not decelerating. I wonder if the behavior is consistent for homing in grbl?

1 Like

I know this is an old post, but I thought I would add that if you want to incorporate a tool offset to this code, do the following: …[prbz+5]
This will set the zero down 5 units from probe trigger point. If you want it to go up, subtract that amount.
Thanks for this, Kev!

1 Like