40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 303 of 335 Not logged in
ID Date Author Type Category Subject
15959   Wed Mar 24 19:02:21 2021 JonUpdateCDSFront-end testing

This evening I prepared a new 2 TB 3.5" disk to hold a copy of /opt/rtcds and /opt/rtapps from chiara. This is the final piece of setup before model compilation can be tested on the new front-ends. However chiara does not appear to support hot-swapping of disks, as the disk is not recognized when connected to the live machine. I will await confirmation before rebooting it. The new disk is not currently connected.

15962   Thu Mar 25 12:11:53 2021 YehonathanUpdateCDSc1auxey assembly

I finished prewiring the new c1auxey Acromag chassis (see attached pictures). I connected all grounds to the DIN rail to save some wiring. The power switches and LEDs work as expected.

I configured the DAQ modules using the old windows machine. I configured the gateway to be 192.168.114.1. The host machine still needs to be setup.

Next, the feedthroughs need to be wired and the channels need to be bench tested.

Attachment 1: 20210325_115500_HDR.jpg
Attachment 2: 20210325_123033.jpg
15963   Thu Mar 25 14:16:33 2021 gautamUpdateCDSc1auxey assembly

It might be a good idea to configure this box for the new suspension config - modern Satellite Amp, HV coil driver etc. It's a good opportunity to test the wiring scheme, "cross-connect" type adapters etc.

 Quote: Next, the feedthroughs need to be wired and the channels need to be bench tested.
15976   Mon Mar 29 17:55:50 2021 JonUpdateCDSFront-end testing

### Cloning of chiara:/home/cvs underway

I returned today with a beefier USB-SATA adapter, which has an integrated 12 V supply for powering 3.5" disks. I used this to interface a new 6 TB 3.5" disk found in the FE supplies cabinet.

I decided to go with a larger disk and copy the full contents of chiara:/home/cds. Strictly, the FEs only strictly need the RTS executables in /home/cvs/rtcds and /home/cvs/rtapps. However, to independently develop models, the shared matlab binaries in /home/cvs/caltech/... also need to be exposed. And there may be others I've missed.

I began the clone around 12:30 pm today. To preserve bandwidth to the main disk, I am copying not the /home/cds disk directly, but rather its backup image at /media/40mBackup.

### Set up of dedicated SimPlant host

Although not directly related to the FE testing, today I added a new machine to the test stand which will be dedicated to running sim models. Chris has developed a virtual cymac which we plan to run on this machine. It will provide a dedicated testbed for SimPlant and other development, and can host up to 10 user models.

I used one of the spare 12-core Supermicro servers from LLO, which I have named c1sim. I assigned it the IP address 192.168.113.93 on the Martian network. This machine will run in a self-contained way that will not depend on any 40m CDS services and also should not interfere with them. However, if there are concerns about having it present on the network, it can be moved to the outside-facing switch in the office area. It is not currently running any RTCDS processes.

Set-up was carried out via the following procedure:

• Installed Debian 10.9 on an internal 480 GB SSD.
• Installed cdssoft repos following Jamie's instructions.
• Installed RTS and Docker dependencies:
$sudo apt install cpuset advligorts-mbuf-dkms advligorts-gpstime-dkms docker.io docker-compose • Configured scheduler for real-time operation: $ sudo /sbin/sysctl kernel.sched_rt_runtime_us = -1
• Reserved 10 cores for RTS user models (plus one for IOP model) by adding the following line to /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=nohz,domain,1-11 nohz_full=1-11 tsc=reliable mce=off"
followed by the commands:
$sudo update-grub$ sudo reboot now
• Downloaded virtual cymac repo to /home/controls/docker-cymac.

I need to talk to Chris before I can take the setup further.

15978   Tue Mar 30 17:27:04 2021 YehonathanUpdateCDSc1auxey assembly

{Yehonathan, Jon}

We poked (looked in situ with a flashlight, not disturbing any connections) around c1auxex chassis to understand better what is the wiring scheme.

To our surprise, we found that nothing was connected to the RTNs of the analog input Acromag modules. From previous experience and the Acromag manual, there can't be any meaningful voltage measurement without it.

I also did some rewiring in the Acromag chassis to improve its reliability. In particular, I removed the ground wires from the DIN rail and connected them using crimp-on butt splices.

15979   Tue Mar 30 18:21:34 2021 JonUpdateCDSFront-end testing

Progress today:

### Outside Internet access for FE test stand

This morning Jordan and I ran an 85-foot Cat 6 Ethernet cable from the campus network switch in the office area (on the ligo.caltech.edu domain) to the FE test stand near 1X6. This is to allow the test-stand subnet to be accessed for remote testing, while keeping it invisible to the parallel Martian subnet.

### Successful RTCDS model compilation on new FEs

The clone of the chiara:/home/cds disk completed overnight. Today I installed the disk in the chiara clone. The NFS mounts (/opt/rtcds, /opt/rtapps) shared with the other test-stand machines mounted without issue.

Next, I attempted to open the shared Matlab executable (/cvs/cds/caltech/apps/linux64/matlab/bin/matlab) and launch Simulink. The existing Matlab license (/cvs/cds/caltech/apps/linux64/matlab/licenses/license_chiara_865865_R2015b.lic) did not work on this new machine, as they are machine-specific, so I updated the license file. I linked this license to my personal license, so that the machine license for the real chiara would not get replaced. The original license file is saved in the same directory with a *.bak postfix. If this disk is ever used in the real chiara machine, this file should be restored. After the machine license was updated, Matlab and Simulink loaded and allowed model editing.

Finally, I tested RTCDS model compilation on the new FEs using the c1lsc model as a trial case. It encountered one path issue due to the model being located at /opt/rtcds/userapps/release/isc/c1/models/isc/ instead of /opt/rtcds/userapps/release/isc/c1/models/. This seems to be a relic of the migration of the 40m models from the SVN to a standalone git repo. This was resolved by simply symlinking to the expected location:

