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
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
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).
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 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
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
--
> -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
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
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
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]
>
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
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
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
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
14 matches
Mail list logo