40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 6 of 56  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  2745   Mon Apr 4 17:05:20 2022 RadhikaSafetyCleanlinessLab flooding

Pictures attached. WS1 and WS2 have been turned back on, since the replacement for the ceiling panels will not arrive for another few weeks according to Facilities.

Quote:

Facilities will be returning on Monday 4/4 between 8-9 AM to remove all ceiling panels above the workstations in B265B (QIL). Replacement of the panels is not yet scheduled, but in the meantime the open ceiling will be covered and the workstations will still be accessible. 

 

Attachment 1: IMG_3298.jpeg
IMG_3298.jpeg
Attachment 2: IMG_3299.jpeg
IMG_3299.jpeg
Attachment 3: IMG_3300.jpeg
IMG_3300.jpeg
  2766   Tue May 10 14:27:26 2022 AidanLab InfrastructureCleanlinessCeiling tile replacement - Day 1

Henry from the Carpentry Shop has started replacing ceiling tiles. They need to be cut to fit each location. There was a lot of set up getting equipment across to Bridge before lunch so not that much progress was made replacing tiles in QIL and TCS Labs. Expect work will speed up as we find our groove. 

Attachment 1: IMG_8782.jpg
IMG_8782.jpg
  2767   Wed May 11 15:53:06 2022 AidanLab InfrastructureCleanlinessCeiling tile replacement - Day 2

Tiles are replaced.

Quote:

Henry from the Carpentry Shop has started replacing ceiling tiles. They need to be cut to fit each location. There was a lot of set up getting equipment across to Bridge before lunch so not that much progress was made replacing tiles in QIL and TCS Labs. Expect work will speed up as we find our groove. 

 

Attachment 1: IMG_8806.jpg
IMG_8806.jpg
Attachment 2: IMG_8807.jpg
IMG_8807.jpg
Attachment 3: IMG_8803.jpg
IMG_8803.jpg
  953   Thu Aug 19 11:33:31 2010 AlastairLab InfrastructureComputingrouter...

The internet was down again when I came in this morning.  I power cycled the router and left it for longer than I did yesterday and everything came back to normal.  Maybe it was the router that was the problem the other day as well, but I just didn't leave it for long enough before I power cycled the network switch.

We should probably swap this router out to see if the unit itself is causing the problem.  Does anyone know if we have a spare or a preffered vendor?  If we don't have a spare I'll order an identical linksys unit from somewhere.

  954   Thu Aug 19 11:44:23 2010 AlastairLab InfrastructureComputingWiki

We need to rebuild the front end soon, so to kill two birds with one stone I thought we could document it on the wiki as we go along.  At the moment the ATF wiki page doesn't want to work.  I'll ask around to find out where it lives and who knows how to get it back up and running I have made this elog the official Rana colours of green and purple along with an assortment of font sizes to appease the wiki gods.

  955   Thu Aug 19 11:49:15 2010 FrankLab InfrastructureComputingrouter...

Quote:

The internet was down again when I came in this morning.  I power cycled the router and left it for longer than I did yesterday and everything came back to normal.  Maybe it was the router that was the problem the other day as well, but I just didn't leave it for long enough before I power cycled the network switch.

We should probably swap this router out to see if the unit itself is causing the problem.  Does anyone know if we have a spare or a preffered vendor?  If we don't have a spare I'll order an identical linksys unit from somewhere.

 It's the router, i've tested that already. We don't know what causes it but Larry said that this might happen if we are running a lot of traffic across it. I don't know if this is true but anyway the plan is to use fb1 as the router instead and also as our internal DHCP and DNS server so that we don't have to give fixed IP addresses and names to computers anymore. Instead we give them a fixed address by knowing their hardware MAC addresses. This is much easier to handle because you only have one config file which contains the entire network setup and if you wanna change something you only have to change that file and not login in all individual computers to make changes. This makes sense as we have almost 30 devices by now...

  The original plan was that Mott will do it but i think now it's on me. I already have the additional network cards we have to install but so far i didn't have the time to shut down everything (we have to shutdown really EVERYTHING as fb1 is used a the global source for all tools incl. the RT code and stuff) and start working on that. We might wanna do that early September as i gonna leave Tue morning to LHO and there are some guys which wanna install sprinklers in the PSL lab until then....

  958   Thu Aug 19 13:18:17 2010 AlastairLab InfrastructureComputingWiki

Quote:

We need to rebuild the front end soon, so to kill two birds with one stone I thought we could document it on the wiki as we go along.  At the moment the ATF wiki page doesn't want to work.  I'll ask around to find out where it lives and who knows how to get it back up and running I have made this elog the official Rana colours of green and purple along with an assortment of font sizes to appease the wiki gods.

 Wiki gods have been appeased.  The CIT wiki had been moved.  ATF wiki can now be found here.

