Guide to Data Acquisition at ATLAS


A Guide to Using the MSU/NSCL Data Acquisition System at ATLAS.

Here is a brief list of what's involved. More details will appear as we learn them. The goal is not to reproduce the comprehensive manual here, but to get the user started and provide information specific to the installation as it is configured at ATLAS.

There are several independent processes involved in acquiring, monitoring, and recording on tape. The Front End is a VME based multiprocessor system. It replaces the event handler (and more) of the old system. There is a master which packs events into buffers and sends them out on the ethernet and a slave which talks to CAMAC and reads the data. The slave programming is done in C which makes it a much more versatile and powerful system than the familiar event handler language. To simplify matters even more many macros have already been written to simplify most of the CAMAC functions typically used.

The Back End is just a DEC ALPHA running VMS (oh well). It receives data buffers over the ethernet from the front end. A program called ROUTER distributes these buffers to CONSUMERS such as DAPHNE, SCALER, TAPE, and anything you may write on your own to monitor/analyze the data on-line. Currently, the standard histogramming task is DAPHNE. However, this is its sole task. It no longer handles writing data to tape, a distinction that is important to remember. If DAPHNE hangs up or crashes, your data is most likely still being put safely on tape by the MSU TAPE process.


View of the System Architecture


Step-By-Step Front End Setup Procedure


Step-By-Step Computer Setup Procedure


Run Control Basics


How to Restart After the System Crashes:

If the data rate is too high, the front end has a tendency to crash unexpectedly. To make matters worse, it may do so quietly. If there is no system dump in the data acq window, then the ways to tell are by noticing that the scalers have stopped increasing (you have to be watching the 'totals' of course), or your spectra have no new counts. Since the system seems capable of crashing often (usually a result of user errors in the triggering electronics or slave program), it seemed only natural to have a separate section on what to do after. Some things will still be loaded and/or running. Some will not. Some will have to be killed even if they are running.

Sometimes only DAPHNE crashes and takes the entire window down with it. This has the unpleasant side-effect of killing the ROUTER, tape, and scaler processes. This will stop your data collection since there is no process writing to tape. If DAPHNE hangs up, but the window remains alive, then data is probably still being collected. The trick is to figure out how to unhang DAPHNE without disturbing data collection.

Below are lists of what you should do if the front end crashes or if just the window gets blown away without a trace (or has to be killed voluntarily).


DAPHNE Stuff:

All the usual DAPHNE structures, commands, etc are unchanged for the most part. Consult the usual sources of help if necessary. Only those commands which are modified or might cause confusion are mentioned.

SCALER Stuff:


TAPE Stuff:


Front End Stuff:

Many front end commands can be issued both from the standard DCL prompt ($) as well as from the front end's own prompt (RcTL>). The commonly used commands like BEGIN, END, etc. have DCL symbols which will execute them without explicitly connecting to the front end first. Ignore this comment and some details below about 'connecting to the front end' if it confuses matters. Just stick to the DCL commands. To gain access to the front end, type fe at the DCL prompt. You then have an 'RcTL>' prompt. A complete list of commands and the general syntax is in the front end section of the MSU manual. Below are some commands which must be executed from this prompt. How to reload the front-end with minimal disruption

PROBLEMS/BUGS/FAQ's:


Electronics Requirements:

Two weaknesses of the interrupt-driven MSU system require some hardware modifications to any standard setup you may already have: 1) It cannot generate a busy signal until ~25 usec after the event signal (INT2) has been received. 2) It cannot wait a calibrated time after being triggered for things such as ADC conversions. We have drawn a schematic of how to implement this trigger logic.

The optional delay for the event signal replaces the software delay we had in old event handler codes. It's value should be chosen such that there is enough total delay for adc conversion before the program begins to read out. If you need 80 usec for an AD811, for example, then add ~60 usec delay to the event signal. If none of the electronics needs more than 25 usec conversion time, then there is no need for any delay.

The width of the event signal plugged into INT2 should be at least 100 nsec. There is no reason to skimp, and many reasons not to. Double-firing of the event signal may send a second interrupt to the slave processor before it has had a chance to process the first one and block out further ones. This may cause the slave to crash.

