Software architecture for modular measurement system in a battery and electronics testing laboratory

[Istvan K]

Greetings, 

To set the scene, our University wants to build a laboratory where we can test batteries and electronic devices with our equipment. Just to list a few of them we have: 
- Climate chamber
- cRIO-9039 for data acquisition and safety control
- Electronic load
- Multiple power supplies
- Multimeters
- Oscilloscope
- LCR meter
- EIS measurement instrument
and so on.... 

All of these devices can be interfaced through LabVIEW, and I am certain that this list will increase in the future. 
The main concept:
- We have a sotfware, where we can create the test sequence, step by step (i.e.: Configure powersupply, delay(ms), enable ps. output, delay(ms), disable output ). The output would be a recipe file, which include each step, and its parameters.
- The main software, where you can import the test sequence, and execute it. The sequences can include multiple measurement instruments. The data logging is continuous.  If there is an emergency, the measurement is aborted. 
   The imported sequence file would be executed step by step in a case structure (or if there is any other possibility). 


My question is: What kinf of architecture would be suitable for the main software? I have already developed larger applications using QMH, but I have experienced its limitations. Im also looking at OOP concpets, but I have no experience with i so far. 
I know that TestStand is similar to our needs, but currently we dont have a budget to purchase it.

Thank you for your help

[Gribo]

First, I'm in the same boat as you are, and here are few of my insights:
You are trying to create a test sequencer - There are off the shelf products that do that (Teststand is NI's solution - $$$). For architecture, anything from the basic QMH to a full blown actor framework with asynchronous actors can be used - in my case, I have used QMH with few extra threads for safety, logging and report generation.

OOP is a way for the designers to think about software modules and abstraction. Do you need such things? Are you planning on supporting multiple models of PSU, loads and other test instruments? If so, OOP provides a convenient way to create those abstraction layers. If you decide on using classes, you should avoid using PPL, they break each other in weird and wonderful ways.

For data logging, I suggest both a central parametric database and local Excel or Calc reports. 

Test templates and deployment: You should consider creating a standardized test template project, along with build specifications, so your operators will use an executable and not the full LV IDE.