DSC alarm set and cleared without operator ack - the variable should be not alarmed and not acked

[scalare]

We are deeply involved in porting our application from 7.1.1 to 8.6.1 under Windows XP.

Our application  heavily depends on DSC and moving from 7.1.1 to 8.6.1 is actually much more than a simple porting....

here is our last problem:

it seems that there is no discrimination between 'active' alarms and 'acknowledged' alarms on a shared Variable  in case the 'ack Type' is set to 'USER'.

Here is what happens:

1) a Boolean shared variable is defined to be alarmed when 'high' (TRUE) and its ack type is set to 'USER' (the operator at our application must ack alarms).

2) the Boolean var is set to TRUE -> it is declared alarmed (OK)  and not ack'ed (OK)

3) the operator ack the variable -> it is declared alarmed (OK)  and ack'ed (OK)

4) the Boolean var is set to FALSE -> it is declared not alarmed (OK)  and ack'ed (OK)

5) the Boolean var is set to TRUE -> it is declared alarmed (OK)  and not ack'ed (OK)

6) the Boolean var is set to FALSE -> it is declared alarmed (NOT OK!!!)  and not ack'ed (OK)

7) the operator ack the variable -> it is declared not alarmed (OK)  and ack'ed (OK)

This last case is the wrong situation: an alarm has been set and cleared without operator ack the variable should be not  alarmed  and not acked 

Actually the variable returns OK only when ack'ed.

see the attached project in which a small vi and a small shared variable lvlib allows to repeat the above steps.

Note:

A) same situation applies to 'double' shared variable

B) under DSC version 7.1.1 everithing was OK 

can anyone Help?

Thank You Guglielmo Rozera

[LiciaP]

Hi Guglielmo,

I had several tests on your example application; I still have to further investigate what is happening (which is quite "curios"), but here are my first results:

- if I set  ACK type to "user" and then run the VI, all works as you expected (alarm is unset when boolean returns to false, even is it has not been acknowledged);

- if I set  ACK type to "user" after have run the VI, I experienced the beaviour you described, also stopping and running again the VI: you have to undeploy the library and deploy it again to recover the expected functionality (it may be connected to what described here);

- I replaced the Datasocket Write you used to write the new value of ACK type with a property node (as in the attached screenshot) and now all seems to work as expected.

Try this modification and let me know your results. As I said, I want to further investigate: I'll post back if I come to a conclusion.

Bye!

Licia

[scalare]

Thank for your replay!

I have tried to undeploy and deploy the library with ack type set to 'User' by default, and then run the vi but the behavior is always the same.

The modification you suggest does not set 'User' ack type because data socket needs '2'  as 'User ' setting while property node needs '1' or (better) its own enumerated type.

Anyway I've corrected the vi according to your suggestion and tried again but nothing changed...

Here I attach the project modified with property node and an indicator to show what is the actual ack type

I hope in your further investigations!

Thank You

Guglielmo 

[scalare]

I've found an old post which perfectly describes same problem with different words.

http://forums.ni.com/ni/board/message?board.id=170&message.id=403307

I didn't found it before.. so It is an old problem, without solution yet!

I do not understand why....It should not be so difficult to correct... 

Do you know whethet NI has a CAR number for it?

 Guglielmo

[scalare]

sorry I've found this number in the above linked post 3Z5HG7G0

any answer from R&D?

guglielmo

[LiciaP]

Hi Guglielmo,

I had a look at the CAR documentation: basically, this behaviour is not considered a bug as it is expected. A KB has been created to explain it: when an alarm is set to be user-acknowledged, the alarm is cleared only when it has also been acknowledged.

I hope this will calrify the issue.

Bye!

Licia 

[scalare]

NO!

This clarifies that NI gets rid of one of the four possibilities that a couple of Booleans allows.

'alarm state' and 'ack state' allow:

1. alarmed AND acked
2. alarmed AND not acked
3. not alarmed AND acked
4. not alarmed AND not acked

the 4th is thrown away!! I do not understand why...

In LV 7.1 everything worked fine....

The link you give states this behavior but  does not explain!

Can anyone explain WHY?

Guglielmo

[Gibbi]

hi scalare,

i met actually the same problem you and the other post describes.  I also think that this is a buggy behaviour in LabVIEW DSC.

It is sad, that user comments are not handled that seriously.

@NI: Where is the problem in solving this?  Some database issues?

The illustration of both user explanations is absolutely understandable and logically correct. 

Even in WinCC the alarm behaviour is as described by the users (i think there are more automation software systems that act as expected).

How much annoyed users are needed to get a movement at NI?

Kind regards

gibbi