Jump to content

Tips/Tricks for Building Packages from Instrument Drivers


amaggs145

Recommended Posts

I am somewhat new to using VIPM, thus far I have been enjoying it very much. It feels great to have a clean/streamlined way to create, organize, and manage all of our reusable VI's.

 

One of our primary uses of LabVIEW where I work is to communicate with test equipment. We have a good deal of instrument drivers that we have written and also instrument drivers that we have downloaded from various places, mostly from ni.com. These instrument drivers are mostly in the Plug & Play form or the Project Style form.

 

I am eager to create packages of these various instrument drivers. I was wondering if there is a how-to somewhere that may outline the "best practices" when converting these types of instrument drivers to packages.

 

Besides being concerned with a good overall/general way of doing this I do have a few specific questions.

 

If we consider the project style instrument drivers (I have attached one here) all of the VI's are in a .lvlib library. To be honest, I have found these libraries to be quite annoying sometimes, they seem to be very glitchy as far as their internal linkages and things of that sort, I can't recall any specific gripes but I do remember them costing me alot of time when trying to develop some drivers using the .lvlib. When converting this type of driver to a package is there any need or benefits at all to keeping the driver VI's and other files in a .lvlib? I know this is how NI recommends to build instrument drivers, I am thinking it is to prevent cross-linkage with other drivers that may have the same name VIs, but with VIPM we are able to add a prefix or suffix to every VI in our package, I am thinking/hoping this will be sufficient enough to get rid of that .lvlib. Any thouhgts?

 

If I keep the same folder structure as laid out inside of the .lvlib, at the top level there is a dir.mnu file that contains all the info to map out the palette (and these .mnu files also include the info for the sub-palettes pictures I think...). Is there anyway to somehow import this file using VIPM to have it set up the instrument driver palettes the way they were designed to be when the driver was built instead of having to manually go through this process which includes removing VI's that are not intended to be visible, moving items around to have a more intuitive palette, and the most labor intensive part is copying all of the sub-palette icons from the original palette into VIPM. Maybe if we can't import this dir.mnu file directly are there any tips/tricks that can make this process a bit easier? Especially the sub-palette icons copying step, the only way that I know how to do this is to (1) go into LabVIEW and go to Tools>Advanced>Edit Palette Set (this takes quite a while to load each time), then (2) right click on a palette icon and choose to Copy Icon, then (3) Cancel any palette changes in LabVIEW or else won't be able to open icon editor in VIPM, then (3) go into VIPM and choose to Edit Icon, then (4) paste icon. I am getting tired just thinking about that process... Don't take this the wrong way, no complaints to VIPM at all, I am sure they are already thinking of a better way to do this if there isn't one already that I don't know about.

 

Thanks so much for any help, all comments/input are welcome and greatly appreciated.

 

Anthony

Temptronic TP04300.zip

Link to comment
Share on other sites

I'm happy to see you are using VIPM. Thank you for the positive comments.

I was wondering if there is a how-to somewhere that may outline the "best practices" when converting these types of instrument drivers to packages.

We don't currently have a how-to tutorial on this. That's a great idea.

I know this is how NI recommends to build instrument drivers, I am thinking it is to prevent cross-linkage with other drivers that may have the same name VIs

One other thing to consider is that lvlibs provide the ability to control access scope on certain VIs. You can specify private scope and protect access. So keeping the code inside of the LVLIB is prudent in this case.

One thing that would be nice is to have VIPM respect this Scope setting and hide items in the palettes (during autogeneration) if they are set to private scope. This is a feature we are considering.

Is there anyway to somehow import this (dir.mnu) file using VIPM

This is not currently possible but is a feature requested by others and is something we are considering for a future version of VIPM.

 

Thank you for all the feature requests. We love to hear what customers want in VIPM in order to be more productive.

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Instrument drivers continue to be a headache to manage with LabVIEW. This refers to both "VISA" and "3rd party DLL based" instrument drivers. There are many issues encountered when dealing with instrument drivers:

 

  • LLB Based Legacy Instrument Drivers that cause conflicts with other VIs
  • DLL Based Drivers require an installer and DLL registration
  • Most installers only install to a single version of LabVIEW

 

 

I could see great value if VIPM could streamline the conversion of an instrument driver. An instrument driver "wizard" would seem to be the most logical way at handling the package building process with the following features:

  • Conversion of a LLB based instrument driver to a LVLIB along with icon extraction
  • Ability to create a package (installer/uninstaller) that is not based upon a LabVIEW version and accessible as a dependency across all versions of LabVIEW
  • Ability to run an installer
  • Ability to run an uninstaller to remove an instrument driver
  • Ability to target MULTIPLE LabVIEW installations for a single installer/driver

(The installer/uninstaller could be accomplished through the Custom Actions, but requires additional work that could be automated with a command line switch.)

 

This would allow a VI Package Configuration to also include 3rd party instruments and would greatly improve the value of VIPM.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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