The top level wiki page is here

  959   Thu Aug 19 22:04:55 2010 Alastair & RanaComputingComputingFront end rebuilt

Rana and I re-made the front end code today and restarted the front end at around 8pm.  We didn't change any of the model - this was mainly just an exercise to try to document the process so that it can be put up on the wiki.

Rana also discovered that BURT is working, and we can use this to log and restore the values in our MEDM screens.  We just need to manually write and restore the BURT snapshot files just now.  The auto-BURT isn't working for the moment.

After restarting we now have a new C2ATF.ini file, so if anyone was recording frames in C2 then they will need to use the GUI to restart the frame logging for that channel (use daqconfig to get the GUI up).  Since this GUI is working we should all start using it exclusively when we add new channels.

  1067   Mon Sep 20 13:29:53 2010 ranaComputingComputingws1 device query (this is very uninteresting)

[ops@ws1 ~]$ /sbin/lspci -v
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Capabilities: <access denied>

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at 8c00 [size=1K]

00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: 66MHz, fast devsel
        I/O ports at 1000 [size=32]
        I/O ports at a000 [size=64]
        I/O ports at a040 [size=64]
        Capabilities: <access denied>

00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209
        Memory at b0000000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201
        Memory at b0001000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209
        I/O ports at 1800 [size=256]
        I/O ports at 1400 [size=256]
        Memory at b0002000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at 1c00 [size=16]
        Capabilities: <access denied>

00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
        I/O ports at 1c40 [size=8]
        I/O ports at 1c34 [size=4]
        I/O ports at 1c38 [size=8]
        I/O ports at 1c30 [size=4]
        I/O ports at 1c10 [size=16]
        Memory at b0003000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
        I/O ports at 1c58 [size=8]
        I/O ports at 1c4c [size=4]
        I/O ports at 1c50 [size=8]
        I/O ports at 1c48 [size=4]
        I/O ports at 1c20 [size=16]
        Memory at b0004000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: b0100000-b01fffff

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201
        Memory at b0005000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 1c60 [size=8]
        Capabilities: <access denied>

00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00002000-00002fff
        Memory behind bridge: b1000000-b2ffffff
        Prefetchable memory behind bridge: 00000000c0000000-00000000cff00000
        Capabilities: <access denied>

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Flags: fast devsel
        Capabilities: <access denied>

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Flags: fast devsel

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Flags: fast devsel

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Flags: fast devsel

00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Flags: fast devsel
        Capabilities: <access denied>

00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Flags: fast devsel

00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Flags: fast devsel

00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Flags: fast devsel

01:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 64, IRQ 11
        Memory at b0104000 (32-bit, non-prefetchable) [size=2K]
        Memory at b0100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>