$sudo ln -s /opt/rtcds/userapps/release/isc/c1/models/isc/c1lsc.mdl /opt/rtcds/userapps/release/isc/c1/models/c1lsc.mdl The model compilation then succeeded: controls@c1bhd$ cd /opt/rtcds/caltech/c1/rtbuild/release controls@c1bhd$make clean-c1lsc Cleaning c1lsc... Done controls@c1bhd$ make c1lsc Cleaning c1lsc... Done Parsing the model c1lsc... Done Building EPICS sequencers... Done Building front-end Linux kernel module c1lsc... make[1]: Warning: File 'GNUmakefile' has modification time 28830 s in the future make[1]: warning:  Clock skew detected.  Your build may be incomplete. Done RCG source code directory: /opt/rtcds/rtscore/branches/branch-3.4 The following files were used for this build: /opt/rtcds/caltech/c1/userapps/release/cds/common/src/cdsToggle.c /opt/rtcds/userapps/release/cds/c1/src/inmtrxparse.c /opt/rtcds/userapps/release/cds/common/models/FILTBANK_MASK.mdl /opt/rtcds/userapps/release/cds/common/models/rtbitget.mdl /opt/rtcds/userapps/release/cds/common/models/SCHMITTTRIGGER.mdl /opt/rtcds/userapps/release/cds/common/models/SQRT_SWITCH.mdl /opt/rtcds/userapps/release/cds/common/src/DB2MAG.c /opt/rtcds/userapps/release/cds/common/src/OSC_WITH_CONTROL.c /opt/rtcds/userapps/release/cds/common/src/wait.c /opt/rtcds/userapps/release/isc/c1/models/c1lsc.mdl /opt/rtcds/userapps/release/isc/c1/models/IQLOCK_WHITENING_TRIGGERING.mdl /opt/rtcds/userapps/release/isc/c1/models/PHASEROT.mdl /opt/rtcds/userapps/release/isc/c1/models/RF_PD_WITH_WHITENING_TRIGGERING.mdl /opt/rtcds/userapps/release/isc/c1/models/UGF_SERVO_40m.mdl /opt/rtcds/userapps/release/isc/common/models/FILTBANK_TRIGGER.mdl /opt/rtcds/userapps/release/isc/common/models/LSC_TRIGGER.mdl Successfully compiled c1lsc *********************************************** Compile Warnings, found in c1lsc_warnings.log: *********************************************** [warnings suppressed]

As did the installation:

controls@c1bhdmake install-c1lsc Installing system=c1lsc site=caltech ifo=C1,c1 Installing /opt/rtcds/caltech/c1/chans/C1LSC.txt Installing /opt/rtcds/caltech/c1/target/c1lsc/c1lscepics Installing /opt/rtcds/caltech/c1/target/c1lsc Installing start and stop scripts /opt/rtcds/caltech/c1/scripts/killc1lsc /opt/rtcds/caltech/c1/scripts/startc1lsc Performing install-daq Updating testpoint.par config file /opt/rtcds/caltech/c1/target/gds/param/testpoint.par /opt/rtcds/rtscore/branches/branch-3.4/src/epics/util/updateTestpointPar.pl -par_file=/opt/rtcds/caltech/c1/target/gds/param/archive/testpoint_210330_170634.par -gds_node=42 -site_letter=C -system=c1lsc -host=c1lsc Installing GDS node 42 configuration file /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1lsc.par Installing auto-generated DAQ configuration file /opt/rtcds/caltech/c1/chans/daq/C1LSC.ini Installing Epics MEDM screens Running post-build script safe.snap exists We are ready to start building and testing models. 15997 Tue Apr 6 07:19:11 2021 JonUpdateCDSNew SimPlant cymac Yesterday Chris and I completed setup of the Supermicro machine that will serve as a dedicated host for developing and testing RTCDS sim models. It is currently sitting in the stack of machines in the FE test stand, though it should eventually be moved into a permanent rack. It turns out the machine cannot run 10 user models, only 4. Hyperthreading was enabled in the BIOS settings, which created the illusion of there being 12 rather than 6 physical cores. Between Chris and Ian's sim models, we already have a fully-loaded machine. There are several more of these spare 6-core machines that could be set up to run additional models. But in the long term, and especially in Ian's case where the IFO sim models will all need to communicate with one another (this is a self-contained cymac, not a distributed FE system), we may need to buy a larger machine with 16 or 32 cores. IPMI was set up for the c1sim cymac. I assigned the IPMI interface a static IP address on the Martian network (192.168.113.45) and registered it in the usual way with the domain name server on chiara. After updating the BIOS settings and rebooting, I was able to remotely power off and back on the machine following these instructions. ### Set up of dedicated SimPlant host Although not directly related to the FE testing, today I added a new machine to the test stand which will be dedicated to running sim models. Chris has developed a virtual cymac which we plan to run on this machine. It will provide a dedicated testbed for SimPlant and other development, and can host up to 10 user models. I used one of the spare 12-core Supermicro servers from LLO, which I have named c1sim. I assigned it the IP address 192.168.113.93 on the Martian network. This machine will run in a self-contained way that will not depend on any 40m CDS services and also should not interfere with them. 15998 Tue Apr 6 11:13:01 2021 JonUpdateCDSFE testing ## I/O chassis assembly Yesterday I installed all the available ADC/DAC/BIO modules and adapter boards into the new I/O chassis (c1bhd, c1sus2). We are still missing three ADC adapter boards and six 18-bit DACs. A thorough search of the FE cabinet turned up several 16-bit DACs, but only one adapter board. Since one 16-bit DAC is required anyway for c1sus2, I installed the one complete set in that chassis. Below is the current state of each chassis. Missing components are highlighted in yellow. We cannot proceed to loopback testing until at least some of the missing hardware is in hand. ### C1BHD  Component Qty Required Qty Installed 16-bit ADC 1 1 16-bit ADC adapter 1 0 18-bit DAC 1 0 18-bit DAC adapter 1 1 16-ch DIO 1 1 ### C1SUS2  Component Qty required Qty Installed 16-bit ADC 2 2 16-bit ADC adapter 2 0 16-bit DAC 1 1 16-bit DAC adapter 1 1 18-bit DAC 5 0 18-bit DAC adapter 5 5 32-ch DO 6 6 16-ch DIO 1 1 ## Gateway for remote access To enable remote access to the machines on the test stand subnet, one machine must function as a gateway server. Initially, I tried to set this up using the second network interface of the chiara clone. However, having two active interfaces caused problems for the DHCP and FTS servers and broke the diskless FE booting. Debugging this would have required making changes to the network configuration that would have to be remembered and reverted, were the chiara disk to ever to be used in the original machine. So instead, I simply grabbed another of the (unused) 1U Supermicro servers from the 1Y1 rack and set it up on the subnet as a standalone gateway server. The machine is named c1teststand. Its first network interface is connected to the general computing network (ligo.caltech.edu) and the second to the test-stand subnet. It has no connection to the Martian subnet. I installed Debian 10.9 anticipating that, when the machine is no longer needed in the test stand, it can be converted into another docker-cymac for to run additional sim models. Currently, the outside-facing IP address is assigned via DHCP and so periodically changes. I've asked Larry to assign it a static IP on the ligo.caltech.edu domain, so that it can be accessed analogously to nodus. 16008 Thu Apr 8 20:58:17 2021 KojiUpdateCDSADC adapter boards assembly 5x 16bit ADC adapter boards (D0902006) assembled. Attachment 1: P_20210408_205411_2_1.jpg 16012 Sat Apr 10 08:51:32 2021 JonUpdateCDSI/O Chassis Assembly I installed three of the 16-bit ADC adapter boards assembled by Koji. Now, the only missing hardware is the 18-bit DACs (quantities below). As I mentioned this week, there are 2-3 16-bit DACs available in the FE cabinet. They could be used if more 16-bit adapter boards could be procured.  C1BHD Component Qty Required Qty Installed 16-bit ADC 1 1 16-bit ADC adapter 1 1 18-bit DAC 1 0 18-bit DAC adapter 1 1 16-ch DIO 1 1  C1SUS2 Component Qty required Qty Installed 16-bit ADC 2 2 16-bit ADC adapter 2 2 16-bit DAC 1 1 16-bit DAC adapter 1 1 18-bit DAC 5 0 18-bit DAC adapter 5 5 32-ch DO 6 6 16-ch DIO 1 1 16015 Sat Apr 10 11:56:14 2021 JonUpdateCDS40m LSC simPlant model ## Summary Yesterday I resurrected the 40m's LSC simPlant model, c1lsp. It is running on c1sim, a virtual, self-contained cymac that Chris and I set up for developing sim models (see 15997). I think the next step towards an integrated IFO model is incorporating the suspension plants. I am going to hand development largely over to Ian at this point, with continued support from me and Chris. ## LSC Plant This model dates back to around 2012 and appears to have last been used in ~2015. According to the old CDS documentation: Name Description Communicates directly with LSP Simulated length sensing model of the physical plant, handles light propagation between mirrors, also handles alignment modeling and would have to communicate ground motion to all the suspensions for ASS to work LSC, XEP, YEP, VSP Here XEP, YEP, and VSP are respectively the x-end, y-end, and vertex suspension plant models. I haven't found any evidence that these were ever fully implemented for the entire IFO. However, it looks like SUS plants were later implemented for a single arm cavity, at least, using two models named c1sup and c1spx (appear in more recent CDS documentation). These suspension plants could likely be updated and then copied for the other suspended optics. To represent the optical transfer functions, the model loads a set of SOS filter coefficients generated by an Optickle model of the interferometer. The filter-generating code and instructions on how to use it are located here. In particular, it contains a Matlab script named opt40m.m which defines the interferferometer. It should be updated to match the parameters in the latest 40m Finesse model, C1_w_BHD.kat. The calibrations from Watts to sensor voltages will also need to be checked and likely updated. ## Model-Porting Procedure For future reference, below are the steps followed to port this model to the virtual cymac. 1. Copy over model files. • The c1lsp model, chiara:/opt/rtcds/userapps/release/isc/c1/models/c1lsp.mdl, was copied to the userapps directory on the virtual cymac, c1sim:/home/controls/docker-cymac/userapps/x1lsp.mdl. In the filename, note the change in IFO prefix "c1" --> "x1," since this cymac is not part of the C1 CDS network. • This model also depends on a custom library file, chiara:/opt/rtcds/userapps/release/isc/c1/models/SIMPLANT.mdl, which was copied to c1sim:/home/controls/docker-cymac/userapps/lib/SIMPLANT.mdl. 2. Update model parameters in Simulink. To edit models in Simulink, see the instructions here and also here. • The main changes are to the cdsParameters block, which was updated as shown below. Note the values of dcuid and specific_cpu are specifically assigned to x1lsp and will vary for other models. The other parameters will be the same. • • I also had to change the name of one of the user-defined objects from "ADC0" --> "ADC" and then re-copy the cdsAdc object (shown above) from the CDS_PARTS.mdl library. At least in newer RCG code, the cdsAdc object must also be named "ADC0." This namespace collision was causing the compiler to fail. • Note: Since Matlab is not yet set up on c1sim, I actually made these edits on one of the 40m machines (chiara) prior to copying the model. 3. Compile and launch the models. Execute the following commands on c1sim: •  cd ~/docker-cymac $./kill_cymac$ ./start_cymac debug
• The optional debug flag will print the full set of compilation messages to the terminal. If compilation fails, search the traceback for lines containing "ERROR" to determine what is causing the failure.

