Slow loading of packed library

[peper2001]

Thanks, it works! No more loading screen and the library loads just once! Thank you guys.

However...Sadly, new issues keep coming over and over again!

The issue of the day is as follows:

I use "start asynchronous call" to load a specific VI (the one that simulates the device mentioned in the first post) which is located in a packed library. 

I do specify a "type specifier" in the function called "open VI reference" and hence, I have direct access to the connector pane of my VI in the "start asynchronous call" function (see picture attached). The connector pane of the VI, consists in 3 different type defs (two parameters (enums) and a bunch of queues references bundled in a cluster).

The type specifier is the VI located in the packed library itself and the connector pane of the "start asynchronous call" shows no coercion dot whatsoever. So it looks like the correct type defs are linked to the connector pane!

Despite all that, when I try to run the code, probe 5 (see picture attached) tells me that I have an error 1031:

"LabVIEW:  VI Reference type does not match VI connector pane."

Any hint on what is happening? My money is on the fact that the connector pane is constituted by type defs which could be broken in the building process.  Is there anything that needs to be taken care of when using type def and packed lib?

Thanks,

peper

[ThiCop]

Does it run in the development environment?

If yes, how does your build specification look like?

[peper2001]

Hi Thierry,

Yes, the main VI (the one calling the packed lib) is not compiled as an .exe, so it does run from the development environment.

In the build spec of the packed lib, all the parameters are at their default values (expect paths). The .lvlib which the .lvlibp is built from, contains only the simulation VI (no subvis included because some of them are shared with other part of the code).

Regards,

peper

[ThiCop]

Hello peper,

Is it possible top verify that this behavior is not actually linked to the packed library?

Or in other words:
Do you get the same behavior if you extract the VI you're running from the packed library and follow these steps:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/create_strict_type_vi_ref/

PS: I know that you know them but I'm just adding this for completeness and future usability for other people reading this.

Seeing that you cannot share the code.

Would it be possible to create a dummy example to illustrate the exact behavior?

With dummy example I mean:

- A VI with the same properties as the one that you're using from the packed library, but without any code in it. (including the project used to build this packed library)

- An extract of your main VI  that only contains the calling of this VI

[OlivierL]

Pepper, any chance that you put an old "Type Specifier" and you since changed it on your main VI?  Try making the same connections to your real VI and see if there is any coercision dots or any other errors.  You may have swapped terminals or added an input or output.  Without the code, it's very hard to tell.

[peper2001]

Thank you all for answering.

I'm really sorry about not being able to share the code. I know it's not easy to comment on code without actually seeing it.

Anyway, my issue is solved (for now...): I have saved a new copy of the type def containing all the queues ref, modified the type specifier of the "open reference" function,  mass compiled all the vi's in my project and finally rebuild all the packed library, et voila.

I don't know which of the aforementioned actions did the trick but anyway, my code works again.

Thanks again!

Regards,

peper

[ThiCop]

Thanks for the update!

If anything else pops up, then you know where to find us. 😉

[peper2001]

Hi,

My application is now running quite fine but I still got one problem.

My main vi dynamically loads other vi's with the "load by reference" function. If my main vi is aborted, the dynamically loaded vi's keep running in the background and i've lost track of their refnums.

The consequence is that I can't abort them and I keep loading new instances of the dynamic vi, each time I run the main vi. Eventually, Labview crashes because of too many vi's in memory.

So my question would be: is there a way to track all the vi's running in the background and abort them before loading a new instance?

Thanks for your help

[ThiCop]

Hello peper2001,

Is there a specific reason why you would want to see the Abort button behave differently?

Does your code in any way depend on the "Abort" Button?

[billko]

Didn't realize how far this thread has gotten.  Comment deleted.  🙂