Upgrading Legacy I/O Systems

When it’s time to modernize, choosing the best I/O strategy and supplier is critical for both new and upgrade projects.

By Jason Haldeman March 13, 2012

Companies that design and build machines and robots often face the problem of upgrading the I/O on one or more of their machines. Even end users find that legacy I/O, which may have been used successfully for years, may need to be replaced because the vendor has gone out of business or no longer supports the hardware. In other cases, an OEM or user may want to change control systems, I/O networks, or vendors for cost, safety, customer preference, quality, or performance reasons.

Modern I/O modules (Figure 1) often support Ethernet connections, wireless communications, advanced diagnostics, remote diagnostics over the Internet, on-board intelligence, multiple inputs and outputs, and a host of other features that can’t be found in older systems. Whatever the driving reasons, upgrading I/O on a machine or manufacturing line is not a simple task, as many factors have to be considered before selecting an I/O system.

From hardwiring to Ethernet

The first PLCs transmitted all remote I/O signals to and from the main processor via hardwiring, as no digital networks existed at the time. Serial networks—based on RS-232, RS-422, and RS-485—came along and transformed the plant floor, because they drastically reduced wiring requirements. With a serial network, multiple devices could be plugged into a single twisted pair.

Soon, most PLC manufacturers came out with their own versions of serial networks such as Modbus, which is still widely used.

Some of these serial networks became de facto standards, including Profibus DP, InterBus, and DeviceNet. These networks and others usually started out as proprietary protocols backed by one or more vendors, and were then were opened up to allow any manufacturer to create compatible devices. Most of these networks worked well, but they weren’t compatible with each other.

Once an OEM or end user committed to a particular I/O network standard, it was often bound to a certain group of vendors for the foreseeable future. If the application required communication with a device on a different network, a gateway device was the normal solution. These devices were expensive and hard to program, making it very difficult for users to integrate machines or robots manufactured by different companies into an operating whole such as a packaging line. 

While PLC manufacturers were fighting for market share, Ethernet was becoming the standard in office networks, and Ethernet soon migrated to the factory floor. PLC manufacturers adapted their serial networks to run on Ethernet, opening up the ability to run multiple protocols on a single Ethernet network. Today, Ethernet-based I/O networks (Figure 2) are replacing older proprietary networks. PLC vendors still maintain individual protocols, but most concentrate their effort on Ethernet-based communication and can thus share the same Ethernet network.

This allows manufacturers to use standard Ethernet functions for overall control of industrial networks. Precise delivery of data to and from multiple I/O devices can be controlled with transmission protocols like Multicast, and general network segmentation can be controlled through the use of a VLAN (virtual local area network). Other Ethernet standards, such as rapid spanning tree protocol, can be used to create redundancy within the network, while not affecting the PLC manufacturer’s I/O communications. These types of protocols are employed on the network through the use of a managed Ethernet switch.

Today, a machine builder is faced with myriad choices of networks including Modbus TCP, EtherNet/IP, Profinet, DeviceNet, Profibus DP, InterBus, Mechatrolink, CANopen, EtherCAT, CC-Link, and more. And wireless options are available for almost all these networks. 

When upgrading I/O, a machine builder or user has to ask:

1. What I/O network do I want, or does my controller dictate the choice?

2. How many vendors make products for that network?

3. Do I want to be bound to one group of vendors for the foreseeable future?

PC vs. PLC

The next factor to be considered in an upgrade is the control system. Although PLCs continue to dominate machine control, industrial PCs are making inroads.

If you’re keeping the same PLC during the I/O upgrade on a machine, then you probably won’t have to reprogram the control logic, but you may have to reconfigure it for the newer I/O. Do you have access to the code that changes the I/O configuration? Without that code, or a readily available patch from the PLC vendor, you may not be able to connect newer I/O to the older PLC, and older model PLCs may not support newer I/O networks even from the same vendor.

One solution may be to upgrade the PLC to a newer model in the same family—one that supports both your control logic program and the new upgraded I/O. The upgraded PLC should support its own newer I/O, but it may not support all of the options that you need.

Fortunately, several I/O suppliers offer modules that work with many networks. Unfortunately, not every supplier covers every network, so an OEM may have to mix and match products from multiple suppliers. For example, if a machine or robot needs a strain gage/load cell converter, the OEM must make sure one is available from the preferred supplier.

Modular vs. proprietary

Being locked into a single PLC vendor poses many problems, not the least of which is the potential for excessive module costs.

In some cases, customers demand a certain brand of PLC. But in many cases, an OEM has freedom to choose the controller, either a PLC or a PC. Even when the customer specifies a certain PLC brand, the OEM can often choose the I/O. That’s because the OEM’s customer is primarily concerned with providing operating support for the PLC’s software, as opposed to the I/O hardware.

For OEMs with a choice, modular I/O is an excellent way to upgrade a machine or robot, or to build a new one. With modular I/O—available from several suppliers—analog and digital input and output devices, signal conditioners, network interfaces, power supplies, terminal strips, and all the other components needed for a machine are network-independent.

