40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 223 of 344 Not logged in
ID Date Author Type Category Subject
4814   Tue Jun 14 09:24:36 2011 steveConfigurationPhotosSUS binary IO chassis 2 and 3 moved from 1X5 to 1X4

 Quote: While preping 1X4 for installation of c1lsc, we removed some old VME crates that were no longer in use.  This freed up lots of space in 1X4.  We then moved the SUS binary IO chassis 2 and 3, which plug into the 1X4 cross-connect, from 1X5 into the newly freed space in 1X4.  This makes the cable run from these modules to the cross connect much cleaner.

Are we keeping these?

6182   Mon Jan 9 23:52:15 2012 kiwamuUpdateCDSSUS channels not accessible from dataviewer

[John / Kiwamu]

We found that some of the suspensions channels (for example C1:SUS-BS_POS_IN1 and etc) were not accessible from dataviewer for some reasons.

So far it seems none of the channels associated with c1sus are accessible from dataviewer.

4780   Thu Jun 2 16:23:42 2011 JamieUpdateSUSSUS control models updated to use new sus_single_control library part

A new library part was made for the single suspension controller (it was originally made from the c1scx controller), using the following procedure:

1. Opened c1scx model (userapps/trunk/sus/c1/models/c1scx)
2. Cut ETMX subsystem block out of SUS subsystem
3. Pasted ETMX block into new empty library, and renamed it C1_SUS_SINGLE_CONTROL
4. Tweaked names of inputs, and generally cleaned up internals (cosmetically)
5. Saved library to: userapps/trunk/sus/c1/models/lib/sus_single_control.mdl

Once the new sus_single_control library part was made and the library was committed to the cds_user_apps repo, I replaced all sus controller subsystems with this new part, in:

• c1scx
• c1scy
• c1sus (x5 for each vertex mass)

All models were rebuild, installed, and tested, and everything seems to be working fine.

12315   Wed Jul 20 13:58:55 2016 SteveUpdateSUSSUS damping out of vac chamber

Cheater cable to be used in clean room pitch gluing alingment.

Satelite amp needs to be there.

Atm 2-3, The ETMs  suspension damping cable  are connected at the end racks. All others go to 1X5

Atm 4-5, The other end of this cable in the high cable tray at 1X3 as shown. We'll disconnect the shorty and move the end to ETMX ( or any sus at 1X5 )

5461   Mon Sep 19 15:41:48 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

The following optics were kicked:
ETMX
Mon Sep 19 15:39:44 PDT 2011
1000507199

5471   Mon Sep 19 22:47:44 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

The last person out tonight should run the following scripts:

In Matlab:

/opt/rtcds/caltech/c1/scripts/SUS/peakFit/writeMultiSUSinmat.m

In command line:

/opt/rtcds/caltech/c1/scripts/SUS/freeswing all

Then in the morning, someone should do a BURT restore to early today (to get the default matricies back), and also restore the watchdogs.

Thanks!

5485   Tue Sep 20 16:45:09 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

Has the Q been checked?  Still in progress...

 Optic POS PIT YAW SIDE ITMX done done done done ITMY done done fine?? done ETMX done done done done ETMY done done done done BS done done done done PRM done done done done SRM done done done done MC1 MC2 MC3

So, update as of 6:17pm:  I have tuned the damping gains for all IFO optics.  Everything is good, except for ITMY Yaw.  It's probably fine, the optic damps okay, but it doesn't look like a nice clean ringdown.  I haven't taken the time to go back and look at it again.

