(FIXME: add picture)
Figure 1. EMC controller software architecture. At the coarsest level, the EMC is a hierarchy of three controllers: the task level command handler and program interpreter, the motion controller, and the discrete I/O controller. The motion controller is detailed in Figure 2. 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 task controller 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 task controller into NML messages and sent to either the motion or discrete I/O controllers at the appropriate times.
The motion controller (Figure 2) 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, and computing an output to the motors. For servo systems, the output is based on a PID compensation algorithm. For stepper systems, the calculations run open-loop, and pulses are sent to the steppers based on whether their accumulated position is more than a pulse away from where their commanded position should be. 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.
(FIXME: add picture)
Figure 2. 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. 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. This figure also shows the hardware abstraction layer situated between the MOT and IO tasks and the actual machine hardware.
The discrete I/O controller (bottom right in Figure 1) 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.
The Task Executor (2nd from top in Figure 1) 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.
Indicated at the very top in Figure 1 is the fourth component of the EMC software, the graphical user interface (GUI). The architecture of EMC supports other components instead of the GUI, such as flexible manufacturing systems or remote GUIs. Whatever component is at the top has high level control of the EMC. It communicates 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. The EMC comes with several types of user interfaces: an interactive command-line program emcpanel, a character-based screen graphics program keystick, an X Windows program xemc, a Java-based GUI emcgui, and a Tcl/Tk?-based GUI TkEmc.
TkEmc is most well-supported, and runs on Linux and Microsoft Windows. The Windows version can connect to a real-time EMC running on a Linux machine via a network connection, allowing the monitoring of the machine from a remote location. TkEmc comes with the Linux distribution of the EMC.
The drawing below is a detailed control diagram of a servo loop. This is NOT the EMC servo loop in the previous drawing. I don't know enough yet to create this level of detailed diagram for the EMC code. But thisis the level of documentation I hope to put together.
(FIXME: add picture)
Figure 3. Detailed drawing of the speed and current loops of a typical servo drive.
A nice thing about this type of diagram is that it is independent of the technology used to implement the loops. This drawing could represent an analog drive, or a fully digital servo. All the arrows inside the dashed boxes represent signals. In an analog system, the arrows represent analog signals. In a digital system they are binary numbers. The closed boxes represent functions, such as addition, subtraction, multiplication, limits, integrators, etc. In an analog system, they are of course continuous. In a digital system, each is evaluated once per servo update. Finally, the three-sided boxes represent parameters, used for configuration, tuning, and so on. They are normally constants - although they may be determined from ini files or other data at startup, they don't normally change while the system is running. (Unless you are tuning the loops.)
In my experience working on VFDs, the control design starts with diagrams like these. Once the control is designed and documented to this level of detail, the actual coding is fairly straightforward. I'm afraid it's going to be a little harder working backwards from the code to the diagrams.
circuit schematic of all of emc, showing realtime boundary
here's a smaller zoomable version of figure2, unforch, this wiki wont dispaly it inline upload:emcmot03.svg