Detecting the sequence of alarms

2 example blocks

Here are 2 example blocks.

Example of a profibus module, bundled bits in IO_Alarm are linked to HMI and SCADA:


Example of a supply faults, bundled bits in O_Alarmen are linked to HMI and SCADA:


So everything is builded in an OOP base, but alarms are linked in an alarmword on the outside of each FB.

The grouping is not done in different classes (HMI) or per unit. The FB's are bundled per equipment. There is an FC with all Scanner objects, FC with all the drives, FC with all Valves, etc etc... and the alarms are coming directly out of these objects... meaning that there is only the internal object logic wich don't looks to other alarms or whatever.

Rebuild or change the whole thing is a little tricky in an installation that does not allow any downtime.

So for the new factory everything can be programmed in an other grouping way, but with this installation I'm a little stuck..

I think we need to put a guy on this to 100% focus on rebuilding the alarm logic or leave it as it is...

Combo said:

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.
[..]
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...

Click to expand...

Exactly !
Alarms should only be triggered by the conditions that is described in the alarm text. If the alarm can be triggered by other causes, then the code does not take other possible causes into account.

For example, monitor the 24V supply to sensors, and when the 24V fails trigger the one alarm for the 24V and mute all the alarms for the sensors.

It takes some effort, but IMO it is the correct way to do it. We do this as much as is possible, even though it can be difficult to achieve 100% hit rate that alarms are only triggered by the conditions described in the alarm text.

Thanks

Thanks JesperMP.

JesperMP said:

Exactly !
Alarms should only be triggered by the conditions that is described in the alarm text. If the alarm can be triggered by other causes, then the code does not take other possible causes into account.

For example, monitor the 24V supply to sensors, and when the 24V fails trigger the one alarm for the 24V and mute all the alarms for the sensors.

It takes some effort, but IMO it is the correct way to do it. We do this as much as is possible, even though it can be difficult to achieve 100% hit rate that alarms are only triggered by the conditions described in the alarm text.

Click to expand...

Having chased multiple alarms and spurious events in a single scan, I began using an event logged bit for each event condition and jumping to a subroutine that timestamps and logs the occurrence in an array then setting the event logged bit on return. I typically allow for 32 events in the array for smaller systems. I also jump to the same subroutine when the condition passes to log the change and time

Ventax said:

Having chased multiple alarms and spurious events in a single scan, I began using an event logged bit for each event condition and jumping to a subroutine that timestamps and logs the occurrence in an array then setting the event logged bit on return. I typically allow for 32 events in the array for smaller systems. I also jump to the same subroutine when the condition passes to log the change and time

Click to expand...

Since it is a Siemens S7 PLC, then it should be mentioned that Siemens has a canned solution for eventdriven alarms with precise CPU timestamps. It is called ALARM-S. The alarms including multilanguage text description is programmed in the PLC project. If a Siemens HMI is used, it can automatically import the alarms and texts with little programming effort.
Regular bit-triggered alarms can be used in parallel with ALARM-S.

ProDiag / PDiag

Hi

I think PDiag or Prodiag in TIA also uses ALARM_S, so Prodiag may be a good solution for future machines maybe ?
But alarms in the same scan, don't they have the same timestamp ? When more then one trigger in the same scan and no different timestamp, this can still mismatch the order of alarms...

Kind regards,
Combo

JesperMP said:

Since it is a Siemens S7 PLC, then it should be mentioned that Siemens has a canned solution for eventdriven alarms with precise CPU timestamps. It is called ALARM-S. The alarms including multilanguage text description is programmed in the PLC project. If a Siemens HMI is used, it can automatically import the alarms and texts with little programming effort.
Regular bit-triggered alarms can be used in parallel with ALARM-S.

Click to expand...

The timestamps of Alarm_S/D/8P are generated with milliseconds.
If there are two consecutive Alarm_S calls, you may have the same timestamp. But I thinks this would not be a problem.

If you are using WinCC, then you can use this alarmtype only if you have your WinCC project inside your Plc project, and you are using AS/OS engineering.
And if you have also S7-400 in your project then there is another disadvantage: The 400 does not support Alarm_S blocks, it has different blocks called Alarm_8 and notify. But Alarm_8 messages are not supported by WinCC flexible panels for example.

okay tnx

Okay, thanks

Thomas_v2 said:

The timestamps of Alarm_S/D/8P are generated with milliseconds.
If there are two consecutive Alarm_S calls, you may have the same timestamp. But I thinks this would not be a problem.

If you are using WinCC, then you can use this alarmtype only if you have your WinCC project inside your Plc project, and you are using AS/OS engineering.
And if you have also S7-400 in your project then there is another disadvantage: The 400 does not support Alarm_S blocks, it has different blocks called Alarm_8 and notify. But Alarm_8 messages are not supported by WinCC flexible panels for example.

Click to expand...

If you want accuracy in alarm, stamping you still cannot beat the PLC scan - end of line. Depends when the the alarm goes off within the scan - does not matter what else you do.

okay

Yes you are right.

BobB said:

If you want accuracy in alarm, stamping you still cannot beat the PLC scan - end of line. Depends when the the alarm goes off within the scan - does not matter what else you do.

Click to expand...