02:00.0 VGA compatible controller: nVidia Corporation G73 [GeForce 7600 GT] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 820d
        Flags: bus master, fast devsel, latency 0, IRQ 50
        Memory at b2000000 (32-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at b1000000 (64-bit, non-prefetchable) [size=16M]
        I/O ports at 2000 [size=128]
        Capabilities: <access denied>

08:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=08, secondary=09, subordinate=09, sec-latency=0
        Capabilities: <access denied>

08:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 0
        Memory at d0000000 (64-bit, non-prefetchable) [size=4K]

08:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=08, secondary=0a, subordinate=0a, sec-latency=0
        Capabilities: <access denied>

08:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 0
        Memory at d0001000 (64-bit, non-prefetchable) [size=4K]

80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Capabilities: <access denied>

80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Memory at d0400000 (32-bit, non-prefetchable) [size=4K]

80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233
        Memory at d0401000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 3000 [size=8]
        Capabilities: <access denied>

80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=80, secondary=81, subordinate=81, sec-latency=0
        Capabilities: <access denied>

  1069   Mon Sep 20 14:07:37 2010 ranaComputingComputingWS1: video settings fixed to have dual head Xinerama

I got the dual head stuff working in the following way:

- downloaded the GeForce 7600 GT drivers for 32-bit Linux from the NVidia website.

- drop into runlevel 3 as root and run the install program from there (after giving it the chmod +x).

- CentOS' native display config program chokes and screws up the xorg.conf. Ignore this and let it pick some cheesy default setting.

- Once logged in in cheesy settings, run 'nvidia-xonfig' to get nvidia driver running. Use the GUI to activate monitor 2. Logout and log back in.

- Run 'nvidia-settings' to set up the dual head appropriately and hit the radio button for Xinerama. Log out and log back in.

  1095   Fri Oct 1 11:53:04 2010 AlastairComputingComputingno chans in dataviewer

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

  1096   Fri Oct 1 12:28:53 2010 AlastairComputingComputingno chans in dataviewer

Quote:

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

 Thanks to Aidan, it's up and running again.  FB0 did not appear to be running the front end at all, and using 'startatf' has got it back working.  Next time we have this sort of problem just running a 'ps -e |grep atf' on FB0 should give you back some processes if it is running, otherwise it needs started.  It appears that the FE Reload button on the master MEDM screen is not doing it's job now.

 

  1097   Fri Oct 1 13:04:44 2010 FrankComputingComputingno chans in dataviewer

 again, FB1 has NOTHING to do with the realtime system. You will never be able to see channels from the RT system running on FB0 using FB1! It's technically impossible without some additional hardware which we don't have !

Don't touch the daqd on FB1, except when changing environmental monitoring channels or TCS channels !

If you restart FB1 almost any computer has to be restarted too as they share the directory mounted via NFS, not only the ones in the ATF lab ! So, plz, don't touch FB1.

Quote:

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

  1098   Fri Oct 1 21:58:29 2010 AlastairComputingComputingwiki

 I've changed the wiki template for one that gives the full screen width.

Also added some more sections and set up the sidebar navigation.  There is now a computing section that we can populate.  The idea is to have first-timer guides for doing all the regular computing jobs that come up in the lab (how to add DAQ channels, how to restart the front-end, how to rebuild the model) as well as places to store more expert information (such as network topology etc).  A lot of this is already there in the elogs and we can just transfer it across.

Again for those that missed it the first time round, the new wiki location is:

https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php

and you can just ask for a password to be emailed to you by clicking on the login screen.

  1107   Wed Oct 13 10:08:48 2010 AlastairComputingComputingNetwork diagram

I made a copy of Frank's most recent network diagram in omnigraffle and it is on the wiki here

The .graffle file is there too, so it can easily be updated by anyone as changes occur.

  1108   Wed Oct 20 18:43:48 2010 AlastairComputingComputingATF FB0 front-end rebuild

 I've started work on updating the model for our front-end code.  First I want to just rebuild as it is using the existing model.  I'm going to put up idiot-proof instructions on the wiki as I go along.

So far I've tried the method given on the 40m wiki here: http://lhocds.ligo-wa.caltech.edu:8000/40m/Simulink_to_Front-End_code  .  I can get pretty far through these instructions before hitting problems at the point where you copy the .ini file across - at this point I find that the file is not in the location given in the instructions.

The simpler instructions on page 17 of T080135-00-C do work however.  I can get all the way through to the point where i do the startatf command and using ps I can see there are processes with the atf name running.  If I open an MEDM screen there is no data coming in though.  Also the daqd process wasn't running, so I did a sudo reboot on FB0.  When I did this FB0 hung while rebooting.  I power-cycled it and it booted up the next time.  When I ssh into it daqd is now running.  I did startatf again.  When I open MEDM the channels still don't seem to be acquiring.

I wonder whether there is a problem that it is not loading epics BURT data because in the /cvs/cds/caltech/target/c2atf/log.txt the final line, repeated over and over again is "Waiting for EPICS BURT 0"

When I try opening the GDS_TP medm screen it comes up with the error "cannot open file /cvs/cds/caltech/scripts/utilities/nova_logo.gif".  When I check, the utilities folder does not exist.  I tried to see where in the MEDM screen this .gif is supposed to live, but in the end I opted for putting random small gif file in nova_logo.gif in the meantime.  Now the MEDM screen runs without complaining but the boxes are white.

 

  1109   Wed Oct 20 23:49:54 2010 AlastairComputingComputingDAQ continued

I've been reading T080135 a bit further.  The auto-generated MEDM file in /cvs/cds/caltech/medm/C2/atf/ called C2ATF_GDS_TP.adl is the one that I've been checking to see if the front-end is working properly.  I've checked that this file was generated today when I compiled ATF.mdl, and it was.  I've made sure that the startatf file that I am running is the correct one - first of all making sure /cvs/cds/caltech/scripts is in the PATH (which it is) and secondly trying to do the startatf directly from that directory using ./startatf.  This startatf file was also generated today, so it is not an old version either.  And we still have the same issue that the MEDM screen isn't running properly - all the boxes are just white.

I notice that daqd isn't running again on FB0.  It had definitely started earlier after the reboot.  I did reboot FB0 one more time after this as I left the lab and by the time I got home and checked daqd wasn't running.  I don't know if this is a problem.

  1110   Thu Oct 21 12:17:54 2010 FrankComputingComputingDAQ continued

if the boxes of the main screen are white the daqd process will not start. It automatically stops if the frontend code isn't running as it is configured to wait for the right DCU to be up (in that case the only DCU in that system IS the frontend, so it can't be started). Any messages while compiling the stuff? Any errors?  My suggestion: save the current simulink model in a save place, take the last, known to be working version and do all the compiling and see if everything starts. If yes you have a bug in your model, if no the way you compile and start the stuff is wrong.

