DAQ

General Overview
The TIARA data acquisition system is VME-based and uses a master trigger in a common deadtime system. That is, it receives a trigger that is generated in some external logic electronics and then initiates the readout of any ADCs that have fired and builds them into events. During the readout of the ADCs, it provides a deadtime signal that can be used to inhibit the production of any further triggers (which would be ignored).

Physically, the system is located in VME crates. One VME crate is the Master and contains an MVME 5500 processor in the first slot (nnlx1). This processor card has access to all other VME modules via the VME backplane, it has access to an ethernet connection that is used to set up nnlx1 and it has access to a separate ethernet connection that is used to broadcast the data stream containing blocks of complete events. The Master VME crate has a card that connects it via a cable to a card in a Slave VME crate that acts as a transparent extension of the first crate. This allows the ADC cards and other VME units to be distributed across two physics crates in the most convenient fashion. In the setup file for the control programme, an address is set for each of the various VME modules and this must obey certain rules that depend upon which crate houses the module (see below). The address is set inside the module itself (hardware address), and in the code (software address), and does not depend in detail on which physical slot is used in VME..

DAQ Software
The Data acquisition software used for this experiment is MIDAS (Multi Instance Data Acquisition System). This software package is developed and maintained at the Daresbury Laboratory (UK), more information could be found at the project web page and should not be confused with the other MIDAS (Maximum Integrated Data Acquisition System) used by PSI and TRIUMF.

The software performs four separate roles,
 * 1) Slow control, allowing for setup of the hardware (setting Discriminator threshold, setting ADC gate,...)
 * 2) Readout of the data from the hardware and writing to file (Via the Tape Server)
 * 3) Basic histogramming (one 1D histogram per channel)
 * 4) Online server, storing and making the data available to online analysis.

DAQ Hardware
The entire system in contained in three 19" racks:

Rack 1 contains a DELL blade server acting as the main DAQ server (hereafter, the server). The server runs the MIDAS software under a Linux Fedora environment. It also acts as a DHCP server for all other computers on the local DAQ network. RACKS 2 and 3 each contain a VME crate: VME1 and VME2 respectively. - VME 1 holds a MVME 5500 onboard CPU in slot 1 acting as the crate controller, this CPU is called nnlx1. On startup nnlx1 will first be assigned an IP address by the server, then proceed to download it's kernel via ftp from the server, boot the kernel, and mount the MIDAS software via smtp (therefore the nnlx1 os is stored on the server) and finally start the MIDAS DAQ software locally. - VME2 is set up as a slave crate to VME1, connected via an SBS 412-1 pair of cards; VME2 is therefore seen by the software as an extension to the VME1 bus. The slave SBS 412-1 card located is VME2 acts as the VME bus controller of this crate and must therefore be mounted only in the first slot of the crate. The SBS 412-1 cards are set in such a way that every instruction sent to the VME BUS at hardware addresses from 0x0000000 to 0x02000000 are transferred to the slave crate. Therefore, all modules in the slave crate must be configured with a hardware address strictly inferior to 0x02000000. On the software side, the only requirement is that the software address matches the hardware address, there is nothing in the MIDAS configuration that specifies the use of the SBS 412-1 card. The cards are setup using jumpers and you should not need to change those setting, but if you were to, take a pictures of the Master and Slave card beforehand.

The event processing logic:
The module that accepts the event Master Trigger signal is called the SAC, and was designed and built at Daresbury. This unit can access the VME data bus. While the system waits for a Master Trigger to arrive at the input of the SAC unit, the ADCs are all in a state where their inputs are enabled. They are therefore live and are ready to encode any input that exceeds the internally set lower level discriminator. When the Trigger signal arrives to the SAC:
 * The inputs for all ADCs are disabled and remain disabled until the event processing is complete,
 * The front-panel VETO output of the SAC is switched to indicate the start of the event dead time. This signal should be used to inhibit the production of further triggers by the external trigger logic,
 * The nnlx1 processor is sent an interrupt signal by the SAC to indicate the start of an event,
 * The nnlx1 then follows a procedure to systematically scan the modules and individual channels to determine which channels have fired, to read them out (in a predetermined order) and finally to reset all of the modules. It knows where to find all of the modules according to the setup data that is entered via MIDAS,
 * The event data are written into a buffer in the nnlx1 and the SAC is signalled to say that the event processing is complete,
 * The SAC then toggles the VETO output on the front panel to terminate the dead time signal and enables the inputs to all of the ADCs, so this VETO output is the measure of the total dead time of the system for each event, and can be used to gate scalers that are measuring the dead time,
 * In the background, the nnlx1 broadcasts blocks of data over the ethernet when the buffer exceeds a high water mark (and toggles to another buffer to allow this process).

Starting the DAQ
Here is a link to manual written by Adrian and Ryan.

QUICK REFERENCE GUIDE

 * 1) Log onto t40server, become superuser, run script   Wait until   shows up in top-left terminal. If it fails to do so, reboot VME.
 * 2)   →   →   Try a couple more times if it fails, then give up and re-boot everything
 * 3) Tape Server:   → Click   button by  . Then   →   →  . Make sure   and   checked in the main Experiment Control window.
 * 4) CFDs:   →   → Tick the modules and channels you want enabled, set thresholds
 * 5) ADCs:   →   → Tick the modules and channels you want enabled, set thresholds
 * 6) Scalers:   →   →
 * 7) Spectra: Make sure   box checked; then   →
 * 1) Spectra: Make sure   box checked; then   →

Starting the server
The first thing to start is the server. The server have two ethernet port, one connected to the laboratory network and one connected to the local network on witch the DAQ is running. Boot the server and login (locally or remotly via the laboratory network). User name and password are written on the pull out ID card in the server front panel. Once logged in launch the DAQ startup script:

