HELIOS Digital DAQ - User contributions [en]

Experiments

2018-09-20T19:29:17Z

Crhoffman: /* ISS Experiments */

=Specific Instructions for Experiments=
==ISS Experiments==

* ELOG [https://isolde-elog.web.cern.ch/iss/]

===iss000-development, mg28 [Sharp, 09/2018], hg206 [Kay, 10/2018]===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ (local) Computer (anldaqrouter):'''
First go to the working analysis directory, then start sorting process on run of interest (ok to do this on run that is currently taking data). This will do a number of different things: 1) it will first run the GEBMerge program (GEBSort director) to combine and timesort all raw data and outputs to the merged file. Then it will run GEBSort (GEBSort directory) which is the event builder and outputs to a .root file. Finally, it runs the TSelector GeneralSort.C (sort_codes directory) which passes the raw data into the human-readable names, e.g., xf, xn, e, etc...A copy of this file is placed in the ../root_data/ director (gen_run#.root). The most recent gen.root file is also in the working directory.

gotoana (cd experiments/iss000/analysis)
cd working
./process_run_local.sh <RUNNUMBER>

The above process will continue to run until it is killed (Ctr-C). A good time to do this is when it says, XXX seconds until next sort...You can look at the gen_run#.root file manually at this point. Otherwise, you can run the following to generate a few pre-made histograms and canvases.

root -l ../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")

Then you have the filled histograms. You may also do the following for example after the Monitors.C has finished.

.L ../sort_codes/Utils.C
listDraws()

Will show some of the pre-made canvases and draw functions.

'''To sort data on the MAC Computer:'''
Sorting data on the MAC Computer (anlanamac) is very similar to the local daq sorting with a couple of small differences. Namely, you have to pull the data locally first before sorting (which requires typing of the password each time), and also, the sort does not continually run. So each time you want to look at the data collected you have to run the (./process_run.sh ##).

After logging into the MAC Computer (heliosdigios@anlanamac)

gotoexp
cd working
./process_run.sh <RUNNUMBER>
<ENTER anldaqrouter PSSWRD>

Now you will have the GEBMerge, GEBSort, and GeneralSort's completed and a local ''gen_run#.root'' file available. You can make the histograms same as before with this.

root -l ../../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")
.L ../sort_codes/Utils.C
listDraws()
xfxn()

'''Data Locations'''
On the LCRC at ''/lcrc/project/HELIOS/iss000''

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-09-17T20:07:54Z

Crhoffman: /* ISS Experiments */

=Specific Instructions for Experiments=
==ISS Experiments==

* ELOG [https://isolde-elog.web.cern.ch/iss/]

===iss000-development, mg28 [Sharp, 09/2018], hg206 [Kay, 10/2018]===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ (local) Computer (anldaqrouter):'''
First go to the working analysis directory, then start sorting process on run of interest (ok to do this on run that is currently taking data). This will do a number of different things: 1) it will first run the GEBMerge program (GEBSort director) to combine and timesort all raw data and outputs to the merged file. Then it will run GEBSort (GEBSort directory) which is the event builder and outputs to a .root file. Finally, it runs the TSelector GeneralSort.C (sort_codes directory) which passes the raw data into the human-readable names, e.g., xf, xn, e, etc...A copy of this file is placed in the ../root_data/ director (gen_run#.root). The most recent gen.root file is also in the working directory.

gotoana (cd experiments/iss000/analysis)
cd working
./process_run_local.sh <RUNNUMBER>

The above process will continue to run until it is killed (Ctr-C). A good time to do this is when it says, XXX seconds until next sort...You can look at the gen_run#.root file manually at this point. Otherwise, you can run the following to generate a few pre-made histograms and canvases.

root -l ../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")

Then you have the filled histograms. You may also do the following for example after the Monitors.C has finished.

.L ../sort_codes/Utils.C
listDraws()

Will show some of the pre-made canvases and draw functions.

'''To sort data on the MAC Computer:'''
Sorting data on the MAC Computer (anlanamac) is very similar to the local daq sorting with a couple of small differences. Namely, you have to pull the data locally first before sorting (which requires typing of the password each time), and also, the sort does not continually run. So each time you want to look at the data collected you have to run the (./process_run.sh ##).

After logging into the MAC Computer (heliosdigios@anlanamac)

gotoexp
cd working
./process_run.sh <RUNNUMBER>
<ENTER anldaqrouter PSSWRD>

Now you will have the GEBMerge, GEBSort, and GeneralSort's completed and a local ''gen_run#.root'' file available. You can make the histograms same as before with this.

root -l ../../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")
.L ../sort_codes/Utils.C
listDraws()
xfxn()

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-09-17T19:53:32Z

Crhoffman: /* ISS Experiments */

=Specific Instructions for Experiments=
==ISS Experiments==

* ELOG [https://isolde-elog.web.cern.ch/iss/]

===iss000-development, mg28 [Sharp, 09/2018], hg206 [Kay, 10/2018]===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ (local) Computer (anldaqrouter):'''
First go to the working analysis directory, then start sorting process on run of interest (ok to do this on run that is currently taking data). This will do a number of different things: 1) it will first run the GEBMerge program (GEBSort director) to combine and timesort all raw data and outputs to the merged file. Then it will run GEBSort (GEBSort directory) which is the event builder and outputs to a .root file. Finally, it runs the TSelector GeneralSort.C (sort_codes directory) which passes the raw data into the human-readable names, e.g., xf, xn, e, etc...A copy of this file is placed in the ../root_data/ director (gen_run#.root). The most recent gen.root file is also in the working directory.

gotoana (cd experiments/iss000/analysis)
cd working
./process_run_local.sh <RUNNUMBER>

The above process will continue to run until it is killed (Ctr-C). A good time to do this is when it says, XXX seconds until next sort...You can look at the gen_run#.root file manually at this point. Otherwise, you can run the following to generate a few pre-made histograms and canvases.

root -l ../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")

Then you have the filled histograms. You may also do the following for example after the Monitors.C has finished.

.L ../sort_codes/Utils.C
listDraws()

Will show some of the pre-made canvases and draw functions.

'''To sort data on the MAC Computer:'''

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-09-17T19:51:09Z

Crhoffman: /* iss000-development */

=Specific Instructions for Experiments=
==ISS Experiments==

* ELOG [https://isolde-elog.web.cern.ch/iss/]

===iss000-development===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ (local) Computer (anldaqrouter):'''
First go to the working analysis directory, then start sorting process on run of interest (ok to do this on run that is currently taking data). This will do a number of different things: 1) it will first run the GEBMerge program (GEBSort director) to combine and timesort all raw data and outputs to the merged file. Then it will run GEBSort (GEBSort directory) which is the event builder and outputs to a .root file. Finally, it runs the TSelector GeneralSort.C (sort_codes directory) which passes the raw data into the human-readable names, e.g., xf, xn, e, etc...A copy of this file is placed in the ../root_data/ director (gen_run#.root). The most recent gen.root file is also in the working directory.

gotoana (cd experiments/iss000/analysis)
cd working
./process_run_local.sh <RUNNUMBER>

The above process will continue to run until it is killed (Ctr-C). A good time to do this is when it says, XXX seconds until next sort...You can look at the gen_run#.root file manually at this point. Otherwise, you can run the following to generate a few pre-made histograms and canvases.

root -l ../root_data/gen_run#.root
gen_tree->Process("../sort_codes/Monitors.C++")

Then you have the filled histograms. You may also do the following for example after the Monitors.C has finished.

.L ../sort_codes/Utils.C
listDraws()

Will show some of the pre-made canvases and draw functions.

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-09-17T19:03:45Z

Crhoffman: /* ISS Experiments */

=Specific Instructions for Experiments=
==ISS Experiments==

* ELOG [https://isolde-elog.web.cern.ch/iss/]

===iss000-development===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-09-17T19:03:19Z

Crhoffman: /* iss000-development */

=Specific Instructions for Experiments=
==ISS Experiments==
===iss000-development===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]
* Video showing how to start a run and what the DAQ looks like when running can be found here [https://photos.app.goo.gl/432F2gAFMam76wor7]

'''Array High Voltage Control'''
* Video to show starting up the Si Array HV can be found here [https://photos.app.goo.gl/Rn9a3fRx1g2tvm748]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-30T14:59:01Z

Crhoffman: /* iss000-development */

=Specific Instructions for Experiments=
==ISS Experiments==
===iss000-development===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here :[[System use]] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-30T13:59:16Z

Crhoffman: /* iss000-development */

=Specific Instructions for Experiments=
==ISS Experiments==
===iss000-development===
'''DAQ Information'''
* Information on rebooting the DAQ can be found here [system use] and a video specific for the iss experiments is here [https://photos.app.goo.gl/saCAzZUWg3NkxaNS9]

'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-27T12:21:54Z

Crhoffman: /* iss000-development */

=Specific Instructions for Experiments=
==ISS Experiments==
===iss000-development===
'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (''helios @anldaqrouter'' std pswrd).
* MAC Computer - for analysis and remote login control of the DAQ Computer (''heliosdigios @anlanamac'' NOT std pswrd - lowercase name of device at ANL).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Locations

2018-08-27T10:09:47Z

Crhoffman: /* EPIC DATA BASE */

= Network Location Information =

Need a nice drawing of the network

= DAQ Computer =
The data acquisition computer for digital HELIOS sits behind a NAT box. The NAT box is located at
digios1.onenet
or
192.168.203.52

The actual digios computer sits at
192.168.1.2
on the LAN setup by the NAT box

= Nat Box =
The login for the cisco ([http://www.cisco.com/c/en/us/products/collateral/routers/rv180-vpn-router/c78-697397_data_sheet.html cisco data page]) is uname ''cisco'' and the gammasphere password
192.168.1.1
Notes on cisco setup:
net -> wan -> iPv4 -> static -> 192.168.203.52 -> default .1 -> DNS .1

IOC's are
192.168.1.2X
DAQ computer is
192.168.1.2

= Terminal Server =
[https://www.digi.com/pdf/prd_ts_portserverts816.pdf Portserver TS16 MEI]

Info? (2.6.23-431.5.1.el6.i686 (RH 4.4.7-3)
Login with ''root'' and gammasphere pswrd

telnet 192.168.1.3 200[1-X]

== Physical Locations and ID's of Digitizers / Routers / Triggers ==

Really need a few figures with labels / diagrams.

* Serial numbers of system hardware
* Board ID numbers for data processing
* IP address and names of modules

== EPICS DATA BASE ==
IOC boot command file
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme0X.HELIOS.cmd

Databases that are loaded
/global/devel/gretTop/9-22/dgsIoc/dbd/gretDet.dbd
/global/devel/gretTop/9-22/dgsIoc/db/dgsDigRegisters.template
/global/devel/gretTop/9-22/dgsIoc/db/asynDebug.template
/global/devel/gretTop/9-22/dgsIoc/db/dgsDigUser.template
/global/devel/gretTop/9-22/dgsIoc/db/daqCrate.template
/global/devel/gretTop/9-22/dgsIoc/db/onMon.template
/global/devel/gretTop/9-22/dgsIoc/db/gretVME.template
/global/devel/gretTop/9-22/dgsIoc/db/daqBoard.template
/global/devel/gretTop/9-22/dgsIoc/db/daqSegment.template
/global/devel/gretTop/9-22/dgsIoc/db/dgsGlobals_HELIOS_VME01.db

Some other locations:

startup = "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray"
putenv("ARCH=vxWorks-ppc604_long")
putenv("IOC=iocArray")
top = "/global/devel/gretTop/9-22/dgsIoc"
putenv("TOP=/global/devel/gretTop/9-22/dgsIoc")
topbin = "/global/devel/gretTop/9-22/dgsIoc/bin/vxWorks-ppc604_long"
sncseq = "/global/devel/supTop/31410/sncseq-2.0.12"
putenv("SNCSEQ=/global/devel/supTop/31410/sncseq-2.0.12")
sncseqbin = "/global/devel/supTop/31410/sncseq-2.0.12/bin/vxWorks-ppc604_long"
asyn = "/global/devel/synApps/asyn/asyn4-17"
putenv("ASYN=/global/devel/synApps/asyn/asyn4-17")
asynbin = "/global/devel/synApps/asyn/asyn4-17/bin/vxWorks-ppc604_long"
epics_base = "/global/devel/base/base-3.14.12.1"
putenv("EPICS_BASE=/global/devel/base/base-3.14.12.1")
epics_basebin = "/global/devel/base/base-3.14.12.1/bin/vxWorks-ppc604_long"
vxstats = "/global/devel/supTop/31410/vxStats"
putenv("VXSTATS=/global/devel/supTop/31410/vxStats")
vxstatsbin = "/global/devel/supTop/31410/vxStats/bin/vxWorks-ppc604_long"
gretvme = "/global/devel/gretTop/9-22/dgsIoc/../gretVME"
putenv("GRETVME=/global/devel/gretTop/9-22/dgsIoc/../gretVME")
gretvmebin = "/global/devel/gretTop/9-22/dgsIoc/../gretVME/bin/vxWorks-ppc604_long"
gretdig = "/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers"
putenv("GRETDIG=/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers")
gretdigbin = "/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers/bin/vxWorks-ppc604_long"
trigger = "/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers"
putenv("TRIGGER=/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers")
triggerbin = "/global/devel/gretTop/9-22/dgsIoc/../dgsDrivers/bin/vxWorks-ppc604_long"
gretdata = "/global/devel/gretTop/9-22/dgsIoc/../dgsData"
putenv("GRETDATA=/global/devel/gretTop/9-22/dgsIoc/../dgsData")
gretdatabin = "/global/devel/gretTop/9-22/dgsIoc/../dgsData/bin/vxWorks-ppc604_long"
autosaverestore = "/global/devel/supTop/31410/asr4"
putenv("AUTOSAVERESTORE=/global/devel/supTop/31410/asr4")
autosaverestorebin = "/global/devel/supTop/31410/asr4/bin/vxWorks-ppc604_long"

Experiments

2018-08-26T12:47:51Z

Crhoffman: /* Specific Instructions for Specific Experiments */

=Specific Instructions for Experiments=
==ISS Experiments==
===iss000-development===
'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (IP/LOGIN Info Needed).
* MAC Computer - for analysis and remote login control of the DAQ Computer (IP/LOGIN Info Needed).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-26T12:47:09Z

Crhoffman: /* iss000-development */

=Specific Instructions for Specific Experiments=
==ISS Experiments==
===iss000-development===
'''Computer Information'''
* DAQ Computer - linux box mounted in the daq crate for daq control. Sits under the NAT BOX (IP/LOGIN Info Needed).
* MAC Computer - for analysis and remote login control of the DAQ Computer (IP/LOGIN Info Needed).

'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

'''To start the daq Commander on the DAQ Computer:'''
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

'''To sort data on the DAQ Computer:'''

'''To sort data on the MAC Computer:'''

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-26T12:41:48Z

Crhoffman: /* iss000-development */

=Specific Instructions for Specific Experiments=
==ISS Experiments==
===iss000-development===
'''Software Information'''
* lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
* Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

To start the DAQ Commander:
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-26T12:41:07Z

Crhoffman: /* iss000-development */

=Specific Instructions for Specific Experiments=
==ISS Experiments==
===iss000-development===
'''Software Information'''
- lumped all software [daq control, sorting, monitoring, etc.] to a single git repo [https://github.com/calemhoffman/digios]
- Cloned versions of git repo on MAC at '''~/experiments/iss000''' and on DAQ at '''~/experiments/iss000'''

To start the DAQ Commander:
gotodaq (or cd ~/experiments/iss000/daq)
./helioscommander

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T21:57:49Z

Crhoffman:

=Specific Instructions for Specific Experiments=
==ISS Experiments==
===iss000-development===
'''Software Information'''
- lumped all software [daq control, sorting, monitoring, etc.] under single folder on repo [https://svn.inside.anl.gov/repos/helios/isolde/iss000]

===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T21:56:12Z

Crhoffman:

=Specific Instructions for Specific Experiments=
==ISS Experiments==
===iss000-development===

====Software Information====

- lump all software [daq control, sorting, monitoring, etc.] under single folder on repo

- Use the new inside repo [https://svn.inside.anl.gov/repos/helios/iss] or maybe a git repo
===iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018]===

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T21:55:17Z

Crhoffman:

=Specific Instructions for Specific Experiments=
=ISS Experiments=
== iss000-development, iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018] ==

===Software Information===

- lump all software [daq control, sorting, monitoring, etc.] under single folder on repo

- Use the new inside repo [https://svn.inside.anl.gov/repos/helios/iss] or maybe a git repo

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T21:54:52Z

Crhoffman: /* ISS Experiments */

=Specific Instructions for Specific Experiments=
=ISS Experiments=
== iss000-development, iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018] ==

=Software Information=

- lump all software [daq control, sorting, monitoring, etc.] under single folder on repo

- Use the new inside repo [https://svn.inside.anl.gov/repos/helios/iss] or maybe a git repo

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T14:44:58Z

Crhoffman: /* iss000-development, iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018] */

=Specific Instructions for Specific Experiments=
=ISS Experiments=
== iss000-development, iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018] ==
=Software Information=

- lump all software [daq control, sorting, monitoring, etc.] under single folder on repo

- Use the new inside repo [https://svn.inside.anl.gov/repos/helios/iss] or maybe a git repo

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

Experiments

2018-08-23T14:42:59Z

Crhoffman: /* Specific Instructions for Specific Experiments */

=Specific Instructions for Specific Experiments=
=ISS Experiments=
== iss000-development, iss001-mg28 [Sharp, 09/2018], iss002-hg206 [Kay, 10/2018] ==
=Software Locations

==h061_mg26 [McNeel, 3/2018]==

Analysis directory on the iMAC [gotoexp]
~/experiments/h061_mg26

===To process a run on the iMAC===
gotoexp ; cd working
./process_run.sh #

Where # is the run number of interest. This command will first pull the data from the DigiOS computer:
get_digios_data #
Then merge all data in a time-sorted fashion:
gebmerge.sh #
Then events are created based on the input file '''GEBSort.chat'''
gebsortmerged.sh #
The output file is '''run#.root'''. Finally, a general sort is carried out to map the data into the proper HELIOS parameters:
root -l ../root_data/run#.root
tree->Process("../codes/GeneralSort.C++")
or
root -l proccess_run.C(#,0)

The output file is '''gen.root''' which is copied to '''../root_data/gen_run#.root'''

To generate the monitor spectra, you can run:
root -l ../root_data/gen_run#.root
gen_tree->Process("../codes/Monitors.C++")

Note, that the GeneralSort.C and Monitors.C are located on the svn at
https://svn.anl.gov/repos/helios/DigiOS/SiDet/trunk

===A new branch for all of the DigiOS DAQ control software is here:===
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h061

===Data is stored locally on the DigiOS DAQ Computer at===
/media/DIGIOSDATA3/data/h061_mg26
and a copy will eventually be available on the iMAC at
~/experiments/h061_mg26/data

==H060_Pb208 [Kay, 3/2018]==
There is an ELOG.

New branch for all of the DigiOS stuff has been made.
https://svn.anl.gov/repos/helios/DigiOS/edm/branches/h060/

Local working directory on MAC
~/experiments/h060_pb208

Data is saved on DigiOS
/media/DIGIOSDATA2/data/h060_pb208

==H057_He6 [Chen, 8/2017]==
'''To Do List'''

* Needs for beam testing
** Control of the digitizer channels for setting threshold, trigger, etc
** A way to quickly process and view the data for beam tuning [online, offline, etc]

* Needs for experiment
** Mapping of the signals [new more simple map?]
** Look into data readout
** Better online monitors
** Fix for GEBSort_nogeb on MAC

'''Locations'''

daq control - /global/devel/systems/helios/h057
data - /media/Digios Data/data/h057_he6

'''Take Data'''

In the directory that you would like the data to be saved on the digios daq computer, execute:
start_digios_run <run #>

stop_digios

'''Move Data'''
In the directory you want to put the data on the MAC computer
get_digios_data <run #>

'''Sorting Data'''

sorting the root file uses codes located in ''svn.anl.gov/repos/DigiOS/SiDet/trunk''

==H054_F21 [Chen, Hoffman, 4/2017]==

'''Locations'''

'''Sorting the data'''
* cp data from digios1 daq computer location ''/media/Digios Data/data/h054_f21'' to malaguena data location ''/music/helios2/H054_F21/digios/data''
# ''cd /music/helios2/H054_F21/digios/data''
# '''rsync --progress --protect-args --size-only -avzPe ssh "dgs@digios1:/media/Digios Data/data/h054_f21/h054*" .''' [NOTE: not sure this gives you the fastest transfer speeds CRH 8/17]
* merge data files from malaguena working directory ''/music/helios2/H054_F21/digios/working''
# '''./gebmerge.sh RUNNUMBER'''
* sort the data files from malaguena working directory
# '''./gebsortmerged.sh RUNNUMBER'''
* generate general root file from malaguena working directory
# '''root -l ../root_data/h054_runRUNNUMBER.root'''
# '''tree->Process("../codes_trunk/GeneralSort.C+")'''
# creates '''gen.root''' file in working directory
* generate ''Monitor'' histograms from malaguena working directory
# ''root -l gen.root''
# ''gen_tree->Process("../codes_trunk/Monitors.C+")''

System testing

2018-07-18T17:04:47Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[digiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300
#auth users = helios,dgs
#secrets file = /etc/rsyncd.secrets -> promted for psswrd for some reason??

pid file: The process id file the daemon uses.
lock file: The daemon lock file.
log file: The location of the log file.
port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.
[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.
path: The file path for files associated with this module.
comment: Descriptive comment for this module.
read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.
timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.
This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

4) Transfer data (syncing!) - remove --delete for copying only.
rsync -rtuh --delete --progress rsync://root@192.168.1.2:12000/digiosdata .

5) Adding users and psswrds [helios username seemed to work without changing .conf file so will not mod at this point.]
Need users to ''start'' daemon i think. Added to the .conf file above -> did not allow starting of daemon by user [helios], kept prompting for psswrd so removed it.

6) setting up some automation
bash file ''sync_data.sh'' in working keeps mirror at 5 second interval...add to cron?

#!/bin/bash
ATTEMPTS=0

while [ "${ATTEMPTS}" -lt "100" ];
do
rsync -rtuh --delete --progress rsync://helios@192.168.1.2:12000/digiosdata /Users/heliosdigios/experiments/infl001_19O/data/.
ATTEMPTS=$(expr ${ATTEMPTS} + 1)
sleep 5
done

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:55:59Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[digiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300
auth users = helios,dgs
secrets file = /etc/rsyncd.secrets

pid file: The process id file the daemon uses.
lock file: The daemon lock file.
log file: The location of the log file.
port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.
[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.
path: The file path for files associated with this module.
comment: Descriptive comment for this module.
read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.
timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.
This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

4) Transfer data (syncing!) - remove --delete for copying only.
rsync -rtuh --delete --progress rsync://root@192.168.1.2:12000/digiosdata .

5) Adding users and psswrds [helios username seemed to work without changing .conf file so will not mod at this point.]
Need users to ''start'' daemon i think. Added to the .conf file above -> did not allow starting of daemon by user [helios]

6) setting up some automation
bash file ''sync_data.sh'' in working keeps mirror at 5 second interval...add to cron?

#!/bin/bash
ATTEMPTS=0

while [ "${ATTEMPTS}" -lt "100" ];
do
rsync -rtuh --delete --progress rsync://helios@192.168.1.2:12000/digiosdata /Users/heliosdigios/experiments/infl001_19O/data/.
ATTEMPTS=$(expr ${ATTEMPTS} + 1)
sleep 5
done

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:49:13Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[digiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.
lock file: The daemon lock file.
log file: The location of the log file.
port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.
[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.
path: The file path for files associated with this module.
comment: Descriptive comment for this module.
read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.
timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.
This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

4) Transfer data (syncing!) - remove --delete for copying only.
rsync -rtuh --delete --progress rsync://root@192.168.1.2:12000/digiosdata .

5) Adding users and psswrds [helios username seemed to work without changing .conf file so will not mod at this point.]

6) setting up some automation
bash file ''sync_data.sh'' in working keeps mirror at 5 second interval...add to cron?

#!/bin/bash
ATTEMPTS=0

while [ "${ATTEMPTS}" -lt "100" ];
do
rsync -rtuh --delete --progress rsync://helios@192.168.1.2:12000/digiosdata /Users/heliosdigios/experiments/infl001_19O/data/.
ATTEMPTS=$(expr ${ATTEMPTS} + 1)
sleep 5
done

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:27:55Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[digiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.
lock file: The daemon lock file.
log file: The location of the log file.
port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.
[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.
path: The file path for files associated with this module.
comment: Descriptive comment for this module.
read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.
timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.
This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

4) Transfer data (syncing!) - remove --delete for copying only.
rsync -rtuh --delete --progress rsync://root@192.168.1.2:12000/digiosdata .

5) Adding users and psswrds

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:10:54Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[diigiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.
lock file: The daemon lock file.
log file: The location of the log file.
port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.
[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.
path: The file path for files associated with this module.
comment: Descriptive comment for this module.
read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.
timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.
This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:10:28Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[diigiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.

lock file: The daemon lock file.

log file: The location of the log file.

port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.

[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.

path: The file path for files associated with this module.

comment: Descriptive comment for this module.

read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.

timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.

This is just a basic configuration. For a more detailed list of options, see the manual page.

3) Start Daemon
[root@digios1 ~]# rsync --daemon
[root@digios1 ~]# ps x | grep rsync
21494 ? Ss 0:00 rsync --daemon
21496 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]# kill `cat /var/run/rsyncd.pid`
[root@digios1 ~]# ps x | grep rsync
21509 pts/10 S+ 0:00 grep rsync
[root@digios1 ~]#

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:08:12Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[diigiosdata]
path = /media/DIGIOSDATA2/data/infl001
comment = RSYNC DATA FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.

lock file: The daemon lock file.

log file: The location of the log file.

port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.

[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.

path: The file path for files associated with this module.

comment: Descriptive comment for this module.

read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.

timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.

This is just a basic configuration. For a more detailed list of options, see the manual page.

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:04:43Z

Crhoffman: /* RSYNC daemon for mirror [MAC] */

Now that we have a working system and Digitizer Tester, we need to learn and test the attributes of the system. To do this, a list of possible test needs are below. These should be organized and the work divided for people to gain experience as well.

=Developments underway=

==RSYNC daemon for mirror [MAC]==

Trying to mirror between data disk and the mac via an rsync server...

1) create the configuration file /etc/rsyncd.conf

2) Setup rsyncd.conf file
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[files]
path = /home/public_rsync
comment = RSYNC FILES
read only = true
timeout = 300

pid file: The process id file the daemon uses.

lock file: The daemon lock file.

log file: The location of the log file.

port: If you do not want the rsync daemon to run on its default port (873) then you may specify a new port here. Make sure this port is open in your firewall. Rsync uses the TCP protocol for its transfers.

[files]: This is the module name. The name used here is what you’ll be putting in the rsync pull command as the first part of the source (/files/../..). You can name it what you’d like and can have as many as you’d like.

path: The file path for files associated with this module.

comment: Descriptive comment for this module.

read only: This tells the daemon the directory for this module is read-only. You cannot upload to it. For upload only, use upload only = true.

timeout: Time, in seconds, the rsync daemon will wait before terminating a dead conenction.

This is just a basic configuration. For a more detailed list of options, see the manual page.

==Universal Python Scripts==
Did not work because unsure about which csv is correct and also the difference between master and slave digitzers was not defined...
Working with python scripts to develop universal and clean generation of cmd's, db's, templates, drivers etc. At the same time, trying to understand where and when all HELIOS files are / come from. So far, I have changed:
/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray
vme0*.HELIOS.cmd
setup a co of the /output/ svn inside of the above directory just for the '''.cmd''' and '''cdCommands_HELIOS''' files

and (but in some strange place that does not seem to be called by the .cmd's). So also trying to put them
/global/devel/gretTop/9-22/dgsIoc/db
dgsGlobals_HELIOS_VME0*.db
dgsGlobals_HELIOS_GLBL.db
setup a co of the /output/ svn inside here as well for only the '''dgsGlobals_HELIOS*.db''' files

Not sure which '''.csv''' file to use. Notice a diff in 20160602 to 201611XX of the MasterDigitizerRegisterMap.csv (but not the MDRM.csv) ??
Try the 20160602 one...?? Seems to match what was done it the 20160602 but '''db''' files do not match what was currently on the DIGIOS disk.
Will have to try it and see...

On the local digios1 daq (with the development HD in place).

Look into templates, other db, etc.!!

=List of tests to perform=

No particular order at this point just vomiting ideas...

* Data collection:
:i) single channel ii) multiple channels iii) HELIOS-like input data to multiple channels iv) across a number of digitizers
* Data processing:
:i) GEBMerge and GEBSort tests ii) simple data processing framework iii) online??
* Full feature tests:
:i) GammaWare buttons do what they are supposed to and are ''understood'' ii) equivalent epics commands are identified and tested iii) '''Bug Reports'''
* Trigger tests:
:i) how to implement trigger system tests into data ii) HELIOS-like multi-channel input tests
* Rate tests:
:i) trigger and channel rate tests of both low and high rate data ii) data throughput checks and ''throttle'' checks iii) total disk space usage for ''typical'' experiment

