| ID |
Date |
Author |
Type |
Category |
Subject |
|
13476
|
Thu Dec 14 19:33:20 2017 |
gautam | Frogs | ASS | c1ass slow channel offloading scripts with small |
I don't think this is really a problem - we offload to the fast channels and not to the slow (although we really should offload to the slow channels). I think the best approach is to use the ezcaservo utility to offload the DC part of the ASS control signals to the slow channels, so as to not waste fast channel DAC counts on DC offsets. In principle, this approach should be somewhat immune to the slow channel calibration not being perfect.
| Quote: |
|
While staring at epics records all day I noticed something about the PIT/YAW offset sliders and ASS offset offloading to slow channels scripts that I'm not sure others are aware off, so I'll briefly discuss it in this post.
The PIT and YAW sliders directly control soft channels that are hosted on the slow machine. Secondary epics records disentangle them for the individual coils:
- UL = PIT+YAW
- LL = -PIT+YAW
- UR = PIT-YAW
- LR = -PIT-YAW
These channels are the direct input for the physical output channels that generate the control voltage.
The fast channels for PIT and YAW have a numerical correction factor built in that accounts for differences between the OSEMs, but the slow channels don't. This means that the slow PIT/YAW controls are not entirely orthogonal but have crosstalk on the order of 10 percent. This in itself is not that dramatic, however the offload offsets scripts for the dither alignment use the fast PIT/YAW values as inputs, which represent the necessary adjustments to the OSEMs only after the individual correction factors have been applied. The offloading to slow knows nothing of this calibration difference between the OSEMs. The result is that there is a ~10 percent of the offset correction error on the mirror alignment AFTER offloading. This will of course converge after a few iterations, but in any case it is recommendable to run the dither alignment again after offloading and not offload the new offsets to the fast channels.
|
|
|
13910
|
Fri Jun 1 21:47:23 2018 |
Koji | Frogs | General | Touch screen manipulation of the IFO |
[Koji Gautam]
We talked about touch interface of medm. We realized that android (and iOS) has vnc clients. I just installed VNC viewer on my phone and connected to my mac. Typing is tricky but I managed to get into pianosa, then launched sitemap. We could unlock/lock the IMC by screen touch!
Basically we can connect to one of the laptops (or control machines) from a tablet (either android or ipad). It'd be better to put both in a same network. It'd be great if we have a tablet case with a keyboard so that we can type without blocking the screen. |
| Attachment 1: Screenshot_20180601-214459.png
|
|
|
14186
|
Tue Aug 28 15:29:19 2018 |
Steve | Frogs | PEM | Rat is cut |
The rat is cut by mechanical trap and it was removed from ITMX south west location.
A nagy kover patkanyt a fogo elkapta es megolte. |
| Attachment 1: rat#2.png.png
|
|
|
14336
|
Fri Dec 7 19:42:47 2018 |
rana | Frogs | elog | can't upgrade DokuWiki because of PHP / SL7 |
All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.
I tried this recently and it fails with this message:
DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
 New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!
