Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
I'm putting together the alarm handling for a project I'm working on. When completed this will monitor a system with >1000 errors potentially reported. The criteria to trigger an alarm can come from multiple sources. Initially I started by creating an AlarmGroup with entries using Digital Observation Types. Even though I was mass manipulating the content and importing it, the group gets larger than I'd like because there needs to be an entry for each potential trigger of each Alarm.
Which uses Event Observation Types and a call in the code like:
AlarmManager.AlarmGlobals.g_AlarmHandler.RaiseEvent(AlarmGroupID,AlarmID)
This is a preferred approach, however the issue I'm seeing with this is the alarm/event is merely "raised". So it isn't an active alarm, plus the History parameter of the Alarm Table must be set TRUE to see the alarm (which causes the Alarm Table to display all previous alarms).
Is there a call that can be made from ST code that will trigger an alarm to be "active"?
Note: The initial attempt using the Digital Observation Types provided the desired behavior - an active alarm posted and was removed on the Alarm Table according to the trigger criteria. The multiple sources factor multiplies the needed number of entries in the group, managing these will become an issue when the alarm handling is fully implemented and in future maintenance/updates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Follow up:
I had a couple revelations. 1) I did not switch the Acknowledgement method of my alarm class to ACK. 2) After changing the Acknowledgement method, I was able to trigger and clear "active" alarms using the RaiseEvent and AcknowledgeOneOfGroup methods respectively.
After playing around with the Event Observation Type I decided to return to the Digital Observation Type. The primary reason was that after scaling the alarms from what I was testing with to something more large and realistic, the timing wasn't working very well.
Ultimately I have a working initial version of the Alarm Configuration. I have to implement several Alarm Groups, and the entries of those have complicated trigger expressions. But sticking with the AlarmGroup import/exports for mass manipulation should be good enough for future support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm putting together the alarm handling for a project I'm working on. When completed this will monitor a system with >1000 errors potentially reported. The criteria to trigger an alarm can come from multiple sources. Initially I started by creating an AlarmGroup with entries using Digital Observation Types. Even though I was mass manipulating the content and importing it, the group gets larger than I'd like because there needs to be an entry for each potential trigger of each Alarm.
Looking around I found this approach in the help documentation:
https://help.codesys.com/webapp/_cds_call_event_alarms;product=codesys;version=3.5.11.0
Which uses Event Observation Types and a call in the code like:
AlarmManager.AlarmGlobals.g_AlarmHandler.RaiseEvent(AlarmGroupID,AlarmID)
This is a preferred approach, however the issue I'm seeing with this is the alarm/event is merely "raised". So it isn't an active alarm, plus the History parameter of the Alarm Table must be set TRUE to see the alarm (which causes the Alarm Table to display all previous alarms).
Is there a call that can be made from ST code that will trigger an alarm to be "active"?
Note: The initial attempt using the Digital Observation Types provided the desired behavior - an active alarm posted and was removed on the Alarm Table according to the trigger criteria. The multiple sources factor multiplies the needed number of entries in the group, managing these will become an issue when the alarm handling is fully implemented and in future maintenance/updates.
Follow up:
I had a couple revelations. 1) I did not switch the Acknowledgement method of my alarm class to ACK. 2) After changing the Acknowledgement method, I was able to trigger and clear "active" alarms using the RaiseEvent and AcknowledgeOneOfGroup methods respectively.
After playing around with the Event Observation Type I decided to return to the Digital Observation Type. The primary reason was that after scaling the alarms from what I was testing with to something more large and realistic, the timing wasn't working very well.
Ultimately I have a working initial version of the Alarm Configuration. I have to implement several Alarm Groups, and the entries of those have complicated trigger expressions. But sticking with the AlarmGroup import/exports for mass manipulation should be good enough for future support.