Re:AHA vs. EMC

Jon Elson <jmelson@...>
Subject: Re: Re:AHA vs. EMC

ballendo@... wrote:

> Andrew Wrote:
>
> >[What I'm looking for is a controller that will handle those huge
> >files full of little bitty line segments that 3d g-code generators
> >put out. As was mentioned recently, these are a challenge for many
> >controllers. I've heard that EMC is not too great at this constant
> >contouring stuff either.
> >(Is this being addressed in the upcoming versions?)
>
> Yes. and no. Read my previous posts. (Capability is there,
> implementation is yet undone.)

I believe the function IS, indeed there, but it may take a lot of CPU
horsepower
to up the block processing rate. It might be worth digging into the
code to see
if there are any obvious inefficiencies that could be reduced. I think
you can get
about 20 blocks/sec with a 100 MHz pentium. How much do you need?

[I'm not sure, but I don't want to see those nasty "dwell" marks on my
parts, and I like seeing the machine zipping, rather than plodding along.]

if the code is producing scads of .0001" vectors, the machine may not be
following that with as much precision as it specifies, anyway. You
might set
the program that produces all that data to make slightly coarser steps
without
really losing anything.

[I'm not sure how I'd do that- DeskProto is fairly automatic and I haven't
seen anyplace where it allows you to degrade the quality. But it isn't
calling for increments that small- thousandths seem to be the minimum
difference.]

I'm not totally clear on how this all works, but it may be that holding
the
trajectory planner at 100 Hz may be part of the bottleneck. You might
time it with a sample program, and then change the cycle time parameter
in the [traj] section and see if this makes a difference.

> > I don't need a lot of odd g-codes- most of what I use is G00, but
> >smooth execution of many small moves is crucial.
>
> Hope you use some g01 also. Boy, you REALLY DO want as much speed as
> you can get!! :)

Hmm, this may actually be the important point. If he really IS trying
to cut
with G00, that is likely the problem. I suspect blending and lookahead
don't
work on G00, as you are NOT supposed to be cutting with it. That is for

rapid feed between cutting movements.

[Looking at a piece of code, it seems that although there is a G00 command
at the start, the bulk of the program is merely G0 after all. (You can't
blame a guy for hoping.) So far, on my MaxNC, I haven't been using
lookahead anyway- it doesn't work on these large files. I've been running
everything in straight DNC mode, which seems to work okay.]


I can say that I am already mostly satisfied with EMC's performance on
long chains of small moves. Mostly where I see it slow down is with
engraving programs. These programs could make the curves in letters with a
modest
number of small arcs, but it is simpler to do it with a LOT of straight
line segments. (Bobcad seems to do the same with surface contours, but I
wasn't demanding really smooth curves on the stuff I've done so far with
it.)

Jon

[Thanks Jon, I wasn't complaining about EMC's performance, since I haven't
actually tried it yet (still waiting for the totally 100% brain-dead
install and configure CD for linux-phobes.) I'm mainly trying to figure out
the best (and easiest ) controller for this sort of thing, and reacting to
certain rumors on EMC's weak spots.. EMC's still in the running, since I
really want to rig some kind of closed-loop system, and most of the ones
I've seen are open-loop.]

Andrew
http://www.computersculpture.com


Andrew Werby - United Artworks
Sculpture, Jewelry, and Other Art Stuff
http://unitedartworks.com