Open VI reference weird behavior

[Gub156]

Hello everyone,

I am currently experiencing a problem with my application and I can't seem to find the cause...

The application attempts to open a VI in an lvlibp using the “Open VI Reference” VI. It works fine the first time and I can use my software as expected. Then, the VI reference is closed and I try to open a new one... and strangely, the old VI reference opens, even though I previously forced the reference to close with the “Close Reference” VI...

Has anyone else encountered this type of problem?

See below for the VI in question with the probes and corresponding data.

[MECSO]

Hi Gub156,

I didn't have time to test this on my own, but just a thought: The VI's name and also the name of the library lvlibp are exactly the same, I'm not sure if this can be handeled. Does thi issue also occur when the library lvlibp name is different?

[tst]

Probe 30 shows the fully qualified name of the VI is "UserTestSequence.lvlibp:InitSeq.vi" and probe 25 seems to show that the second VI also has the same name and seems likely to be in another lvlibp that has the same name. You can't have two different VIs (or two different libraries) with the same fully qualified name loaded at the same time.

I don't remember what the Open VI Reference function does today if you give it a path which points to a VI with the same fully qualified name as a VI which is already loaded. I believe that in the past it would throw an error and today it loads the existing VI (since that's what you see).

The solution would be either to rename one of the libraries or to make sure you fully unload the first library before trying to load something from the second. I'm assuming packed libraries can be unloaded (I know that classes can't, but I believe packed libraries can), but it can be tricky, as you have to make sure you fully closed all the relevant references.

[Gub156]

Hi, ts, MECSO,

Thanks for your replies.

I'll have a look at your solution ts and see how to safely unload the complete lvlib before loading a new VI.

I'll post the answer here once I've found what I'm looking for 🙂

Regards,

Julien

[tst]

The best option would probably be to not have different libraries with the same name (which was the concrete suggestion made by MECSO). Is there a good reason for this in your case?

While I can imagine some scenarios where it might be relevant (for example, plugin systems which behave differently or have different versions of the same library), it seems like a recipe for having to be very careful with what you do if you expect to use those libraries during a single run of your program, since you don't load and unload libraries directly (assuming normal LV code, where you open reference to VIs, which then cause the containing library to load). I expect it would mean you need to manage all the dependencies carefully so that you don't have something loaded from the library and then used by some other part of your code, etc.

If you can avoid the duplicate names (or at least if you can set it up in such a way that a program only has a single copy), then things become simpler.

[rolfk]

Do you happen to have any class in the lvlibp? LabVIEW classes are not unloadable. Once they are loaded they stay loaded until you completely close LabVIEW (or at least the context it was loaded into such as a LabVIEW project). But a loaded class file would also keep the according lvlibp in which it is located loaded. There is no way around this.

The fully qualified name of a VI inside a lvlib (or lvlibp) is the entire path from the VI name up to and including the lvlib(p) component. For VI name comparisons this is what counts and the fact that you use multiple lvlibp with the same name for sure generates a lot of trouble. You should never do that.

[Gub156]

Hello rolfk,

I don't use classes in my libraries. However, I fully understand that using multiple libraries with the same name can be confusing and not necessarily appropriate. I will modify the way my program works in this way.

Thank you in advance for your valuable help!

Regards