:
'''TRACES'''
Trace EDM window plots DAQ$(CR)_CS_Trace where CR = VME# (1,2,3....)

Values for TraceBd, TraceLen, TraceChan, etc set in screen, where are these in a file? Start search:

cd "/global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/"

System testing

2018-07-18T16:01:01Z

Crhoffman:

System testing

2018-07-18T16:00:03Z

Crhoffman:

System testing

2018-05-23T19:48:41Z

Crhoffman: /* Developments underway */

System testing

2018-05-23T19:31:01Z

Crhoffman: /* Developments underway */

System testing

2018-05-23T16:36:03Z

Crhoffman: /* Developments underway */

System testing

2018-05-23T16:09:54Z

Crhoffman: /* Developments underway */

System testing

2018-05-23T16:07:30Z

Crhoffman: /* Developments underway */

System testing

2018-05-22T23:49:22Z

Crhoffman: /* Developments underway */

System testing

2018-05-22T23:48:59Z

Crhoffman:

VME99 test stand IOC

2018-05-21T15:53:03Z

Crhoffman: /* VME99 */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

The IOC has been flashed with the most recent BSP file (devel7) and has been given in IP address on ONENET
192.168.203.211

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18. (completed)

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details. HOWTO: ''pycd'' on ''dgs1'', a number of ''build directories'' are there, '''genSystem.py''' is the main program.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]: JTA and WJ working on this on CON5. Located, now looking for a simple Makefile that is ''flat''. '''/global/devel/gretTop/9-22/dgsDrivers/Makefile'''

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

