DAQ

From NPDGamma Wiki

Jump to: navigation, search

The data acquisition system for NPDGamma is very simple, as everyone is fond of saying.

The DAQ program (button program) is run from Clover/Control, which ssh's into hazel, which subsequently ssh's into the 3 VMEs and tells them to take data. The only input is the number of T0s. Once the specified number of T0s is recorded, the information is copied back to hazel, the runs are given appropriate names and written to the RAID array and also to Fiver.

See Nadia's continuously evolving write-up on the data structure and DAQ setup (LINK)

This was the most current wiring diagram - [link] and the one [link] preceding it, which is still occasionally useful.

and the write-up that goes with it [link]

Contents

DAQ Administration

  • The work package leader for the DAQ is Scott Wilburn, who is stationed at LANL. The on-site DAQ expert and custodian is Nadia Fomin. Any DAQ work that is not routine has to be approved by her.
  • Routine DAQ Tasks
    • Start/Stop runs
    • Viewing data runs with online analysis software
    • Rebooting crashed VME crates
  • Tasks requiring Nadia's approval
    • Any wiring changes in the VME crates
    • Any DAQ code changes (on clover, hazel, or vme computers)
    • Installation of any software on clover, hazel, or vme computers
    • If you're not sure - ASK! These computers are isolated from the outside world, and are not backed up with any regularity.
  • DAQ components and their primary functions
    • Cyclonus - technically administered by ORNL. This is the "bridge" machine that has internet access, but is also on a private network with hazel and clover. We use cyclonus to make elog entries while on shift, and to monitor beam parameters.
      • Cyclonus does not have a common account, like npdg, as that is against ORNL rules. If you wish to have a cyclonus account - contact Nadia. Your userid will be the same as your ucams id.
    • Clover - this is the computer that runs the "button" program, i.e. the gui we use to take runs. It is also the computer that has the removable disk for local data storage, which means this is also the computer we use to look at the data (online analysis code lives in /home/npdg/SNS_ONLINE). While you'd think that clover takes data, in actuality, it does not.
    • Hazel - this is the computer that actually interfaces with the VME crate computers and sends out commands to start runs. It then collects the data and pipes it back to clover for storage and copying to fiver (located at UT and accessible to everyone who's not at ORNL).
  • OFF-site NPDGamma-related computers
    • Fiver - this is the main analysis machine that also has a raid array with a copy of the data attached to it. This machine does NOT accept passwords, only keys. Do NOT request accounts on this machine unless you will be analyzing the data. The first step in requesting an account is to create a private/public ssh key pair. Google for instructions. The people who can grant accounts are Nadia, Matthew, and Rob.
    • Battlestar - this is the machine that hosts the wiki and the e-log, both of which are backed up daily. If you require an account on the wiki, contact Nadia, Matthew, or Kyle. No one except the administrators of the wiki and the elog should require accounts on this machine. Also, physical access is pretty much limited to people who have a UT affiliation and can get keys and swipe cards to the appropriate buildings.

Current Wiring Diagram

A slightly outdated overall wiring diagram is available here --> DAQ Wiring

There have been updates to add a latch to VME1 to eliminate some bad run file sizes, and also an update to the spin-sequence gating logic under VME3, which can be found here. The diagram update shows two available configurations, and Configuration 0 is currently in use.

This is a very visual guide, where different kinds of modules are depicted in different colors and only the existing connections are shown (i.e. there are unused inputs/outputs on some modules). Each module in the diagram is labeled with X.Y, where X denotes its location in the crate (1-whatever), and Y denotes a submodule (for example, coincidence modules are typically broken down into more than one).

There is another version of something similar here.

SNS Proposed network structure

This is the original proposal for the network structure at the SNS. As of now, we do not possess "unnamed internet machine", and the connection between target and B-field computers does not exist (the latter should in the near future, the former in the slightly less near future). .

. .

Status Update

The current state of the DAQ (as it pertains to the detector and monitor data) is described here DAQ STATUS

This is the previous (4/11/2008) status update for the collaboration link

VME 1

Image:vme1a.jpg Image:vme1b.jpg

VME 2

Image:vme2a.jpg Image:vme2b.jpg

VME 3

Image:vme3a.jpg Image:vme3b.jpg

In the above picture, the VME3 crate is missing a Joerger VS64 module. A replacement has been bought, and since then, the original was located (naturally).

New Spin Sequencer

After the data taking period of 2011, the analysis of the PV asymmetry data revealed a transient in the signals that is largest for the first pulse in the sequence. This is a problem as the spin sequence repeats every 150 ms, and there is an additive asymmetry that is introduced by this transient. The solution is to alternate the spin sequences: A, B, A, B, where A is 01101001 and B is 10010110. At first, it was done and tested with NIM logic, but then, Jackie built us a new spin sequence module.

Its schematic is available here.

DAQ-related talks

Friday Lunch Talks - Nadia Fomin (link)

Pics of VME2 with the back plate off (VME2_REAR)

ADM31 High Performance Data Acquisition System Users’s Manual Revision 1.1 March 1994 (should be manual for Detector ADC)File:ADM31 48 96.pdf

TRIUMF Gain Module Manual HERE

Personal tools