Another control logix query

[Alan Case]

Still trying to get my head around certain aspects of Control logix.
I understand that io is scanned assynchronous to program scan but I cannot see why you would need to buffer an input or an output before and after you use them. Could someone explain why this is necessary and is it done as a matter of course with all io.
As I see it if an input changes while a rung is being evaluated then the result of that rung will be closer to a real result with no buffering. ie stale data is not being used

Regards Alan Case

 

[Peter Nachtwey]

Why buffer or synchronize inputs?

In many applications/rungs it will make no difference if the I/O is buffered to synchronize it or not, but:

1. What if an input is used a couple of times in a rung or scan.
2. What if two or more inputs are used together.

I am sure some one else can find more reasons to buffer the inputs.

Doesn't this make you wonder if not buffering/synchronizing inputs is safe?

TANGENT or MORE ADVANCED TOPIC for blocks of register data.

When communicating to and from our motion module we don't need to buffer the outputs or the inputs, BUT we have what we call a 'synchronization' register for the input and one for the output. When issuing commands the data can be updated with little care but it is ignored by the motion controller until the output synchronization register is changed. At this time the motion controller accepts the data all at once. In reply the motion controller updates the status area and changes the synchronization register to the same value as the output value when done. This lets the PLC know that the response or status is ready and it is the response to the last command. This is not unlike the 'TSN' or transaction sequence number that is used in many communication protocol like 'DF1'. Use this trick when communicating between two Control Logixs or a Control Logix and another intelligent device like a motion controller.

Obviously, small I/O devices will not have TSNs or synchronization registers so buffering is a good choice.

Our motion controller ALWAYS buffers digital inputs using hardware latches and even then we copy the data in to buffers. Would you have it any other way? I wouldn't.

 

[Rick Densing]

I haven't used CL, but I can think of why you would want to buffer.

Main reason- then it programs like a scan-based PLC. Easier to migrate your thinking.

Another- if there are two or more pieces of code that deal with the same data and you want to be sure that it is all from the same moment in time.

I can see your point about the freshness of data. No need for immediate commands. It does take a change in program-think.

 

[schick]

The absolute simplest reason I can think of would be if you had an input which didn't last as long as a full scan interval.

 

[Allen Nelson]

I always buffer my input and outputs anyway. I have one "Mapping file" that handles all transactions between the real I/O and the buffered I/O.

That way, if things change (point on a module goes bad, sensor changes type/voltage, changes from NO to NC, whatever), I only have to change the code in one place.

I can't come up with any good examples, where it would be surprising to have an input bit be ON on rung 20 where it wasn't in rung 2. But that's one potential risk.

 

[Alan Case]

Hi Allen. I havent been able to think of an occurrence that would be bad if an input was on in rung 2 and off in rung 20 either. That was what got me thinking as the AB manual basically says that you should buffer all IO. The input you use on the rung preceding its use and the output on the rung after its use.

Regards Alan

 

[[email protected]]

Make a dummy smart

I understand what you are trying to accomplish, as far as getting the scan to operate just like a PLC's would, but my question is a simpler question which may take a more difficult answer. We have a program on site that has it's own subroutine called I/O Update. It states the goal of the subroutine at the top of the ladder. Pretty much the whole subroutine is just Moves from Localblah blah blah to LOCALblah blah blah. Can someone explain to me how simply moving this data to a new set of tags with all capital letters can accomplish data being updated as a PLC would? I've never been to any classes on CL. I can find my way around it and do most of the stuff I want to do without much trouble, but I've never really gotten any theory about this buffering thing. To add to my confusion, we also have 2 other fairly complicated lines controlled by ControlLogix that I believe do not have any buffering done, and they seem to be just fine. Feel free to clear the clouds from my mind on this subject.

Russ

 

[93lt1]

Russ-
If you have a ladder that simply copies the I/O data into other memory locations, This is a buffer.

The ladder you talk about is probably first (possibly last) in the scan order. If you have one ladder copying all of your I/O data into other PLC memory locations, you have effectivly locked the state of the I/O for that entire scan (provided you are scanning that ladder at the same rate as the rest).

 

[Jiri Toman]

buffered I/O

Logix 5000 I/O scan is asynchronous and equivalent to the immediate I/O instructions in PLC5/SLC500.

PLC5/SLC500 have I/O which is synchronized with the ladder scan. The processor scans the I/O first and then the ladder logic starting at the top rung. In order to accomplish the same thing you need to
move I/O data to a buffer on the first scanned rung of
your program. This technique should be used for most programs
as a pre-caution. The reason for this is that you could have
intermittent logic malfunctions if the I/O was updated
asynchronously. For example you could have logic consisting of
20 rungs that would utilize a specific input point. These rungs could be spread all over your overall program. Should the input get triggered while only say half of these 20 rungs were scanned, the resultunt logic could potentially be erroneous and causing
mysterious machine operation. This is truly dependent on your actual
program and on the timing of the input activation.
Very unpredictable!

 

[Gerry]

In the majority of cases, the asynchronous I/O scan does not produce any noticeable effect. Even if one input is involved in the control of several outputs, a one-scan time difference between output operations will still appear to be simultaneous.

However, there are situations where the async scan can cause trouble and it will invariably be intermittent. Generally, the problems would be with a series of calculations or some sequencing logic. I first experienced the consequences with a PLC3 many years ago. What was occassionally happening should have been a logical impossibility. After hours of staring at the logic and pondering the conundrum, it dawned that if a particular input used in two consecutive rungs changed state between rungs then the problem was obvious. I buffered the input and the problem vanished.

With AB PLC's, local I/O is synchronous and remote I/O is asynchronous. The 1774, PLC3, and PLC5/250 only have remote I/O and so are completely asynchronous. The PLC2 and PLC5 can have a combination of local and remote or all local so I/O scan could be all synchronous or a combination. The SLC is always synchronous. The exception to the local/remote rule of course is ControlLogix in which everything is asynchronous.
There was a rumour about development of a local I/O system for the 5/250 but I don't know if it ever happened.

 

[[email protected]]

I get it, duh

93lt1, thanks for the quick explanation. I guess I forgot that once something is copied to it's location, it holds that state until it's changed. Simple things I forget sometimes.