J. Kissel, B. Weaver Work Permit: #5880 FRS Ticket: #5489 Integration Issue: #FRS 5506 ECR: E1500045 Betsy and I've installed the individual coil driver switching of HSTS M3 stages as per documentation linked above. The front-end model changes were prepared and described yesterday (see LHO aLOG 27223), though note, we found some bugs and have to recompile again this morning (LHO aLOG 27239), after making the MEDM screen modifications described in the this log. We've made modifications to the following MEDM screens: /opt/rtcds/userapps/release/sus/common/medm/hxts/ M SUS_CUST_HSTS_OVERVIEW.adl <--- made CD STATE and TEST/COIL ENABLE settings and readbacks for each quadrant independent, and linked to new non-generic HSTS screens mentioned below and created new screens: /opt/rtcds/userapps/release/sus/common/medm/hxts/ ? SUS_CUST_HSTS_M3_EUL2OSEM.adl <--- used to be generic with all HXTSs, but now specific to HSTSs ? SUS_CUST_HSTS_BIO.adl <--- used to be generic with all HXTSs, but now specific to HSTSs and screen shots of each are attached. Unfortuanely, because the BIO settings and EUL2OSEM matrix elements are new channels for the M3 stage, one has to, by-hand, re-enter every suspension's - Requested coil driver state - The TEST/COIL ENABLE switch - The M3 EUL2OSEM matrix elements. and then hit "LOAD MATRIX" on all of the M3 EUL2OSEM matrices. We used Betsy's screenshot from last night to do this (from LHO aLOG 27225). We've also made our best attempt at updating the safe and down.snap files which had to have the former, ganged BIO channels replaced with the individual coil BIO channels. This required quite an SDF dance: 1) On SDF SAVE SCREEN for each SUS, - change SAVE TABLE to "EPICS DB TO FILE" in order to update the snap file with the new epics database channel list currently running with the new model - change FILE OPTIONS SELECTION to "OVERWRITE" in order do this with the currently loaded snap file - Hit SAVE FILE (We did this with every safe, down, or observe snap file for a given suspension) 2) On SDF RESTORE SCREEN for each SUS, - SELECT REQUEST FILE that you want to load in with the new updates - LOAD TABLE This should cleared out any of the channels with have disappeared from the model and create a bunch of new channels which are NOT INITitallized. Since keeping track of all of these channels and snap files was a bear, I don't promise that we've gotten everything right. We'll just have to keep an eye on them over the next few weeks to check if we've missed anything. Jenne's working on updating all Guardians that controlled the M3 stages of the HSTSs, and coding up the 3-coil-motion necessary for switching the coil state one at a time like is done on the beam splitter.
[TJ, Jenne]
We have modified the ISC guardians to handle the new coil driver switching capabilities.
In the DOWN state of ISC_DRMI, all of the optics for which we switch coils are switched back to their high range states.
I've re-written what was once the "BS M2 switch fast" script that guardian called, and incorporated it in a more general form in the ISC_library. The COIL_DRIVERS state now calls this function from the ISC library for each of the optics that need switching. I've tested it in the guardian shell for PRM, and the script behaved as expected (same recipe as has always been used for BS before), so it should all work nicely.
It's possible that we will find (by running them in parallel in guardian shells, for example) that we can do the coil switching on all of the optics in parallel while maintaining lock. If this is so, we may need to push the coil switching into the suspensions' guardians. But, for now, we leave this as "future work".
Thankfully I had forgotten to hit "load" for the ISC_LOCK guardian, because once we started the COIL_DRIVERS state, I realized that I had made poor choices for the matrix elements that get turned off before we switch the analog state for a coil.
What now happens (and I had forgotten to incorporate in the new HSTS coil driver switching) is that when one coil gets zeroed in the eul2osem matrix, a matching set of coils must be zeroed in each column of the matrix. For example, if I am zeroing LL, then in the length degree of freedom, I need to also zero UR, and have the LR and UL matrix elements twice as large as normal. This keeps the optic balanced, with the actuation strength roughly the same. For pitch, I need to zero UL, so that pitch control is only using LR and UR (with 2x larger matrix values) for the duration that LL is off. For yaw, I need to zero LR. Anyhow, this has now been fixed, and the fixed version of the code successfully ran for the PRM. Recall that PRM was often the lockloss culprit, so it was commented out of the previous version of the guardian.
So, I believe that with this one lock data point, we can say that the new coil driver switching ability has been a success.