Alternatives for Instruments Drivers

[Faizan_habib]

Hi,

I want to communicate with instruments like Oscilloscope, DC Load and Power supply. There are instruments drivers available for specific instruments, but I want to share the My GUI with other teams and they might not have the same instruments. What could be the possible solutions or alternatives so that I dont have to use specific driver  to configure the respective instrument so that  My GUI should be usable with any OSC, DC Load and PS.

Note: The goal here is to develop a Automated Test Bench using LabVIEW.

Thanks & Regards,
Faizan

[RTSLVU]

---

@Faizan_habib wrote:

My GUI should be usable with any OSC, DC Load and PS.

---

Hmmm... Dream the impossible dream comes to mind here.

There have been several attempts to standardize instrument programming.

IEEE488.2, SCPI and the IVI framework comes to mind.

But the main problem is what if brand-X instrument has and option brand-Y instrument does not?

Not to mention that no manufacturer is required to support any of these standards.

My solution for a "universal test program" is to put all the "drivers" in the program and use a configuration file that tell the LabView program what instruments are present so it can use the proper driver.

[santo_13]

---

@Faizan_habib wrote:

Hi,

I want to communicate with instruments like Oscilloscope, DC Load and Power supply. There are instruments drivers available for specific instruments, but I want to share the My GUI with other teams and they might not have the same instruments. What could be the possible solutions or alternatives so that I dont have to use specific driver  to configure the respective instrument so that  My GUI should be usable with any OSC, DC Load and PS.

Note: The goal here is to develop a Automated Test Bench using LabVIEW.

Thanks & Regards,
Faizan

---

You need to create a plugin architecture that allows you to add support for new instrument models and types, adding abstraction layer helps you to write test automation agnostic of instrument model. Be aware this is an extensive and expensive work to create a sophisticated abstraction layer with support for wide variety of models.

Read this whitepaper - https://www.ni.com/en/forms/hardware-measurement-abstraction-layers.html I like it as it also covers the effort and cost associated with developing an abstraction.

[rolfk]

It's generally called HAL (Hardware Abstraction Layer) and there have been umpteen projects trying to do that in many different languages, including LabVIEW. The idea is great, and the execution seems to feel sound in the beginning until you start to do real work. Then you run into the problems. Scope 1 has 2 channels, Scope 2 however 4. Scope 3 has also 4 channels but the first two channels support 10 modes while the last two only can be used in 2 modes. Scope 4 has a special super hyper duper channel in addition to 2 standard channels, and Scope 5 only supports frequency domain measurements. And so on. Then you go to power supplies where you have simple power supplies, source measurement supplies, 2 and 4 quadrant capable supplies and what not else. And multimeters, frequency generators, network analyzers, vector analyzers, etc.

And before you know it your HAL is either one huge mess of options, additions, extensions, workarounds and exceptions or a limited model that supports exactly your initial two models and anything else is tough luck!

It basically comes down to one huge question: Are you willing to spend the rest of your life trying to support an impossible model or are you rather wanting to do practical work and get various systems built that actually do some real work?

As Santhosh mentioned, a plugin architecture can get you a useful approach to implement a limited functional model. But a plugin architecture is itself quite an engineering work already and should not be taken easily. It can be done and can work reliable but expect to spend quite a few hours on that alone before you can even start to go on the implementation of your actual plugins themself. And your users do not magically gain the ability to use their own devices. They all have to develop a plugin for their device for your, more or less advanced, plugin interface architecture. Usually they will rather select to develop their own application for their device than go and learn a rather complex plugin architecture to write their own plugin for.

[Yamaeda]

HAL has already been mentioned, and as Inferfaces is now a thing (since 2020) something like this:

Create Interfaces for your Instrument types and add some methods. e.g. Read Current (which could exist on a DAQ or a PSU)

Create instrument classes and implement relevant methods e.g. Read Current 

Code your system with the Interface functions 

Add ini-files to configure your systems and support different instrument setups

Cry as the real world hits you. 🙂

[santo_13]

---

@Yamaeda wrote:

Cry as the real world hits you. 🙂

---

This will happen slowly as the reality in HAL development hits you (it may not if you can carefully contain the scope of functionality of your HAL) but if you try make a swiss army knife, then, this is inevitable.

[Faizan_habib]

Thanks for the suggestion. Now, I am planning to just add 4 to 5  instrument drivers in my code, and giving user an option to select the instrument brand he wants to use. Do you think I should use OOP for it as well? also plan here is that if later we want to add the new driver we don't have to go through every case and make a change. 

[santo_13]

---

@Faizan_habib wrote:

Thanks for the suggestion. Now, I am planning to just add 4 to 5  instrument drivers in my code, and giving user an option to select the instrument brand he wants to use. Do you think I should use OOP for it as well? also plan here is that if later we want to add the new driver we don't have to go through every case and make a change. 

---

OOP with Plugin architecture and factory pattern helps you with ability to add more instrument model support without having to modify the application code.

[Faizan_habib]

I do not understand the plugin architecture? can you please refer me to some documentation which can help? or any example. 

Thanks

[aeastet]

We use OOP to do this for what we have done. We have modules that help pull things together. We have a device layer OOP class. This allows us to chose how the device is communicating. That plays into a bigger communication loop. I can tell the system what we are talking to (i.e. Power Supply, DMM, etc.. and what communication protocol (TCP, USB, Serial, etc...) it uses to talk. From here we have two vi's the we override that allow us to add any new devices. Today we support many different devices. It only takes a few hours to add a new system. Less if it actually uses a standard such as SCPI. 

You will have the trade offs that the others mentioned. We have a standard interface for the devices that we use. You lose some options on some devices and have options that are not available for others. It really just depends on what you need to accomplish.