Once the frontend is running, if the daqd still isn't starting try checking the logfile of the daqd process. it's in the /fb directory. Usually it tells you exactly what's wrong... 

  1111   Fri Oct 22 10:56:51 2010 Rana & AlastairComputingComputingfront-end now working

The front-end code is working again now on FB0.  Many of the folders were owned by root because of some previous badly written documentation - these have all now been chown'ed into submission.  The main lesson learned is: DON'T EVER MAKE THE MODEL AS ROOT!

We now have a really simple route to re-making the model when we have any changes.  This is documented on the ATF Wiki here. Please don't deviate from this process ever.

Dataviewer now works on WS2 (though doesn't work from mainmenu because it doesn't start up grace).  The gyro MEDM screens aren't working right now because I changed some of the parts names in the model.  I also plan on hijacking a few more channels for the gyro before remaking the model again.  There is still an issue with the user accounts on FB0 which needs fixed at some point in the future.

Most importantly we now have a Rana approved color scheme for the terminal shell on WS2.

  1112   Sun Oct 24 19:27:44 2010 ranaComputingComputingNow running ELOG 2.8.0
  1123   Mon Nov 1 19:46:05 2010 ZachMiscComputingfloppy disk cleared

 I am wiping the floppy disk entitled "Alastair's Agilent traces 1", which I know that several of us have used to transfer data from time to time. I have temporarily backed it up on my hard drive, but if no one claims any data I will delete it.

  1125   Tue Nov 2 19:22:56 2010 AlastairComputingComputingDAQ

I've rebuilt the C2ATF front-end and renamed all the channels for the gyro as well as changing the topology.  I started a list of channels on the wiki here.

I have made one new medm screen for us to use to start with.  It is called C2ATF_GYROMAIN.adl  (see screenshot below).

Most of the channels now just come in and go to a filter so that we can aquire them.  The laser piezo actuation signal does go back out again through channel 9 so we can act on the slow feedback.  I have added 4 general channels that come in and go back out, just in case there are things we wish to do that I haven't thought of yet.

The front-end is running happily for the moment.

Attachment 1: Screenshot.png
Screenshot.png
  1133   Wed Nov 3 19:00:45 2010 AlastairComputingComputingDAQ

Quote:

I've rebuilt the C2ATF front-end and renamed all the channels for the gyro as well as changing the topology.  I started a list of channels on the wiki here.

I have made one new medm screen for us to use to start with.  It is called C2ATF_GYROMAIN.adl  (see screenshot below).

Most of the channels now just come in and go to a filter so that we can aquire them.  The laser piezo actuation signal does go back out again through channel 9 so we can act on the slow feedback.  I have added 4 general channels that come in and go back out, just in case there are things we wish to do that I haven't thought of yet.

 

The front-end is running happily for the moment.

 

I've made a second MEDM screen for the gyro.  It is more of an indicator screen showing which signals we are aquiring from which part of the gyro.  It has a few charts that we can modify as we think of things that we want displayed (it shows just photodiode DC values and actuation signals at the moment).

I added a matrix to the TEST channels and incorporated that into the C2ATF_GYROMAIN.adl

I've spent a while routing cables.  We now have all the correct channels attached to the ADC and I've labelled them at the gyro end.  I ordered a couple more patch bays so that each bench can have two.  Frank is going to pass on the info for the BNC cables that are used to connect the patch bays - they were custom lengths and he has the original quote.  We'll buy enough new ones that we can route 2*16 channels for both benches.

Attachment 1: Screenshot.png
Screenshot.png
  1138   Thu Nov 4 22:18:31 2010 AlastairComputingComputingChanges to model

I've been working on getting the model to switch the boost on and off based on the transmission pd signal.  So far I have the software part working but not the hardware.

In terms of software, initially I tried modifying the epics atf1.db file.  I added  a calc channel that compared the trans_pd value to a user input channel from the MEDM screen.  I could get this to switch, but got stuck at the point where I tried to write this back out through the DAC.  While you can use an 'ao' channel in epics to do this, we want instead to write out through the front end.  I set up an epics channel that could write out through the front end, by putting it into the model but got stuck trying to work out how to write the calc channel to the channel that is connected to the DAC.  Making them the same channel didn't work and I couldn't find a way to transfer a value from a calc channel to an 'ai' channel.

Instead I got it to work by putting doing the comparison in the Simulink model.  The trans_pd epics value is compared to a user input MEDM value, and the binary output of this then toggles a switch that sets DAC output 10 high or low.  One nice thing about this is that it doesn't require any manual editing of the .db file.

