LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

your own instrument VIs in instr.lib ?

Solved!
Go to solution

As I am digging into this code that I have inherited, I realized the previous programmer/programmers created their own VIs and placed them into the instr.lib directory.

 

The VIs are specific instrument related, but they do not follow NI's best practices and are a jumble.

 

It is not easy to tell which are VIs provided by the manufacturer and which are ones that have been derived from those VIs. It is a mess.

 

 

 

 

0 Kudos
Message 1 of 15
(3,788 Views)

I'm not sure if you are asking a question here, or commenting on your situation.

 

But one thing to note, there are many manufacturer libraries out there that aren't written very well either.  Sometimes creating a LabVIEW library was an afterthought assigned to a co-op engineer who has had little or no LabVIEW training.  Libraries with stacked sequence structures and abuse of local variable are signs of poorly written LabVIEW code.

0 Kudos
Message 2 of 15
(3,785 Views)

If you're asking how to differentiate, you should be able to find a VI tree from the original driver supplier, which your colleagues probably did not alter.

 

If you're asking what other people do, I personally do not use instr.lib very much. I usually keep instrument drivers with a project, so that if I move the code to another machine I don't have to make sure to download more things. However, sometimes it's very hard to make the drivers "forget" that they used to be in instr.lib... Once they are sorted out though, you can keep them in source code control and share them among many projects, so that if you do find a bug later, you can fix it in many places at once.

Message 3 of 15
(3,783 Views)

@RavensFan wrote:

I'm not sure if you are asking a question here, or commenting on your situation.

 


My question is what do I do given this situation?

Do I continue on this muddled path or try to fix it?

I had thought that the manufacturer's VIs be left alone in instr.lib and that VIs that I wrote would go into the project's subdirectories.

0 Kudos
Message 4 of 15
(3,779 Views)
Solution
Accepted by topic author njacacia

I would leave the manufacturer's one in instr.lib, and place your own either in your project folders on your hard drive, or create your own repository on your hard drive that can be shared among multiple projects.  My understanding is that is what the user.lib directory was for.

Message 5 of 15
(3,767 Views)

I've been where you are too many times, and am again today.  I was handed a mess of modified drivers and even modified NI vis!  You have 2 choices; untangle the mess or start clean.  

 

If you are familiar with LabVIEW and have a good handle on the task you are going to automate, its often best to start clean.  A good design pattern (state machine, producer comsumer, qmh, etc) and clear logic and code often make life much easier.  

 

If you're really pressed for time and the issue with the code seems small, ignore as much as possible, resist the urge to clean and just get dirty and fix it.  That's my day! 😉

 

As for driver untangling.  Obtain a clean copy, unzip and compare file dates as a first step.  You can compare the clean drivers to the modified ones to see what code changes were made.  If you're lucky maybe your predecessor found and fixed bugs!  ( There are bugs in both Keithley and Keysight/Agilent/Hp drivers that I've fixed, reported and never get updated. )

 

Good luck.

0 Kudos
Message 6 of 15
(3,708 Views)

But if you place a plug n play driver (including your custom ones) in instr.lib, doesn't the Instr Io --> Instr Drivers --> Instrument Drivers palette get auto-updated?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 15
(3,699 Views)

@njacacia wrote:

@RavensFan wrote:

I'm not sure if you are asking a question here, or commenting on your situation.

 


My question is what do I do given this situation?

Do I continue on this muddled path or try to fix it?

I had thought that the manufacturer's VIs be left alone in instr.lib and that VIs that I wrote would go into the project's subdirectories.


I'm going to offer you just a bit more advice.  

 

Making some assumptions f4rom what I think your situation may be.  (And let's see how close I get- I've been there)(

You inheireted a development enviornment from a "Lone Wolf" developer who didn't need to worry about irritating co-developers and didn't know when to update readme-files or even make vi.lib read only.

 

My guess is most of the vi.lib edits are cosmetic.

 

To do this compare get a "Clean machine with a fresh LabVIEW install and use a copy of the current vi.lib.  Set both read only and watch the modified dates of those vis.  Libraries will throgh a lot of "VI loaded from... and crosslinking is possible if you fail to load vi's / lvlibs to compare in a new project context. If you do find any non-cosmstic changes take notes and do not change anything in vi.lib Create a new re-named copy and stick it in user.lib

 

Modified objects in instr.lib can be handled a bit mor aggressivly.  It likely the developer actually made code changes for a reason.  (Not always a "Good Reason") But, be a bit open-minded to the changes those vis are not as rigorously developed as vi.lib vis.  The trick here is to distribute the working source code to the rest of the developers.  And, thats exactly what a Source Code Distribution is for!

 

Once you've untangled the mess remember to visit your next LabVIEW User's group meeting.  You may get the opportunity to meet the developer that left you that mess.  Sock'em one from me too! Smiley Wink


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 15
(3,693 Views)

I find this thread interesting in the variety of replies and insights, and hope there will be more replies.  Here's mine:

I'm a longtime LV developer in a small team, and though in practice we tend to work as individuals on separate projects, we share code whenever we can.

As far as placement of one's own and/or modified code goes, I've followed the following cardinal rules:

  1. NEVER modify anything in (or add to) vi.lib - that's NI's standard library, and gets replaced with each new release.
  2. Use user.lib for anything that looks like a good reuse candidate, apart from instrument control.
  3. Use instr.lib for any code developed to be instrument specific.  Whether NI-supplied, manufacturer-supplied, or organically-grown drivers.

Just about all my user.lib and instr.lib development is LVLIB encapsulated, for namespacing, icon patterning, reference documentation, and palette consistency.

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Message 9 of 15
(3,674 Views)

@DavidBoyd wrote:

I find this thread interesting in the variety of replies and insights, and hope there will be more replies.  Here's mine:

I'm a longtime LV developer in a small team, and though in practice we tend to work as individuals on separate projects, we share code whenever we can.

As far as placement of one's own and/or modified code goes, I've followed the following cardinal rules:

  1. NEVER modify anything in (or add to) vi.lib - that's NI's standard library, and gets replaced with each new release.
  2. Use user.lib for anything that looks like a good reuse candidate, apart from instrument control.
  3. Use instr.lib for any code developed to be instrument specific.  Whether NI-supplied, manufacturer-supplied, or organically-grown drivers.

Just about all my user.lib and instr.lib development is LVLIB encapsulated, for namespacing, icon patterning, reference documentation, and palette consistency.

 

Dave


I usually build packages with VIPM to install into either user.lib or instr.lib (as appropriate) and keep the "source" in a development folder.  That way I'm not editing "live" code.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 10 of 15
(3,662 Views)