LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Changing alarm limits in a library from within a VI

I am running LabView 8.6f1 with the DSC module on XP. I have some (network-published) shared variables defined in a project library created through the project explorer, but I would like the user to be able to change the alarm limits from within a VI (and have those changes remembered). I have tried using the SharedVariableIO property node, but the new setting is lost as soon as the VI is exited and restarted. From other posts, this seems to be because the property node updates the variable engine but not the library file.

 

I have tried various permutations on undeploying, saving, and redeplying the library while changing the value but that doesn't seem to help. Can this be done? Thanks,

 

  --David

0 Kudos
Message 1 of 11
(3,092 Views)

Once you write the setting in to the SharedVariableIO property node, you want to commit the shared Variable, after that you exit the VI and While opening the VI read the SharedVariableIO property node, So that data will not be losted.

Message 2 of 11
(3,052 Views)

David,

 

The information for the alarm levels of the variables is stored in the library. Hence, in order to make changes and save the information permanently, you'd have to save the library modify the library and save it from the VI, which is not possible at the moment. Plus, like you noted, changing the alarm values through the property node implements changes directly in the variable engine, not the library. 

If you want to remember the alarm value changes between successive runs of the VI, you could implement a dedicated shared variable to keep track of the last change made to the alarm level, then at the beginning of the next run you can read the value of that variable and change the alarm level accordingly. 

Misha
0 Kudos
Message 3 of 11
(3,033 Views)

 Vijay,

That's what I tried initially, but it doesn't work. If the shared variable engine goes down, or the library is ever re-deployed, the changes will be undone.

 

 

Misha,

Thanks for the info about not being able to programatically edit the library; it's good to know I can stop trying for now. I guess I will suggest that feature for next release. The variable idea would work (but take a lot of variables), or I guess I could use a configuration file, but I don't like the idea of having a different "true" alarm value in the library.

 

 

On the topic of shared variable alarms, how can you easily read the alarm state for use elsewhere in a VI? For instance, I have separate LED indicators for a Hi, Lo, and Rate alarm; how can I read a specific variable's alarm state so I can wire it to such boolean indicators? The ActiveX controls don't seem to have this sort of functionality. I have tried the DSC ReadAlarms, but this returns all current alarms for each selected variable in an array of clusters. Is the way to do this to string search that array of clusters for the alarm URL of interest, and if it is found/not found equals active/not active? Thanks,

 

  --David

0 Kudos
Message 4 of 11
(3,021 Views)

Hey David,

 

You're right, at this point the outputs of the "read alarms" VI do not explicitly specify which type of alarm was set off. However, you can extract this information from outputs such as the alarm URL (something like \\host\DSC Alarms Demo\Double Variable.Alarms.Lo) or Area (something like LOArea). For example, you can extract certain characters from the output and set up a case structure to set off the appropriate LED. 

The DSC Alarms Demo is a useful example to look at for tips for formatting and displaying alarms. 

Misha
0 Kudos
Message 5 of 11
(2,999 Views)
Now that I think about it, the Alarm Area output is probably meant to provide exactly that information. And, you don't even have to extract the characters, just wire this output into a case structure and and make appropriate cases to light up your LEDs.
Misha
0 Kudos
Message 6 of 11
(2,992 Views)

I have spent a day or two trying to do the very same thing, and not understanding why the change in limit values would not 'stick'!

The initial Post was dated March of 2009.  Has anyone discovered a solution?

Gretchen

0 Kudos
Message 7 of 11
(2,547 Views)

From what I understand this was a software limitation of that version of labview 8.6, is that the version you are running and have you attempted the suggestions listed above? 

 

Good Programming

Beau H

BeauH
Applications Engineer
National Instruments
0 Kudos
Message 8 of 11
(2,531 Views)

I am using Labview 2010 on XP.

I can modify the alarm levels programmatically using either shared variable properties or DSC 'Configure Alarming', but only for that execution of Labview.  The next time I start Labview, the new alarm levels are zapped, & all levels are back to the original values.  I have not tried the 'commit' suggestion.

Gretchen

0 Kudos
Message 9 of 11
(2,522 Views)

Hi GretchenSkelly

 

I think the problem that you guys are having is that an instance of the shared variable engine must be running at all times. Without this host, the data will be lost or in this case, reset. Please take a look at this dev zone, specifically the Shared Variable Engine section:  http://zone.ni.com/devzone/cda/tut/p/id/4679#toc3. Also here is a link to an example regarding shared variables for your benefit: https://decibel.ni.com/content/docs/DOC-3806.

 

Jason L.

 

Product Support Engineer
National Instruments
0 Kudos
Message 10 of 11
(2,499 Views)