probe isr m-code and probe detection pin

[jschoch]

It may be good to be able to turn on the probe ISR and to halt on probe contact when you are moving around to do things like probe corners. probe_state_monitor seems to only be on during a probe. You likely don't want to do the per tick monitoring but you would want to create a fault if the probe made contact while you were changing position for center finding for corner finding. This could save your tool or your probe tip if you got something wrong in the sender config. Perhaps marlin's M401 could be used to tell the controller that you are starting a probing macro or Sender cycle.

This also brings up the idea of a probe connection detect pin. This is a good way to ensure you have the probe connected and disconnect it when you are not probing.

[terjeio]

It may be good to be able to turn on the probe ISR and to halt on probe contact ...

Agree. While in the probing tab it should act as an e-stop when not actually probing? In a perfect world G38 could be used to switch modes. Using M401 is out of the question for vanilla grbl?
Another backwards compatibility issue.

... turn on the probe ISR ...

The probe pin is polled, no ISR is assigned. IIRC ISR handling was not done in vanilla grbl since the Arduino does not have IRQ flags per pin? I believe I added an interrupt handler to one of my (unpublished?) drivers long ago - perhaps I should try to locate that as I believe I disabled the IRQ while probing, this since probe state polling is done in the stepper ISR. IMO if IRQ is used for probing as well then the probe ISR should only set (never reset) a flag on contact which is then returned from the polling call. No debounce?

This also brings up the idea of a probe connection detect pin.

By using a stereo jack socket and a mono plug?

[jschoch]

Using M401 is out of the question for vanilla grbl?

I don't think this would be a problem unless you were trying to run grblHAL as a printer. I just picked M401 randomly since marlin uses it for probe deploy. I just looked at klipper and M401 is the same. If you don't have a 3d printer with autoleveling; you typically drive a RC servo to push the Z leveling probe contact down with this M-command. This is the first step for probing and generating a height map. I guess the detection of the probe can be done since differently since the optical probes are signaling contact when they are parked. It may not be a good choice.

This also brings up the idea of a probe connection detect pin.
By using a stereo jack socket and a mono plug?

I think a normally closed switch would work. The idea would be:

in probe mode:

probe_init()
check for probe detection signal && probe_detection_enabled()
if probe detection signal not found alarm
check probe state
if probe state ! triggered return ok

In job run mode (or maybe any motion other than probing)

if probe_detection_enabled() && probe found alarm (GUI could prompt to disconnect probe)
else run motion

The downside of trying to do this with any motion is jogging to the probe start position would be a pain in the ass. My centroid lathe controller has this optional feature.

[terjeio]

For reference

Probe Detection Input Circuit:
A “Normally Closed” Probe DETECTION Circuit CLOSES the Input when Probe is plugged in, this is required method. Some probes such as the Centroid DP-4 have a simple Probe Detection Circuit built into the probe which when the probe is plugged in by the operator lets CNC12 know that a probe is active and in use. This detection input tells CNC12 to start activate Probe Protection. For instance, the spindle will be disabled so the user can not turn on the spindle with the probe plugged in, probe protection will also stop all movement if a probe is tripped unexpectedly to try and prevent crashing of the probe. After CNC12 sees an “unexpected probe contact” ( a probe trigger event not during a probing cycle) it will only allow the user to jog in the opposite direction that the probe was moving when the contact occurred to prevent the user from accidentally moving the probe further into the contact direction causing damage to the probe. So, you can see it is important to use a Probe Detection input. If your probe is not equipped with a probe detection circuit you can wire up a simple switch to the probe detect input that acts as the probe detection circuit. It is up to the operator to throw that switch to the closed positions before using the probe to let CNC12 know that a probe is in use so probe protection is activated. A “Poor man’s” probe detection circuit.

[terjeio]

if probe_detection_enabled() && probe found alarm (GUI could prompt to disconnect probe)
else run motion

This is ok if already triggered, what to do if triggered during a normal move or connection is lost during probing?

I have added probe connected state to the hal.probe_get_state function call:

typedef union {
    uint8_t value;
    struct {
        uint8_t triggered   :1,
                connected   :1,
                unassigned  :6;
    };
} probe_state_t;

For now implemented like this in most drivers (always connected):

// Returns the probe connected and triggered pin states.
probe_state_t probeGetState (void)
{
    probe_state_t state = {
        .connected = On
    };

    state.triggered = <get probe pin state>

    return state;
}

At start of a probing move currently this check is done:

grblHAL/grbl/motion_control.c

Lines 842 to 849 in 73604aa

	// After syncing, check if probe is already triggered. If so, halt and issue alarm.
	// NOTE: This probe initialization error applies to all probing cycles.
	if (hal.probe_get_state()) { // Check probe pin state.
	system_set_exec_alarm(Alarm_ProbeFailInitial);
	protocol_execute_realtime();
	hal.probe_configure_invert_mask(false); // Re-initialize invert mask before returning.
	return GCProbe_FailInit; // Nothing else to do but bail.
	}

