As you might tell, this system grew organically.
Perhaps it is time for a wholesale re-write
(second system syndrome?) now that the specs
have settled. Being pragmatic, I will just 
document the current specs, but leave the existing
(working) code untouched (and severely ugly).

The way this system works is that the user specifies
what channels of what boards should be used in a
DAQ "run". The user also specifies which module
acts as a "trigger" for the DAQ, and which (scaler)
channels acts as a data set "delimiter" - i.e.
what channel increments when the NSRL "spill" is
complete.

The ugly truth is that a configurable "trigger"
is not really implemented - that requires a set
of functions for enabling/disabling interrupts 
on a per-module basis. This is doable, but not
high on anyone's priority list.


Even though a programmable "incrementer" IS supported,
there are issues with the SIS scaler, so only the
CAEN scaler is ever used, and it is always set to
the last channel.

OK, once the user is satisfied with the system configuration,
the Java app can launch the "runDaq" program, feeding
it an XML configuration file. The file is parsed by
xmlParse.cc, aided by the XmlDom C++ lib.

It turns out that not enough data is actually in that
file to specify all that is needed (as we will see),
so we take some short-cuts.

xmlParse.cc invokes low-level H/W functions - both in 
the CAEN bus-bridge library, an in "runDaq.c" - which was
the original "C" program to interface with the CAEN library.

runDaq.c contains the module-specific functions, e.g.
for reading channel data from the module, or (if it
were implemented) - setting up interrupts. As an aside,
the interrupts are actually set up by cfe-958-daq02, even
tho the data is read through the bus bridge (remember, 
I said it grew organically).

runDaq.c also responds to interrupts, collects data 
into memory (for printing out between spills), etc.
The "heavy lifting" of printing out data is done
in "unpackData.c". Th one remaining module (calibrate.c)
is used to establish a baseline for the V1290 fast
ADC. This device has systematic offsets which can be 
removed with a baseline subtraction. I don't think
this has ever been used - so it probably doesn't work.
If it DID work, it should be incorporated into the Java
app, or perhaps automatically at the start of runDaq.

HTH -- Larry

