LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow Asyncronous VI Startups

Solved!
Go to solution

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.

0 Kudos
Message 11 of 27
(1,891 Views)

@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:"
  • !1.png

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


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 27
(1,875 Views)

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


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 27
(1,863 Views)

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.)

Download All
0 Kudos
Message 14 of 27
(1,853 Views)

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

!2.png


"Should be" isn't "Is" -Jay
0 Kudos
Message 15 of 27
(1,849 Views)

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.

0 Kudos
Message 16 of 27
(1,838 Views)

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

!3.png

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 Smiley Very Happy   No, it wasn't fun but I had to solve it once a while back.

 

 


"Should be" isn't "Is" -Jay
Message 17 of 27
(1,827 Views)

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).

Download All
0 Kudos
Message 18 of 27
(1,817 Views)

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.

 

POD Launch Rev.png

 

 

I know it hurts.....

 

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


"Should be" isn't "Is" -Jay
Message 19 of 27
(1,810 Views)

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).

Download All
0 Kudos
Message 20 of 27
(1,801 Views)