Re: [Emc-users] Avoiding probe crash

[Gene Heskett]

On Thursday 07 December 2017 15:07:08 andy pugh wrote:

> On 7 December 2017 at 19:52, Gene Heskett  wrote:
> > Humm. Do you have an old version? I can't see any "common" text in
> > my copies, using 2.8-pre updated this morning...
>
> select8 − 8-bit binary match detector
> match8 − 8-bit binary match detector

My blink comparator failed.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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

Re: [Emc-users] Avoiding probe crash

[andy pugh]

On 7 December 2017 at 19:52, Gene Heskett  wrote:

> Humm. Do you have an old version? I can't see any "common" text in my
> copies, using 2.8-pre updated this morning...

select8 − 8-bit binary match detector
match8 − 8-bit binary match detector



-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] Avoiding probe crash

[Gene Heskett]

On Thursday 07 December 2017 11:14:24 andy pugh wrote:

> On 7 December 2017 at 16:01, Sebastian Kuzminsky  
wrote:
> > net motion-is-probe <= select8.0.out5
>
> The text in "select8" seems to be borrowed from "match8" and does not
> actually describe the function of the component.

Humm. Do you have an old version? I can't see any "common" text in my 
copies, using 2.8-pre updated this morning...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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

Re: [Emc-users] Avoiding probe crash

[andy pugh]

On 7 December 2017 at 16:01, Sebastian Kuzminsky  wrote:

> net motion-is-probe <= select8.0.out5

The text in "select8" seems to be borrowed from "match8" and does not
actually describe the function of the component.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] Avoiding probe crash

[andy pugh]

On 7 December 2017 at 16:09, andy pugh  wrote:

> If you need a logical true/false based on that pin (Which is S32) then
> I think (after looking through all the likely HAL components) that you
> would need to convert

I was wrong. As Seb has pointed out, "select8" will work.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] Avoiding probe crash

[andy pugh]

On 7 December 2017 at 15:51, 王若溪  wrote:

> If motion.motion-type == 5 can be a HAL signal then my problem is solved. I
> could program the behaviour that suits my need.

If you need a logical true/false based on that pin (Which is S32) then
I think (after looking through all the likely HAL components) that you
would need to convert to U32 and use mux_generic (which lets you
define an output state for every motion type) or convert to float and
use "near" or "wcomp"
http://linuxcnc.org/docs/2.7/html/man/man9/conv_s32_u32.9.html
http://linuxcnc.org/docs/2.7/html/man/man9/conv_s32_float.9.html
http://linuxcnc.org/docs/2.7/html/man/man9/mux_generic.9.html
http://linuxcnc.org/docs/2.7/html/man/man9/near.9.html

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] Avoiding probe crash

[Sebastian Kuzminsky]

On 12/07/2017 08:51 AM, 王若溪 wrote:

If motion.motion-type == 5 can be a HAL signal then my problem is solved. I
could program the behaviour that suits my need.


There's currently not a single boolean pin that carries 
"motion.motion-type == 5", but you can easily make one, perhaps using 
something like this:


net motion-type <= motion.motion-type
net motion-type => select8.0.sel

net motion-is-probe <= select8.0.out5

Now the motion-is-probe signal will be True during probing moves, and 
False at all other times.


I would welcome a PR that adds individual binary 
"motion.motion-type-is-*" output pins to Motion.



--
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

Re: [Emc-users] Avoiding probe crash

[王若溪]

I agree to have an Abort instead of an E-stop, only in this way we have a
defined deceleration rate. Each touch probe or tool setter has several
millimetres of safe travel, given the deceleration during the stop, we can
calculate the maximum safe feed with

max_safe_feed = sqrt(2 * safe_travel * deceleration)

(Unit conversion may need to be applied)

If motion.motion-type == 5 can be a HAL signal then my problem is solved. I
could program the behaviour that suits my need.

2017-12-07 23:26 GMT+08:00 王若溪 :

> Good call. I like this.
>
> (It's a joke isn't it?)
>
> 2017-12-05 0:42 GMT+08:00 Nicklas Karlsson :
>
>> On Tue, 5 Dec 2017 00:37:03 +0800
>> 王若溪  wrote:
>>
>> > I'm writing some auto measurement G-code program using my CNC mill and a
>> > touch probe.
>> > Seems that LinuxCNC doesn't want to stop when the probe is tripped
>> during a
>> > non-probe move if the machine is running a G-code program.
>> > Currently, I'm replacing every non-probe move with G38.3. After it's
>> > execution, signal an error if the current position is not commanded
>> > position (which indicates that the probe was tripped during this move),
>> > continue if current position matches commanded.
>> >
>> > Any thoughts?
>>
>> Yes, connect touch to stop signal.
>>
>> 
>> --
>> 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
>>
>
>
>
> --
> 王若溪
> 清华大学
> 航天航空学院
> 航硕161班
>



