aLIGO LHO Logbook

H1 SUS (CDS)

sheila.dwyer@LIGO.ORG - posted 19:34, Tuesday 19 July 2016 - last comment - 10:53, Wednesday 20 July 2016(28503)

making SDF a little easier to deal with

For all the suspensions for which the guardian sets the SDF file to down, I have changed the safe.snap to be a softlink to the down.snap in the userapps repository. This means we have one less sdf file to worry about maintaining for these suspensions. If anyone can do a similar job for the rest of the suspensions, (ie, make sure that safe.snap is a softlink to some file that gets maintained), things will be a little easier next time we restart all models.

Comments related to this report

matthew.evans@LIGO.ORG - 22:20, Tuesday 19 July 2016 (28504)CDS

Link

Along the same lines, I made a script which should allow us to right-click on a EPICs field and ask that it be accepted into the currently loaded SDF file.

This script is based on "instafoton.py" in /opt/rtcds/userapps/trunk/cds/utilities, with some help from create_fe_sdf_source_file_list.py (/opt/rtcds/userapps/trunk/cds/h1/scripts/). The idea is that it can be added to the MEDM drop-down menu like instafoton. The script is instaSDF.py in /opt/rtcds/userapps/trunk/cds/utilities (also attached).

The script works by changing the snap file which is currently loaded in SDF (as reported by the SDF_LOADED EPICs record, e.g. safe.snap), and then asking SDF to reload. As of this writing, the script is "toothless" in that it does not take the final steps to replace existing snap file or reload; the code required to do this is commented out.

To do:

have the CDS folks take a close look at instaSDF.py
uncomment the active lines, backup the target snap file, and test as in (e.g., instaSDF.py H1:SUS-ETMX_L3_LOCK_P_GAIN )
add an entry in the MEDM Execute menu (like instafoton)

Non-image files attached to this comment

instaSDF.py

betsy.weaver@LIGO.ORG - 09:19, Wednesday 20 July 2016 (28518)

Link

While I still don't follow why we went from wanting more SDF files at various states, including an all-sacred SAFE.snap, to now just wanting 1 file, with JK's instruction I made more soft links in sus burt files. I guess this takes off where Sheila left off, namely that for any SUS that was sitting on the OBSERVE file this morning during IFO DOWN, I set the safe.snap to be softlinked to the observe snap. So, none of the names that the SDF overview say that the SUSes are looking at are correct. Everything has a soft link to some other file.

Someone else will have to suggest what PI files are softlinked too, I didn't touch those.

The following list is the state of the situation. Good luck.