So we'll have to wait until SL7 (which is what NODUS is running).
I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):
> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version
|
|
14545
|
Mon Apr 15 22:55:34 2019 |
gautam | Frogs | Thermal Compensation | Lab thermostat adjusted |
It is feeling cold in the office area. According to the digital wall clock near the coffee machine, it is 19C. Rana bumped the thermostat setpoint up by 2F (from 75F to 77F). We need to setup long-term monitoring. |
|
15081
|
Fri Dec 6 15:22:01 2019 |
gautam | Frogs | LSC | DAFI system revived |
[Jordan, gautam]
We did the following:
- Route the fiber from the control room to 1Y2.
- Plug fiber in to FiBox at either end, turned FiBoxes ON.
- Tested the optical connection by driving a 1Vpp 440 Hz sine wave from a function generator - Yehonathan hears it loud and clear in the control room.
- Tested that both CH1 and CH2 work - only CH1 is connected to the speakers in the control room at the moment.
- There is some cross-coupling between the channels - not sure if this is happening in the multi-mode fiber or in the electroncis, but I estimate the isolation to be >30dB.
- Connected CH8 and CH9 of DAC0 in the c1lsc expansion chassis to CH1 and CH2 respectively of the FiBox in 1Y2.
- Restarted the c1daf model on c1lsc, came up smooth.
- Routed the POY11 error signal through the various matrices in c1daf, and we could 👂 the Y-arm cavity 🔐 😎
- Channels are muted for now - I'll give this a whirl while doing the PRFPMI locking.
|
|
15162
|
Tue Jan 28 08:26:53 2020 |
rana | Frogs | PEM | shaking |
https://breakthrough.caltech.edu/magazine/2019-aug/#article-Listening-with-Light
|
|
15882
|
Mon Mar 8 20:11:51 2021 |
rana | Frogs | Computer Scripts / Programs | activate_matlab out of control on Megatron |
there were a zillion processes trying to activate (this is the initial activation after the initial installation) matlab 2015b on megatron, so I killed them all. Was someone logged in to megatron and trying to run matlab sometime in 2020? If so, speak now, or I will send the out-of-control process brute squad after you! |
|
16325
|
Tue Sep 14 15:57:05 2021 |
jamie | Frogs | CDS | fb1 /var full after reboot, caused all sorts of problems |
/var on fb1 filled up today, which caused all sorts of CDS issues. I found out about the problem by reading the logs of the services that were having trouble running, in which they complained about not being able to write to disk. I looked at the filesystem status with 'df' and noticed that /var was full, which is where applications write temporary data, and will always cause problems if it's full.
I tracked the issue down to multiple multi-gigabyte log files: /var/log/messages and /var/log/messages.1. They were full of lines like this one:
Aug 29 06:25:21 fb1 kernel: l called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl called cmd = 1gpstime iotcl ca
Seems like something related to the gpstime kernel module?
Anyway, I deleted the log files for now, which cleared up the space on /var. Things should be back to normal now, until the logs fill up again... |
|
16327
|
Tue Sep 14 16:44:54 2021 |
jamie | Frogs | CDS | fb1 /var full after reboot, caused all sorts of problems |
Jonathan Hanks pointed me to this fix to the gpstime kernel module that was unfortunately put in after the 3.4 release that we're currently using:
https://git.ligo.org/cds/advligorts/-/commit/6f6d6e2eb1d3355d0cbfe9fe31ea3b59af1e7348
I hacked the source in place (/usr/src/gpstime-3.4/drv/gpstime/gpstime.c) to get the fix, and then rebuilt the kernel module with dkms :
sudo dkms uninstall gpstime/3.4
sudo dkms install gpstime/3.4
I then stopped daqd_dc, unloaded gpstime, reloaded it, restarted daqd_dc. The messages are no longer showing up in /var/log/messages, so I think we're ok for the moment.
NOTE: the fix will be undone if we for some reason reinstall the advligorts-gpstime-dkms package. There shouldn't be a need to do that, but we should be aware. I'm discussing with Jonathan if we want to try to push out a new debian package to fix this issue... |
|
16339
|
Thu Sep 16 14:08:14 2021 |
Ian MacMillan | Frogs | | Tour |
I gave some of the data analysts a look around because they asked and nothing was currently going on in the 40m. Nothing was changed. |
|
17261
|
Fri Nov 11 20:01:56 2022 |
rana | Frogs | Computer Scripts / Programs | FSS SLOW servo not running |
I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.
The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.
I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working. |
|
17262
|
Fri Nov 11 20:59:13 2022 |
Chris | Frogs | Computer Scripts / Programs | FSS SLOW servo not running |
The problem with trends was due to the epics data collection process (standalone_edc) that runs on c1sus. When all the FEs were rebooted earlier this week, this process was started automatically, but for some reason it hasn’t been doing its thing and sending epics data to the framebuilder. I restarted it just now, and it’s working again. Until this problem is sorted out, we need to remember to check on this process after rebooting c1sus.
| Quote: |
|
I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.
|
|
|
17263
|
Sat Nov 12 21:59:24 2022 |
Anchal | Frogs | Computer Scripts / Programs | FSS SLOW servo not running |
I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.
On optimus I ran:
sudo docker stop scripts_PID_FSS_Slow_1
On megatron I ran:
sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow
However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.
On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.
| Quote: |
|
Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.
|
|
|
17281
|
Thu Nov 17 16:48:07 2022 |
Anchal | Frogs | Computer Scripts / Programs | FSS SLOW servo running Now |
I've moved the FSS Slow PID script running to megatron through systemd daemons. The script is working as expected right now. I've updated megatron motd and the always running scripts page here. |
|
91
|
Sun Nov 11 21:05:55 2007 |
rana | HowTo | SUS | MC Touching or not |
I wrote a script: SUS/freeswing-mc.csh, which gives the MC mirrors the appropriate kicks
needed to make a measurement of the free swinging peaks in the way that Sonia did.
#!/bin/csh
set ifo = C1
set sus = ${ifo}:SUS-
foreach opt (MC1 MC2 MC3)
set c = `ezcaread -n ${sus}${opt}_PD_MAX_VAR`
ezcastep ${sus}${opt}_PD_MAX_VAR +300
ezcaswitch ${sus}${opt}_ULCOIL OFFSET ON
ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
sleep 1
ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
sleep 1
ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
sleep 1
ezcawrite ${sus}${opt}_LATCH_OFF 0
ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
ezcaswitch ${sus}${opt}_ULCOIL OFFSET OFF
ezcawrite ${sus}${opt}_PD_MAX_VAR $c
end
echo
date
echo
It basically ups the watchdog threshold, wacks it around at the pendulum frequency, and then disables the
optic so that there are no electronic forces applied to it besides the bias. The date command at the end
is so that you know when to start your DTT or mDV or lalapps code or whatever. |
|
92
|
Sun Nov 11 21:21:04 2007 |
rana | HowTo | Computers | New DV |
To use the new ligoDV (previously GEO DV) to look at 40m data, open up a matlab, set up for mDV as usual,
and then from the /cvs/cds/caltech/apps/ligoDV/ directory, type 'ligoDV'.
Then select which NDS server you want to look at and then start clicking to get some plots. |
| Attachment 1: Screenshot-1.png
|
|
|
107
|
Thu Nov 15 18:23:55 2007 |
John | HowTo | Computers | Swap CAPS and CTRL on a Windows 2000/XP machine |
I've swapped ctrl and caps on the four control room Windows machines. Right ctrl is unchanged.
Start menu->Run "regedit"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
Click on the KeyboardLayout entry.
Edit->New Binary Value name it Scancode Map.
Then select the new Scancode Map entry.
Edit menu->Modify Binary Data.
In the dialog box enter the following data:
0000: 00 00 00 00 00 00 00 00
0008: 03 00 00 00 3A 00 1D 00
0010: 1D 00 3A 00 00 00 00 00
Exit the Registry Editor. You need to log off and then on in XP (and restart in Windows 2000) for the changes to be made. |
|
120
|
Tue Nov 20 18:35:20 2007 |
John | HowTo | Computers | MatLab in Emacs |
If you can't get MatLab to run in emacs try adding the following to the .emacs file
(setq matlab-shell-command-switches '("-nojvm"))
This stops the gui opening.
To start MatLab type M-x matlab-shell.
To enter MatLab mode M-x matlab-mode.
I've done this on LINUX3.
To run MatLab in emacs under windows one can use MatLabShell http://www.cs.umb.edu/~ram/matlabShell/index.html |
|
142
|
Thu Nov 29 18:10:13 2007 |
Alberto | HowTo | Computer Scripts / Programs | GPIB Scripts |
I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems. |
|
143
|
Thu Nov 29 19:35:14 2007 |
rana | HowTo | Computer Scripts / Programs | GPIB Scripts |
| Quote: | I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems. |
Alice and Jamie used the USB-GPIB interface. You should just try using the black laptop which already has this capability or ask Jamie Rollins
who actually knows something. |
|
158
|
Mon Dec 3 16:24:47 2007 |
tobin | HowTo | Computers | GNU screen |
| GNU screen is a utility that can be quite handy for managing long-running psuedo-interactive terminal programs on remote machines. In particular, I think it might be useful in developing and testing "Matlab DMT" tools on Mafalda. |
|
159
|
Mon Dec 3 17:55:39 2007 |
tobin | HowTo | Computer Scripts / Programs | linemon |
| Matlab's Signal Processing toolbox has a set of algorithms for identifying sinusoids in data. Some of them (e.g., rootmusic) take the number of sinusoids to find as an argument and return the "most probable N frequencies." These could be useful in line monitoring. |
|
164
|
Wed Dec 5 10:57:08 2007 |
alberto | HowTo | Computers | Connecting the GPIBto USB interface to the Dell laptop |
| The interface works only on one of the USB ports of the laptop (the one on the right, looking at the computer from the back). |
|
166
|
Wed Dec 5 16:57:36 2007 |
tobin | HowTo | Computer Scripts / Programs | SR785 data converter on linux |
| I was pleased to find that the SR785 Data Viewer (including the command line conversion utility) installs and works in linux using WINE (on my laptop at least). There are some quirks, of course, but I was able to extract my data. |
|
175
|
Thu Dec 6 18:11:15 2007 |
rob | HowTo | Computer Scripts / Programs | Making DMF monitors |
I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.
I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:
1) Write the DMF routine you want, as a matlab function (not a script).
2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).
3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/
to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
|
|
184
|
Mon Dec 10 13:54:26 2007 |
rob | HowTo | Computer Scripts / Programs | Don't blame the Matlab compiler |
For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution... |
|
206
|
Thu Dec 20 19:05:34 2007 |
waldman | HowTo | OMC | HOWTO build front ends |
For instance, to build the TPT front end code.
- Save your file /cvs/cds/advLigo/src/epics/simLink/tpt.mdl
- go to /cvs/cds/advLIGO on the TPT machine
- do make clean-tpt tpt install-tpt
- do rm /cvs/cds/caltech/chans/daq/C2TPT.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing.
- do make install-daq-tpt
- run starttpt to restart the tpt computer.
Enjoy. |
|
274
|
Sat Jan 26 18:12:45 2008 |
rana | HowTo | Computers | extra processes and crashes |
There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.)
You can check this by running top. IF there's lots of them you can kill them by using 'pkill'.
I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup. |
|
280
|
Mon Jan 28 15:11:38 2008 |
rob | HowTo | DMF | running compiled matlab DMF tools |
I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:
1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).
NB: Steps (4) and (6) must be carried out on mafalda. |
|
349
|
Sun Mar 2 23:43:45 2008 |
rana | HowTo | LSC | PD6 response |
John's PD plotting script is superior to all of the ones we had before; lets make him post the script so we can all use it.
Looks like PD6 is not too happy after all; the 199 MHz response is not much higher than the 166 MHz response. I thought we were supposed to have them balanced to within 6 dB or so? |
|
395
|
Sun Mar 23 00:43:08 2008 |
mevans | HowTo | General | Online Adaptive Filtering |
| I wrote a short document about the OAF running on the ASS. Since there is no BURT setup, I put a script in /cvs/cds/caltech/scripts to help with setting initial parameters: upass. |
| Attachment 1: OnlineAdaptiveFilter.pdf
|
|
|
404
|
Wed Mar 26 13:41:53 2008 |
Andrey | HowTo | SUS | Modification of ''C1DRIFT_MONITOR'' |
I learned how to modify the drift-monitor in MEDM so that values on it change colors from green to yellow to red depending how much is the fluctuatioin (deviation) of the value from its mean nominal value.
In order to do this, I used the following eight commands:
tdswrite CHANNEL_NAME.HIHI VALUE
tdswrite CHANNEL_NAME.HIGH VALUE
tdswrite CHANNEL_NAME.LOW VALUE
tdswrite CHANNEL_NAME.LOLO VALUE
tdswrite CHANNEL_NAME.HHSV 2
tdswrite CHANNEL_NAME HSV 1
tdswrite CHANNEL_NAME LSV 1
tdswrite CHANNEL_NAME LLSV 2
where CHANNEL_MAME is the name of the channel the value of which is indicated on the MEDM screen C1DRIFT_MONITOR, for example
C1:SUS-MC1_SUSPOS_INMON, and VALUE is numerical value that I assigned to the channel parameters.
By now I modified nine mode-cleaner channels (POS, PITCH and YAW channels for MC1, MC2 and MC3) and 6 channels for ITMX and ITMY.
Note that as we have problems this week with computer C1SUSVM, namely ''c1susvme2'' is not working, indicators for MC2 in the drift-monitor do not change colors today although they should.
In order to judge which values should be established as reasonable deviations from the average nominal values, I was looking into Dataviewer trends for the channels that are in the drift-monitor.
In the future indicators for channels ETMX and ETMY, BS, PRM, SRM should be modified in complete analogy with what I did already for MC and for ITM. So, I have modified 3*5 = 15 channels, and 3*5 = 15 channels are left for the future.
Note that (as far as I understand) instead of commands "tdswrite" it is absolutely legitimate to use commands "ezcawrite". |
|
478
|
Thu May 15 10:40:21 2008 |
steve | HowTo | General | Lisa Goggin, PhD |
Lisa Goggin successfully defended her thesis on May, 13 2008
"A Search For Gravitational Waves from Perturbed Black Hole Ringdowns in Ligo Data"
She started out as a surf student in the 40m.
Congratulation! |
| Attachment 1: lisa.JPG
|
|
|
536
|
Tue Jun 17 22:00:53 2008 |
John | HowTo | PSL | Problems turning MZ servo on/off |
| We were unable to toggle the MZ servo on/off (Blank/Normal) from MEDM. Pushing on the Xycom board and cables changed the fault from constant to intermittent. At least one lock loss has been caused by a MZ glitch. |
|
551
|
Sun Jun 22 21:38:49 2008 |
rob | HowTo | General | IFO CONFIGURE |
Now that we're getting back into locking, it's nice to have a stable alignment of the interferometer.
Thus, after you're done with your experiment using subsets of the interferometer (such as a single arm),
please use the IFO_CONFIGURE screen, and click "Restore last Auto-Alignment" in the yellow "Full IFO" section.
If you don't know what this means/how to do this, you shouldn't be using the interferometer on your own. |
|
615
|
Tue Jul 1 14:24:58 2008 |
rob | HowTo | Computer Scripts / Programs | conlog time machine |
I've written a perl script (now in the $SCRIPTS/general directory) which implements a "conlog restore" command, restoring channels matching a regexp to a given time using the conlog records and the EpicsTools.pm perl module. The script is called time_machine_conlog:
| Quote: |
op440m:~>time_machine_conlog
time_machine_conlog restores EPICS control settings using a conlog time
usage: time_machine_conlog [<--dryrun>] <date=yyyy/mm/dd,hh:mm:ss> <timezone> <regexp>
Can also accept a gps time, in which case timezone=gps.
Use the option <--dryrun> to see conlog output without restoring any settings.
EXAMPLE: time_machine_conlog 2008/05/30,12:00:00 PDT "C1:SUS-MC.*_(PIT|YAW)_COMM"
|
It sometimes returns an error message even when the command is successful--this is because conlog stores EPICS settings to an absurd level of precision, but ezcawrite will not write EPICS values to this level (or at least won't indicate if it did). I consider this a bug in ezcawrite so I'm not touching it.
The script is untested with regards to switch settings (such as ENABLE/DISABLE). It's mainly intended for numerical values. |
|
617
|
Tue Jul 1 21:27:27 2008 |
rob | HowTo | Computer Scripts / Programs | slider twiddling after reboot |
Sometimes after we reboot the front-end machines, some of the hardware gets stuck in an unknown state. We generally fix this by twiddling EPICS settings, which refresh the hardware somehow and put it into a known state. I've started a script (slider_twiddle) which we can just run after reboots to do this for us. Right now it just has the QPD whitening gain settings. As we find more stuff, we can add to it. It's in $SCRIPTS/Admin/. |
|
636
|
Sun Jul 6 16:17:40 2008 |
tobin | HowTo | Computers | SVN |
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). |
|
639
|
Mon Jul 7 13:49:27 2008 |
Yoichi | HowTo | PSL | MZ offset, gain tips |
John, Yoichi
This morning John found that MZ servo is not working.
We were able to bring the MZ back by changing the output offset a bit. But we were not sure what was actually wrong.
So we pulled out the MZ board and checked several TPs to understand the behavior.
Here is the summary of what we learned this morning.
The MZ control board has the following stages:
[Mixer] -(error signal)-> [Sum amp for input offset] -(error + offset)-> [Variable Gain Amp] -> [Filter (x100 DC gain)] -(FB signal)-> [High Voltage Amp] -> output
(The HV amp also works as the sum amp for the output offset)
(1) We noticed that the Sum amp for the input offset has an output of -0.14V even when the offset input is 0V. This can be canceled by the input offset slider.
So for the moment, it is fine. But we might want to change the op-amp because the weird offset implies there might be something wrong with the chip.
The procedure to null the -0.14V offset is the following:
a) Enable Test 1 input on the MZ MEDM screen.
b) Move the input offset slider until the mixer monitor becomes 0V. Currently the input offset slider is at -7.5V to cancel the -0.14V offset.
(2) Because the gain of the Variable Gain Amp and the Filter combined is large, the Filter can be easily saturated if the output offset is not right.
This was the cause of the MZ problem this morning. The output offset slider was at a wrong position making the error signal slightly off centered from zero.
This residual DC error signal was amplified by the large gain chain and saturated the filter amp.
Our experience is that the output offset cannot go below -3V. We set it at 0V for now. |
|
654
|
Thu Jul 10 13:47:12 2008 |
Yoichi | HowTo | Computers | svn access via https |
Now you can access to the svn repository on nodus by https.
To perform a checkout, you can use the following command
svn co --username svn40m https://nodus.ligo.caltech.edu:30889/svn/trunk/chans
This will check out "chans" directory.
The password for svn40m is written in the usual place.
You can also access the URL by a web browser to see the repository in a very primitive way.
A nice web interface for browsing the repository is planed but not yet implemented. |
|
788
|
Mon Aug 4 00:56:07 2008 |
Koji | HowTo | General | Abs. Len. Meas. ~ Auto freq scanner with GPIB |
Work log on August 3rd - Part1
o Yesterday I was too much tired of changing the RF frequency, reading peaks on the RF spectrum, and writing the values. Rana saw me and thought I was such poor that he gave me an USB-GPIB adapter.
o I dig into the internet for the manuals of the adapter, IFR2023A(Marconi), and HP8591E(RF spectrum analyzer) in order to learn how to use them.
o I had LabVIEW installed on my laptop. Finally I understand how to use that adapter (by Agilent) with LabVIEW. I made a small program to scan the frequency of IFR2023A, and read the peak values from HP8591E. It is unfortunate that there is no LabVIEW in the 40m lab. I think I can make an independent executable which does not need the LabVIEW itself. Give me some time to understand how to do it. |
| Attachment 1: freq_scan.png
|
|
|
833
|
Thu Aug 14 10:26:45 2008 |
steve | HowTo | SUS | sus cable pin cheater for out of vac damping |
The 40m D25 vacuum feed troughs give you a mirror image pin count.
Sus damping outside of the vacuum envelope require this cheater cable where
on the male D pin 1 is connected to female D 13 and so on
and male D pin 14 is connected to female D 25 and so on |
| Attachment 1: suscabmin.png
|
|
|
867
|
Thu Aug 21 17:55:14 2008 |
rana | HowTo | IOO | MC WFS DC Offsets |
I ran the McWFS_dc_offsets script to trim out the DC offsets on the MC WFS DC signals.
Rob says "who cares?" |
|
875
|
Mon Aug 25 10:23:53 2008 |
steve | HowTo | General | cable killer |
Rack 1Y7 double violation:
BNC cables left to be jammed by door
and see destroyed BNCs
RED fibers should be rerouted.
I placed protective obstacle in position
so the door can not be closed.
Please do not do this!
DNA analysis is in progress on your finger prints. |
| Attachment 1: cablkill.png
|
|
| Attachment 2: cablkll2.png
|
|
|
882
|
Mon Aug 25 17:45:34 2008 |
rana, josephb, rob | HowTo | PEM | Accelerometer range |
Joe shows us by jumping up ~15" in the control rom that the accelerometers are set with not enough gain.
Since this is taken around 5:30 in the evening, so we can take the nearby time series to represent what a
high noise level is. I recommend we up the gain using the ICS-110B .ini file. |
| Attachment 1: Screenshot-4.png
|
|
|
889
|
Tue Aug 26 19:07:37 2008 |
Yoichi | HowTo | Computers | Reading data from Agilent 4395A analyzer through GPIB from *Linux* machine |
I succeeded in reading data from Agilent 4395A analyzer, who's floppy is crappy, through GPIB from a Linux machine using
agilent 82357B USB-GPIB interface.
I installed the linux GPIB driver to one of the lab. laptops (the silver DELL one currently sitting on the 4395A analyzer).
I wrote an initialization script for the USB-GPIB interface and a small python script for reading data from the analyzer.
[Usage]
1. Connect the USB-GPIB interface to the laptop and the analyzer.
2. Run /usr/local/bin/initGPIB command (it takes about 10sec to complete).
3. Run /usr/local/bin/getgpibdata.py > data.txt to save data from the analyzer to a text file.
The data format is explained in the comments of getgpibdata.py
This method is way faster than the unreliable floppy. The data is transfered in a few sec.
I'm now writing a wiki page on this
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB
I will install the same thing into the other DELL laptop soon.
Let me know if you have trouble with this. |
|
890
|
Wed Aug 27 10:55:35 2008 |
Yoichi | HowTo | Computers | Annoying behavior of the touch pads of the lab. laptops is fixed |
I was sick of the stupid touch pad behavior of the lab. laptops, i.e. firefox goes back and forth in the history when the cursor is moved.
It was caused by firefox mis-interpreting the horizontal scroll signal as back/forward command.
I stopped it by going to about:config in firefox and set mousewheel.horizscroll.withnokey.action to 0 and
mousewheel.horizscroll.withnokey.sysnumlines to true. |
|
904
|
Fri Aug 29 18:24:48 2008 |
rana | HowTo | PSL | PMC: PZT Calibration |
I calibrated the PMC PZT at DC by using 'trianglewave' to drive the DC offset slider
and reading back PMC_PZT and PMC_TRANSPD_F (both are DC coupled DAQ channels).
The attached PDF illustrates the method: look at the voltage required to span 1 FSR and then divide.
PMC_cal (m/V) = (1064 nm)/2 / V_FSR The calibration for our PZT is therefore 10.4 nm/V.
The full scale (0-300 V) range is 3.1 microns.
From Jenne's elog entry we know that the series resistor to the PZT is 63.6 kOhms. The PZT is labeled as
having a capacitance of 279 nF. So the PMC drive's pole frequency is 1/2/pi/63.6e3/279e-9 = 9 Hz +/- 0.5 Hz.
The cable capacitance is ~20 pF/foot so its not significant for this.
The template file is Templates/PMC-PZTcal.xml.
Using the above calibrations, also plot the calibrated PMC ERR and PZT spectra. |
| Attachment 1: pmc-pzt-cal.pdf
|
|
| Attachment 2: mcf.png
|
|
|
966
|
Thu Sep 18 18:38:14 2008 |
Yoichi | HowTo | Computers | How to compile an SNL code for VxWorks |
Dave Barker guided me through how to compile an SNL code into a Motorola 162 CPU object.
Here is the procedure:
(1) You need an account at LHO and a password for ops account at LHO. Contact Dave if you don't have these.
(2) Copy your code (say Particle.st) to the LHO gateway machine.scp Particle.st username@lhocds.ligo-wa.caltech.edu:/cvs/cds/lho/target/t0sandbox0 (3) Login to lhocds.ligo-wa.caltech.edussh username@lhocds.ligo-wa.caltech.edu (4) Login to control0ssh ops@control0 (5) Change directory to the sandbox dir.cd /cvs/cds/lho/target/t0sandbox0 (6) Prepare for the compilationsetup epics (7) Edit makefile in the directory. You have to modify a few lines at the end of the file.
There are comments for how to do it in the file.
(8) Compilemake Particle.o (9) Copy the object file to the 40m target directoryscp Particle.o controls@nodus.ligo.caltech.edu:/cvs/cds/caltech/target/c1psl/
That is it. |