How to trigger an alarm in DSC module if after re-enabling alarming

[TomBrass]

My application monitors a large number of tags.  I've set up the user interface to allow the operator to temporarily disable an alarm for a set amount of time.  For example, if someone opens the door to a freezer, then closes it, the temperature tag will go into alarm.  Since we know why the alarm occurred, the operator can disable the alarm for a couple of hours.  When the alarming is re-enabled for that tag, if it is still in the alarm range, it should go back into alarm.  The problem is that it doesn't.  Is there a way to put it back into alarm programmatically?  I am also using the Alarms & Events Display ActiveX control for acknowledging alarms, so I would rather not use User Defined Alarms.  Any ideas would be greatly helpful.

Tom

[ThHagel]

Hi Tom,

what Version of LabVIEW and DSC do you use?

[TomBrass]

I am using LabVIEW 8.6.1 and DSC 8.6.

Tom

[mishkin]

Tom,

Are you using "Enable alarm  & even notification" and "Disable alarm & event notification" VIs to enable/disable? 

You can try using a property node instead: 

[TomBrass]

Yes, I am using the property node to change the alarming property.  If you set this property to True, it does not generate an alarm if it is already outside of the limits.  Seems like a bug to me, but perhaps other people expect it to behave this way.

Tom

[TomBrass]

Okay, here is a suggestion from a colleague of mine.  Change the scaling to bring the sensor back within limis, then change the scaling back to generate an alarm.  A total kluge, but would it work?  Unfortunately, I don't have the hardware handy (its at the client site) to test this.  Anyone want to try this and see if it works?

Tom

[ThHagel]

Hi Tom,

I encountered the same problem with 8.5.1 and this behavior is still included in DSC 8.6.1 (I installed that version and tried it, thats what took so long).

The problem is that after enabling the alarm feature, the alarmstate gets only evaluated as soon the shared variables value gets updated. 

I didn't like this behavior either and I created a workaround using the alarm limit settings (via property node). So if I want to disable my alarming I simply set the limits to values that can not be reached by the signals value range. If I want to enable it again I set the limits back to the real limit values that I want to be evaluated for alarming. The good thing about this is, that the evaluation takes place immediately after changing the limits back to normal. This is why your alarm will occur immediately after enabling your alarming with this workaround method. This works fine for my projekt.

Regards,

Thomas

[TomBrass]

Interesting idea.  We display the limits on the front panel, and I think the client wants to see the limits.  However, there is no reason why we can't change the limits behind the scenes and continue to display the original limits.  I'd have to keep track of them anyway so that I can return the limits to those values.  I'll have to look at my code and see how that will fit in.  I like the idea, though.

Thanks for the input!

Tom

[mishkin]

Thank you for reporting this to us. I was able to reproduce this behavior and reported it to our R&D department (ID 170352) so that they can look into it.

[TomBrass]

The method I described before works great, its been working for over a year now.  Unfortunately, I found a problem with Boolean sensors.  I thought this method worked for Booleans as well, but it only seems to generate a transient alarm.  That is okay if the alarm is User-Acknowledged, but not so great if it is Auto-Acknowledged.  Any thoughts on how to make this work for Booleans?  I tried reconfiguring the sensor as an analog sensor (set the limit to 0.5, values are False = 0, True = 1), but it didn't help.  Perhaps because there are only two values, and the engine is looking for a change in value.  Any suggestions would be greatly appreciated.

Tom