LabVIEW
Alternatives for Instruments Drivers
@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.
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.
