Probing: Delay after trigger?

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:

After successful probing, parameters 5061 to 5069 will be set to the coordinates of X, Y, Z, A, B, C, U, V, W of the location of the controlled point at the time the probe changed state.

linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38

(every thread cycle; 25us by default?)

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

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.

FWIW, I added a Mesa output to my HAL, connected to the same signal used for motion.probe-input in order to monitor it with the oscilloscope along with the touch probe's trigger signal.

The total delay is 2-3ms (see attachment;CH1 is the probe trigger signal, CH2 is the Mesa output).

The reason it's not ~1ms (servo period) is that I had an OR gate connected to motion.probe-input for both a touch probe and a tool setter and the OR's function was executed after hm2_7i92.0.write. Removing the OR gate and connecting the Mesa input used for the touch probe directly to motion.probe-input (and the new output) dropped the delay to 1-2ms (I don't have a screenshot for that).

Either way, even 3ms delay does not explain the pretravel variation I'm observing, so the problem must be somewhere else. At 50mm/min probing speed, the total error introduced by that delay should be around 2.5um (given that I didn't make a mistake in my calculations). So not an actual problem at the moment.

Looking at my HAL file (initially generated by PNCconf) I wondered whether I need the PIDs (EDIT: I'm using open-loop steppers). After searching the forums I found that it helps with position estimation (if I understood correctly). A couple of questions:

1. How do the PIDs affect the position recorded during probing?
2. Is the following snippet correct or it's a bug in PNCconf?

net x-output     <= pid.x.output
net x-output     <= hm2_7i92.0.stepgen.00.velocity-cmd

Doesn't this mean that x-output has 2 writers?