Start Asyn Call function

[mcduff]

Don’t have LabVIEW here, what to you want to do with reference?

In the VI that is called you can get the reference there.

if you really need that reference try converting to a variant to get rid of the cyclic dependency.

mcduff

[Bob_Schor]

Sorry I didn't see this earlier.  Here is how to do Start Asynchronous Call.  This method has the virtue that if you create an Application (a.k.a. an "Executable"), this code will continue to work with no modifications.  The key step that you missed is that you need to wire a Strictly-Typed Reference to the Open VI Reference function.  Here's the Top-Level code (also see attached):

Bob Schor

[mcduff]

---

@Bob_Schor wrote:

Sorry I didn't see this earlier.  Here is how to do Start Asynchronous Call.  This method has the virtue that if you create an Application (a.k.a. an "Executable"), this code will continue to work with no modifications.  The key step that you missed is that you need to wire a Strictly-Typed Reference to the Open VI Reference function.  Here's the Top-Level code (also see attached):

Bob Schor

---

I believe the main problem the OP was having was that he was trying to bundle the VI Type Specifier Reference in their async call. That led to a weird cyclic dependence where the type specifier was not correct.

mcduff

[Vasilich2004]

I agree about "weird cyclic dependence". Vi reference is like pointer and it shouldn't be like that.

I tried to use "Strictly type reference" (didn't know about that ... thanks!!!) but still reference line is broken in my program. File is attached but I can't copy from Paint into here.

Later I will try to cast reference to something else but I assume it would be trouble in re-casting place.

[mcduff]

---

@Vasilich2004 wrote:

I agree about "weird cyclic dependence". Vi reference is like pointer and it shouldn't be like that.

I tried to use "Strictly type reference" (didn't know about that ... thanks!!!) but still reference line is broken in my program. File is attached but I can't copy from Paint into here.

Later I will try to cast reference to something else but I assume it would be trouble in re-casting place.

---

You still did not answer the question, what do you need the reference for? There might be a simpler solution.

mcduff

[TomOrr0W]

@Bob_Schor

I have stopped using strictly-typed references for asynchronous calls due to the advice I found here: https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/ and some of the discussion here: https://forums.ni.com/t5/Actor-Framework-Discussions/Asynchronous-Calls-in-the-Actor-Framework/m-p/3....  I haven't had any issues since doing so.  Other than the reference not being strictly typed, my code typically looks similar to yours.

Are you sure that the reference needs to be strictly-typed?

[Bob_Schor]

I did, indeed, "miss the point" that @Vasilich2004 was trying to make, namely the difficulty of passing a reference to the sub-VI being called asychronously as part of an input parameter of that same VI.  I can envision a situation where you might want a reference to a VI passed as a parameter to the VI itself, namely an attempt to call the VI recursively (making it what LabVIEW calls a "reentrant" VI).  Assuming this is what you were trying to do, I made two changes to the VIs you attached -- I removed the reference to the called VI, made the called VI reentrant, then tried wiring everything up -- it "worked" (meaning that there were no obvious errors).  Whether it makes sense or not, I can't say ...

About eight or so years ago, I needed to run a number of identical "clone" sub-VIs, each one handling an experiment-under-test, with identical VISA and camera hardware taking the data.  I originally tried creating the clones with VI Server, but it was a real mess, so I tried the newly-released Start Asynchronous Clone method.  I also didn't like using Strictly-typed references (I forget how, but I managed to figure out how to make things work without Strict Typing), but problems arose.  I also discovered that I had to worry about changing the code if I wanted to build an Executable.  I "stumbled" upon the method I described, which (almost) always worked for me, and have never regretted it.

Note the "almost" in the last sentence.  When you spawn an Asynchronous Routine, it is very important that you take care to have all of them exit, even if their caller stops running.  At one point, trying to debug why things were not working, I wrote a little utility that went looking for "orphan" routines and allowed me to (manually) abort them.  I haven't had to use it in many years as I have tried to ensure that all of my running routines "shut each other down" in case of an unexpected error.  Proper Error Handling is definitely warranted when you have VIs running autonomously!

Bob Schor

[Vasilich2004]

@Bob_Schor

could you, please, attach code.

Yes, you are correct with few my projects.

1. An application consists of

- 4 (multiply!) stages on the same serial port

- few devices based on the stages. there are few instances of particular devices.

- main application

2. Such applications DO require careful return resources or application will be hanged and visible into Windows Task Manager. During compiling Async call vi requires to be included (I use "Task" suffix) and etc.

But! Combination of 

- reentrant VI which starts by async call (could you, please, provide a link to Start Asynchronous Clone method) 

- Memory Control Functions

- insertion reentrant VI into subpanel

allows to simplify main application, create independent library with clear test code. Also getting all serial port answers by one vi which sends events allows to decrease amount of reentrant VIs (unfortunately, it can't help with slow vi, like stage absolute motion).

Long time ago I wrote such application in C++, then in C# and now found way to write in LabVIEW.

[Vasilich2004]

@mcduff

I do explained in first message

====

keep all variables together

====

[mcduff]

---

@Vasilich2004 wrote:

@mcduff

I do explained in first message

====

keep all variables together

====

---

Yes, but that still doesn't explain. If you are using Call and Forget, you can close that reference immediately, if you are using Call and Collect you can close it after you collect the data. Normally, the collection is done outside of the Called VI, otherwise it doesn't make sense. So besides keeping variables together, what do you need it for?

mcduff