[JeffK, Jenne]

Jeff pointed out that the PI damping gain (if no changes were made to guardian) would now be 4x higher than they were throughout O4, due to the work done today.  See alog 88285 for the actual work by Jeff and Oli.  To account for this, the SUS_PI guardian now has a 1/4 in the gain setting line.

Details for remembering later:

In June 2020, we upgraded from 18-bit to 20-bit DACs, and as Jeff notes in alog 88285, we didn't have a place to nicely account for the effective gain change digitally in the PI damping path.  Effectively, we should have put in a filter with gain of 4x to account for the number of bits changed.  Since we didn't, we have been actuating PIs (assuming same digital gains) 4x less during O4 than we had been in O3.  Not a huge deal, since we had PI dampers and PI damping settings that were effective. 

With today's work, Jeff and Oli have put in a digital place to correctly account for the gain change with the new 28-bit DACs.  To keep the 'accounting' neat and tidy, they've put in the whole correction gain from 18-bit to 28-bit (not just 20-bit to 28-bit).  This means that they've put in the forgotten-during-O4 gain of 4x, so if things were left alone in the SUS_PI guardian, we'd be sending 4x actuation strength to the ETMs.  In O4, the 4 PI modes we've been damping have only gone to the ETMs.  Since we don't have automatic gain adjustment in the PI damping guardian, I've divided the gain setting line by 4 in SUS_PI, so that we'll end up with the same actuation strength now as we did have in O4. 

J. Kissel, O. Patane
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

Oli was working their way through adjusting the SUS "OUTF" FM10 blocks that are traditionally used to adjust the calibration of the DACs being used, and we re-realized that we've never had a place in the PI model to adjust the DAC gain thru the upgrades from 18- to 20-, and now 28-bit DACs -- see the original discovery back in May 2025 (LHO:84522, which quotes that ETMY's PI DAC had been misalibrated by a factor of 4x since Jun 2020).

In that May 2025 aLOG, I "mildly advocated" for an implementation of ESDOUTF banks like there is in every other SUS drive chain. 
Today, I implemented that change, since (a) the gain difference between a 18-bit and 28-bit DAC is now a factor of 2^10 = 1024x -- much more noticeable, and (b) it's a total no brainer change that's easy to do while we're already restarting this model for the DAC upgrade proper.

The update to the library, 
    /opt/rtcds/userapps/release/sus/common/models
        PI_MASTER_V2.mdl          r26600 --> r34033
is within the ETM_UPCONV_V2 block, which I show in the attached BEFORE vs AFTER.

We have compiled, installed, and restarted h1susetmypi front-end model so that it has this minor change.
Oli will aLOG the installation of the gains.

J. Kissel, D. Barker

As an inadvertent result of us using the new "rev lock" RCG feature during the build of front-end model h1susetmy, we discovered that there was a newer revision of the sub-sub library part used within the QUAD_MASTER library part -- 
    /opt/rtcds/userapps/release/sus/common/models/
        ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl : r16336 --> r30316
where the latter text shows the userapps svn repo version that the h1susetmy model was last compiled with, and what it will be compiled with if we use latest rev of the model (r34028, see LHO:88282).

The ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl is *actually* a library, i.e. it contains a library of library parts that can be used for linearization.
One is the ESD_LIN_CHARGE_MASTER, and the other is ESD_LINE_CHARGE_GENERIC_MASTER.

We're 100.0% confident that the h1susetmy, which uses QUAD_MASTER, uses the ESD_LIN_CHARGE_MASTER block, that's poorly commissioned and has its settings configured to not use it.
We're 98.5% that r16336 --> r30316 update to the library is the creation and commissioning of the other ESD_LINE_CHARGE_GENERIC_MASTER block, given Dec 2024 LLO aLOGs like LHO:74555 and 74771. The 1.5% lack of confidence is only that it's challenging to follow LLO's QUAD front-end model's references to libraries.

Anyways -- this is just to say explicitly that we're going forward with using this r30316 version of the library, but it won't change any function or form of the h1susetmy model.

D. Barker, J. Kissel, O. Patane
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

Following the solidifying of the wiring plan / IO chassis layout (see LHO:88276), Dave did the lion's share of updating the front-end USER models in prep to the 28-bit 32CH upgrade. I merely reviewed it to make sure we understood all the moving pieces and that the connections to the analog world made sense, and am documenting it here.

Recall -- although the wiring diagram -v11 had shown all 20-bit DACs, in order to best reflect the 2022 ideal as of 
    - TST stage :: ECR E1800306 / IIET: 11689,
    - PUM stage :: ECR E1900216 / IIET: 13232
    - Everything else :: ECR E2100485 / IIET:20828, 
but H1 had not yet achieved that ideal, as we instead put our money toward developing and waiting for the 28-bit 32CH DACs. As such, in the "BEFORE" shots, you'll see the reality of the mix of 18-bit and 20-bit DACs. In short, the QUAD TOP (M0 and R0) and TMTS TOP (M1) had not yet been upgrade to 20-bit DACs. So those stages now "skip a version" and go straight to 28-bit 32CH DACs (D2200368).

Attached are screen-shots of the DAC section of the user models BEFORE vs. AFTER:
    - h1susetmy BEFORE vs. AFTER
    - h1sustmsy BEFORE vs. AFTER
    - h1susetmypi BEFORE vs. AFTER

I also include a view of the 28-bit 32CH DAC card usage from each model that uses it; a view which better shows the consumption of channels by function across USER models.
    - DAC0 AFTER
    - DAC1 AFTER

This view helps identify some index / naming convention issues with DAC1 (see DAC1 usage screenshot). This DAC controls *only* the TST stage ESD, but spans the h1susetmy and h1susetmypi USER models. In both the susetmy and susetmypi models, the card_num parameter is set to 1 (one). HOWEVER, because the h1susetmy model uses both of the new two DACs (card_num=0 and card_num=1), the card_num=1's block name is DAC_1. In h1susetmypi which only uses the second card (card_num=1 ), it's block name is DAC_0. 
It's confusing when you look at it like this, and the RCG (current) forces it to be this way because of IO chassis which have mixed DAC card types (unlike ADCs, which the RCG will happily accept cherry pick ). The solution will be as it has been -- update the MEDM macro files that support the user interface, such that we get the UI showing the signal flow through the USER model output and IOP model output without folks having to think about it.