Slow Asyncronous VI Startups

[thutch79]

I was using a FG to store the reference for the main UI anyway, so this could work. That same FG was launching the UIs, so I'll have to move that out into a different subvi. I'll give it a try and let you know how it works out.

[JÞB]

---

@thutch79 wrote:

I certainly know how to make an asynchronous call by reference. I do that in other areas. What I don't know is how to obtain a reference to a clone generated when that call is to a reentrant VI. This is the reason I stuck with the "run VI" method. When you say "read up on populating a clone pool", do you have any links or threads I could start with? I did some quick searching without much of a return.

Actually, both methods were around for the course material I have for advanced architectures (2011). They actually compare the two. They did make it clear the ACBR is preferred, but again, I didn't know any easy way of getting that clone reference.

---

Which is why I pointed you here

see especially note 5

A bit more about the re-entrancy options Especially how to interact with clones in subpanels

NOTE Also that if scripting is enabled there are methods to set the allocation option programatically

See also a method to prealocate more (but not less than) the default number of clones in the clone pool

Type casting the refnum out of a ACBR or, P-Node or Invoke node with a vi server ref opened with option 0x40 to I32 yields a unique value for each clone.  See this modification of the shipping example "

• Asynchronous Call and Collect (Using Option 0x40) VI: labview\examples\Application Control\VI Server\Asynchronous Call By Reference:"
• 
  

If you really look close,  you'll see that the 0x40 option no longer makes a difference since each ref opened in a loop has a unique i32 (But take a look at the boolean.

Once you wrap your head around the subtleties (By digging into the help and examples) getting the behavior you want without ANY time penalties is fairly straightforward

Just to prove my point about subtlties

TRY to open a ref to the same vi prior to the loop that oens the 10 refs

TRY to place a pre-alocate method in front of the loop

The complier is getting pretty smart and not all subtleties have made the help file in any place I found it

[JÞB]

If you really look close,  you'll see that the 0x40 option no longer makes a difference...

I'll take that back.  Option 0x40 makes no difference in timing HOWEVER, there appears to be a subtlty in how the "Clone Name" property is assigned.  Without the flag the clone names ID number increment by 1 [Target - Async (Reentrant).vi:6570004,Target - Async (Reentrant).vi:6570005....]

With the flag the increment by 3 [Target - Async (Reentrant).vi:6570002, Target - Async (Reentrant).vi:6570005...]

This I don't understand at all but since performance isn't effected, I can live with it

[thutch79]

My new plan has a flaw. I was going to go the FGV route, but the way my splash screen start-up vi runs, I could potentially create a race condition. If I rely on the VI I called to register its own reference in the FGV, I can't be sure it's in my FGV by the time the subvi that loads them into subpanels executes. Therefore, I was turning to the solution offered by Jeff.

Attached is a simple example I was trying out by extracting what I thought I need from the example given. Everything seems to work great. I get the unique references to the clones I need. However, the Start Asynchronous Call node doesn't seem to start the VI now. Can anyone see what I did wrong? (note, I hard coded the path to the target vi, so you'll probably need to adjust that.)

[JÞB]

Thutch.  Go back through the help file links I sent you earlier.

You'll find that the clones should handle any vi properties that need to be set inside themselves

Its a subtle effect of why the boolean array in my prior example is all TRUE.  It sure is fun to find out all this for the first time isn't it!!!  (Painful but, hey you are learning something right?)

Some comments on what you missed on your first read through of the links

[thutch79]

I realized that I forgot the option flags a few minutes after I posted. That explains why nothing was running. I only had the FP.open in there because the VI I was calling wasn't opening (it was set to open the front panel when run). Once I fixed the flags, it started up the VI's correctly and opened them. I am planning to call and forget, so my options should be x40 and x80. 

I'm confused about your two first comments. This is exactly like the example you showed, right? You need a strict vi ref to use ACBR, right? And what do you mean by "wrong source"?

Since it was working correctly once I fixed the flag issue, I tried sending them to subpanels. However, I seem to get the base VI and not the started clones within my subpanels. Is this due to the subtlety you noted that all ref of clones are equal and point to the base VI? If so, my whole plan is probably shot. It doesn't make sense to store the refs of clones if I can't use them to place them into subpanels.

[JÞB]

Lets try one more quick mod to the modified shipping example:

Here We drop on of the CLONEs into a sub panel.

Try it.  when you hit the breakpoint use the RCM to open the BD (I set the option on the sub panel)  then look carefully at the title bar.  Go ahead change the index input to index array,  Drop a few more sub-panels in there (make sure you don't try to load the same clone in more than one sub-panel---It   Works like a Champ!  (Or like a Champion whipped out an example like this before):smileywink:

Spoiler

Damn, I should be getting kudos for all the pain I went through to learn this stuff    No, it wasn't fun but I had to solve it once a while back.

[thutch79]

Thank you for all the help. You're right...I should be hitting the kudos button.

I'm not getting it to work. I can't see why my try at it is any different from the example (except I plan on a call and forget, instead of call and collect).

[JÞB]

Your target is set to shared clones it needs to be preallocate  (VI Options Execution)

You are opening the ref the wrong way

(Some error chain clean -up as well) and you get this which works fine.

I know it hurts.....

[EDIT] silly snipette tool changing linked property nodes  to by ref p-nodes

[thutch79]

Sorry to keep bothering you, but it doesn't seem to work. It puts one in the subpanels, but it's not the clones. The clone numbers should be 1 and 2. Also, it leaves the target VI in a funny "running, but not running" state so I can't edit anything. The only way I've found to get out of that is to exit the project.

This time my co-worker clued me in to the fact that I could drag and drop you code pictures, so now I know the code should be the same (aside from putting in the subpanels and updating the static VI reference).