===relevant documentation that is elsewhere ===

https://wiki.anl.gov/gsdaq/The_DGS/DFMA_EPICS_Implementation

https://wiki.anl.gov/gsdaq/Tim_Madden_software_documentation

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

HELIOS IOC Settings

2018-05-15T16:43:41Z

Crhoffman: /* Status of HELIOS IOCs */

=Status of HELIOS IOCs=

ioc1 - 192.168.1.20:ffffff00 
S/N: E116D1A 
Flashed with new Bootrom. 
boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.20:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ##########
flags (f) : 0x0
target name (tn) : ioc1
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme01.HELIOS.cmd

ioc2 - 192.168.1.21:ffffff00 
S/N: E116DC9 (Actually, E116DC5 - SAK 5/30) 
Flashed with new Bootrom. 
boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.21:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ##########
flags (f) : 0x0
target name (tn) : ioc2
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme02.HELIOS.cmd

S/N: E116DD7
flashed with bootrom following instructions on hardware page - vme03.HELIOS.cmd boot script created following
template from vme02.DFMA.cmd and vme03.DFMA.cmd for 4 digitizers. The IOC boots from vxWorks, however, whether or not the digitizers are properly configured has not been tested. -SAK 05/30/2016

boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.22:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : #########
flags (f) : 0x0
target name (tn) : ioc3
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme03.HELIOS.cmd

