...
I will provide here only those details and commands to run a scan. There may be minimal detail
of what is actually happening when you execute the commands but for the most part I leave such
description for later tutorials. The important lessons to learn from this are the tools required to
perform a given scan, which commands to execute and how/where to execute them. The aim is to
provide enough detail such that practically any user could perform these scans without expert supervision. Clearly some level of expertise is required to interpret the results of the scan and perform some higher level procedures.
Procedure
Logging in
Wiki Markup
We perform the scan remotely. That is we begin by opening a shell and logging into our SR1 account.
When we login to lxplus we should first be sure to issue the '-X' command so that ssh can then provide
X11 forwarding
> ssh \ -X lxplus.cern.ch \ -l \ [username\]
From lxplus we then do:
> ssh atlsr1.cern.ch
This should take us into the machine called 'analysis1'. There are machines such as 'control5' and and 'control4' and other SR1 machines
but for now let's just concentrate on getting things started. It is likely you will need to login to these other machine to compile code or perform
other operations. So once you have logged-on to analysis1 you should logon to control4:
> ssh control4
Checking out and compiling the code
...
From this subdirectory the following files will need to be changed:
./partitions/PixelEnv.data.xml
./partitions/Partition_Pixel.data.xml
./segments/Segment_PixelInfrastructure.data.xml
./sw/PixSW.data.xmlunmigrated-wiki-markup
It is important to change all of the instances of "pixeldaq" to be "\[username\]" for your directory. Also, one should change "PixelInfr" \ -> "PixelInfr_\[username\]". Instances of "PixelDD" should be changed to "PixelDD_\[username\]". There are certain caveats to this. One such caveat is that anything beginning with "Segment_" with PixelInfr in the statement should
NOT be changed to include the username.
Note: If not all of these have been changed suitably then one will have trouble successfully starting your infrastructure and initializing the ROD will fail.
In order to start the TDAQ infrastructure one should execute the following command. Normally,
I tend to store the command line in an executable file, which I call 'startdaq_infr'.unmigrated-wiki-markup
cat \ ~/startdaq_infr
setup_daq \ -i obk \ -i cdi \ -i logger PixelInfr_\[username\]
When the TDAQ partition is launched you should then be able to go through the execution of the various
commands:
Boot -> Initalize -> Config -> Start. Do all of these until everything is up and running in Run Control panel.unmigrated-wiki-markup
In order to control the partition, check that it is running, and ultimately kill it, the following two commands
will be of help:
How to check the current partition: ipc_ls
How to kill the started partition: pmg_kill_partition \ -p PixelInfr_\[username\]
Flashing the ROD
In order to ensure that the ROD which you want to test is using the version of the code you wish to test you have to flash
that executable (master binary) onto the ROD. There are a couple of scripts to make this easy for you. In order to do this, you first need to determine
which crate the ROD you are using is situated on. There are two choices crate0 and crate1. To make it simple, RODs 11, 15 and 20 are on crate0
and all of the rest (5,12,14,17,21) are on crate1. To flash crate0 you must login to the machine pixrcc04, and for crate1 access pixrcc03.
Once you have logged-on to either pixrcc04 or pixrcc03 you then cd to the following location: daq/RodDaq/RodUtils. From there you have to
execute two commands:
...
~/daq/Applications/Pixel/CalibrationConsole/Console
Then execute ./Console &
...
- Select TDAQ partition for PixelInfr_\[username\] \ -> make sure PixelInfr is also started since we need DDC service.
- Goto 'command tool' panel, right click to pop out the command menu. Select 'DIGITAL_TEST'. Select the 'Base tag' and 'latest revision', i.e. just click ok to start the scan.
...