Here are some screen captures of the HSTS BIO and EULER2OSEM matricies which we will be incorporated into new MEDM screens tomorrow.

J. Kissel, B. Weaver, [J. Betzwiser remotely]

As usual, we were only able to find bugs in the above SUS model changes for individual coil driver state switching after we'd finished making the MEDM screen modifications. 

After checking the coil driver compensation functionality after the model changes, we were immediately reminded that the STATE MACHINE logic for those HSTSs stages which have modified TACQ drivers is different from those stages without modification. The beam splitter M2 stage -- which we'd used as an example for the new infrastructure -- which uses an unmodified TACQ driver, where as the recycling-cavity HSTS's (PRM PR2 SRM and SR2 -- at H1 at least) have both their M2 and M3 TACQ drivers modified for extra actuation range. Once we reminded ourselves which suspensions had which drivers modified, we found it best to create a new library part in the 
/opt/rtcds/userapps/release/sus/common/models/STATE_BIO_MASTER.mdl
library capable of individual coil state switching library that uses the correct compensation switching code for the modified driver. It's obscure, but it's as simple as copying over the existing INDIVIDUAL_CTRL block, then changing 
inline TACQ $SUS_SRC/CD_STATE_MACHINE.c
to
inline TACQ_M2 $SUS_SRC/CD_STATE_MACHINE.c
in each of the cdsFunctionCall block.

I've attached screenshots of the updated STATE_BIO_MASTER library and the innards of the parts inside. Note that I've 
- changed the names of the library blocks associated with the TACQ drivers at the top level to better differentiate between the differences. 
- made the inline function call visible under the cdsFunctionCall block (right-click > Properties ... > Block Annotation tab > double click on "Description" block property token to add to the list of things for annotation > hit OK) so that the difference in the code call is obvious without digging into the properties.

These new library blocks (and the renamed existing blocks for the unmodified driver) were hooked up to the HSTS master models according to their arrangement of TACQ driver modifications: [For H1 ONLY see E1400369 and E1200931]
HSTS_MASTER   MC1, MC3               No TACQ Driver Mods

MC_MASTER     MC2                    M2 stage driver modified

RC_MASTER     PRM, PR2, SRM, SR2     Both M2 and M3 stages modified

Also, for convenience, remember you can find details of the modification in L1200226, but in summary, the modified driver is a factor of 10 stronger than an unmodified driver (and there's no longer frequency response in the output impedance network, which is why the digital compensation has to change).
Also, also, the state machine diagrams that outline how the digital compensation works with the analog driver state can be found in T1100507

These updated models have been committed to the sus/common/models/ directory of the userapps repo, so one needs not do anything different than the above update instructions to receive the bug fix. Since the distinction between whether no, one, or two of an HSTS's TACQ drivers are modified is made at the top-level of the model, i.e. by which of the HSTS_, MC_, or RC_MASTER blocks are used, there shouldn't be a need to change any top-level stuff at LLO to receive this model update. Just update that sus/common/model/ corner of the repo, and recompile, re-install, and re-start.

Tega, Ross, Jim and Dave.

Detailed changes made to the PI models.
PI_MASTER:
1. Added OMC_PI_MODE library part.
2. Replicate the functionality of the "SUS_PI_DAMP" block in "SUS_PI_COMPUTE" and "ETM_DRIVER". 
3. Removed the down-conversion blocks from SUS_PI_DAMP to avoid unnecessary computation in the h1susitmpi model. 
4. Renamed OMC_PI as OMC_PI_DOWNCONV to better reflect functionality.
5. Rearranged the library parts so that Simulink blocks related to the OMC_DCPD are on the right whilst blocks that process the QPD data are on the left. 

h1susetmxpi:
1. Replace the ETMX_PI_DAMP block with the new library parts: SUS_PI_COMPUTE (block name: ETMX_PI_DAMP) and ETM_DRIVER (block name: ETMX_PI_ESD_DRIVER). 
2. Moved the down-conversion blocks out of ETMX_PI_DAMP into a single block at the top of the model.
3. Added OMC_DCPD data into the PI control path using a switch that takes either the processed signals from the QPDs (ETMX_PI_DAMP)  or the processed signals from the OMC_DCPDs(ETMX_PI_OMC_DAMP)". 

h1susetmypi:
1. Replace the ETMX_PI_DAMP block with the new library parts: SUS_PI_COMPUTE (block name: ETMY_PI_DAMP) and ETM_DRIVER (block name: ETMY_PI_ESD_DRIVER). 
2. Moved the down-conversion blocks out of ETMY_PI_DAMP into a single block at the top of the model.
3. Changes needed to process OMC data are on hold for now.

h1susitmpi:
1. Updated the links for ITMX_PI_DAMP and ITMY_PI_DAMP blocks to the new library part: SUS_PI_COMPUTE.

The attached images show the before & after snapshots for each model.

Rebooting the entire guardian machine just because one node was having a problem seems like extreme overkill to me.  I would not recommend that as a solution, since obviously it kills all other guardian processes, causing them to loose their state and current channel connections.  I don't see any reason to disturb the other nodes because one is having trouble.  Any problem that would supposedly be fixed by rebooting the machine should also be fixed by just kill and restarting the affected node process.

The actual problem with the node is not specified, but the only issue I know of that would cause a node to become unresponsive and immune to a simple "guardctrl restart" is the EPICS mutex thread lock issue, which has been reported both at LLO and LHO, and both with solutions that don't require rebooting the entire machine.  Presumably the issue being reported here is somehow different?  It would be good to have a better description of what exactly the problem was.

Restarted the IOC.

Diagonal pressure continues to trend down

*CP3 Dewar fill from Norco truck tomorrow

Looking at the data from the various flow sensors, maybe, just maybe, the problem is with the flow sensor attached
to the auxiliary circuit (which monitors flows to the power meters ...).  The attached plot seems to imply that the
flow to the power meters dropped before the crystal chiller flow declined.

    Would need to check that the power meters are really attached to this part of the cooling circuit because the
diode chiller was running this morning.

For reference the cooling system information is under
https://dcc.ligo.org/DocDB/0067/T1100373/002/LIGO-T1100373-v2%20Coolant%20system%20operating%20and%20maintenance%20manual.pdf

Temp induced

CP3 Dewar is being filled this Tuesday so LLCV may need to be lowered again.

Is the DAC spectrum post-switch using up a large fraction of the range? If the noise in the PRC loop has change a little bit it could make this transition less risky.

Here's the PRM drive from last night's lock, in which we just skipped the PRM M3 BIO switching leaving the low pass off (BIO state 1). It seems like we should have plenty of room to turn the low pass on without saturating the DAQ.  

FRS Ticket #5489 closed in favor of a long-term fix Integration Issue #5506 (which is now also in the FRS system) and for an eventual ECR. Work permit #5880 indicates we'll install the fix tomorrow. See LHO aLOG 27223.