LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating 2 separate Main programs, passing values

Thank you all for the replies and suggestions! I realize I have a long ways to go, and a lot to learn before gaining enough insight to code effectively. Anyway, I am not too familar with using queues, action engines and some of the more advanced LabVIEW functions. I will have to look more into the sample code when I have some time. Meanwhile, I am trying to avoid using shared variables as was suggested. My first attempt to improve the program was to use the Server VI to call my second program from the main program. The current problem I am running into is that I am unable to come up with a clever way to exit the Event Structure of the second program, and still have the front panel of the first program retain its functionality.

 

What I really liked about the shared variable approach was that I could open (2) VI's independently and execute them. Both programs had Event Structures that waited for user interaction with the front panel, and exchanged/updated the values without affecting each other. When I try to use the Server VI to call my second program, I get stuck inside the event of the second program and cannot regain access to the first program. The way I am getting out now is to wire a True statement to the stop function so that the second program only executes a single time before returning to the main program. The problem now is that the second program is no longer event controlled, but a single execution. Any suggestions on how to best address this problem? The shared variable approach seems to make much more sense at this point... 

0 Kudos
Message 11 of 14
(614 Views)
Also including the (2) programs.
Download All
0 Kudos
Message 12 of 14
(613 Views)

You got hit with a dataflow problem.  Your main VI is waiting for the subVI (your other front panel) to finish before it continues execution.  Fortunately, there is an easy way around this issue.  Instead of using the Call By Reference Node to launch your second VI, use an Invoke Node and set the method to Run VI.  Set Wait Until Done to FALSE and Auto Dispose Ref to TRUE.  This launches the VI as an independent thread and returns control to your calling VI.

 

You need to set your data value before running the VI.  Do this with another Invoke Node before running the VI.  Use either Ctrl Val.Set [Flat] or Ctrl Val.Set to set front panel controls.  Note that this method is not dependent on the connector pane pattern, so is somewhat more maintainable.  However, it is slower than the Call By Reference Node method.  In cases like this, it really doesn't matter.

 

I agree that the shared variable is easier to use up front.  However, it is not as maintainable in this sort of application as a LV2 global or single-element queue.  My experience has been that you either take the development hit up front to use a thread-safe reference object or a much larger debugging hit later, and then need to use the thread-safe reference object anyway.  Once you have done it a few times, it is much easier, especially if you make templates of your favorite design patterns.

0 Kudos
Message 13 of 14
(593 Views)

DFGray,

 

Thank you so much for all your help. It is much appreciated. I will revise my program and try what you suggested. Hopefully the extra work involved with overcoming the initial learning curve will pay off in the end. Cheers. 

0 Kudos
Message 14 of 14
(579 Views)