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 (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 been known to damage the jig the pcb pad was on. > > > ---------------------------------------------------------------------- >-------- 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 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 <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ 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
