CEM Source Issues

• Principles of Operation

• Current Status

• DAQ Needs

• Analysis Needs

• Manpower Needs

• Mechanical System
  • View of cable/source "bucket" loop

  • View of source motor, pulleys, and limit switches on open 45° end of central wedge

  • Picture of SOURCE_MONITOR output showing all 48 wedges being calibrated simultaneously

  • Note "chimney" wedge (05E) has two source drives: one just for the CEM and another just for the CHA. Will this require a whole extra VME cal card, or do we come up with some other solution?

• Connections to VME calibration card in central VME (VIPA) crate
  • Currently, a 34-conductor twist-and-flat cable came from back of RABBIT crate to a "PC auxiliary board" mounted on the inside of the kickplate for each wedge. This cable carried current to the source motor and read back whether the limit switches were shorted or not. If these are not too susceptible to noise, easiest solution is to simply put adapter on existing cable to VME transition card or directly to transition backplane connectors. Otherwise, individual solder connections for each condutor will need to be replaced on PC auxiliary board.

  • Two main sets of cables came out of the PC auxiliary board: one of seven conductors in a twelve-pin small Burndy connector to the source drive assembly and another eight cables of two conductors each in a three-pin small Burndy connector to the temperature probes. The latter will no longer be used in Run 2, but unless they impede installation there is no reason to remove them (and insurance might be good).

• Typically, we have had to do maintenance on source drives every oppurtunity that arches are pulled. Ideally, I would say no less than once every two years. Unfortunately, we went for much longer than this in Run 1B. By the end of Run 1, 12 out of 49 source drives had some problem that prevented some or all towers of that wedge from producing source peaks in either the CEM and/or the CHA. Typical problems were:
  • Tension on source cable from tensioning pulley was either too small or too high; either could cause source to stall, usually going around pulley entering or exiting either the CEM or CHA.
  • Dirt on cable or limit switches, or misalignment of limit switches caused limits to not be seen, or false limits to be generated.
  • Bad electrical connections, especially source inhibit cable connections.

• Source drives, cables, pulleys, geardrives were refurbished in Summer 1997 by Chris Houlk and Brendan Bevensee. Each was tested in place with battery as DC current source. Note this is a long way from a complete system test with a new VME cal card.

• One remaining problem: long portion of nylon-sheathed source cable has been stripped on wedge 19E; this stops motor going into E-M about halfway. Probably requires retying and restringing new source cable. Doesn't make sense to do this until source readout is available on this wedge.

The legacy archive VAX computer is b0cc06 on the b0 cluster. The programs in this section will have to be completely rewritten, minimally as Java interfaces to C routines in VRCs.

• Hardware
  • TSI functionalitiy to run sources at 0.67 cm/s and 5 Hz with 10 ms RC time constant (to mitigate cosmic ray spikes in current channel).

• Software
• SOURCE_STATUS: controlled and readback source motor and limit status in real-time. This package/program will need to talk to all VME cal cards simultaneously in its final incarnation. Run 1 version in SRC package on legacy VAX used FASTBUS calls to latch to control inhibits and single-word transfers via MXs to RABBIT crates. Integration with other packages would break new ground.
• SOURCE_MONITOR: display package/program to display source peaks in real-time while data-taking was occuring. Run 1 version in SRC package on legacy VAX used data from shared buffer in online DAQ computer using low-level calls (bypassing YBOS) to make readout sufficiently fast. Presumably, this should be easier with Java and TRYBOS. One useful addition, make printing easy.
• PISABOX set and readback of central PMT HVs via Pisabox distribution system. This will be used extensively in initial setting of gains from source results, so ease of use is important. Run 1 version was on B0SCCE using Jorway interface to CAMAC crates, on legacy VAX now?
• RUN_CONTROL: do we integrate above functions into RUN_CONTROL or have them run autonomously. Run type is just like data or D-mode pedastals, but should be seperate bank CEMC or CHAC (C for current), instead of CEMD or CHAD (D for data = charge) to avoid confusion.

• Database? Run 1 CDFDB system of CALIB database types worked naturally for source runs: CEM/SRC results in TMP area for individual source run results, average of good results from multiple TMP file in ACC area files, and those ACC files selected for modification of gains (CEM/LER) copied into SUM area.
• Analysis code to derive source peak values (Bob Wagner, Argonne) and average multiple runs for final calibration per tube at given time. Located in CEN_TASK and CEN_MANAGER packages on legacy VAX.

  It has been suggested this may be a perfect case of using legacy Fortran code, since this code is certainly not execution time-critical. However, the details of how to do this are the devil: how to we hook TRYBOS and ORACLE into existing code? Is this really easier than a complete rewrite?

• I've told Dong Hee Kim that I believe a 50% commitment for about 6 months of one post-doc (or better) and two grad students is necessary to completely bring up the system to an operational state for all source drives in all central wedges. This means a real 50%, so this should be that group's main activity for 6 months or longer (at a lower rate). If this effort also includes code for analysis, I think we'll be extremely fortunate.

• Unlike Run 1 (where we did not touch CEM HVs unless gain became very abnormal), Larry and I believe we should adapt the CHA methodology: modify CEM HVs to compensate for loss in gain in PMTs.

  Ultimately, the real gains comes from physics (E/p of Ws, Zs, and inclusive electrons), but we should attempt to make these "tweaks" as small and infrequent as possible by doing the above. We may find disagreement between physics and sources has become larger (this seemed to be the trend at the end of Run 1).

• We need detailed plan for how we initially set CEM PMT HVs from source peak values. Do we just pin to last Run 1 source values, or is there something more we can do?