This is a mirror of an older page describing some of EMC's internals.
It refers to the specifics of emc1, yet some of it also applies to the ways it's done in emc2. One day someone might have enough good will to update the graphics, descriptions for the current code.
Over the last few weeks there has been a long discussion on the EMC mailing list about a hardware project that would work with EMC. During the discussion, I realized that we needed a more detailed block diagram that shows the internal operation of the EMC program.
I set up this site as a place for the diagram, at least until it is finished. Once it is complete, I hope that it can be included in the EMC handbook.
As soon as I started to draw, I realized that a single block diagram isn't enough. The EMC is complex enough that you need to look at it at several levels to understand it. As a result, this site will start with a top level view of the EMC, then dig down into the details of how it actually works.
This is very much a work in progress. I'll probably be revising and adding drawings every few days, as I learn more about the internals of EMC, and as other people point out my mistakes. I am looking for corrections and details from anyone who can contribute. I am especially interested in input from the original developers. By myself, the best I will be able to do is document those sections of the code that I manage to understand after much study. I'd like to achieve more than that...
Please send comments and corrections to the EMC mailing list.
A note about the drawings:
Most of the drawings on the site are quite detailed, and are intended to fit on an 8-1/2 x 11 inch page. They were done using the drafting tool EasyCad. Then they were printed to postscript files, and GhostScript was used to convert them to high and low resolution bitmaps. The low-res bitmaps show up in the HTML page. They are only about 50-75 dpi, so small text and details will be unreadable. But they are small, <10K, so they load fast and give you an idea of what the drawing looks like. If you click on a low-res image, you will get the high-res version, which is at 300 dpi. Depending on your browser, you should then be able to pan around the drawing to see the whole thing, save it, and/or print it. Line drawings compress well - even the 300dpi image is usually under 100K. I assume the handbook would use the postscript versions of the drawings.
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.
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.
Motion Controller EMCMOT
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.
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.
Discrete I/O Controller EMCIOThe 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.
Task Executor EMCTASKThe 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.
Graphical User InterfacesIndicated 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.
Detailed Control DiagramsThe 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.
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.
|< Предыдущая||Следующая >|