01-11-2019 03:24 AM
wiebe@CARYA wrote:
@Yamaeda wrote:
But that will wait until the VI is done...
Yes, I forgot the 0x40 option when opening the ref. Close enough. 🙂
/Y
01-11-2019 03:30 AM
@Yamaeda wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:
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.
01-11-2019 03:39 AM
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
01-11-2019 04:36 AM
@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.
01-11-2019 05:28 AM
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
01-11-2019 08:39 AM
@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.
01-11-2019 10:59 AM - edited 01-11-2019 11:12 AM
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.
01-11-2019 11:05 AM
@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.
01-11-2019 11:11 AM - edited 01-11-2019 12:00 PM
@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.