J. Kissel

I've made significant progress in the efforts to bring the HAM Auxliary Suspensions (HAUX) and HAM Tip-Tilt Suspension (HTTS) front end model infrastructure up to current SUS standards given the integrated testing experience thus far (as per ECR E1300578), focusing on the HTTS. Unfortunately, I'm unable to confirm success of the work I've done because what I've drawn in Simulink does not compile. Ah well. Stay tuned for further progress; details of today's work below. 

---------
Today I created a new front-end simulink model,
${userapps}/sus/h1/models/h1sushtts.mdl
which utilizes a 5 copies of the the brand new, combined, HAUX / HTTS master model called
${userapps}/sus/common/models/HSSS_MASTER.mdl
where HSSS stands for HAM Single-Stage Suspension.
This model (h1sushtts.mdl) will replace
${userapps}/asc/l1/models/h1asctt.mdl
but will continue to run on the ASC front end, h1asc0, on the same core (specific_cpu=4).

Because there is so much unique stuff in the HSSS that differs from the multi-stage suspension's 
${userapps}/sus/common/models/FOUROSEM_STAGE_MASTER.mdl
(e.g. alignment offsets, damping, shuttering) I've concluded that these optics should just be treated like every other multi-stage optic, where the "final" stage (in this case the only stage) is part of the over-all SUS-type library part, but not its own STAGE_MASTER. This renders all of these library parts obsolete:
${userapps}/sus/common/models/
FOUROSEM_DAMPED_STAGE_MASTER.mdl
FOUROSEM_DAMPED_ALIGNMENT_STAGE_MASTER.mdl
FOUROSEM_DAMPED_STAGE_MASTER_newOSC.mdl
FOUROSEM_DAMPED_STAGE_MASTER_oldOSC.mdl
because it contains damping loops, alignment offsets, and includes a lock-in in the manner similar to the rest of the SUS. The obsolete parts are various iterations of the original FOUROSEM master that reflect the history of the HSSS control system, created along the way to add all the new features that we now know we need today. Now that the HSSS master exists, which contains the best of all the above obsolete models, there's no need to keep these others around. I will delete them once I can confirm successful compilation of the models that use the HSSS master, and I've done all necessary modifications to the HSSS MEDM screens. 

Also of note, in addition to the HSSS library blocks for RM1, RM2, OM1, OM2, and OM3, I've created a new block called HTTS, which contains the stuff that uses combined information from all the optics, i.e. the Online detector characterization (ODC) channels, and the USER DACKILL. This way the stored ODC channel will be
$(IFO):SUS-HTTS_ODC_CHANNEL_OUT_DQ
which will look like all the other SUS ODC channels (with $(OPTIC) replacing HTTS), but reflects that the channel contains information about all of the five HTTSs. The only other thing in this block is the USERDACKILL, which also absorbs watchdog information from all 5 HTTSs, so the DACKILL channels will now be
$(IFO):SUS-HTTS_DACKILL_STATE
for example. This DACKILL "OR"s all the HTTS individual watchdog flags, so it's still the silly bad state of cascading a trip from HAM6 to HAM1 (or vice versa), but I'll leave changing watchdog systems for another day and another ECR that's not buried in otherwise janitorial engineering changes.

Finally, in addition to a TON of other clean-up and the relevant addition/modifications of all the features, described in G1301192, I've removed the HAM-A coil drivers voltage monitors from this main "control" model. Instead I've put them in another new front end simulink model,
${userapps}/sus/h1/models/h1susauxasc0.mdl
which will occupy the 6th and final, spare, core of the h1asc0 front end (specific_cpu=5), and use the (otherwise unused) DCUID of 22. In this way, the HTTS become like every other SUS where these non-essential coil-driver monitor signals are read out by a separate core, if not entirely separate IO chassis / front end (including the HAUX which already do have their VOLTMON signals in h1susauxh2.mdl).
This new "monitor" model contains a filter bank for each voltage monitor of all the HTTS (i.e. 4 x 5 = 20), 
$(IFO):SUS-$(OPTIC)_M1_VOLTMON_$(DOF)
of which the both the IN1 and OUT are stored in the commissioning frames (i.e. 40 new channels), but only the OUTs (which will presumably be calibrated) will be stored in the science frames (i.e. 2 channels). Both channels are to be stored at 256 [Hz] as most of the rest of the HSSS channels in the control model will be.

------------
Both models fail to compile, but I believe they're throwing bogus errors.
For h1sushtts, I get:
Bad DAQ channel name specified: 
OM3_M1_OSEMINF_UL_IN1
make[1]: *** [h1sushtts] Error 2
make: *** [h1sushtts] Error 1
make failed
log file is /opt/rtcds/lho/h1/data/buildlog/h1sushtts_2013_45_27_21:45:46
I'm not sure why it would fail on OM3, since this DAQ channel is listed in the same library part as the rest of the four HTTSs in the model.

and for h1susauxasc0, I get:
ADC card numbers must be unique
make[1]: *** [h1susauxasc0] Error 255
make: *** [h1susauxasc0] Error 1
make failed
log file is /opt/rtcds/lho/h1/data/buildlog/h1susauxasc0_2013_48_27_21:48:47
This I know is bogus, because the ADC cards are unique.