Jump to content

lvlib question


Recommended Posts

VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs.

So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.

Link to comment

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

Link to comment

VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs.

So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.

That's a good description of how the system behaves, but not quite the understanding I'm looking for. Let me expand a bit wink.gif

Imagine a VI of Water.vi contained in Bottled.lvlib. Further, imagine that, unlike the current system, the VI knows nothing about the lvlib. The lvlib is more of a pathing "hint".

The fully qualified name of the VI could be constructued depending on how the VI is loaded: from the lvlib, you get Bottled.lvlib:Water.vi. Loaded independently, you just get Water.vi. Further, the VI could also belong to River.lvlib, or other libraries. Changing the name of the lvlib wouldn't affect the VI, and different libraries could span common components. Namespace collisions would, of course, need to be resolved.

Obviously, this isn't the way LV works, but I would guess that it was considered. So, why the two-way relationship? What breaks without it?

Thanks,

Joe Z.

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

Good point.

I've not looked into the protection mechanism: good food for thought.

Thanks,

Joe Z.

Edit: need to think about this some more...

Edited by jzoller
Link to comment

River and Bottle would be Projects. You can do the described feature with projects (and manually resolving your name conflicts).

Yep, that works... except for hierarchies of namespaces. Which application instance would your Bottled:River:Water run in? :)

Joe Z.

Link to comment

If the VI didn't know about the library:

  • Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
  • Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
  • Classes, XControls and StateCharts -- all of which are libraries -- would not work.
  • Licensing restrictions from NI would not work

That's it. ;-)

Link to comment

If the VI didn't know about the library:

  • Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
  • Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
  • Classes, XControls and StateCharts -- all of which are libraries -- would not work.
  • Licensing restrictions from NI would not work

That's it. ;-)

Ah, thanks Aristos, that explains it.

My personal use cases are a little different than NI's, so I wasn't seeing the reasoning.

Joe Z.

Link to comment

Joe, you're mixing namespaces with library membership. Perfectly understandable as Labview defines namespaces by library membership, but the concepts serve different purposes and hopefully the day will come when users can define their own namespaces. (I've blown the namespace horn enough I'm sure AQ is quite tired of hearning it.)

The fully qualified name of the VI could be constructued depending on how the VI is loaded: from the lvlib, you get Bottled.lvlib:Water.vi. Loaded independently, you just get Water.vi.

Hmm... dynamic namespaces determined at run-time? Interesting concept, although I admit I don't see what problem this is attempting to solve.

Further, the VI could also belong to River.lvlib the {River} namespace, or other libraries namespaces. Changing the name of the lvlib namespace wouldn't affect the VI, and different libraries namespaces could span common components.

Allowing a vi to be exposed via multiple namespaces... I'm right there with you.

Namespace collisions would, of course, need to be resolved.

That's the whole point. With user-defined namespaces collisions are less likely to happen and when they do they are easier to resolve.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.