$Id: sga_setup.html,v 1.2 2005/05/31 20:02:55 tl Exp tl $ GAMMASPHERE sga DAQ

The GS sga DAQ


Basic and Setup commands


Runtime commands

Other commands

Fiber optics cables

Data from the shack comes through four fiber optics cables. A 5'th fiber optics cable is use for data flow control.

To switch from the old DAQ to the new sga DAQ, the five fiber optics cables must be moved from the Event Builder (EB) in the old VME crate/rack to the EB in the sga (small) VME crate. The new sga VME crate is currently located on the table to the left of the old DAQ, behind the old VMS chemf machine. Simply move the fiber optics cables from the old EB to the new EB. The connectors are just like BNC cables, but they are fragile, so move them carefully. The cables are labeled by the lowest bit they carry, notice how they are labeled on the old DAQ before you move them.

At some point, when some console problems have been solved, the sga DAQ VME crate will probably move out into the shack.

Console access

Currently the console access to the sga CPU is through con5. Thus, either directly on con5 or remotely logging in to the machine, issue this command:

  tip -9600 /dev/ttya
That should give console access to the processor from the window you issued the tip command from. The sga DAQ is currently controlled entirely from the console. There is no remote control at this time.

It is a good idea to have the console up before rebooting (or turning power on) so you can see how the booting proceeds.

To kill a console connection, type

  pkill -KILL tip

Processor boot

When the processor is powered up, it will automatically boot. The VME crate has a small on/off toggle button on the front that turns on the power to the VME crate. The processor should show these lines at the end if it booted up properly:
#To start the Acquisition, type #
#                               #
#    sgaInit                    #
#                               #   
#at the command line            #

Starting sga

Typing 'sgaInit' ( notice the capital 'I') in the console window starts the sga DAQ program on the VME CPU.

note: The current calibration parameters are automatically loaded when the sga DAQ is started up.

note: You are not expected to ever get out of the sga program again once it is started, so there is no need for an exit option in the sga program.

note: Type 'help' to show the commands that are available. These commands are documented below in ~roughly the order that you would use them in order to start up an experiment and take data.

Storing data directly to USB disks

It is possible to make the sga DAQ store data directly to a USB disk which you can take with you at the end of your experiment.

Here is a short writeup of how you mount the USB disk on con5 or con6 so the VME PowerPC can mount it and write to it.

The instructions for the linux machines are here.

data format

The dataformat on the disk is just like the regular GS dataformat except that the Tape headers and buffer headers are written to disk as 16K buffers. Thus, the first two buffers in a file have first word values of 1 and 2. The rest of the buffers are data buffers and have first word values of 3.
Note: older version of the new DAQ only wrote data buffers to disk.

Backup issues

You may write the data from the new DAQ to GS disks or USB disks. In both cases, it is YOUR responsibility to backup your data either to another portable drive or tape. We cannot take responsibility for backing up your data. There are two DLT tape drives available for this purpose as well as a number of 8mm tapedrives.

A RAID array may be available in the future, but for now the data goes to regular disks. Thus, it is important to backup your data as you go along in the event that the disk you store the data on encounters a problem during the experiment.

If you are using GS data disks for storage you will have to relinquish the space on the disk(s) quickly after your run so the next experimenters have disk space available to store their data.


use: datadir host dir

This command is used to specify the host and top-level data directory where the
data acquired by the sga DAQ is stored (it is all to disk now).  The specified
host must have the directory exported to the sga processor for this to work.
The top-level directory will have subdirectories, one for each run specified.


datadir con6 /home/root3/gamuser/gsfma167

note:  look for the /home/root# disk that has the most space available.  Then
specify the directory with the gs run id for your experiment as shown above.
Make sure to specify the host that the disk you are going to use is mounted on.

note: there is usually as default host directory specified, so you may not necessarily
have to issue this command to get started.  It is possible to have a removable
USB drive be the destination for the data (needs a little more work).

note:  The data is owned by user 'gamuser'.  So user 'gamuser' must have write
access in the directory where the data is to be stored.  user 'gamuser' is owner
of /home/root2/sgadata and other directories on the suns.

note: you must specify '/export/home/...' since these are the direcories
that are exported. Both on the host and other machines, the same directory
is know as just '/home/...'