lrwxrwxrwx 1 controls     controls 67 Jan 13 2015 h1susauxasc0/h1susauxasc0epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxasc0_safe.snap
lrwxrwxrwx 1 controls     controls 67 Jan 13 2015 h1susauxb123/h1susauxb123epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxb123_safe.snap
lrwxrwxrwx 1 controls     controls 65 Jan 13 2015 h1susauxex/h1susauxexepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxex_safe.snap
lrwxrwxrwx 1 controls     controls 65 Jan 13 2015 h1susauxey/h1susauxeyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxey_safe.snap
lrwxrwxrwx 1 controls     controls 65 Jan 13 2015 h1susauxh2/h1susauxh2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxh2_safe.snap
lrwxrwxrwx 1 controls     controls 66 Jan 13 2015 h1susauxh34/h1susauxh34epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxh34_safe.snap
lrwxrwxrwx 1 controls     controls 66 Jan 9 2015 h1susauxh56/h1susauxh56epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susauxh56_safe.snap
lrwxrwxrwx 1 sheila.dwyer controls 62 Jul 19 19:00 h1susbs/h1susbsepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susbs_down.snap
lrwxrwxrwx 1 sheila.dwyer controls 64 Jul 19 19:22 h1susetmx/h1susetmxepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmx_down.snap
lrwxrwxrwx 1 controls     controls 66 Jul 27 2015 h1susetmxpi/h1susetmxpiepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmxpi_safe.snap
lrwxrwxrwx 1 sheila.dwyer controls 64 Jul 19 19:28 h1susetmy/h1susetmyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmy_down.snap
lrwxrwxrwx 1 controls     controls 66 Jul 27 2015 h1susetmypi/h1susetmypiepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmypi_safe.snap
lrwxrwxrwx 1 betsy.weaver controls 67 Jul 20 09:02 h1sushtts/h1sushttsepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_observe.snap
lrwxrwxrwx 1 betsy.weaver controls 65 Jul 20 09:03 h1susim/h1susimepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susim_observe.snap
lrwxrwxrwx 1 controls     controls 65 May 2 16:22 h1susitmpi/h1susitmpiepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmpi_safe.snap
lrwxrwxrwx 1 sheila.dwyer controls 64 Jul 19 19:02 h1susitmx/h1susitmxepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmx_down.snap
lrwxrwxrwx 1 sheila.dwyer controls 64 Jul 19 18:59 h1susitmy/h1susitmyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmy_down.snap
lrwxrwxrwx 1 betsy.weaver controls 66 Jul 20 09:05 h1susmc1/h1susmc1epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc1_observe.snap
lrwxrwxrwx 1 sheila.dwyer controls 63 Jul 19 19:06 h1susmc2/h1susmc2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_down.snap
lrwxrwxrwx 1 betsy.weaver controls 66 Jul 20 09:05 h1susmc3/h1susmc3epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc3_observe.snap
lrwxrwxrwx 1 betsy.weaver controls 66 Jul 20 08:55 h1susomc/h1susomcepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susomc_observe.snap
lrwxrwxrwx 1 sheila.dwyer controls 63 Jul 19 19:19 h1suspr2/h1suspr2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr2_down.snap
lrwxrwxrwx 1 sheila.dwyer controls 63 Jul 19 19:04 h1suspr3/h1suspr3epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr3_down.snap
lrwxrwxrwx 1 sheila.dwyer controls 63 Jul 19 19:03 h1susprm/h1susprmepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susprm_down.snap
lrwxrwxrwx 1 betsy.weaver controls 66 Jul 20 09:01 h1sussr2/h1sussr2epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussr2_observe.snap
lrwxrwxrwx 1 betsy.weaver controls 66 Jul 20 08:59 h1sussr3/h1sussr3epics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussr3_observe.snap
lrwxrwxrwx 1 sheila.dwyer controls 63 Jul 19 19:20 h1sussrm/h1sussrmepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussrm_down.snap
lrwxrwxrwx 1 betsy.weaver controls 67 Jul 20 09:14 h1sustmsx/h1sustmsxepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sustmsx_observe.snap
lrwxrwxrwx 1 betsy.weaver controls 67 Jul 20 09:15 h1sustmsy/h1sustmsyepics/burt/safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sustmsy_observe.snap

jeffrey.kissel@LIGO.ORG - 10:53, Wednesday 20 July 2016 (28524)CDS, GRD, SEI, SYS

Link

J. Kissel, B. Weaver, S. Dwyer

Note that this is a conscious paradigm shift regarding safe.snaps.

Since all SUS control models are pointing to either down.snaps or OBSERVE.snaps, there will be requested output when the front-end comes up from a reboot. HOWEVER, the SUS output will still be protected because the SUS USER model watchdog, (based on the SEI watchdog), by design comes up tripped, preventing all output. It requires human intervention to be untripped. Even if for some reason this user watchdog fails, we still have the IOP Software watchdog that is independently watching the SUS OSEMs adding another layer protection further preventing any unlikely hardware damage.

I recommend that SEI do this as well, and then they can reduce their number of files that need maintaining to one.

Why, then, do we have some SUS point to OBSERVE.snap, and others point to down.snap?
Those suspensions which *have* a down, are those suspensions manipulated by ISC and DRMI guardians (i.e. MC2, PRM, PR3, SRM, SR2, and all of the BSC SUS besides the TMTS). Thus, there is quite a bit of difference between their nominal low noise settings (i.e. OBSERVE) and their "lets start the lock acquisition sequence" settings (i.e. down).

These down.snaps were created only for these suspensions in order to have a limited enough scope that we got accomplished what needed accomplishing, when the settings for these suspensions were in question.

Thus, there remain OBSERVE.snaps for typically ISC untouched SUS (i.e. MC1, MC3, SR3, SR2, the IMs, OMs and RMs, the TMTS, and the OMC), because these were created for *every* front-end model prior to O1. Since we're more often in a low-noise-like state for these SUS than in the SAFE state, the OBSERVE files have been better maintained.

Note also that we're continuing to unmonitor channels and setting that are manipulated by guardian. Thus there should be a decreasing amount of DIFFs between any of these models' "ground" state and their nominal low noise state.

This comes at a price however -- if guardian code is changed, then those SDFs settings must be manually re-monitored, which is difficult at best to remember. Especially for the new filter module monitoring system where we have individual control over each button in the bank. Further, if there are settings which are not monitored that are regularly changed by operators (like alignment sliders) or things that occasionally get tuned by scripts (like A2L DRIVEALIGN matrix elements, or Transmon QPD offsets), then they have a potential for coming up wrong. Thus, as a part of "SDF reconciliation" before a planned reboot, we should look at all channel diffs, not just those that have been masked to be monitored.