Manage Instrument Drivers with VI Package Manager (VIPM)

[chris.b]

This is something a few power users have asked me about. There's no Instrument Driver or VIPM Idea Exchange, so I thought I would post it here.

What if VIPM could manage Instrument Drivers from IDNet?
There are a few key benefits this would offer us...

• download IDNet drivers directly from VIPM 
• track which version of a driver you are using for different projects and revert when necessary 
• wrap up ID dependencies in a VIPC file for use at a customer site

 

[SteveChandler]

Excellent idea and Kudos but Isn't VIPM a third party application?

[jgcode]

This is a great idea Chris. Currently we create internal packages for any third party code we use in projects (ID's included) so VIPM can manage it's installation. But I would much rather have the author create the package and be able to download it directly from VIPM.

[crelf]

by SteveChandler on 01-19-2011 03:28 PM - last edited on 01-19-2011 03:29 PM

• Excellent idea and Kudos but Isn't VIPM a third party application?

Yes, but it's free, and it's the same application the LTN relies on.  In short, if you're not using it, you should be 🙂

[Jim_Kring]

You've got my vote 🙂

[Mellroth]

Thank you Chris for putting this on the idea exchange.

As I said in our discussion, I'd also like the instruments to be a separate group in VIPM.

/J

[tst]

I very rarely use IDs, although I can see the reasoning behind this very well.

There is one usability issue that VIPM needs to work out first, though - today, unless something has changed recently, VIPM shows all of the packages in the repositories it connects to. If you'll do that with the IDNet, you're going to get a bazzilion items in the list. This takes time both to download and to display in the main VIPM window, so VIPM will need a more intelligent mechanism for what should be displayed in that table before this idea can be implemented.

[Minty]

I think this is a really bad idea (let the flaming begin). It's the equivalent of Microsoft saying that you have to use a 3rd party package to use MSDN.

It also gives a serious commercial advantage to JKI over any other tool writers (are ther any...lol?). Not to mention those poor souls that are unable to use the JKI software due to company IT policies.

NI should be looking at upgrading the example finder or writing something else to match many of the features of the VI package manager instead. What is required is an integrated solution to versionng and upgrades of toolkits rather than reliance on a 3rd party.

[ibberger]

if VIPM is not the only source of driver packaes: ok if VIPM should be the only way to download drivers: I am strictly against it! I tried VIPM several times and always had problems with it (maybe because I use a english LV on a german Windows XP?). I don't want to be reliant on JKI or OpenG if I want do download a driver ... sorry guys, no kudos 😞

[chris.b]

Minty and ibberger - 

I take no offense to the resistance. I would never want to make it harder for anyone to download and use IDs. Also, I don't think it should be mandatory to use VIPM (or anything outside of LV) to get IDs.

However, VIPM as an alternative for managing IDs can be very compelling, especially for large and experienced LV teams, because of the ease of version management and distribution.

[gsussman]

I think that this idea would be more appropriate in the VIPM idea exchange than the LabVIEW idea exchange.