4. Accessing MEDM screens. Once the model is running, a button should be added to the sitemap screen (located at c1sim:/home/controls/docker-cymac/userapps/medm/sitemap.adl) to access one or more screens specific to the newly added model.

• Custom-made screens should be added to c1sim:/home/controls/docker-cymac/userapps/medm/x1lsp (where the final subdirectory is the name of the particular model).

• The set of available auto-generated screens for the model can be viewed by entering the virtual environment:

• $cd ~/docker-cymac $ ./login_cymac                    #drops into virtual shell # cd /opt/rtcds/tst/x1/medm/x1lsp  #last subdirectory is model name # ls -l *.adl # exit                             #return to host shell
• The sitemap screen and any subscreens can link to the auto-generated screens in the usual way (by pointing to their virtual /opt/rtcds path). Currently, for the virtual path resolution to work, an environment script has to be run prior to launching sitemap, which sets the location of a virtual MEDM server (this will be auto-scripted in the future):

• $cd ~/docker-cymac$ eval $(./env_cymac)$ sitemap
• One important auto-generated screen that should be linked for every model is the CDS runtime diagnostics screen, which indicates the success/fail state of the model and all its dependencies. T1100625 details the meaning of all the various indicator lights.

16021   Tue Apr 13 16:24:38 2021 Ian MacMillanUpdateCDS40m LSC simPlant model

Added Matlab to the Docker machine. This should help immensely with workflow as well as keeping installed libraries consistent. Next step is outlining the project so coding is easier

