packed library asynchronous call and collect

[littlesphaeroid]

I have an application working that loads the FP of a VI into a subpanel and then, when switching to another VI, collects the first VI's results using asynchronous call and collect. This is part of a drop-in test architecture I've been working on. I have this working well for tests deployed as llb's, but when I switched to lvlibp files, the collect step times out. 

Additionally, the load times for the packed libraries are exceptionally long, but are fast for the llbs. The packed libraries seem to ofrer some advantages (i get all kinds of cross linking issues going on with the llbs and my project file if both are open at the same time), but The snafus with the packed libraries are becoming irritating.

Thoughts?

[tyk007]

---

@littlesphaeroid wrote:

I have an application working that loads the FP of a VI into a subpanel and then, when switching to another VI, collects the first VI's results using asynchronous call and collect. This is part of a drop-in test architecture I've been working on. I have this working well for tests deployed as llb's, but when I switched to lvlibp files, the collect step times out. 

Additionally, the load times for the packed libraries are exceptionally long, but are fast for the llbs. The packed libraries seem to ofrer some advantages (i get all kinds of cross linking issues going on with the llbs and my project file if both are open at the same time), but The snafus with the packed libraries are becoming irritating.

Thoughts?

---

Well, unlike llbs, prioject libraries load all of their contents when the library is opened. This is true even for packed project libraries. Is it possible that the PPL load time is also what is giving you grief? You can minimise this by pre-emptively loading the PPL into memory ie. calling a containing VI on startup of your application to force the contents to load.

[littlesphaeroid]

I fonud the problem with the colect was that I was using a user event to stop the running VI, but the caller and running VI (in a PPL) were not sharing the same user event. 

Meanwhjile, I have been playing with pre-loading the test VIs, but the load time is incredible: several seconds per test (for less than 700kB) each. So if I have 40 tests, teh laod time is not going ot be acceptible ot preload the tests.

I've played around with loading times with different open VI reference paremetes (with and without a strich VI type, and using various options, but I don't yet have a solution. It's disappointing, as I don't see a path to a time-efficient plugin architecture. But it's not like htis hasn't been done before, so i'll figure it out eventually.

Thanks!!

[crossrulz]

---

@littlesphaeroid wrote:

I fonud the problem with the colect was that I was using a user event to stop the running VI, but the caller and running VI (in a PPL) were not sharing the same user event.

---

If you were using a FGV/Action Engine or a global variable to pass your User Events around, that would be the case.  You should pass your User Event into your dynamically called VI using the connector pane.

---

@littlesphaeroid wrote:

It's disappointing, as I don't see a path to a time-efficient plugin architecture. But it's not like htis hasn't been done before, so i'll figure it out eventually.

---

What version of LabVIEW are you using?  I know there has been a lot of effort lately going into trying to load VIs, especially from PPLs, faster.  I want to say there was a major speed up in 2014 or 2015.

[littlesphaeroid]

hI cROSSRULZ:

I am on 2014. Loading is slow. I don't think we're moving to 2015 any time soon.

I could pass in event reference, but in my prior architecture plan, I used a FGV for the event ref. I think I can still use this if I put it in a PPL, but in the meantime I've worked around this by getting a reference to the stop button on the called VI.

I love user events, and have implemented them quite a lot, but trying to move toward using PPL throws a wrench in the works.

[littlesphaeroid]

I'm getting loading times of <1s is I load from an llb, and 4-5s if I load from a PPL (lvlibp). This is unworkable in my applicattion. It means pre-loading test (can take minutes), or waiting for test to load on first run (increased test time=money) and reusing the references on subsequent calls. But for configuration it means the user is waiting many seconds for a tiny program to load. This is the first time I've ever been really sad about LabVIEW. 

[crossrulz]

I can't help but think that you have not modularized your ppls enough and you therefore have a bunch of duplicate code in each ppl.  Can you supply any examples?

[littlesphaeroid]

I'm certain there is duplicated code, but each currently has about 30 small VIs and is around 700kB. In order for the tests to be modular, they need all their code except any coded in a shared PPL, I htink. Well, I don't currently have any shared PPLs, but the sample/dummy tests I'vemade for testing my sequencer are really quite small and simple.

I have attach a sample PPL. 

[littlesphaeroid]

I have found after all these months that thepacked library load times are actually very fast when running an executable, and slower when run in the development environment. My test plugin architecture will keep the cursor busy almost constantly while running in the development environment, but runs quickly as an executable. The alvantages of the packed libraries over llbs in terms of namspacing has been a real advantage for this architecture.