The automation PC is located in the control room, and the dump valve is on the other side of the tank farm wired to a remote I/O cabinet, all connected over an Ethernet network.

The IT guys are working on the network, and they say it may take a few days to track down the intermittent cable. But hey, in the meantime, they say that it mostly works…

That answer might be sufficient for watching YouTube, but it is just not going to cut it for controlling that valve.

What do you do?

Control systems got started with relays. The power to the relay was delivered over a pair of wires. If a wire broke, the relay would not turn on.

Over the years the relay might have been replaced with far more reliable solid state electronic relays, and the wire went from carrying the actual control signal to perhaps a serial data stream. This way more than one relay could be controlled or monitored at the far end, and the limit on the number of relays was the serial data speed.

But for most control systems, the integrity of the wire was still a critical part of the system working as it should. When the wire broke, you didn't just lose one relay, but many outputs and inputs. The integrity of the network infrastructure was critical to the smooth and safe operation of the automation network.

What if, rather than just talk to a few relays, you could talk to a relay controller or better, an intelligent I/O processor at the end of the wire? What if you could send a small set of commands from your host PC or controller over the wire and the I/O processor would make sure they were executed, whether the wire went down or not? The I/O processor could take on some of the automation tasks. This would free up the main automation PC or controller, and it would help make the system more reliable.

For example, let’s say you wanted to turn on a digital output, let's call it valve_101, for 30 seconds. Here is one way of doing that in some structured text (generic) code.

turnOn(valve_101);

delaySec(30);

turnOff(valve_101);

You can see two problems here. One, if the network hiccups at the end of the delay, your valve may not turn off when you intended. And two, your control program just sits and kills time for 30 seconds. Nothing can be done in this program while we wait for the time to pass. Of course we could start a timer, set a flag variable so we don’t restart the timer each time the program loops, and then have our code check whether the timer has expired.

But we can do the exact same thing by sending a command to an intelligent I/O processor like this:

StartOnPulse (30, valve_101);

Two things happen here: First, the I/O processor receives a single command to turn on our valve AND turn it off 30 seconds later. This is done by sending the valve a pulse that starts and then stops after 30 seconds. So even if the network link goes down, we’re assured the valve will turn off. Second, our control program can move on and not be burdened with keeping track of the 30-second delay. (Plus this is a LOT less complex than using the timer/flag method, thus making your code a lot easier to read and debug.)

Another advantage of using these intelligent I/O commands is that they make your system more robust. For example:

Timers: Generally, timers are not persistent in automation controllers or computers. If the controller cycles power, you’ve lost the timer and how long the point has been on, and when it should turn off. You will need to add a lot more code into the control program to account for this.

Remote I/O: This is a biggie; this is where we started the blog. Networks are becoming bigger. LANs (local area networks) are morphing into WANs (wide area networks).

Your automation controller is located at the site office, but the I/O is across the ways, at the far end of the tank farm. If the network goes down or glitches, it should not mean that your output changes state before it should—or not at all. Thanks to our intelligent I/O processor, the duration along with the point state is being handled AT the location of the I/O point. As long as it has power, the timing function will do its job regardless of the state of the network, or the host PC or controller. The dump valve will turn off when it should.

Relay controller vs. intelligent I/O

Yes, our example here might have been solved with a simple relay controller that does accept pulse commands. However, these relay controllers tend to be very task specific and typically only work in relay applications. But an intelligent I/O system will give you the capabilities of the relay controller, plus so much more.

So simple yet so powerful.

Telling a digital output to turn on or off for a set amount of time in a single command: oh so simple, but oh so very powerful.

We have only just scratched the surface of what intelligent functions are built into our I/O and how we have used them (and in some cases abused them) over the years.

Check out our interactive online SNAP I/O Configurator to build your intelligent I/O solution.

Till next week. Cheers Mate.