The 222 gate generator used in latch mode performs the function of setting a prompt busy. Simply start it with the UNDELAYED event signal. The MSU system will generate an end of event signal which is available via a BiRa output register (chan # 1) in the camac crate. We use this signal to end the busy signal. It can be used for other things you normally like to do at the end of an event. In the BGO setup we also use this end of event signal to clear our MLU camac module.

A consequence of using the latching gate generator is that unplugging the event signal and plugging it back in may leave your electronics inhibited since you will have started the BUSY latch, but not necessarily stopped it. Just push the stop button on the LeCroy 222 to get acquisition going again.

The MSU system also provides a "STOPPED RUN" signal. It sets a bit in the BiRa output register (chan # 2) at the end of a run and clears it at the beginning. Just fan this in with the normal BUSY to inhibit the electronics at the end of a run.


Slave Program suggestions:


Communication with and Setup of CAMAC Hardware (CNAF)

CNAF commands can be issued in the MSU system using the BCNAF command from the front end (FE) or the 'RCTL BCNAF' command from the regular command line. However, there is currently no software ready to do these tasks from inside programs. Fortunately, the branch (parallel) crate controllers, BiRa 1302LM A-2, used in the MSU data acquisition system allow us to use our old Kinetics system controllers , KS3989 RS232, as 'auxiliary' crate controllers in the CAMAC crates. This allows us to issue cnaf commands running the same programs which we used in the old DAPHNE system - via these auxiliary crate controllers.

To use the KS3989 controllers as auxiliary crate controllers 16 resistor packs must be removed from them. Six of them are easy to get access to; but 10 of them are only accessible by removing one of the PC boards of the module (see the manual for instructions on how to do this). Some of the resistor packs are removed so that the auxiliary crate controller does not terminate the CAMAC bus - that should only be done by the master crate controller in slots 24/25. Thus, only modified KS3989 controllers can be used as auxiliary crate controllers. Likewise, modules that have been changed cannot be used as master crate controllers anymore. The modules that have been modified are marked as such with yellow tape on the side of the boxes. Please clearly mark any that you may change, and do NOT lose the resistor packs!

The main crate controller (the BiRa) in slots 24/25 must have a cable from its 'REQUEST' to 'GRANT IN' LEMO connectors. In addition, a cable must connect the BiRa crate controller's 'GRANT OUT' (in slots 24/25) to the KS3989 controller's 'GRANT IN'. The auxiliary crate controller (KS3989) can be placed in any slot of the CAMAC crate. Since some of the CAMAC control lines are only available in slots 24/25, a ribbon bus cable (called "ACB" or Auxiliary Crate Bus) connects the master crate controller to the auxiliary crate controller. The 40 pin bus connectors are on the back of the crate controllers. When the auxiliary crate controller receives a CNAF command over it's front-end RS232 serial line, the auxiliary crate controller will issue the command from the main crate controller via the ACB bus. It doesn't actually do it itself. The request/grant lines are only there to establish the priorities of the crate controllers, all communication is done over the backside ACB bus.

figure: Auxiliary crate controller connections.

As opposed to the DAPHNE system, the RS232 lines used to issue the CNAF commands are not direct lines from the DAQ computer to the CAMAC crate serial controllers. Rather, ports 2,3 and 4 of the terminal servers, which are part of the MSU rover DAQ systems, are used for this purpose. You can access those lines from the two ALPHA DAQ machines as:

All the lines are accessible from either of the two ALPHA computers.Please note: These lines used to be called lta8412,....lta8514. They were changed in August 1996

Ports 5-8 of the terminal servers are used for the MSU system processors in the VME crate. Port 1 can only be used as a 'local terminal'. However, ports 2-4 may be used either as 'local ports' (i.e., hooked up to dumb terminals) OR be used as RS232 lines for the DAPHNE cnaf commands.

WARNING:

Some notes:

Display lat-ports/scaler lat-ports

A number of lat ports have been set up on the terminal server in the data room for scaler and DAPHNE display terminals.
   lta5001:  scaler display on terminal next to anph15
   lta5002:  scaler display on terminal next to guppy
These connections are usually not touched and selected automatically from the ATLASSETUP scaler display menu entry.

A number of lat ports are set up for DAPHNE display terminals. These connections are somtimes changed - so check the connections if you cannot make the displays work. The standard connections are:

   lta5003: connected to the 4115 display @ anph15 (19200 baud)
   lta5004: connected to the 4107 display @ guppy  ( 9600 baud)
   lta5005: connected to the 4107 display @ anph15 ( 9600 baud)
To make the DAPHNE display connection to e.g. the 4115 terminal:
    hit ctrl-Z on the 4115 so that it no longer shows the "lat-3" prompt.
    ddv/type=4115 lta5003:

DISCLAIMER
Originally written by Daniel Blumenthal,
now maintained by [email protected] (Torben Lauritsen x4026)

$Id: index.html,v 1.2 2000/08/08 15:37:21 tl Exp tl $