LabVIEW
Asynchronous call
I have two VIs (see in the attachment).
The first VI (AsynchronousCall.vi) performs an "asynchronous call." (see in the following picture)
The following VI (Test.vi) is started by the asynchronous call. (see in the following picture)
The first VI only iterates over an array and starts the Test.vi. An element from the array is passed. This element should then be used in Test.vi. However, the first entry from the array is not passed correctly after the first call. It follows that my asynchronous program does not receive the correct input data.
Important: In order to recreate Senario, the front panel of Test.vi can be opened first after the asynchronous call. Because when it's open, it works as intended! The target/actual comparison is in the following list:
Target value
- Asynchronous program should have "Test_0" as input parameter.
- Asynchronous program should have "Test_1" as input parameter.
- Asynchronous program should have "Test_1" as input parameter.
- Asynchronous program should have "Test_3" as input parameter.
Actual value
- Asynchronous program is "" (empty string) as input parameter.
- Asynchronous program is "Test_1" as input parameter.
- Asynchronous program is "Test_1" as input parameter.
- Asynchronous program is "Test_3" as input parameter.
How can it be avoided that the string is empty the first time it is called?
The 32-bit version of LabView 2015 is used, but this Senerio also occurs with newer versions (32-Bit LabVIEW 2019)
Virtually nothing you say makes any sense.
- Please don't attach VIs that are owned by some crazy library. Disconnect from any libraries before attaching (!!!).
- Your subVI is not reentrant. It should be.
- The subVI should be configured to show the panel when called, else you won't really see anything useful.
- You are only calling the VI exactly three times (test 1...3) so you should only have three calls. Nowhere in your code is any string named "Test_0", so why do you expect that to appear anywhere? If you want that, create a string array with four elements accordingly.
- Greedy loops are not nice.
- If you have the reentrant subVI open in edit mode when you run the toplevel, it will turn reserved (so you cannot edit while clones are running!) but that instance has nothing to you with the reentrant instances you are calling, that's just a dummy at that point, so ignore it and make sure the subVI is closed before running the main VI.
Try the attached set. I don't see anything unexpected.
What problem are you trying to solve?
Are you sure asynchronous dynamic calling will solve it?
It never solved anything for me (just causes crashes and hanging VIs).
I've always found easier solutions for my problems.
Search LabVIEW like a graph! 
I have found that it can work. I have for instance classes that instantiate a background daemon through this, that keeps running in the background to process something and communicates with the class interface through queues, events or some other mechanism. However I would fully agree that this is an Advanced technique that should not really be attempted to be used before someone has gone through the entire Basic and Intermediate training courses and written a few applications with those techniques, before attempting to do Asynchronous VIs. It's the same in other programming languages, be it Futures (Java). Lambdas (C#), coroutines (Lua), or function pointers/callback functions (C++). These are generally advanced programming features that should not really be used until someone has a sound understanding of the programming language in question.
(And that's not directed at you Wiebe, I know that you know LabVIEW well, but you may have tried asynchronous VIs a few years to early and a burnt child tends to fear the fire.)
@rolfk wrote:
(And that's not directed at you Wiebe, I know that you know LabVIEW well, but you may have tried asynchronous VIs a few years to early and a burnt child tends to fear the fire.)
Yes, that is pretty accurate.
I think I tried them recently, and still got locked VIs. But even if they worked (for me), I'd still prefer dynamic dispatching, parallel for loops, and a few other techniques over dynamic calling VIs in general. Maybe also because dynamically calling OO code is harder and less often needed.
I guess it's up to OP now, to decide to share the use case... Maybe (async) dynamic calling is appropriate, maybe there's another solution.
