How to create an IVI-style driver in native LabVIEW

[AndyBaxter]

Hi All,

We are looking to implement an ATE which will need to use instrument types not directly covered by any of the existing IVI instrument classes but for which we already have native LabVIEW drivers.

There will be 2 test systems, each using instrument of this new class but each using a unit from a different vendor.  The two Bit Error Rate testers (from Agilent and Anritsu) have markedly different architectures and so whilst the drivers for each will functionally be able to perform the same tasks (ie measure BER) the driver structure (order of commands, relevant setup and pre-test configs etc) will differ significantly.

Given that the same test software will run on both systems I ideally need to minimise the code differences between the two so as to minimise any future modification overhead. 

Other than writing a higher level 'shell' for each of the driver functions that then calls whichever of the two drivers is needed (based perhaps on some input selecting either system A or system B or a *IDN? response) is there a better way to get the same functionality that IVI provides but in native LabVIEW?  I certainly want to be able to encapsulate the hardware choice such that the test software remains consistent across the differing hardware platforms.

We're running LV 8.5 but have limited access at this point to any non-LabVIEW coding resources hence the native LV requirement.

Any guidance / suggestions appreciated

Andy

[O_Proulx]

Good Morning Andy,

The first thing I would do is look on idnet to see if there is already a driver for your particular instrument model.  You can also look at this document for more detailed help on finding and installing instrument drivers.

Since these two instruments seem to have totally different command sets, you will need to have seperate code for each.  Therefore, I think your "higher level shell" idea is probably the best way to create your project.

In any case, I think this may be a point to start.  Let me know if you need more help.  Have a great day.

[NathanT]

Hello Andy,
          What you are looking for is known as a Hardware Abstraction Layer (HAL).  I recommend that you and your team sit down and decide which instrument functions your Top-Level ATE application will need.  This will be your Class Application Program Interface (API).  It is very important for the whole team to work on the Class API and agree on it.  We generally use a spreadsheet to prototype APIs for LabVIEW Plug and Play Instrument Drivers.  Since you are using LabVIEW, I recommend that you base your API on the General Instrument Driver Template that ships with LabVIEW and is available through the Instrument Driver Project Wizard.
          It is important to identify any feature/performance differences between the different instruments in the same class and decide how you will handle them (and how your driver will handle them) and any new instruments in the future.

          As far as actually developing the Class driver to call the instrument driver, the idea of using the ID Query to ID the instrument is not a bad idea.  I recommend taking it a step further and using VISA User Data through a VISA property node to pass the instrument model throughout the application.

This sounds like a cool project.

Let us know how it goes,

NathanT