dumb instrument control

[Noddy14]

Hello,

We have developed a measurement instrument that passes raw data to the host PC via a USB interface. The instrument has little data processing capability.

The host PC runs the user interface (VB6) software to carry out all the data handling and processing.

We have developed a VB6 DLL library that can be called by another program to carry out the low level communication with the instrument as well as the necessary data processing.

The USB interface on the instrument is not USBTMC.

Now, we have been asked to provide a VISA driver for our instrument. We are unsure how this could be done. Would this simply entail modifying our DLL to accept VISA commands? If so, in genral, how could the DLL be 'knitted' into the users' application software?

Thanks!

[Supreeth.K]

Hi,

I am guessing you want your end users to be able to use your device with LabVIEW. If you are looking to do this, the best way forward would be to distribute your DLL to your end users. They can then integrate it with the LabVIEW code using a 'call library function node' in LabVIEW or better still if you are a LabVIEW developer, you can write a few basic VIs to encapsulate all the details away from your user.

If you want to make your devise VISA ready, I belive this would entail making the lower level communication protocols of your device compatible with the VISA API. Look for the VISA specifications here: http://ivifoundation.org/specifications/default.aspx.

Doing this would be like developing the USBTMC low level protocols. 

However your USB device can be used as a raw device in NI VISA. Please read through this article for more information:

http://www.ni.com/white-paper/4478/en/

If your users do this, then they would not be able to use the VB6 DLL you have written and they need to know the specifics of the communication protocol of the device. This would mean a lot of work for the end user which is not recommended.

I hope this helps.

Thanks and Regards,

[Dennis_Knutson]

There is no reason that a USB RAW driver requires the end-user needs to know the low level details. Just like a normal LabVIEW driver hides details of SCPI commands, yours could do exactly the same thing. The only advantage to using USB RAW is that the instrument would appear in MAX. Using the test panels would require knowledge of the low level protocol however. So, you have to determine what your end-user wants to do and how much time you want to spend on writing a second driver for the instrument. I don't think you could use a single driver unless you are emulating a serial port.