headers
gene heskett | 1 Feb 01:18
Favicon

Re: Probing error?

On Tuesday, January 31, 2012 06:57:39 PM Chris Radek did opine:

> On Tue, Jan 31, 2012 at 11:31:26AM -0500, gene heskett wrote:
> > the machine state, the usefulness of the probe has been fulfilled, so
> > why the heck should it care one way or the other when the machine
> > tries to do a g0 z[#5063 +0.02] in order to back off
> 
> I sympathize with you being frustrated with this, but the reason for a
> probe RISING edge during a machine rapid causing the machine to stop
> is very clear - if you don't mean to be probing, and you're rapiding,
> and something hits the probe, the next half-second or so may cause the
> shedding of many tears and dollars if the machine doesn't stop.  Those
> things are shockingly expensive.

This could be usable, IF the probe was isolated, but it is not, its the pcb 
material that is isolated.  In this case, any move in the upper hemisphere 
s/b legal.  There is nothing in the up direction but the end of the post or 
the top of the gearbox hitting the Z bearing housing.

> Problems with bounce are a pain though, and not just for linuxcnc
> users I bet, because my Renishaw has a debounce time constant, in the
> hardware, of several ms.  I do final probe moves (length of only about
> .002) at F0.1!

I'd have to come from about .0100 up as there is about 5 thou of backlash, 
and my last probe move now is at .5 ipm.  At .1, its so slow you have to 
actually check the Z motor coupling to see if its working at all.

> > It does
> > care while executing the following G00 or G01 move, and its reporting
(Continue reading)

Permalink | Reply | 1 comment |
headers
gene heskett | 1 Feb 01:21
Favicon

Re: Probing error?

On Tuesday, January 31, 2012 07:19:33 PM Peter C. Wallace did opine:

> On Tue, 31 Jan 2012, gene heskett wrote:
> > Date: Tue, 31 Jan 2012 11:31:26 -0500
> > From: gene heskett <gheskett@...>
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> >     <emc-users@...>
> > 
> > To: emc-users@...
> > Subject: Re: [Emc-users] Probing error?
> > 
> > On Tuesday, January 31, 2012 11:15:31 AM Chris Radek did opine:
> >> On Tue, Jan 31, 2012 at 10:49:04AM -0500, gene heskett wrote:
> >>> show stopper.  In doing a G38.2 f1 z2.5, it will probably stop well
> >>> within a thou of contact.  But then I am dead in the water because
> >>> when I try to do a z move to #5063 + 0.01, it will move about .0005,
> >>> breaking the contact, which is then reported as an error, shutting
> >>> the machine down and
> >> 
> >> Exactly what error do you get?
> >> 
> >> I'm suspicious that it's not the break that's the error, it's
> >> another bounced make.
> > 
> > While that is virtually guaranteed to happen Chris, my point is that
> > once the G38.2 move has detected a closure, stopped the named axis
> > and recorded the machine state, the usefulness of the probe has been
> > fulfilled, so why the heck should it care one way or the other when
> > the machine tries to do a g0 z[#5063 +0.02] in order to back off and
(Continue reading)

Permalink | Reply | 0 comments |
headers
gene heskett | 1 Feb 01:27
Favicon

Re: Back to isolcpus=1, again...

On Tuesday, January 31, 2012 07:22:16 PM Kent A. Reed did opine:

> <I'm backtracking a bit>
> 
> On 1/31/2012 10:49 AM, gene heskett wrote:
> > On Tuesday, January 31, 2012 09:53:43 AM andy pugh did opine:
> >> >  On 31 January 2012 16:36, gene heskett<gheskett@...>  wrote:
> >>> >  >  In grub, if the rtai kernel line has "isolcpus=1" appended,
> >>> >  >  which takes cpu1 out of the scheduler, then after the boot in
> >>> >  >  completed, everything is running on cpu0.
> >>> >  >  
> >>> >  >  Then, using taskset, put emc/linuxcnc to running on the now
> >>> >  >  forcibly idled cpu1.
> >> >  
> >> >  I thought LinuxCNC did this automatically if isolcpus was set?
> > 
> > Apparently it does not, at least not on my box, Andy.  There is a line
> > in the dmsg output that seems to indicate it is aware of isolcpus,
> > but IMO its wrong.  In fact I'll look and see if taskset's use fixes
> > that right now. No, that line:
> > 
> > RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs
> > DISPATCHED), ISOL_CPUS_MASK: 0).
> 
> Gene:
> 
> I haven't spent enough time in the RTAI source code to know just what
> ISOL_CPUS_MASK means and what it causes to happen or not happen. Perhaps
> this will turn out to be a vital clue but I don't know how to interpret
> it.
(Continue reading)

