EMC Software

Introduction

As part of our collaboration with the OMAC User's Group, we have written software which implements real-time control of equipment such as machine tools, robots, and coordinate measuring machines. The goal of this software development is twofold: first, to provide complete software implementations of all OMAC modules for the purpose of validating application programming interfaces; and second, to provide a vehicle for the transfer of control technology to small- and medium-sized manufacturers via the NIST Manufacturing Extension Partnership.

The EMC software is based on the NIST Real-time Control System (RCS) Methodology, and is programmed using the NIST RCS Library. The RCS Library eases the porting of controller code to a variety of Unix and Microsoft platforms, providing a neutral application programming interface (API) to operating system resources such as shared memory, semaphores, and timers. The RCS Library also implements a communication model, the Neutral Manufacturing Language, which allows control processes to read and write C++ data structures throughout a single homogeneous environment or a heterogeneous networked environment.

The EMC software is written in C and C++, and has been ported to the Sun Solaris and PC Linux operating systems. When running actual equipment, a real-time version of Linux is used to achieve the deterministic computation rates required (200 microseconds is typical). The software can also be run entirely in simulation, down to simulations of the machine motors. This enables entire factories of EMC machines to be set up and run in a computer integrated manufacturing environment.

The EMC software is available free of charge on our FTP site. Please read the README file before getting or installing the software.

This software was prepared by United States Government employees as part of their official duties and is, therefore, a work of the U.S. Government and not subject to copyright.

The EMC at Work

We have installed EMCs on several machines. All use servo motors with incremental encoder feedback. Stepper motor support is in progress. Here is a sampling:

3-axis Bridgeport knee mill at Shaver Engineering. The machine uses DC brush servo motors and encoders for motion control, and OPTO-22 compatible I/O interfaced to the PC parallel port for digital I/O to the spindle, coolant, lube, and estop systems.
3-axis desktop milling machine used for prototype development. The machine uses DC brush servo motors and encoders. Spindle control is accomplished using the 4th motion control axis. The machine cuts wax parts.
4-axis Kearney & Trecker horizontal machining center at General Motors Powertrain in Pontiac, MI. This machine ran a precursor to the full-software EMC which used a hardware motion control board.

EMC Components

There are four components to the EMC software: a motion controller (EMCMOT), a discrete I/O controller (EMCIO), a task executor which coordinates them (EMCTASK), and a collection of text-based or graphical user interfaces (EMCPANEL, EMCGUI).

Motion Controller EMCMOT

The motion controller (Figure 1) is written in C for maximum portability to real-time operating systems. Motion control includes sampling the position of the axes to be controlled, computing the next point on the trajectory, interpolating between these trajectory points, computing an output to the motors based on a PID compensation algorithm, and writing to the motors. The motion controller includes programmable software limits, interfaces to hardware limit and home switches, PID servo compensation with zero, first, and second order feedforward, maximum following error, selectable velocity and acceleration values, individual axis jogging (continuous, incremental, absolute), queued blended moves for linear and generalized circular motion, and programmable forward and inverse kinematics.

The motion controller is written to be fairly generic. Initialization files (with the same syntax as Microsoft Windows INI files) are used to configure parameters such as number and type of axes (e.g., linear or rotary), scale factors between feedback devices (e.g., encoder counts) and axis units (e.g., millimeters), servo gains, servo and trajectory planning cycle times, and other system parameters. Complex kinematics for robots can be coded in C according to a prescribed function interface and linked in to replace the default 3-axis Cartesian machine kinematics routines. A C language application programming interface (API) between the motion controller and the external world is provided so that specific hardware can be integrated into the EMC without modifying any of the core control code. Programmers must implement these API functions for each board.

