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
>
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
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
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
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.
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
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
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 *
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.
> >
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: [E
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 Jacob
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
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
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
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
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
> 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
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
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
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
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.
>
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
28 matches
Mail list logo