I/O's evolution from massive relay panels to distributed intelligence

When the programmable logic controller (PLC) was first introduced in the late 1960s, a major shift in factory automation occurred. It integrated multiple devices into a single control strategy, and, as in the relay panels it was replacing, all devices were wired back to a main panel. The size of the panel was commensurate with the number of devices that were being connected to the control system.

Typically, the field devices were wired to terminal blocks where the other side of the terminal block was wired to the PLC input/output (I/O) structure that existed in the panel. In practice, these panels were very large, some being four doors wide.

The I/O modules were chassis-based and had a separate power supply for each I/O group. The I/O structure used dc power to operate, even though most devices in the early days were 120 Vac. This also required that the wire size would be 14/18 gauge. This clogged the wireways and made panel design harder than it should have been.

As the control system matured, customers were demanding smaller panel sizes, as well as wanting to reduce the installation of the project cost by reducing the amount of wire used in the field. Remote I/O was born early on. Depending on the application, local I/O could be used, but, the higher the device count, users were leaning toward distributing the I/O across the process and/or machine install.

This reduced the overall install costs of the automation strategy by taking the I/O to the area of the process that needed to be connected. Smaller panel size, as well as less wire, was used in the field.

The protocol used typically was serial and was proprietary to the vendor. Data speeds approached 230K baud, which was somewhat fast enough at the time. Depending on the number of remote I/O chassis, the I/O update time in a synchronous system can add significant time to the execution of the control program. In some applications, that 10-20 milliseconds means the difference between success and failure of the control program.

Remote I/O isn’t really distributed I/O as such. The cost of the power supplies, chassis and modules dictated that you must have enough I/O to justify that cost. This was realized in the mid 1990s when smaller I/O structures came to market allowing for a reduced footprint and a better cost structure. Device-level protocols were also introduced but some remained as a serial protocol, although speeds were enhanced.

The customer base continued to demand reduced costs and more flexibility in their automation designs, and, while industrial Ethernet was commonplace, our industry moves slowly.

Then standards happened. Published communication standards have become available to everyone. The advent of third-party vendor I/O solutions became the norm. A PLC/PAC control strategy could exist with multiple vendor I/O solutions all running on the same network. Valve controllers could exist as an independent device on the control network. A pushbutton cluster, an HMI panel, a solenoid valve manifold, ac drives and the like were developed and entered the marketplace setting the stage for an I/O battle.

Get your subscription to Control Design’s daily newsletter.

Now we can have true distributed I/O in any control strategy. The driving force of automation design boiled down to the main CPU vendor and the software being used to program it, as well as the ease of which third-party equipment can be integrated with it.

Being a node on a network requires a network cable with local device wiring. Getting power to the node is really the only consideration. Machine design is simplified since you can put an I/O block on the opposite side of the machine with four I/O points economically and tie it into the main panel using Cat. 5/6 cable. It’s cost-effective, clean installation, and it provides choice in vendor.

IEC 61149 provides a standard for distributed control networks. It works at the device level so that a limit switch or photocell can be a node on the network. There is no need for adapters, I/O modules or mounting considerations because the device is all of that. The decision-making process of the device is programmed directly in the device. There are applications where this granularity may work well, and some where it will not work well. The issue of troubleshooting and training comes into effect, but it is distributed control at its finest.

Regardless of semantics, we have at our disposal a plethora of I/O solutions that can serve our applications well including process requirements. Reduced footprints and reliable communications allow for superior designs with a much lower cost structure than we have ever had.

Just gotta’ pick your horses and run with them.