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