J. Kissel
Electronics Wiring: D2000202

I'm taken the first pass at building the front-end simulink models for the new HAM7 SUS: FC1, which now lives in h1susfc1.mdl, and all the rest, ZMs 1-5, and OPO, live in h1sussqzin.mdl. The first two attachments show screenshots 2021-08-18_h1susfc1_toplevel.png and 2021-08-18_h1sussqzin_toplevel.png, are of the top-level of these models that have been digitally cabled up according to D2000202. Though they've not been compiled, and thus not stripped of bugs yet, they should be ready to go for testing with the new computer and IO chassis.

The top level models live in the standard location,
    /opt/rtcds/userapps/release/sus/h1/models/
        h1susfc1.mdl
        h1sussqzin.mdl


For the most part, generating these models from the wiring diagram and existing SUS library parts in
    /opt/rtcds/userapps/release/sus/common/models/
was pretty easy -- just the tediousness of LOTS of fine detail librarianship and organization connections.

The hard/new parts were as follows:
    For FC1:
        - I chose to start from a copy of SRM, because is the "master" model for the binary IO that controls/reads back the coil driver switching for all SUS in the sush56 IO chassis, and I know FC1 will be the same.
        - However, the way that electronics are organized in the much more crowded sush56, SRM shares it's stuff and is midway down the hierarchy, so the encoding and decoding of the the two binary IO cards that chassis has is a mess (sush2 and sush34 would be no less complicated). So, for FC1, which is the only suspension in sush7 with any BIO, I had to re-remember the arrangement of bits in each coil driver type worked, and decode and encode them nicely. Unsurprisingly, the end result is much cleaner and the equivalent blocks in any other susham chassis.
        - The second pair of attachments, 2021-08-18_h1susfc1_FC1_BIO_ENCODE.png and 2021-08-18_h1susfc1_FC1_BIO_DECODE.png show this handy-work.

    For ZM2:
        - Here, as discussed in LHO aLOG 59651, ZM2 is an HPDS, so all of it's piezo-driven longitudinal control is done by either beckhoff or be some other fast DAC some where. So, we can "cheat" as we did for ZM4, ZM5, and ZM6 and use an HSSS_MASTER part for control of the M1 stage.

    For ZM1, and ZM3:
        - For these HDDS, which use brand new COSEM (Coil-only OSEMs, no sensor LED + PDs as in AOSEMs or BOSEMs) for fast, 2 kHz alignment dither, we need a brand new library part. This low lives in/opt/rtcds/userapps/release/sus/common/models/HDDS_MASTER.mdl. The 5th attachment, 2021-08-18_HDDS_MASTER.png shows what's in the top level of the library part. Just what you'd expect -- an M1 and M2 stage. However, unlike other multi-stage suspensions, since the only plan for the COSEM drive is to dither the optic at ~2 kHz, I have *not* connected the control output of the M2 stage to the M1 stage. I've also gotten rid of *all* the remnants of the status bits that were only used for the now defunct ODC channels. 
        - The M1 stage is just a standard top mass stage that I copied from the HSSS_MASTER. For the M2 stage, which you can see in 2021-08-18_HDDS_MASTER_M2.png, I've stripped out all of the standard OSEM sensor signal infrastructure.
        - Interestingly, since there's no sensor on the M2 stage to use for a watchdog on whether the user is requesting WAY too much drive, I've picked off the MASTER_OUT channels, and used *those* as the input to the now-new-and-improved RMS watchdog part, FOUROSEM_WD_RMS_MASTER.mdl. This has the same improvements that have been implemented in the OFI and OPO suspension, namely that the RMS calculation is *actually* an RMS, with space for band limiting and low passing before and after as one might expect (unlike the older rest of the SUS which still need to be upgraded).

But -- that's it! They're done!

These models should be ready for hand off to Dave / Erik.