Alarms (Access delay & tripped state)

[UKL]

Hi,

I design a VeriStand project with 60 alarms (2 lists of 30).

1) I tried to use the Alarm monitor tools but it is really, really slow ! 

So, i used a VI to get the alarm's data.

The access delay (which is already slow at first) increase continually each time I call the "Get Alarm Data", even if I open/close the alarm reference each time or at the beginning/end of the vi.

An other strange thing is the different access delay when we switch from one list to an other (the down peaks).

(See attached files)

2) I found it is impossible to change the state of an alarm in a VI (enable, disable, tripped ...) if this alarm is in tripped mode . So, i need to associate one procedure with a disable alarm command for each alarm.

So, would you have an opinion on these inconveniences? 

Regards, KLS

[JérémyC]

Hello KLSsuperstar,

I looked for explanations and here the information given to a customer 5 months ago :

"The R&D engineer said that we most likely won't be able to improve the performance of the Alarm Monitor tool because this issue is related to the NIVS engine. After their investigation they've identified a .NET method that spends a significant amount of time searching for a given alarm channel. This issue has been documented in CAR 396524 and it will likely be fixed in the near future.

The main problem comes from the GetMultipleAlarmsData .NET method when it searches for "Alarm Watch" Channel. The delay is coming specifically when traversing to the WatchChannel. Our G code traverses past every channel until the WatchChannel is found. This means that if the System Channels list is organized before the alarm's watch channel, then our code visits all 300+ system channels in search for the watch channel. Additionally, if the user has Stimulus listed or DAQ channels, then again this adds to the items our code must first traverse before finding the alarm's watch channel. This is a bug in the current API, and unfortunately there is currently no workaround for it. We'll try to address it as soon as possible."

Regarding your second point, there is also a Corrective Action Request because the Alarm Monitor tool should disable and gray out the Enable/Disable button if an alarm is in a tripped state.

In fact, a user is not allowed to change the state of alarm when that alarm is in a Tripped/Delayed Tripped state. However, the Alarm Monitor workspace tool fails to convey this behavior to the user by allowing the user to interact with the Enable/Disable button, but failing to take action because the alarm is tripped. The resulting behavior appears to the user as a bug.

Regards,

[h_yong]

Hi, I believe I'm the one who originally submitted the bugs about the unusably long delay. Do you know if CAR 396524 will be fixed by VeriStand 2013?

To get around the 2nd point, I've put in a small delay (e.g., 0.1s) for most alarms. This allows me (in VeriStand 2009 where the alarm monitor works reasonably quickly) to click rapidly at the disable button. If I click it during the delay time, the disable request will take. Obviously this is not ideal, so for most alarms that I want to disable in runtime, I multiply by a user channel that I change the value of to make the alarm trip condition not met.

[JérémyC]

Hello h_yong,

According to the information filled in the CAR 396524, the issue mentioned should be fixed in VeriStand 2013.

Regards,