There is one problem with connecting this up right now.  Frank thinks the DAC output is probably differential (we measure 5v out on the boost controller channel when connected to a scope, but 10v on a multimeter), and if we connect it to a grounded piece of equipment (such as the boost input on the PDH box) we will be shorting the output.  We should take the DAC card out of the rack and check that this is the case.  If so then it seems we need a differential input on the boost switch and everything else that we are controlling from the DAC (such as the slow input on the laser).

 

  1139   Thu Nov 4 23:22:53 2010 ZachComputingComputingwhy is the elog so slow?

 I have noticed that the elog is taking excruciatingly long to load today. Is this happening to anyone else?

  1143   Sat Nov 6 23:48:02 2010 ranaComputingComputingws1 is back, almost

The network interface for ws1 was failing to work for some reason. I tried the usual Linux forums for advice but most of it was useless.

Finally one of them suggested that there was a warm power up v. cold power up issue with the Realtek 8169 Network card chipset.

So I turned off the machine and then reformatted the disk and did a fresh install. The network is now working (allowing this elog access).

But then...I realized that (someone) gave me a 32-bit install DVD and so I'm now wiping it and starting over.

  1145   Sun Nov 7 21:47:10 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

As is the standard mandated by CDS, I have converted the UID for controls to 1001 and the groupID of the controls group to 1001 and made the user controls be a member of the controls group only.

I had done this on ws1/ws2 before and there were naturally inconsistencies with it and fb1. I have just now done it fb1 and then fixed up many files by doing:

chgrp -R controls *; chown -R controls *

in /cvs/cds/caltech/ and in /opt/

There will certainly be short term negative consequences of this action, but its better we do it sooner than later. I'll have to get some Seifert consultation to finish fixing fb0.

  1151   Mon Nov 8 17:26:38 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

I changed over the user/group ownership of the /frames subdirectories to controls for both fb0 and fb1. Lets see if this is correct.

I also updated the firmware on the linsys router, turned off uPnP, and also turned off DHCP (as a test). I've been noticing that what happens

lately is that the connection to the outside world just goes away sometimes and then comes back after a few minutes. This along with

the fact that our bandwidth to our own LIGO network is only 600 kB/s makes me think that the issue is on Larry's side of the table.

  1152   Mon Nov 8 22:37:33 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

 Frank and I had to play some games with openmotif/grace/medm to get things going again. Basically, the EPEL repo should be added to all of the linux machines using rpm.

Then, we must install grace from the EPEL and this will also install the correct 64 bit openmotif which is used by MEDM (Motif Editor and Display Manager). As of now, dataviewer

and DTT and MEDM are working on most machines.

Attachment 1: Untitled.png
Untitled.png
  1154   Tue Nov 9 02:18:36 2010 alastairComputingComputingrouter ordered

 I've ordered the new router.  Joe tells us that the 40m router is a Linksys BEFSX41  , however this model doesn't seem to be available anywhere (unless you count secondhand ones on amazon....) even on the linksys website.  Instead I have ordered the next one up in the range which appears from the specs to be the same router but with 8ports.  It is a BEFSR41.  Should be with us in approx 2-3days as it was in stock.

  1156   Wed Nov 10 01:15:34 2010 AlastairComputingComputingWiki is down...

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

  1157   Wed Nov 10 01:21:49 2010 KojiComputingComputingWiki is down...

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

  1158   Wed Nov 10 01:46:53 2010 AlastairComputingComputingWiki is down...

Quote:

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

That is strange.  I had also forgotten that the 40m wiki isn't hosted at Caltech.  I still can't get access to either of them.

 

  1159   Wed Nov 10 01:52:22 2010 AlastairComputingComputingWiki is down...

Quote:

Quote:

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

That is strange.  I had also forgotten that the 40m wiki isn't hosted at Caltech.  I still can't get access to either of them.

 

I suspect that the problem is actually at this end.  I tried another computer and a desktop with a wired connection and neither worked.  It's strange though because I would have assumed that although it's weird port number on the wiki's server, I would still be using a normal port number at this end since I'm accessing it through a browser (or is this not the way it works?).

  1213   Tue Dec 14 17:02:56 2010 Alastair, Zach, Frank (and absolutely definitely no help from Joe)ComputingComputingFB0 status update

We started having a look at the prolems with the frame builder in the ATF today.  As Zach had said, the previous attempts ended at the point where FB0 was rebooted and one of the drives kept coming up with some problem.  The main issue before the reboot was that daqd kept restarting.  It seems that the two problems are unrelated.

