LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to pass variables (arrays, boolean etc.) from main VI to subVI called in event structures


wiebe@CARYA wrote:

@Yamaeda wrote:

Asynch.png


But that will wait until the VI is done...


Yes, I forgot the 0x40 option when opening the ref. Close enough. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 11 of 19
(1,091 Views)

@Yamaeda wrote:

wiebe@CARYA wrote:

@Yamaeda wrote:

Asynch.png


But that will wait until the VI is done...


Yes, I forgot the 0x40 option when opening the ref. Close enough. 🙂

/Y


That would allow multiple instances, but the Call By Reference would still block execution until the VI is done.

 

In OP's example, the dialog is started in an event structure. So the event structure would not continue until the dialog is done. If that was acceptable, he might as well use a plain sub VI.

0 Kudos
Message 12 of 19
(1,087 Views)

That should be a "Start asynchronous call". So unless asynchronous means something else then I've been led to believe, it should fire and forget.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 13 of 19
(1,084 Views)

@Yamaeda wrote:

That should be a "Start asynchronous call". So unless asynchronous means something else then I've been led to believe, it should fire and forget.

/Y


My bad. Weird that the Call By Reference has a 'weird' run arrow while initiating a normal run, and the Start Asynchronous Call has a normal run arrow while starting an abnormal run...

 

Can't say I'm using either much. DD obsoleted most of my use cases, and the remaining cases usually requires a normal dynamic start, as I don't have a CP type def... Anyway, OT.

Message 14 of 19
(1,074 Views)

wiebe@CARYA wrote:
My bad. Weird that the Call By Reference has a 'weird' run arrow while initiating a normal run, and the Start Asynchronous Call has a normal run arrow while starting an abnormal run...

I agree, I've had the same reaction many times. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 19
(1,065 Views)

@stevenette wrote:

Ok, I have created 2 new vi's to better explain my position


Your Event Structures block your loops until an event happens.  If you want to read/write your global variable, you need an event to happen.  Try a value-change event in the main VI, and a 100 ms timeout in the subVI.

 

BTW, Async "Launching" is an advanced LabVIEW technique; you would be better served learning the basics first, including how to use the "highlight execution" feature that would have allowed you to debug this problem.

Message 16 of 19
(1,055 Views)

I guess nobody noticed that I recommended "start asynchronous call" in message #5 already, but since the communication should be ongoing after launch, it will not help much and some of the other suggestions should be used.

0 Kudos
Message 17 of 19
(1,046 Views)

@drjdpowell wrote:

Your Event Structures block your loops until an event happens.  If you want to read/write your global variable, you need an event to happen.  Try a value-change event in the main VI, and a 100 ms timeout in the subVI.


Possibly too advanced for the OP, but I would be using User Events to send the data back and forth.  This would negate the need for the timeout and the data is broadcasted to anybody registered for the event.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 18 of 19
(1,043 Views)

@stevenette wrote:

Ok, I have created 2 new vi's to better explain my position.


When developing code that involves multiple small VIs, "STOP MAXIMIZING THE DIAGRAM AND FRONT PANEL WINDOW TO THE SCREEN!". That's just obstructive, because you can only look at one thing at a time, mostly staring at whitespace. Painful!

 

Then you need to learn the basics first, because your code is completely constipated. To end the subVI, you should end the loop using the conditional terminal using another event (same for main). Then you need a timeout case to poll the global variable.

 

Many things can be simplified. In the main VI, you have N instances of identical code, differing only by a path constant. All you need is one instance that indexes into an array of paths using the tool selector.

0 Kudos
Message 19 of 19
(1,040 Views)