Home‎ > ‎Projects‎ > ‎

IA Labview platform for research environment

Generic and modular automation software (LabView 8.5) that integrates imaging, motion, dosing, and data acquisition devices. This program was also extended for data characterization, data conditioning, and analysis. 


Creative Commons License
The "IA Labview platform for research environment", first proposed by Tiberius Brastaviceanu, is licensed under a Creative Commons Attribution 3.0 Unported License. Based on a work at IAC.


Contact us to get the program and/or to collaborate 
If you have questions about the program see to Q&A forum
For general questions about the community use the general forum
You can find more info about the platform in our shared database


News !


Extension to support NI FPGA for fast feedback systems



Creator: Tiberius Brastaviceanu
Contributors:  ...
Last Updates: April 2011

Actual users of the program
Dilson Rassier, McGill University (Kinesiology and Physical Education, ), Montreal, Canada
David Juncker, McGill University (Biomedical Engineering), Montreal, Canada
Philippe Comtois, Montreal Heart Institute
Brian Anderson, University of Arizona

Publications about this platform
Integrated microfluidic probe station Rev. Sci. Instrum. 81, 115107 (2010). 

The program also drives the system published in :



General approach

This document presents the General Application[1], which is a generic software (LabVIEW 8.5) that integrates different types of scientific instruments into different applications, and automates experiments.

The principal requirements that guided the design and implementation were:

  • A modular architecture
  • Easily reconfigurable: the user can define/configure different applications using a different set of instruments without the need of programming in LabVIEW
  • Easily expandable: new instruments and data processing/analysis modules can be integrated into the system with minimal LabVIEW programming efforts
  • Easily maintainable: transparent architecture and easy to understand code

In terms of functionality, the General Applications must give the user the possibility to:

  • Interact manually with different instruments within a user-friendly environment
  • Perform script-based automated experiments
  • Save data with information about instrument settings and user specified experimental conditions
  • Plan experiments by displaying and processing/analyzing previously acquired data.
  • Provide remote access to- and control of the experimental setup.
Learning to use the program:
  • Learning features were embedded in the program in order to improve the user learning curve. The concept implemented here is learn-as-you-use-it. At every step, the user is presented with contextual information and with possible further actions. Additional contextual information is reachable through a contextual help window (Control-H in Windows) on a need-to-know bases. Both features can be easily expanded and customized. This reduces the need to read long and boring user manuals.

General Architecture

The General Application was built on a highly modular architecture. The goal was to create a generic structure that can handle multiple applications, easily customizable, easily extensible, easily maintainable, suitable for a dynamic research environment. For every physical instrument there is a corresponding
Instrument Driver, which is a program/driver that can handle all necessary functions of the physical instrument it represents. Instrument Drivers have the same architecture and are treated as “black boxes” with the same sets of outputs and inputs. The Application Configuration program, part of the General Application, helps the user to build an application instance. In short, an application instance is everything the user needs to perform an experiment, which includes all the Instrument Drivers that will be used to perform this experiment. Application instances can be saved for later use once they have been configured. Different users of the program can therefore work with their personalized Application. The Script Writer is another important part of the General Application, it helps the user to build a script for an automated application instance, or an automated experiment. The environment in which the user interacts with different instruments is called the Principal Program. Recently, the program was expanded to accept Data Characterization, Conditioning, and data Analysis modules. There are modules for waveform or 2D array of data, performing filtering, averaging, fitting, comparison, etc. Other modules process and analyze images and videos. 

Principal Program

The Principal Program is the work environment. It assists the user in building an application and to run this application. Running the application means interacting with different instruments that are part of it, or performing script-based automated experiments. The user can also call other modules for data processing/analysis. Therefore, this program plays two important roles: GUI (Graphical User Interface) and Master of the Application. The Principal Program is basically a UI/Master/Slave pattern. Behind the GUI we have a User Interface Event Handler pattern integrated with a Subpanel Viewer pattern. The Subpanel Viewer displays front panels of running Instrument Drivers on the Principal Program's front panel, and enables the user to interact with these Instrument Drivers. When used in the automated mode the execution is controlled by a script. The part of the program which handles this type of execution is basically a Master/Slave template provided by NI [2]. According to the rules defined by this pattern, the Principal Program is a Master, sending commands to Instrument Drivers to be executed at a given moment and in a given order. Timed loops are used in order to take advantage of parallel processing