Command to launch is:     $matlab & From Jon just for bookkeeping: Then in the Matlab command window, open the CDS parts library via: addpath /home/controls/simLink/lib/  open /home/controls/simLink/CDS_PARTS.mdl Then open an RTCDS model (for example, here the LSC plant) via: open /home/controls/docker-cymac/userapps/x1lsp.mdl 16037 Thu Apr 15 17:24:08 2021 JonUpdateCDSUpdated c1auxey wiring plan I've updated the c1auxey wiring plan for compatibility with the new suspension electronics. Specifically it is based on wiring schematics for the new HAM-A coil driver (D1100117), satellite amplifier (D1002818), and HV bias driver (D1900163). Changes: • The PDMon, VMon, CoilEnable, and BiasAdj channels all move from DB37 to various DB9 breakout boards. • The DB9 cables (x2) connecting the CoilEnable channels to the coil drivers must be spliced with the dewhitening switching signals from the RTS. • As suggested, I added five new BI channels to monitor the state of the CoilEnable switches. For lack of a better name, they follow the naming convention C1:SUS-ETMY_xx_ENABLEMon. @Yehonathan can proceed with wiring the chassis.  Quote: I finished prewiring the new c1auxey Acromag chassis (see attached pictures). I connected all grounds to the DIN rail to save some wiring. The power switches and LEDs work as expected. I configured the DAQ modules using the old windows machine. I configured the gateway to be 192.168.114.1. The host machine still needs to be setup. Next, the feedthroughs need to be wired and the channels need to be bench tested. Attachment 1: C1AUXEY_Chassis_Feedthroughs_-_By_Connector.pdf 16038 Thu Apr 15 18:33:39 2021 KojiUpdateCDSMore 16bit ADC adapter boards We received 10x 16bit ADC adapter boards from Todd. S2100687~S2100696 The number of soldered resistors seems to be less than that on the schematics. They are related to duotone, so check if it's OK upon use. Attachment 1: P_20210415_183139_1.jpg 16050 Mon Apr 19 13:15:20 2021 Ian MacMillanUpdateCDS40m LSC simPlant model The x1SUSsim model on the docker was made in a more recent version of Simulink so I updated Matlab (see this) I updated Matlab to 2021a so now the docker has 2020b and 2021a installed. This should also install Simulink 10.3 for the sus model to open. I used my account to activate it but I can change it over if I get a dedicated license for this. I am not sure what Jon did for the 2020b that he installed. it is giving me "License error: -9,57" so I guess it didn't work... I will try to just make the model on the 2020b just so I have something. ----------------------------------------------------------------------------------------------------------------------------- I was able to fix the problem with the activation (using this). I can now open the x1sussim.mdl file. It is trying to access a BSFM_MASTER Library that it doesn't seem to have. the other files don't seem to have any warnings though. the simple suspension model can be found in home/controls/docker-cymac/userapps/c1simpsus.mdl on the docker system. This is where I will put my model. (right now it is just a copied file) Also using Simulink on the docker is very slow. I think this is either a limit of the x2goclient software or the hardware that the docker is running on. 16052 Mon Apr 19 21:54:55 2021 YehonathanUpdateCDSUpdated c1auxey wiring plan Except for the feed-throughs that require a DB9-M connector I finished wiring and labeling the Acromag, following Jon's updated wiring plan. We can start testing the differential inputs until the missing connectors arrive. 16059 Wed Apr 21 10:03:01 2021 Ian MacMillanUpdateCDS40m LSC simPlant model So I am stuck on how to add the control block to my model. I am trying to make it as simple as possible with just a simple transfer function for a damped harmonic oscillator and then the control block (see overview.png). The transfer function I am using is: $H(s)=\frac{Q^{-2} f^{-2}s^2+1}{f^{-4}s^4+(Q^{-2} f^{-2}-2f^{-2})s^2+1}$ For future generations: To measure the transfer function (to verify that it is doing what it says it is) I am using the discrete transfer function estimator block. To get a quick transfer function estimator Simulink program run ex_discrete_transfer_function_estimator in the Matlab command line. This works well for filters but it was hit or miss using the discrete transfer function. The roadblock I am running into right now is that I can't figure out how to add the controller to the model. Not on an interpretation level but in a very straightforward "can I drag it into my model and will it just work" kind of way. I am also a little confused as to exactly which block would do the controlling. Because I want to just use the x of the pendulum (its position) I think I want to use the suspension controls which come are connected to in the suspension plant model. But where exactly is it and how can I get the model? I can't seem to find it. Attachment 1: Overview.png 16061 Wed Apr 21 11:01:37 2021 RanaUpdateCDS40m LSC simPlant model The controller would be in the c1sus model, and connects to the c1sup plant model. So the controller doesn't go in the plant model. Both the controller and the plant can be modeled using a single filter module in each separate model as you've drawn, but they go in separate models. 16081 Fri Apr 23 15:52:19 2021 Ian MacMillanUpdateCDS40m LSC simPlant model I have attached the framework that I am using for the full system. Plantframework.pdf has the important aspects that I will be changed. Right now I am trying to keep it mostly as is, but I have disconnected the Optic Force Noise and hope to disconnect the Suspension Position Noise. The Optic Force Noise Block is additive to the signal so eliminating it from the system should make it less realistic but simpler. It can be added back easily by reconnecting it. The next step is adding my plant response, which is simply the transfer function and measurement from the last post. These should be inserted in the place of the red TM_RESP in the model. The TM_RESP block takes in a vector of dimension 12 and returns a vector of dimension 6. The confusing part is that the block does not seem to do anything. it simply passes the vector through with no changes. I'm not sure why this is the case and I am looking for documentation to explain it but haven't found anything. As to how a 12 vector turns into a 6 vector I am also lost. I will probably just disconnect everything but the x position. I tried to just throw in my model (see Simple_Plant.pdf) and see what happened but the model would not let me add built-in blocks to the model. This is weird because all the blocks that I am adding are part of the basic library. My guess is that this mode will only accept blocks from the CDL library. I will either need to change my blocks to be made from blocks in the CDL library or maybe I can pass the signal out of the plant framework model then into my model then back to the plant framework model. I think this is just a Matlab thing that I don't know about yet. (Jon probably knows) I have also attached an image of the controls model for reference. It looks like a mess but I'm sure there is a method. I won't get lost in going through it just assume it works... for now. The next question I have been asking is how do I show that the system works. When anchal and I made a python simulation of the system, we tested it by seeing the evolution of the degrees of freedom over time given some initial conditions. We could see the pendulum propagating and some of the coupling between the DOFs. This is a fast and dirty way to check if everything is working and should be easy to add. I simply recorded the POS signal and graph it over time. Once we get to a state-space model we can test it by taking the transfer function, but since our plant is literally already just a transfer function there isn't much of a point yet. Also, I need to add color to my Simple_Plant.pdf model because it looks really boring :( Attachment 1: Plant_framework.pdf Attachment 2: Simple_Plant.pdf Attachment 3: Controls.pdf 16084 Sun Apr 25 21:21:02 2021 ranaUpdateCDSSUS simPlant model 1. I suggest not naming this the LSC model, since it has no LSC stuff. 2. Also remove all the diagnostic stuff in the plant model. We need nothing except a generic filter Module, like in the SUS controller. 3. Also, the TF looks kind of weird to me. I would like to see how you derive that eq. 4. Connect the models and show us some plots of the behavior in physical units using FOTON to make the filters and diaggui/DTT (at first) to make the plots. 16088 Tue Apr 27 15:15:17 2021 Ian MacMillanUpdateCDSSUS simPlant model The first version of the single filter plant is below. Jon and I went through compiling a model and running it on the docker (see this post) We activated an early version of the plant model (from about 10 years ago) but this model was not designed to run on its own so we had to ground lots of unconnected pieces. the model compiled and ran so we moved on to the x1sus_single_plant model that I prepared. This model is shown in the first attachment wasn't made to be run alone because it is technically a locked library (see the lock in the bottom left). It is supposed to be referenced by another file: x1sup.mdl (see the second attachment). This works great in the Simulink framework. I add the x1sus_single_plant model to the path and Matlab automatically attaches the two. but the docker does not seem to be able to combine the two. Starting the cymac it gives these errors: cymac | Can't find sus_single_plant.mdl; RCG_LIB_PATH=/opt/rtcds/userapps:/opt/rtcds/userapps/lib:/usr/share/advligorts/src/src/epics/simLink/:/usr/share/advligorts/src/src/epics/simLink/lib:/usr/share/advligorts/src/src/epics/simLink cymac | make[1]: *** [Makefile:30: x1sup] Error 2 cymac | make: *** [Makefile:35: x1sup] Error 1 I have tried putting the x1sus_single_plant.mdl file everywhere as well as physically dragging the blocks that I need into the x1sup.mdl file but it always seems to throw an error. Basically, I want to combine them into one file that is not referencing anything other than the CDS library but I cant figure out how to combine them. Okay but the next problem is the medm screen generation. When we had the original 2010 model running the sitemap did not include it. It included models that weren't even running before but not the model Jon and I had added. I think this is because the other models that were not running had medm screens made for them. I need to figure out how to generate those screens. I need to figure out how to use the tool Chris made to auto-generate medm screens from Simulink but I can't seem to figure it out. And honestly, it won't be much use to me until I can actually connect the plant block to its framework. One option is to just copy each piece over one by one. this will take forever but at this point, I am frustrated enough to try it. I'll try to give another update later tonight. Attachment 1: x1sus_single_plant.pdf Attachment 2: x1sup.pdf 16092 Wed Apr 28 18:56:57 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan We took a Supermicro from the lab (along with a keyboard, a mouse, and a screen taken from a table on the Y arm) and placed it near the Acromag chassis. We installed Debian 10 on the machine. I followed the steps on the slow machine wiki for setting up the host machine. Some steps had to be updated. Most importantly, in the new Debian, the network interfaces are given random names like enp3s0 and enp4s0 instead of eth0 and eth1. I updated the wiki accordingly. To operate the chassis using one 15V source I disconnected the +24V cable from the Acromag units and jumpered the +15V wire into the power input instead. I started up the Acromags. They draw 0.7A. I connected an Ethernet cable to the front interface. I checked that all the Acromags are connected to the local network of the host machine by pinging them one by one. 16093 Thu Apr 29 10:51:35 2021 JonUpdateCDSI/O Chassis Assembly ### Summary Yesterday I unpacked and installed the three 18-bit DAC cards received from Hanford. I then repeated the low-level PCIe testing outlined in T1900700, which is expanded upon below. I did not make it to DAC-ADC loopback testing because these tests in fact revealed a problem with the new hardware. After a combinatorial investigation that involved swapping cards around between known-to-be-working PCIe slots, I determined that one of the three 18-bit DAC cards is bad. Although its "voltage present" LED illuminates, the card is not detected by the host in either I/O chassis. I installed one of the two working DACs in the c1bhd chassis. This now 100% completes this system. I installed the other DAC in the c1sus2 chassis, which still requires four more 18-bit DACs. Lastly, I reran the PCIe tests for the final configurations of both chassis. ### PCIe Card Detection Tests For future reference, below is the set of command line tests to verify proper detection and initialization of ADC/DAC/BIO cards in I/O chassis. This summarizes the procedure described in T1900700 and also adds the tests for 18-bit DAC and 32-channel BO cards, which are not included in the original document. Each command should be executed on the host machine with the I/O chassis powered on:$ sudo lspci -v | grep -B 1 xxxx

where xxxx is a four-digit device code given in the following table.

Device Device Code
General Standards 16-bit DAC 3120
General Standards 18-bit DAC 3357
Contec 16-channel BIO 8632
Contec 32-channel BO 86e2

The command will return a two-line entry for each PCIe device of the specified type that is detected. For example, on a system with a single ADC this command should return:

10:04.0 Bridge: PLX Technology, Inc. PCI9056 32-bit 66MHz PCI IOBus Bridge (rev ac)
Subsystem: PLX Technology, Inc. Device 3101
16096   Thu Apr 29 13:41:40 2021 Ian MacMillanUpdateCDSSUS simPlant model

To add the required library: put the .mdl file that contains the library into the userapps/lib folder. That will allow it to compile correctly

I got these errors:

Module ‘mbuf’ symvers file could not be found.
Module ‘gpstime’ symvers file could not be found.
make[1]: *** [Makefile:30: c1sup] Error 2
make: *** [Makefile:35: c1sup] Error 1

I removed all IPC parts (as seen in Attachment 1) and that did the trick. IPC parts (Inter-Process Communication) were how this model was linked to the controller so I don't know how exactly how I can link them now.

I also went through the model and grounded all un-attached inputs and outputs. Now the model compiles

Also, The computer seems to be running very slowly in the past 24 hours. I know Jon was working on it so I'm wondering if that had any impact. I think it has to do with the connection speed because I am connected through X2goclient. And one thing that has probably been said before but I want to note again is that you don't need a campus VPN to access the docker.

Attachment 1: Non-IPC_Plant.pdf
16097   Thu Apr 29 15:11:33 2021 gautamUpdateCDSRFM

The problem here was that the RFM errors cropped up again - seems like it started ~4am today morning judging by TRX trends. Of course without the triggering signal the arm cavity couldn't lock. I rebooted everything (since just restarting the rfm senders/receivers did not do the trick), now arm locking works fine again. It's a bit disappointing that the Rogue Master setting did not eliminate this problem completely, but oh well...

It's kind of cool that in this trend view of the TRX signal, you can see the drift of the ETMX suspension. The days are getting hot again and the temp at EX can fluctuate by >12C between day and night (so the "air-conditioning" doesn't condition that much I guess 😂 ), and I think that's what drives the drift (idk what the transfer function to the inside of the vacuum chamber is but such a large swing isn't great in any case). Not plotted here but i hypothesize TRY levels will be more constant over the day (modulo TT drift which affects both arms).

