Machine Design

Motion Control Over The Ethernet

Connecting Ethernet to machine controllers isn't a new idea. But controlling motion over Ethernet is, and this approach may signal the end of machine-mounted motion-control hardware.

By Brain Kapitan
Chief Technologist
Ken Wyman
Vice President Marketing
API Motion Inc.
Amherst, N.Y.

EDITED BY John R. Gyorki

The most common multiaxis motioncontrol cards that plug into a PC's bus slot have been used for many years. And although they are inexpensive and have been quite successful, they have had several shortcomings that limit their expansion into larger systems. For example, they clutter the rear of the PC with numerous wires for I/O connections, and along with daughtercards and connectors, they require more than one slot space.

The new NMAC (Networked Machine Automation Control) architecture from API Motion connects multiple motion controllers to machine-mounted drives through Ethernet networks. This eliminates the problems typical of PC-based plug-in cards that require extensive I/O wiring at the PC, consume PC bus slots which prevents expansion, and use proprietary software.

Because NMAC employs component object models (COMs), they can be created and manipulated by widely used development tools such as Visual C++, Visual Basic, Java, Delphi, and C++ Builder. Moreover, COM objects sit between the users application and the Ethernet network and with its advanced buffering technology, does not require a realtime operating system extension to keep the communications flowing properly and quickly.

Three of the four key ingredients needed for the next generation of motion control are: Ethernet to provide a fast, standardized and reliable network platform; the PC to provide an open, flexible hardware computing platform; and COM technology to provide a powerful, objectoriented software platform. The fourth is an intelligent servodrive such as API Motion's 3400 Series servodrive with Ethernet ports and NMAC software which offers a completely digital, standards-based, motion-control system.

While many professional organizations and companies spent time debating the merits of the various types of industrial field-buses and the best places to put them, Ethernet quietly stepped out of the fray and onto the factory floor. Now it's rapidly securing a position as the de facto standard for industrial automation networks. The number of industrial companies introducing Ethernet-based compatible products is proof that Ethernet is evolving as the industrial network standard. Further emphasizing this is the recent announcement by GE Industrial Systems and Cisco Systems of their joint venture, GE Cisco Industrial Networks. GE Cisco has stated that their "network of choice is Ethernet."

Ethernet is the first major ingredient needed for the next generation of motion-control systems. And the rapidly advancing technology from evolving PCs run a close second. PCs have been irrevocably altering machine-automation topology and motion control. A decade ago, motion controllers in the now-familiar PC plug-in card format began making serious inroads into machine-control architectures. Today, these cards are ubiquitous in industry wherever a general motion-control solution is needed. The reason for their widespread use is simple: They and their host PCs were relatively inexpensive, even in the beginning, compared to alternative stand-alone proprietary systems. But PC-based, plug-in motion-control cards are going away, being replaced by the PC itself. The continual decline in the intervening years of PC hardware costs, even as computing power increased many times, has only increased the use of PC-based motion control. It's inexpensive, standardized, and increasingly powerful PC hardware that gets the nod.

Why not the Motion Control Card?
Why don't multiaxis motion-control cards figure in the next motion-control breakthrough? After all, motion-control cards can provide sophisticated control of motion up to typically eight axes for a reasonable price. They sit in PCs that usually are needed in automation systems, and their cost, while not declining as much as the PC, at least didn't go up, even as their capabilities increased.

They have four problems. First, they require a lot of wiring. Each drive needs several wires for command and status signals. In addition, wiring is usually needed for feedback signals and any I/O controlled by the motion-control card. What's more, the motion-control card, typically with added daughtercards and associated connectors, consumes more than one slot in the PC. The wiring is not only costly in materials and assembly labor, but decreases reliability — the more connections, the more points of potential failure.

Second, someone must learn the programming software. Most motion-control cards are programmed using a computer language, and whether simple or complex, English or Basic-like, they are likely to be proprietary to a vendor, and perhaps even to a specific model of controller. Other vendors' software may be based on derivatives of standard programming languages, but that approach usually requires a seasoned professional software engineer to develop even the simplest motion-control programs.

Third, the number of axes are limited. PC-card motion controllers are typically available for a fixed number of axes only, usually in multiples of four or eight. So, even when only one or two axes of control are needed, the cost includes at least four. Further, these cards are sold in one or more form factors such as ISA, PCI, VME, and PC-104, which raise configuration and compatibility problems, depending on the desired host platform.

Finally, motion-control cards limit access to other intelligent devices on the machine. They don't provide data-oriented communication facilities between the card and motor drives or the discrete I/O they control. This is due to the nature of the architecture of these cards. "Dumb" controlled devices are assumed, and all motion-related intelligence resides on the motion controller. This greatly limits diagnostics, and hampers system setup and commissioning.

The Software Ingredient
Ongoing developments in software, especially in operating systems and standardized, object-oriented programming technology, have provided increasingly powerful, easier-to-use, and more reliable software for industrial and commercial automation systems. Software, in particular Microsoft's COM (Component Object Model), is the third ingredient needed for a breakthrough motion-control technology.

Microsoft's COM technologies provide a powerful, consistent object-oriented interface for application programs and were designed to promote software interoperability. COM objects are capable of being created and manipulated by a variety of Windows development tools including Visual C++, Visual Basic, Visual J++ (Java), and Inprise's Delphi and C++ Builder.

