Slow Asyncronous VI Startups

[JÞB]

you are RIGHT!  loading two seperate clones into a callers in two subpanels set them run reserved but not running.

Run vi methods don't work right either since the clones are forced to share dataspace in order to work at all!

Looks like I'll learn something too!

I'll keep playing and get back later.

[Jed394 · Accepted solution]

---

@thutch79 wrote:

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

---

I'm not sure where you guys are at with this, but here is an example I put together very quickly.  This doesn't follow best practices but hopefully it illustrates what you are trying to do.  Run Launcher and it will load a main vi and spawn 3 subvis that run concurrently.  You can then select which clone you want to run in the subpanel of the main vi.

[thutch79]

Thanks for throwing together that example. I think this is probably my best approach. If I can summarize, you spawn the clones within a for loop by opening a reference and using ACBR to start them. Each sub then registers itself with a FGV by loading in the VI's ref from the "This VI" node. The FGV is then used to grab the desired reference in order to insert it into the subpanel.

That approach will certainly work. As I said before, it creates a potential race condition upon start-up. Since the sub has to register itself, I need to find a way to communicate that all subs are up and running before allowing the system load its initial sub-UIs.

Thanks all for the great help and advice. I learned a little more out of the experience.

[JÞB]

I knew there had to be a way to get multiple clones running in multiple sub panels-  Thanks for the lesson Jed!

[thutch79]

I implemented this today. With regard to my original need (i.e. faster load times), the difference is night and day. Instead of taking 4 to 5 minutes to load, my app is loading in under 10 seconds.

Now I'm off to eliminate the other place I used the .vit approach...

[Jed394]

@thutch79 wrote:

Thanks for throwing together that example. I think this is probably my best approach. If I can summarize, you spawn the clones within a for loop by opening a reference and using ACBR to start them. Each sub then registers itself with a FGV by loading in the VI's ref from the "This VI" node. The FGV is then used to grab the desired reference in order to insert it into the subpanel.

That approach will certainly work. As I said before, it creates a potential race condition upon start-up. Since the sub has to register itself, I need to find a way to communicate that all subs are up and running before allowing the system load its initial sub-UIs.

Thanks all for the great help and advice. I learned a little more out of the experience.

---

Glad that example helped.

As far as your startup sequence, I'm not so sure its an issue of a race condition as it is, "What is responsible for what".  Obviously you have the launcher that would start your main UI.  The next question should be is this main UI responsible for control of these subvi's or do they run totally independent.  If the Main is responsible for the life of the subvi/gui then it might be better for the Main to launch these vi's instead of the launcher.  Like I mentioned if you create a notifier in your main and then pass that into your subvi, the subvi can send a notification to main letting it know its fully loaded.  Since main knows how many subvi's it has launched it can wait for all these notifications and then continue and load the subpanel or error if there is a problem.  Basically the notifier replaces the Functional Global.  This notifier would also give you a good way to pass information from the subpanel up into the main if needed. 

 It seems like you are in the stage of development where I was a little bit ago.  Have you considered looking into the actor model of programming?  If your interested you could look into the actor framework or do some research on Daklu's Actor Oriented info.  The site Lavag.org has a lot of good info.  This link might get you started:  http://lavag.org/topic/17035-feedback-requested-daklus-ni-week-presentation-on-aod/

[thutch79]

Thanks Jed. Unfortunately this app has been around for a few years now. It's part of an instrument development effort. When I started the app, I was not too familiar with LVOOP. I've since become more familiar with it and have started to include it in many cases. I'm actually in the middle of a large restructuring of an area of the code to make it object oriented. This effort to fix the startup time was a bi-product (got sick of waiting for it to load while I was testing). Whenever I get into a new application, I will certainly read up on the actor framework. I generally try to figure out the latest approaches when starting. Before beginning this app a few years ago, I went through the advanced architectures course for that reason. Always love to keep learning....