LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best practice when altering driver VI's

Is there a best practice when we alter a 3rd part VI as part of a driver?

 

For example, often I will download a driver from NI and start using it in my project only to find that I need to alter a few of the VI's.

Normally I would just save the VI in question as new then give it a name with a prefix so I know the name of the original VI.

It gets messy when other VI's in the driver need to call the altered VI etc. 

 

So I am wondering if there is a best practice so when the driver is updated it can be updated in the project without fixing all the previously changed VI's?

0 Kudos
Message 1 of 6
(285 Views)

There isn't one rule on how to do that. I have seen the following options work for different use cases,

 

  • Create a wrapper for standard manufacturer drivers, and use the wrapper in your application
    • This allows you to change the underlying implementation without directly changing the original driver
  • Take the manufacturer driver as a reference or starter code, and copy the content to your new library of VIs; thereby, you can keep the library light only to your needs
  • If only a few VI have to change, create new VIs with the updated implementation and maintain it as part of the application and your dependency to the original driver is unchanged
Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 2 of 6
(275 Views)

One more approach that has become my go-to, when feasible.

1. Make a copy of the entire driver code library into a working directory of your own.  Then remove / uninstall the original driver to prevent future confusion between the original and the code you're about to start managing.

2. Use JKI's "VI Package Manager" to build a "code package" out of this copy.  This step will (among other things) create a code snapshot that you can revert back to if you ever want or need to.  Initially, it should be the original driver.

3. Learn how to install it into one of the standard LabVIEW folders (probably instr.lib, maybe user.lib).

4. Be sure that when you use the driver functions, you select them from out of the folder where you just installed them.

5. Make changes as needed to some of the driver functions within your own working directory.

6. Build a new version of your "code package" with VI Package Manager and install it to instr.lib or user.lib

7. Repeat steps 5 & 6 as you continue to develop and find more things you'd like to change or add.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 3 of 6
(215 Views)

Excellent suggestions!  There is 1 more VERT IMPORTANT step that you should take.   Go back to the original page on the Instrument Driver Network and select the "Submit Feedback" button.   If you describe your experience, and the modifications you felt necessary,  NI WILL close the loop with the Driver author and improve the quality for future users.


"Should be" isn't "Is" -Jay
Message 4 of 6
(203 Views)

I will have to research the proper way to disassemble then reassemble the driver library or break the relationships between VI's and just add them to my project.  I always seem to disassemble them incorrectly then have improper references, missing VI's or broken menus etc.  It's only a dozen VI's in total so I think I will just break all relationships and use them in my project.  

Thanks to all for the advice. 

0 Kudos
Message 5 of 6
(193 Views)

@JÞB wrote:

Excellent suggestions!  There is 1 more VERT IMPORTANT step that you should take.   Go back to the original page on the Instrument Driver Network and select the "Submit Feedback" button.   If you describe your experience, and the modifications you felt necessary,  NI WILL close the loop with the Driver author and improve the quality for future users.


I have provided feed back on several driver packages on Instrument Driver Network and nothing was ever updated. 😞

Example: RIGOL DSA800 Series Analyzer

Example discussion about the driver can be found here.

---------------------------------------------
Certified LabVIEW Developer (CLD)
0 Kudos
Message 6 of 6
(148 Views)