On 12/05/2017 12:05 PM, Kurt Jacobson wrote:
I like Cristian's idea of having a "stop on unexpected probe trip" HAL pin,
defaulting to TRUE.
That seems the most flexible, and then even a remap could set/unset it if
needed for some reason.
On Tue, Dec 5, 2017 at 1:58 PM, Ken Strauss <ken.stra...@gmail.com> wrote:
Perhaps too much to ask but having the "stop on unexpected probe trip"
behavior driven by a tool table parameter would be even better. That would
eliminate the need to modify existing probe routines.
-----Original Message-----
From: Cristian Bontas [mailto:cristianbonta...@gmail.com]
Sent: Tuesday, December 05, 2017 1:16 PM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Avoiding probe crash
I would have the "stop on unexpected probe trip" behavior driven by a
config
setting, or even better a HAL pin. The latter would allow maximum
flexibility,
e.g. it could be linked to a UI toggle if needed, or always on/off as
desired.
On 05.12.2017 20:01, Sebastian Kuzminsky wrote:
On 12/05/2017 09:56 AM, Jon Elson wrote:
On 12/05/2017 08:11 AM, Les Newell wrote:
Yup, I can confirm it ignores probe when in auto.
If the probe is not tripped, and the non-probe auto move touches the
probe, it just keeps on moving?
That is really wrong! I'm pretty sure my old 2.7.x does stop with an
error message.
I agree that any unexpected probe trip (ie, any probe trip that
happens while the machine is *not* running G38.*) is a scary event
that seems like it should Abort or maybe even E-stop the machine.
The one argument i've heard for ignoring probe trips during non-probe
moves is that some probes might trip spuriously when jostled by tool
changers, or simply from sitting on a flimsy workbench next to a
high-acceleration machine.
A possible solution might be to somehow make LinuxCNC know when a
probe tool is loaded in the spindle, and Abort/Estop on non-G38 probe
trips when a probe tool is loaded, and ignore all probe trips when no
probe tool is in the spindle.
Les Newell's use case (where the "probe" is a tool length sensor
permanently mounted to the table) shows the problem with my "what's in
the spindle"-centric proposal.
I like part of Christian's proposal, where the user can configure HAL to
enable/disable the "E-stop on unexpected probe trip" behavior.
I'm also sympathetic to Jon Elson's opinion that a spurious probe trip
is essentially a misconfigured/glitchy machine, and it's the user's job
to fix it somehow (possibly using some HAL logic to control the signal
that Christian proposed).
So I propose this:
* Define a "probe trip" to be a positive edge on the motion.probe-input pin.
* A probe trip during G38 (ie, when motion.motion-type == 5) is handled
just like now.
* A probe trip at any other time causes E-stop.
* A user with a glitchy probe can restore 2.7's behavior ("ignore probe
trips when not probing") by setting up HAL logic like this:
motion.probe-input = probe-input-pin AND (motion.motion-type == 5)
In brief, this is a proposal to change the behavior from 2.7's "ignore
spurious trips" to a new "E-stop on spurious trips", and a suggestion of
a simple user-level configuration work-around to restore the old
behavior by masking the probe input. Other HAL circuitry is of course
possible too, depending on what the user wants.
--
Sebastian Kuzminsky
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