1) The first issue, with the hard drive has been solved.  The drive that was causing the problem was sdc1.  The machine FB0 has four drives installed, one of which was labelled "full" and a second one "trend".  We removed these two drives, backed up the fstab file and removed them from the listing in fstab.  The computer was able to boot with no problems.  We identified sdc1 as being "full", mounted in position 3 in the computer casing.  I got a temporary replacement that is 1TB from Larry and have installed that in it's place.  After checking the device name in the /dev directory (didn't want to format the wrong one...) I formatted it using fdisk /dev/sdc and created the filesystem using mkfs.ext3 /sdc1

I then went back and copied the old version of fstab back to it's original place and put the fourth drive, sdd back in place.  The machine was rebooted and I checked that the new drive was mounting correctly as /frames/full.  I noticed that the ownership of /full was not the same as /trend (the new drive was owned by root) so I used chown controls:controls /frames/full to make controls the owner.  Inside /full there is a directory /lost+found that I also chown'ed to be controls.  Everything seems happy with this now.

I've ordered a new 1.5TB drive and a second one to keep as a backup.  They were only $59.99 from Tiger Direct - Bargain!!!

2a) The issue with daqd restarting may be a bit more involved.  The first thing that was noticed was that fb1 exhibits the same problem of daqd restarting.  Since fb0 was out of commission at this point, we checked on fb1 to see when the last data in /frames/full was written.  The date was Nov 13th.  Also the user name changes on the 8th, corresponding to this elog posting that Rana put up.  He had been trying to change over all the machines to having the same group user id.  It seems that fb1 however is still on controls oldcon as the user and group.  At some point when the front-end was restarted it no longer had write permission.

b) However having checked out fb0 it appears that this is controls controls, and that it should not have the same problems.  I looked in /frames/trend/second and there is data in there since the Nov 13th date.  However the owner of the data is root which I'm guessing is bad.  I wonder whether the permissions on the /frames/full folder may have been set such that it was unable to write to this folder, or perhaps it was just that the old drive was failing.  It seems that the easiest way to check is to start the frontend again and see if it will record full data.

I ran startatf, then opened the frond end medm panel and set the Burt restore entry to 1.  The front-end came back up just fine, and the gyro MEDM screens are working.  I kept checking back on the processes running until daqd started, with a time of 16:52.  I then went into the /frames/full folder on the new disk and checked for new data.  There was a new data folder which, just like the trend data, is owned by root.  I'm going to leave it for ten minutes to see if any data is recorded that I can access.  I'll come back and update this elog entry........

.....23:35 and daqd is still up and running on fb0 since this afternoon.  So replacing the hard drive seems to have fixed that problem.  Need to look at dataviewer again tomorrow because I can't seem to pull any data on dataviewer without it coming up with errors.

  1249   Thu Jan 20 12:50:43 2011 ZachLab InfrastructureComputingfb0 put back into rack, moved to a better location

 [Alastair, Zach]

We moved fb0 from its limbo on the floor back into the rack. Instead of putting it in its inane previous location (wedged into the very bottom and not fitting in all the way), we put it a little higher up and properly mounted it in. We didn't want to support the back with cable ties, so we found some random Bosch parts that served as pretty good supports. We should look into getting little supports that can screw into the backside of the rack to hold up the longer modules.

We also did some other reasonable things like screwing the lid back on the big blue ADC/DAC module so that the heavy power supply that someone put on top of it didn't crash through it when it was brushed against.

Picture:

fb0.png

  1293   Tue Feb 8 21:28:33 2011 Alastair & Co.ComputingComputingFB0 issues....

Problem 1

Disk sdc was full.  See below list of files, showing that it stopped at 05:43:

-rw-r--r--  1 controls controls 19126210 Feb  8 05:40 C-R-981207616-32.gwf
-rw-r--r--  1 controls controls 19126385 Feb  8 05:41 C-R-981207648-32.gwf
-rw-r--r--  1 controls controls 19104189 Feb  8 05:41 C-R-981207680-32.gwf
-rw-r--r--  1 controls controls  2629632 Feb  8 05:42 .C-R-981207712-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:43 .C-R-981207776-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:44 .C-R-981207840-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:45 .C-R-981207904-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:46 .C-R-981207968-32.gwf

The wiper was running, and was set to 95%:

[controls@fb0 fb]# more wiper.log

Tue Feb  8 20:27:01 PST 2011

Directory disk usage:
/frames/full 912389612k
Combined 912389612k or 891005m or 870Gb

/frames/full size 961432072k at 94.90%
/frames/full is below keep value of 95.00%
Will not delete any files
df reported usage 94.92%

However the disk was full:


[controls@fb0 fb]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     234476168  24758300 197615008  12% /
/dev/sda1               101086     28296     67571  30% /boot
tmpfs                  1029676         0   1029676   0% /dev/shm
/dev/sdd1            1442145212 149825928 1292319284  11% /frames/trend
/dev/sdc1            961432072 912594164         0 100% /frames/full
fb1:/cvs             961432032 108480608 852951424  12% /cvs

