Distributed controls, smart IO
As microprocessors have become smaller and more powerful, it has become easier and less expensive to locate some of the processing power inside of the I/O device. An example of a smart device that has long had this capability is machine vision. Smart cameras have always had at least rudimentary I/O capabilities; pass/fail, product selection, and user-defined outputs for reject reasons are just a few of these.
The opening up of control network protocols and adoption of Ethernet-based deterministic control devices also has made it easier for innovators to create unique devices for different applications. For many years communications with remote devices required the developer to know each vendor’s communication protocols. Vendors were not always forthcoming with this information since it was in their interest to sell their own hardware. Serial and RS422/485 based protocols also were quite slow compared to today’s Ethernet-based systems.
Microprocessor-based devices also required developers to learn the major controller manufacturer’s I/O structure, whether it was byte, integer, or double integer (DINT) based, and other details. Slowly the rules for controllers have become more open and uniform; an example is IEC 61131-3, the international industrial control programming standard, the rules for what a PLC should be, its languages, and instruction definitions. Most PLC manufacturers now offer platforms that conform to these definitions, and also offer tag-based controllers.
At a recent industrial trade show I saw my first Raspberry-Pi based, commercially available industrial remote device. In this case it was a hybrid HMI with a camera interface. Raspberry Pi and Arduino are very low cost systems that kids are learning in elementary and secondary schools’ science, technology, engineering, and math (STEM)-related programs. This opens opportunities for younger developers to create and become innovators.
As far as when applications are more conducive to locating the control functions closer or farther from the process, there are several factors to consider. One is: do humans need to be present to diagnose and correct faults? Machine vision applications, for instance, may require lens or lighting adjustments. Data acquisition and simple remote failure corrections usually don’t require much operator intervention, though they do require periodic maintenance. Lower costs and higher communications speeds also have made remote applications more conducive to redundant controls.
Another consideration is how critical a failure is to the process. A human operator often is required to make decisions or intervene physically when alerted to a problem. If the process can continue with a few remote adjustments, controllers can often be autonomous.
More distributed, less central
Distributed control systems (DCS) historically been slow and expensive. With the increased capabilities of programmable automation controllers (PACs), higher speed/more open communication protocols and more powerful, lower cost microprocessors, the proliferation of more distributed and autonomous systems is inevitable. The Industrial Internet of Things (IIoT) is based almost entirely on this premise. While it has long been possible to monitor conditions and use alarming functions to make simple corrections, it is rapidly becoming possible to create distributed systems that have no central controller at all.
More answers www.controleng.com keywords distributed I/O
How might smart, distributed I/O devices help your next project?
See other distributed I/O articles linked below.