note: it is a peculiarity of the VME processor, that the directory
is created so that only gamuser can see it. You can use the 'chmod o+rx'
from the suns to change the access if anyone else needs
to be able to read the data.


use: newexp dirname descriptions

This command is used to start a new experiment.  'dirname' will be the directory
where the data files will be placed.  The 'descriptions' ends up in the log
file and the info buffers (first two 16K buffers) of the disk file.


newexp 152dy_a 48Ca@197MeV

note: use ls to see where the directory '152dy_a' was opened.

note: there must not be any spaces in the 'descriptions', use _
      instead of spaces.

note:  You cannot open an old directory.  If the DAQ crashes, then you must open
a new directory.  That is the reason for the _a in the example above, so you can
use _b for the next one and so forth.

note:  A logfile is opened in the current datadirectory at the end of this step.
Use 'ls' to see where it is and what the name is.


use: newrun description run#

Used to start a new run. Specify the run number you want
with 'run#' 

The 'description' end up in the info buffers (first two 16K 
buffers) of the disk file.


newrun 201MeV 21

note: There must not be any spaces in the 'descriptions', use _
      instead of spaces.
note: the new DAQ will not accept a run number less than
      the current run number.       


use: sendto host

Used to specify a computer to send the data to for online
monitoring (e.g., with GSSort). 


sendto con5

note: There is no broadcast option in sga, so you can only
send data to one computer at a time.

note: the DAQ must be stopped to set a host to send data to.

note: to stop sending data, use the 'nosend' command.

note: the sga sender has some problems. Occationally it will
send out some bad data packets. The data save to disk do
not have these problems, so it it is only the on-line sorter
that detects errors. The error rate is less than 1/1000, so
it is a very small problem.


use: start

starts the DAQ



note: There is no response from this command, so you normally
type 'stat' just after it to see that that DAQ indeed started up, data
is flowing to disk and sent out.


use: stop 

Stop the DAQ, or rather the processing of the data from the CES memories.





use: loadcal

Used to load the current calibration files:


which are on the host computer specified by the datadir command. Use printcal
to see the calibration parameters. Use 'showdirs' to see where the directory 
resides physically.



note:  the calibration parameters are loaded automatically when you start the
sga DAQ program.

note: /sga is really a link to /home/root2/daq/sga/current/.


use: printcal

Print the Calibration coefficients





use sendfrac #

Used to specify the fraction of data, 1-in-#, that is
sent to the the computer with the online monitoring


sendfrac 2

note: The above example would send every-other processed
databuffer (via UDP packets) to the receiving computer

You can send data to the computers that were listed when you booted the processor, including a few outside onenet.


use: showmode

used to show the modeflags that control what data is
saved and sent.



the response might look like this

GScmd: showmode
h->mode = 0x01ba

note: the above example shows the typical modeflags you would have
if you write 'everything' to disk. Notice the TAC2 signal is not subtracted
in this particular case.


use setmode +|- mode

where mode is one of the following:

GC_MODE       : gain correction
TIME_VETO     : time veto
HC_SUPPRESS   : honeycomb suppress
WRITE_GE_TIME : write ge times
WRITE_GE_FULL : write all ge information
WRITE_BGO     : write BGOs
WRITE_ALL_GE  : write dirty germaniums
WRITE_ALL_BGO : write all BGOs
RF_TIMING     : do tac2 subtraction


to write 'everything out'

setmode +WRITE_ALL_BGO
setmode +WRITE_ALL_GE
setmode +WRITE_BGO
setmode +WRITE_GE_FULL

to then switch to just writing the usual 
limited information out

setmode -WRITE_ALL_BGO
setmode -WRITE_ALL_GE
setmode -WRITE_BGO
setmode -WRITE_GE_FULL

to switch on and off the TAC subtraction:

setmode +RF_TIMING
setmode -RF_TIMING

note: The typical limited datastream is default. Use
'showmode' to see what the modeflags are.


use: getimewin [lo hi]

Used to show and set the prompt time windows on the germaniums.


getimewin 1400 166

note:  The prompt time windows should be set properly after alignment if you
want the SGA software to properly identify events that should be honeycomb
suppressed. 'printrates' will show some info on the suppression. 


