Universal Labview program: how do you create a program that adapts to different devices?

[MAILFERTSeb]

Hello,
I create a lot of software to control different experimental manips in the lab.
I'd like to create a universal program so that users always have the same interface (more or less).
The problem is that I have to adapt:
- to peripherals that may have different communication protocols (serial, .dll call, .net, ActiveX) for the same kind of peripheral
- peripherals that aren't necessarily all connected
- to varying numbers of peripherals.

How do you deal with this kind of thing?
I know quite a few commercial or open-source software programs (micro-manager, for example) that adapt to the peripherals connected and allow the user to configure according to what he has on his hand.

This means that the software must have a certain database of peripherals and must have a fairly generalist architecture so that it's as general as possible.

In short, I'm curious to hear your feedback, your examples and your advice.
Thank you,
Sébastien

Translated with www.DeepL.com/Translator (free version)

[Yamaeda]

That's what Classes and Interfaces are for!

Classes for things that are similar in functionality where you want to reuse code.

Interfaces to bridge the differences between classes so that the main UI only implements 1 solution.

[Henrik_Volkers]

many years ago (~20a) I did something like that using vi-server and functional globals,  more modern architecture is possible today (see previous post).

concept: each type of device has the same style of vi, call it source.vi , providing the the generic interface for the main vi and

a set of functions to call

-provide basic info main

-get the resources (interface(VISA,TCP,dll,...  ) ,check and get  device (ID,)

-configuration, done by a individual config vi and/or get variant or so ,  (include how to share the data, my tip: since a global synchronisation is often not possible , a timestamped datafile for every source is created storing maybe additional available data, additional to a channel to send the data to the main application for 'realtime' display, but depends on your tasks) 

-start

-stop

free device (and resource)

(some basics .. add what you need)

now you have a bunch of source.vis (some with more than one instance) running in parallel...providing timestamped(!) data to main vi,

you can share some global signaling for coarse synchronisation, but I assume the same situation I had, that a lot of them are free running, if you request a value some will always start a new measurement with a certain delay , some only send the last recent, others continiously send data (like a lot of scales) with a complete different timing...;) )

I had a subdirectory where my sources.vis where located.  whenever I created a new one, it was stored there and the main vi could use it.

I thougth I could write a general GPIB and general serial-COM vi (got quite close to it, but ) ... , but in most cases a copy-paste-modify for new devices was faster.  And with the instrument driver network nowadays 🙂

For the lab use an automatic store and reload of the last actual(!) configuration was one of the most important features 😄

[ShockHouse]

What you are looking to build, or use is called a HAL (Hardware Abstraction Layer). The company I work for offers one and you can watch a video on HAL on our website if you want an idea of what those are.

https://www.testeract.com/hal-info

As other posters have mentioned, you basically define a common interface (device type, ex: DCPowerSupply), and use classes and inheritance to implement functionality for the different models of the device type you have (ex: Keysight N6700 Power Supply). This can allow you to create common code (or GUIs) for controlling a DCPowerSupply, that can actually control 100's of different types of Power Supplies.

[RTSLVU]

Here's what I have done. In my case I have several test systems. All have AC and DC power sources, AD and DC loads, Power analyzers, and a DAQ/Switch unit. I use an XML file for each system that is parsed on start up. My program contains all of the VI's for each instrument and the proper VI is selected by the instrument type in the XML file.

Although we have attempted to standardize our test equipment. There are still several differences present across the test systems.

Despite these differences, the validation platform software can run on any the test system located in the lab without making any modifications to the test script or LabVIEW program. 

 The Validation Platform software currently supports this test equipment:

1. AC power sources
   1. California Instruments Ci5001iX 
   2. California Instruments CSW5550
   3. Elgar SW5250 (Deprecated)
2. DC power sources 
   1. Sorensen DHP series
   2. Sorensen DLP series
   3. Sorensen XGI series
   4. Agilent N87xx series
   5. Keysight N89xx series
3. AC Loads
   1. California Instruments 3091LD
   2. NHR 3200
4. DC Loads
   1. TDI Dynaload RBL series
   2. NHR 4700 series
5. Yokogawa power analyzers
   1. WT-1800
   2. WT-1600
   3. WT-500
   4. WT-230 
   5. WT-130 (Deprecated)
6. HP/Agilent/Keysight DAQ/Switch unit
   1. 3497xA Series
   2. DAQ97x Series
7. Test system high current DC switching relays controlled by 3497xA/DAQ97x using:
   1. Multifunction card DIO (Deprecated)
   2. Actuator card

[NIquist]

As ShockHouse mentioned, this is HAL.  If you search for "LabVIEW HAL" you will find pages of forum links, tutorials and videos from NI, Delacor and many others putting their 2 cents in.

Be aware, it pretty much requires LVOOP expertise and potentially Actor Framework experience to do this right.  I believe there are also toolkits available that can help, so you might look into those if you lack experience.

Good video from Bloomy Controls:  NIWeek 2019/Who Are You Developing Your HAL/MAL For? You Or The Test Engineer - LabVIEW Wiki

[Kyle97330]

We did one of these where I work.  I don't have time to go into all the details, but I have some general advice.

• Make sure that in addition to handling real devices, the system you create can handle simulated ones.  If you do it right, you can test your software on a system with no hardware connected at all.
• You might be tempted to start with the equipment that you use the most.  Instead, consider starting with equipment that is the simplest regardless of how much you use it.  Whatever system you come up with will likely have problems you discover over time, and whatever you make first will have the most amount of things you have to redo when you fix your system, so the simpler the better.
• Look at the IVI foundation and all the hardware they have interchangeable drivers for.  Those drivers are the result of several large companies spending a lot of time and effort creating common interfaces for 13 different instrument types, and if you will be using any of those you should try to tap into what they've already done.

[Taggart]

---

@MAILFERTSeb wrote:

Hello,
I create a lot of software to control different experimental manips in the lab.
I'd like to create a universal program so that users always have the same interface (more or less).
The problem is that I have to adapt:
- to peripherals that may have different communication protocols (serial, .dll call, .net, ActiveX) for the same kind of peripheral
- peripherals that aren't necessarily all connected
- to varying numbers of peripherals.

How do you deal with this kind of thing?
I know quite a few commercial or open-source software programs (micro-manager, for example) that adapt to the peripherals connected and allow the user to configure according to what he has on his hand.

This means that the software must have a certain database of peripherals and must have a fairly generalist architecture so that it's as general as possible.

In short, I'm curious to hear your feedback, your examples and your advice.
Thank you,
Sébastien

Translated with www.DeepL.com/Translator (free version)

---

Unless all your potential experimental setups are incredibly similar - don't do this. 

It's not as useful as you think, will take way too long to develop, and will overcomplicate the software for each of your experiments and each experiment will have something, some component, some aspect that breaks one of the assumptions of your glorious do-it-all HAL. It's inevitable.

Just create what you need for each setup. Use a mini-HAL within each project to allow swapping out similar instruments and that's all you should need.

Simple software is easier to change and maintain. Keep it simple.

[MAILFERTSeb]

Hi Sam,

that's exactly where I'm at.

Creating a complex architecture that will probably never exactly fit all my new configurations or creating software for each independent configuration.

I'd say I'll try looking at HAL, just out of curiosity and for my personal knowledge and see if it's the best way to work.

Thank you very much for your reply.

Sébastien

[MAILFERTSeb]

Thanks, I'll take a look at HAL!