If, for example, an OEM sells to a company in Germany, modular I/O will work with Profibus DP, the preferred network for many European firms. If the same machine or robot is being sold to a company that wants a Rockwell Automation PLC, then the I/O will work with DeviceNet. The machine uses the same I/O devices, but each is connected to the I/O network with bus couplers, so only the couplers need to be changed on the I/O station.

Machine vs. cabinet-mount

Machines can have dozens of sensors and control devices such as proximity switches, encoders, load cells, pressure and temperature sensors, relays, motor starters, and indicator lights. These sensors and control devices are mounted on the machine itself, and must be wired to the discrete and analog I/O. These I/O devices can be mounted in a cabinet or on the machine.

For machines that will be sold internationally, the typical choices are IP20-rated devices for mounting in a control cabinet, IP67 devices for mounting directly on the machine, or a combination of both. The IP rating is based on the international standard IEC 60529, which rates the degrees of protection against dust, contact, and water. IP20 is equivalent to NEMA 1, and IP67 is equivalent to NEMA 6.

With cabinet-mounted IP20 systems (Figure 3), sensors and control devices are wired to I/O devices mounted in a NEMA or IP-rated control cabinet. The cabinet can also hold power supplies, power conditioning equipment, air conditioning, HMI screens, Ethernet switches, and I/O racks. The I/O devices or racks connect to any Ethernet-based network via bus couplers.

IP67 devices (Figure 4) have greater protection against dirt and water, and can be mounted directly on the machine or robot without the need for an enclosure. Each station has a built-in Ethernet connection. IP67 devices cost more than IP20, but total costs are often less because there’s no need to buy a cabinet with its additional installation costs. In many cases, an OEM can buy pre-made cables to run from sensors to I/O devices, further reducing installation and wiring costs.

When deciding whether to use IP20 or IP67 equipment, make sure you can obtain the I/O devices you need, as vendors typically offer fewer IP67-rated options compared to IP20. This may force you to mix and match devices, so make sure the I/O vendor supports this capability.

Going wireless

Wireless I/O is gaining momentum in machine and robot control. While serial and Ethernet networks took decades to develop, wireless has made giant strides in just a few years. Many OEMs are still wary of wireless, just as they weren’t too sure about Ethernet when it was initially introduced for real-time control applications.

Wireless I/O can be used for applications that traditionally required slip rings and drag chains that are difficult to wire; to replace highly-flexible cables that are prone to breaking; and in temporary installations, such as components that are being integrated into a permanent system. For robots in particular, wireless I/O can be very advantageous.

The most obvious advantages of wireless I/O are the elimination of costs associated with running wires from the machine to the controller, and the simplicity of the installation overall—which could result in lower maintenance and diagnostic costs. We’re a long way from the completely wireless machine, but as industry gains more confidence with wireless, applications will continue to grow. Wireless I/O devices are generally available in both IP20 and IP67 versions.


One of the primary advantages of modern I/O devices is built-in diagnostics. I/O devices can transmit information such as short circuits, overloads, temperature extremes, status, and other diagnostic data, making it possible to pinpoint problems quickly and reduce machine downtime. 

For example, in DeviceNet systems, faults are transmitted as diagnostic alarms with associated parameters classifying them as major or minor. The parameters can contain either I/O-specific error codes or network-specific error codes. If the fault is generated in the remote I/O station, additional information can be supplied by the vender through diagnostics in the process data channel. Wear indicators or similar information for diagnostics can be signaled via two maintenance request priority levels.

Standard Microsoft Windows software, such as Internet Explorer, can be used to diagnose network problems. For example, Phoenix Contact’s Ethernet I/O has a built-in Web interface, allowing a user to view device status and configuration information through Web pages.  

Another major development in machine control is remote access, where the OEM can diagnose problems from a PC, laptop, or even a cell phone thousands of miles away. An engineer simply gets on the cloud and connects to the remote machine or robot to view and change data in the controller and I/O. Using built-in diagnostics makes this task even easier, because a remote engineer can quickly identify problems such as short circuits or overloads in the I/O.   

For all of these reasons, machine builders and users are updating their legacy I/O systems, getting away from proprietary networks, and moving into the modern world of Ethernet-based communications. In an ideal world, all the sensors, control devices, and controllers would be interchangeable to meet various customer requirements—and so would the I/O hardware and networks.

Ideally, an OEM or integrator should be able to install Profibus-based I/O on a machine when the customer wants a Siemens PLC, and the next day build the same machine with an Allen-Bradley PLC and DeviceNet. In practice, this is possible only if you select your I/O strategy and supplier carefully, making sure that all needed capabilities are supported in a cost-effective manner.

Jason Haldeman is a product marketing lead specialist for Phoenix Contact.


Author Bio: Jason Haldeman is senior product marketing, Phoenix Contact USA.