07-19-2021 10:21 AM
I've been using LabVIEW for 3 years now and I'm digging into the NI supplied IVI Drivers for the 2nd time now. My goal is to get and use canned drivers that fully support my instruments to save test software development time. IVI drivers claim to be that solution.
So I'm starting with a simple Keysight 34465 benchtop multi meter. I've coded my own drivers for stuff like this before so I know the SCPI commands and such. I write very lean and simple drivers that run fast.
When I look under the covers of what makes this thing go is how very complicated this driver actually is! LabVIEW is not a fast environment but with all this stuff going on underneath, how fast can this thing actually run, and its really just a wrapper for SCPI commands.
I'm trying to get a handle on just how useful these driver actually are, do they actually save development time, and are they actually widely used?
Thanks!
-John C.
Solved! Go to Solution.
07-19-2021 11:01 AM
I'm personally not a fan of the NI drivers. As you stated, they tend to be overly complicated and still don't quite do what I want. I just write my own with only the details I need.
07-20-2021 10:30 AM
You're the second person to say that. I have a peer here who has done lots more LabVIEW than me who rolls his own simple, specific drivers for his projects.
I was just really hoping that I could get something to save me time and have a common way to do things.
07-20-2021 06:29 PM
It just depends on your use case, if you know what you're doing and how to do it, writing your own SCPI wrappers is the best way to go but at what cost?
If you're performance-hungry and want to cut down every ms of automation time, sure writing specially catered SCPI wrappers is the best way to go.
It is analogous to writing a program in machine language vs any programming language, things were wrapped up to make it easy for the majority of the audience and not everyone.
07-21-2021 07:33 AM
That's a very valid point, if performance is critical then you need to write your own and they have to be very specific.
I guess the issue I'm having is they are too complicated and my experience with two of them has been poor. In two cases I downloaded LabVIEW IVI drivers, that were certified, and they didn't work. That's a really big disappointment after reading through IVI Foundation material with lofty goals.
07-21-2021 08:33 AM - edited 07-21-2021 08:35 AM
One more thing, third-party drivers available on NI website are not developed/supported by NI.
Since you mentioned Keysight 34465 IVI drivers, that should have been developed by Keysight and handed over to NI to be available at a central location. I don't think NI has the time or resources to verify every such instrument driver, they do a code quality check and could not do the functional tests without the hardware and setup.
If your complaint is about a third-party instrument's driver functionality, it has to be directed to the manufacturer and not NI, you would not complain to Microsoft if the .NET drivers of keysight DMM does not work or has issues.
Same applies to LV project-based drivers for third-party instruments.
07-21-2021 10:10 AM
OK, what I'm hearing on these forums, and after talking to my peer who is very good with LabVIEW is that these IVI Drivers don't work out of the box most of the time and are not what the IVI Foundation intended.
It seems that most people roll their own with SCPI commands and write just what they need for their project and the goal of a large library of downloadable device drivers just isn't available, or they don't work.
Thanks for your time people.
-John C.