Alarms' Stacking

[ATU]

But his fault was occuring on the FFU instruction?
However, if the previous FFL instruction did increment the count after it executed, maybe the next time it used the control structure was in the FFU and then that caused the fault?

Although, It probably wouldn't be a bad a idea to monitor that count variable in the control structure and inhibit the FFL instruction anyway if the count was at the end.



If the FIFO empties, it is supposed to return zero's.
You could use the empty bit to shut down the timer.

 

[adamjstewart]

Apologies, my bad.

From the FFU help file,

A major fault will occur if: Length > FIFO array size
Fault type 4
Fault code 20

Same thing?

 

[ATU]

I don't think it is the same thing. That is why I wanted to see his tag list. The FFU instruction decrements the position in the FIFO. His length should not change, if I understand how the instruction works.

What happens if executes the FFU when the position is 0? Do you get the fault?

 

[Money4Nothing]

I don't see the point in trying to separate the alarms that occur in one scan. Suppose you have two inputs that switch at exactly the same time, surely the input that gets scanned first will show up as the first out even though it occurred at exactly the same time.
Am I missing something?

This is exactly what I was thinking.

If multiple alarms occur in the same scan cycle, then you report that they occured simultaneously. If you have have a safety scenario that requires the reaction to an alarm condition be faster than one scan cycle, then we have a different issue altogether. If you are merely interested in reporting, I don't think you need to resolve to the time scale of a scan cycle.

$

 

[Brian123]

This is exactly what I was thinking.

If multiple alarms occur in the same scan cycle, then you report that they occured simultaneously. If you have have a safety scenario that requires the reaction to an alarm condition be faster than one scan cycle, then we have a different issue altogether. If you are merely interested in reporting, I don't think you need to resolve to the time scale of a scan cycle.

These were my thoughts exactly. However, as it was pointed out to me, calling a subroutine multiple times per scan as you detect alarms might be a good way of keeping the error logging simple and easy to follow in the ladder. It might look like one is trying to timestamp each alarm as it happens, but really it is a method of keeping your program clean.

Brian

 

[adamjstewart]

I tried this, or rather my perception of this.

Subroutine one, being scanned all the time:
Each alarm (total of 5 in the test) represented as a discrete output.
The rung after each discrete output, uses an XIC (with one shot), of that output to trigger the JSR.

The problem I had, if all 5 alarms are triggered with the same trigger condition (ie same scan), my FFL instruction in the 2nd subroutine would only increment once. I was triggering the FFL with one XIC for each alarm. A branch for each alarm as input conditions for my FFL.
It seemed anyhow, that even though I was jumping to the FFL subroutine, the FFL was not getting triggered.

So, I abandoned the concept of using JSR's to run the FFL subroutine. It just wasn't incrementing the .POS value.

It would take some extremely fast hyper-alarming for several to occur in the same scan anyhow.

Anyone have ideas as to why my FFL wouldn't be incrementing?

 

[ATU]

The FFL is edge triggered. Each time you called the subroutine the enable line for the instruction is always true. Then you leave the sub remaining in this state, so the instruction is never scanned in the false condition. It never sees the transition.

 

[dsking]

no i don't get the fault if the position i 0 on the FFU.
I will post the taglist up shortly.

 

[dsking]

ATU: Here is the taglist.
Hopefully its readable.

 

[adamjstewart]

The FFL is edge triggered. Each time you called the subroutine the enable line for the instruction is always true. Then you leave the sub remaining in this state, so the instruction is never scanned in the false condition. It never sees the transition.

That was how I was intending for it to work, but for some reason, either the sub was actually only getting called once, or it was the FFL that was only incrementing once. I'll try it again...maybe I was dozing off that day...

 

[dsking]

I have also attached a copy of the logic maybe that will help.

 

[adamjstewart]

ATU: Here is the taglist.
Hopefully its readable.

DUMP is a single DINT
STACK_1 is a single DINT

In the screenshots, you have expanded a single (32 BOOLs) DINT.

I think STACK_1 needs to be an array of DINTS
Example DINT[100]

That's why you don't get a fault when .POS = 0, the FIFO=STACK_1 (single DINT) equals the configured size of the FFL, Length = 1
Unless I'm out to lunch again. What was your length again?

 

[ATU]

Dsking,

OkiePC told you to fix the array. If you do that, your faults will probably stop.

 

[dsking]

OOPPs Ignore the earlier post.
I have also attached a copy of the logic maybe that will help.
I just put .zip at the end of the file. Just replace that with .acd I hope tha t works.

 

[ATU]

adamjstewart,

Try reseting the .eu bit before you exit the subroutine.