Probing: Delay after trigger?

Hello everyone,

First post here so forgive me if this is the wrong sub-forum to post.

I'm trying to build a simple 3D touch probe (the "6 balls/3 pins" kind). Probing seems to work but it's currently not very accurate (calculated pretravel variation of ~70um). I'm using LinuxCNC 2.9.2 with Mesa 7i92+7i76 on an i3-2100. Probe Basic as GUI.

While looking at my oscilloscope trace of the trigger signal, I was wondering how fast I should expect the movement to stop once motion.probe-input is triggered. Is it normal to expect a 5-10+ ms delay or there is something wrong with my setup? What I'm seeing is that even though the probe triggers immediately after a light touch to the object, the probe switch opens after some time (as if movement towards the target of G38.2 continues). Is this behavior normal?

Even if there is a significant delay, should I expect the value reported in #5061/#5062/etc. to be the exact position when motion.probe-input has been triggered?

Looking at the code (github.com/LinuxCNC/linuxcnc/blob/master...otion/control.c#L693) the position is saved immediately upon triggering and tpAbort is called (tp == trajectory planner?). Assuming that this code is called from the 25us thread, it seems strange to see the probe switch open after 10ms.

Attached is a capture from the oscilloscope. Channel 1 is the voltage at the probe (probe is the lower leg of a resistive divider) and Channel 2 is the trigger signal.

Thanks in advance.

Maybe I am not understanding the question, but after triggering the probe
the joint must obey the ini file set acceleration bounds when coming to a stop
and reversing. This could easily be many mS.
 

I understand your issue, delay after triggering. Although not a fix (all systems has some sort of delays/accel/decel/ect), the workaround is to use a probe calibration routine. Easier to offset those cal values from the measurement than to real-time the system (imho).

Delay or not, I spec within 5um using cal/offsets.

Fwiw my calibration routine was inspired by github.com/hausen8/EasyProbe

You'll probably need to complete the missing Z calibration, however the X & Y are completed and functional. Have a look. And let us know how you're doing!

Maybe I am not understanding the question, but after triggering the probe
the joint must obey the ini file set acceleration bounds when coming to a stop
and reversing. This could easily be many mS.

You are absolutely right. For some reason I totally forgot about deceleration. Probably because the probing speed I'm using is too low (50mm/min). I'll have to check my ini settings and try to calculate the total distance required for stopping after the probe triggers.

So, if this is the reason I'm observing this behavior, I should expect the probed position (#5061/etc) to correspond to the timestep when motion.probe-input was triggered, right? So, the maximum expected error to the probed position from LinuxCNC itself should be the distance the probe travels in 25us interval between motion.probe-input checks. Am I right?

Although not a fix (all systems has some sort of delays/accel/decel/ect), the workaround is to use a probe calibration routine. Easier to offset those cal values from the measurement than to real-time the system (imho).

Currently, I'm trying to see how good the probe/circuit is without calibration. As far as I understand, calibration can only really help if the probe behaves equally well from all approach angles (i.e. pretravel variation is small). If the probe always triggers at the exact same position when approaching the object from a specific angle (i.e. unidirectional repeatability is 0 independent of probe orientation) but the pretravel variation is too large (e.g. 100um) how can calibration help in this case? It might only help if I can guarantee that the probe is always inserted into the spindle in the exact same orientation, which unfortunately I cannot.FWIW, my test setup is a 63mm OD ball bearing. I'm probing the center using Probe Basic's routines and then run a custom routine to probe the outside of the bearing every 10deg 10 times.
 

Fwiw my calibration routine was inspired by github.com/hausen8/EasyProbe

You'll probably need to complete the missing Z calibration, however the X & Y are completed and functional. Have a look. And let us know how you're doing!

Thanks for the link. I'll take a look to see if I can find something different compared to Probe Basic's calibration routine.

jdryg wrote:

Correct statement. The spindle requires indexing at 0deg before the probe tool be mounted and meas takes place. And ofc only effective in the angles the calibration is prog to be within. Best 'workaround' I found to address this delay/overtravel issue. Yet. 

You are 100% correct though. The Lcnc control could see improvement on the probing code (I recommend). I also run a 828 and 808 (sinumerik) and both sends the control into estop-like when the probe triggers, then reset. Not sure how that's done, slightly brutal on the mechanical but nonetheless there is zero overtravel. Saying estop-like here it could also well be disabling/enabling the drives too. 

Please update us on your progress. Subscribed, and thanks for raising this issue. 

Correct statement. The spindle requires indexing at 0deg before the probe tool be mounted and meas takes place. And ofc only effective in the angles the calibration is prog to be within. Best 'workaround' I found to address this delay/overtravel issue. Yet.

I don't know if the overtravel I'm observing is actually an issue, that's why I asked in the first place. If someone can confirm that the order of operations performed by LinuxCNC is as I understand them to be, it should not be an issue after all.

What I expect LinuxCNC to do:
- Check motion.probe-input as fast as possible (every thread cycle; 25us by default?)
- When the pin changes state, store the current position into #5061/etc.
- On the same cycle start decelerating.
- When the machine stops, finish G38.2 command and move on to the next command in the program.

Can you or somebody else confirm whether this is correct or wrong?

If it's correct, overtravel while decelerating should not be an issue, as far as I can tell, because the position I'm interested in is already recorded at the correct timestep.

Btw, are you Mecanix from cnczone forums? I found the thread about your probe and I was wondering if you ever measured its pretravel variation similar to how ZincBoy described in an old thread .

Over travel in G38.x does not influence the stored position, it would be fairly useless if it did:

Thank you! I somehow missed (or forgot reading) the docs...

Depends on your Servo Thread, usually 1ms for a Mesa setup.

Yeah. I just found out that I mixed the times of the servo and base threads in my head So motion.probe-input is checked every 1ms. That means that I have to calculate how much distance the probe can travel in 1ms to see what's the expected error in my calculations.

Thank you all for your replies.