Reports until 17:56, Saturday 11 February 2012
H2 DAQ
david.barker@LIGO.ORG - posted 17:56, Saturday 11 February 2012 - last comment - 16:13, Monday 13 February 2012(2209)
LHO DAQ upgrade to RCG-2.4.1

Rolf, Alex, Dave.

We upgraded LHO from RCG-2.3.1 to RCG-2.4.1 today. All systems were burtrestored using the supplied safe.snap files, or from the autoburt of 9am this morning. H2 systems were not activated beyond doing the burt restores (watchdogs left tripped, etc.).

The problem of some cores running long was investigated. All front ends were configured to new advanced bios settings. This appears to have fixed the run-long problem, we will continue to check this over the weekend.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 07:22, Monday 13 February 2012 (2210)
Discovered H2 SUS ETMY had not been BURT restored after this upgrade. The BURT file, using
/opt/rtcds/userapps/release/sus/burtfiles/etmy/h2susetmy_safe.snap (NOTE THE CHANGE OF LOCATION OF CDS USERAPPS REPO!!) 
gave a red, "NOT OK!" message upon restore, but from the looks of the error log and looking over the system, I think it's an issue with BURT file formatting upgrade, not that anything got improperly restored. After the restore, I can comfirm that the DAQ is functional -- I'm taking first set of Transfer Functions after upgrade now, I can (1) open DTT, (2) use it to send out excitations, (3) read back (in the present) _DQ channels.

From prior discussions with D. Barker, R. Bork, and M. Landry, I'm 80% confident that h2susetmy's *was not* changed in this upgrade, where h2susitmy and h2susfmy's models were. I mention this because I was worried that the BIO (Binary Input/Output; completely different from the bios the Dave mentions above) would have lost its functionality -- therefore inhibiting drive (that pesky "test/coil" switch). Will provide more details in later aLOGs when I know more.
jeffrey.kissel@LIGO.ORG - 13:18, Monday 13 February 2012 (2217)
In BSC8, I'd found the H2 SUS FMY also needed a BURT restore. I've restored this suspension using
${userapps}/release/sus/h2/burtfiles/fmy/h2susfmy_safe.snap

However, because we've upgraded our Binary I/O interface in the RCG 2.4 version of the Simulink masters models,

${userapps}/branches/branch-2.4/sus/common/models/QUAD_MASTER.mdl
${userapps}/branches/branch-2.4/sus/common/models/BSFM_MASTER.mdl

which is what was used to compile both H2 SUS ITMY (a QUAD) and H2 SUS FMY (a BSFM) (but NOT YET H2 SUS ETMY), and that upgrade includes the need for new MEDM screens, found in 
${userapps}/branches/branch-2.4/sus/common/medm/${optic}/SUS_CUST_${OPTIC}_BIO.adl
we need to make changes to 
/opt/rtcds/lho/h2/medm/SITEMAP.adl,
which is where the generic screens' hard coded variables live.

I have updated the paths for ITMY and FMY (both in the call to the OVERVIEW screen, as well as in the SUSDIR variable), but it still doesn't call the right screen. Unfortunately, without the right variables sent to the screen, opening the screen by itself just shows white channels -- a feature of the generic screens.

Debugging is in progress...
jeffrey.kissel@LIGO.ORG - 16:13, Monday 13 February 2012 (2219)
H2 SUS ITMY is now functional: the trick was that the 
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl
MEDM screen's link to the 
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl
was hard-coded to
/opt/rtcds/$(site)/$(ifo)/userapps/release/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl.

Once I corrected the button link, I was able to pull up the correct version of that screen, and change the coil driver State (H2:SUS-ITMY_BIO_M0_STATEREQ set to 1.0), and enable the coils (H2:SUS-ITMY_BIO_M0_CTENABLE set to 1.0). The attached TF shows that actuation works, and the dynamics haven't changed. 

One would expect that H2 SUS FMY has the same problem, but when I fixed his overview,
${userapps}/branch-2.4/sus/common/medm/bsfm/SUS_CUST_BSFM_OVERVIEW.adl
the *new* channels came up white, implying that they don't exist, or are broken in some way. I'm still waiting here from Dave whether he compiled FMY with the RCG2.4 version of the BSFM_MASTER. 
Non-image files attached to this comment