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

I do not see a need to re-home the machine in that event, thats an 
operator judgement call as to whether it needs re-homeing, or it was a 
bad move. If the operator can't judge/see the difference, he's obviously 
a new bee, needing a chaperone.

> That would be a pain to recover from a 
> mistake when jogging.

No argument with that. However, if its ignored, that can be an 
educational experience, if not a costly one. I don't have a clue how 
many bits of pcb I've smashed just because I'd forgotten to clip to the 
contact pad it was being, and ran the g38 on purpose. Its embarrassing 
to me, and has 

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 
> 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  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  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] Tech Shop goes out of business

[Jon Elson]

On 12/04/2017 09:36 PM, Danny Miller wrote:
I saw this info, including a non-public letter to their 
investors.


It declared an intent, yes.  BUT lemme say it's "out there".

It does not look like a professional business move.  It 
doesn't look like it's even in accordance with acceptable 
business practices.


They didn't file for chapter 13, which companies sometimes 
use to restructure debt and stay in business.  They filed 
chapter 7- the business assets and its whole existence is 
handed over to a third-party trustee who liquidates it and 
uses the cash to partially pay back creditors.  The 
business is then gone-gone.


Apparently, from the message I got, they did NOT actually 
FILE the chapter 7 papers.  This investor was in the wings, 
and something changed at the last minute, so they did not go 
through with the filing.  At least, that how ** I ** read 
the 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