I will change this to:

    // After syncing, check if probe is already triggered or not connected. If so, halt and issue alarm.
    // NOTE: This probe initialization error applies to all probing cycles.
    probe_state_t probe = hal.probe_get_state();
    if (probe.triggered || !probe.connected) { // Check probe state.
        system_set_exec_alarm(Alarm_ProbeFailInitial);
        protocol_execute_realtime();
        hal.probe_configure_invert_mask(false); // Re-initialize invert mask before returning.
        return GCProbe_FailInit; // Nothing else to do but bail.
    }

Do we want a new alarm code for when not connected? Dependent on COMPATIBILITY_LEVEL?

Original handling in stepper.c:

grblHAL/grbl/stepper.c

Lines 353 to 360 in 73604aa

	// Check probing state.
	// Monitors probe pin state and records the system position when detected.
	// NOTE: This function must be extremely efficient as to not bog down the stepper ISR.
	if (sys_probe_state == Probe_Active && hal.probe_get_state()) {
	sys_probe_state = Probe_Off;
	memcpy(sys_probe_position, sys_position, sizeof(sys_position));
	bit_true(sys_rt_exec_state, EXEC_MOTION_CANCEL);
	}

For now functionally unchanged:

    // Check probing state.
    // Monitors probe pin state and records the system position when detected.
    // NOTE: This function must be extremely efficient as to not bog down the stepper ISR.
    if (sys_probing_state == Probing_Active && hal.probe_get_state().triggered) {
        sys_probing_state = Probing_Off;
        memcpy(sys_probe_position, sys_position, sizeof(sys_position));
        bit_true(sys_rt_exec_state, EXEC_MOTION_CANCEL);
    }

It is perhaps ok to leave this as is, but it could be nice to have a check for probe connection status and terminate the move (with an alarm?) if connection is lost during probing.

Which brings me back to my initial question above.

Requirements:
One extra input for the probe connected signal, possibly interrupt capable.
The probe signal needs to be wired to an interrupt capable pin.

Scenarios:

• Normal moves including jogging, probe is triggered.

1. Issue a feed hold command and enter alarm mode?
2. Issue an e-stop command and enter alarm mode? Position may be lost.
3. Other?

Only allow moves in the opposite direction until triggered is cleared?

• Probing moves, probe connection is lost (requires interrupt capable connected pin).

1. Issue a feed hold command and enter alarm mode?.
2. Other?

What do you think?

[jschoch]

Let's consider the two types of probers, first the folks who use continuity who likely have made their own setup, and those who have a dedicated touch probe or tool setter.

For the first case (continuity probers); Is anyone actually going to wire up the 2nd input? I'd guess most would not but it still might be worth doing for this case.

1. forgot to disconnect your clips because something else went wrong and you got distracted. This is where checking probe state on job start is a good thing.
2. a clip pops off mid probe move. This is clearly bad and things should halt but can you detect it?
3. the wires get caught up and the machine pulls the connection out.
4. noise generating false probe signals but they may just give up on homing and probing at this point.
5. something moves/disconnects mid-probe.

For the 3rd case I've not had this happen but I can see it happening.

The 2nd prober type would be folks with a dedicated probe or tool setter and if they made it or bought it they are likely to be much more concerned with it breaking. I think this is the main target audience for the probe detect feature. Now, how likely are they to integrate it into a DIY probe? I think they are more likely to just wire it up to a manual switch for probe detect. If it the detection was built into the probe design you could also detect power and use the probe input to fault on a loss of vcc. In any case the probe detect feature is much more likely to save your investment in the dedicated probe.

Probe detect really should be optional, just like limit switches.

As far as the trigger clear move the controller (or sender) would have to track the last move direction, i'm not sure if it does that. I can definitely see a situation where you panic and drive the probe further into the work if you aren't clear on your machine coordinates. I have a machine with a fixed Z and so I have to visualize the tool moving even though only the table moves in X/Y jogs and I do get it wrong. It would be great if it could prompt to say which direction the crash happened since the probe routine moves and last move may not be obvious. Alarm 4 wouldn't tell you much about how to recover and that could be really frustrating for a noob. It could also be argued you should look at the problem and figure out how to move out of it since moving in Z may actually be the best thing. Imagine a bad crash into a clamp that moved the work in an unexpected way.

My vote would be for the operator to figure out how to move out of the pre-probe crash state.

[terjeio]

Probe detect really should be optional, just like limit switches.

Sure, it will be an option at the driver level. The core will check a driver capability flag to find out if a live signal is available. If not, probe protection is not possible and will be skipped.

        ...
        probe_connected           :1,
        unassigned                :3;
    };
} driver_cap_t;