|
|
Architecture
RTXI is designed to run experiments that require high-frequency periodic execution. At the heart of this design is the real-time (RT) thread (See Figure below). The RT thread is essentially a standard Linux thread, with two important caveats: (i) it runs with the highest priority afforded by the real-time enabled kernel and (ii) it executes periodically and then sleeps for a designated (short) period of time.
In addition to the RT thread, RTXI runs a user-interface (UI) non-real-time thread. The UI thread is also a standard Linux thread and runs in the same process address space as the RT thread. The UI thread is responsible for handling user input in the form of command-line arguments and graphical user-interface (GUI) events. Because the UI and RT threads share an address space, they can interact with each other through data structures that are stored in that shared address space. It is through the manipulation of these data structures that the UI thread is able to act as a mediator between the user interacting with the GUI and the RT thread, which repeatedly wakes up and executes the user-selected plugins loaded into RTXI. Plugins are function-specific code modules that can be used in combinations to build custom experiment protocols and interfaces, thereby eliminating the need to code all aspects of each experiment protocol from scratch. Often, users will have multiple plugins working in parallel during a single RTXI session. Typically, those plugins will need to share data and information. RTXI provides an event delivery system that allows plugins to signal the occurrence of user-defined events (such as detected neuronal spikes) and then send data to other plugins that are listening for such an event.
Simplified RTXI system architecture with "two thread" process structure. At the beginning of each timestep, the RT thread wakes and then signals each active DAQ driver to acquire all active inputs from the Experiment Hardware (such as a patch-clamp amplifier or an optical-mapping camera). Note that although it is shown as one component, the Experiment Hardware could be multiple components. The input data is then made available to other system components from the DAQ driver. The RT thread then executes the RT section of all of the plugins currently loaded in the system. Typically, during the RT sections of the various plugins, the input data from the DAQ driver will be accessed, and in the case of some plugins, data will be passed to the DAQ driver to output to the Experiment Hardware at a precise later time (with the time and the data determined as a function of the processed inputs). When all of the plugins are finished executing their RT components, the RT thread then signals the DAQ driver to write any output signals that it may have received from the various plugins. The RT thread then checks for and handles any relevant events. It then goes to sleep until the next timestep. While all of those processes are happening in the RT thread, the GUI thread is managing the graphic components of the system. Each plugin will typically have a sub-window embedded in the main window through which users can control the plugin and its various parameters. In the case of the Oscilloscope and Data Recorder plugins, specifically, users can select which channels are displayed and recorded using the GUI. Users can also control the execution of the RT thread from the GUI via the System Control by sending events to the RT thread.
Plugins
Plugins are
function-specific code modules that offer modularity to end-users. Often
used features need not be coded from scratch every time they are needed in
an application. This approach speeds the application-specific design
process and expands the utility of RTXI. We, along with end users, have
developed a library of both general-purpose and application-specific
experiment-control plugins. Users are able to choose from these plugins
options, customize them to meet their particular experiment demands, or
write their own plugins. The screenshots on the home page show
feature-rich RTXI experiment designs containing multiple plugins. The
plugins currently released as part of RTXI include:
- Oscilloscope plugin. This plugin is analogous to a hardware oscilloscope. It allows for the display of any
RTXI signal, including DAQ inputs/outputs or computed RTXI variables (which could include functions of
the DAQ inputs/outputs or any other variables used by the RTXI processes).
- Data Recorder plugin. This plugin allows the user to select a set of RTXI signals (as described for the
Oscilloscope), and have the timestep by timestep values of those signals recorded to user-specifïed files.
- Cardiac Electrophysiological Cellular Control plugin. This plugin is used for monitoring and controlling the
electrophysiological behavior of cardiac cells.
- A-M Systems Amplifier Controller plugin. This plugin controls the operational state of an A-M Systems
brand microelectrode amplifier, enabling on-the-fly software switching between modes (e.g., instantaneous
switching from voltage clamping to current clamping). This plugin helps free end-users from having to
purchase expensive software to run the less flexible standard microelectrode amplifier systems.
- Multi-Channel Mapping and Cardiac Tissue Control plugin. This plugin is used for monitoring multiple electrophysiological
recordings (e.g., glass microelectrode signals) and has the ability to monitor and control
action-potential duration rhythms by closed-loop alteration of the stimulus interval.
- Resistance Measurement plugin. This plugin is for measuring the seal resistance of a patch-clamped cell.
- Wavemaker plugin. This plugin allows users to output, through an analog output channel, a voltage time
series that has been stored in an ASCII file. This is particularly useful for "playing back" data that has been
recorded previously. One might want to do this when developing real-time analysis algorithms (e.g., cardiac
action-potential duration detection) and testing such algorithms in real-time. This plugin enables testing of
such development "offline"; i.e., without a biological preparation.
- Scheme Scripting Interface plugin. This plugin provides the ability to develop simple RTXI UI code (but not
GUI development) in the Scheme language. This plugin allows users to create a basic UI without having to
deal with the complexity of C++ programming.
- Python Scripting Interface plugin. Like the Scheme Scripting Interface plugin, this plugin provides the ability
to develop simple RTXI UI code (but not GUI development) in the Python language.
- Performance Monitor plugin. A benchmarking plugin is available for users
to quantify timing characteristics of their system and real-time applications.
- Camera activation plugin. This simple control plugin controls an imaging light source and triggers a Red-
Shirt optical mapping camera to start (or terminate) acquisition. Note that this is not the same as real-time
acquisition of optical mapping data.
- Hodgkin-Huxley model neuron plugin. A model of a standard Hodgkin and Huxley model neuron.
- Channel and Synapse plugins. Several model-specific plugins of channels and synapses are available.
One is "ElecSyn", which allows users to create an electrical synapse between any two cells with a runtime
adjustable conductance. Another is "Post-Synaptic Conductance" plugin, which has parameters for
controlling the time constant, sign, and magnitude of a post-synaptic conductance. Another is "g_h", which
is an H-current model.
- Istep plugin. A plugin that enables flexible current-clamp stepping protocols.
- PRC plugin. A plugin for conducting simple Phase Response Curve experiments. This plugin randomly
perturbs the cells and quantifies the amount of advance or delay the perturbation has on the next firing
time of the cell.
- SpikeDetect. A simple plugin that handles the detection of action potentials from a cell.
- SpikeRateController. A plugin that applies DC current to a cell to make it fire at a specified rate.
- Model synchronization plugin. A plugin that allows users to pause/unpause multiple running models at the
same time, to synchronize their execution.
|
|