Re: [CAD_CAM_EDM_DRO] EMC's Conversation w/ Motion Controllers

jackw19x wrote:

>What's the nature of the conversation between EMC and a servo motion
>control card? Can EMC be reasonably viewed as a black box with g-code
>and encoder signals going in and strings on some alphabet going out
>to a motion control card?
>

No, not really. This is where the computer hits the 'real world'. Let
me describe what EMC does
for Servo-to-Go, or my PPMC card set. At a certain level, they are
almost identical. A timer
on the motherboard causes a servo update program to be executed as a
real-time process.
The RS-274D interpreter has given a list of moves to the trajectory
planner, which converts
it to axis positions and velocities for an integral sub-multiple of the
servo cycles, such as every
5th one. The servo routines interpolate linearly between these
trajectory points. Every servo
cycle, the first thing done is to read the real position from the
encoder counters. Actual
velocity is computed from the last sample, and position error is
computed by the difference
between desired position from the interpolation mentioned above, and
then a new velocity
is computed from this info and the P,I,D and FF<0..2> terms specified
for that axis in the
setup file. This new velocity is sent to Digital to Analog Converters,
which command the
motors to turn at that velocity.

> But what alphabet and what strings?
>

So, there is not an exact mapping from the G-code to the commands to the
servo card, because
the system must respond to the external world's perturbations. When the
cutting tool digs into
the workpiece, the machine slows down, and the servo amps need to
deliver more power to keep
it moving at the desired rate. Good servo amps have very tight control
on velocity, but the gain
is still finite, and so the servo routines will see some slowdown, and
have to command higher
velocity to compensate for the servo amp's finite gain.

> What
>kind of interface exists between EMC and the controller?
>

Basically, there is a set of common routines in a "wrapper" C code that
handles the classic
functions, such as initialize encoders, initialize DACs, read position,
write DAC and such.
These C functions only call the hardware-specific C functions that do
the work on the
specific hardware. So, you just slip the right wrapper routine into the
list of files to be
linked, and it hooks the hardware-specific code to the
hardware-independant caller.

> I suppose
>different controllers accept different sets of commands, so EMC must
>have a place where interface code can be grafted on--right?
>
>

Well, the fine details are different, but the major function to be
performed is pretty common,
so it makes this easier.

Jon