Notes about MVD chaintest

The MVD chaintest currently uses the following hardware:

  • 1 MVD interface module crate + and external power supply which supplies power to the backplane ("+5V" only)
  • 1 Data Collection Interface Module (DCIM) prototype
  • 1 Timing and Control Interface Module (TCIM)
  • 1 homemade (by SangYeol Kim) VME board used for serial controls (in place of the Arcnet Interface module). Here is a schematic of this board, plus another board "fanout" board which allows it to talk to multiple power/comm boards. The fanout board is not used currently.
  • 1 mini-DAQ, with only the "transmitter" section being used.
  • 1 VME crate and associated power supply (on loan from Nevis)
  • 1 Data Collection Module (DCM)
  • 1 VME crate controller, exact model unknown, (on loan from Nevis)
  • 1 VME card called "Phenix par"
  • 1 MVD motherboard
  • 1 MVD power-comm board
  • 3 MultiChip Modules (MCM's) -- only two have been used in most tests
  • 1 MVD low-voltage crate and modules to supply power to the motherboard, power-comm board and MCMs
  • a NIM crate and a few NIM modules (including a pulser) to send level-1 triggers to the miniDAQ
  • assorted cables and optical fibers

    and the following computers:

  • 1 PC used to run miniDAQ
  • 1 PC used to control modules in interface module create (including downloading of Xilinx code in DCIM and MCMs along with serial data strings)
  • 1 hp-unix system whose disk is used (nfs mounted) by the VME crate controller. This computer is also used to do some processing on the output data.
  • The VME crate controller listed in the hardware section above is a computer, so it could be listed here instead

    and the following software:

  • minidaq software (LabWindows) from Miljko Bobrek to send timing and control signals to the TCIM
  • LabView software from SangYeol Kim to control the modules in the Interface create -- this code performs the serial data functions which will be done via Arcnet eventually.
  • VxWorks (?) software which runs on the VME create controller, I got this from Mickey Chiu and Jamie Nagle at Nevis. This software resides on the hp disk and writes output data files (prdf format) to the hp disk. This directory contains this software.
  • Some primitive software (C) programs which run on the hp to check the output data format. You can look at those programs in this directory.

    Here is a sketch of the setup:

    postscript

    Here are some instructions on how to run the whole system:

    1. Connect the glink fibers. These instructions assume "multiplexed mode", where the DCIM uses glink fibers 1,4,5 (counting from the top) to send out the data from the 6 input MCMs. Connect these fibers to inputs 2,3,4 (counting from the bottom) on the DCM.
    2. Turn everything on:
      a) computers
      b) VME crate
      c) minidaq
      d) IM crate
      e) LV supplies (switches 1 and 4 are used)
    3. Startup minidaq control program (called "glinktx test5")
      a) press the "arrow" button at the top left to start
      b) press "reset fifo"
      c) press "Load TC" and wait from 3 "empty" lights to change to "data", this takes about 2 minutes because the computer is so slow
      d) press TX data loop
    4. Startup chaintest program
      In the MCM section:
      a) set PC=1 and download Xilinx
      b) set MCM=1,2,3 (or higher if there are more MCMs) and press "send data" twice for each number.
      c) press MCM reset
      In the DCIM section:
      a) put it in "corr mode", "3 DCM", "non-zero supp", ADDR=30
      b) download xilinx
      c) configure
      d) check done MUX for 1...6
      e) check Glink MUXs for 1...6, in multiplexed mode only three of these actually check something, but I am not sure which are which -- so just check them all.
      In the TCIM section:
      a) serial
      b) configure
      c) check glink
    5. Run the DCM program:
      a) reboot crate controller by pressing the reset button (not necessary if you just turned it on)
      b) from a window on the hp,
      telnet mvdcc1
      or type on the dumb terminal we use as console for the crate controller
      c) start the dcm program
      dcm
      0 (interactive mode)
      0 (user mode)
      1 (configured crate)
      301 (read config file)
      config_file_mvd_dsp2.dat (configuration file)
      303 (initialize current config)
      304 (set in data-taking state)
      305 (start run)
      0 (0 means no limit on the number of events)
      data.dat (pick an output file name)
      turn on the pulser to trigger events
      306 (stop run)
    6. On another hp window, use the readprdf program to read the data file:
      cd /usr1/mvdonl/chain/Data/
      readprdf data.dat
      alternatively, you can "dump" the output to the screen in hex mode with:
      od -x data.dat

      Look here for a description of the DCIM output packet format.

      Results so far

      Look here for a report of progress sent out 18-Oct-99.

      Look here for a report of progress sent out 21-Oct-99.

      Here are misc other relevant email messages whch have not been translated to htl, but you can still read them if you want.

      Look here for a report of progress sent out 3-Dec-99 after the system was first able to accept large number of events.

      10-Dec-99: We are having problems somewhere in the system when 6 MCMs are used. The problems seem to be in the DCM or in the way we try to use it. If you look here you can look at some of the files taken from the directory where the vxworks startup script (which loads misc dcm software) is located. We use the file called start_script. Below that directory, is the directory (Data) containing some other key files, including config.dat which is the "configuration file" used to setup the DCMs. I attempted to extrapolate from a file setup for only one input fiber to config.dat, which expects three input fibers. Perhaps I did it wrong.

      I say the problems seem to be in the DCM because we switch the fibers carrying data from MCM 3+4 with the fiber for MCM 5+6, but the problem in the output did not move with the fiber -- it remained in the 5th packet of each event.

      For anybody able to read and understand prdf files, here is a sample prdf file with the problem I will describe below.

      The setup had
      MCM 1+2 --> Glink fiber 1, to DCM input 2 (input 1 doesn't work)
      MCM 5+6 --> Glink fiber 2, to DCM input 3
      MCM 3+4 --> Glink fiber 3, to DCM input 4.
      We run in duplex mode, send level-1 triggers, and readout data from the three fibers. The output goes to a prdf file.

      There are two problems:
      1) The packets are not (as far as I understand) self-describing. I think this is probably a problem (someday) for Miljko.
      2) The DCM input 4 does not seem to work (or we do not know how to use it). I think this is a problem for someone at Nevis.

      The first problem makes diagnosing the second problem harder. As far as I understand, the DCIM output packets (click here for the format) contain the DCIM number (set by jumpers on the DCIM) and and odd/even packet bit. However, each DCIM has three output fibers. The output information does not say which of the three fibers the packet comes from. Because the packets are not self-describing, understandinf the following problem is harder.

      I have inferred the order of the packets in the data file by a variety of tests. I think that the output prdf file has packets in the order: MCM1, 5, 3, (odd/even bit =0) then 2, 6, 4 (odd/even bit = 1). The order is scrambled (in this particular example) because I switched the MCM 3/4 and 5/6 Glink fibers into the DCIM. However, if you look in the example prdf file (you can do it with this C program or you can look at this output from the program which translates the sample prdf file to ascii and adds some labels) the output only contains 5 packets for each event -- you can tell this by looking at the event number. There are 4 packets which look correct, except there is some confusion about the odd/even bit, then the 5th packet contains nonsense. The 6th packet clearly comes from the next event. In summary, the second problem is that the 4th DCM input channel seems to put out one garbage packet instead of two valid packets. Are we doing something obviously wrong? When I switch two fibers into the DCIM, the problem seems to remain in the 5th output packet -- implying that the problem is in the DCM, not upstream of it.

      Comments and suggestions would be appreciated.

      updated 17-Dec-1999
      John Sullivan