Embedded Files
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.
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 if you want to join the community. If you have questions about the program see 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
Creator
Last Updates: April 2011
Users of the program
Users of the program
Dilson Rassier, McGill University (Kinesiology and Physical Education, ), Montreal, Canada
David Juncker, McGill University (Biomedical Engineering), Montreal, Canada
Sensorica - an open enterprise, Global
Philippe Comtois, Montreal Heart Institute
Brian Anderson, University of Arizona
Publications about this platform
Publications about this platform
Integrated microfluidic probe station Rev. Sci. Instrum. 81, 115107 (2010).
The program also drives the system published in :
The program also drives the system published in :
Optical detection system for probing cantilever deflections parallel to a sample surface; Rev. Sci. Instrum. 82, 013701 (2011)
General approach
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
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
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.
The LabVIEW code behind the Principal Program
The LabVIEW code behind the Principal Program
The code behind the Principal Program is very transparent, and well documented.
Instrument Driver
Instrument Driver
Script Writer
Script Writer
Instruments drivers available
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.
Motion devices
Warner SF -77B Perfusion Fast Step (stepper motor)
Arcus Lin Stage with ACE SDE, USB controller
Piezo micromanipulator
Driver from Dilson, driven by NI DAQ or a NI FPGA
Fluid control
MFCS Pressure Controller
Warner VC-6 Valve Controller
Image
Nikon Microscope Controls
Data acquisition and control
Integrated systems
Penguin (an AFM-like displacement/force measurement device), also connected to a Multipurpose PCI NI DAQ - 6289 for data acquisition and some control operations
Mosquito (an optical fiber-based displacement/force transducer) from SENSORICA, based on LabJack, based on NI USB-6221 DAQ.
Serial communication
Integrate a new instrument into the system
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
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.
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.
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
Other modules
Signal Characterization
Signal Characterization
Acquires waveform data from 1 analog channel and performs FFT on it. It also has averaging capability.
Signal conditioning
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
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
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
Documentation
Specific documents
Calibration procedure of CCD camera (a QImaging)
[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
Page updated
Google Sites
Report abuse