Re: Re: Re: EMC capability

Let me clarify "snail pace" below for new readers. I used this
referring to the rate at which the EMC interpreter reads blocks of
gcode. It does not refer the the rate-of-change in the fixes/features
that are being added to the EMC code. Or the rate at which the EMC is
taking over the world of cnc;)

> Date: Sat, 07 Oct 2000 20:53:26 -0000
> From: ballendo@...

<s>

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

Let's do it, ballendo. We can start one interpreter stand alone with all
of the error checking stuff intact. The gui would just have to pass the
gcode file to it for verify and to the running machine control for
cutting. I could fix tkemc to do that. Can you fix a copy of the
interpreter?

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

Perhaps we should continue this discussion on the emc@... list 'cause
resetting the interpreter's world view is the slowest part of my
subroutines script.

<s>

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

Yep! But this list is the best place to discuss what an open source CNC
ought to be and do and most all of us have ideas in that department. Many
of the changes to EMC during my experience with it have come from a,
"Wouldn't it be nice if," post or phone call. In fact Fred asked a while
back for volunteers to serve on EMC's steering committees. So the
continuing discussion of CNC features ought to be a part of this list.

Toward the end of summer, someone suggested migrating the NIST CMM code to
create probing in the EMC and this month a first version of it is there.
I've already got two probe switches, one turned upside down to measure
tools. The next suggestion is that we want EMC to read and follow a 3 axis
differential probe like Renishaw builds. This may take a little longer.

With the most of the EMC and RCS stuff on SourceForge now, it is easily
possible for each person with even modest "developer" type skills to
contribute to making the EMC do all of the things we want it to.

Folk without those kinds of code writing skills can test out the latest
revisions to the code. Many of the EMC related problems that come up
here are from these folk and are exactly what the development community
wants to hear about. CAD_CAM... is one of two places where these reports
should be submitted. (emc@...)

Those who apply the EMC to machines can write about their experience and
work on the documents that go along with a project like this. Those who
just want to cut parts can contribute as they develop programming skills,
and troubleshooting experience. By writing these things up in a xecond
Linux window while the machine is running that 20k blocks of gcode file.

And EE's like Jon E. as well as us amateur smoke liberators can and are
working on hardware interface.

With open source projects, its a bit like a 350lb transvestite dressed in
drag -- there's something for everyone.

Now I'll shut off rant and go back to read.

Ray