Detecting the sequence of alarms

userxyz

Member
Join Date
May 2002
Location
any
Posts
2,768
Hi,

I have a really nasty coding problem :).

So we have a machines with 3000 alarms. Because some engineers want to improve the OEE of the installation, they want to know the right alarm sequence. It speaks for itself that I cannot reprogram the complete alarmlogic for 3000 alarms :). I tried an alternative with searching in a DB when a bit triggers and so one, but this doesn't work well...
A Scada or HMI is too slow because of it's aquisition time, therefor I need to make the right alarm sequence in the PLC...

I'm thinking to try the following in the PLC:
- Blockcopy the DB with alarmbits to a DB with array of bits.
- Make a DB with corresponding array of TOD's (Read Clock).
- When one or more bits are triggered, the TOD is recorded in the TOD's.
- Bubble Sort all arrays with the TOD value's.

What you guys think ?
 
I know some PLC vendor support time-stamp with OPC AE (Alarm & Event) but you need compatible HMI. ie. Contrologix with RSView SE. Probably be the easiest to implement, effort wise.
 
I would try with couple XOR and And commands, with leads to these threads (alarm PDF printing / cengage.com)

http://www.plctalk.net/qanda/showthread.php?t=113938
http://www.plctalk.net/qanda/showthread.php?t=102972
http://www.plctalk.net/qanda/showpost.php?p=690996&postcount=10


First make array of bits 3000 bits long. Then make same code than on PDF example, so you would have arrays of raw alarms, current alarms, unacknoledged alarms, acknoledged alarms with seperated

If you loop all these bits on one PLC scan, you can make array of new alarms (one scan pulse when alarm finded)
Now if you look these bits which are goed to alarm state since last PLC scan you can save TOD time. (all pulsed bits have same TOD time also, because they are looped on one PLC scan)

So now you have alarm TOD times and bits, move these to newest alarm list, and there is no need of buble sort anything.

Only problem would be how to remove alarms from this list, you would maybe need also acknowlegment bits and rotate bits to point correct alarms with same time than you look new alarms :unsure:


ps. Also copying raw alarms to list and searching "alarm state". Remove all finded bits from this list and copy to newest list ( all on one PLC scan) would maybe work. if alarm goews off and on, then copy alarms back to search list

There can't be newer alarms, if you search on every scan if there is alarms and move all new alarm to newest list.
 
Last edited:
Surely you don't get 3000 alarms in a succession, do you?

I'm sure that with a bit of analysis (which they have to do at any stage of the problem solving), some alarms can be grouped and worked individually.
From this, you can perhaps create a trigger and store data in a DB with the timestamps of each of the signals in the group switching to gather when each was triggered.

The other options will work too, but I find that you're collecting data now which eventually will swamp the people asking for it instead of analysing which data they need and work from there.

The other option, if you're using Siemens PLC's, could be to use ServiceLab... If I remember correctly you can get a pretty interesting acquisition time (I did machine movement commissioning with it) and also define triggers to record data which could work if you're taking the focused approach.
 
Can you use both the HMI and PLC?
Let the HMI manage the alarms; operator actions, lists and times.
The PLC only needs to solve the problem of which alarm occurred first.


Example:
The HMI could log the alarm messages and (approximate) times. That also lets you easily manage the alarms, acknowledging, etc.

In the PLC create a circular INT buffer with a list of the triggered alarms. You should only need to know the sequence in which the alarms were triggered. Write the triggered alarm number, increment the array counter.
You can use (correlate) the HMI alarm info to get the times, messages, and tags names.
 
I think what you're looking for is a proper SCADA system that monitors and historicalises alarm data. That's kind of it's main job.

As cardosocea said, if you did have to do something with logic, I'm sure you could spend a couple of days manually recording alarms and work out which ones actually need to be the target of your OEE focus, but in general, this is one of the exact reasons people invest in SCADA.
 
The biggest problem you will have is the order of alarms. If the first alarm goes off when the scan flag has gone past and then another alarms goes off before the scan flag goes past they will be in the wrong order. The second alarm will be picked up on the first scan and the first alarm on the second scan. Not possible from my experience.
 
Hi Combo
You say you have 3000 alarms. Your process must be split into units/cells/lines whatever

The alarms may already be divided into logical groups so if you intend to optimise a certain part of the process your 3000 may be reduced

Alternatively how many of the 3000 alarms actually generateAs Bob B said scan issues relating to order of scan are going to be your biggest issue
 
Hi,

I have a really nasty coding problem :).

So we have a machines with 3000 alarms. Because some engineers want to improve the OEE of the installation, they want to know the right alarm sequence. It speaks for itself that I cannot reprogram the complete alarmlogic for 3000 alarms :). I tried an alternative with searching in a DB when a bit triggers and so one, but this doesn't work well...
A Scada or HMI is too slow because of it's aquisition time, therefor I need to make the right alarm sequence in the PLC...

I'm thinking to try the following in the PLC:
- Blockcopy the DB with alarmbits to a DB with array of bits.
- Make a DB with corresponding array of TOD's (Read Clock).
- When one or more bits are triggered, the TOD is recorded in the TOD's.
- Bubble Sort all arrays with the TOD value's.

What you guys think ?


