Pixel Trigger Procedures

 

How to log in to the User Interface

The PIT User Interface is now accessible from the same operator node that contains the SPD user interface.
  1. from the Start button go to PIT ON
  2. the PIT user interface (UI) opens automatically, log in with the "spd" username.  The detector is schematically reproduced and the color logic is the following:
- GREEN: READY - HS in ready state and included in the trigger logic
- BLUE: NOT REQUIRED - HS masked in the trigger logic (they can be both switched on or off)
- ORANGE: NOT LOCKED: HS not switched on but required from the trigger logic

If all the half staves required from the trigger logic are in ready state in the SPD, then the PIT general status is ready.

 

Open the FSM

  1. make sure that the panel displayed is the SPD_DCS, if not, go there from the menu on the left
  2. press the FSM button in the upper left corner of the UI
  3. take the control pressing the padlock and selecting "Take"

 

Open the log file

The log file of the Pixel Trigger is located in machine alispdpit1 (username apixel).  The path is the following:
/home/apixel/pitFed/pit.log
  1. open an XTerm and log to the machine:  ssh apixel@alispdpit1
  2. go to the folder pitFed and execute tail -f pit.log for live monitoring of the log file

 

Load the PIT configuration from the database

The PIT database contains 3 different set of data concerning
   - FIRMWARE: definition of the algorithms associated to the 10 outputs, and of their parameters
   - PARAMETERS OF ALGORITHMS: definition of the values of the algorithm parameters
   - MASKS: definition of the masked half-staves and chips
These 3 information can be trated separately.
  1. from the menu on the left open the PitFED, right click on "pitFedStatus" and open the panel
  2. go to the tab "Configuration", in the center of the panel you can see 3 buttons corresponding to the 3 different information stored in the database.  The most used one is the "Link DB Configuration", to retrieve or save the PIT masks; the principle of operation of the others are the same
  3. press on the button "Link DB Configuration", a new panel will open.  Press on the button "Select a Link Version" and choose one database version to load.  Then click on the button "Apply DB Version To The Hardware".

 

Exclude one half-stave or chip from the Link Configuration

  1. from the menu on the left open the PitFED, right click on "pitFedStatus", open the panel and go to the tab "Configuration"
  2. press on the button "Link DB Configuration", a new panel will open.  Press on the button "Select a Link Version" and choose one database version to load
  3. apply the desired changes: the chips included in the trigger logic are with a tick mark, the masked chips correspond to empty boxes
  4. click on the button "Apply data from panel to the hardware".    Eventually, when the changes are fully checked, create a new DB version by clicking on the button "Create new version from the hardware" 

 

 Set and read the output algorithms parameters

Refer to the Pixel Trigger page for the list of the algorithm parameters

  1. from the menu on the left open the PitFED, right click on "pitFedStatus", open the panel and go to the tab "Configuration".  On the left side of the panel there are two buttons to set a parameter of an algorithm (Set Algorithm Parameter) and to read it back (Get Algorithm Parameter)
  2. to set a parameter, write the algorithm selection number, write the parameter number and the desired value.  Press on the button "Set Algorithm Parameter"
  3. to read a parameter, write only the algorithm selection number and the parameter number.  Press on the button "Get Algorithm Parameter"

 

Check for noisy chips

  1. from the "PitFedStatus" panel go to the tab "Configuration"
  2. start and stop all the counters with the buttons "start all counters" and "stop all counters".  Wait at least 10 seconds between the two commands
  3. set an appropriate threshold (i.e. 50) and click on the button "find noisy chips".  Check the log underneath for the noisy chips
  4. eventually mask the single chips following the instructions on how to exclude one chip from the Link Configuration here

 

Check the phase alignment (of the data stream wrt the PIT timer)

  1. check the indicator "Check Phases" on the main PIT panel: it has to be green when the SPD is included in a run
  2. if the indicator is red the phases are not aligned
    1. go to the PIT_DCS main panel and click on "Restart Phases Service"
    2. if the "Check Phases" is still red, call the expert
  3. write an entry in the Logbook.

NOTE for the expert:  to determine which channel(s) is(are) not aligned, one can generate a report of phases by the pitFed issuing the command auto_check_phases in the advanced panel of the PitFED DCS GUI (or pressing the button "Auto Check Phases" on the Configuration tab. The report is produced in the log file, see instructions above to monitor the log file on alispdwn005 to read the phases report.

 

[FOR EXPERTS] How to restart the pitFed driver

NOTE: you see if the driver is stopped if you launch some commands and the indicator in the top right corner of the pixel trigger user interface remains grey

  1. open an XTerm and log to the machine:  ssh apixel@alispdpit1
  2. launch "./run_pitFed start"
  3. then from the User Interface load the last parameters and links configuration from the database (see Load the PIT configuration from the database)

 

[FOR EXPERTS] How to link the configuration version inside ACT

  1. click on FERO CC button (top right, with the tools icon)
  2. from the Detector menu choose PIT
  3. specify that a DB version can be considered as good (and linkable)
    1. click on "Allowable versions" and select the version that you want to link
    2. from the Subsystem menu choose Firmware, Firmware parameters or Link configuration depending on the version you want to link. Usually it is Link configuration
    3. insert a Description and click on "Set version as allowable"
  4. now link this version to the correct run type
    1. click on "current versions"
    2. select the run type (usually PHYSICS) and click on Modify
    3. from the Subsystem menu choose Firmware, Firmware parameters or Link configuration. BE CAREFUL: in case the Link is modified remember to apply the changes for both the parameter values Defaule and CINT1_900
    4. select the version from the "Allowable versions" table and click on "Set as current version"
    5. exit from the panel and check with the refresh button that everything is correct

[FOR EXPERTS] RORC drivers / kernel incompatibility

  1. The physmem and rorc drivers, installed in the machines via RPM, only work with a specific version of the linux kernel. Each time there is a new kernel version, we need to prepare new RPMs. For the PIT machines, the drivers version is 2.6.32-431.17, the same as the kernel version at the time the machine was installed:

    [root@alidcscom351 ~]# rpm -qa | grep rorc-kernel-module
    mrorc-kernel-module-3.1.2-2.6.32_431.17.1.el6.x86_64.x86_64
    rorc-kernel-module-7.1.4-2.6.32_431.17.1.el6.x86_64.x86_64
    [root@alidcscom351 ~]# rpm -qa | grep physmem-kernel-module
    physmem-kernel-module-6.7-2.6.32_431.17.1.el6.x86_64.x86_64

    In the meantime, there was a kernel upgrade performed by YUM to version 2.6.32-431.20 (in fact two kernels were installed, but the latest -  2.6.32-431.23 - was never loaded because the machine didn't reboot since then). This breaks the compatibility with the drivers and therefore the RORCs are not detected any more.

    Solution:
    ============
    1) Disable SLC6 updates repository
    - edit /etc/yum.repos.d/slc6-updates.repo and, for the [slc6-updates] block, set the enabled parameter to zero.

    2) Change the default kernel to load at boot time (older kernel versions remain installed on the machine, so we can tell the linux boot loader, GRUB, to load the old correct kernel)
    - edit /etc/grub.conf and change the "default" parameter to 2 (this parameter specifies the index, starting from zero, of the kernel to load. In the PT machines there are 3 installed kernels - 23, 20 and 17 - so we want number 2: 17).

    3) reboot the machine