EMC capability was Re: OK - you convinced me

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)

>> -2. The gcode program is not pre-processed, so jumps forward
>>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?

>b- I don't quite know what you mean by gcode being broken. It
>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?

I've read and re-read nearly everything Tom K. has written. Which
"analysis" do you speak of?

No, I don't believe any dialect of gcode "should" contain any
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)

>Conditional part program execution using boolian operators is
>implemented.

Thank you again. I didn't know that either.

>c- As for subroutines and loops, both Burt Eding and I have written
>wrapper programs that will get you some of those capabilities.
>Mine is under the scripts menu of the standard tkemc. We are
>working on Burt's to give it a friendlier front end.

>I am not sure quite what you mean by parametric programming but
>5000+ parameters can be<snip>.

I knew this. It's the combination of these params with boolean and
subs and loops that REALLY gets us ALL THE WAY there. I know we will,
but we're still working on it.


As I have said OFTEN in my posts, 1.It depends on what you're doing,
and, 2. This field is a MOVING target. I like EMC and have great
hopes for its' future. I keep telling people, keep your eye on it!
I've been pretty busy in some other areas and haven't kept up
recently. I'll try to do a better job of keeping up with the
improvements. Or keep my mouth shut :-)
Thanks for the info.


Ballendo (AM re-posting the below paragraph, seems even more
pertinent now)

'*******************************************************************
PERSONALLY, I find something to LOVE(and something to HATE) in nearly
all the CNC controls I've ever used. So I use a number of them
(depends on what I'm doin'). Works for me, but others have more
success REALLY learning the ins and outs of ONE program.