Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Want to control Keithley 2420 with IviDcPwr in C# .net

Hello,
 
I want to control a Keithley 2420 SourceMeter as a dc power supply using the ivi driver.
Language is C# under .net.
 
- I wrapped the Keithlex 24xx Visa driver, this works.
- I wrapped the IviDcPwr driver and configured the Kethley 2420 under MAX where I referred to the Keithley 2400 Ivi driver.
  Initialization works, but most of the IVIDcPwr functions are not available. Tke KE2400 driver seems to be a DMM driver not supporting the Dc Power commands. It seems to be the same if I wrap the 2400 driver direclty, but then I get no informations by NISpy.
 
Does anbody has some hints for me which is the best way to integrate ivi drivers in C# .net?
 
Regards
Roland Gesche

Message Edited by Roland Gesche on 07-28-2005 02:01 AM

0 Kudos
Message 1 of 6
(5,124 Views)

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.

0 Kudos
Message 2 of 6
(5,115 Views)
Dear Mr. Burnside
 
> 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?
 
Yes, exactly. For me this seems to be the best way to use drivers in .net as fas as function panel files (*.fp) are available. I tried to use references too, but some DLL's needs to be converted by Tlbimp first (just inconvenience) and frequently methods are missing in the added reference which makes it unusable. 
 
> 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?
 
Yes, I tried 2 ways:
 
1. Wrap the IviDcPwr Dll from National and configure the instrument by MAX with reference to the Keithley KE2400 DLL. NiSpy is showing calls to the KE2400 DLL but unfortunately not the GPIB communication which is shown if I use GPIB directly.
.
2. Wrap the Keithley KE2400 DLL directly. In this case, the Logical Name and the GPIB interface configured in MAX is active too,
but NISpy does not show any communication. Functionality is the same as 1.
 
IVI would be great, but now it seems to be a problem to get a IVI DcPwr driver for the Keithley scope meters which supports at least the basic function set. 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.
 
We are going to change from LabWindows/CVI to measurment studio. Of course, we can use the VISA drivers and make C# classes to communicate with the instruments. But then, we are going to reinvent some parts of the IVI concept whic seems the only possibility if I can not get the drivers working with the functionality I need.
 
Best would be to have native .net IVI drivers. Are threre any ideas if and in which time scale these can be expected?

Best Regards
Roland Gesche

0 Kudos
Message 3 of 6
(5,110 Views)

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.

0 Kudos
Message 4 of 6
(5,094 Views)

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

0 Kudos
Message 5 of 6
(5,079 Views)
From your last post:

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?

If you pass a driver session name to a specific driver rather than an actual resource descriptor, the driver will use the settings from that driver session to determine initialization options like simulation. If you use a driver session name with the InitWithOptions function, the values in the option string take precedence over the values in the driver session settings in the config store. So, if you use a driver session name with a specific driver where the driver session has enabled simulation, you will have simulation enabled for the session. You can override this by passing "simulate=1" to the option string parameter of InitWithOptions, or simply create another driver session for use in your application where simulation is disabled.
0 Kudos
Message 6 of 6
(5,075 Views)