X number of trips in y time

If I wanted to bring an alarm on if I get a trip more than 3 times(variable from an HMI)in an hour(again variable from an HMI)what would be the best way of acheiving this? I have looked at using an array of N registers with a trip counter as a pointer and subtracting the first and last register time value and comparing this with the HMI value.Another possibility is a FIFO function but I am unfamiliar with this.
I am using an SLC 5/05.
I am tying myself in knots and just wonder if anybody has got a function like this working in the past.
Any help is most appreciated.

How many signals do you need to monitor? Sounds like you are over complicating it.

I would use a simple counter, reset the counter when desired time has passed. For testing you could create a TON and use the .DN bit to reset your counter.

If C5:0.ACC >= HmiAlarmVar, set alarm. If Alarm condition is active, don't increment C5:0. If TON.DN is set, reset C5:0

Does this help?

ELake20 said:

How many signals do you need to monitor? Sounds like you are over complicating it.

I would use a simple counter, reset the counter when desired time has passed. For testing you could create a TON and use the .DN bit to reset your counter.

If C5:0.ACC >= HmiAlarmVar, set alarm. If Alarm condition is active, don't increment C5:0. If TON.DN is set, reset C5:0

Does this help?

Click to expand...

I assume the OP wants to know if there are three trips in a rolling hour.

What I would do is create three latched values. When the first trip occurs I'd latch the first one. Then when the second trip occurs AND the first latch is ON, I'd latch the second one. Then when the third trip occurs AND the second latch is ON, I'd latch the third.

On each latched bit, I'd start a one hour timer. When the timer times out, I'd reset the latch. I'd then count the number of latched values - if the sum is ever 3 you have your problem condition.

May sound more complicated than it really is. You will need to be sure that each trip only latches one bit at a time.

Lets see if I understand you correctly: You want a variable number of faults and a variable time period.

Is there an upper limit on the number of faults?

Alas, if only the SLC had an FAL instruction. Even without it its really not too bad as long as the upper limit isn't large, say no more than ten.

See attached. Its just four rungs and it probably needs some work for what you are wanting but hopefully it helps.


Edit:
I do see one problem with it - between rungs 1 and 2 you need to shift everything down when N10:0 decrements to zero.

Change rung 1 to
XIC T4:0/DN BST EQU N10:0 1 OTE B3:0/3 NXB GRT N10:0 0 SUB N10:0 1 N10:0 NXB GRT N10:1 0 SUB N10:1 1 N10:1 NXB GRT N10:2 0 SUB N10:2 1 N10:2 NXB GRT N10:3 0 SUB N10:3 1 N10:3 NXB GRT N10:4 0 SUB N10:4 1 N10:4 NXB GRT N10:5 0 SUB N10:5 1 N10:5 NXB GRT N10:6 0 SUB N10:6 1 N10:6 NXB GRT N10:7 0 SUB N10:7 1 N10:7 NXB GRT N10:8 0 SUB N10:8 1 N10:8 NXB GRT N10:9 0 SUB N10:9 1 N10:9 BND

Define the symbol SHIFT_DOWN to B3/3. This will detect the need to shift everything down one register.

And insert this between rungs 1 and 2. This will do the actual shift. You might be able to use FFU instead, but this makes it obvious whats going on.
XIC B3:0/3 BST MOV N10:1 N10:0 NXB MOV N10:2 N10:1 NXB MOV N10:3 N10:2 NXB MOV N10:4 N10:3 NXB MOV N10:5 N10:4 NXB MOV N10:6 N10:5 NXB MOV N10:7 N10:6 NXB MOV N10:8 N10:7 NXB MOV N10:9 N10:8 NXB CLR N10:9 BND

Its ugly, but we can't use COP because we are shifting the wrong direction, unless you wanted to use an intermediate file. Hopefully it will give you some ideas - sorry, can't spend more time on it.

Thanks for the replies

