Back in the ’80s and ’90s, when 20 free-standing doors of relay logic panels, lined up in a row, would be replaced by a five-door PLC and power panel with four large racks full of about 1,000 I/O points, it made sense to resist distributed I/O on machine projects. Each of the I/O points ran from the main control enclosure to one of a dozen stations through one or multiple junction boxes on a 90-ft manufacturing line.
A crew of electricians might install miles of 16, 14 and 12 American wire gauge (AWG) copper wire delivered on several pallets—tons of it. Many events can cut, shred, break, step on or drill a hole through a wire or cable causing a failure, so a failed network cable would cause many I/O points or even hundreds, depending on the design, to fail.
The reality is that it only takes a single item failure to stop just about any automated machine. That item can be many things, such as a sensor, solenoid, wire or network cable. When using distributed I/O, it is possible to eliminate literally miles of wire and cable in a large system. Failures will be less frequent as there is less wire to fail and the distributed I/O intelligence also adds another a benefit, of which there are many, if properly designed and documented.
Use of distributed I/O saves wiring and shortens cable runs. It also creates a more modular design that can save floor space and reduce control enclosure size. So it's not just eliminating the bundle of wire by placing the I/O module close to the field device, it's creating a design that can be duplicated and then connected with a network and control power cable.
For best results, create a modular design when using distributed I/O. Breaking it down to its functional pieces and even adding a few more distributed I/O drops can make a system very plug-and-play and reusable. In the past, a large system's fat bundles of I/O wire would often need to be disconnected before shipping and then reconnected at the end user’s facility. Distributed I/O significantly reduces the need for field assembly.
Distributed I/O is making its way to servo motors, drives and power distribution. While rack-based drives, along with their shrinking size, make for convenient installation in the main control cabinet, these devices are moving to what some call cabinet-free designs. They can be distributed out to the machine and controlled with just a network cable and power drop. If you don't distribute these devices onto the machine, control them with an industrial Ethernet protocol instead of discrete I/O.
Also, document the distributed I/O drops and device addresses well so that changes or problems are quickly corrected. Documentation includes a spreadsheet of all IP-addressed device drops and I/O addresses, a clearly drawn network diagram, program logic descriptors and human readable tags on the distributed field devices. Some may claim their distributed I/O is self-documenting, but you and other programmers will need a cheat sheet and device labels in addition to the drawings.
To connect all of the distributed I/O, use one of the many industrial Ethernet protocols, or possibly IO-Link and similar for a more local option. The controller typically drives the network and protocol, as distributed I/O is often a well integrated part of the controller family now, whether from the same manufacturer or third-party suppliers.
Failed communication cables, network configuration and traffic were all concerns in the past, but network setup for distributed I/O is pretty simple and well-documented. However, network traffic can bite you sometimes. Keep an eye on the distributed I/O scan speed needed for the application.
ALSO READ: New technology pushes machine smarts to the edge
When using distributed I/O, keep the control network separate from the corporate network, which is best practice. Distributed I/O often needs a separate control network for best performance. Adding a vision system or two, some servo drives, a few robots, an HMI, communication to ERP and MES systems, and maybe remote access, all to one network along with distributed I/O is a poor design decision. Keeping distributed I/O and other real-time devices on a separate network or networks can help. Just beware that, on larger systems, there will probably be multiple control and information Ethernet networks.
Don't hesitate to try distributed I/O on a machine. Pick one that works well with your controller of choice and can be mounted directly to the machine or in a junction box; create a modular design; attach it directly to the machine; connect the network and power cable; plug in the field devices and start controlling that machine with a lot less wire.
