Re: EMC and constant contouring

[Fred Proctor <frederick.proctor-at-nist.gov>]

Dan Falck wrote:

> I have been playing with EMC and the CYCLE parameter in the [TRAJ] section
> of emc.ini.  It is set to .010 by default.  I ran an engraving program that
> wasn't optimized and had lots of small line segments (.010" in length, I'm
> not sure).  It ran very rough with CYCLE set at .010.  It had a case of the
> jitters and seemed to have drained the buffer faster than the control could
> feed it.  Then, I changed the CYCLE parameter to 0.005 and it seemed to
> help a lot.   I don't have time to really tweak it tonight, but will play
> with it more over the coming week.

This works up to a point, but there is a basic problem in the EMC motion
controller's blending algorithm that will show rough running. The
problem is that blending between adjacent motion segments (short lines,
in the case of contouring programs) only works when two segments blend
together. For contouring programs, it's possible that more than two
segments will be moved through during the trajectory cycle. That is, for
really small segments and a large feed rate, in one trajectory cycle (10
milliseconds), 3 or more segments may need to be traversed. The problem
can be lessened by reducing the [TRAJ] CYCLE_TIME parameter, up to a
point, as you discovered. Even better would be for us to fix the motion
planner.

Rogier Blom, a guest researcher from the Netherlands who was here last
summer, wrote and improved motion planner and we were able to machine
that MasterCAM race car program in wax pretty nicely. The code for this
is the "segment queue" stuff in emc/src/emcmot. There is still a little
bit of work to be done on this, according to Rogier, so it never made it
into the distribution.

I plan on adding full 6-degree-of-freedom motion planning to the EMC,
and I'll revisit the blending at the same time. In the meantime,
workarounds like Dan's will help up to a point.

--Fred