When to NOT Buffer IO?

khelza

Member
K
Join Date
Sep 2015
Location
Ontario
Posts
67
I'm doing a write-up which includes the importance of Buffering IO in newer Asynchronous-operation PLCs.

I'm trying to be as descriptive as possible, which includes explaining when NOT to buffer.

So far, I've come up with:
- older synchronous scan PLCs
- safety or interrupt related functions
- analog values

However, because I don't deal with these scenarios often, or really ever.. I don't know to word it eloquently and would love some input from others, or links to resources which explain it well.

:unsure:
 
Last edited:
Why not buffer analog values?

An the answer to your question is either "Buffer if you want to" or "Follow company policy/Design criteria to the letter"

I tend to buffer everything, no matter what platform, as it makes code reuse and testing soooo much easier.
 
You speak of "newer" async and "older" sync PLC's.

Are any PLCs truly asynchronous besides the Logix family?

Siemens PLCs, for example, communicate asynchronously, but they buffer the io data for you, so the code behaves mostly synchronously by default.
 
rdrast said:
the answer to your question is either "Buffer if you want to" or "Follow company policy/Design criteria to the letter"
Click to expand...

Sorry, but this is not the answer to my question, because the question is when NOT to buffer (NOT being the operative word). I already understand the important of buffering.

Buffering "if you want to", should not be suggested because it doesn't take into account the operation of the PLC (synch/asynch) or how the code functions.

The company template is designed to buffer I/O, but one of the template designers mentioned that in certain cases, although uncommon, buffering is not required or useful.

So my question remains.. when is it useful to NOT buffer IO?
 
Okay Khelza, Whether to buffer or not is entirely dependent on YOUR specific application. There is no hard and absolute rule. Feel free to make one up for yourself however.
 
The only case I can imagine, when buffering should NOT be done, is deliberately writing a code that processes IO change within a single scan. I can hardly imagine a need in such, but theoretically it is possible.

If the question is when buffering does harm, the answer is simple: whenever you may need the data refresh faster than it's being buffered.
This includes, but may be not limited to buffering in a task whose cycle is slower than the one's using the buffered data.

And by the way...
Buffering is really such only if done once per program cycle.
If there are tasks with different cycle, each should have own buffering of the same I/O.
 
When you are not going to use the unbuffered input more than once, you don't have to buffer it.

For instance say you detect some product with a photoelectric sensor. To avoid false triggering you have the unbuffered input driving an on-delay timer set to 0.2 seconds. Since you don't need the unbuffered input and only use the output of the on-delay you don't have to buffer the input. Preferably you put things like that first in your program.
 
Sergei Troizky said:
The only case I can imagine, when buffering should NOT be done, is deliberately writing a code that processes IO change within a single scan. I can hardly imagine a need in such, but theoretically it is possible.

If the question is when buffering does harm, the answer is simple: whenever you may need the data refresh faster than it's being buffered.
This includes, but may be not limited to buffering in a task whose cycle is slower than the one's using the buffered data.

And by the way...
Buffering is really such only if done once per program cycle.
If there are tasks with different cycle, each should have own buffering of the same I/O.
Click to expand...
+1

Back in Logix5 (and maybe Logix500), there was and IIN, immediate input, instruction. This instruction updated the input image for the input word addressed in the IIN. The time I recall seeing such an instruction used was in an STI file, which is essentially a task with a different execution time from the main program.
 
mk42 said:
You speak of "newer" async and "older" sync PLC's.

Are any PLCs truly asynchronous besides the Logix family?

Siemens PLCs, for example, communicate asynchronously, but they buffer the io data for you, so the code behaves mostly synchronously by default.
Click to expand...

IIRC the PLC-3 was asynchronous.
 
I usually buffer I/O on a ControlLogix using an InputMapping and OutputMapping program. The exception is I/O for PID loops. The input and output mapping for those I/O happens in the PID task.
 

Similar Topics

M
Diagnostic buffer
Hi, is there a way to change the time and date in the plc so they appear right in the diagnostic buffer. Also am I right in thinking the error is...
Replies
1
Views
40
RVaughan
RVaughan
J
Micro850 ASCII Buffer Not Operating Properly
I've been developing a tester using a Micro850 in Connected Components Workbench and part of that tester requires me to scan a barcode every test...
Replies
11
Views
2,171
drbitboy
drbitboy
K
UPS or Buffer Modules
Does anyone have any recommendations on UPS or buffer modules that can handle power flickers? We don't need a system that can back up for an...
Replies
1
Views
982
enaq
E
J
S7-1200 Clear Ethernet Buffer
Hello, I am using an S7-1200 with a Moxa N5250A to read data from a weigh scale, but occasionally the scale will send a couple of frames of data...
Replies
2
Views
1,613
Jonnie_R
J
C
Control Logix Ethernet Card Buffer Overrun
I have a system that is using TCP sockets. There are 5 connections between the Ethernet card and the end devices (smart conveying system)...
Replies
0
Views
696
creativepaper
C
Back
Top Bottom