First Out Logic on ControlLogix platform

"I need to show what I/O point ( both digital and/or analog) trips the system. I am going to use CNTRLGX I/O and processors. This "First out" trip logic is going to be passed to a Foxboro DCS system via the Prosoft Modbus card. I have used a "fist trip bit" in the past that was based on processor scans. But now I am faced with the question what happens if the processor is scanning and the first out trip happens after the processor has scanned that rung.

Does anyone have any sample code or good ideas to work from??"

Always pays to check the RA KnowledgeBase for this kind of thing, there really is heaps of stuff in there:

Note G17754 - How to determine when a modules data has been updated

"Most modules have a RollingTimeStamp varaible assoicated with it. Each time the data for any channel changes, the RollingTimeStamp value will change. By reading this value, you can determine if the data has actually been "Refreshed"; In a PLC-5, you would have used the DN bit on the BTR or BTW for that module. For 1756 output modules, the RollingTime Stamp will change when the output value changes, for Input modules the RollingTime Stamp value will change each time the module sends updated data. This time stamp will roll over at 32767. "

This is the simplest way to do it. If you require a more sophisticated solution there are specific Sequence of Events systems available.

This sort of question arises quite frequently. The biggest problem is that the detection is scan dependant.

But now I am faced with the question what happens if the processor is scanning and the first out trip happens after the processor has scanned that rung.

Click to expand...

I have yet to find a way around that problem. If anyone does, please let us all know.

Phillip, are you saying that the module has a built in time stamp function from which you could trace a range of events in a scan and determine which one came on first, independant of the scan? That would be a neat trick but I would imagine require quite a bit of code to make the "first on bit" detrmination. With modern high speed processors scanning fairly large programs in less than 10ms I imagine it would be quite difficult.

Much has been made of how ControlLogix input tables are updated asynchonous to scan. It's funny, but it really doesn't play much of a roll.

The question that you must be able to answer is: How much of a delay will there be between two events, a "cause" and "effect" signal, as to determining which one caused shutdown.

If it's less than an average CLX scan time, then you can do it simply, using something like the following logic:

   +--- EQU --+    EVENT_1     Trip_ID.0

---| Trip_ID  |------| |---------(L)

   |      0   |

   +----------+

 

 

   +--- EQU --+    EVENT_2     Trip_ID.1

---| Trip_ID  |------| |---------(L)

   |      0   |

   +----------+



(etc.)

Trip_ID is a DInt. The above code sets one bit in Trip_ID only if no other bit in it is set. If you need more than 32 alarms trapped, just use multiple DINTs with multiple EQUs.

Now, if the two events happen pretty close to simultaneously, then you need to tell the PLC which one you want to log when that happens. That modification would look something like this:

   +--- EQU --+    EVENT_1    EVENT_2    Trip_ID.0

---| Trip_ID  |------| |---------|/|-------(L)

   |      0   |

   +----------+

 

 

   +--- EQU --+    EVENT_2    Trip_ID.1

---| Trip_ID  |------| |---------(L)

   |      0   |

   +----------+



(etc.)

In this case, it's assumed that if Event 1 and Event 2 happen on the same scan, then the PLC will log the trip as having a root cause of Event 2.

But if Event 1 occurs even one scan ahead of Event 2, the PLC will erroneously log the problem of having been caused by Event 1.

But the problem isn't really traceable to the asynchrounous scan stuff. While it's possible that the status of Event 2 could change from the first rung to the next, that's not what gave the erroneous result. The fact is that Event 1 was set in the PLC before Event 2 was.

But there's not much you can do about it. And it's really no different than a PLC-5 or SLC (or most other PLC) might have, where the circuitry of the input module took one scan more time to detect the threshhold voltage at the pont between two "simultaneously" triggered inputs.

All CLX modules have their own Rolling Time Stamp clock; From the Help File:

"CST Timestamped Input Data

The module returns general fault and input data along with the value of the system clock (from its local chassis) when the data changes. The system clock resides in the module, and is synchronized with all of the other system clocks in the same chassis (when there is a CST master in the chassis).

The timestamp samples the system clock after the data has been sampled and all filter delays are completed.
If Change of State is enabled for any input points, the timestamp reflects the time when the module detected the change of state.
If the module detects more than one change of state before it manages to send the data out (either because there are several input points with the change of state enabled, or because the one point is changing rapidly), the timestamp is written into the buffer each time the module detects a change of state. Thus, the timestamp reported to the controller reflects the last enabled change of state that occurred before the data was transmitted."

This method will let you discriminate between events on DIFFERENT modules, but not on different inputs on the same module. In order to do that you need a specific SOE module. There are two input modules:

1756-IB16ISOE for 24v DC

1756-IH16ISOE for 125vDC.

ControlLogix SOE

Curious - http://forum.mrplc.com/index.php?showtopic=3599