Instrument driver management on multiple testers

[Bob_Albern]

I have several test systems running LabVIEW, each with a different but highly overlapping hardware set. The hardware is an assortment of PXI instruments and high speed and high precision rack equipment. The nature of instrument drivers is such that they are rarely complete or up to date. For instance, I have an Agilent 81304B scope that does not have a driver available from either Agilent nor NI but the commands are a superset of the 54xxx series of scopes. Therefore I started with the 54xxx driver and enhance it as needed. I also build setup utilities which I add to the drivers. This leads to compatability issues related to the "continuous improvement" activities between released products and the current drivers.

With this background, I have been trying to find a way to encapsulate the drivers with the software when I release a product to production. My current structure has a Master Instr.lib directory on a server with the latest drivers. When I start a new project, I copy the driver directory to the product directory and point all the SW to that copy of the drivers. If I create a new driver function that would be useful for future projects, I back it up to the Master Instr.lib directory. This allows new products to have the benefit of new functions without having to requalify released products every time I update the master lib.

The problem is that LabVIEW is way too good at finding copies of the instrument drivers on the network. Over time, I find the driver vi's are pointing to various copies of the instrument libraries on the network, even though the drivers are available locally. If I open a vi on new product B, LabVIEW may pull the code from the drivers for released product A without giving me any notice. In the course of my work, I will save the calling vi to my local directory. This also changes the search path for the driver vi on the production system for product A. The next time product A is loaded it flags a warning that the vi was found in a different location (the development system for product B). This sends the production people into an exception and stops production. They then come hunting for my head.

I have modified the options:path so only the local instrument driver library is searched but this problem persists. Why does LabVIEW search beyond the specified search paths and how can I stop it from doing so? I would rather not implement a strict revision control system. I don't have the time to maintain it and getting a half dozen test engineers to follow it would be like herding cats! Any suggestions would be appreciated.

[Andy F.]

Bob,

That certainly does sound like an undesireable situation.  LabVIEW shouldn't be searching around the network for VIs, so it might be possible that a previously linked VI remained in your top level VI.  What I might suggest is to create a VI that programmatically loads your Master library subVIs into memory from the local disk.  Since these VIs are open if you open the top-level VI and save it, the local disk locations for these VIs will be saved.  This could be a small VI that can be run when starting development and once the local disk locations are saved you should be ok.  Let me know if you have any questions.

Thanks!
Andy F.

[Bob_Albern]

Thanks for the suggestion, Andy. Unfortunately, it sounds cumbersome. I have over a dozen instruments with 463 subVIs in 70 folders in the instrument directory for one project. Is there an easy way to load all of them? Since I only use a small subset of the driver VIs for any given project, this would seem to demand a lot of overhead.

I have not verified the scenario that caused the driver links to get corrupted. I plan to conduct an experiment next week to find out. If it occurs as I described above, then preloading the driver VIs should force all tests to correctly load code from the local driver library. I don't know that loading the driver VIs will fix the problem with the production people seeing a warning message. If a driver link has been redirected, then a warning will still pop up that it is being redirected back to the local instrument library. 

I'll keep you posted on what I find. This is not my top priority so it may be a week before I get a chance to investigate.

Bob

[NIJanell]

Hello Bob,

I do agree that Andy's suggestion sounds cumbersome, but it also seems like the best one.  Take the following situation:

You have driver A, program A and vi C, which is included in driver A.  When you load program A, vi C is loaded as a subVI.  This time, vi C is loaded from the driver A location

Later, you are working on program B, which uses driver B (which is just a modified driver A).  It also calls vi C as a subVI.  Since you loaded vi C earlier, it remembers where it is located and loads the VI from driver A - which you don't want.  Unfortunately, this is done "under the hood" so we just have to work around it.  By loading driver B programmatically, we would be doing just that.

Let us know how it goes,

Janell R | Applications Engineer

[Bob_Albern]

OK, I’m willing to try loading the drivers when I start working on a project. With 450+ driver VIs in multiple directories, how do I do this programmatically, especially considering the VIs will be changing regularly?

This still leaves another issue. If I’m working on program B, pull up a VI from program A for reference, and inadvertently save it out, the next time program A is run in production it will give a warning. I know nothing is wrong with the code but the production people do not. Is there a way to suppress the warning messages for an operator account?

Thanks,

Bob

[NIJanell]

Hello Bob,

While working with another customer earlier today, I found what I believe to be a much easier solution - LabVIEW Libraries!

Using the previous example with programs A and B, viC would now be known as programA.lvlib:viC.vi and programB.lvlib:viC.vi - now, LabVIEW cannot "confuse" them.  No more warnings to worry about either!  I think this is exactly what you are looking for.

Janell R

[Joe_H]

Unless I am missing something why not build an EXE of the vi for production. Seems like it would be much easier.

Maybe I'm wrong! If not then it would seem that the libraries would be the best bet. Although LV should not be looking for anything beyond the search path either.