Originally Published MEM Fall 2008
NETWORKING
) |
Ethernet communications is rapidly gaining popularity in industrial applications, including medical, because it enables the real-time exchange of information between processing equipment and companies' Ethernet-based management systems. Ethernet technology is becoming widely accepted because of multiple factors, including:
- The speed advantages over lower baud rate protocols.
- The number of tools available for troubleshooting and optimizing a network.
- The broad base of competitive vendor support and solution options.
- The large pool of trained personnel who are familiar with the technology.
In addition, the ability to bridge existing proprietary communications schemes makes it possible to phase in the use of Ethernet rather than having to replace all devices with non-Ethernet communication products, which can include temperature controllers and programmable logic controllers (PLCs), at once. When asked, engineers most frequently respond that they expect to use Ethernet to integrate control systems in the future. But a follow-up question, inquiring which Ethernet protocols they plan to use, is often met with confusion. Some engineers do not realize that there are thousands of protocols that are compatible with, and can coexist on, Ethernet networks.
In attempting to navigate this sea of protocols, it is natural to look first to familiar ones that offer the functionality seen on office networks, at home, and on the Internet. Using such protocols, Ethernet can extend access to remote users through Web browsers and e-mail. But for an engineer tasked with automating a process, the challenge is to connect devices to other devices to integrate automatic functions. For example, a temperature controller may need to get its set point from a PLC.
For the purpose of automation, Ethernet protocols such as HTTP (which allows Web browsers to display Web pages) and SMTP (by which e-mail messages are transmitted) are ill suited. These protocols are designed to transmit information over Ethernet, but the information is in a form that requires human interpretation. One purpose of automation is to relieve humans of the tedious task of monitoring and adjusting a process based on feedback from sources such as pressure gauges and mercury thermometers that require human interpretation. Another purpose of automation is, of course, to improve process results by removing variations in human interpretations and occasional misinterpretations from the process. Rather than protocols that transmit messages intended for human eyes to interpret, automation needs protocols that transmit information structured for such devices to interpret. An example of a control automation problem can be used to illustrate this need.
An engineer who plans to automate a plastics extruder must consider not only the logic functions that control the screw movement, but also the critical temperature control of the melt that ensures the correct profile and properties of the finished product IV tubing or stents. The engineer must also consider the reliability of the process and the ease of use.
A PLC may be ideal for the sequential functions, but accurately controlling temperature is also important. Here the engineer is traditionally faced with a dilemma. The system can use the PLC to perform temperature control directly, or stand-alone temperature controllers can be used in conjunction with the PLC.
Performing temperature control in a PLC presents numerous challenges. Programming can be difficult, requiring expertise that may not be available. Control algorithms can interfere with other program functions by consuming processing bandwidth, or can require the use of a more expensive PLC than would otherwise be required. Control may be suboptimal because a simple on-off control algorithm, the easiest to program in a PLC, is used. The alternative, using a stand-alone temperature controller, resolves these issues. Commercially available temperature controllers include advanced control algorithms and automatic tuning, so little expertise is required. The calculations and input/output updates associated with temperature control are performed by the PID controller's processor, freeing the PLC's processing bandwidth for other tasks. But in the past, differences in the supported protocols meant that getting stand-alone temperature controllers and PLCs to communicate was time-consuming, costly, and difficult as well. If the PLC and temperature controller do not communicate, the machine depends on the operator to integrate these functions.
For example, an extruder may use a PLC to operate functions such as screw speed and delivery of plastic pellets into the extruder from the hopper, and also use discrete temperature controllers to control the temperature of the extruder's barrel where the pellets melt. Operators know that careful coordination of screw speed and melt temperature can make start-ups and material changes faster. Quick start-ups and material changes save valuable production time and material, and reduction of scrap is especially significant in medical applications where scrapped material cannot be reintroduced into the process. But if the PLC and temperature controllers are not coordinated by the automation system (if they do not communicate), someone has to manually change the temperature settings on the controllers. Without the communications link, the chances are greater that the temperature settings will not be correct and the start-ups and transitions will take longer than the optimal time. Production errors are more likely to occur, causing expensive scrap.
Engineers often prefer to use stand-alone temperature controllers when performance of control loops is important. These controllers are also used when the PLC application could be negatively affected by incorporating the temperature control function, but traditionally the cost and difficulty of integrating a temperature controller was a major barrier. Because many PLCs and a growing number of temperature controllers now support Ethernet-based protocols intended for industrial applications, this barrier is falling away.
Ethernet Protocols
One such protocol is EtherNet/IP. According to the Open DeviceNet Vendors Association (ODVA), the agency that sponsors both DeviceNet and EtherNet/IP, EtherNet/IP is a member of a family of networks that implements the common industrial protocol (CIP) at its upper layers. CIP encompasses a group of messages and services for manufacturing automation applications including control, safety, synchronization, motion, configuration, and information. EtherNet/IP provides users with the network tools to use standard Ethernet technology for manufacturing applications while enabling Internet and enterprise connectivity.
Using EtherNet/IP specifically yields the advantages of an Ethernet network, as well as the advantages of CIP designed for device-to-device communications. Those advantages include the following:
- Explicit messaging, which allows devices to be configured via the network. A device can be detected and completely configured automatically in the event that a piece of hardware is replaced.
- Implicit messaging, which allows efficient communication of data and instructions from one device to another or from one device to many consumers of data on the network. This minimizes network traffic and allows the speed advantage of Ethernet to be achieved.
- Assurance of interoperability. All devices are tested by ODVA, and users can expect fewer problems when putting devices from multiple vendors together on a network.
- Integration with other EtherNet/IP-compliant devices such as PLCs or touch screen human machine interfaces (HMI).
EtherNet/IP allows engineers to integrate various components such as PLCs and temperature controllers with each other in effective and efficient control schemes.
Another Ethernet protocol that is commonly supported by industrial devices is Modbus TCP/IP. This protocol is governed and promoted by Modbus-IDA, an independent nonprofit organization. Modbus TCP/IP is, at its heart, the same as the Modbus RTU protocol that has been described as the de facto standard for multivendor integration. While Modbus RTU is found commonly in networks that use RS-232 or RS-485, its younger sibling Modbus TCP/IP extends this protocol by packaging the simple-to-understand messages in a TCP/IP wrapper, making them compatible with industrial and office Ethernet networks.
Because Modbus TCP/IP is essentially Modbus RTU embedded in TCP/IP packages, it is relatively simple for instrumentation suppliers to leverage their Modbus RTU support into support for Modbus TCP/IP. It is also relatively easy for users familiar with Modbus RTU to learn the Ethernet version. Finding something that is relatively easy to learn will appeal to many users who are daunted by the task of integrating and automating a machine or process.
The model of embedding an old industrial protocol into the newer Ethernet-friendly TCP/IP protocol is not unique to Modbus and offers advantages in addition to familiarity. A user with a machine or a factory full of devices that support Modbus RTU can extend their usefulness with Modbus RTU–Modbus TCP/IP gateways. Because the task of embedding Modbus RTU messages into TCP/IP wrappers and extracting Modbus TCP/IP messages from their wrappers is relatively simple and independent of the content of the message, gateways can be added in a machine or a factory without a monumental effort. Because the gateway only has to translate messages from one hardware network to the other (Ethernet to RS-485 typically) and add or remove the TCP/IP wrapper, it takes little effort to set up the gateway itself. The same commands and Modbus registers (memory addresses) are used in both versions of the protocol, so the content of the messages does not need to change. That saves time over having to program a gateway to translate data from one set of addresses in one protocol to another set, such as that which must be done when translating from, for example, Modbus RTU to DeviceNet.
While the upside to this protocol is a faster learning curve, the downside is that it lacks the more advanced features of protocols such as EtherNet/IP. It has no implicit messaging, and devices are not all conformance tested. If the primary objective is to integrate discrete devices such as PID temperature controllers with an HMI panel or PC-based software, Modbus TCP/IP can offer a nearly seamless transition from the older Modbus RTU and RS-285 paradigm to the world of Ethernet communications. If, however, the primary objective is to integrate devices with a PLC, then the choice of protocol may be driven by the choice of PLC vendor and other factors.
Temperature Controllers for Automation
Fortunately, many new temperature controllers are being designed for automation. Many new offerings give an engineer the option to choose the best controller for the application and still get the protocol necessary to integrate with the other components in the system. Choosing the best controller means making choices about integrated features, package size, and interface type. Integrated features include the following:
- One or more loops of control (devices vary from single loop to 50 or more loops).
- Advanced control algorithms (fuzzy logic and other ways to optimize control over standard autotuning).
- Application-specific and mathematical functions (such as cascade control, square-root function, residual oxygen sensing).
- Diagnostic and asset management functions (heater failure detection, backup sensor, integrated overtemperature safety shutdown device).
- Integrated power switching.
More integration in the temperature controller means a higher level of functionality in less space with fewer connections to make. Using a multiloop controller can simplify integration because multiple loops of control can be accessed by a PLC or an HMI at one address. Also, controllers with multiple inputs offer functionality such as sensor backup, a feature with which when one sensor fails, the controller switches to a second sensor for feedback to avoid interruptions and scrapped product. This functionality could be achieved with single input devices and external logic, but such setups would require more wiring and programming.
Integration of multiple functions such as control, power switching, and safety limits can greatly decrease the number of field-wiring connections in the control panel and thereby improve reliability. Such integration is ideal for applications in which space is limited. Having a less-crowded panel, fewer wiring connections, fewer discrete components, and better thermal loop monitoring with error reporting are all benefits to the user. A controller with such integrated functions decreases design and assembly time, requires less panel space, minimizes system complexity, and best of all, lowers the total cost of ownership.
Package size is often a concern when selecting a temperature controller. The familiar 1/4, 1/8, 1/16 DIN–size products with one or two inputs and one or more outputs still dominate the market. Multiloop and modular products offer an alternative when space is at a premium.
Another factor to be considered when selecting a temperature controller is the type of interface. The DIN-size products that mount in panel cutouts and include two to eight buttons and seven-segment LED or LCD displays are still prevalent, but alternatives are becoming more common. There are products with more-advanced displays and products that mount inside the control panel with no integral displays. The no-display products appeal to supervisors concerned with minimizing the opportunity for uncontrolled and unauthorized adjustments to settings. This design could concern maintenance personnel who may be called upon to make adjustments or troubleshoot equipment and do not want their access to be limited to only operator parameters. Providing access to settings not needed by operators on password-protected screens in PC software or on an HMI requires extra programming time. Selecting a controller with an integral interface or one that can be controlled remotely, but physically controlling access to that interface, is a good alternative.
Conclusion
While there are many options for integrating devices in automation solutions, Ethernet will play a significant role in the future. There are many Ethernet protocol options. Some provide more functionality for remote access by users and others provide more functionality for integrating devices. The emergence of protocols such as EtherNet/IP and Modbus TCP/IP enables engineers to attain the advantages of using Ethernet in industrial applications. The broad support by suppliers for these protocols allows an engineer to choose the best device for the job without compromising the ease of use that comes with fully integrating the control system.
Author's Note
DeviceNet and EtherNet/IP are trademarks of Open DeviceNet Vendors Association. Modbus is a registered trademark of Schneider Automation Inc.
Sean Wilkinson is product manager for multiloop controllers and software for Watlow (St. Louis).