$> ./daq_script/startup.sh

This will first activate all the necessary service for the server to act as such (DHCP, ftp, smtp). Then it will launch tmux (terminal multiplexer), and split the terminal windows in four. Tmux allow us to have multiple terminal session into a single session, especially useful when working remotely. The upper left windows is the minicom output on port com1, connected to nnlx1, it allow you to monitor the status of nnlx1. The upper right windows is the MIDAS64-session windows where the MIDAS DAQ software is executed. The lower left windows is the tape server windows were the "Write to disk" MIDAS software is executed. The lower right windows is left for your use. You can switch from one panel to another by using "ctrl-b" followed by one of the arrow key (Besides, "ctrl-b + 2" takes you to bias setting panel and back to the normal panel by "ctrl-b + 1").

The way the system is setup, the Tape server is the same computer as the DAQ server. The data are therefore written to the server hard drive. The server is fitted with two 2Tb HDD mounted in RAID 1 configuration (and therefore appearing as a single 2Tb drive).

Starting nnlx1
Once the DAQ is started on the server, you start nnlx1 by switching one the two VME crates (both need to be on for MIDAS to work correctly). Once you started the crate, you should see the booting messages in the minicom windows (upper left) of the terminal. If the boot goes correctly (a lengthy process of about xx minutes), you will be prompted by the following message:

$> nnlx1 login:

You do not need to login, but if your wish to do saw, simply type the user name "root".

Setting up the hardware
Once the login prompt is visible, nnlx1 is ready to be configured by MIDAS, to do so, click on the "VME Control" menu in MIDAS and choose "Experimental Control". A new window will appear will the list of module in the VME crate, their hardware addresses (that should match the address set on the module itself) and their position in the crate (for information only, does not affect how the module works). Click on the "Load configuration into register" button, if all the hardware and software configuration matches, the process should check a few second (you will see text flashing in pink in the lower left of the windows). Once done, you can close the windows using the cross at the bottom right.

You can now access module specific menu in the "VME Control" menu, for example to control the Discriminator, click on v895, and menu allowing you to change the threshold and activate/deactivate channels will appear. You can all on All module and/or all channels for faster setting up.

Here are details specific to each modules

Finishing nnlx1
"Quit" in the menu and then type "pkill tmux"

= SAC =

The module that accepts the event Master Trigger signal is called the SAC (Silenna Acquisition Control), and was designed and built at Daresbury. As its name suggest this unit is originally designed to work in conjunction with Silenna's ADC. This introduce an slight difficulty as the front panel connector matches the front panel connectors of the Silenna ADC but differ from the front panel CAEN V785 connectors. The SAC hardware address is setup using switches located in on the board. It uses the A16 address of 0x0800.

The SAC control the triggers using the following pattern of operation:While the system waits for a Master Trigger to arrive at the input to the SAC unit, the ADCs are all in a state where their inputs are enabled. They are therefore live and are ready to encode any input that exceeds the internally set lower level discriminator. When the Trigger signal arrives at the SAC:
 * the inputs for all ADCs are disabled and remain disabled until the event processing is complete,
 * the front-panel VETO output of the SAC is switched to indicate the start of the event dead time. This signal should be used to inhibit the production of further triggers by the external trigger logic,
 * nnlx1 is sent an interrupt signal by the SAC to indicate the start of an event,
 * nnlx1 then follows a procedure to systematically scan the modules and individual channels to determine which channels have fired, to read them out (in a predetermined order) and finally to reset all of the modules. It knows where to find all of the modules according to the setup data that is entered via MIDAS,
 * the event data are written into a buffer in nnlx1 and the SAC is signalled to say that the event processing is complete,
 * the SAC then toggles the Veto output on the front panel to terminate the dead time signal and enables the inputs to all of the ADCs,
 * in the background, nnlx1 broadcasts blocks of data over the ethernet when the buffer exceeds a high water mark (and toggles to another buffer to allow this process).

= ADC: V785 =

= Discriminator V895 and V814 =

= TDC: Vyyy =

= Scaler: Vxxx =

= CAENet controller =

= Frequently Asked Questions =

We saw this problem when we did alpha source measurements in February, 2017. In that time, the "Run" button went white shortly after we "daq.sh" --> "Load Configuration Register Server" on Control panel (Under VME Module Control) --> Control (under Experiment Control). Also, at the same time, we couldn't access ADCs and Shapers from DAQ, which means we couldn't change at all setting like thresholds. If that is the case to you, first, check the ADC's display. If "Busy" LEDs are on, that may be causing the trouble (these lights on shortly after we "Load Configuration Register Server" in our case). Pressing "Reset" button (some times, if necessary, because no LED lights on the module, hard to tell if the button is working) on CAENet controller which communicates with the shaper modules. In our case, this fixed the problem. Then, it might be better to reboot the VME modules (just turn off and then on) before restarting the DAQ (pkill tmux, and then daq.sh). When you restart the DAQ and "Load Configuration Register Server", if you didn't see ADC's busy LEDs and see DRDY (Data ReaDY) LEDs instead, your problem is likely to be solved. In our case, the shapers didn't output any signals (preamp out signals (i.e., shaper input signals) were ok though), which we presume no signals went to either CFD or ADC. This might be related to the ADC busy problem. Anyway, by "Resetting" the CAENet, the communications between Shapers and DAQ recovered, and probably Shaper ouputs went to ADCs appropriately, and then solved the ADC Busy problem. If you experience something different, please post it on wiki.
 * What to do if the "Run" button on Control Panel (Under Experiment Control) went white and cannot run the DAQ?