Since you didn't specify a processor, I'm going to guess ControlLogix L71 or better, and suggest using the ALMD instruction for each of those 3000 alarms. I'm told that Factorytalk view will display the alarms on the alarm summary with the timestamp from the plc, in the correct sequence based on the timestamp. I don't have experience with this solution myself .. but it's on my backlog to try this timestamp in the PLC for Sequence of Events logging.


This will greatly increase your scan time .. but it is simple and direct!


If you don't have a controllogix, I have done timestamps inside the plc, but I have yet to find an HMI that will display the alarms in order by timestamp from the PLC.
 
Main problem

Hi,

Thank you all for your replies allready.

The main problem now is when an alarm occurs that more then one alarm goes active. So on a drive fault for example you get 5 alarms for example. The main reason is the drive, but because the PLC program can cause other alarmbits in the same cycle or the next cycles, the order isn't there in the HMI Alarms and Scada. The HMI and Scada looks with around 500ms polling time to the PLC, but the PLC can cause many alarms in such time frame.

We do have an HMI and SCADA (WinCC) system above this Siemens S7-317 CPU, but this cannot be solved there because they are too slow to handle this.

I don't know the machine and I do not plan to analyse 3000 alarms for regrouping or changing any logic. Therefor I am looking for an other solution.

@Lare:
That looks allmost what I need I think. I now have written also something with an array of bits, and when a bit becomes 1 I give the array index number to a new alarmview window on Scada WinCC. But, this isn't okay, because you only get one active alarm number like this. Repeat Until and you get the first active in the list, for next and you get the last... so no, this isn't working.

However... maybe I can search in the list (array of bits) and when I find one I place it in a new array with integers (alarmnumbers) and then append in that list (or fifo). So using a for next loop, if founded an alarm, place it in de alarmnumbers list. This will work for all alarms that are not triggered in the same cycle...
Once all alarms solved I can clear that list...

The order is indeed still a problem when alarms occur in the exact same cycle, but most of the alarms are in sequence like this. For example when hitting an emergency stop, it takes a while before you get air pressure alarm, I mean, it will take at least some PLC cycles because something physical haoppens after the emergency stop and has to come via feedback (inputs).

Kind regards,
Gerry
 
You may not have enough memory on the PLC for this, but can't you associate a time stamp with the alarm bit and have an instruction save the time stamp whenever the alarm is triggered?

One other thing I remembered is that you can write to the diagnostic buffer in the PLC... this is not ideal, but it could give you an indication of the sequence in a couple of alarms, though it is less than straightforward to get the information.
 
Read my comment above - even in the PLC the alarms will not necessarily in order due to the scan and when the alarm turns on - no way around the scan!
 
I hear you

Hi,

Yes I hear you.
The problem is indeed that several alarms can be triggered in the same scan.

What about Prodiag, the same problem can occur, the order will also not be the real order when more then one alarmtrigger is in the same scan...

The main problem (I think) is the way the alarms are programmed. Some alarms should be ignored when the cause is something else... for example... alarm air pressure shouldn't be shown as an actual alarm when an emergency stop is pressed... But this should be solved in the alarm logic. The problem is that the supplier made all needed alarms but didn't care much about showing the real pending alarms or the order of the alarms. This is frustrating the engineers who are doing OEE on this installation.

Don't really know what I will do with this one... i think the best way is that someone changes the alarm logic and follows this up...

Kind regards,
Gerry



Read my comment above - even in the PLC the alarms will not necessarily in order due to the scan and when the alarm turns on - no way around the scan!
 
Hi,

Yes I hear you.
The problem is indeed that several alarms can be triggered in the same scan.

What about Prodiag, the same problem can occur, the order will also not be the real order when more then one alarmtrigger is in the same scan...

The main problem (I think) is the way the alarms are programmed. Some alarms should be ignored when the cause is something else... for example... alarm air pressure shouldn't be shown as an actual alarm when an emergency stop is pressed... But this should be solved in the alarm logic. The problem is that the supplier made all needed alarms but didn't care much about showing the real pending alarms or the order of the alarms. This is frustrating the engineers who are doing OEE on this installation.

Don't really know what I will do with this one... i think the best way is that someone changes the alarm logic and follows this up...

Kind regards,
Gerry

If this is the problem, going through the exercise of collecting this data will end up being pointless as you'll end up only confirming your suspicion and not really making any headway into solving the alarm groups popping up.

This is something like a current loop gets open, you have a hardware fault alarm, a current loop alarm and a pressure/Tx not available alarm, etc... the solution for this would start from putting together a standard (which can be applied to new builds from then on), and modify the software to match the standard in order to avoid two alarms for the same event.
 

Similar Topics

I've been called to a site to assist with an ASi fault. The line has been down for a couple of weeks following a failure of the ASi power supply...
Replies
6
Views
1,240
I am looking at an application where I will need to detect small hairline cracks in stamped metal parts. The sensing will need to be done in the...
Replies
10
Views
1,062
Hello everybody, I am working on a project which has HMI FTView SE 13 (Local) and controllogix L71 PLC. I have a question how does PLC detect a...
Replies
0
Views
500
So, we have one servovalve that is very critical to machine operation and idea is (or was) to detect if valve gets disconnected from analog output...
Replies
11
Views
2,751
I had bought a used PLC before but I had to return it. Once in a while its run mode shut off momentarily. I had the PLC on my desk. (No I/Os...
Replies
22
Views
5,301
Back
Top Bottom