When setting out to design a control system, the logical path tends to start at the brains of the operation and end at the fingers and toes. The controller choice comes first, then the major devices and, finally, the input and output devices that make it all come together.
While this is the traditional way to design a control system, innovation on the input/output (I/O) end of the system has changed the way we might approach our designs.
Get your subscription to Control Design’s daily newsletter.
The impact of programmable logic controllers
In the early days of programmable logic controllers (PLCs), we would approach a design by listing all of the devices that make up the machine or process, splitting it into inputs and outputs and then splitting that list up into analog and digital devices. From this list, we could determine how many logic modules were needed to talk to all of the field devices.
That module count would determine the size of the chassis needed to mount the I/O modules. In some cases, there were more modules than the base controller rack, or chassis, could contain, and we would split the modules up into base and child/subracks. A communications protocol that was native to the main processor would be used to have the base rack talk to the child racks.
In those early days, the base rack and the child racks needed to be in the same physical control panel, and the method of communications had distance limitations. As the years passed, the development of additional communications protocols would make it possible to mount the child rack in a remote location and the term “remote I/O” came into use. Depending on the communications protocol, the distance from base rack to remote rack could be as little as a few feet and as much as several hundred feet.
Base vs. remote racks
Base and remote I/O originally had the same mounting base or backplane. The base chassis, or rack, would have a processor in the first position/slot with I/O modules filling out the rest of the positions in the backplane, while the remote chassis would have a communications module in the first slot with the same type of I/O modules filling out the rest of the slots in the rack.
Each slot didn’t have to contain a physical module, but the memory allocation would match the size of the rack since these early PLCs assigned blocks of memory based on the size of the rack in which it was mounted. For example, a base rack might have four slots in it, so memory was allocated based on potential of four I/O modules in the four slots of the rack.
A remote rack might have seven or 10 slots, and the assigned memory of that rack would be based on the potential of all seven or 10 slots being filled with I/O modules.
Tag-based vs. memory-based systems
The next generation of PLC, sometimes called a programmable automation controller (PAC) used the same rack-based I/O system with two notable differences. The physical size of the racks was much smaller, about one-third of the size, and the controllers were tag-based instead of memory-based.
In a memory-based system, the controller had a series of base pre-configured memory files. The base types were bit, integer, floating-point, timer and counter.
The size—how many elements of the defined type—could be expanded or reduced based on the needs of the program. Additional files could be added to the base memory system to further define the program needs but had to be of the same type as the base memory files.
In a tag-based system, tags are user-definable, meaning they are given a text name and can be of any file type. Like the memory-based system, the tag space can be as big as the program needs. However, for both systems, the size of the memory space plus the program itself determines the model of controller that needs to be used for the system.
Device communications
The latest generation of controllers no longer use a fixed chassis and can contain as many modules as the model of controller permits. The size of the base memory also comes with a defined number of communication nodes that can talk directly to the controller. The more memory, the more communication nodes are available, and the cost of the controller goes up in a relative manner.
All of this innovation has opened up possibilities when it comes to the architecture of our control system. Variable-frequency drives (VFDs) and servo drives now connect to our controller on a standard communications protocol, which is determined by the make of controller, and appear as nodes on the communications channel.
The same is true for other output devices such as linear drives. The remote I/O racks don’t have to be of the same I/O type as the base controller and can be quite small. This makes them more appropriate for mounting remotely on a process or machine.
Some remote I/O racks can be mounted directly on the machine frame, without the need to locate them inside a junction box. The machine-mounted devices are robust and resistant to environmental conditions that traditional I/O racks could not be exposed to.
User-configurable I/O
While all of this innovation has happened to the “brains” side of the control system, a quiet revolution has happened on the “fingers and toes” end of the design. Traditional I/O would come in digital or analog versions. The device would wire to a digital or analog I/O module, which would, in turn, talk to the controller in the system.
Methods of wiring have made it much easier to deploy I/O. This has enhanced control designs because it isn’t so much trouble to get additional signals back to the controller.
The machine-mounted I/O module mentioned previously now comes in versions where the module itself is a node on the communications network. Most machine-mounted modules are capable of up to eight or 16 points of I/O, but, even better, those modules can be daisy-chained together to provide even more machine-mounted I/O points but on the same node on the communications network.
Machine-mounted I/O can be user-configurable, meaning that individual points can be assigned as an input or output and since each of the eight points of physical ports can be split into two separate points, there can be 16 points of either input or output, on a point-by-point basis, chosen by the designer/programmer.
IO-Link master/slave
Gaining traction over the past couple of years, IO-Link is a game changer in the world of I/O. Using the same physical connections as a traditional M12 I/O point, I/O devices can provide more than just the analog or digital signal back to the control system. IO-Link devices essentially become nodes where additional information like model number and signal strength/health can be read from the device, but user configurations can be downloaded to the device, as well.
The machine-based module changes—instead of traditional I/O, it is now an IO-Link master or slave—and the usual four wires now become two wires for power and the other two wires are for communications.
The best part about the advent of IO-Link is many of your favorite I/O devices are already capable of IO-Link. There is no need to move away from what you are comfortable using.
One example of where IO-Link provides an advantage is the ability to monitor signal strength. A traditional digital sensor would only be able to signal a change of state to indicate the presence of an object. With IO-Link, the processor can receive a 1 or 0 to indicate the presence or absence of the object. But it can also read the quality of the signal.
This can be used by the programmer to set up a message to indicate the demise of a signal. This would suggest that the sensor has accumulated debris that is inhibiting the ability of the sensor to properly function.
A message could be then displayed on the operator station to prompt the operator to clean off the sensor or announce impending failure, so that maintenance can plan to replace it as a planned event.
The concept of IO-Link has even migrated to safety-related systems. The safety relay becomes a master, and the individual devices on the safety channel become nodes on a safety network. The devices can be door switches, light curtains, safety mats or locking gate latches.
The programmer defines the order of the devices on the network and downloads the configuration to the safety relay. If the definition doesn’t match the actual order of the devices on the network, an error occurs, and the definition must be corrected before the function can take place.
Like the base devices on IO-Link, these safety link systems can indicate not only make-or-break status but additional information like pending failure of dual channels of operation. Door latch devices provide tags to not only indicate status of the door switch but tags to command the door latch to lock or unlock. All of this in a single tag structure in the memory map of the safety relay with one tag for each node on the network.
A control system relies on the inputs and outputs to make everything happen, and every new innovation makes that system easier to design and implement.
