HV Module Test Stand Program

The purpose of this page is to detail what will eventually be the standard operating procedure for testing HV modules in the PHENIX Experimental Hall.  A test area, equipped with two mainframes, terminals, and a rack for dummy loads, has be set up in PEH, adjacent to the counting house.    The main testing program, test_stand, and a few supplementary applications are run from this area.  On this page, file names are shown in italics and programs are shown in bold.

PROCEDURE

1. Determine which type of modules are being tested and acquire the appropriate dummy loads
2. Install a set of modules and hook them up to the dummy loads
3. Modify the config_file to match the new parameters
4. Configure, compile, and run generate.cc to develop a phhv.dat file from the config_file
5. Move the new phhv.dat to the proper Epics directory, and modify phhv.grp if required
6. Run gmake in the Epics directory to recompile the medm software
7. Check the status of the IOC crate controller
8. Run medm and record HV module statistics
9. Modify testing_procedures.cc to suit the current HV modules
10. Run gmake to recompile the changes
11. Move or delete the old testlog file
12. Run test_stand to test the modules
13. After ending the program, log the module test results
14. If necessary, run oocleanup
15. Either delete the test database using oodeletedb or merge it into the large database

Determine Module Type

• 1461/M006
• 1461/M104
• 1461/M100
• 1461/M410
• 1471
• 1461
• 1462
• 1468
• 1469
• 1469/M100

Install the Modules and Loads

1. When installing modules, make sure that each is firmly pressed into place, and makes the proper electrical connection.  The modules do not need to be screwed into place. The dummy loads are simply slid into one of the smaller rack's slots.
2. Once the modules are in place, they can be connected to the dummy loads.  Several cables were fabricated to make this connection.
3. Each module has a Hardware Voltage Limit and a potentiometer that controls the value of this limit.  Using a voltmeter, measure the value of this voltage limit on each module (the mainframe, but not the HV, needs to be on to make this measurement).  If necessary, change the value to match the system requirements.
4. Finally, note each module's serial number.

Modify the config_file

Currently, the module naming scheme uses the format B_hv_CH_#, where # is an ascending number.  This naming schme may can in the future.  The module types follow this format: 14##NMOD, where 14## is the module type, N is either a P (for positive polarity) or an N (for negative), and MOD is a set of three numbers which reference which modification number.  MOD is not present for some of the modules.
The serial numbers are recorded exactly as they appear on the back of the module.

List each module in the mainframe in ascending order, stating with slot 0.   Record the name, type and serial number.  Do not place a blank line at the end of the file.   You may wish to save the older version of the file; otherwise, replace it.

Configure and Run generate.cc

1. Open the generate.cc file in an editor and change the default values if necessary.  The default values are located at the beginning of the file; also, locate the section of code (between lines 102 and 326) that corresponds to the module type used and see if changes need to be made there as well.  Save the changes.
2. Compile the program with the command "CC -o generate generate.cc" if changes have been made.  The program is also compiled when gmake is run.
3. Run the program by typing "generate".  By default, the program looks for a file called config_file for input, and creates an output file called phhv.dat as output.  Different files can be indicated by using command line arguments:  "generate my.config mydat" looks for a file called my.config for input and outputs to a file called mydat.dat (note that the .dat extension is added by the program -- do not place it in the command line).

Move phhv.dat file to the Epics Directory

In addition, you may want to modify the phhv.grp file.  This is a small list of sub-groupings of the modules.  Currently, the modules all are collected into one group called TEC.  This file only affects the medm program and is not used by the test_stand program.

Run gmake in the Epics Directory

Check the Status of the IOC Crate Controller

In order to start the test program, the IOC must be booted and operating properly.  Once gmake has been run in the Epics directory, the IOC should be rebooted.  It is important that the mainframe be finished with its start-up sequence before the IOC is booted; otherwise the IOC becomes unpredictable.  Correct IOC operation can be checked by loging into the controller (using rsh) and checking to see that the mainframe control thread has been spawned.

