Instrument Driver for a product family!

[balendran bala]

Hi,

I need write Instrument driver for our Test Equipment product family consisting of multiple cards. If I write the driver in a usual NI conventional method, i.e. one driver for per card, then there will be lot of duplicate codes between them and pain to maintain. Base code is exactly identical among them (50 % code). So, need your expertise to identify the best approach to write the driver. Any help is appreciated.

NI conventional method:

http://zone.ni.com/devzone/cda/tut/p/id/3271

Thank you,

Balendran

[Tomi Maila]

Hi,

I strogly recommend using object-oriented design for the instrument drivers. Object-oriented programming allows you to write generic interface class for all of your instruments and a specific driver implementation class for each of your instrument. All instruments can then be accessed using the generic interface class method VIs allowing to write generic programs that can use any of your instruments.

Functionality that is shared by all of the instruments can be implemented in the generic class so it can be shared by all of the instrument drivers. Functionality that is shared by some but not all instrument drivers can be implemented using a object-oriented design concept called composition.

I've been writing a few articles introducing to object-oriented programming with LabVIEW and have plans to go on with some more articles. Please take a look at the articles on my blog at Expressionflow.

Tomi

[LAVA 1.0 Content]

QUOTE(balendran bala @ May 14 2007, 09:06 AM)

I need write Instrument driver for our Test Equipment product family consisting of multiple cards. If I write the driver in a usual NI conventional method, i.e. one driver for per card, then there will be lot of duplicate codes between them and pain to maintain. Base code is exactly identical among them (50 % code). So, need your expertise to identify the best approach to write the driver. Any help is appreciated.

Welcome to LAVA!

I've never written commercial grade drivers for card based (PCI/PXI/VME) hardware before, so I don't know if there are special cases for this. I can tell you what I've seen though...

Example: Fluke has a group of GPIB based instruments called multicalibrators. The NI driver for these instruments is a single driver download. The driver use a combination of the IDN query, VISA properties and an error handler to initialize the instrument and to check if a command is valid with that instrument. The driver sub-palletes are also broken down to allow selection of commands specific for the model. You would write a single driver for the series, and include code to handle the different models...

Your could write a common function library that would reside in the root directory of your driver. This would be in the form of a LVLIB, and you would call this from the individual drivers. This would limit your driver to the later versions of LabVIEW ( 8.0 and up for LVLIBs). If your customers are using < 8.0, this wouldn't work...

Another option would be writing an IVI based driver if you're looking to market these cards for languages other than LabVIEW . I would contact NI and ask them for their advice on this...

As a final note, you might want to watch http://openmeas.blogspot.com/' target="_blank">Brian Powell's BLOG. He's a NI software architect who specializes in instrumentation.

[crelf]

QUOTE(LV Punk @ May 14 2007, 11:39 PM)

Fluke has a group of GPIB based instruments called multicalibrators. The NI driver for these instruments is a single driver download. The driver use a combination of the IDN query, VISA properties and an error handler to initialize the instrument and to check if a command is valid with that instrument.

QUOTE(Tomi Maila @ May 14 2007, 11:29 PM)

I strogly recommend using object-oriented design for the instrument drivers. Object-oriented programming allows you to write generic interface class for all of your instruments and a specific driver implementation class for each of your instrument. All instruments can then be accessed using the generic interface class method VIs allowing to write generic programs that can use any of your instruments.

These guys have absolutely got it right: if your instruments have enough commonality, you can combine both of these techniques so that with a simple *IDN? query at initialise object and can filter out the functions that aren't supported by your hardware. Depending on the hardware, writing a comprehensive driver can be difficult, so if you're not confident, I'd contact a system integrator.

[Mark Smith]

I agree with Tomi that in principle, OO code is the way to go. However, there's at least one shortcoming of the current implementation of LVOOP that you should be aware of. I recently wrote a LVClass (using LVOOP) that I wanted to distribute as "class Library" - that is, a set of VI's installed to a specific directory. As I found out, the Source Distribution build option in the Project Explorer does not work properly and that cascades down into being unable to use the project explorer's installer dialogs to build an installer. This could be a severe shortcoming for an instrument driver library that you would want to distribute with an installer. Here's my question to NI Support and their answer

Question:

I have a project with a LV Class. I want to 1) distribute the LV Class as part of a source distribution and 2) create an installer for the source distribution. While I can build a source distribution that includes a LV Class, I cannot generate a preview for the source distribution. This apparently prevents me from creating an installer for the source distribution, since all I can see from the Source Files dialog on the Installer Properties is <Error generating preview>. A simple example is attached. Is there a workaround?

Answer:

"...

