more quick actions
minimize quick actions
Topic starter
Hello all
There is something that I do not seem to understand about TREATMENT group alarm acknowledgement.
Group alarm acknowledgement operates in both directions :
1. When the bit is set the group of alarms are acknowledged.
2. When any of the alarms in the group is acknowledged by another means, the bit is set.
I do not understand in which case the second direction is useful ?
Posted : 02/07/2013 6:38 pm
Personally, so far I never used this feature but if, I follow you, in the situation 2 all alarms of the group will be ack. because the bit is set isn't?
But, checking the help, I can see that the bit can be set to 0 to acknowledge the alarm group. so, in situation 2, if this bit is set to 1 it won't acknowledge the others.
Finally, I agree it's not clear. It's a documentation mistake or ....
May be you can test it first to see the behaviour?
Posted : 03/07/2013 6:00 am
Topic starter
Thank you Niko. I have tested for see the behaviour and it is not a documentation mistake.
I have 3 alarm : ALA1, ALA2 and ALA3.
I have a bit ACK for acknowledge group alarms.
Situation 1 : If I set ACK, ALA1 ALA2 and ALA3 are acknowledged. -> OK
Situation 2 : If I acknowledge ALA2 with the alarm viewer (for example), ACK is set, ALA1 and ALA3 are acknowledged
I don't understand why when I acknowledge one of the alarm, the bit is set ?
Posted : 03/07/2013 12:25 pm
Did you ask Dominique ?
Posted : 03/07/2013 1:02 pm
Topic starter
I asked yesterday by email
Posted : 03/07/2013 1:23 pm
Hi Anthony,
I remember why this treatment has been coded for. It was a request from Assystem for a CERN project.
They have PcVue and many small HMI devices that can also acknowledge a small part of the process alarm it was concerned with.
I am sure about the first behaviour :p but I did not remember the second one which really occurs.
I am pretty sure that Dominique will confirm that it has been requested like that by the customer.
It would mean 2 things :
- there is a documentation mistake for the french version
- an improvment should be asked to have an additionnal flag at the end of the line, not to set the bit. Of course the default option for migration would be setting it (0 or 1 depending on what has been chosen)
Edouard
Posted : 05/07/2013 10:59 am
Topic starter
Hello everyone and thank you for your answers.
Dominique told me that this behavior was a request from CERN project.
It is not possible to disconnect Situation 2.
I have created SPR 48295 for documentation and 48335 for improvment.
Posted : 05/07/2013 7:27 pm