07-28-2005 01:50 AM - edited 07-28-2005 01:50 AM
Message Edited by Roland Gesche on 07-28-2005 02:01 AM
07-28-2005 09:06 AM
I'm assuming you're using the 2400 series IVI driver available from Keithley's web site? I downloaded and examined the driver, and you're right - it doesn't support the IviDcPwr class. It does appear to have a large number of instrument-specific driver attributes related to sourcing power, though. I'm not sure I understand what you meant when you wrote "It seems to be the same if I wrap the 2400 driver direclty" - can you clarify that for me?
When you say that you "wrapped" the drivers, did you mean that you used the Measurement Studio .NET Instrument Driver Wizard to create .NET classes around the drivers? This is currently the best way to use instrument drivers in either C# or VB.NET. If you have additional needs that this tool does not meet, I'd be very interested in discussing it with you further.
07-28-2005 09:36 AM
Best Regards
Roland Gesche
07-29-2005 10:10 AM
Hello Roland,
Having "native" .NET drivers depends first on having a set of specifications from the IVI Foundation describing the requirements of those drivers - what interfaces they have to support, installation and deployment requirements, modifications to the config store, etc. The IVI Foundation is working on defining .NET interfaces for drivers, but there is currently no schedule for when that work will be completed.
I would also point out that, even after those specifications are finalized, it is unlikely that all existing IVI drivers will get re-written in a .NET language. Just as the LabVIEW interface ofr IVI drivers is often created by making calls into the IVI-C driver, it is likely that many IVI .NET drivers would be implemented in terms of either the IVI-C or IVI-COM driver. This is not too different from using the wrappers generated by the Instrument Driver Wizard, although the actual API would probably have a more "native" feel.
Your statements about Ni-Spy had me a little confused: Whether you use the specific driver or the class driver, you should still be able to capture both VISA and GPIB information in Spy. Can you confirm from the Spy>>Options>>View Selections menu that you have the NI-488.2 and NI-VISA capture enabled?
I would also like to try and answer your question "For me it is still not clear what happens between my application (with a wrapped driver from National or from Keithley) , MAX, and the driver configured within MAX. Is there any documentation available.": The interaction between the class driver, the specific driver, and the Ivi Configuration Store (which is what you're actually working with when you go through MAX) does not change when you access a driver through a .NET wrapper. If you are using a wrapper around a class driver, that wrapper is communicating with the IVI-C compliant class driver dll. It in turn is accessing information in MAX to load the IVI-C specific driver, and delegating calls into it. Likewise, if you use a wrapper around a specific driver, it is communicating with the IVI-C specific driver, which in turn can access information from MAX for things like logical name resolution, virtual channel names, and initialization options.
It sounds like the biggest barrier you're encountering right now really has nothing to do with .NET, though - the Keithley driver you're trying to use does not implement the class driver interface through which you are trying to use it. This would be a problem regardless of the language you were using - you would see the same kind of failures in CVI or LabVIEW or VB6 as well. Unfortunately, there's not a lot we can do to fix that problem. I'd suggest taking it up with Keithley, and seeing if they'd be willing to produce a simple IviDcPwr compliant driver for that family of devices.
I would still like to get to the bottom of the NI-Spy behavior you're encountering - there's nothing about using a .NET wrapper on the driver that should impact that.
08-01-2005 06:45 AM
Hello Glenn,
you are right, there are some independent issues:
1. Native .NEt IVI drivers.
I have to wail for the IVI Foeundation .NETZ specificationa nd then for drivers from the hardware suppliers as far as they will make drivers for my (old) systems. But that is a long-term issue and not an actual problem.
2. NI Spy
> Your statements about Ni-Spy had me a little confused: Whether you use the specific driver or the class driver,
> you should still be able to > capture both VISA and GPIB information in Spy.
> Can you confirm from the Spy>>Options>>View Selections menu that you have the NI-488.2 and NI-VISA capture enabled?
Yes, all NI-xxx are checked.
I found a error on my side: Simulation must be switched off (don't simulate) in MAX.
Now, Spy reports:
a) All communication isf I use the wrapped VISA (KE24xx) driver: ok.
b) VISA but no GPIB communication if I use the wrapped IviDcPwr driver with KE2400 driver configured in MAX.
(But the unit reacts at least with a error beep, so there are some GPIB commands). I will do some more tests with this.
c) GPIB communication if I used the wrapped KE2400 Ivi driver: ok.
3. Communication
> If you are using a wrapper around a class driver, that wrapper is communicating with the IVI-C compliant class driver dll.
> It in turn is accessing information in MAX to load the IVI-C specific driver, and delegating calls into it.
ok, thats what I do in 2.b)
> Likewise, if you use a wrapper around a specific driver, it is communicating with the IVI-C specific driver,
> which in turn can access information from MAX for things like logical name resolution, virtual channel names, and initialization options.
Thats what I have in 2.c)
Also, the simulation setting from MAX is used?
In this case, the software setting in MAX driver sessions is not active, right?
4. Keithley
It is rightm, my major problem is the missing IviDcPwr functionality of the Keithley SourceMeter driver. I will contact Keithley regarding this issue.
Thank you very much
Roland
08-01-2005 08:57 AM
Thats what I have in 2.c)
Also, the simulation setting from MAX is used?
In this case, the software setting in MAX driver sessions is not active, right?