Buffering I/Os?

I've recently started PLC programming (learning it as part of my new job in controls), and I've noticed it is common practice to buffer your inputs and outputs in your process to a controller tag/variable.

From what I've gathered, this acts as both a safety measure (if I/O devices fail?) as well as ensures operations that depend on sequences of events occur properly.

Could someone elaborate, or enlighten me if I have the wrong idea?

Thanks!

The two things I have seen this useful for:
Sometimes it can be useful in testing a program if the processor does not allow forcing of I/O. You can toggle a pointer bit and make the mapped I/O not look at the real world I/O during a test.
If you have standard logic that is cut and past but the machines are not always wired the same then you can just map the real world I/O to your tags and not have to find everywhere in the program the tag is used.

We buffer all of our I/O, anticipating that "in the future" we will either expand/modify the program or update the physical I/O in some way. Buffering makes it simple to re-address the I/O in a single location, rather than at ever point through the program where it is used.

Many people write programs with the assumption that the state of an input (as reflected in the input table) at the beginning of a scan is maintained through the entire scan. This is how all the PLCs I had worked with before the Control/Compact Logix platforms. But these newer platforms update the I/O asynchronously to the scan.

Therefore some buffer the inputs at the beginning of the scan so that they behave more like the familiar ones.

I/O buffering is a good practice and programmers embrace it for quite a few good reason. It's very essential you normalize I/O if you have an asynchronous processor like AB controllers. But these days for a normal load, the scan time is so remarkably fast (for eg. ControlLogix), it hardly matters. You can also just simply change the instruction type when you buffer your inputs from an XIO to XIC or vice-versa if ever the wiring gets changed. By buffering, you only have to change in one place rather than doing everywhere in the logic. I'm sure there could be other reason but these were a few I could tell you right away!

Can you guys post an example rung of how this would look? I had a PLC guy one day show me some time ago, I thought this was cool, but I forgot how he did it.

Thanks,
Joe_WaZoo

From what I've seen / been doing, there is a separate Subroutine that buffers the inputs:

For discrete input:


|---[ Input ]------------------------------------( Buffer )---|


Reverse for DO

For analog input (RSLogix style):


|------| MOV |----------------------|

MOV Instruction
Source: Input
Destination: Buffer



Swap source and destination for AO.

Here are some options for inputs: 1) create individual rungs for each I/O point to set/reset the buffer bits based on the I/O state(s) 2) copy input module words over to the buffer words 3) if your processor can deal with tables/arrays, copy the entire input table -- assuming you have contiguous points -- over to the buffer memory at once

Simply reverse the logic for the Output buffering to copy the buffer data over the top of the output memory.

The choice is largely based on the capabilities of the PLC you are using and the number of I/O points you have to deal with.

I prefer using single-dimension arrays or tables whenever possible but other users may prefer other methods for their own reasons.

kdcui's mention of Subroutines is an option for "location" of the mapping code. We have a couple of PLC5 applications where the I/O buffering is simply handled at the beginning and end of the main ladder program. In AutomationDirect PLC's, we usually use Stages to transfer data in (at the beginning of the program) and out (at the end of the program) of the buffer memory.