The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF.

Attachment 1: RFM_errs.png
Attachment 2: Screenshot_2021-04-29_15-12-56.png
16098   Thu Apr 29 16:35:51 2021 YehonathanUpdateCDSUpdated c1auxey wiring plan

I installed the EPICs base, asyn and modbus modules according to Jon's instructions.

Since the modbus configurations files were already writtten for c1auxey1 (see elog 15292) the only thing I did was to change the IP addresses in ETMYaux.cmd to match the actual assigned IPs.

I followed the rest of the instructions as written.

The modbus service was activated succesfully.

The only thing left to do is to change ETMYaux.db to reflect to new channels that were added. I believe these are BI channels named C1:SUS-ETMY_xx_ENABLEMon.

16099   Thu Apr 29 17:43:16 2021 KojiUpdateCDSRFM

The other day I felt hot at the X end. I wondered if the Xend A/C was off, but the switch right next to the SP table was ON (green light).
I could not confirm if the A/C was actually blowing or not.

16100   Thu Apr 29 17:43:48 2021 AnchalUpdateCDSF2A Filters double check

I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere?

 Quote: The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF.
Attachment 1: F2AFiltersON.png
16103   Thu Apr 29 19:55:45 2021 YehonathanUpdateCDSUpdated c1auxey wiring plan