However, unlike the venerable, but at times despised DLL (dynamic link library), COM objects are not static sets of "library" function calls. Instead, COM technology was intended from the start as a means of addressing the problems of application complexity, version issues, and evolution of functionality over time that DLLs not only fail to solve but actually help to create.

Also, COM objects are active entities. Once created, each COM object can have its own "thread of execution." In other words, when a COM object is created, code begins to execute within the object, outside and independent of the application program that created it. This independence allows sophisticated, multithreaded motion-control strategies to be developed. One benefit among many is freedom from "big-loop" programs where the host PC must continually run long sequential programs. COM objects are persistent as well. They can continue to exist after the application that created them ceases to exist. Also, a COM object may be used by more than one "client" application. Related to COM is DCOM (Distributed Component Object Model). With DCOM, COM objects don't need to reside on the same machine that uses them.

The Final Ingredient
The final ingredient is the intelligent device. By definition, intelligent devices can perform complex operations without the assistance of a host or master. Examples are motor drives capable of cubic-spline interpolation and I/O points that determine their logical states based on other inputs and outputs.

Intelligent devices are fundamental to the next generation of motion control for several reasons:

  • Bandwidth reduction: When intelligent devices are networked, they greatly reduce network traffic and loading, because conversations and data can be kept to a minimum. A high-level motion command, such as "accelerate to 10 rev/sec in 0.5 rev," can be encoded in a small data packet. The intelligent drive receiving this packet deciphers it, computes the required trajectory, and executes the command on cue without further involving the host.
  • Minimal host processing burden: Intelligent devices relieve the host (master) computer of the tedium of orchestrating each action of the drives and I/O. This permits the host to concentrate on system-level functions and user applications.
  • Peer-to-peer communications: Intelligent distributed devices can communicate peerto-peer without intervention from the master. As a result, each intelligent device is aware of what other devices in the system are doing and their status, enabling them to take action independent of the host when necessary.

The necessary ingredients for the nextgeneration motion-control concept includes intelligent devices (such as drives and I/O) interconnected by a deterministic Ethernet network to a Windows-based PC host with COM as the interface layer to the user's application. One approach is API Motion's NMAC — Networked Machine Automation Control. It's an open, extensible softwarebased motion-control technology that eliminates the need for expensive proprietary motion-control hardware. And it uses Ethernet networking for direct motion control.

Deterministic Ethernet?
The number of industrial networks such as DeviceNet, Profibus, and SERCOS have increased markedly in recent years, but their lack of interoperability, restricted bandwidth, and cumbersome conformance requirements has limited their effectiveness and capabilities. Ethernet was initially dismissed as an industrial network candidate, mainly because it lacked determinism and didn't effectively work around communication collisions. But the NMAC configuration and operation of Ethernet overcomes these obstacles. It eliminates undesired collisions and guarantees determinism.

NMAC network implementation is based on a single-master, multiple-slave arrangement and uses the Internet standard protocol UDP/IP over Ethernet. UDP, User Datagram Protocol, is the "other" Internet transport protocol and is virtually unknown compared to TCP, Transmission Control Protocol. UDP, however, has the low overhead and quick execution time that make it an attractive protocol for control networks such as NMAC. NMAC also takes advantage of UDP's multicast messaging, a feature that TCP lacks. Further, NMAC does not need the guaranteed message delivery that TCP affords, and such connection-based services would only get in the way and slow NMAC. Its fast communications are also due in part to the 100 Mbits/sec Ethernet (100baseT) for the physical and data link layers (the two lowest layers of the OSI Reference Model). The familiar IP (Internet Protocol) handles addressing in NMAC, exactly as it does for the Internet.

An NMAC network basically operates as follows: First, in the master communication phase the master device issues commands to each of the connected intelligent devices. These can be as simple as a status request, or as complex as a series of positions to be cubic-spline interpolated by a drive.

Next, in the slave communication phase each connected slave device responds in turn to the master. When they aren't responding, the slaves listen to each other's conversations (referred to as "promiscuous mode"). This approach is the key for the effective peer-to-peer communications mentioned earlier.

Finally, it has a silent phase that prevents master or slave conversations. This provides a required cushion to guarantee deterministic operation of the network. The length of this phase is determined by the NMAC master and parameters that are set in the application program.

COM motion
Key to keeping all the communications flowing properly and quickly in NMAC is COM. NMAC's COM objects constitute the software layer that sits between the user's application and the Ethernet network and intelligent devices. Because NMAC employs COM technology, any COM-aware development system, such as Visual C++, Visual Basic, or Java may be used to develop the user application.

NMAC technology frees system engineers from the axis limits of motion control cards. Up to 255 motion axes per network can be accommodated by the current version of NMAC that runs with Windows operating systems 95, 98, 98SE, NT 4, Win2000, CE 2.12, and 3.0.

NMAC is also capable of coordinated motion using a proprietary buffering scheme that eliminates issues of operating system latency. With this advanced buffering technology, NMAC does not require a real-time operating system or extensions. NMAC's COM server generates trajectories (linear, circular, or hyperbolic) for a set of up to five axes at a time. In addition, it allows users to generate the trajectories for coordinated axes in real time, "on the fly." Hence, any physically realizable motion can be created and controlled.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.