Automing instruments in LabVIEW without using specific drivers and coding for each instrument?

[ibzrehmani]

Hello,

I am new to programming in labVIEW, but I had a couple of questions about its use in automating and remote controlling multiple instruments.

Is it an ideal software for remote controlling/test automation of various instruments. Supposing I have multiple spectrum analyzers from various companies I understand that labVIEW has instrument drivers or special VI's that would control these instruments. But if I wanted all these spectrum analyzers to say, display to a different computer using remote control, but I wanted to use the same program for effeciency, is there a way of doing that universally for all instruments using labVIEW? Or do I have to tailor that program for each instrument cause of the instrument drivers?

If labVIEW cannot do that, has anyone had good success for these kinds of scenarios in other programming languages?

Thanks in advance for your help.

[RTSLVU]

Well the more "universal" you try to make a program to work on multiple instruments the more complex it becomes. 

I once created a program for our test stations that all contain various manufacturers AC and DC sources, AC and DC loads, and five different models of power analyzers.

So my program had to contain the VI's (drivers) for every possible instrument that could be in a test rack, and be easily comfigured to select the proper code for the proper instruments. 

I used an XML file to store the test rack configuration and the program would read this and use that to select the proper code to use when running.

Here is a sample VI that I made for setting the voltage on any one of three different DC power sources that could be in the test racks.

You will need to save the snippet to see all the code, but there is a case for each type of dc power source that hold the proper VI.

[Bob_Schor · Accepted solution]

Look up Hardware Abstraction Layer (which you can implement with LabVIEW, though it is a slightly advanced topic).

The notion of having a specific Test and being able to run it against different Instruments, decided at Run Time, is the kind of situation that LabVIEW and the use of HALs was designed to facilitate.

The concept involves "Levels of Abstraction".  When you design a test, you can design it for an Abstract Framistan, since all Framistans are supposed to be able to measure Vorbels in the range of 0-100, so you just need to hook up a Vorbel generator, make it generate Vorbels according to some Test Sequence (linearly, randomly, quickly, slowly, pulsatile, continuous, you decide), measure the readings your Abstract Framistan records, and compare it with the Results you Expect, writing up the Results in a nice Report.

Of course, NI's Framistat uses Ethernet as the communication medium, while HP's uses a Serial port (depending on the model, the serial parameters may change) and Intel's uses a .DLL to communicate with its low-level API.  So you also need to develop, for each specific instrument, an "interface" between its API and the Abstract Framistan (not everyone uses Vorbels as the input unit, for example).

So the Good News is that it is Do-able, the Bad News is that one of the better ways of handling this type of programming question is to use Object Oriented Programming (OOP).  A number of languages (LabVIEW, C++, JAVA) support OOP, but LabVIEW might have the edge when it comes to interacting with Hardware.

Did I tell you look up Hardware Abstraction Layer?  Add LabVIEW to the Search Query and you should find some very nice presentations by Elijah Kerry ...

Bob Schor

[Ben]

Using LVOOP and dynamic dispatching and utilizing the Factory Pattern will do it provided all of the spectrum analyzer had the same capablities.

Somewhere on this site there was a discussion about HAL (hardrware abstraction Layer) that could give you some ideas.

Ben

[RTSLVU]

Also isin't this what IVI (Interchangeable Virtual Instruments) http://www.ivifoundation.org/ was supposed to solve?

Not that I have been impressed by any IVI implementations I have seen...

[crossrulz]

As others have stated, you need a Hardware Abstraction Layer (HAL) which is best implemented with Object Oriented Programming (OOP).  If you do not know OOP, I suggest you first learn that.  Then you need to plan your HAL very carefully (what methods do you need?  what inputs do they need?  what outputs will be given?  how granular do you want the public methods?).  Making a HAL is not exactly hard.  Making a HAL that lasts is a completely different story.

[rolfk]

---

@RTSLVU wrote:

Also isin't this what IVI (Interchangeable Virtual Instruments) http://www.ivifoundation.org/ was supposed to solve?

Not that I have been impressed by any IVI implementations I have seen...

---

Yes sort of! The problem with this are however manyfold and most of them are not even NI's fault. Basically writing a good IVI driver is quite a lot of work, but writing a proper class definition that supports all possible features of any possible kind of instrument that fits into that class, absolutely impossible! That makes the idea nice in theory but breaks it as soon as you get into more advanced features of instruments.

Then there is the problem that most instrument manufacturers are in the business of manufacturing instruments, not writing software architectures, so the drivers they write, if they even bother, are in many cases more an example program than a real driver.

Personally I find the idea of HAL very cool, but think that it is basically impossible to write a good HAL architecture that will suit everyone and still be possible tot develop with acceptable effort and no advanced computer programming degree.

If you have a limited use case, it can be done with reasonable effort, but starting to define a architecture that is meant to work for everyone in the industry, is doomed.