We received a stock of DB9 male feed-through connectors. That allowed me to complete the remaining wiring on the c1auxey Acromag chassis. The only thing left to be done is the splicing to the RTS.

16105   Fri Apr 30 00:20:30 2021 gautamUpdateCDSF2A Filters double check

The SDF system is supposed to help with restoring the correct settings, complementary to burt. My personal opinion is that there is no need to commit these filters to SDF until we're convinced that they help with the locking / noise performance.

 Quote: I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere
16106   Fri Apr 30 12:52:14 2021 Ian MacMillanUpdateCDSSUS simPlant model

Now that the model is finally compiled I need to make an medm screen for it and put it in the c1sim:/home/controls/docker-cymac/userapps/medm/ directory.

But before doing that I really want to test it using the autogenerated medm screens which are in the virtual cymac in the folder /opt/rtcds/tst/x1/medm/x1sup. In Jon's post he said that I can use the virtual path for sitemap after running $eval$(./env_cymac)

16107   Fri Apr 30 19:18:51 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

We finished the installation procedure on the c1auxey1 host machine. There were some adjustments that had to be made for Debian 10. The slow machine wiki page has been updated.

A test database file was made were all the channel names were changed from C1 to C2 in order to not interfere with the existing channels.

We starting testing the channels one by one to check the wiring and the EPICs software. We found some misswirings and fixed them.

 Channel Name Type EPICs Test Acromag windows software test C2:SUS-ETMY_ULPDMon AI Pass Pass C2:SUS-ETMY_URPDMon AI Pass Pass C2:SUS-ETMY_LLPDMon AI Pass Pass C2:SUS-ETMY_SPDMon AI Pass Pass C2:SUS-ETMY_LRPDMon AI Pass Pass C2:SUS-ETMY_ULVMon AI Pass Pass C2:SUS-ETMY_URVMon AI Pass Pass C2:SUS-ETMY_LLVMon AI Pass Pass C2:SUS-ETMY_SideVMon AI Pass Pass C2:SUS-ETMY_LRVMon AI Pass Pass

Its getting late. I'll continue with the rest of the channels on Monday.

Notice that for all the AI channels the RTN was disconnected while testing.

16109   Mon May 3 13:35:12 2021 Ian MacMillanUpdateCDSSUS simPlant model