use: bgotimewin [lo hi]

Used to show and set the prompt time windows on the BGO detectors.


bgotimewin 1200 1800

note: works just like getimewin, just for the BGO detectors.


use: feradelay value

used to specify the dipswitch setting on the FERAVXI board that
controls the delay before the FERAS are read out. This dispswitch
setting is used to identify events with external data

the input must be in decimal and in the range 0-15

0000 0  0
0001 1  1
0010 2  2
0011 3  3
0100 4  4
0101 5  5
0110 6  6
0111 7  7
1000 8  8
1001 9  9
1010 a 10
1011 b 11
1100 c 12
1101 d 13
1110 e 14
1111 f 15
  ^  ^  ^
  |  |  + - decimal
  |  +----- hexadecimal
  +-------- binary


feradelay 12

note: The example shows how this parameter should be specified if
only the two most significant bits are set. If the feradelay is not set
properly, the sga processor will not be able to decode the data
from the GS front--end. 

Use 'debug 32' to probe the data and see that the external data is decoded properly. Use 'debug 0' to which off the inspection again. The feradelay value is part of the datastream that goes to the sga DAQ, but the feradelay value is not passed on to the output stream. The relation to the feradelay word used in the old DAQ is given below: FERA dip switch settings and OLD fera delay word |sga FERA word |||||| | 0100 00ww wwww wwww dddd dddd dddd dddd - 0x4000 0 0100 01ww wwww wwww dddd dddd dddd dddd - 0x4400 1 0100 10ww wwww wwww dddd dddd dddd dddd - 0x4800 2 0100 11ww wwww wwww dddd dddd dddd dddd - 0x4c00 3 0101 00ww wwww wwww dddd dddd dddd dddd - 0x5000 4 0101 01ww wwww wwww dddd dddd dddd dddd - 0x5400 5 0101 10ww wwww wwww dddd dddd dddd dddd - 0x5800 6 0101 11ww wwww wwww dddd dddd dddd dddd - 0x5c00 7 0110 00ww wwww wwww dddd dddd dddd dddd - 0x6000 8 0110 01ww wwww wwww dddd dddd dddd dddd - 0x6400 9 0110 10ww wwww wwww dddd dddd dddd dddd - 0x6800 10 0110 11ww wwww wwww dddd dddd dddd dddd - 0x6c00 12 0111 00ww wwww wwww dddd dddd dddd dddd - 0x7000 12 0111 01ww wwww wwww dddd dddd dddd dddd - 0x7400 13 0111 10ww wwww wwww dddd dddd dddd dddd - 0x7800 14 0111 11ww wwww wwww dddd dddd dddd dddd - 0x7c00 15 ^^ ^^ || |+- low bit || +-- 2'nd bit |+---- 3'rd bit +----- high bit on fera delay dispswitch e: error bit, second highest bit, always 1 (not 0!) w: word counter d: data


use: modcal type list offset [gain]

used to manipulate the calibration coefficient from the sga console
(rather that GSSort), especially to fix up 'bad' values and such.

type is one of: ehi, elo, esi, tge or tbgo and list is, e.g., "12,16-30,75,80-110". Then follows the
offset, and for energy calibrations the gain.


modcal tge 1-110 0

sets all germanium time offsets to zero.

modcal ehi 86 -0.23 1.0567

set the calibration parameters for detector 86

note: Make Sure you save the parameters afterwards with
the 'savecal' option, see below.


use: savecal file

Saves the calibration parameters that the sga CPU has to the
default calibration files on disk so they can be loaded properly
on reboot or if GSSort is used to find new calibration parameters.


savecal /data/curpar.cmd
savecal /config/curpar.cmd