Figure 1. Motion controller software architecture. The motion controller is a single C program, executing cyclically. When controlling actual machines, the motion controller requires a real-time operating system. In our installations, we have used RT-Linux. This gives real-time deterministic cycle times down to about 100 microseconds. The motion controller uses either shared memory or RT-Linux FIFOs to receive commands or send status, error, or logging information. NML is not used directly by the motion controller since NML requires C++ and the coding was limited to C to maximize portability to other real-time operating systems.


Discrete I/O Controller EMCIO

The discrete I/O controller (bottom right in Figure 2) is written in C++, using the NIST RCS Library. It is based on a hierarchy of C++ controller classes derived from the NML_MODULE base class, each communicating using NML. Discrete I/O controllers are highly machine-specific, and are not customizable in general using the INI file technique used to configure the more generic motion controller.

A C language application programming interface (API) between the discrete I/O controller and the external world is provided so that specific hardware can be integrated into the EMC without modifying any of the core control code. Programmers must implement these API functions for each board.

Task Executor EMCTASK

The Task Executor (at the top in Figure 2) is coded similarly to the discrete I/O controller, using the NML_MODULE base class and the RCS Library. It is less machine specific than the discrete I/O controller, as it is responsible for interpreting G and M code programs whose behavior does not vary appreciably between machines.

External Programs

Indicated at the very top in Figure 2 is the fourth component of the EMC software, the external programs such as the graphical user interface (GUI) or flexible manufacturing system (FMS) which are used to run the EMC. These communicate using NML, sending messages such as power on, enter automatic mode, run a program, or power down. GUIs may send manual commands initiated by the operator, for example jogging machine axes in manual mode, or homing each axis.

Figure 2. EMC controller software architecture. At the coarsest level, the EMC is a hierarchy of three controllers: the Numerical Control Executive (NCE), the motion controller, and the discrete I/O controller. The motion controller is detailed in Figure 1. The discrete I/O controller is implemented as a hierarchy of controllers, in this case for spindle, coolant, and auxiliary (e.g., estop, lube) subsystems. The Numerical Control Executor (NCE) coordinates the actions of the motion and discrete I/O controllers. Their actions are programmed in conventional numerical control "G and M code" programs, which are interpreted by the NCE into NML messages and sent to either the motion or discrete I/O controllers at the appropriate times.


Configuring the EMC

The EMC is configured with files that are read at startup and used to override the compiled defaults. No real controller will likely use the compiled defaults, so you will certainly need to edit at least some of these files to reflect the specifics of your machine.

There are four files: emc.ini, emc.nml, tool.tbl, and rs274ngc.var. The first, emc.ini, contains all the machine parameters such as servo gains, scale factors, cycle times, units, etc. and will certainly need to be edited. emc.nml contains communication settings for shared memory and network ports you may need to override on your system, although it is likely that you can leave these settings alone. tool.tbl contains the tool information such as which pocket contains which tool, and the length and diameter for each tool. rs274ngc.var contains variables specific to the RS-274-NGC dialect of NC code, notably for setting the persistent numeric variables for the nine work coordinate systems. The specific formats of each of these files is detailed in the following sections.

Machine Configuration file emc.ini

The machine configuration file emc.ini follows the Microsoft INI file format, in which values are associated with keywords on single lines, perhaps in sections denoted with square brackets, e.g.,
[SECTION]

; COMMENT
SYMBOL = VALUE
Everything from the first non-whitespace character after the = up to the end of the line is passed as the value, so you can embed spaces in string symbols if you want to.

You can edit the values for each keyword in any text editor. The changes won't take effect until the next time the controller is run. The file should be called emc.ini, but the name can be overriden using a command line argument to the controllers. See the section "Starting Up" for information on how to do this. The following sections detail each section of the configuration file, using sample values for the configuration lines.

[EMC] Section

The [EMC] section contains general parameters for the whole controller. These are:

[TASK] Section

The [TASK] section contains general parameters for EMCTASK, which includes primarily the NC language interpreter and the sequencing logic for sending commands to EMCMOT and EMCIO.

[TRAJ] Section

