Good morning Douglas,

Thanks for your question.

This question often arises because the programmer is unsure of how their program will react if the input or output update happens in the middle of executing his program.

The problem with this concern is that in most applications the physical I/O, and the I/O modules themselves, are several times slower than the PAC's program scan.

In those applications it is nearly impossible for field devices to turn on or off simultaneously, and therefore their states will always be stretched out over multiple program scans no matter what.

An exception to this is when all of the inputs have the same on and off time specifications, and “knowing” the order of operation is crucial to your control program.

For instance, if you are monitoring dozens in an electrical generation system, it can be extremely important to know the exact order the breakers trip in order to safely control the system.

In an application like that, you'd often have the highest priority, highest speed periodic task using CPS instructions to synchronously copy input values from Input modules to internal tags prior to running your control program to detect if any of the inputs had changed state. After which you may also need to use CPS instructions to copy your output tag values to your actual output modules.

Aside from applications like the above, it typically makes no sense to buffering I/O because (as you said) it involves a lot of additional code, and most field devices and I/O modules update many times slower than the I/O and Program Scans.

As far as your second question about re-using an output tag set earlier in the program scan as a permissive later in the same program scan, there's no problem with this as even if you waited a scan to read the actual output, that wouldn't mean that the output device was on yet but instead it would just mean that you've written a “1” to the output module.

When the actual Output on the Output module has been commanded to turn on (set to 1,) it still takes several milliseconds for the output module to provider power to the connected field device, and then many more milliseconds for the field device to sense that it's input voltage is high enough to be considered as “on,” and then even more time for it to actually start whatever operation it is suppose to do (like start to open a valve or close a contact, etc.)

Hope this helps!

Shawn Tierney,
Instructor at The Automation School