One of the biggest struggles that we go through during the design process is how to keep parallel paths in our projects. Generally, it is human instinct to think linearly. We focus on the task before us and move on when that task is done. While this works well in theory, in practice our design process is much more loop-shaped with many circles back to catch features not thought of in the original planning stage. There isn’t a designer out there that hasn’t tossed out the odd curse at having to change the design long after that ship has left the dock.
Any controls designer will admit that the best projects are those where they can pull together parts of previously designed elements. We have already spent countless hours designing those blocks of circuits and programs, so why reinvent the wheel? Those same designers will also admit that no matter how hard they try, there isn’t a good way to make a generic design that will fit everything the concept specialists can throw at them. Or is there? I recently came across a couple of articles about the emerging technology of software-configurable I/O, and it gave cause for serious consideration of the possibilities. Trade shows have started to show some bite on the concept as it applies to industry. The need for configurable I/O isn’t new, but the application of software to tell a generic hardware module how to behave is certainly the new kid on the block.
The programmable logic controller (PLC) has evolved over the years. Early models were called “bricks,” where there was a single module containing the PLC and a fixed number of inputs and outputs. The next generation of PLCs added the convenience of a rack—of predetermined I/O space—where modules could be added to expand the I/O beyond the brick portion of it. This can be referred to as conventional I/O. Next came expandable I/O, where additional racks of I/O could be added, either in the same electrical enclosure or a remote panel. This was called remote I/O for that reason. Today, remote I/O has evolved to allow for multiple communications protocols connected to a conventional PLC.
Conventional I/O requires that you allocate I/O—by inserting a module in a rack—based on groups usually at the byte level. In the conventional I/O system, typical modules might be an eight-point ac input module or a 16-point, 24-Vdc output module, a two- or four-channel analog module or combinations of inputs and outputs of a similar voltage or type—digital or analog. The downside of this type of I/O is the designer must rely on a relatively accurate list of inputs and outputs at the outset of the design and then build the I/O table of modules to suit the list. Add to that design some additional unassigned addresses of each module type to ensure for future expandability and to allow for design changes. The selection of modules is tied to the product offering of the manufacturer.
The need for more I/O in a conventional I/O system prompted the development of remote I/O. Regardless of the vendor, remote I/O utilizes a communications module in the base rack to interface with the PLC in the main rack. There have been a number of different protocols used to communicate between main and remote racks over the years. Some of the more popular are Data Highway (DH), Data Highway Plus (DH+), ControlNet, DeviceNet, Profibus and Modbus. The general concept is that each remote rack is assigned a block of memory—input and output—in the main PLC, and the remote communications module takes care of mapping the I/O modules into this memory allocation.
An alternative to the main/remote rack style I/O system is to utilize slice I/O. The premise here is to have just a processor in the main rack and a communications module. All other I/O is located in close proximity to the actual devices being controlled. For example, one cluster might be located in the main control panel while others would be located in a remote control panel or field-mounted junction boxes. Another advantage of slice I/O is we can use modules that only have two or four I/O points, instead of a block of eight, 16 or 32. The benefit to this is not having to leave a chunk of unused I/O bits hanging around gathering up space in the panel. You get what you need, where you need it. With a little bit of foresight, a designer can include null slices to allocate memory (I/O) where future slices may be inserted if needed. I/O slices are limited to eight digital I/O points or less, so make sure to allow for enough space.
A few years back, many automation vendors started offering a different approach to automation where the backplane or rack could contain more than one communications module, and more than one logic controller could be present in the same control system. These are often called programmable automation controllers (PACs). Inputs can be shared between controllers to provide independent yet linked control of a much larger system. The advantage of this technology is to split up the tasks performed by these separate logic controllers to provide an increase in productivity and response. Another advantage of this type of automation platform is the mixing of older and newer technologies, especially with communications protocols. Data Highway devices could exist in the same control system with newer Ethernet or Profibus products.
The trick to any I/O system is to have a plan. Any system that remotely communicates with a block of I/O will have limitations on how much you can stuff into each node, or cluster, of I/O. Familiarizing yourself with the intended system will help tremendously and cut down on the amount of rework needed if the I/O expectations change.
ALSO READ: Consider machine integration in the design phase
The latest trend in automation is toward soft PLCs, where the programmable logic controller is entirely software-based, residing on a computer or server. The I/O for the controller resides on remote I/O, conveniently located close to the devices they control. The great part about a soft PLC is that the designer is not restricted to just ladder diagram, statement list or function block style programming. The programming algorithms can be in any programming language and then compiled. A logical next step in this trend has been software-configurable I/O.
The need for software-configurable I/O emerged from distributed control systems (DCSs), where the point of control may be in another building, city or even country. Building projects of this nature traditionally require all of the digital and analog devices to be known before the control system can be designed. For a large project containing hundreds or even thousands of I/O points, this could take months or even years to develop to the point where the controls designer could even begin to put pen to paper. The strung-out nature of this alludes to the linear approach to projects. Early players in the configured I/O game included Emerson, Honeywell and Invensys, all of them heavy in DCS. More recently companies such as ABB have gotten into the market for this fascinating product.
The general premise of this type of product is to assign a node of I/O at a particular location and then tell the individual I/O points what type of point they will be at some future point in time. A point can be an input or output and can be digital or analog in nature. The decision of what it will be does not have to be determined at design time. While software-configurable I/O is clearly geared toward the large-scale, DCS-type project, it certainly could be adapted to serve other automation applications.
Imagine, if you will, the possibilities should PLC vendors ever decide to bring this into the machine-level market. Current technologies with logic controllers and automation controllers offer some flexibility down to the byte level but still insist on some rigidity as far as requiring specific modules to perform specific functions. Software-configurable I/O would save tremendously in terms of upfront engineering by allowing for changes all through the design process that don’t negatively impact the hardware choices made at the beginning of the process. The flexibility of changing a type or function of an individual point of I/O after the machine has shipped is endless. Rarely does a machine leave the vendor that doesn’t need an update somewhere down the road. Inputs changing to outputs, digital signals becoming analog, all without swapping out or adding additional hardware is certainly a future worth looking forward to.
Rick Rice is a controls engineer at Crest Foods, a dry-foods manufacturing and packaging company in Ashton, Illinois. With nearly 30 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications. Contact him at [email protected].
