Jump to content

Instrument Driver for a product family!


Recommended Posts

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

Link to comment

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

Link to comment

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

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 :o . 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.

Link to comment

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

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.

Link to comment

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.

Link to comment

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: ...

Link to comment

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

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.

Link to comment

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

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.