02-28-2020
07:43 AM
- last edited on
01-02-2025
09:16 AM
by
Content Cleaner
I'm trying to use IVI drivers for the first time, instead of instrument specific ones. I've installed the IVI compliance package, created a logical session in MAX as described in the somewhat out of date support doc: http://www.ni.com/tutorial/4594/en/
I haven't been able to establish a working path from a Labview IVI driver to the IVI configuration in MAX(IVI VISA resource in Labview shows nothing, and a manual entry can't locate the resource). For my test case, I'm working on a HP 34401A, but I have other instruments I'd like to get this working with (HP 83752A, 8562EC, R&S SML02)
Are there any newer support documents for IVI driver configuration, or should I cut my losses and use hardware specific drivers?
My software versions are:
Labview 2013 (LV 2018 also installed)
IVI Compliance Package 16.0
NI-VISA 16.0
NI-MAX 19.0
02-28-2020 07:53 AM
The ideas behind IVI drivers are fantastic, but the implementation is not always good.
The same problem with hardware specific drivers, but you can go inside and see what goes wrong and even implement changes.
I made some high level wrappers with LVOOP around standard drivers and they solved the problems of changing instruments without a lot of changes for the implementation.
I would advise to use the same approach.
04-23-2020 02:36 PM
Hi Albert,
My circumstances appear identical to KipK12.
Although I'm no stranger to different methods of creating non-public hardware abstraction layers (of different flavors, usually based in object-oriented programming / classes), I'm not as experienced in the IVI standard. The "instrument specific features" limitation of IVI isn't that important to me.
From my understanding, IVI presents an option to install a minimal set of dependencies like KipK12 mentioned, without a hardware-specific driver, and without investing my own effort in wrapping things up in classes. So I want to follow-up with you on your comment:
@Albert.Geven wrote:I made some high level wrappers with LVOOP around standard drivers and they solved the problems of changing instruments without a lot of changes for the implementation.
I would advise to use the same approach.
I suppose these questions apply to anyone who may be reading this and has done something like you have:
I'm trying to get a feel for estimates on a "level of effort" for incorporating IVI vs developing yet another independent, non-public hardware abstraction layer.
04-23-2020 05:12 PM
Hi
1) I did not use IVI at all just the standard api. The biggest problem was to slect which functions should or should not be added to a specific instrument, I used the IVI approach of a minimum set of features. So to say I looked at the IVI api and tried to stay close to that.
2) I used the original driver and added an api to call that original interface and made sure the result fitted in the api.
3) I don't know yet if I can exchange what I have. I'm retired but can within NI give you all the details if needed. I have to dig it up from my NAS but what do you really need.
4) It took considerably effort to find out what we wanted in a time that LabVIEW had not a full blown object oriented system. But what I can share I will share.
04-25-2020
12:19 AM
- last edited on
01-02-2025
09:18 AM
by
Content Cleaner
@KipK12 wrote:
I haven't been able to establish a working path from a Labview IVI driver to the IVI configuration in MAX(IVI VISA resource in Labview shows nothing, and a manual entry can't locate the resource).
I'm seeing the same thing. I haven't overcome this issue in LabVIEW NXG 4.0 with ICP 19.5. However, in Visual Studio there wasn't any problem talking with the instrument, taking measurements, etc using all three of the below:
Not sure what's going on. Sorry that may not help other than to let you know you're not alone.
Somewhat separate - the instrument driver I'm trying to use is IVI-COM, and NXG uses a DNI (dotNET Interface) component to handle interoperability with dotNET assemblies, then you select the methods and properties are available through the "project items>>software" side-menu - so I also tried that approach. And there was a "gotcha" I missed at first when installing ICP, where all the check boxes weren't checked that included .NET. In any case, haven't had any luck yet..
@KipK12 wrote:
Are there any newer support documents for IVI driver configuration, or should I cut my losses and use hardware specific drivers?
For my current application, I'm evaluating the acceptability of IVI, as well. NI's source-measure units (SMUs) conform to the IviDCPwr class, far as I know....but one thing I have found is that you should always check the readme from a vendor. Recently I've been struggling with a Keithley 26xx SMU which apparently belongs to a "custom" IVI class instead of a standard class. It's in the readme, line 2 or 3.
More to your question about other documentation - I am not aware on the NI side, but other vendors have their own flavor of how they comply with setting up IVI instruments in their own tools. Maybe one of those could help?
Not a great answer, but maybe one of the other resources could help you catch something that was overlooked.
On my own side of things, for whomever reads this later, I want to correct something I said:
@TimmTheEnchanter wrote:
From my understanding, IVI presents an option to install a minimal set of dependencies like KipK12 mentioned, without a hardware-specific driver, and without investing my own effort in wrapping things up in classes.
The part above that I striked through (like this) is, at best, poorly worded - at worst, wrong. IVI provides a type-of-hardware driver. An instrument-specific driver is still required.
04-25-2020
02:04 AM
- last edited on
01-02-2025
09:18 AM
by
Content Cleaner
Hi KipK12,
I happened to find a post that describes a behavior that sounds very similar to what you and I saw. It details that there is an IVI Engine and Adapters software package that should be installed to overcome the blank / empty / no logical name appearing issue. It was released in 2017, so if your software includes IVI Compliance Package (ICP) 16, maybe this is why you're seeing the problem. I hope this helps you.
Unfortunately, it didn't work for me, but I am using LabVIEW NXG, so that is very different.