Something is screwed up with the way that wiper calculates how full the disk is.  We changed the value down to 90%, and the disk is now at 91%.  The wiper script says it's at 85%, so it's still getting the wrong value, but the disk is no longer full and we are recording frames again.

 

______________________________________________________________

Problem 2

Now that the frame data is being taken again, we can see the realtime data in dataviewer.  However, we cannot get any frame data from the past.  Dataviewer throws up the following error.  The frame data is definitely there, is owned by controls, and we are definitely acquiring the channel whose data we are trying to retrieve.  There is something wrong here that I cannot work out.

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=11-02-08-04-59-52; Length=60 (s)
No data output.

I think this is going to be a problem we need to get Alex to take a look at.

  1326   Tue Mar 1 21:40:49 2011 AlastairComputingComputingWiki

 We now have access control lists for the wiki, which means we can choose who has access to what pages.  At the moment I've set the front page to being non-password protected, along with the main experiments page.  I've also made an LVC account, though at the moment this has no different access than the non-password pages.

We should decide how we want the wiki set up.  Here are a couple of options:

1) We could make dedicated "public" pages, and have these non-password protected. Then we could have LVC access to basically all or most of the wiki, but without any editing rights.  Then we can have our own accounts that can edit.  The downside to this approach is that it is unlikely any public pages will ever be updated.

2) Another option is to allow public access to as many pages as we feel comfortable with, but for these to be the same regular pages that make up the wiki.  This has some advantages because the public pages get updated with everything else.  The downside here is that there will be many frustrating links on public pages that come up with "you do not have enough rights to continue" when you click them.

3) Option 3 is to just have no public access at all.  We just keep the whole thing private, and choose what pages to give the LVC account access to.  Again LVC doesn't need to have editing rights.

I should point out that the LVC account will only have one password (rather than using albert.einstein accounts) so people will have to know the password to get in.

  1355   Thu Mar 17 11:55:08 2011 ranaComputingComputingcoconutBattery

coco.png

  1449   Tue Jul 12 13:41:15 2011 AlastairLab InfrastructureComputingRouter replaced

 The old wired router has been replaced.  I've emailed Larry to ask him to replace the old router MAC address on the DHCP list for this IP address, but it's set up as static anyway.

EDIT:  I heard back from Larry and he has updated the DHCP list to reflect this change.

  1466   Tue Jul 26 21:55:08 2011 AlastairComputingComputingfb0

 Did I break something?  I think I might have.

I rebooted fb0 remotely and now I can't log back in.  Does this thing not start up properly by itself?

EDIT: It's restarted okay now.  It just took ~20mins.  Really strange.

  1468   Wed Jul 27 18:28:40 2011 alastairComputingComputingframe builder is happy again

 The frame builder was unhappy when we looked at it today.  I hadn't restarted the frontend code since rebooting.  After restarting it, daqd didn't seem to want to restart, and there were red warning lights in the FE Diagnostics MEDM screen.  This was even after setting burt restore to 1.

In the end I rebooted the computer, started the front end, set burt restore to 1 and then waited for daqd to start.  It restarted correctly this time, and everything looks good.

  1525   Wed Aug 17 20:16:02 2011 AlastairComputingComputinggw0

 I stopped the sendmail service on gw0, the future gateway machine.  The computer was hanging on startup when it tried to start this service.  I was looking into whether the host name was set up properly when I realised that this service is not running on any of the other machines in the ATF.

Is there any reason why we would need to keep running the sendmail service?

  1582   Tue Dec 20 14:52:05 2011 ZachComputingComputingAdded 'sitemap' alias to fb0

Somehow it wasn't there.

...aaand for some reason it doesn't work. Loads screens fine, but monitors are all blank instead of containing numbers. Odd.

  1583   Tue Jan 3 15:59:07 2012 AidanComputingComputingDirectory clean up

 I've moved all the old medm directories into an archive directory. (/caltech/medm/archive)

I've also gone into the /cvs/cds/advLigo/fe/ and moved all the old models into an archive directory (/cvs/cds/advLigo/fe/archive).

 

  1780   Sat Nov 3 13:20:27 2012 AidanComputingComputingRe-compiled Real Time Model with TCS channels

 I saved the existing ATF model as atf.mdl.ctrl and built a modified version for some temporary TCS real-time work for aLIGO. The new ATF model is saved as atf.mdl.tcs (and currently as atf.mdl).

The new model compiled and was installed. It still runs all the GYRO stuff (which was all unaltered) but I replaced the defunct CTRL block from the doubling experiment with a new TCS block.

- should the old model need to be replaced, this can be done by copying aft.mdl.ctrl to atf.mdl and compiling with fb0:/cvs/cds/advLigo$ make atf install-atf

 

