jeffrey.kissel@LIGO.ORG - posted 18:35, Thursday 12 May 2022 - last comment - 08:01, Friday 13 May 2022(63115)
Front End model Prep allowing for lots of Options for HAM1 Feedforward or Sensor Correction to Improve REFL WFS and/or CHARD/PRC2/INP1 Cavity Alignment
J. Kissel WP 10434 ECR E2200226 After talking with Jenne and Jim last and this week, discussing what we've found in terms of all the coherent coupling paths between the HAM1 Table Top L4Cs (see LHO:63114), I have now built up the front-end model infrastructure to hold space for all the future possibilities of comparing the options for feed foward (recapped here): - run a feed forward directly to the RM actuators, - "sensor correction" for the DC pointing control loops by subtracting the HAM1 TT signal out of the REFL WFS DC error signal, or - "sensor correction" for the RF channels of the REFL WFS -- to remove the HAM1 from *all* the INP1, PRC2, and CHARD loops, rather than just the CHARD loop - as well as the already successful "blind wiener method" of sensor-correction style feed-forward directly to the CHARD (and INP1, and PRC2) error signals and to do this with *multiple* degrees of freedom of witness X, Z, RX, and RY TT L4Cs, rather than just Z. We've designed that all the feed-forward calculations should be done in the "sei proc" model, and then their output will be sent over dolphin PCIE IPC to the ASC model and the RMs' model. As such, implementing making changes to the following for non-library part models: /opt/rtcds/userapps/release/ hpi/h1/models/ h1hpiham1.mdl << where the TT L4Cs are broadcast (actually the senders already existed, but there was a typo in the "channel" name that we'd like to fix) isi/h1/models/ h1seiproc.mdl << where the feed-forward / sensor correction filters will live asc/h1/models/ h1asc.mdl << where the FF / SC filter output will be plugged into various parts of the REFL WFS and the cavity DOF error signals sus/h1/models/ h1sushtts.mdl << where the feed-forward will be added into the RM actuators. While I had hoped to actually finish making all these changes by this past Tuesday, the ASC model proved to be quick a headache to organize enough to make these kinds of changes, so they didn't go in. As such, I've copied my changes over to the following models that have been committed to the same respective folders for safe keeping, to be installed two Tuesdays from now, h1seiproc_pendingchanges_20220511.mdl h1asc_pendingchanges_20220511.mdl h1sushtts_pendingchanges_20220511.mdl I'll attach screenshots and explanations of my work in comments to this aLOG.
Changes to h1hpiham1 As mentioned in the main entry, here there was just a mistake in the name of the IPC sender "channel," where instead of the standard abbreviation for hepi, "HPI," (aytch, pee, eye) we instead had "HP1" (aytch, pee, one). Fixed it. Since - the sender's already existed but no other model received it, - and the CDS team is going to rebuild the H1.ipc list of sender channels entirely from scratch next Tuesday we figure there's no harm in having this change actually still in place, such that it'll just get installed by default during the RCG upgrade (again, next Tuesday). This is the only model of the list of 4 I mention above that I committed as is, with the same file name, without "setting it aside" with the "_pendingchanges_20220511" tag.Changes to h1seiproc For all the subsequent models, in addition to the changes needed to implement this feed-forward scheme, I also took the opportunity to "clean as you go," organizing the model to be a more legible and consistent with other models and modern conventions. However, I made sure that *none* of these "clean as you go" changes would impact any functionality or channel names or anything. So, with this said, let's walk through the changes to seiproc. IPC Input now ingests the TT L4C senders: - before vs. after #CleanAsYouGo: IPC Output from the corner station sensor correction is bused and tagged over to the far right of the model where, by convention, all output to hardware goes: - Output of "SEI" top_name block, now bused and tagged before vs. after - And the list of PCIE output, where the tag and unbus happens (just like the other signals that came out of the SEI block) before vs. after Brand new "HPI" top-name block, that has all the infrastructure for the new feed forward filter banks -- leaning heavily on the CDS part that yields a frequency dependent matrix, where I've piped the four X, Z, RX, and RY L4C signals into four separate matrices -- one destined for the ASC model's pitch error signals (called CART2ASCP), one for the ASC model's yaw error signals (called CART2ASCY), one for RM1 (called CART2RM1), and one for RM2 (called CART2RM2). Also note that there's a bank of input filters (INF) for holding the digital AI filter handling any fourier pollution from the transfer from the 2 kHz h1hpiham1 model, to the 4kHz seiproc model. And then finally, since we always like having a kill switch, there's an output switch that feeds into all outputs via blocks that match the output signal names. Check out the tour through: - the HPI block from the top level, - one layer down into the HPI block to show the HAM1_TTL4C_FF block, - diving into that HAM1_TTL4C_FF block, to see all of the real guts showing the INF block, the frequency dependent matrices, and the output switch banks, - for completeness, the inside of the INF block and the inside of one of the output switch blocks, - and zooming all the way up and back out, to the top level right hand side where the PCIE senders to the ASC and HTTS models are definedChanges to the ASC model Here's where I had to do the MOST amount of "clean as you go." After years of ECRs to the ASC system, temporary tests that stuck, and hacks around the RCG's ability to implement what we actually wanted, it had become quite an unextensible mess. So, I took the opportunity to clean up as I went. Again, while this involved a ton of *visual* reorganization, I have taken great effort to not change any existing channel names, infrastructure, or functionality. So, let's take a tour through it. - #CleanAsYouGo At the top level, I cleaned up, via bussing and tagging, all the ADC and DAC connections, and organized them as we've come to organize the SEI and SUS models -- with the inputs on the left, the outputs on the right, and clear clustering of ADCs, SHMEM, PCIE, and RFM, and DACs, rather than having them directly piped into the main model block. This is because the ASC model has *SO MANY* inputs, it's becoming challenging to understand even simple facts like "how many ADC cards are used" or "what DAC channels are used?" -before ADCs, DACs, and Example Input vs. after ADC input and DAC output You'll notice though, that I didn't do this for *all* the IPC that comes in and out. I found this just too intractable. We'll have to save that for next time. - Still at the top level, on the left input side under the PCIE grouping, brand new ingested receivers of the Pitch and Yaw HAM1 L4C FF signals from seiproc - Final top-level change of adding the bussed up tag of FF signals into the very bottom of the ASC block as new inputs before vs. - Once inside the ASC block, just a big, overall reorganization and better naming of functional areas before vs. after - Zooming in to the very bottom left corner, we see where the new inputs are de-muxed and pushed into individual tags to be used throughout the rest of the model - #CleanAsYouGo the input signal processing for all the WFS was a garbled tightly packed mess, so I spread everything out, and organized the blocks into groups of AS WFS, POP WFS, and REFL WFS, where within each section they're sorted into rows of the "A" vs "B" sensor, and columns of frequency content, and labeling them. - AS and POP WFS before sorted into AS WFS after and POP WFS after, and - REFL WFS before sorted into REFL WFS after plus the new A and B blocks where the feed-foward to the DC, RF9_I and RF45_I channels are added. - #CleanAsYouGo the hardest part of this model change was figuring out exactly *where* to install the feed-forward signals into CHARD. Why? Just look at the before pictures -- and note that I'm just showing the pitch DOFs; there's an equal mess in the yaw DOFs - DRMI Cavity control before - DC Pointing and Arm Cavity A and B Blend Filters before - zoom in on the Arm Cavity A and B Blend Filters before - back up to the Arm Cavity Control before and then compare that to what I've done by grouping each cavity DOF into a Pitch and Yaw subsystem and heavily employing tags, - A general zoomed out feel for how things look after - DRMI cavity control after - Arm cavity control after - DC centering after after With this organization, it was super easy to make an inventory of what degrees of freedom has what "enhancements" from the basic WFS or QPD control loop, be it - Power Normalization (all DOFs by DC6 and 7 have this) - Adding smooth limiters to the error signals (installed LHO:44261 -- all cavity DOF loops have this, but DC centering loops do not) - Adding sensing matrix excitation points (installed after ECR E1600020 -- all cavity DOF loops have this, but DC centering loops do not) - Adding sensor blending (installed after ECR E1600020 -- only the arm cavity DOFs have this) - Adding radiation pressure torque compensation (installed after LHO:43849 -- only the arm cavity DOFs have this) and now we add in - The HAM1 FF to CHARD, PRC2, and INP1. You can see this clearly if we open up the new CHARD Block, which has *all* of the above enhancements. And I've tried to label each of the functions, and organize it cleanly. All the other control blocks have various combinations of lesser features that CHARD, so I won't walk you through them. You'll notice that these are organized and color coded as though they *could* be made into library parts, but since there was no one block that had *so* many of the same type, and at least with the cavity DOFs they are / were each subtly different enough, that I figured I might as well just leave them as unique snow-flakes, so they're easier to individually modify in the future. Hopefully this makes things more extensible, at the cost of a bit more to maintain. - Now that we see how the sensor correction / feed forward will be implemented in CHARD, let's go back to the HAM1_FF block, and show you the insides of that, in - the new A and B blocks - the A block, and then in - the the REFL_A_HAM1FF_RF45_I_PIT block where the FF signal is added to the target. *phew*! OK, that wraps up the changes to the ASC model. One more to go!