I have to go to a dinner, but later (probably in the morning, so I don't disturb evening locking) I'll check the MC Qs.

5493   Wed Sep 21 00:34:29 2011 ranaUpdateSUSSUS diag stuff... just so I remember what I'm doing

ETMX was ringing up when it was mis-aligned for Y arm locking. I restored the input matrix to something more diagonal and its now damping again. Needs more work before we can use the calculated matrix.

11569   Thu Sep 3 19:52:24 2015 ranaSummarySUSSUS drift monitor

Since Andrey's SUS Drift mon screen back in 2007, we've had several versions which used different schemes and programming languages. Diego made an update back in January.

Today I added his stuff to the SVN since it was lost in the NFS disks somewhere. Its in SUS/DRIFT_MON/.

Since we've been updating our userapps directory recently to pull in the screens and scripts from the sites, we also got a copy of the Thomas Abbott drift mon stuff which is better (Diego actually removed the yellow/red functionality as part of the 'upgrade'), but more complicated. For now we have the old one. I updated the good values with all optics roughly aligned just a few minutes ago.

2901   Sun May 9 20:02:23 2010 ranaConfigurationSUSSUS filters deleted again to reduce CPU load on c1susvme2 again

On Friday, I deleted a bunch of filters from the c1susvme2 optics' screens (MC1,2,3 + SRM) so as to reduce the CPU load and keep it from going bonkers.

This first plot shows the CPU trend over the last 40 days and 40 nights. As you can see the CPU_LOAD has dropped by 1 us since I did the deleting.

In the second plot (on the right) you can see the same trend but over 400 days and nights. Of course, we hope that we throw this away soon, but until then it will be nice to have the suspensions be working more often.

16997   Wed Jul 13 12:49:25 2022 PacoSummarySUSSUS frozen

[Paco, JC, Yuta]

This morning, while investigating the source of a burning smell, we turned off the c1SUS 1X4 power strip powering the sorensens. After this, we noticed the MC1 refl was not on the camera, and in general other vertex SUS were misaligned even though JC had aligned the IFO in the morning to almost optimum arm cavity flashing. After a c1susaux modbusIOC service restart and burt restore, the problem persisted.

We started to debug the sus rack chain for PRM since the oplev beam was still near its alignment so we could use it as a sensor. The first weird thing we noticed was that no matter how much we "kicked" PRM, we wouldn't see any motion on the oplev. We repeatedly kicked UL coil and looked at the coil driver inputs and outputs, and also verified the eurocard had DC power on which it did. Somehow disconnecting the acromag inputs didn't affect the medm screen values, so that made us suspicious that something was weird with these ADCs.

Because all the slow channels were in a frozen state, we tried restarting c1susaux and the acromag chassis and this fixed the issue.

5766   Sun Oct 30 23:03:37 2011 SUS_DiagonalizerUpdateSUSSUS input matrix diagonalization complete (EXAMPLE)
New SUS input matrix diagonalization complete. Matrices have been written to the frontend. Summaries for each optic can be viewed below.

(THIS IS AN EXAMPLE---no new matrices have been written.)
5775   Tue Nov 1 13:46:03 2011 ZachUpdateSUSSUS input matrix diagonalizer REMOVED from crontab

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

5770   Mon Oct 31 14:06:16 2011 ZachUpdateSUSSUS input matrix diagonalizer added to crontab

I actually tried to do this last night, but I was getting a terminal error from nodus. Jamie told me to just manually redefine the TERM variable and it would work. So, I have added kickAll and diagAllSUS to controls@nodus's crontab:

nodus:~>crontab -l

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

0 7 * * * /opt/rtcds/caltech/c1/scripts/backup/check_backup.sh

0 17 * * 0 /cvs/cds/caltech/users/jenne/LIGOX/LIGOX_Pizza_Reminders.sh

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

Again, their functionality should be checked before this is allowed to run on Sunday!

15836   Tue Feb 23 23:12:37 2021 KojiSummarySUSSUS invacuum wiring

This is my current understanding of the in-vacuum wiring:
1. Facts

• We have the in-air cable pinout. And Gautam recently made a prototype of D2100014 custom cable, and it worked as expected.
• The vacuum feedthrough is a wall with the male pins on the both sides. This mirrors pinout.
• On the in-vacuum cable stand (bracket), the cable has a female connector.

2. From the above facts, the in-vacuum cable is

• DSUB25 female-female cable
• There is no pinout mirroring

Accuglass has the DSUB25 F-F cable off-the-shelf. However, this cable mirrors the pinout (see the datasheet on the pdf in the following link)
https://www.accuglassproducts.com/connector-connector-extension-cable-25-way-female

3. The options are
- ask Accuglass to make a twisted version so that the pinout is not mirrored.

or
- combine Accuglass female-male cable (https://www.accuglassproducts.com/connector-connector-extension-cable-25-way-femalemale) and a gender changer (https://www.accuglassproducts.com/gender-adapter-25d)

4. The length will be routed from the feedthrough to the table via the stacks like a snake to be soft. So, it will require some extra length.

5. Also, the Accuglass cables don't have a flap and holes to fix the connector to a cable post (tower). If we use a conventional 40m-style DSUB25 post (D010194), it will be compatible with their cables. But this will not let us use a DSUB25 male connector to mate. In the future, the suspension will be upgraded and we will need an updated cable post that somehow holds the connectors without fastening the screws...

6365   Tue Mar 6 16:17:36 2012 JenneUpdateSUSSUS matrix diagonalization status

Has default inmat:

PRM, ITMX

Has fancy inmat:

BS, ITMY, SRM (but side is non-fancy), ETMX, ETMY, MC1, MC2, MC3

So it's likely that the MICH problems (giganto 1Hz peak) Keiko and Kiwamu were seeing last night had to do with ITMX having the non-optimized input matrix.  I'll try to figure out where the data from the last freeswing test is, and put in a fancy diagonalized matrix.

Rana asked me to look at the SUS MEDM screen upgrade situation, and provide an upgrade prescription.  Unfortunately there not really a simple prescription that can be used, since our configuration diverges quite a bit from what's at the sites.  But here's what I can say:

It looks like we already have the beginnings of an upgrade in place, so I say we just run with that.  The new screens are in:

/opt/rtcds/userapps/release/sus/c1/medm/new


The primary screen is:

/opt/rtcds/userapps/release/sus/c1/medm/new/OVERVIEW.adl


This seems to be a copy of the site ASC_TIPTILT screens.  (In fact I think I remember putting this here).  I went ahead and did some ground work to make it easier to get these new screens into place.

• I cleaned up all the channel name prefixes so that at least the channel prefixes will resolve to our SUS channels.
• I made a link from the sitemap with some of the correct macros to fill some things in appropriately: "IFO SUS/NEW ETMX"
• I fixed the names to the sub-screens, so that it correctly opens the correct sub-screens (although the macros seem to not be passed correctly)

At this point someone needs to just go through and fix all the channel names to match ours, and tweak the screen to our needs (there's no side OSEM, for instance).  The subscreens need to be cleaned up as well.

### sed replace string

If there is a specific string you want to replace every instance of in the screen, you can do that easily from the command line like this:

sed -i 's/OLD/NEW/g'

This will replace every instance of the string OLD with the string new in the file path/to/file.  Be careful: this will replace EVERY instance of OLD.  If OLD matches things you don't want, they will be replaced as well.

This construction is actually "regular expressions", so if you want to get fancy you can match against more complicated strings.  But just be careful.

If you leave out the "-i" the string-replaced text will go to stdout, instead of being replaced in the file "in place", so you can check it first.

### query replace in emacs

If you want more fine-grained control of text replace, so that you can see what's being replaced, try using "query-replace" in emacs:

M-x query-replace

You can then type in the original string, followed by the replacement string.  When it starts to run it will highlight the string that will be replaced.  Hit "space" to accept or "n" to skip and go to the next.

13221   Wed Aug 16 20:01:03 2017 gautamUpdateGeneralSUS model ASC input weirdness

I'm not sure if this has something to do with the model restarts / new RCG, but while I was re-enabling the MC watchdogs, I noticed the RMS sensor voltage channels on ITMX hovering around ~100mV, even though local damping was on (in which configuration I would expect <1mV if everything is working normally).  I was confused by this behaviour, and after staring at the ITMX suspension screen for a while, I noticed that the input to the "ASCP" and "ASCY" servos were "-nan", and the outputs were 10^20 cts  (see Attachment #1).

Digging a little deeper, I found that the same problem existed on ITMY, ETMX, ETMY, PRM (but not BS or SRM) - reasons unknown for now.

I have to check where this signal is coming from, but for now I just turned the "ASC Input" switch off. More investigation to be done, but in the meantime, ASS dither alignment may not be possible.

After consulting with Jamie, I have just disabled all outputs to the suspensions other than local damping loop outputs. I need to figure out how to get this configuration into the safe.snap file such that until we are sure of what is going on, the models start up in this safer configuration.

gedit 28 Oct 0026: Seems like this problem is seen at the sites as well. I wonder if the problem is related.

13228   Fri Aug 18 21:58:35 2017 gautamUpdateGeneralSUS model ASC input weirdness

I spent some time today trying to debug this issue.

Jamie and I had opened up the c1sus frontend to try and replace the RFM card before we realized that the problem was in the RCG code generator. During this process, we had disconnected all of the back-panel cabling to this machine (2 ethernet cables, dolphin cable, and RFM cables/fibers). I thought I may have accidentally returned the cables to the wrong positions - but all the status indicator lights indicate that everything is working as it should, and I also confirmed that the cabling is as it is in the pictures of the rack on the wiki page.

Looking at the SimuLink model diagram (see Attachment #1 for example), it looks like (at least some of) these channels are actually on the dolphin network, and not the RFM network (with which we were experiencing problems). This suggests that the problem is something deeper. Although I did see nans in some of the ETMX ASC channels as well, for which the channels are piped over the RFM network. Even more puzzling is that the ASC MEDM screen (Attachment #3) and the SimuLink diagram (Attachment #2) suggest that there is an output matrix in between the input signals and the output angular control signals to the suspensions. As Attachment #4 shows, the rows corresponding to ITMX PIT and YAW are zero (I confirmed using z read <matrixElement>). Attachment #3 shows that the output of all the servo banks except CARM_YAW is zero, but CARM_YAW has no matrix element going to the ITMs (also confirmed with z read <servoOutputChannel>). So 0 x 0 should be 0, but for some reason the model doesn't give this output?

GV Edit: As EricQ just pointed out to me, nan x 0 is still nan, which probably explains the whole issue. Poking a little further, it seems like this is an SDF issue - the SDF table isn't able to catch differences for this hold output channel.

As I was writing this elog, I noticed that, as mentioned above, the CARM_YAW output was "nan". When I restart the model (thankfully this didn't crash c1lsc!), it seems to default to this state. Opening up the filter module, I saw that the "hold output" was enabled.

## Toggling that switch made the nans in all the SUS ASC channels disappear. Mysterious .

All the points above stand - CARM_YAW output shouldn't have been going anywhere as per the output matrix, but it seems to have been responsible? Seems like a bug in any case if a model restarts with a field as "nan".

Anyways the problem seems to have been resolved so I'm going to try locking and dither aligning the arms now.

Rolf mentioned that a simple update could fix several of the CDS issues we are facing (e.g. inability to open up testpoints), but he didn't seem to have any insight into this particular issue. Jamie will try and recompile all the models and then we have to see if that fixes the remaining problems.

 Quote: I have to check where this signal is coming from, but for now I just turned the "ASC Input" switch off. More investigation to be done, but in the meantime, ASS dither alignment may not be possible. After consulting with Jamie, I have just disabled all outputs to the suspensions other than local damping loop outputs. I need to figure out how to get this configuration into the safe.snap file such that until we are sure of what is going on, the models start up in this safer configuration.

4967   Thu Jul 14 15:27:08 2011 steve,UpdateSUSSUS oplev spectras

Quote:

Quote:

 Quote: Healthy BS oplev

I repeated the BS oplev spectrum today and I do not understand why it does look different. I did it as Kiwamu describes it in entry#4948  The oplev servo was left ON!

It is working today! Finally I repeated the BS spectra, that we did with Kiwamu last week

The optical levers were centered during these measurements  without the reference of locked cavities.  They have no reference value now.

SRM sus need some help. ITMX is showing pitch/yaw modes of the pendulum .....OSEM damping is weak?

4972   Fri Jul 15 09:25:02 2011 ranaUpdateSUSSUS oplev spectras

In addition to the OL quadrants, you need to plot the OPLEV_PERROR and OPLEV_YERROR signals since these are the real signals we use for finding the mirror motion. If they're not in the Dataviewer, Jamie should add them as 256 Hz DAQ channels (using these names so that we have the continuity with the past). These DAQ channels correspond to the IN1 channels for the OL filter banks.

Also JPG are banned from the elog - you should put all of the plots into a single, multipage PDF file in honor of the new Wagonga.

16553   Thu Jan 6 22:18:47 2022 KojiUpdateCDSSUS screen debugging

Indicated by the red arrow:
Even when the side damping servo is off, the number appears at the input of the output matrix

Indicated by the green arrows:
The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC.

Indicated by the blue arrows:
This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified.

Indicated by the orange circle:
The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

16570   Tue Jan 11 10:46:07 2022 TegaUpdateCDSSUS screen debugging

Seen. Thanks.

Red Arrow: The channel was labeled incorrectly as INMON instead of OUTPUT

Green Arrow: OK, I will create a custom medm screen for this.

Blue arrow: Hmm, OK I will look into this. Doing this work remotely is a pain as the medm response is quite slow for poking around.

Orange circle: OK, I'll move this to the left side of the line.

Note to self: I also noticed another error on the side (LPYS blue box just b4 the sum). The channel is pointing to YAW instead of the side, so needs to be fixed as well.

 Quote: Indicated by the red arrow: Even when the side damping servo is off, the number appears at the input of the output matrix Indicated by the green arrows: The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC. Indicated by the blue arrows: This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified. Indicated by the orange circle: The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

16611   Fri Jan 21 12:46:31 2022 TegaUpdateCDSSUS screen debugging

All done (almost)! I still have not sorted the issue of pitch and yaw gains growing together when modified using ramping time. Image of custom ADC and DAC panel is attached.

Quote:

Seen. Thanks.

 Quote: Indicated by the red arrow: Even when the side damping servo is off, the number appears at the input of the output matrix Indicated by the green arrows: The face magnets and the side magnets use different ADCs. How about opening a custom ADC panel that accommodates all ADCs at once? Same for the DAC. Indicated by the blue arrows: This button opens a custom FM window. When the pitch gain was modified with a ramping time, the pitch and yaw gain grows at the same time even though only the pitch gain was modified. Indicated by the orange circle: The numbers are not indicated here, but they are input-related numbers (for watchdogging) rather than output-related numbers. It is confusing to place them here.

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.

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.

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)

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. 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
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.
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

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

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.

16191   Mon Jun 7 17:49:19 2021 Ian MacMillanUpdateCDSSUS simPlant model

Added difference to the graph. I included the code so that others could see what it looks like and use it for easy use.

16195   Wed Jun 9 13:50:48 2021 Ian MacMillanUpdateCDSSUS simPlant model

I have attached an updated transfer function graph with the residual easier to see. I thought here I would include a better explanation of what this transfer function was measuring.

This transfer function was mainly about learning how to use DTT and Foton to make and measure transfer functions. Therefore it is just measuring across a single CDS filter block. X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod block to be specific. This measurement shows that the block is doing what I programmed it to do with Foton. The residual is probably just because the measured TF had fewer points than the calculated one.

The next step is to take a closed-loop TF of the system and the control module.

After that, I want to add more degrees of freedom to the model. both in the plant and in the controls.

16201   Tue Jun 15 11:46:40 2021 Ian MacMillanUpdateCDSSUS simPlant model

I have added more degrees of freedom. The model includes x, y, z, pitch, yaw, roll and is controlled by a matrix of transfer functions (See Attachment 2). I have added 5 control filters to individually control UL, UR, LL, LR, and side. Eventually, this should become a matrix too but for the moment this is fine.

Note the Unit delay blocks in the control in Attachment 1. The model will not compile without these blocks.

16230   Wed Jun 30 14:09:26 2021 Ian MacMillanUpdateCDSSUS simPlant model

I have looked at my code from the previous plot of the transfer function and realized that there is a slight error that must be fixed before we can analyze the difference between the theoretical transfer function and the measured transfer function.

The theoretical transfer function, which was generated from Photon has approximately 1000 data points while the measured one has about 120. There are no points between the two datasets that have the same frequency values, so they are not directly comparable. In order to compare them I must infer the data between the points. In the previous post [16195] I expanded the measured dataset. In other words: I filled in the space between points linearly so that I could compare the two data sets. Using this code:

#make values for the comparison tck_mag = splrep(tst_f, tst_mag) # get bspline representation given (x,y) values gen_mag = splev(sim_f, tck_mag) # generate intermediate values dif_mag=[] for x in range(len(gen_mag)):     dif_mag.append(gen_mag[x]-sim_mag[x]) # measured minus predicted tck_ph = splrep(tst_f, tst_ph) # get bspline representation given (x,y) values gen_ph = splev(sim_f, tck_ph) # generate intermediate values dif_ph=[] for x in range(len(gen_ph)):     dif_ph.append(gen_ph[x]-sim_ph[x])

At points like a sharp peak where the measured data set was sparse compared to the peak, the difference would see the difference between the intermediate “measured” values and the theoretical ones, which would make the difference much higher than it really was.

To fix this I changed the code to generate the intermediate values for the theoretical data set. Using the code here:

tck_mag = splrep(sim_f, sim_mag) # get bspline representation given (x,y) values gen_mag = splev(tst_f, tck_mag) # generate intermediate values dif_mag=[] for x in range(len(tst_mag)):     dif_mag.append(tst_mag[x]-gen_mag[x])#measured minus predicted tck_ph = splrep(sim_f, sim_ph) # get bspline representation given (x,y) values gen_ph = splev(tst_f, tck_ph) # generate intermediate values dif_ph=[] for x in range(len(tst_ph)):     dif_ph.append(tst_ph[x]-gen_ph[x])

Because this dataset has far more values (about 10 times more) the previous problem is not such an issue. In addition, there is never an inferred measured value used. That makes it more representative of the true accuracy of the real transfer function.

This is an update to a previous plot, so I am still using the same data just changing the way it is coded. This plot/data does not have a Q of 1000. That plot will be in a later post along with the error estimation that we talked about in this week’s meeting.

The new plot is shown below in attachment 1. Data and code are contained in attachment 2

16289   Mon Aug 23 15:25:59 2021 Ian MacMillanUpdateCDSSUS simPlant model

I am adding a State-space block to the SimPlant cds model using the example Chris gave. I made a new folder in controls called SimPlantStateSpace. wI used the code below to make a state-space LTI model with a 1D pendulum then I converted it to a discrete system using c2d matlab function. Then I used these in the rtss.m file to create the state space code I need in the SimPlantStateSpace_1D_model.h file.

%sys_model.m

Q = 1000; phi = 1/Q; g = 9.806; m = 0.24; % mass of pendulum l = 0.248; %length of pendulum w_0 = sqrt(g/l);

f=16000 %this is the frequency of the channel that will be used

A = [0 1; -w_0^2*(1+1/Q*1i) -w_0/Q] B = [0; 1/m]; C = [1 0]; D = [0]; sys_dc = ss(A,B,C,D)

sys=c2d(sys_dc, 1/f)

This code outputs the discrete state space that is added to the header file attached.

5356   Wed Sep 7 09:21:57 2011 jamieUpdateSUSSUS spectra before close up

Here are all suspension diagonalization spectra before close up. Notes:

• TMX looks the worst, but I think we can live with it. The large glitch in the UL sensor at around 999423150 (#5355) is worrying. However, it seemed to recover. The spectra below were taken from data before the glitch.
• ITMY has a lot of imaginary components. We previously found that this was due to a problem with one of it's whitening filters (#5288). I assume we're seeing the same issue here.
• SRM needs a little more data to be able to distinguish the POS and SIDE peaks, but otherwise it looks ok.
 ITMX       pit     yaw     pos     side    butt UL    0.355   0.539   0.976  -0.500   0.182  UR    0.833  -1.406  -0.307  -0.118   0.537  LR   -1.167   0.055   0.717  -0.445   0.286  LL   -1.645   2.000   2.000  -0.828  -2.995  SD   -0.747   0.828   2.483   1.000  -1.637   8.01148 ITMY        pit     yaw     pos     side    butt UL    1.003   0.577   1.142  -0.038   0.954   UR    0.582  -1.423   0.931  -0.013  -1.031   LR   -1.418  -0.545   0.858   0.008   1.081   LL   -0.997   1.455   1.069  -0.017  -0.934   SD   -0.638   0.797   1.246   1.000   0.264  4.46659 BS        pit     yaw     pos     side    butt UL    1.612   0.656   0.406   0.277   1.031   UR    0.176  -1.344   1.683  -0.058  -0.931   LR   -1.824  -0.187   1.594  -0.086   0.951   LL   -0.388   1.813   0.317   0.249  -1.087   SD    0.740   0.301  -3.354   1.000   0.035   5.49597 PRM        pit     yaw     pos     side    butt UL    0.546   1.436   1.862  -0.345   0.866   UR    1.350  -0.564   0.551  -0.055  -0.878   LR   -0.650  -0.977   0.138   0.023   0.858   LL   -1.454   1.023   1.449  -0.268  -1.398   SD    0.634  -0.620  -0.729   1.000   0.611 5.78216 SRM ETMX        pit     yaw     pos     side    butt UL    0.863   1.559   1.572   0.004   1.029   UR    0.127  -0.441   1.869   0.480  -1.162   LR   -1.873  -0.440   0.428   0.493   0.939   LL   -1.137   1.560   0.131   0.017  -0.871   SD    1.838   3.447  -0.864   1.000  -0.135   5.5259 ETMY        pit     yaw     pos     side    butt UL   -0.337   1.275   1.464  -0.024   0.929   UR    1.014  -0.725   1.414  -0.055  -1.102   LR   -0.649  -1.363   0.536  -0.039   0.750   LL   -2.000   0.637   0.586  -0.007  -1.220   SD    0.057  -0.016   1.202   1.000   0.142   4.22572 MC1        pit     yaw     pos     side    butt UL    0.858   0.974   0.128   0.053  -0.000   UR    0.184  -0.763   0.911   0.018   0.001   LR   -1.816  -2.000   1.872   0.002   3.999   LL   -1.142  -0.263   1.089   0.037   0.001   SD    0.040   0.036  -0.216   1.000  -0.002   5.36332 MC2        pit     yaw     pos     side    butt UL    1.047   0.764   1.028   0.124   0.948   UR    0.644  -1.236   1.092  -0.088  -0.949   LR   -1.356  -0.680   0.972  -0.096   1.007   LL   -0.953   1.320   0.908   0.117  -1.095   SD   -0.092  -0.145  -0.787   1.000  -0.065   4.029 MC3       pit     yaw     pos     side    butt UL    1.599   0.343   1.148   0.168   1.101   UR    0.031  -1.647   1.139   0.202  -1.010   LR   -1.969   0.010   0.852   0.111   0.893   LL   -0.401   2.000   0.861   0.077  -0.995   SD   -0.414   0.392  -1.677   1.000   0.018   3.61734

5247   Tue Aug 16 10:59:06 2011 jamieUpdateSUSSUS update

Data taken from: 997530498+120

Things are actually looking ok at the moment.  "Badness" (cond(B)) is below 6 for all optics.

• We don't have results from PRM since its spectra looked bad, as if it's being clamped by the earthquake stops.
• The SRM matrix definitely looks the nicest, followed by ITMX.  All the other matrices have some abnormally high or low elements.
• cond(B) for ETMY is better than that for SRM, even though the ETMY matrix doesn't look as nice.  Does this mean that cond(B) is not necessarily the best figure of merit, or is there something else that our naive expectation for the matrix doesn't catch?

We still need to go through and adjust all the OSEM ranges once the IFO is aligned and we know what our DC biases are.  We'll repeat this one last time after that.

 TM M cond(B) BS       pit     yaw     pos     side    butt  UL    1.456   0.770   0.296   0.303   1.035    UR    0.285  -1.230   1.773  -0.077  -0.945  LR   -1.715  -0.340   1.704  -0.115   0.951  LL   -0.544   1.660   0.227   0.265  -1.070  SD    0.612   0.275  -3.459   1.000   0.046  5.61948 SRM       pit     yaw     pos     side    butt UL    0.891   1.125   0.950  -0.077   0.984  UR    0.934  -0.875   0.987  -0.011  -0.933  LR   -1.066  -1.020   1.050   0.010   1.084  LL   -1.109   0.980   1.013  -0.056  -0.999  SD    0.257  -0.021   0.304   1.000   0.006   4.0291 ITMX       pit     yaw     pos     side    butt UL    0.436   1.035   1.042  -0.068   0.728  UR    0.855  -0.965   1.137  -0.211  -0.969  LR   -1.145  -1.228   0.958  -0.263   1.224  LL   -1.564   0.772   0.863  -0.120  -1.079  SD   -0.522  -0.763   2.495   1.000  -0.156  4.55925 ITMY       pit     yaw     pos     side    butt UL    1.375   0.095   1.245  -0.058   0.989  UR   -0.411   1.778   0.975  -0.022  -1.065  LR   -2.000  -0.222   0.755   0.006   1.001  LL   -0.214  -1.905   1.025  -0.030  -0.945  SD    0.011  -0.686   0.804   1.000   0.240   4.14139 ETMX       pit     yaw     pos     side    butt UL    0.714   0.191   1.640   0.404   1.052  UR    0.197  -1.809   1.758  -0.120  -1.133  LR   -1.803  -1.889   0.360  -0.109   0.913  LL   -1.286   0.111   0.242   0.415  -0.902  SD    1.823  -3.738  -0.714   1.000  -0.130   5.19482 ETMY       pit     yaw     pos     side    butt UL    1.104   0.384   1.417   0.351   1.013  UR   -0.287  -1.501   1.310  -0.074  -1.032  LR   -2.000   0.115   0.583  -0.045   0.777  LL   -0.609   2.000   0.690   0.380  -1.179  SD    0.043  -0.742  -0.941   1.000   0.338   3.57032

5286   Tue Aug 23 10:38:27 2011 jamieUpdateSUSSUS update

SUS update before closing up:

• MC1, MC2, ITMX look good
• MC3, PRM look ok
• SRM pos and side peaks are too close together to distinguish, so the matrix is not diagnalizable.  I think with more data it should be ok, though.
• all ITMY elements have imaginary components
• ITMY, ETMX, ETMY appear to have modest that swapped position:
• ITMY: pit/yaw
• ETMX: yaw/side
• ETMY: pos/side
• MC3, ETMX, ETMY have some very large/small elements

Not particularly good.  We're going to work on ETMY at least, since that one is clearly bad.

 OPTIC M cond(B) MC1       pit     yaw     pos     side    butt UL    0.733   1.198   1.168   0.050   1.057  UR    1.165  -0.802   0.896   0.015  -0.925  LR   -0.835  -1.278   0.832  -0.002   0.954  LL   -1.267   0.722   1.104   0.032  -1.064  SD    0.115   0.153  -0.436   1.000  -0.044  4.02107 MC2        pit     yaw     pos     side    butt UL    1.051   0.765   1.027   0.128   0.952   UR    0.641  -1.235   1.089  -0.089  -0.942   LR   -1.359  -0.677   0.973  -0.097   1.011   LL   -0.949   1.323   0.911   0.121  -1.096   SD   -0.091  -0.147  -0.792   1.000  -0.066   4.02254 MC3        pit     yaw     pos     side    butt UL    1.589   0.353   1.148   0.170   1.099   UR    0.039  -1.647   1.145   0.207  -1.010   LR   -1.961  -0.000   0.852   0.113   0.896   LL   -0.411   2.000   0.855   0.076  -0.994   SD   -0.418   0.396  -1.624   1.000   0.019 3.60876 PRM       pit     yaw     pos     side    butt UL    0.532   1.424   1.808  -0.334   0.839   UR    1.355  -0.576   0.546  -0.052  -0.890   LR   -0.645  -0.979   0.192   0.015   0.881   LL   -1.468   1.021   1.454  -0.267  -1.391   SD    0.679  -0.546  -0.674   1.000   0.590   5.54281 BS        pit     yaw     pos     side    butt UL    1.596   0.666   0.416   0.277   1.037   UR    0.201  -1.334   1.679  -0.047  -0.934   LR   -1.799  -0.203   1.584  -0.077   0.952   LL   -0.404   1.797   0.321   0.247  -1.077   SD    0.711   0.301  -3.397   1.000   0.034   5.46234 SRM NA NA NA ITMX        pit     yaw     pos     side    butt UL    0.458   1.025   1.060  -0.065   0.753   UR    0.849  -0.975   1.152  -0.199  -0.978   LR   -1.151  -1.245   0.940  -0.243   1.217   LL   -1.542   0.755   0.848  -0.109  -1.052   SD   -0.501  -0.719   2.278   1.000  -0.153 4.4212 ITMY        pit     yaw     pos     side    butt UL    0.164   1.320   1.218  -0.086   0.963   UR    1.748  -0.497   0.889  -0.034  -1.043   LR   -0.252  -2.000   0.782  -0.005   1.066   LL   -1.836  -0.183   1.111  -0.058  -0.929   SD   -0.961  -0.194   1.385   1.000   0.239   4.33051 ETMX        pit     yaw     pos     side    butt UL    0.623   1.552   1.596  -0.033   1.027   UR    0.194  -0.448   1.841   0.491  -1.170   LR   -1.806  -0.478   0.404   0.520   0.943   LL   -1.377   1.522   0.159  -0.005  -0.860   SD    1.425   3.638  -0.762   1.000  -0.132   4.89418 ETMY        pit     yaw     pos     side    butt UL    0.856   0.007   1.799   0.241   1.005   UR   -0.082  -1.914  -0.201  -0.352  -1.128   LR   -2.000   0.079  -0.104  -0.162   0.748   LL   -1.063   2.000   1.896   0.432  -1.119   SD   -0.491  -1.546   2.926   1.000   0.169   9.11516

7548   Mon Oct 15 14:51:16 2012 JenneUpdateSUSSUS were kicked hard as a result

 Quote: Apparently all of the ION pump valves (VIPEE, VIPEV, VIPSV, VIPSE) opened, which vented the main volume up to 62 mTorr.  All of the annulus valves (VAVSE, VAVSV, VAVBS, VAVEV, VAVEE) also appeared to be open.  One of the roughing pumps was also turned on.  Other stuff we didn't notice?  Bad.

Several of the suspensions were kicked pretty hard (600+ mV on some sensors) as a result of this quick vent wind.  All of the suspensions are damped now, so it doesn't look like we suffered any damage to suspensions.

636   Sun Jul 6 16:17:40 2008 tobinHowToComputersSVN
I was able to check out the 40m SVN here in Livingston using this command:

svn co svn+ssh://controls@nodus.ligo.caltech.edu/cvs/cds/caltech/svn/trunk/medm

As you might guess, this uses ssh in place of the web server (which we don't have yet).
1320   Wed Feb 18 19:13:20 2009 ranaConfigurationComputersSVN & MEDM & old medm files
Allegra had a 2 year old version of SVN installed and CentOS (yum) couldn't upgrade it, so I did an 'svn remove subversion'
and then a 'svn install subversion' to get us up to the Dec '08 version (1.5.5) which is the latest stable.

I also removed all of the old ASS medm directories without backing them up. There's a new RCG script version which is
fixed so that it no longer dumps these old medm directories in there; there's no need since there's already an
medm archive area.

I also removed the medm/old/ directory, did an svn remove, and then copied it back. This is the only way I know of
removing something from the repository without removing it from the working directory.
10292   Tue Jul 29 21:34:41 2014 ericqUpdateComputer Scripts / ProgramsSVN bulletin

A heads up to anyone using SVN with computers on the Martian network:

When we moved the svn repository on nodus to /export, we set it up such that the internet-facing svn URL was unchanged. However, it turns out that the martian network machines (i.e. Stuff mounted on the NFS share) were still pointing to the old svn files in /cvs/cds/caltech/svn, and thus not seeing new revisions made in /export/home/svn. If your martian network svn'd files got weird, this is why.

I'm relocating the root svn URLs on the martian machines' checkouts to point to the nodus https address as I find them, to make them robust against future local movement of the svn files.

Peoples' user files should be fine, this looks like it'll only really affect things such as scripts and medm screens, etc.

10313   Thu Jul 31 23:19:22 2014 KojiUpdateComputer Scripts / ProgramsSVN bulletin

Did this break "netgpibdata"?

-rw-rw-r-- 1 controls controls   24225 2014-07-30 18:36 SR785.py
-rwxr-xr-x   1 controls staff      12944 Jul 31 23:08 SR785.py