jeffrey.kissel@LIGO.ORG - posted 14:40, Monday 08 August 2022 - last comment - 15:15, Monday 08 August 2022(64368)
Continuing 20-bit DAC Upgrade Campaign: Now to SR2 and SRM M2 and M3 Stages
J. Kissel, D. Barker, E. von Ries, D. Sigg IIET Tickets 13232 and 20828 ECRs E1900216 and E2100485 WP 10609 Tomorrow we'll be upgrading SUS SR2 and SUS SRM's M2 and M3 stages to be driven with 20-bit DACs. After reviewing the relevant SUS wiring drawings, - SUSH34 = D1000599 - SUSH56 = D1002740 I've identified *which* to DAC cards need upgrading. Thankfully, unlike other suspensions, the M2 and M3 stages are not spread across two DAC cards, so there won't any collateral upgrades like there were with last week's changes (see LHO:64274). See attached redlined pages of D1301004-v32, but in words, - To upgrade SR2, in sush34, we replace "DAC-5," which is the 6th (of 6) 18-bit DAC card in the chassis, in the 2nd slot, slot 2, of Adnaco Backplane A3, which connects to slot 8's DAC interface card on the interface backplane. - To upgrade SRM, in sush56, we replace "DAC-4," which is the 5th (of 5) 18-bit DAC card in the mixed 16-and-18-bit DAC card chassis, in the 1st slot, slot 1, of Adnaco Backplane A3, which connects to slot 7's DAC interface card on the interface backplane. I'll be working on updating the top-level USER models this afternoon, h1sussr2, and h1sussrm. Dave will be working on updating the top-level IOP models this afternoon, h1susioph34, and h1susioph56. We'll bring all impacted ISC, SEI, and SUS systems to their safest state and power down the two IO chassis tomorrow to replace the cards.
Non-image files attached to this report
Comments related to this report
J. Kissel
Attached are screenshots of the changes to the h1sussr2 and h1sussrm top-level models, via before vs. after shots:
- SR2 before vs. after
- SRM before vs. after
Of important note -- I've changed the block names underneath the DAC cards to reflect the actual card count / position in the IO chassis. While the *names* of the blocks don't get recorded anywhere, nor do they influence the RCG (e.g. by changing channel names), Dave and I have agreed on this user model policy to preserve our sanity. Where it's not the case in USER models, the IOP models *do* demand that the block name match the card position and it *does* impact the corresponding channel names. Having them match, even if just aesthetically, between user model and IOP model helps reconciliation of which card is which when interfacing with drawings and physical IO chassis / card layouts.
These changes have now been committed to the userapps repo as of rev 23394 under
/opt/rtcds/userapps/release/sus/h1/models/
h1sussr2.mdl
h1sussrm.mdl
and are ready for installation during tomorrow's maintenance when we upgrade the actual cards.
Images attached to this comment
