As technology continues to evolve, some terms meant to represent one thing have come to mean something a bit different. A technology that once had restrictions can evolve to the point where, not only is that restriction gone, but the name of the technology doesn’t even necessarily apply anymore.
We see this phenomenon manifest itself in the variety of input/output (I/O) options in the industrial world, specifically with the term “remote I/O.”
Also read: How does I/O termination affect protocol choice?
For many years, remote I/O simply meant the I/O node was located somewhere other than in the main control cabinet with the programmable logic controller (PLC). Instead the node was then remotely connected to the PLC over some network, and the PLC would be able to read and write to I/O on the remote node. This is in contrast to local I/O, where the I/O modules or units were housed in the same cabinet with the PLC. Discrete wires were run from the devices back to that cabinet no matter where the devices were on the machine.
Remote I/O nodes solved a few design challenges in the use of PLCs, proximity being the first one. Remote I/O on larger machines made it easier to locate the connection point for the sensor, relay or switch closer to the actual devices, instead of either running long wires back to the main cabinet or having multiple PLCs.
Hardwiring was also a challenge. Excessive lengths of cables and wires can be very cumbersome and costly when the I/O devices are a long way from the main PLC, and connecting I/O devices locally to the PLC is not the best approach.
In these situations, machine builders would find it far more beneficial to utilize a remote-I/O solution where all the sensors are wired to a remote-I/O node and then more easily connected with one communication cable back to the PLC.
Finally, there was the issue of speed. For a very long time, the advantage to having I/O connected directly to the PLC (local I/O) meant speed. It was a much faster I/O exchange with the central processing unit (CPU) than the remote-I/O option.
Remote I/O has evolved since its origin. Network speeds have gotten much faster, data-exchange sizes have gotten much larger, and network protocols have homogenized to the point where communication standards are shared among manufacturers, eliminating proprietary networks and hardware.
Machine builders can pick from the best I/O products and control devices from all manufacturers to use on their machines. Devices have changed, too. No longer is it just inputs and outputs that live on these networks: servo drives, temperature controllers, human-machine interfaces (HMIs) and other specialty devices have found homes on remote I/O networks as they’ve evolved.
From remote to networked
As the advantages of remote I/O grew with the evolution of the network, perceptions were slower to evolve. The term “remote I/O network” itself made machine builders think of the limited networks of the past, where the need was for some simple I/O at a remote location. However, calling on the faster communication and update speeds, along with the larger amount of data that is used, remote I/O morphed into “networked I/O.” Just changing that terminology helps machine builders to understand that proposing a networked I/O solution isn’t done to solve a proximity problem, but rather to streamline the interface of the PLC to the devices.
Remember, I/O networks or fieldbuses evolved from their origins to encompass more complex devices and accommodate multiple vendors, enabling standardization. This standardization makes it desirable to use an I/O network or fieldbus for devices with large amounts of information to exchange, rather than creating a connection to those devices using the native, usually proprietary, communication protocol, or limiting the exchange of information to just a few digital inputs and outputs.
It’s therefore more appropriate to refer to networked I/O, rather than remote I/O, for parts of the machine-control solution. For example, if servo control is done over an EtherCAT network, it can traverse long distances, but the key advantage is that it can exchange large amounts of data and perform at high speeds. Thus, connecting servo drives that live in the main cabinet becomes a networked-I/O solution.
We’re seeing remote-I/O nodes housed in the same cabinets as controllers for this networking advantage. It’s easier to connect everything over a network, as opposed to locally. Distance is no longer the driver for this solution. There are simply more field devices in play. Between servo motors, sensors and controllers, connecting everything together over a remote network is easier to manage. Additionally, speed is no longer an issue with a remote-I/O network.
And because it’s a standard communication protocol, it is easier to connect devices, making it easier to integrate devices from different manufacturers. The manufacturer will provide instructions on how to integrate the device into a standardized network.
Changing the terminology helps change the perception, making this powerful aspect of machine control more accessible conceptually to machine builders.