Attachment 1: Screen_Shot_2012-11-02_at_11.51.42_AM.png
Screen_Shot_2012-11-02_at_11.51.42_AM.png
  1781   Mon Nov 5 13:12:53 2012 AidanComputingComputingTCS aLIGO Real-Time model

The C2ATF model with aLIGO TCS controls is now running correctly on fb0

I followed the standard troubleshooting instructions in ATF eLog 124 to get the model to run. All the channels can be access from the C2ATF_TCS_MASTER.adl medm screen in /cvs/cds/caltech/medm/c2/atf/

We're now saving 14 channels of data to frame builder. They are:

[C2:ATF-TCS_AOM_OUT_OUT_DAQ] - 4096Hz

[C2:ATF-TCS_AOM_SET_OUT_DAQ] - 16Hz

[C2:ATF-TCS_CHILLER_SLOW_GAIN_OUT_DAQ] - 16Hz

[C2:ATF-TCS_CHILLER_TEMP_SET_OUT_DAQ] - 16Hz

[C2:ATF-TCS_ISS_IN_AC_OUT_DAQ] - 4096Hz (in-loop ISS PD)

 

[C2:ATF-TCS_ISS_IN_DC_OUT_DAQ] - 16Hz (in-loop ISS PD)

[C2:ATF-TCS_ISS_OUT_AC_OUT_DAQ] - 4096Hz (in-loop ISS PD)

[C2:ATF-TCS_ISS_OUT_DC_OUT_DAQ] - 16Hz (in-loop ISS PD)

[C2:ATF-TCS_LSR_HD_PD_OUT_DAQ] - 16Hz

[C2:ATF-TCS_LSR_SLOW_GAIN_OUT_DAQ] - 16Hz

[C2:ATF-TCS_LSR_TCS_LSR_TEMP_OUT_DAQ] - 16Hz

 

[C2:ATF-TCS_LSR_PWR_MTR_OUT_DAQ] - 16Hz

[C2:ATF-TCS_PZT_CTRL_SENS_OUT_DAQ] - 16Hz

[C2:ATF-TCS_PZT_OUT_OUT_DAQ] - 4096Hz

 

 

 

 

Attachment 1: Screen_Shot_2012-11-05_at_1.08.55_PM.png
Screen_Shot_2012-11-05_at_1.08.55_PM.png
  1931   Wed Jun 10 13:48:22 2015 KateComputingComputingWS1 log in problem

Zach gave me the controls password for ws1 and I just tried logging in. The following error message (see attachment) shows up. Suggestions?

Attachment 1: IMG_0803.JPG
IMG_0803.JPG
  1933   Fri Jun 12 12:23:14 2015 KateComputingComputingWS1 log in problem

Nicolas took a look at this with me. We turned the computer off and attempted to reboot it, but it did not boot. Looking in the BIOS menu, no hard drive is found. I've ordered a new one (Samsung SSD 250MB) and will install the latest version of Ubuntu on it next week when it arrives. 

Quote:

Zach gave me the controls password for ws1 and I just tried logging in. The following error message (see attachment) shows up. Suggestions?

 

  2171   Sun Aug 27 21:55:14 2017 awadeComputingComputingMapping the ATF/PSL/TCS lab

I ran nmap over the local ATF network to find out what was connected and to grab MAC addresses. 

I've updated the lab network infrastructure schematic and table in the ATF wiki here: https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:resources:computing:network:menu

In the last month there were a few changes to the top level router coming into the lab.  The main one is that DHCP has been enabled for IP addresses 10.0.1.150 and above.  Any computer connected to the network adhoc will simple be allocated an address above 150.  This is great for laptops, thin front end computers and test rigs but probably should not be the state of permanent lab computers. 

Also there were a mixer of things plugged into the top level 10.0.1.1 router and randomly into the wall.  These are now all directed through the same node.

Some issues:

  • There is one loose 3com network switch that has unmoored itself and taken on a floating DHCP IP address. This needs to be corrected pronto, however, its not clear if its the PSL lab router or the TCS one. The nmap scan is showing only two 3com routers, that means one is missing from the network or not responding to pings (a config option maybe?).  The DHCP router needs to be nailed down so we can find the missing router and also give it an IP address.
  • Some IP addresses have been allocated manually into the >150 IP address zone.  These may cause conflicts down the track and should be allocated other sensible IPs
  • nmap seems to be skipping  over some DHCP IPs including awade's and Craigs mac laptops.  So its likely that some machines on the network are still being missed.  A bash ping script should maybe be written to catch the missing machines.
  • There are unexplained computers on the network (probably in the TCS lab) that need to be added to the ATF wiki

 

ELOG V3.1.3-