LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dsc 8.0.1 alarm behavior

I am moving from DSC 7.1 to 8.0.1 (and as soon as it is here 8.2) and I am noticing some differences in alarming.
 
In DSC 7.1 when a tag moved into alarm an "alarm instance" was generated with a "set time" corresponding to when the tag alarmed.  When the tag returned to normal (whether it was acked or not) its "clear time" was updated and when it was acknowledged its "ack time" was updated.  If a tag moved in and out of alarm without acknowledgement an "alarm instance" would get generated for each transition into alarm, each instance having "set time" and "clear time" as appropriate.
 
Now in 8.0.1 the "clear time" property does not seem to function and no new instances of an alarm get generated until the existing alarm is acked and returned to normal.
 
I am not sure whether these are "features", bugs in the PSP engine or a configuration error on my part.  Anyone else using the DSC 8.0.1 that can describe the alarm behavior in their system?
 
George

0 Kudos
Message 1 of 10
(7,267 Views)
George,

You are correct that this is incorrect behavior and has already been submitted to R&D (3Z5HG7G0), unfortunately not in time for fixing in 8.2.  This will not occur if the alarm is set to be auto-acknowledged, in which case the clear time will be the same as the ack time.
Doug M
Applications Engineer
National Instruments
For those unfamiliar with NBC's The Office, my icon is NOT a picture of me 🙂
0 Kudos
Message 2 of 10
(7,254 Views)
Does NI ever plan to fix this bug. It has been 2 years and 2 new revisions. I am running 8.5 and still have the same problem. Help!!!
0 Kudos
Message 3 of 10
(6,388 Views)
Hi Mrs. Ed Lester,
 
I confirmed with the developer that the way these features work in LabVIEW 8.5 is the intended behavior.  The developers do have a link to this discussion forum, so if you'd like to make suggestions, you can do so here or at ni.com/contact.
Regards,

James R.
National Instruments
0 Kudos
Message 4 of 10
(6,267 Views)

Hi JamesR,

I am confused. Do the developers of DSC 8.5 really want the "clear time" property not to function and no new instances of an alarm be generated until the existing alarm is acked and returned to normal. It seems that you would want to know when an alarm cleared why else would you have a field that says "Clear Time". I suspect that DougM's post back in August 2006 is still true and that it is a bug that is still not fixed in DSC 8.5. Any information you can provide would be helpful if I am incorrect.

Thanks.

0 Kudos
Message 5 of 10
(6,253 Views)


jljkl wrote:

Hi JamesR,

I am confused. Do the developers of DSC 8.5 really want the "clear time" property not to function and no new instances of an alarm be generated until the existing alarm is acked and returned to normal. It seems that you would want to know when an alarm cleared why else would you have a field that says "Clear Time". I suspect that DougM's post back in August 2006 is still true and that it is a bug that is still not fixed in DSC 8.5. Any information you can provide would be helpful if I am incorrect.

Thanks.




Alarms can either require that the user acknowledge them to become cleared (User must ack) or they can acknowledge themselves when their value goes below the configured setpoint(auto ack).  In LabVIEW 7.1 every tag had only a single alarm associated with it and that alarm's state changed as the value of the tag changed.  Starting in LabVIEW 8.0, variables (the new tag) can have multiple independent alarms associated with it.  Having the alarm clear itself and then generate a new instance when the value cycles around the setpoint would behave like a memory leak.
Regards,
Robert
0 Kudos
Message 6 of 10
(6,180 Views)
LabVIEW's current (8.x) alarm behavior is incorrect and inconsistent. Although it is lengthy I will enumerate the reasons:

Alarms (independent of HMI package) have two fundamental properties: alarm state and acknowledge state. Alarm state indicates whether the associated value has deviated from a predefiend normal range or value. Acknowledge state indicates whether the user has indicated awareness of the associated alarm. Alarms typically can be configured to "auto-acknowledge" when they return to normal (clear). However, even when configured to auto-ack, the operator can usually manually acknowledge the alarm before it clears.

There are consequently three interesting times associated with alarms: when the alarm became active, when the alarm was acknowledged, and when the alarm returned to normal (cleared).

First consider the case of an alarm configured to auto acknowledge on return to normal:

The alarm becomes active at time A and then returns to normal at time B.
LabVIEW Logs: Active=A, Acknowledge=B, Clear=B

The alarm becomes active at time A, is manually acknowledged at time B and clears at time C:
LabVIEW Logs: Active=A, Acknowledge=B, Clear=C

Each time the alarm becomes active a new entry is added to the alarm log record. So far so good. Now consider the case of an alarm the user must acknowledge:

The alarm becomes active at time A, is acknowledged at time B and clears at time C:
LabVIEW Logs: Active=A, Acknowledge=B, Clear=C

The alarm becomes active at time A, clears at time B and is acknowledged at time C:
LabVIEW Logs: Active=A, Acknowledge=C, Clear=C ** THIS IS WRONG!!! THE ALARM CLEARED AT TIME B!!!

Finally consider:
The alarm becomes active at time A,
Clears at time B,
The alarm becomes active at time C,
clears at time D,
and acknowledged at time E

LabVIEW Logs: Active=A, Acknowledge=E, Clear=E ** THIS IS WRONG!!! THE ALARM CLEARED AT TIME B and D!!!

This last case is also incorrect because it does not reflect the fact that there were several alarms. The log record will incorrectly reflect a single alarm.

Whether LabVIEW's implementation of tags and alarms makes it hard to create correct alarm behavior is irrelevant. The bottom line is LabVIEW does NOT behave correctly and has shipped with bugs in its alarm handling since LabVIEW 8.0.
Message 7 of 10
(6,169 Views)

George,

I've recently posted a problem which is exactly what You describe here.

I did not find your post when I was looking for a solution to the problem.

http://forums.ni.com/ni/board/message?board.id=170&message.id=402223&query.id=240940#M402223

 

In my post I describe, in other words, the same situation... I have also attached a vi to experience the problem.

 

So in LabVIEW 8.6.1 it is still a unsolved bug!    Smiley Mad

 

Do You know whether it has, at least, a Corrective Action Report Number (CAR Number)?

 

I am going to put a link to your post in my post...

 

we'll see  

 

Guglielmo

 

 

0 Kudos
Message 8 of 10
(3,160 Views)

6 years later...

 

Labview DSC is still having problems with setting an alarm to user ack:

- The API for setting the alarm sto user ack does not work

- Setting a shared variable to user ack with property nodes does not work

- The work-around is to write 2 to the "secret alarm variables" vis PSP (e.g. \\ hostname \ Process \ variable \ alarms \ HiHi \ Acktype )

 

Labview DSC is still having problems with the behaviour of user ack alarms and alarms in general:

- The ack type settings does not persist after putting the process to pause.

- Sometimes we get ghost alarms: they can not be acknowledged, and they never get cleared(!)

- Alarms are never cleared, even if the variable is not in an active alarm state anymore (except when acknowledged).

 

 

 

 

0 Kudos
Message 9 of 10
(2,720 Views)

Hi langedrag,

 

I would like to assist you in resolving these issues but I will need some more information. Can you tell me what you are trying to accomplish with the user  acknowledge alarms? Do you have some code that I could use to try and reproduce this issue? Have you had a chance to look at the example code for user acknowledge alarms in the NI Example Finder. It is a pretty good resource on how user acknowledge alarms are best used.


Regards,


Josh B

Applications Engineer
National Instruments
0 Kudos
Message 10 of 10
(2,698 Views)