LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[Name space, scope, lifetime] of variables

I received an example VI from a spectrometer vendor.  The block diagram of the VI basically has a sequence with initialization, working, and closing frames.  The initialization frame detects how many spectrometers are present and sets up the arrays and other variables for normal operation.  The working frame has a loop that collects data until a stop button is pressed.  The closing frame cleans up by destroying the arrays that were allocated in the initialization frame.

For modularity and easier implementation, I wanted to change as little of this code as possible so I added two booleans (initialize and cleanup) to control whether the code in those two frames should be executed and whether the working frame should be executed.  My thinking was that the VI could be called with initialize set true and cleanup set false and later called with both set false to execute the working loop one time (with the stop button set by default to true).  This worked for a while until I made some other code changes (which I don't know) to my application (not this example code) and now the method does not work.  Instead, when I call initialization, two spectrometers are found, but when I call the VI to collect data, no spectrometers are found.

Can someone help this newbie to understand about the time-to-live of variables in LV?  When I return from the first initialization call, do the variables still exist or are they destroyed?  Is there any way to make the values persists across multiple calls?  The only other way I can think of to integrate this function into my main app is to hack it to pieces and place each piece into my main app.  This seems so wrong though.
0 Kudos
Message 1 of 2
(1,995 Views)
The first thing you have to understand is that, technically, there are no "variables" in LabVIEW. The wires carry the data, and in the sense of variables like you have in text-based languages, those are the variables. That said, it sounds like the vendor VI is working with creating references, and that is what is being "destroyed" in the closing frames. You don't destroy arrays.

As far as "time-to-live": When a VI, runs memory is allocated for data as needed. That data is available to that VI, and that VI alone, unless you use other mechanisms, like output terminals, queues, functional globals, etc. Once the VI finishes, that memory is released.

It sounds like you're trying to use the vendor VI in multiple instances, and it also sounds like the VI wasn't designed to work that way. If you have the vendor VI used in one instance with the "init" setup, then it will create the references, and not do anything. If you then try to call the vendor VI somewhere else in your code and skip the "init" setup, the vendor VI will have no spectrometers with which to run since the internal array of references was never created.

That said, you have a couple of options:
  • Break up the vendor VI into the respective blocks: init, work, close. You will need to modify them so that the array of references are controls/indicators as needed. In other words, the "init" VI will output an array of references, and the "work" VI will take in a control of references with which to work.
  • Wrap the vendor VI with a functional global/action engine. Basically you would need to use a shift register to store the array of references, and then use a case structure around the individual "init", "work" and "close" sections.
0 Kudos
Message 2 of 2
(1,984 Views)