-- 
王若溪
清华大学
航天航空学院
航硕161班
--
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

Re: [Emc-users] Avoiding probe crash

[王若溪]

Good call. I like this.

(It's a joke isn't it?)

2017-12-05 0:42 GMT+08:00 Nicklas Karlsson :

> On Tue, 5 Dec 2017 00:37:03 +0800
> 王若溪  wrote:
>
> > I'm writing some auto measurement G-code program using my CNC mill and a
> > touch probe.
> > Seems that LinuxCNC doesn't want to stop when the probe is tripped
> during a
> > non-probe move if the machine is running a G-code program.
> > Currently, I'm replacing every non-probe move with G38.3. After it's
> > execution, signal an error if the current position is not commanded
> > position (which indicates that the probe was tripped during this move),
> > continue if current position matches commanded.
> >
> > Any thoughts?
>
> Yes, connect touch to stop signal.
>
> 
> --
> 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
>



-- 
王若溪
清华大学
航天航空学院
航硕161班
--
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

Re: [Emc-users] Avoiding probe crash

[Les Newell]

I agree. The current behaviour in MDI is to feed hold and abort the rest 
of the motion. That should also work for auto.


Les

On 05/12/17 22:14, Greg Bentzinger via Emc-users wrote:

I like Seb's version with the exception that a probe trigger E-stop.
Personally I would prefer the option to invoke a motion/feed hold command with 
alarm vrs E-stop since many machines can stop faster under power.
Greg
--
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




--
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

Re: [Emc-users] Avoiding probe crash

[Moses McKnight]

I perhaps have a little different perspective since we use probe moves with 
plasma systems where the "probe" is the torch tip and is either ohmic sensing or 
a switch mechanically activated when the torch is pressed against the metal.


2.7 does not ignore all spurious trips, because it will abort if probe is 
tripped during a jog or homing.  I am using a patch I made which adds two INI 
settings to disable each of those behaviors, although we pretty much only ever 
disable probe aborting during homing for our setups.


I do think it should be "abort" instead of e-stop on spurious trips.

I like the idea of a HAL pin to disable the behavior because I think that might 
make it easier to do more complex disabling of probe aborts - such as ignoring 
probe trips while homing, or restoring the 2.7 behavior where spurious probe 
trips are ignored except while homing or jogging.


Moses

On 12/05/2017 03:28 PM, Sebastian Kuzminsky wrote:

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.





--
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

Re: [Emc-users] Avoiding probe crash

[Jon Elson]

On 12/05/2017 03:28 PM, Sebastian Kuzminsky wrote:


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.

Well, an abort is probably less troublesome than an E-stop.  
In some systems, an E-stop is not so easy to recover from.  
Right now, I think 2.7.x does an abort, and that has been 
fine.  Or, am I running 2.6.x,  I forget...



Jon


--
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

Re: [Emc-users] Avoiding probe crash

[Gene Heskett]

On Tuesday 05 December 2017 17:02:53 Ken Strauss wrote:

> > -Original Message-
> > From: Sebastian Kuzminsky [mailto:s...@highlab.com]
> > Sent: Tuesday, December 05, 2017 4:29 PM
> > To: Enhanced Machine Controller (EMC); Kurt Jacobson
> > Subject: Re: [Emc-users] Avoiding probe crash
> >
> > 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 (m

Re: [Emc-users] Avoiding probe crash

[Sebastian Kuzminsky]

On 12/05/2017 03:14 PM, Greg Bentzinger via Emc-users wrote:

I like Seb's version with the exception that a probe trigger E-stop.
Personally I would prefer the option to invoke a motion/feed hold command with 
alarm vrs E-stop since many machines can stop faster under power.


I don't like Pause as a response to this failure.

I agree than a message should be presented to the user, something like 
"unexpected probe trigger (not during a probe move)".


What about Abort instead of Estop?

My understanding is that Abort causes the machine to stop running the 
program and decelerate to 0 velocity at the maximum rate (just like if 
you hit Escape in Axis), whereas E-stop causes the machine to cut power 
to the motors (allowing the machine to coast to a stop).



--
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

Re: [Emc-users] Avoiding probe crash

[Greg Bentzinger via Emc-users]

I like Seb's version with the exception that a probe trigger E-stop.
Personally I would prefer the option to invoke a motion/feed hold command with 
alarm vrs E-stop since many machines can stop faster under power.
Greg
--
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

Re: [Emc-users] Avoiding probe crash

[Ken Strauss]

> -Original Message-
> From: Sebastian Kuzminsky [mailto:s...@highlab.com]
> Sent: Tuesday, December 05, 2017 4:29 PM
> To: Enhanced Machine Controller (EMC); Kurt Jacobson
> Subject: Re: [Emc-users] Avoiding probe crash
>
> 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

Does "A probe trip at any other time causes E-stop " mean that the machine
must be re-referenced? That would be a pain to recover from a mistake when
jogging.



--
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

Re: [Emc-users] Avoiding probe crash

[Sebastian Kuzminsky]

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

Re: [Emc-users] Avoiding probe crash

[Kurt Jacobson]

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.
> > >
> > >
> >
> >
> > 
> --
> > 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
>
>
>
> 
> --
> 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
>
--
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

Re: [Emc-users] Avoiding probe crash

[Ken Strauss]

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.
> >
> >
>
>
> --
> 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



--
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

Re: [Emc-users] Avoiding probe crash

[Sebastian Kuzminsky]

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.



--
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

Re: [Emc-users] Avoiding probe crash

[Jon Elson]

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.


Jon

--
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

Re: [Emc-users] Avoiding probe crash

[Les Newell]

Yup, I can confirm it ignores probe when in auto.

Les

On 04/12/2017 18:09, Rene Hopf wrote:

On 4. Dec 2017, at 18:49, Les Newell  wrote:

G0 and G1 were MDI but I guess it will work the same in auto.

it does make a differente. it also makes a difference if the machine is homed 
or not :D
--
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




--
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

Re: [Emc-users] Avoiding probe crash

[Rene Hopf]

> On 4. Dec 2017, at 18:49, Les Newell  wrote:
> 
> G0 and G1 were MDI but I guess it will work the same in auto.

it does make a differente. it also makes a difference if the machine is homed 
or not :D
--
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

Re: [Emc-users] Avoiding probe crash

[Les Newell]

I just tested on my mill with master from a couple of months ago. Probe 
trips during G0, G1 and keyboard jog will stop the machine. Probe trips 
when using jog wheels are ignored. G0 and G1 were MDI but I guess it 
will work the same in auto.


Les

On 04/12/2017 17:38, Jon Elson wrote:


But, I am pretty sure that if a G-code program trips the probe with a 
G01 move, it will also stop.
Maybe you should check and see if only G0 moves fail to stop. You can 
check this safely by manually tripping the probe while far away from 
anything that would cause damage.


I think the only real answer is to be real careful with manual probe 
moves, with your finger hovering over

ESC or E-stop.

Jon

-- 


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




--
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

Re: [Emc-users] Avoiding probe crash

[Jon Elson]

On 12/04/2017 10:37 AM, 王若溪 wrote:

I'm writing some auto measurement G-code program using my CNC mill and a
touch probe.
Seems that LinuxCNC doesn't want to stop when the probe is tripped during a
non-probe move if the machine is running a G-code program.
Currently, I'm replacing every non-probe move with G38.3. After it's
execution, signal an error if the current position is not commanded
position (which indicates that the probe was tripped during this move),
continue if current position matches commanded.


Yes, it seems that it only senses the transition from 
not-tripped to tripped in a non-probe move.
This, of course, allows you to jog away from a tripped 
probe. But, conversely, it allows you to

drive the probe to greater deflection, too!

So, if you accidentally jog something into the probe, the 
machine does stop, with an error message
"probe tripped during jog move" or such. But, then you can 
just ignore it and break the probe.


But, I am pretty sure that if a G-code program trips the 
probe with a G01 move, it will also stop.
Maybe you should check and see if only G0 moves fail to 
stop. You can check this safely by manually tripping the 
probe while far away from anything that would cause damage.


I think the only real answer is to be real careful with 
manual probe moves, with your finger hovering over

ESC or E-stop.

Jon

--
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

Re: [Emc-users] Avoiding probe crash

[Sebastian Kuzminsky]

On 12/04/2017 09:37 AM, 王若溪 wrote:

I'm writing some auto measurement G-code program using my CNC mill and a
touch probe.
Seems that LinuxCNC doesn't want to stop when the probe is tripped during a
non-probe move if the machine is running a G-code program.
Currently, I'm replacing every non-probe move with G38.3. After it's
execution, signal an error if the current position is not commanded
position (which indicates that the probe was tripped during this move),
continue if current position matches commanded.

Any thoughts?


We're currently discussing this issue here:

https://github.com/LinuxCNC/linuxcnc/issues/368

Please comment in that thread, describing your use case.


--
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

Re: [Emc-users] Avoiding probe crash

[Nicklas Karlsson]

On Tue, 5 Dec 2017 00:37:03 +0800
王若溪  wrote:

> I'm writing some auto measurement G-code program using my CNC mill and a
> touch probe.
> Seems that LinuxCNC doesn't want to stop when the probe is tripped during a
> non-probe move if the machine is running a G-code program.
> Currently, I'm replacing every non-probe move with G38.3. After it's
> execution, signal an error if the current position is not commanded
> position (which indicates that the probe was tripped during this move),
> continue if current position matches commanded.
> 
> Any thoughts?

Yes, connect touch to stop signal.

--
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