When the cymac is started it gives me a list of channels shown below.

 $Initialized TP interface node=8, host=98e93ecffcca$  Creating X1:DAQ-DC0_X1IOP_STATUS  $Creating X1:DAQ-DC0_X1IOP_CRC_CPS$  Creating X1:DAQ-DC0_X1IOP_CRC_SUM  $Creating X1:DAQ-DC0_X1SUP_STATUS$  Creating X1:DAQ-DC0_X1SUP_CRC_CPS  $Creating X1:DAQ-DC0_X1SUP_CRC_SUM But when I enter it into the Diaggui I get an error: The following channel could not be found: X1:DAQ-DC0_X1SUP_CRC_CPS My guess is that need to connect to the Diaggui to something that can access those channels. I also need to figure out what those channels are. 16114 Mon May 3 20:36:46 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled. We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way. The digital input channels were still not working. This is a software issue that we will have to deal with later. (Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes. 16116 Tue May 4 07:38:36 2021 JonUpdateCDSI/O Chassis Assembly ### IOP models created With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested. Model Host CPU DCUID c1x06 c1bhd 1 23 c1x07 c1sus2 1 24 The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet. ### Timing system set-up The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days. Attachment 1: Screen_Shot_2021-05-03_at_4.16.06_PM.png 16118 Tue May 4 14:55:38 2021 Ian MacMillanUpdateCDSSUS simPlant model After a helpful meeting with Jon, we realized that I have somehow corrupted the sitemap file. So I am going to use the code Chris wrote to regenerate it. Also, I am going to connect the controller using the IPC parts. The error that I was having before had to do with the IPC parts not being connected properly. 16122 Wed May 5 15:11:54 2021 Ian MacMillanUpdateCDSSUS simPlant model I added the IPC parts back to the plant model so that should be done now. It looks like this again here. I can't seem to find the control model which should look like this. When I open sus_single_control.mdl, it just shows the C1_SUS_SINGLE_PLANT.mdl model. Which should not be the case. 16124 Thu May 6 16:13:24 2021 Ian MacMillanUpdateCDSSUS simPlant model When using mdl2adl I was getting the error: $  cd /home/controls/mdl2adl $./mdl2adl x1sup.mdl error: set$site and $ifo environment variables to set these in the terminal use the following commands: $  export site=tst $export ifo=x1 On most of the systems, there is a script that automatically runs when a terminal is opened that sets these but that hasn't been added here so you must run these commands every time you open the terminal when you are using mdl2adl. 16126 Fri May 7 11:19:29 2021 Ian MacMillanUpdateCDSSUS simPlant model I copied c1scx.mdl to the docker to attach to the plant using the commands: $  ssh nodus.ligo.caltech.edu [Enter Password] $cd opt/rtcds/userapps/release/isc/c1/models/simPlant$  scp c1scx.mdl controls@c1sim:/home/controls/docker-cymac/userapps
16130   Tue May 11 16:29:55 2021 JonUpdateCDSI/O Chassis Assembly
Quote:

### Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Today I brought and installed the new optical transceivers (Finisar FTLF1217P2BTL) for the two timing slaves. The timing slaves appear to phase-lock to the clocking signal from the master fanout. A few seconds after each timing slave is powered on, its status LED begins steadily blinking at 1 Hz, just as in the existing 40m systems.

However, some other timing issue remains unresolved. When the IOP model is started (on either FE), the DACKILL watchdog appears to start in a tripped state. Then after a few minutes of running, the TIM and ADC indicators go down as well. This makes me suspect the sample clocks are not really phase-locked. However, the models do start up with no error messages. Will continue to debug...

Attachment 1: Screen_Shot_2021-05-11_at_3.03.42_PM.png
16131   Tue May 11 17:43:09 2021 KojiUpdateCDSI/O Chassis Assembly

Did you match the local PC time with the GPS time?

16134   Wed May 12 13:06:15 2021 Ian MacMillanUpdateCDSSUS simPlant model

Working with Chris, we decided that it is probably better to use a simple filter module as a controller before we make the model more complicated. I will use the plant model that I have already made (see attachment 1 of this). then attach a single control filter module to that: as seen in attachment 1. because I only want to work with one degree of freedom (position) I will average the four outputs which should give me the position. Then by feeding the same signal to all four inputs I should isolate one degree of freedom while still using the premade plant model.

The model I made that is shown in attachment 2 is the model I made from the plan. And it complies! yay! I think there is a better way to do the average than the way I showed. And since the model is feeding back on itself I think I need to add a delay which Rana noted a while ago. I think it was a UnitDelay (see page 41 of RTS Developer’s Guide). So I will add that if we run into problems but I think there is enough going on that it might already be delayed.

Since our model (x1sup_isolated.mdl) has compiled we can open the medm screens for it. I provide a procedure below which is based on Jon's post

[First start the cymac and have the model running]
$cd docker-cymac$  eval $(./env_cymac) $  medm -x /opt/rtcds/tst/x1/medm/x1sup_isolated/X1SUP_ISOLATED_GDS_TP.adl

To see a list of all medm screens use:

$cd docker-cymac$  ./login_cymac  #  cd /opt/rtcds/tst/x1/medm/x1sup_isolated  #  ls

Some of the other useful ones are:

 adl screen Description X1SUP_ISOLATED_Control_Module.adl This is the control filter module shown in attachment 2 at the top in the center. This module will represent the control system. X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod.adl See attachment 4. This screen shows the POS plant filter module that will be filled by the filter representing the transfer function of a damped harmonic oscillator:        $\frac{x}{F}=\frac{\omega_0^2}{\omega_0^2+i\frac{\omega_0 \omega}{Q}-\omega^2}$ THIS TF HAS BEEN UPDATED SEE NEXT POST

The first one of these screens that are of interest to us (shown in attachment 3) is the X1SUP_ISOLATED_GDS_TP.adl screen, which is the CDS runtime diagnostics screen. This screen tells us "the success/fail state of the model and all its dependencies." I am still figuring out these screens and the best guide is T1100625.

The next step is taking some data and seeing if I can see the position damp over time. To do this I need to:

1. Edit the plant filter for the model and add the correct filter.
2. Figure out a filter for the control system and add it to that. (I can leave it as is to see what the plant is doing)
3. Take some position data to show that the plant is a harmonic oscillator and is damping away.
Attachment 1: SimplePlant_SingleContr.pdf
Attachment 2: x1sup_isolated.pdf
Attachment 3: X1SUP_ISOLATED_GDS_TP.png
Attachment 4: X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod.png
16151   Fri May 21 09:44:52 2021 Ian MacMillanUpdateCDSSUS simPlant model

The transfer function given in the previous post was slightly incorrect the units did not make sense the new function is:

$\frac{x}{F}=\frac{1}{m\omega_0^2-m\omega^2+im\frac{\omega_0 \omega }{Q}}$

I have attached a quick derivation below in attachment 1

Attachment 1: Transfer_Function_of_Damped_Harmonic_Oscillator.pdf
16153   Fri May 21 14:36:20 2021 Ian MacMillanUpdateCDSSUS simPlant model

The plant transfer function of the pendulum in the s domain is:

$H(s)=\frac{x(s)}{F(s)}=\frac{1}{ms^2+m\frac{\omega_0}{Q}s+m\omega_0^2}$

Using Foton to make a plot of the TF needed and using m=40kg, w0=3Hz, and Q=50 (See attachment 1). It is easiest to enter the above filter using RPoly and saved it as Plant_V1

Attachment 1: Plant_Mod_TF.pdf
16154   Sun May 23 18:28:54 2021 JonUpdateCDSOpto-isolator for c1auxey

The new HAM-A coil drivers have a single DB9 connector for all the binary inputs. This requires that the dewhitening switching signals from the fast system be spliced with the coil enable signals from c1auxey. There is a common return for all the binary inputs. To avoid directly connecting the grounds of the two systems, I have looked for a suitable opto-isolator for the c1auxey signals.

I best option I found is the Ocean Controls KTD-258, a 4-channel, DIN-rail-mounted opto-isolator supporting input/output voltages of up to 30 V DC. It is an active device and can be powered using the same 15 V supply as is currently powering both the Acromags and excitation. I ordered one unit to be trialed in c1auxey. If this is found to be good solution, we will order more for the upgrades of c1auxex and c1susaux, as required for compatibility with the new suspension electronics.

16166   Fri May 28 10:54:59 2021 JonUpdateCDSOpto-isolator for c1auxey

I have received the opto-isolator needed to complete the new c1auxey system. I left it sitting on the electronics bench next to the Acromag chassis.

Here is the manufacturer's wiring manual. It should be wired to the +15V chassis power and to the common return from the coil driver, following the instructions herein for NPN-style signals. Note that there are two sets of DIP switches (one on the input side and one on the output side) for selecting the mode of operation. These should all be set to "NPN" mode.

Attachment 1: optoisolator.jpeg
16167   Fri May 28 11:16:21 2021 JonUpdateCDSFront-End Assembly and Testing

An update on recent progress in the lab towards building and testing the new FEs.

### 1. Timing problems resolved / FE BIOS changes

The previously reported problem with the IOPs losing sync after a few minutes (16130) was resolved through a change in BIOS settings. However, there are many required settings and it is not trivial to get these right, so I document the procedure here for future reference.

The CDS group has a document (T1300430) listing the correct settings for each type of motherboard used in aLIGO. All of the machines received from LLO contain the oldest motherboards: the Supermicro X8DTU. Quoting from the document, the BIOS must be configured to enforce the following:

• Remove hyper-threading so the CPU doesn’t try to run stuff on the idle core, as hyperthreading simulate two cores for every physical core.
• Minimize any system interrupts from hardware, such as USB and Serial Ports, that might get through to the ‘idled’ core. This is needed on the older machines.
• Prevent the computer from reducing the clock speed on any cores to ‘save power’, etc. We need to have a constant clock speed on every ‘idled’ CPU core.

I generally followed the T1300430 instructions but found a few adjustments were necessary for diskless and deterministic operation, as noted below. The procedure for configuring the FE BIOS is as follows:

1. At boot-up, hit the delete key to enter the BIOS setup screen.
2. Before changing anything, I recommend photographing or otherwise documenting the current working settings on all the subscreens, in case for some reason it is necessary to revert.
3. T1300430 assumes the process is started from a known state and lists only the non-default settings that must be changed. To put the BIOS into this known state, first navigate to Exit > Load Failsafe Defaults > Enter.
4. Configure the non-default settings following T1300430 (Sec. 5 for the X8DTU motherboard). On the IPMI screen, set the static IP address and netmask to their specific assigned values, but do set the gateway address to all zeros as the document indicates. This is to prevent the IPMI from trying to initiate outgoing connections.
5. For diskless booting to continue to work, it is also necessary to set Advanced > PCI/PnP Configuration > Load Onboard LAN 1 Option Rom > Enabled.
6. I also found it was necessary to re-enable IDE direct memory access and WHEA (Windows Hardware Error Architecture) support. Since these machines have neither hard disks nor Windows, I have no idea why these are needed, but I found that without them, one of the FEs would hang during boot about 50% of the time.
• Advanced > PCI/PnP configuration > PCI IDE BusMaster  > Enabled.
• Advanced > ACPI Configuration > WHEA Support > Enabled.

After completing the BIOS setup, I rebooted the new FEs about six times each to make sure the configuration was stable (i.e., would never hang during boot).

### 2. User models created for FE testing

With the timing issue resolved, I proceeded to build basic user models for c1bhd and c1sus2 for testing purposes. Each one has a simple structure where M ADC inputs are routed through IIR filters to an output matrix, which forms linear signal combinations that are routed to N DAC outputs. This is shown in Attachment 1 for the c1bhd case, where the signals from a single ADC are conditioned and routed to a single 18-bit DAC. The c1sus2 case is similar; however the Contec BO modules still needed to be added to this model.

The FEs are now running two models each: the IOP model and one user model. The assigned parameters of each model are documented below.

Model Host CPU DCUID Path
c1x06 c1bhd 1 23 /opt/rtcds/userapps/release/cds/c1/models/c1x06.mdl
c1x07 c1sus2 1 24 /opt/rtcds/userapps/release/cds/c1/models/c1x07.mdl
c1bhd c1bhd 2 25 /opt/rtcds/userapps/release/isc/c1/models/c1bhd.mdl
c1sus2 c1sus2 2 26 /opt/rtcds/userapps/release/sus/c1/models/c1sus2.mdl

The user models were compiled and installed following the previously documented procedure (15979). As shown in Attachment 2, all the RTS processes are now working, with the exception of the DAQ server (for which we're still awaiting hardware). Note that these models currently exist only on the cloned copy of the /opt/rtcds disk running on the test stand. The plan is to copy these models to the main 40m disk later, once the new FEs are ready to be installed.

### 3. AA and AI chassis installed

I installed several new AA and AI chassis in the test stand to interface with the ADC and DAC cards. This includes three 16-bit AA chassis, one 16-bit AI chassis, and one 18-bit AI chassis, as pictured in Attachment 3. All of the AA/AI chassis are powered by one of the new 15V DC power strips connected to a bench supply, which is housed underneath the computers as pictured in Attachment 4.

These chassis have not yet been tested, beyond verifying that the LEDs all illuminate to indicate that power is present.

Attachment 1: c1bhd.png
Attachment 2: gds_tp.png
Attachment 3: teststand.jpeg
Attachment 4: bench_supply.jpeg
16177   Thu Jun 3 13:06:47 2021 Ian MacMillanUpdateCDSSUS simPlant model

I was able to measure the transfer function of the plant filter module from the channel X1:SUP-C1_SUS_SINGLE_PLANT_Plant_POS_Mod_EXC to X1:SUP-C1_SUS_SINGLE_PLANT_Plant_POS_Mod_OUT. The resulting transfer function is shown below. I have also attached the raw data for making the graph.

Next, I will make a script that will make the photon filters for all the degrees of freedom and start working on the matrix version of the filter module so that there can be multiple degrees of freedom.

Attachment 1: SingleSusPlantTF.pdf
Attachment 2: SUS_PLANT_TF.zip
16178   Thu Jun 3 17:15:17 2021 YehonathanUpdateCDSOpto-isolator for c1auxey

As Jon wrote we need to use the NPN configuration (see attachments). I tested the isolator channels in the following way:

1. I connected +15V from the power supply to the input(+) contact.

2. Signal wire from one of the digital outputs was connected to I1-4

3. When I set the digital output to HIGH, the LED on the isolator turns on.

4. I measure the resistance between O1-4 to output(-) and find it to be ~ 100ohm in the HIGH state and an open circuit in the LOW state, as expected from an open collector output.

Unlike the Acromag output, the isolator output is not pulled up in the LOW state. To do so we need to connect +15V to the output channel through a pull-up resistor. For now, I leave it with no pull-up. According to the schematics of the HAM-A Coil Driver, the digital output channels drive an electromagnetic relay (I think) so it might not need to be pulled up to switch back. I'm not sure. We will need to check the operation of these outputs at the installation.

During the testing of the isolator outputs pull-up, I accidentally ran a high current through O2, frying it dead. It is now permanently shorted to the + and - outputs rendering it unusable. In any case, we need another isolator since we have 5 channels we need to isolate.

I mounted the isolator on the DIN rail and started wiring the digital outputs into it. I connected the GND from the RTS to output(-) such that when the digital outputs are HIGH the channels in the coil driver will be sunk into the RTS GND and not the slow one avoiding GND contamination.

Attachment 1: Optical_Isolator_NPN_Input.png
Attachment 2: Optical_Isolator_NPN_Output.png
16181   Thu Jun 3 22:08:00 2021 KojiUpdateCDSOpto-isolator for c1auxey

- Could you explain what is the blue thing in Attachment 1?

- To check the validity of the signal chain, can you make a diagram summarizing the path from the fast BO - BO I/F - Acromag - This opto-isolator - the coil driver relay? (Cut-and-paste of the existing schematics is fine)

ELOG V3.1.3-