PhATty_200x300.jpg (40539 bytes)VME Software

Outline:


How to Unpack VME Data from PhoRaw Files

The super module VMEUnpackSuperMod is used to unpack the VME data from a raw data file. Be sure to call each standard module function on this super module (StartAnalysis(), StartRun(), etc.).

This super module will place event data objects into the event for each sub-detector in the VME. Currently, this means it will put in the event a TPhSpecTrgEventData object, and two TPhPCALEventData objects (one for the PCAL and one for the PCAL's cosmic trigger). These event data objects will store the raw data in whatever way is appropriate for that sub-detector.

The super module contains the following modules:

  1. TPhVMEInitMod
  2. TPhVMEUnpackerMod

The super module is configured in $PHATHOME/macros/pcal/vme_unpack_setup.C

VME Unpacking Machinery Explained

The purpose of the VME software is to get the raw data from the DAQ files into a format that allows each sub-detector in the VME to easily access its data.

The unpacking scheme is different from that of the silicon and the fastbus. In the silicon detector, all signal processing is done for the entire silicon detector at once. In that case, it makes sense to use the TPhTopoData scheme to process the data in terms of electronics: FECs, strings, chips and channels. In the VME, each VME module could in principal belong to a completely separate sub-detector, so unpacking the raw data into a format which is organized by electronics does not make sense.

Thus, the goal of the VME unpacker is to get the data out of the TPhVMERawHit, where it is stored in the PhoRaw file, and into a class which is unique to each sub-detector.

This is accomplished by an abstract class, TPhVMESubDetEventData, from which any VME sub-detector's event data class must inherit. Each sub-detector's event data class must implement its own FillValueForChannel() function. This function is called by the unpacking module and allows each sub-detector to store the raw data value, given the row, column and VME data type (i.e. ADC, TDC, etc.), in whatever way is appropriate for that sub-detector.

Below is a flow chart of how this process occurs:

It's just that simple!

But let us go through each step anyway:

  1. During TPhVMEInitMod::StartRun(), the VME map is set up. It is either gotten from the database (default) or read in from a root file. After this has been run, the VME map can be accessed through TPhDetector::GetVMEMap().
  1. TPhVMEUnpackerMod gets the raw data, crate number, module number and channel number from the TPhVMERawHit object.
  2. TPhVMEUnpackerMod sends the create, module and channel number to the VME map.
  3. The VME map returns the corresponding row, column, data type sub-detector name, sensor name and (PMT) position to TPhVMEUnpackerMod.
  4. TPhVMEUnpackerMod looks for an existing TPhVMESubDetEventData object using the sub-detector name.
  5. If one is NOT found, TPhVMEUnpackerMod sends the sub-detector name to the static function TPhVMEDetector::NewSubDetEventDataFor(). Then the following happens:
  1. The name of the sub-detector's event data object is looked up in the static function TPhVMEDetector::GetSubDetEventDataNameFor(), according to the sub-detector's name.
  2. The number of rows and columns is looked up, according to sub-detector name, in the static function TPhVMEDetector::LookupSize().
  3. Using the sub-detector event data's name, the number of rows and the number of columns, the static function TPhVMEDetector::NewSubDetEventDataFor() calls new on the appropriate sub-detector's event data (i.e. TPhPCALEventData, TPhSpecTrgEventData, etc.) and returns a pointer to that TPhVMESubDetEventData.
  4. From now on in the channel loop (but not the event loop), when TPhVMEUnpackerMod looks for an event data object with this sub-detector's name, it will find the object that TPhVMEDetector just new-ed.
  1. (If no existing TPhVMESubDetEventData object was found for this sub-detector, TPhVMEDetector::NewSubDetEventDataFor() makes a new one as described above and returns it to TPhVMEUnpackerMod.)
  2. TPhVMEUnpackerMod sends the row, column, data type and raw data value to the TPhVMESubDetEventData.
  3. Through C++ inheritance magic, the sub-detector's event data object (i.e. TPhPCALEventData, TPhSpecTrgEventData, etc.) uses the row, column, data type to store the raw data value in whatever way is appropriate for that sub-detector.

This scheme allows all hard coding of sub-detector names, sizes and specific sub-detector event data objects to be neatly contained in TPhVMEDetector.h.


How to Add a New VME Sub-Detector in the Software

The system was designed to make this process as simple as possible.

  1. Make a class which inherits from TPhVMESubDetEventData. This class must implement the function:
    Bool_t FillValueForChannel(const Int_t& row, const Int_t& col, const EVMEDataType_t& type,
    UInt_t value)
    . Nothing else is required of the class, but you may find it useful to actually store the value in an array of some kind. A list of the possible data types can be found in the enum in TPhVMERawHit.h.
  2. Edit TPhVMEDetector.h. At the bottom of the file are the static functions that contain some hard-coded information about each sub-detector.
  3. Edit the VME map to add your sub-detector.

There are some useful values in the enum EVMEDescriptions of TPhVMEDetector.h. You should make note of these when creating a new sub-detector. Also please use these enums whenever possible to avoid hard-coding values.

That's all there is to it!


How to Chanage the VME Map

To change the VME map, you will need to edit the text file in $PHATHOME/init/VMEMap.txt. Each line in the text file describes one VME channel. The columns are:

  1      2      3            4          5     6       7          8          9
Crate Module Channel Sub-Detector-Name Row Column Data-Type Sensor-Name Position

The rules for adding a channel are:

Once the text file has been made, you can use the macro $PHAT2HOME/macros/pcal/pro/newmap.C to save the new map.

  1. .x $PHAT2HOME/macros/load_all_libs.C
  2. .L $PHAT2HOME/macros/pcal/pro/newmap.C+
    (notice that you should load it in compiled mode!)
  3. make a TDatime object that is the validity date of the new map (i.e. when the new map went into effect). For example:
    TDatime mdat(2009,3,2,15,30,0)
  4. newmap takes the following inputs:
    1. Text file name -- full directory with no environment variables! For example:
      "/phobos/u/cjreed/PhatII/init/VMEMap.txt"
    2. The validity date of the new map (see step 3). For example:
      mdat
    3. Comments describing the new map. For example:
      "VME Map for PR09 with the new spec trig walls"
    4. The operator (user) name. For example:
      "Reed"
  5. Execute the newmap function with the appropriate inputs.
  6. The macro will then read the map from the text file and print it out.
  7. Look over the map, make sure it is correct in both directions.
  8. You will be prompted to save the new map. Answering "y" will write the new map to the database and the $PHAT2HOME/init/VMEMap.root file.
  9. The new map should not overwrite the old map in the root file. To help you find a suitable name for the old map, the macro will ask if you want to print the old map.
  10. You will then be prompted for a name to give the old vme map. This name should NOT be "VMEMap". This is simply the name of the old vme map object file in the root file; it is not a full description. For example:
    "PR08VMEMapFinal"
  11. Quit root.
  12. cd $PHAT2HOME/init/
  13. cvs commit VMEMap.root VMEMap.txt