S/N: E116D27
flashed with bootrom
boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.23:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ###########
flags (f) : 0x0
target name (tn) : ioc4
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme04.HELIOS.cmd

S/N: E116DC9

boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.24:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ##########
flags (f) : 0x0
target name (tn) : ioc5
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme05.HELIOS.cmd

S/N: E116DAF

boot device : gei
unit number : 0
processor number : 0
host name : helios1
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.25:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ##########
flags (f) : 0x0
target name (tn) : ioc6
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme06.HELIOS.cmd

S/N: E116D26 -_ VME99 in F-Wing Test Stand
boot device : gei
unit number : 0
processor number : 0
host name : XXXX
file name : /global/devel/boot/mvme5500/vxWorks
inet on ethernet (e) : 192.168.1.XX:ffffff00
host inet (h) : 192.168.1.2
user (u) : dgs
ftp password (pw) : ##########
flags (f) : 0x0
target name (tn) : ioc99
startup script (s) : /global/devel/gretTop/9-22/dgsIoc/iocBoot/iocArray/vme99.cmd

VME99 test stand IOC

2018-05-07T20:11:47Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details. HOWTO: ''pycd'' on ''dgs1'', a number of ''build directories'' are there, '''genSystem.py''' is the main program.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]: JTA and WJ working on this on CON5. Located, now looking for a simple Makefile that is ''flat''. '''/global/devel/gretTop/9-22/dgsDrivers/Makefile'''

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