The Producer/Consumer pattern would be more suitable for an instrument driven application. I built this program for user driven applications. The Principal Program plays an active role, rather than a passive role waiting for data to be processed whenever it becomes available from producers.  Moreover, a State Machine pattern would not be suitable fro user driven applications, for  two principal reasons. First, because some Instrument Drivers must be able to execute in parallel. Second, because for the sake of generality, the order of execution of different Instrument Drivers must retain maximum flexibility, must be user defined. I think this is sufficient to justify my choice of the Master/Slave pattern over other widely used patterns.
 

See documentation here


The LabVIEW code behind the Principal Program

The code behind the Principal Program is very transparent, and well documented. 



Instrument Driver

To integrate a new instrument into the system use the InstrumentDriverTemplate.vi to build the corresponding Instrument Driver. You only need to drop the new Instrument Driver into the Instrument Drivers folder[3] to use it, and, if the general structure was not altered, it should work properly within the system. An experiment showed that it only takes 3-5 hours to adapt a fairly complex LabVIEW driver to the General Application using our generic driver template.  

The Block diagram of the  InstrumentDriverTemplate.vi. is shown on the picture  on the right. Notice its modularity and appreciate how easy it is to read it.

See documentation here



Instruments drivers available

Many Instrument Drivers were created based on the InstrumentDriverTemplate, that are compatible with the General Application.The following is a list of physical devices that can interface with the program.


Integrate a new instrument into the system

A new instrument can be easily integrated into the system by going through a few steps, using the Instrument Driver Template. According to my experience, it should take one day of work to integrate a new instrument within the general application, by building a corresponding Instrument Drive. You need the low level LabVIEW functions though...    


Application Configuration


The role of the Application Configuration is to assist the user in building an application instance. In short an application instance is a list of all the instruments the user needs to perform an experiment. All Instrument Driver are placed in a common folder called Instrument Drivers [4]. Once the list of Instrument Drivers has been selected every instrument must be configured, which means to select the proper values for execution parameters. Execution parameters affect the priority of execution of a particular Instrument Driver as treated by the operating system, the speed of execution of main loops composing these programs and the CPU these programs will run on. Computational resources can thus be wisely allocated for a given application instance, giving more importance to time-critical components. 

The user can follow the message board for contextual instructions on how to use this program. For more information on every control and indicator the user can open the HELP window by selecting taping Control/H and by simply placing the mouse indicator on top of that specific control/indicator. 





Script Writer

The role of the Script Writer is to assist the user in building a script for an automated application instance. A script is essentially a list of commands that will be sent to different instruments, part of this application instance, in the order they appear. Instrument Drivers can execute in parallel, but they can only be addressed by the Principal Program sequentially. For example, we can send a command to a dosing device to dispense a given volume at a given flow rate, and while this task is executed the Principal Program can send other commands to a Motion device. 

Two versions of the Script Writer ware created. One of them supports 3D visualization of motion commands, and symmetry operations on a base motion script for easily building a large matrix of displacement patterns. The second one is a simplified version that can be used to build small scripts, making sure that the syntax is respected.




Other modules



Signal Characterization


Acquires waveform data from 1 analog channel and performs FFT on it. It also has averaging capability.



Signal conditioning


Get's waveform from a file and performs time averaging and filtering. It also performs FFT on the signal - lower graph. This module is integrated with the Principle program. Open manual, ask permission to edit. 



Signal Analysis


Get's waveform from file and applies all sorts of analysis tools. Can do statistics, Fitting, comparison, and you can crop the data. This module is integrated with the Principle program, and can receive data directly from the Signal Conditioning module. Open manual, ask permission to edit. 



Visualization


Matches in time a waveform with a movie of the experiment. This program allows you to relive an experiment. It takes data from files. You can adjust the synchronization between the video file and the acquired data from the 'delay' control (on top of the data graph).


Documentation


Specific documents


[1] I call General Application the entire body of VIs, integrated into a complete Labview program (Principal Program) which is used to perform an experiment.

[2] To see it open the Getting Started window from View/Getting Started Window, chose New/VI from Template, expand From Template, expand Frameworks/Design Patterns, and choose Master/Slave Design Pattern A copy of this VI can be also found in the Building Material – Templates folder, under the name of MasterSlavePattern.VI.

[3] Future developers shall not modify the name of this folder.

[4] Future developers shall not modify the name of this folder.


Contact us to get the program and/or to collaborate