Preferred approach to deploying instr.lib drivers

[OneOfTheDans]

What is your preferred approach to deploying 3rd party instr.lib drivers between projects/computers/co-workers?

A couple options I've used, or at least considered, over the years...

1. Wing it; manually re-download a driver anytime it's missing/needed (haven't we all??)
2. Symlink instr.lib to a central network drive, which includes every driver we've ever used
3. Version-control instr.lib, sync it to each machine, include every driver we've ever used
4. Build & deploy a VIPM package for every driver we need, only install what's needed per-project

So how do you like to manage these things?

[santo_13]

I will go with #4 so that you have the option to install on need, this can be a hybrid with #2 so you can push updates to all machines.

IMO, #1 and #3 are too crude, prone to user errors, and not scalable with a larger team.

Edit: #5 create a central NIPM feed, push NI Packages for each driver to this feed, and users can open NI Package Manager and install from there as needed.

[Gregory]

I do not keep 3rd party instrument drivers in "instr.lib". I have a source code repository called "instrument drivers" where I store all of these. When I want to use a certain driver in my project, I make a copy of the instrument driver in that project.

Pros:

The project has all of the code it needs to run (besides stuff that comes from NI installers)

If the controlled version of the driver has a change that affects its behavior, the projects it was used in are not affected.

Cons:

Instrument driver code is duplicated with every project it is used in

If the controlled version gets a bug fix, it must be rolled out to each project it was used in

[JÞB]

Use a unique Virtual Machine for each project and deploy all 3rd party tools and drivers with a package built by the Lead Developer.  Yup, that means you have to capture the requirements before writing any code!  But, that is why you pay the lead to look forward to the delivery rather than write code first.

[billko]

We use any and all the methods mentioned here, plus some very liberal cross-pollination.  Whenever we go to management to ask for money to straighten all this out, they don't want to use department funding, but there is no money set aside in our various projects to fix it.  Then when management goes to the bean counters to try to come up with a way to pay for it, they get the narrow-minded bean counter "this doesn't add to the bottom line" response.

Just one more way corporations suck the life out of you.

[crossrulz]

Option #6: Don't use third party drivers that install to instr.lib

I find that most of the drivers out there barely work or do too much for what I need.  So I almost always write my own.  I will add that I am referring mostly to devices you talk to through VISA.  These drivers are then built into PPLs via a "core" project.  Projects then copy out the PPLs they need and keeps them in their own repository.

[OneOfTheDans]

Thanks all for the responses, sorry it took me a while to get back into the thread.

@santo,

Not really crude, I've actually had the best luck with #3 (version control)! Knowing the history of each driver is nice, and user can locally control which rev they're on. On the other hand, #2 (shared folder via symlink/Dropbox) is very bad. Although it's convenient at first, we eventually had big problems if anyone changed instr.lib, because it would instantly propagate to other developers who weren't expecting the change. Thanks for suggesting NIPM, I haven't used it (or VIPM) before, I'll need to look into both and see which fits our needs.

@Gregory,

The first LabVIEW project I inherited did something similar, albeit without version control. It became very difficult to re-use our code because copying a files between projects often end up pointing back to the original project's instrument driver (cross-linking). I guess if we took great care and setup each project identically it would be ok, but with a range of developer skills, we ended up with lots of broken projects. Since instr.lib is a symbolic location, moving our drivers there fixed most of the cross-linking problems. But I really like the idea of each project standing alone and owning its dependent drivers.

@Jay,

As much as I'd like to just make someone else manage the drivers, I'm on the hook here 😄

@billko,

Are you suggesting money alone can fix this, e.g. with some deployment solution? Or money for developers' time would fix it? Either way, what solution would you choose if you had no constraints?

@crossrulz,

I'm leaning toward a variant of your approach. I've found the same about instr.lib driver quality, but they're usually not so bad that I want to rewrite them all. I might keep 1 project per driver so I can develop one without needing the superset of drivers and dependencies. How do you track the PPL versions? On projects where I've copied PPLs around, I always lose track of who's up to date, and it eventually bites me by running an old plugin missing a bugfix, for example.

[billko]

---

@OneOfTheDans wrote:

Thanks all for the responses, sorry it took me a while to get back into the thread.

<snip>

@billko,

Are you suggesting money alone can fix this, e.g. with some deployment solution? Or money for developers' time would fix it? Either way, what solution would you choose if you had no constraints?

</snip>

Nobody wants to pay for something that they can't directly monetize.  They can't say, "We saved X amount of dollars by making distributions of our drivers," so nothing ever gets done.  If it were up to me, I'd make distributions in VIPM.  Let the library source code be the library source code.  I deplore using the actual library source code in instr.lib; I'd rather have the source code in its own folder and build distributions from there, and the distribution goes into instr.lib.  Then you grab whatever version of whatever driver you need from the driver repo.  (Some distributions may even contain customized versions that contain bug fixes.)

[Gregory]

---

@OneOfTheDans wrote:

Thanks all for the responses, sorry it took me a while to get back into the thread.

@Gregory,

It became very difficult to re-use our code because copying a files between projects often end up pointing back to the original project's instrument driver (cross-linking).

---

Yes, you should take care in organizing your files, especially for code that may be used in multiple projects. There are many VIs that I use in multiple projects, not just instrument drivers, so I think it's best to get in a good habit. It's just a little bit of up front time to save you a lot of pain in the future. All of my projects are arranged on disk as

• Project_Name (Folder)
  • Project_Name.lvproj
  • Instrument Drivers (Folder)
  • Re-Use (Folder)

[OneOfTheDans]

@billko, so it's a vote for drivers via VIPM, thank you! I understand your frustration about the bean-counter approach. Maybe you'll be glad to hear that has not been my experience. I've been using LabVIEW for 7 years at 3 different companies. All have been at least accepting, and usually supportive of standardizing things like drivers. They all understood the value of minimizing technical debt so you can achieve faster results when you need it. I wonder if the two extremes you and I have experienced have to do with different regions, different industries, different spot in the product cycle (e.g. R&D vs. manufacturing), or just plain luck. At any rate, I hope you're able to get the best of the bean counters someday!