VME99 test stand IOC

2018-05-07T19:59:22Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details. HOWTO: ''pycd'' on ''dgs1'', a number of ''build directories'' are there, '''genSystem.py''' is the main program.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]: JTA and WJ working on this on CON5.

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

VME99 test stand IOC

2018-05-07T19:39:00Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details. HOWTO: ''pycd'' on ''dgs1'', a number of ''build directories'' are there, '''genSystem.py''' is the main program.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]: No progress here?

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

VME99 test stand IOC

2018-05-07T19:37:07Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details. HOWTO: ''pycd'' on ''dgs1'', a number of ''build directories'' are there, '''genSystem.py''' is the main program.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]:

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

VME99 test stand IOC

2018-05-07T19:30:38Z

Crhoffman: /* Hardware To Do */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

- Serial connect on the "new" linux machine (need root access)

-

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]:

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

==System configuration file concept==
We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of
<nowiki>
DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
</nowiki>

is what we foresee.

VME99 test stand IOC

2018-05-07T19:22:50Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to ''parse'' to read in, as a test. Seems simple but still some details.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]:

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

VME99 test stand IOC

2018-05-07T19:22:10Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

== VME99 ==

The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.

==Goals for VME99==

List of the issues or requested features that will be addressed by VME99.

1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point.
2) Gammaware working on LINUX / another machine
3) MTrigger Readout

