Re: Re: EMC capability was Re: OK - you convinced me
Posted by
Ray
on 2000-10-07 08:19:14 UTC
Ballendo
You liked the opening I gave you. I thought a caveat might be something
I'd hang in front of the mule's nose to get it to take me to the feed mill.
very small cuts at very high speeds. The EMC's snail-pace when it
interprets blocks of gcode would stretch the making of a complex mold
from a few weeks to a few months.
one of my early gui's (graphical user interface) I built in a routine that
kept track of the currently executing line of code so that if you
pressed abort or e-stop it would pop up the gcode with the aborted line
highlighted. Arrow buttons would let you move back or ahead in the
program to the place you wanted to restart. One of these days, if someone
hangs a caveat in front of this old mule's nose, I'll get that into tkemc.
quite doing what it should.
jump around in the gcode like you think it should.
documentation of each of the interpreters led me to conclude that NIST
was pretty determined to find the most commonly accepted features of RS274
and include them. For the casual observer here, I need to remind us that
the RS in that "standard" means recommended standard. As several have
pointed to, each control uses its own version of RS274 and would like you
to think that it is the "real" standard.
you do and suggest that as you read the reports of these NIST folk, you
feel some of the frustration of a computer programmer who is accustomed to
a wide variety of relatively high level language features in both semantics
and syntax trying to force themselves to use the extremely limited RS274
language to tell a control/machine what to do. They are looking through
the computer at the problem.
From the other extreme view, looking through the old machinists wooden
tool box with all of the one-of-a-kind ground HSS tools, the RS274 took on
a lot of needless frills when those "damnable basic programmers" started
insisting on do loops and goto's. If you had the right shaped tool all you
had to do was get it to the right place at the right speed.
ever get all the way there. The target is racing toward the event
horizon faster than any of us can keep up. That is why I like an "open
source" controller project like EMC so much better than a proprietary
system. As you said:
While working on tkbackplot, I got far enough to post an alpha tgz with a
note that 3d had not been implemented 'cause i couldn't figure out the
math at 2 am my time. Well within a couple hours Paul Corner (my time +
at least 5) posted the correct lines of code to fit in my release. I
don't think either of us was trying to make a proprietary killing on our
work. We saw a feature that needed to be there. Sure Mazak and many
others had similar features first. But hey! It's always a moving target.
So my conclusion is. It you want it and the company hype says it's in
there already, buy it. Nobody is doing the same kind of hype for the EMC
so you'll just have to investigate the latest features like a thermocouple
to adjust size. And my though is that if it's not there write it and
put it in.
Ray
You liked the opening I gave you. I thought a caveat might be something
I'd hang in front of the mule's nose to get it to take me to the feed mill.
> Message: 13You are being generous. It is true that big mold making machines take
> Date: Fri, 06 Oct 2000 23:09:54 -0000
> From: ballendo@...
> Ray,
>
> Short for Caveat Emptor, Latin for "let him beware"
> Usual modern context is "Let the buyer beware"
>
> So a caveat is something to be aware of.
> Having said that, it appears I should be more aware of my own posts!
>
> >I know of several who use the EMC for engraving and find that 25+
> >blocks per second is enough for most homebrew setups. In fact you
> >can watch it engrave a virtual copy of the intelligent systems
> >division logo by calling up isd.ngc and run it with backplot
> >showing. With sim or stepper definitions you can set whatever
> >engraving speed you think you want and see just how well it does.
>
> I get into trouble whenever I mention this in a predominately
> machinist environment. If we are engraving small letters(or a 3d
> mold), then lines/arcs of .005 to .010 are reasonable to assume. At
> 25 blocks/second, this is a MAX speed of .25/second or 15IPM! (inches
> per minute) With .060!! line lengths, we're still only 1.5IPS or
> 90IPM. While this second example is in the lower range for most
> commercial engravers, it's still pretty slow. And .060 lines will
> look pretty bad on .25 letters!
>
> I do agree that it's CURRENTLY workable, but it's not where it needs
> to be, and Fred P. agrees! (Fred is the lead man on the NIST EMC
> programming team, for those who don't know. While we're here, I
> should say Ray(of this post) is/has been PRETTY important to the EMC)
very small cuts at very high speeds. The EMC's snail-pace when it
interprets blocks of gcode would stretch the making of a complex mold
from a few weeks to a few months.
> >> -2. The gcode program is not pre-processed, so jumps forwardYes, I suppose the restart is clunky compared to some modern controls. On
> >>and back, (broken tool)re-start, and subroutines, loops, and
> >>parametric programs are difficult to impossible.
>
> >a- The EMC will restart after a broken tool on any line that you
> >choose.
>
> Thanks, I didn't know that. On re-read, I think I DID know that.
> Is/WAS it a clunky process?
one of my early gui's (graphical user interface) I built in a routine that
kept track of the currently executing line of code so that if you
pressed abort or e-stop it would pop up the gcode with the aborted line
highlighted. Arrow buttons would let you move back or ahead in the
program to the place you wanted to restart. One of these days, if someone
hangs a caveat in front of this old mule's nose, I'll get that into tkemc.
> >b- I don't quite know what you mean by gcode being broken. ItYour earlier post made it sound like you thought the interpreter was not
> >seems to work for me just the way the handbook and the nist
> >supplement says that it should. If you mean that subroutines,
> >loops, and parametric programs should be a part of any gcode, I
> >guess you're entitled to your opinion although you ought to read the
> >analysis of RS274 by Tom Kramer etal again.
>
> Not sure what you're referring to here, I looked through the back
> posts? Could you clarify the "Gcode broken" part for me?
quite doing what it should.
> -2. The gcode program is not pre-processed, so jumps forward andIn fact the problems that you mention seem to indicate that it doesn't
> back,
jump around in the gcode like you think it should.
> I've read and re-read nearly everything Tom K. has written. WhichThe comments within the c, c++ code and many of the comments in the
> "analysis" do you speak of?
documentation of each of the interpreters led me to conclude that NIST
was pretty determined to find the most commonly accepted features of RS274
and include them. For the casual observer here, I need to remind us that
the RS in that "standard" means recommended standard. As several have
pointed to, each control uses its own version of RS274 and would like you
to think that it is the "real" standard.
> No, I don't believe any dialect of gcode "should" contain anyYes, and perhaps it's a point-of-view problem. I'll go even further than
> SPECIFIC capabilities. However, I do believe that we should learn
> from our past, and as an example, the use of 38.2 for general probing
> (and not related to tool setup)is a poor choice when nearly every
> commercial mfr uses G31 for "skip function" and general probe usage.
>
> EMC is based on an old A/B (allen bradley) dialect. Other dialects
> have become more prominent and universal in the ensuing years. I do
> think EMC has an important responsibility to the future, and NOT the
> past. They "could" be unifying the code usage, instead of "preserving
> the diversity" out of some reliance on an old (poorly written, in
> Tom K's opinion, and I second it!) defining paper! (the NCMS paper,
> FYI)
you do and suggest that as you read the reports of these NIST folk, you
feel some of the frustration of a computer programmer who is accustomed to
a wide variety of relatively high level language features in both semantics
and syntax trying to force themselves to use the extremely limited RS274
language to tell a control/machine what to do. They are looking through
the computer at the problem.
From the other extreme view, looking through the old machinists wooden
tool box with all of the one-of-a-kind ground HSS tools, the RS274 took on
a lot of needless frills when those "damnable basic programmers" started
insisting on do loops and goto's. If you had the right shaped tool all you
had to do was get it to the right place at the right speed.
> I knew this. It's the combination of these params with boolean andNow I'm back to caveats hanging fron a string. I don't think that you
> subs and loops that REALLY gets us ALL THE WAY there. I know we will,
> but we're still working on it.
ever get all the way there. The target is racing toward the event
horizon faster than any of us can keep up. That is why I like an "open
source" controller project like EMC so much better than a proprietary
system. As you said:
> As I have said OFTEN in my posts, 1.It depends on what you're doing,Let me illustrate with a real example from a recent open source event.
> and, 2. This field is a MOVING target.
While working on tkbackplot, I got far enough to post an alpha tgz with a
note that 3d had not been implemented 'cause i couldn't figure out the
math at 2 am my time. Well within a couple hours Paul Corner (my time +
at least 5) posted the correct lines of code to fit in my release. I
don't think either of us was trying to make a proprietary killing on our
work. We saw a feature that needed to be there. Sure Mazak and many
others had similar features first. But hey! It's always a moving target.
So my conclusion is. It you want it and the company hype says it's in
there already, buy it. Nobody is doing the same kind of hype for the EMC
so you'll just have to investigate the latest features like a thermocouple
to adjust size. And my though is that if it's not there write it and
put it in.
Ray