This limitation of the LabVIEW class is a known issue with LabVIEW 8.20, and is being addressed in a future release of our software package. There currently is not a workaround for this issue. However, I am interested in working with you to try and find a workaround. Can you please give me information about your desired behavior. Are you simply looking to move the class to another computer?

..."

You could most likely get around this limitation using a third party installer if you want to go this route.

Also, building a class with an "interface" like implementation (methods meant to be overridden in child classes) requires Dynamic Dispatch terminals. Methods built with Dynamic Dispatch terminals cannot be invoked using VI Server calls. This may or may not be important to your implementation, but it was an important limitation to me. All in all, I decided LVOOP in LV 8.2 is a good start but not ready for prime time. I'm interested to see what gets addressed in LV 9.x.

Lastly, I don't have much experience with the third party LabVIEW OO tools, so there may be some options there that would work well for you.

So, given the current state of LV, I would agree with LV Punk that using the LVlib (LabVIEW Libraries) to build a set of driver libraries would work well. The source distributions and the installer are easy and in my experience reliable using LVLibs.

[JDave]

QUOTE(crelf @ May 14 2007, 07:20 AM)

These guys have absolutely got it right: if your instruments have enough commonality, you can combine both of these techniques so that with a simple *IDN? query at initialise object and can filter out the functions that aren't supported by your hardware. Depending on the hardware, writing a comprehensive driver can be difficult, so if you're not confident, I'd contact a http://www.viengineering.com/' target="_blank">system integrator.

It would be good to add some sort of a 'full disclosure' statement since you may be slightly biased towards your suggested system integrator.

[Tomi Maila]

QUOTE(mesmith @ May 14 2007, 05:52 PM)

As I found out, the Source Distribution build option in the Project Explorer does not work properly and that cascades down into being unable to use the project explorer's installer dialogs to build an installer.

I'm using OpenG Package Builder to build source installation packages from LabVIEW OOP projects and VI Package Manager to install these packages. This solution works fine and works on all LabVIEW supported platforms. Any third party installer buidler should work fine as well. For example http://nsis.sourceforge.net/Main_Page' target="_blank">Nullsoft install system would propably do the job.

Tomi

[crelf]

QUOTE(dsaunders @ May 15 2007, 01:37 AM)

It would be good to add some sort of a 'full disclosure' statement since you may be slightly biased...

What do you mean? I just picked a random integrator

You're absolutely right: Disclaimer: I am an employee of the most-excellent http://www.viengineering.com/' target="_blank">V I Engineering, Inc., a fabulous National Instruments Select Alliance Partner, chocked full of Certified LabVIEW and TestStand Developers and Architects...

[LAVA 1.0 Content]

QUOTE(mesmith @ May 14 2007, 10:52 AM)

I agree with Tomi that in principle, OO code is the way to go.

I don't disagree that OOP is useful, but I don't see it as "the way to go" in this case.

My argument is that a driver developed for distribution to users needs to be:

1. multi-revision compatible (7.x, 8.x)
   
2. functional with different LabVIEW levels(base, full, prof)
   
3. modification friendly to the end user
   

There are still lots of 7.x users out there (even a few 6.x) An base OOP driver would put the instrument(s) at a competitive disadvantage

Not all users have full or pro licenses, so a LVOOP driver could limit use ( and limit to 8.2x )

making a modification to a driver based on classes would be above the skill level of > 75% of LabVIEW users at this point.

When developing something like this, identifying the least common denominator is as important as selecting the sharpest tool in the shed.

Just my :2cents: ...

[crelf]

QUOTE(mesmith @ May 15 2007, 12:52 AM)

I agree with Tomi that in principle, OO code is the way to go. However, there's at least one shortcoming of the current implementation of LVOOP that you should be aware of.

QUOTE(LV Punk @ May 15 2007, 02:21 AM)

I don't disagree that OOP is useful, but I don't see it as "the way to go" in this case. My argument is that a driver developed for distribution to users needs to be...

I'd still go the OO route, but, for the reasons you guys have pointed out, I wouldn't use LVOOP: I'd use dqGOOP or OpenGOOP instead.

[Yair]

QUOTE(crelf @ May 14 2007, 07:39 PM)

I'd still go the OO route, but, for the reasons you guys have pointed out, I wouldn't use LVOOP: I'd use dqGOOP or OpenGOOP instead.

Or Sciware GOOP or Endevo\NI GOOP for the inheritance they provide.

Dataact also had a version which was supposed to include inheritance (I think it was called FOOP), but I don't know if that's still around. It may have just been an experiment.

[balendran bala]

Thank you guys!

Balendran

[crelf]

QUOTE(balendran bala @ May 15 2007, 06:40 AM)

Thank you guys!

No worries - anytime!