Dear B&R Team.
I have some items for using the alarmsystem by mappview.
I have a full system behind by using VC4 alarmsystem.
It works like this:
I fully programm in oop in Ansi C
So the main object´s has a callback to carry out alarms. It was in VC4 very easy for gouping by using Alarm Groups. It was also easy for carry out alarms by connecting a array and set the a Element or more to “TRUE” → The alarm appears.
I organised all my objects to carry out a number and made a short function which took the number and place the right item in the alarm array.
So now mapview and alarmxcore
As i have seen, all the alarms can only carried out by a certain string, which is in the alarmxCore list.
up to now, i haven´t find any possibility to make different groups for the alarms like VC4. Is there any possibility and is there any way to carry out alarms by using an index or array?
The possibilitiy i thought about was by making kind a hack:
All the alarms name for a certain object will start with string: “Alarm” and a number like “6”.
When the Objekt call the alarm method i will take the string “alarm” followd by “0”+Alarmnumber so i have e.g. “Alarm6” for in order for alarmSet.
So are there some possibilities or better methods?
Thank your for your help
PS: is the german language also ok or just english?
MappAlarmXCore just has access to the AlarmList from the configuration view or the alarms generated at runtime, which are also stored in the configuration object but on the target.
For setting alarms you have to give the name of the alarm. I do not know another possibility. BUT you could create an array on your own as kind of lookup table between number and string. With this you can create the groups on your own. When the objects returns the number, the function setting the alarm could resolve it using this table.
This might be cumbersome but would also keep your work from VC4 existent.
You can parse the configuration object at startup and create the lookup table “dynamically”. E.g the configuration object can be exported by MpComDump and the parsed using the FileIO library.
Groups as known from VC4 are not part of MpAlarmX. The only form of groups is the category where an alarm can be categorized.
You can use the severity on each alarm to determine which group it is in or use a string prefix in the name so it can be used in a reaction within your code.
Up to now, I do not have other possibilities in mind.
I would suggest wrapping the MpAlarmX functions in a function block and write your own reset/set/ack logic inside the FB. This way you can extend the built in functionality while still leveraging the benefits from AlarmX functions.
You can then put all your alarms in an array where you cyclically can check the inputs like ConditionToSet, GroupID or whatever you may choose to implement.
Thank you for you suggestions. But it would not really help.
At least i still have a system which would wrap the alarmxcore system. By using objekt oriented programming it could be that a certain instance of a class will be created multible times. Thats the reason i used the alarmgroups in VC4 in order to have multible “selector rooms” in connection to the created objects.
My system which handles the complete alarm system has a couple methods: When a new instance of a object will created and its necessary to carry out alarms there is a method to build a “new selector room” for this new object(s). This can be made as long as memory will be available. In the end when there are multible selector room or it could be said multible groups for alarms a summary errorbit or errorclassification can be carried out. This system also carries out the reset funcitionality. Only the object knows when an alarm can be reset, not other parts. So the reset will be carried out to the object, the object will proof it and then if possible reset the alarm to the main system.
In VC4 i prepared as much gruops as necessary. It was also for a better overview. Now i have to put all alarms in one list. This is less overview.
Thats the reason i asked to have a similar possibility to alarmgroups.