LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Instrument driver's API

Hi guys!
I need help with one question. I have a number of devices with the same control meaning but with slightly different functionality (list of settings) and different APIs (it's a number of detectors of radiation). I need them all in my programm, and I need the ability to extend the number of devices and it's functionalities in future. The question is, do I have to create instrument driver for each one and then use it in case mode or can I try to create one extendable instrument driver with the common high-level API based on the other APIs?
Thanks!
 
0 Kudos
Message 1 of 5
(3,410 Views)

I would go with a common high level driver, Look at IVI for a good model, here a common driver architecture is defined for many classes of instruments.

 

Paul

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 2 of 5
(3,400 Views)
Seems like a good use case for LabVOOP to me. This is the name of LabVIEWs
native object oriented approuch.

Regards,

Wiebe.


0 Kudos
Message 3 of 5
(3,398 Views)
Hello Err,
       I agree with Paul that if would be good for you to look at the concepts that are implemented in IVI drivers. (ni.com/ivi)  Your instruments most likely don't fall under one of the current IVI classes, but there is a tool in CVI that helps you create a custom class driver.  If your instruments have an overlapping command set, you could just create one driver, with consessions made for the different models.  If your instruments have different command sets, you should probably create separate drivers.  My recommendation is that you start with the Generic LabVIEW Plug and Play Driver Template in LabVIEW and add your well thought-out radiation detection API to it.  You can then use that driver as a template and run the Driver Wizard for each instrument and then customize the generated driver.
      I highly recommend investing some time in your API design, so that you won't have to change it later in the development cycle.  It also really helps to have someone else to talk to about the API to see what makes sense to someone less familiar with the instruments.

If you would like, please let us know the following:

Instrument models and quantity of each
Average number of commands for each instrument
Communication buses (GPIB, Serial, Ethernet, etc)
Will you be using VISA?
Do the instruments already have dlls that are used to programmatically control them?
Timeframe of project

Cheers,

NathanT

0 Kudos
Message 4 of 5
(3,371 Views)

Thank you all for advices!

 NathanT:

I'll try to answer your questions.

- I participate in software development for spectroscopy, and a part of project is a module for spectral radiation detectors.  It's a number of CCD-arrays from Sony Ormins, Toshiba, Hamamatsu, Fairchild and other less known vendors.

- Each detector operated by approx. 10 commands, but for different model the number may be different. In other words, number of commands is varying from 4 to 15.

- Some of detectors communicate with PC via USB, and the others via RS485 (USB-RS translator). Also we plan to use Ethernet-based devices in future

- At the moment we use VISA only for one device, but in future there we plan to use it wider

- Almost all devices have dlls and documentation. The exception - message-based device, noticed in the previous item.

- It's a big project. I think it will evolve through the years.

 

0 Kudos
Message 5 of 5
(3,361 Views)