How to develop a "VISA instrument driver" ?

[Garraty]

I work in a test instrument manufacturing company. Few years ago we have developed a USB instrument. We have developed hardware, UI software and also USB driver. Now it's necessary to make this instrument more "standard" in particulary about the possibility to program and control it from Labview or .Net applications. It's also very important to add a LAN control.

After reading a lot of documentation found on the net, I don't have very clear how to proceed. Big instrumentation manufacturers provides IVI driver, and I think this is the first step (and by Nimbus of Pacific MindWorks is not a problem).

And then, I don't understand what I have to develop. I think that I have to develop something like a "Visa driver" but everything I find about Visa, seems to be from the client perspective. I think also that is necessary a SCPI parser. I have also read this topic http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Where-can-I-find-Visa-server-examples/m-p/132... , about Visa and 488.2, but .... nothing is clear !

Any suggestion about my problem ?

Thanks in advance.

[Dennis_Knutson]

There are 3 types of IVI drivers. IVI-C, IVI-COM, and the new IVI.NET. IVI-C is what is supported by NI and since you posted here, I would assume that is what you want to create. IVI-C drivers are created with LabWindows/CVI, an ANSI C compiler. There are many companies that will write IVI-C drivers (like the company I work for).

VISA is an API that allows a single driver to communicate to GPIB, RS-232, USB, Ethernet, PCI, and PXI instruments. It is not something you create. It is something that the IVI driver calls to read/write to the instrument. A VISA license comes with NI hardware such as the GPIB controllers or software such as CVI or LabVIEW. It can also be purchased. The VISA driver resides on the pc and sits above the low level hardware drivers.

SCPI is a standard for instrument command syntax and was originally developed for GPIB instruments. For example, a DMM would have a command like CONF:VOLT DC. It is a syntax that is easy to read and understand. If you wish to add SCPI syntax to your instrument, you would need a SCPI parser added to your firmware. It would probably be a welcome feature to the developer of your driver.

You might also want to consider USBTMC as a standard for the USB driver and VXI-11 or LXI for Ethernet. There is a lot of information at the IVI Foundation on the different types of IVI drivers, the instrument classes, SCPI, and VISA.

[Albert.Geven]

Hi

Please do not develop only an IVI driver. If everything was perfect IVI would have been perfect too but most of the time it is not and debugging and changes are almost impossible. Please look at standard LabVIEW drivers and implement your driver in that way. Debugging in LabVIEW is very powerful and we don't have a blackbox implementation we can't debug.

The idea of IVI of a standard API for a group of instruments is very good but can more easily be implemented by a small LVOOP layer on top of a standard labview driver.

look at this video for the tools available in LabVIEW already

http://www.ni.com/swf/presentation/us/labview/projinstdrv/

[Makoto]

VISA driver (or library) is one-level lower layer protocol than IVI drivers. So you don't have to develop VISA driver itself. VISA is simply an I/O driver, which does not depend on specific device models.  Any vendor's devices can be used with existing VISA drivers, as long as the devices are correctly supporting the required protocols (such as USBTMC, VXI-11, HiSLIP). 

As for SCPI, the command parser is all responsible by the device firmware.  VISA does not interpret any command strings even if they are SCPI-compatible.  VISA is only a protocol-wrapper of I/O interfaces.

As for IVI drivers, you will have to develop them for your device model basis. (Of course you can develop one driver that supports all the model variations in the same series at once.)

Therefore,

PC side:

IVI Driver --- you need develop

VISA Driver ---  *** no need to develop ***

USBTMC's kernel-mode class driver --- *** no need to develop ***

Firmware side:

USBTMC/VXI-11/HiSLIP protocols --- you need develop

USB physical driver --- you need develop

SCPI parser --- you need develop