Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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 >

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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.

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 王若溪
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 *

Re: [Emc-users] Avoiding probe crash

2017-12-07 Thread 王若溪
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. > >

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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).

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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: [E

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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 --

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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 Jacob

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread Sebastian Kuzminsky
ntas [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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread Kurt Jacobson
ilto: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 > > s

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread Ken Strauss
mail.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 latt

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-05 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-04 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-04 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-04 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-04 Thread 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

Re: [Emc-users] Avoiding probe crash

2017-12-04 Thread 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. >

[Emc-users] Avoiding probe crash

2017-12-04 Thread 王若溪
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