J. Kissel, D. Macleod Via the ODC Team's "internal status checking webpage," Duncan found that several ODC EPICs records that define good settings for the PCALX's hardware injection path were errantly all zeros. In short: I've fixed the problem and the ODC summary bit for PINJX is happy and green. ------------- Details of how I made the summary bit green: The subpage for PINJX shows three columns: "ini" "safe" and "current", and I *think* that the "ini" coulmn is what they want the value to be (reported in decimal), the "safe" is what the SDF system's safe.snap has stored, and "current" is the current EPICs value. These channels were "not monitored" in the SDF system, and the safe.snap file that the front end loads upon restart had them set to zero, so it's not surprising that no one noticed these had gone bad. However, given the recent rearrangement of the hardware injection path (see LHO aLOG 27383) the values listed in the "ini" column are also incorrect. The channels in question are H1:CAL-PINJX_ODC_HARDWARE_CTRL_EQ H1:CAL-PINJX_ODC_HARDWARE_GAIN_EQ H1:CAL-PINJX_ODC_CW_CTRL_EQ H1:CAL-PINJX_ODC_CW_GAIN_EQ H1:CAL-PINJX_ODC_TRANSIENT_CTRL_EQ H1:CAL-PINJX_ODC_TRANSIENT_GAIN_EQ H1:CAL-PINJX_ODC_CHANNEL_BITMASK After digging through the h1calex front-end model to figure out what these ODC channels listed on the web actually *are*, I found the following (see first two attachments for visual aide): - the three _GAIN_EQ records are compared against the *actual* gain of each of the three hardware injection filter banks (H1:CAL-PINJX_CW_GAIN, H1:CAL-PINJX_TRANSIENT_GAIN, H1:CAL-PINJX_HARDWARE_GAIN). These records are just standard decimal values, and since the filter bank gains are currently all +1.0, all of these records should be +1.0. - the H1:CAL-PINJX_ODC_CHANNEL_BITMASK is a binary bit-word that masks which of the ODC bits are used to determine the summary status bit. Of course you know, in EPICs, binary bitwords must be entered in as hexidecimal. Also you know that, in ODC Bit 0 is reserved for the summary, so the mask starts functioning at bit 1. Since there are 6 comparison channels that we want to inform the summary bit, we need six bits, so the value should be Bit# 6 5 4 3 2 1 0 Decimal Hex What Goes In EPICs H1:CAL-PINJX_ODC_CHANNEL_BITMASK 1 1 1 1 1 1 0 = 126 = 7e = 0x7e - the three _CTRL_EQ records are compared against the output of "CtrlOut" spigot of each of the three hardware injection filter banks, respectively, which cdsCtrlFilt2 filter modules. According to the doc text inside the CDS_PARTS.mdl library, this cdsCtrlFilt2 output is a 13-bit bitword indicative of the state of all switches in the filter module: FM1's status is the least significant bit (Bit 0), FM2 through FM10's status are Bits 1 through 9, and Bits 10, 11, and 12 are the input, offset, and output switch status respectively. Because the _CTRL_EQ records are bit-wise compared to the front end's bitword, the record's value must also be a binary bit word. So, here's the table to translates this mess for each of the three filter banks, given the current, correct status of these filter banks (see third attached screen shot). Bit# 13 12 11 10 09 08 07 06 05 04 03 02 01 Decimal Hex What Goes In EPICs H1:CAL-PINJX_ODC_HARDWARE_CTRL_EQ 1 0 1 0 0 0 0 0 0 0 0 0 0 = 5120 = 1400 = 0x1400 H1:CAL-PINJX_ODC_CW_CTRL_EQ 1 0 1 1 1 1 1 1 1 1 1 1 1 = 6143 = 17FF = 0x17ff H1:CAL-PINJX_ODC_TRANSIENT_CTRL_EQ 1 0 1 0 0 0 0 0 0 0 0 0 0 = 5120 = 1400 = 0x1400 Switch Name OT OF IN F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 All of the bits are now green, and the mask is lights are on as expected, and the summary bit is green. I've switched ON the monitoring of these channels in the SDF system, and accepted these new values. I trust that Duncan will update the ODC team's page such that the "ini" column is correct. I've also re-installed (and SDF monitored) all of the appropriate strings in each H1:CAL-PINJX_ODC_BITn channel (where n is the bit number from 0 to 13), as defined again by this ODC Team webpage. ------------- Critiques of this instantiation of ODC: - This ODC system is essential identically recreating the SDF system. There's really no need for this. The SDF system is required to be reconciled before going into any observational stretch, so if the hardware injection path's filter banks are monitored by the SDF system (and they are), then they by default confirmed to be correct every observation stretch. - If someone decides that this is worth keeping, - these EPICS records should be much more clearly labeled and explained on the ODC MEDM screen. - The actual output of the CtrlOut from each of the cdsFiltCtrl2 banks should be fed into an EPICs record as well. This way one can easily take the current value and copy it into the comparator, such that the novice doesn't have to go through the binary to EPICs hex translation game that I had to above.