Re: Re: EMC capability

>Ray wrote:

><snip>It is true that big mold making machines take 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.

It's not just the hi-end machines that can do this! I mentioned
commercial engraving machines($15K); Wood routers also run 2-500IPM.

IMO, some of the problems with the currently available S/W based cnc
controls, is they don't take these "other" users into account. To a
machinist,80ipm may be "movin", but to a woodworker or engraver, that
would be "barely movin'". (Yes, I realize you aluminum guys are way
beyond this, but the MINDSET still seems to be, as long as its movin
by computer control, they'll be pleased with whatever speed they can
get.)(actually the WHOLE commercial machining world is moving much
faster "can you say steel at 300IPM!!!" , It's the pervasive
"mindset" to which I speak.)

IMO, part of the "snail pace" of EMC is the "huge" amount of error
checking put into the interpreter. By itself, this is a good thing.
If I were going to use EMC exclusively, I'd take out nearly ALL the
error-checking from my RUN-TIME interpreter, and check all toolpaths
with the version of the interpreter currently used in both places.

This would be no different than turning off the feed/speed overrides
once a program is "proved-out". If its ck'd out OK, then let's make
chips!

>One of these days, if someone hangs a caveat in front of this old
>mule's nose, I'll get that into tkemc.

And we'll all benefit when you do. :-)

>Your earlier post made it sound like you thought the interpreter was
>not quite doing what it should.

Only in so far as the error check'g mentioned above, and the reliance
on outdated info (NCMS,again!) to make CURRENT decisions re:
implementation of/for EMC.

>In fact the problems that you mention seem to indicate that it
>doesn't jump around in the gcode like you think it should.

The interpreter(as YOU already know) doesn't(didn't??) read the file
into an array (or other structure) so that these jumps become trivial
and quick.

>The comments within the c, c++ code and many of the comments in the
>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.

Mostly agreed. Fred, Will, and Tom are doing a great job! However,my
conversations with the NIST folk have been, "well you make a good
point, but we've already done it this way. And, If we followed each
persons advice, we'd never get anything resolved."

Ok, I can accept the truth of this. BUT, they've adopted as their
LITMUS test, an OLD, VERY POORLY written, Nowadays UNSTANDARD, spec!
With the potential EMC has, we will be relying on the choices made
now for a LONG time!

>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.

<snip>They are looking through the computer at the problem.

EXACTLY Right! And they're NOT alone. I have worked with a number of
programmers (of CNCcontrol, not the gcode) over the years, and it's
like pulling teeth to get them past this!

Whether or not a person chooses to accept the quality of the current
state of things, there IS a CURRENT set of CONVENTIONS which should
be referred to and addressed by responsible programmers. E.G., no
matter how you FEEL about MS, or WINxx, you BETTER be willing to work
with, or around, them. They ARE the common denominator, for better,
or worse. Same thing exists in CNC, but many seem to ignore, or are
unaware of it.

><snip>If you had the right shaped tool all you had to do was get it
>to the right place at the right speed.

All these control "features" are just another way of GETTING the
right shaped tool.

>Now I'm back to caveats hanging fron a string. I don't think that
>you 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.

Agreed. I too, like the "open source" the world is moving to. Look at
this list! Ten years ago, putting this much experience in one room
would be next to impossible. It's a great time to be alive!

>And my thought is that if it's not there write it and put it in.

You have the advantage of having(or having developed) the ability to
do this. The point I make is that, we who don't, or can't, must rely
on others who can. If those who "can" are not listening, or disagree,
then we're stuck. (Ray,like you, I'm in the "those who can" camp, but
we mustn't forget that, at present, we are the minority, at least
re:CNC)

My family is begging me to Go! (birthday party)
Bye for now.
Ballendo