Permalink | Reply | 3 comments |
headers
dave | 1 Feb 02:38
Favicon

Re: Probing error?

On Tue, 31 Jan 2012 19:18:41 -0500
gene heskett <gheskett@...> wrote:

> On Tuesday, January 31, 2012 06:57:39 PM Chris Radek did opine:
> 
> > On Tue, Jan 31, 2012 at 11:31:26AM -0500, gene heskett wrote:
> > > the machine state, the usefulness of the probe has been
> > > fulfilled, so why the heck should it care one way or the other
> > > when the machine tries to do a g0 z[#5063 +0.02] in order to back
> > > off
> > 
> > I sympathize with you being frustrated with this, but the reason
> > for a probe RISING edge during a machine rapid causing the machine
> > to stop is very clear - if you don't mean to be probing, and you're
> > rapiding, and something hits the probe, the next half-second or so
> > may cause the shedding of many tears and dollars if the machine
> > doesn't stop.  Those things are shockingly expensive.
Yes, they are: but shop-built ones can be quite effective. A couple of
years ago I posted a design for a "simple probe" ... done with 3 thick
brass buttons isolated by nylon and epoxy and .1875 dowel pins to fit
into the cones on the buttons. Really not good to better than 0.1 thou
in xy plane or z. Still good enough for amateur use. :-)
Someplace in the archives of the usr list are posts and a pointer to
some pics. If you paid $$$$$ for a commercial probe the real caution is
in order. 

Dave

> 
> This could be usable, IF the probe was isolated, but it is not, its
(Continue reading)

Permalink | Reply | 0 comments |
headers
BRIAN GLACKIN | 1 Feb 04:24
Picon

Archived discussion of IRC link - broken

on the community page http://www.linuxcnc.org/index.php/community

the link in this text "There is also an archive of the
discussions<http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/>that
take place on #linuxcnc. "

leads to

http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/

and results in
Not Found

The requested URL /irc/irc.freenode.net:6667/emc/ was not found on this
server.

Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.

Probably from the rebranding.

Pardon if this is a known issue.

Brian
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Christiansen | 1 Feb 05:14
Favicon

Re: question on gcode parsing

On 30.01.12 07:54, Kenneth Lerman wrote:
> On 01/30/2012 12:28 AM, Erik Christiansen wrote:
> > What is being missed here is that the present parser does all that you
> > fear above, just without the maintainability and documentation benefits
> > conferred by a higher level implementation, using powerful tools.
> >
> > Erik
> >
> No.  I don't think so.
> 
> The current implementation does it; not the current parser. If we go 
> back to the compilation/execution analogy, some error conditions are 
> detected at run time; not at compile time.

There is no compile time. Both the current and future parsers are
interpreters only, AIUI.

> I don't see how the parser can require that G1 has an Fn clause
> defined on the same or some previously executed line.

Nor can I. It doesn't. AIUI, gcode executes with whatever value of that
modaility is current. It does that now, and any new interpreter easily
does the same. The grammar then _permits_ an Fn clause where we choose.

> The parser knows nothing about execution order; only about lexical
> order. Since the Fn might be hidden away in some subroutine, the parse
> might not have seen it. I would think that knowing whether an Fn is
> active is a difficult problem when looking from the outside, but a
> simple problem from the inside of the run time environment. (Of
> course, feel free to prove me wrong.)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Kent A. Reed | 1 Feb 06:00
Picon