Thanks for all the replies. When I get back to the desk in the morning I'll have another go. Cheers.

pauly said:

Thanks for all the replies. When I get back to the desk in the morning I'll have another go. Cheers.

Click to expand...

JHarbin said:

I assume the OP wants to know if there are three trips in a rolling hour.

What I would do is create three latched values. When the first trip occurs I'd latch the first one. Then when the second trip occurs AND the first latch is ON, I'd latch the second one. Then when the third trip occurs AND the second latch is ON, I'd latch the third.

On each latched bit, I'd start a one hour timer. When the timer times out, I'd reset the latch. I'd then count the number of latched values - if the sum is ever 3 you have your problem condition.

May sound more complicated than it really is. You will need to be sure that each trip only latches one bit at a time.

Click to expand...

Thanks JHARBIN, Idon't quite follow the bit about resetting the latches and then counting the latches.

pauly said:

Thanks JHARBIN, Idon't quite follow the bit about resetting the latches and then counting the latches.

Click to expand...

You will count the number of latches (each latched bit will indicate an individual occurance of a trip). If there are 3 then you have your problem condition.

I made a couple of assumptions - primarily that after 3 you don't care how many you have. If this isn't the case, then you will need more sets of latched bits.

Since the time frame is one hour, once a trip occurs it will stay latched for one hour so that it can be counted. After the hour is up, it is reset (or unlatched) so that it is no longer counted. That is why I start a one hour timer which is enabled by the latched bit. When the timer completes, it unlatches the bit. There will be one timer per latched bit.

Lets say a trip occurs at exactly 12:00. You will have one latched bit. Say another occurs at 12:45, now you have two. If the third occurs before 1:00, you will have three, but if it occurs at 1:01, the first one will be unlatched at 1:00 so you will show only one, then at 1:01 you will have two again. As long as you don't have another before 1:45, you will be fine. That's when number two will roll off.

Again, the only issue is that you need to configure your logic so that only one trip is logged (Bit Latched) per event.

Sorry - I can't show you this in ladder logic - I do most of my programming in block. I could do it in ladder, but I'm in the middle of several projects. I just thought my hints would help.

I originally considered using multiple timers and latching them in using the /TT bit, but you indicated that you wanted to handle a variable number of faults, where that number was settable from the HMI. Hard programming timers doesn't lend itself to that very well. Thats why I recommended using a file where the time period set on the HMI could be loaded into as many registers as faults were allowed, and then each word in the file could be decremented once a second.

Now that I've had a lunch hour to think it over, here is an example that is similar to the first but it is a little simpler. It uses a a LIFO queue (last in first out) and LFL and LFU instructions.


Choose a LIFO size that is equal to the maximum number of faults you are going to allow to be selected on the HMI. The attached assumes that will be ten again.

Now each time a fault occurs use LFL to load the time period (in seconds) set at the HMI into the LIFO stack (N7:2 in the example). If the stack is full then unload one value first. After a while the stack will always be full, but don't worry about it, mostly it will be full of zeros. The unloaded value will always be zero and we will ignore it. The stack also won't contain more non-zero values than what is set for the number of faults allowed except if you decrease the number of faults (N7:1) while there are existing faults. However those will still decrement to zero so it probably doesn't need any exception handling.

LFL is a transitional instruction so we'll load a new value to the queue only once per fault.

Now, same as before, once every second decrement the value of every register in the LIFO that is greater than zero. Then count how many are greater than zero.

This is what I came up with. Do not have RS500 here at the house. It's a Logic Drawing in Excel.

Interesting challenge. I would be thinking of a fifo of the timeofdays when the alarm was generated if i was using Siemens. I dont use SLC so cant say on the exact solution

CORRECTION.

Left out NC in front of timers.

Pauly, After a little more thought. You would need additional timers and counters to raise count limit above 3. Timers and Counters would have to equal Maximum Counts allowed before multiple trip detection.