use: isomermod [# fakeVSN]

Declare a module to be an isomer detector. This detector
will be taken out of the regular GS data and redefined
as an external FERA module with a VSN of 'fakeVSN' and
the same FERA dataformat as an ORTEC FERA.
Ch 1 is hit BGO hit pattern, ch2 is BGO time and ch 3 is BGO energy.


isomermod 14 214
isomermod 16 216
isomermod 18 218

note: to return a geBGO module to regular GS use, specify a VSN
      number of zero.
      to list the isomermodules, leave out any arguments.      



use stat [#sec]

Used to make a snapshot of the status of the DAQ, including
the event rates. It prints
part of the information that you see on the WWW:


#sec is the number of seconds to gather statistics for the rates.
3 seconds is default. 



the response might look something like this

GScmd: stat log
Mon Jun 06 09:44:45 2005

data storage host...: con5
directory/exp-name..: /home/root2/daq/sgadata/a1
__description.......: test
run number..........: 1
data file...........: a1.r001.dat.023
log  file...........: a1.r001.log
__chunck stat.......: #23 -> 97003/120000
UDP sending data to.: bohr; fraction: 1-in-5
time window: GE:[1,16384] BGO:[1,16384]
feradelay: 0x000c=12 (dipswitch setting)
record ver: 1; debugflag: 0x0000; h->mode = 0x001a
16k buffers   =    2857026
saved buffers =    2857026;     45712 MBytes
sent buffers  =     571405;      9142 MBytes
mapped evts   = 1531712805
.... waiting 3 seconds for rates
buffer rate....:    27.333 16KBuf/s
data rate......:   437.333 KBytes/s
disk save rate.:   437.333 KBytes/s
sender rate....:    85.333 KBytes/s
event rate.....: 14576     Events/s

so it has a lot of information.

note: if you rates are low, you may have to specify large value
of #sec (60 is max)


use: printrates

prints the rates of the detectors as well as the fraction that is in
the prompt time windows on the bgo and germanium detectors.



note:  The rates are found asynchronous by a task that runs in the
background.  So the rates are 60 seconds behind.  The rates are also
shown on the WWW page.

Note:  Please be aware that the rates that are shown with 'printrates'
are not the sane as the scaler rates shown on the EPICS screens.  The
latter rates are the free running hits in the ge and BGO detectors,
whereas the rates shown with 'printrates' are the aparent rates in the
ge and BGO modules after trigger conditions have been applied.  Thus,
they are in genaral much lower than the raw scaler rates.  The
'printrates' function is mostly meant to check the ge and BGO time
windows.  The ge time windows must be set properly for the honeycomb
suppression to work and both the ge anf BGO time windows must be set
carefully in order to extract the HK information


use: showerrors

Shows errors encountered while interpreting 
the data in the CES memories



note: If you are not seeing the datarate that you expect based on the
rates in the Master trigger module, use this command to see if one
of the CES memories has developed a problem.


use: zeroerrors

The errors shown with 'showerrors' are accumulated errors. Using this
command the counters used in 'showerrors' are reset so that you can get
a current evaluation of the error rates.





use: ls

list the data files and log file in the current
experiment directory. Similar to 'ls -l' under
unix. The command will also conviniently remind you of which computer
the data host is and what directory the data is stored in.



note: the data is stored in 'chuncks', the ending number
is the chunck number. 


use: ratewatch [on # #|off]

Used to keep an eye on the rates.  It will scroll down the console
window, if the DAQ is on, making it easy to see if the DAQ is working
properly. first # is time bt. logging to console, the second # is
the modulus for logging the rate to the logfile.


ratewatch on 30 10
ratewatch off

First example turns the ratewatch on, printing out every 30 seconds
and looging the result to the logfile every 10'th time (i.e.
every 300 seconds).
The second example turn the ratewatch off again



use: savedata

turn on saving of data (default)





use: nosave

turns the saving of data off





use nosend

turns the sender off





use: showdirs

The sga VME CPU NFS mounts a number of directories. This command
lists these directories.





use: ps

Like the Unix 'ps' command. List the processes that
are running on the sga VME CPU




use: watchdog [on #|off]

There are hiccups in the GS DAQ that needs to be monitored
by watchdog tasks. That was the case in the old DAQ as well.
This command is used to turn on and off the sga Watchdog.


watchdog on 30
watchdog off

the first example turn on the watchdog, asking it to check
the error rates every 30 seconds. If there are too many errors,
it will reset the DAQ and restart the acquisition. The second example
turn the watchdog off.

note: The watchdog is normally always (per default) active.
You should not have to turn it off


use: file

used to execute the command in a command file. 





use: reboot

reboot the sga VME CPU 



note: equivalent to cntrl-X under VxWorks