Re: rs274ngc bison/flex parser {was: question on gcode parsing}

On 1/31/2012 6:05 PM, Michael Haberler wrote:
> ok, while this wonderful discussion was raging on, I built a working parser for the current linuxcnc
dialect, as an experiment in feasability (this is NOT an end-user tool!)
>
> http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev
>
> - Michael
>
> ps: I'd appreciate feedback from language geeks wrt to removing shift/reduce conflicts.
>
>

Michael:

To quote an Australian friend, "Good on ya, Mate!" (Best said with a 
raised tinny of beer in your hand.)

To quote an old proverb, "a bird in the hand is worth two in the bush."

Regarding your postscript, see treatments like 
http://docs.freebsd.org/info/bison/bison.info.Expect_Decl.html and its 
linked material for a very pragmatic approach to the problem. I know 
this approach is anathema to purists but sometimes pragmatism works.

A better answer is ... well, wait, I'll bet Erik has better things to 
say than I do. I'm twenty years out of practice and likely to shoot 
myself in the foot if I go off halfcocked.

Regards,
Kent
(Continue reading)

Permalink | Reply | 0 comments |
headers
dave | 1 Feb 06:45
Favicon

Re: question on gcode parsing

On Wed, 1 Feb 2012 15:14:39 +1100
Erik Christiansen <dvalin@...> wrote:

> On 30.01.12 07:54, Kenneth Lerman wrote:
> > On 01/30/2012 12:28 AM, Erik Christiansen wrote:
> > > What is being missed here is that the present parser does all
> > > that you fear above, just without the maintainability and
> > > documentation benefits conferred by a higher level
> > > implementation, using powerful tools.
> > >
> > > Erik
> > >
> > No.  I don't think so.
> > 
> > The current implementation does it; not the current parser. If we
> > go back to the compilation/execution analogy, some error conditions
> > are detected at run time; not at compile time.
> 
> There is no compile time. Both the current and future parsers are
> interpreters only, AIUI.
> 
> > I don't see how the parser can require that G1 has an Fn clause
> > defined on the same or some previously executed line.
> 
> Nor can I. It doesn't. AIUI, gcode executes with whatever value of
> that modaility is current. It does that now, and any new interpreter
> easily does the same. The grammar then _permits_ an Fn clause where
> we choose.
> 
> > The parser knows nothing about execution order; only about lexical
(Continue reading)

Permalink | Reply | 4 comments |
headers
andy pugh | 1 Feb 09:13
Picon

Re: Archived discussion of IRC link - broken

On 1 February 2012 05:24, BRIAN GLACKIN <glackin.brian@...> wrote:

> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/
>
> and results in
> Not Found

I don't think that the IRC archive has worked for quite a long time.
There are a couple of private chatbots archiving the IRC, but I am not
sure if it is appropriate for the LinuxCNC website to link to them.
(That hands an implicit responsibility to the 'bot owners which might
not be fair)
Try: http://psha.org.ru/irc/

--

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
Permalink | Reply | 0 comments |
headers
Erik Christiansen | 1 Feb 09:23
Favicon

Re: rs274ngc bison/flex parser

On 01.02.12 00:05, Michael Haberler wrote:
> ok, while this wonderful discussion was raging on, I built a working
> parser for the current linuxcnc dialect, as an experiment in
> feasability (this is NOT an end-user tool!) 

It would take all the fun out of it, if it were. :-)

Before using the debug facilities to look at any of the 34 conflicts, I've
so far just glanced at the lexer and parser. On the first scan of the
latter, two things strike me, one significant, and one just a matter of
clarity.

(1)
The grammar specifies expression and control flow constructs, but seems
100% devoid of any explicit gcode grammar. I've scrolled up and down
twice now, but still can't see any rapids, moves, feedrates, or
toolchanges. Nuffin!

It seems that any gcode intelligence, which would enable it to parse the
"current linuxcnc dialect", is yet to be added.

Confirming the growing suspicion, I found only this:

block:
      word
   |  block word
      ;

word:
      letter  optional_value
(Continue reading)

Permalink | Reply | 8 comments |

Gmane