The [TRAJ] section contains general parameters for the trajectory planning module in EMCMOT.

[AXIS_#] Sections

The [AXIS_0], [AXIS_1], etc. sections contains general parameters for the individual axis control modules in EMCMOT. The axis section names begin numbering at 0, and run through the number of axes specified in the [TRAJ] AXES entry minus 1. The following parameters P, I, D, FF0, FF1, FF2 are used by the servo compensation algorithm to optimize performance while tracking trajectory setpoints. See Tuning Servos for information on setting up a servomotor system. The following polarity values determine how inputs are interpreted and how outputs are applied. They can usually be set via trial-and-error since there are only two possibilities. The EMCMOT utility program USRMOT can be used to set these interactively and verify their results so that the proper values can be put in the INI file with a minimum of trouble. The following entries are used to set the parameters for the DC servomotor simulations. These are only used when running the EMC in simulation. The following entry is used to set the parameters for the amplifier simulations. These are only used when running the EMC in simulation. The following entry is used to set the parameters for the encoder simulations. These are only used when running the EMC in simulation.

[EMCIO] Section

The [EMCIO] section contains control values and setup parameters for the digital and analog I/O points in EMCIO.

The following entries set general parameters for the I/O controller.

The following entries set parameters for spindle control. The following entries set the bit indices for the digital I/O so that the controller knows the mapping to I/O point wiring. The indices start at 0 for the least significant bit in the digital I/O map. See Setting up the External Interfaces for information on interfacing I/O boards to the software. The following entries set the polarities for the digital I/O points. These can be set by trial-and-error, or by noting the levels and any inverting done by the electronics between the sensors and actuators and the electronics.

Using the USRMOT Motion Utility

USRMOT is an interactive text-based utility that is used to set and test motion parameters for the EMCMOT motion controller. To use USRMOT, first run EMCMOT standalone (yourprompt> represents whatever your system prompt is):
yourprompt> emcmot
In another window, run the USRMOT utility:
yourprompt> usrmot
motion>
The motion> prompt is displayed by USRMOT when it runs. Entering a blank line lets you see the status:
motion> 
mode:           free
cmd echo:       0
split:          0
heartbeat:      605
compute time:   0.014992
traj time:      0.200000
servo time:     0.020000
interp rate:    10
axes enabled:   0               0               0
cmd pos:        0.000000        0.000000        0.000000
act pos:        0.000000        0.000000        0.000000
velocity:       10.000000
accel:          100.000000
id:             0
depth:          0
active depth:   0
inpos:          1
vscales:        Q: 1.00 X: 1.00 Y: 1.00 Z: 1.00
logging:        closed and stopped, size 0, skipping 0, type 0
homing:         ---
enabled:        DISABLED

Tuning Servos

For a detailed description of tuning servos, see the following references:
  1. Benjamin C. Kuo, Automatic Control Systems, Fourth Edition.

Defining Complex Kinematics

By default the EMC assumes trivial Cartesian kinematics in which X, Y, and Z coordinates map directly to motors 0, 1, and 2. You can define more complex kinematics, for example for a robot, by replacing the default kinematics functions with your own.

The C language declaration for the kinematics, found in emcmot.h, is

#include "posemath.h" /* PmPose */ extern int forwardKinematics(double * joints, PmPose * pos); extern int inverseKinematics(PmPose pos, double * joints);
You can replace these with any kinematics you like, provided they conform to these declarations. Replace the file trivkins.o from the link line that builds emcmot with your own, and rerun the compiler.

Setting up the External Interfaces

The interface between motion control and discrete I/O control points and the software is declared in the C language header file extintf.h.

For example, one of the external APIs is

/*
  extDacWrite(int dac, double volts)

  writes the value to the DAC at indicated dac, 0 .. max DAC - 1. 
  Value is in volts. Returns 0 if OK, -1 if dac is out of range.
  */
extern int extDacWrite(int axis, double voltage);
which is called by the motion controller to output a voltage to the motor velocity amplifiers. For a particular digital-to-analog converter board, the function would be implemented as something like:
/* specific function to output voltage for my board */
int myBoardDacWrite(int axis, double voltage)
{
  short int vout;

  vout = (short int) (voltage / 10.0 * 0xFFFF);

  _outw(0x280 + axis, vout);

  return 0;
}

/* mapping of my function to API */
int extDacWrite(int axis, double voltage)
{
  return myboardDacWrite(axis, voltage);
}
Another external API is
/* reads value of digital input at index, stores in value */
extern int extDioRead(int index, int *value);
which is called by the discrete I/O controller to read a digital input into the 'value' variable, from the I/O point at the specified 'index'. For a particular digital I/O board, the function would be implemented as something like:
/* specific function to input value from myboard */
int myBoardDioRead(int index, int *value)
{
  unsigned char mask;

  mask = 1 << index % 8;

  *value = (_inb(0x380 + index / 8) & mask) ? 1 : 0;

  return 0;
}

/* mapping of my function to API */
int extDioRead(int index, int *value)
{
  return myboardDioRead(index, value);
}
The code above is referred to as a "wrapper" for myboard. NIST has written wrappers for some specific boards. See Wrapped Hardware for more information.

Starting Up

The EMC can be started up by scripts, which take command line arguments for the various files if their names are to be overriden. The scripts should be run in the directory in which the configuration file are located, unless they are overriden with paths to alternate files. The conventional practice is to create a script file called run.emc based on one of the example run scripts, and run it in the top-level emc directory where the configuration files emc.ini and emc.nml are located. The syntax is:
./run.sunos5

Control Platforms

From the point of view of technology transfer, the EMC has strived to provide software which is of high performance yet can be run on inexpensive computing platforms. The target platform for control is a PC-compatible desktop computer, 386-compatible or higher, with a minimum of additional hardware. We have ported our software to the Linux operating system, since it is free and has free real-time support from New Mexico Tech. We also run in simulation on most Unixes, and Microsoft Windows NT. The following are some links to related Web sites.

No approval or endorsement of any commercial product by the National Institute of Standards and Technology is intended or implied. Certain commercial equipment, instruments, or materials are identified in this report in order to facilitate understanding. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

PC Hardware

These links provide information on PC-compatible hardware in general. Go here for technical specs, pinouts, I/O addresses and register bitmaps, etc.

Linux Documentation

There is a world of free information on Linux, the free Unix-like operating system for 'most any platform. You can get it for PCs, Macintoshes, Sparc workstations, notebook computers, and more.

Linux Software

Third parties provide shrink-wrapped Linux packages which save you the trouble of ftp-ing 20 megabytes of code from Finland over your 28.8 kbps modem overnight. You can also find lots of free software for Linux.

Real-time Linux

Michael Barabanov and Victor Yodaiken of New Mexico Tech modified the Linux source slightly, inserting a real-time scheduler between Linux and the hardware interrupts it used to receive. Now, your code can run in the scheduler, with Linux running when you're done. Tasks can run at cycle times down to about 50 microseconds or so. That's 20 kilohertz in real-time on your desktop PC.

Programming Linux

Information on accessing hardware or operating system resources not covered in general C language textbooks.

Windows NT

The EMC software can run on Windows NT, although not in real time. Here are links for getting free compilers, debuggers, editors, version control software, etc. to run EMC software on NT in simulation for minimal cost.

Windows NT/CE Realtime

With third-party software, you can run code on Windows NT or CE in real time. Here are some places to go for NT/CE real-time information.

Note: the EMC software has not been ported to any of these real-time subsystems, although we are working with some of them. If you'd like to help out, let us know.

Wrapped Hardware

We have written APIs to some hardware for our installations, giving them the functional interface we program to in our EMC code. Here are some of them.