Known issues brought up from past experiments:
*Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile.
*Code base does not properly flush digitizers at run stop.
*Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn’t.
*Code base as-is does not correctly read out data from triggers, only digitizers.
*Code base has “sort” and “copy” modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that “sort” mode is vestigial and should be removed.
*GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS).
*All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal “cheat sheet” setups in which they perform direct read/write cycles to specific registers by address using the “back door” access. These “cheat sheet” magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
*Version control is, well, out of control. DGS1 folder structure a mess.

JTA's less well-known issues:
*No support in system for A24/D16 VME transactions.
*No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags.
*No support in system for source-synchronous block transfer on backplane.
*No architectural support in system for any other kinds of modules other than ‘trigger’ or ‘digitizer’. Some support for two subtypes of ‘trigger’ (master and router) but no support for subtypes of ‘digitizer’ (master and slave).
*Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software “GammaWare” that doesn’t match current firmware.
*VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names.
*Due to manufacturer changes there are two EPICS “board support package” (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.

==Hardware To Do==
- Cable to setup a ''terminal'' without a terminal server. JTA will do this by end of 5/4/18.

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal

==Software To Do (most is in ppt file attached)==
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. '''genSystem.py''' (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

Now just need to ''parse'' to read in, as a test. Seems simple but still some details.

- Modify of the ''Makefile'' to only compile what is needed. Mike and JTA both looking at the ''Makefile''. - Update [5/7]:

- Best path forward? The '''correct path''' or '''simple path''' [start with '''correct path''']? Argument for the '''simple path''' is to get ''Gammaware'' working on linux?

==Powerpoint notes==

[[file:VME99_20180430.pptx]]

VME99 test stand IOC

2018-05-07T19:06:02Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

VME99 test stand IOC

2018-05-07T19:03:00Z

Crhoffman: /* Hardware To Do */

VME99 test stand IOC

2018-04-30T20:11:07Z

Crhoffman: /* Software To Do (most is in ppt file attached) */

VME99 test stand IOC

2018-04-30T20:08:55Z

Crhoffman: /* Powerpoint notes */