LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic call of a vi with a reference stored in a global variable

I finally found a little time to tinker around with some ideas.  I've had trouble finding a clean solution too.  Briefly, I tried:

1.  Top-level Main vi uses VI Server to open a vi reference to Sub2 and stores that reference in a "functional global." 

2. Main vi configures a continuous sampling AI data acq task and stores the task id in a functional global.

3. Main vi opens a vi reference to Sub1.  Uses the 'Run VI' invoke node method with 'Wait...' and 'Auto-dispose' set to F.

4. Main vi loops and queries Sub1 until detecting that Sub1 has begun its main loop.

5. Main vi now loops and waits for user to press 'Stop' button, then terminates execution.  Main vi does NOT clear DAQmx task or vi refnum to Sub2.  It does clear the vi refnum to Sub1.

6. Sub1 starts by reading the DAQmx task id and the Sub2 vi refnum out of their functional globals. 

7. Sub1 uses the 'Run VI' invoke node to launch Sub2 with 'Wait...' and 'Auto-dispose' set to F.

8. Sub1 calls DAQmx Start.

9. Sub1 signals its progress to Main as it enters its main loop.  The loop checks for 'DAQmx Task Done', a DAQmx error, or for a user 'stop' button.  When the loop terminates, the vi refnum to Sub2 is cleared.

10. Sub2 reads the DAQmx task id from the functional global.

11. Then Sub2 simply loops and queries the DAQmx task for 'TotalNumSamples' which it writes to an indicator.  If there's a DAQmx error or the user hits the 'Stop' button, the loop terminates.  On termination, the DAQmx task is cleared.

That's a lot to swallow.  The idea is that the task id refnum and the vi server refnum that are opened by Main are being stored in a functional global vi that is definitely in memory (because it is accessed by Sub1 and Sub2) before Main is allowed to terminate.

Nevertheless, as soon as Main is terminated, the DAQmx task gets automatically cleared causing both Sub1 and Sub2 to terminate because their task id refnum is no longer valid.  On the other hand, if Main isn't terminated, it's just fine to terminate Sub1 (which was responsible for Starting the task) without any effect on Sub2.

It sure seems there must be a fairly straightforward solution, but at the moment I'm stumped too.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 11 of 13
(1,042 Views)

Hi Gabs,

      If I understand the things you've tried, in all cases the Top-level VI associated with opening the reference, stops executing.  Using a daemon to keep the VI in memory isn't preventing the resources associated with the reference from being deallocated (invalidating the reference.)  But if the daemon opens the reference, the reference will be good as long as the daemon is running (or until the reference is explicitly closed.) 

So, building on the suggestions of previous posters Smiley Wink , here's a pic of a possible daemon-solution. Smiley Happy

this "daemon.vi" creates a notifier and "publishes" it in "global 1.vi".

Launch daemon.vi

Run VI_1.vi to obtain a new reference to "driver.vi". (VI_1 terminates)

Run VI_2.vi to utilize the previously created reference.

Cheers!

Message Edited by Dynamik on 06-18-2006 01:11 AM

When they give imbeciles handicap-parking, I won't have so far to walk!
Download All
Message 12 of 13
(1,035 Views)

Hi,

sorry for the delay.. and first of all: thanks for your answers. Actually, I had solved the problem a few days before with a mixture of both of Kevins and Dynamiks answers. I have added a boolean control to my main VI where the user can choose if he uses the VI in an application (default setting) or during the VI test phase. If test phase is chosen, the VI stays active using a loop until the user presses a stop button, so the references and task IDs stay valid (they are saved in a functional global). If application is chosen, there is no problem at all because then the references and IDs stay valid automatically. So I hope that will work. Anyway, thanks a lot for your suggestions, in future I may try out your ideas and that may result in a more elegant solution than mine.

Greetings,

Gabs

0 Kudos
Message 13 of 13
(1,003 Views)