CodaLite

codaLite Data Acquisition Package

--Wolin 15:11, 27 August 2008 (EDT)

codaLite is a lightweight and easy to install and use DAQ package suitable for everything but large-scale high-speed DAQ systems (CODA3 is being developed for the such systems). It has been in use for a number of years in numerous test stands at JLab and at universities. It is composed of mature CODA3 components, prototypes of CODA3 components still under development, and other software written specifically for codaLite.

codaLite includes much of the functionality of CODA3, but sacrifices scalability and robustness against component failure for simplicity and ease of use. Extensive use is made of the cMsg interprocess communication package (a CODA3 component), which allows for a complete decoupling of codaLite components so that they can be developed and tested in isolation. Note that in codaLite the cMsg system is used both for run control and event transfer, whereas in CODA3 the ET system, a very high-speed shared-memory based interprocess communication package, is used for event transfer.

codaLite optionally supports AFECS, the CODA3 run control package. AFECS provides a graphical run control interface, real-time histograms of event and data rates, but requires creation of configuration files for all DAQ configurations needed (not a big deal in most cases). If AFECS is not used, simple scripts are used to start and stop runs.

All codaLite components run on Linux and Solaris, and most components are supported on VxWorks. Libraries are available to read out common front-end DAQ modules such as the JLab F1 TDC, JLab FADC 250, CAEN V792 integrating ADC, and many others (contact Dave Abbott, abbottd@jlab.org, for details).

codaLite.tar.gz can be found on the CODA ftp site. Included in the distribution is a README file describing how to install and use codaLite.

codaLite Components

codaLite components are all normal programs compiled and linked in the usual manner. Some are user customizable. Important codaLite components are described below. See the README in the distribution to find the actual program names:

cMsg Interprocess Communication Server

This Java program brokers all communications, and should not be modified. Typically only one copy needs to be running. It can be started at boot time. The cMsg server is not supported on VxWorks.

Data Source

This C++ program collects event data and ships it off to an event builder process. It is designed to be customized by the user to collect data from the devices in his or her particular DAQ system. It supports a polling mode on Linux, and both a polling mode and a VME interrupt mode on VxWorks (I am working on a VME interrupt mode for Linux). DAQ systems must run one or more copies of this component.

Event Builder/Recorder

This C++ program receives all data from the Data Sources, combines the data into a single event, then writes the events to disk. Typically EVIO format is used (EVIO is a CODA3 component), but the program can be customized to use any format. Optionally this program can ship events to other processes for monitoring, and to other event builder processes in a hierarchical event building scheme. Typically one copy of this program needs to be running. Generally it does not need to be modified.

File Analyzer

This example C++ program reads event data from files written in EVIO format by the Event Builder/Recorder and delivers the data to a user-written analysis routine.

Online Event Analyzer

This example C++ program can receive full events from the Event Builder/Recorder, or partial events from an individual Data Source, and analyze them in real time. The analysis routines are supplied by the user. Combined with a graphics package, such as ROOT, the Online Event Analyzer can display analysis results in real time.

evio2xml

This utility dumps EVIO files to the screen in XML format.

cMsgLogger

This Java utility spies on cMsg communication streams and dumps message information to the screen. It is typically used for debugging.

cMsgMonitor

This utility takes a snapshot of the current configuration of the cMsg system and prints a summary to the screen. It is typically used for debugging.

codaLite Usage

A typical small-scale system needs just the cMsg communication server, one Data Source running on a VxWorks processor in a VME crate (or on Linux), and one Event Builder/Recorder. A TI module in the VME crate accepts triggers from the experimental hardware and delivers interrupts to the VME backplane. The Data Source software running in the VxWorks processor receives the interrupt, then dispatches to a user-written data readout method that collects data from modules in the VME crate, packages it into an event, and ships it to the Event Builder/Recorder. The latter receives the events and writes them to disk in EVIO format. Short scripts are used to start and stop runs. Use evio2xml to dump the EVIO files in ascii XML format. Customize the File Analyzer to analyze your data.

Multiple VME crates can be used with appropriate wiring and programming of the TI boards in the VME crates. Currently there is no support for PCI interrupts on Linux (contact me if you need to do this).

FAQ

Help, nothing works!

• Contact Elliott Wolin, 757-269-7635, wolin@jlab.org. Carl Timmer (timmer@jlab.org) is the major author of the cMsg package. Dave Abbott (abbottd@jlab.org) and Ed Jastrzembski (jastrzem@jlab.org) are knowledgeable about many aspects of VxWorks, VME, and DAQ boards.

But I don't use a VME single board computer

• No problem. Modify the Linux test program to read out your devices. If you use Linux PCI interrupts you are on your own, as I've never done that. But note that soon the JLab DAQ group will produce a PCI-based TI board to solve this problem (see next entry).

What is a TI board?

• In stand-alone mode the Trigger Interface (TI) board accepts up to four differential ECL trigger signals plus up to eight additional input bits, latches them all upon receipt of a trigger, then very quickly sends out a Level 1 accept signal for use by readout modules. The TI holds off accepting new triggers and sending out Level 1 accept until it receives a re-enable request over the VME bus. When the controller completes the readout it issues the re-enable request. The TI also has an eight-bit general purpose output register on the front panel.

How do I hook up a TI board?

• All input signals are differential ECL, so signal translators are needed to communicate with NIM logic or with the JLab FADC250 (which uses PECL). The bottom four bits of the INPUT connector accept triggers, the upper eight are latched when a trigger arrives on the lower four. The five-pair "BSY -L1A-" connector puts out different types of Level 1 accepts on the lower four pairs, and a busy signal on the uppermost pair. The lower two L1A pairs put out a level when a trigger is active, the two L1A pairs above them put out a 50 ns pulse. Usually it is best to use the pulsed outputs.

How do I read out my VME-based DAQ board?

• Contact Dave Abbott (abbottd@jlab.org) for VME readout libraries for commonly used DAQ boards.

How do I communicate with a VME-based single board computer over RS232?

• Use "minicom" configured with baud rate 9600, 8 bit, no parity and one stop bit. As root run "minicom -s" to set and save this configuration. Check the protections on the RS232 port (usually /dev/ttyS0) and "chmod a+rw" if needed.

My VME single board computer can not read the kernel or boot file

• Make sure "rsh" is enabled on the local host the single-board computer tries to boot from. Also make sure that on the local host the ".rhosts" file in the home directory (in which the single-board computer IP address is listed) has access permissions 600 (chmod 600 .rhosts).