Re: [CAD_CAM_EDM_DRO] Re:AHA vs. EMC
Posted by
Jon Elson
on 2000-09-09 23:26:05 UTC
ballendo@... wrote:
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?
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 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.
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.
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
> Andrew Wrote:I believe the function IS, indeed there, but it may take a lot of CPU
>
> >[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.)
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?
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 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, butHmm, this may actually be the important point. If he really IS trying
> >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!! :)
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.
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