If the IOC is having problems, it may be necessary to reboot it.  To reboot the IOC, either type Control-X from the rsh, or hit the reset switch on the controller.  The IOC should begin a boot procedure -- this can be viewed from the VT220 terminal (input channel B).  When it is finished, rsh back into the controller and type 'iocInit "sample.def"'.  Wait until you see that the mainframe process has been spawned.

Run medm

1. Run medm by typing "medm -x phhv.adl"
2. Check out the module settings, making sure that the values were intialized correctly.
3. Enable some of the channels.
4. After verifying that the mainframe coolant fans are on, turn on the HV.
5. Ramp up a few channels to operating voltage, and record the measured current.
6. Experiment, at your discretion, with a few of the medm features to make sure everything is operating properly.  One idea is to check that the channels can ramp down to zero when the HV is on and the channels are enabled.
7. The program should running, with the HV on, while the test_stand program is running.  Some test procedures in test_stand will fail if the HV is off when they are run.

Modify testing_procedures.cc

dMaxVoltage is the absolute value of the operating voltage of the test program.  The program holds the modules at this voltage during its long-term test.  This variable should be set to the expected operating voltage of the sub-system.  Do not include a negative if the system has negative polarity.

dDVoltage is a small (5-10% of full yield) voltage used in the Demand Voltage test.  That porcedure verifies that it can set the demand voltage to diferent values by setting each channel's demand voltage to this value and then setting each to twice this value.  This variable should be kept small (100 to 500 V).  Do not include a negative if the system has negative polarity.  Sometimes a channel will trip a voltage error if they try to ramp to a very low voltage -- such errors should be recorded as they are found.  The bad channels can continue to be tested by raising this variable beyond their trip level.

dTCSet is a variable used to reset the trip currents.  One procedure of the test program forces all the channels to have a current trip, to test the trip process.  This is done by setting the trip current below the normal current produced when the modules are connected to the dummy loads.  This variable should be set to less than 2/3 of the current measured previously.  Do not include a negative if using a negative polarity module.

dRange is the range of volts around the demand voltage that the program will accept as valid.  I.e., the program will not raise an error if the read voltage from a channel is between (Demand Voltage - dRange) and (Demand Voltage + dRange).  The default value is now 3 volts.

iLimit is the number of times a channel can trip during the long-term test before the program gives up trying to re-enable it.  Its default is 20.

iLTsleep is the number of seconds the program waits before re-examining the channels during the long-term test.  Its defualt is 600 (10 minutes).

Run gmake in the Test Program Directory

Move the testlog File

Run test_stand and Start the Test

Start the program by typing "test_stand config_file" (note:  the command might be slightly different, if the test program executable directory is not included in your path environment variable).  The program should be run in the same directory where the config_file is located.  When the program starts, it creates a new database in /export/software/oncs/db/; the federated database is held in /export/software/oncs/db/hv/.

At the "->" prompt, type "help" to get a list of available commands.  You can examine and change module variables from here.

At the "->" prompt, type "test" to enter the test routine sub-menu.  You can run a test procedure individually, or you can type "all" to run each procedure, one after the other.  If all the procedures are run, the program will execute each in order, and will stop if any of them raises an error.  The last procedure, testLongTerm, does not end until the user Control-C's out of it and ends the program.  The long-term test should be run for several hours (we have been using a minimum of four so far).

Log the Test Results

Run oocleanup

Deal with the Test Database

Remove a database by typing "oodeletedb -db databasename". Do not include the .TheDB.DB extension in the database name.  You can add the option "-force" to prevent  the program from asking you verify the deletion.  If the database file has be accidentally deleted, you can correct the catalog in the Federated database by typing "oodeletedb -catalogonly -db databasename".

The program that will merge the databases is under development, and will be part of the oodb_mgr utility.