40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 1 of 56  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  27   Sun Feb 10 13:27:57 2008 Stefan BallmerComputingGeneralPictures of Bork-Space setup
Attachment 1: CIMG3586.JPG
CIMG3586.JPG
Attachment 2: CIMG3587.JPG
CIMG3587.JPG
Attachment 3: CIMG3588.JPG
CIMG3588.JPG
Attachment 4: CIMG3589.JPG
CIMG3589.JPG
  43   Fri Apr 11 16:37:03 2008 Stefan BallmerComputingGeneralSet up CDS wireless router / controlling from nokia handheld works
I set up a CDS wireless router:
IP: 131.215.113.2
SSID: cdsrana
Unname & PWD written on router

It has WEP and MAC-filtering enabled.

With that I was able to use the little Nokia handheld to control the digital system.
Example:
- start x-terminal
- 'cd'
- 'ws1'
(this just starts ssh to ws1)
- startSlider
(this bring up the offset slider for the PZT control loop), or
- startmedm
(this starts the OMS main screen)

We have to make medm screens that work for the little Nokia screen....
  50   Fri May 2 22:00:17 2008 DmassComputing Daq Channels
I activated the channels C2:OMS-SUS_T3_ACT_OUT and C2:OMS-SUS_LEFT_IN1 in daqconfig, set both to acquire, and saved them to cvs/cds/caltech/chans/daq/C2OMS.ini

Real screens and naming conventions to follow.

[Edit: I do not know how to disable the auto smileys, so : O is seen as Yawn]
  51   Fri May 2 22:54:44 2008 DmassComputing Screens
I made a simulink model and put it here: /cvs/cds/advLigo/src/epics/simLink/atf.mdl

as instructed by the rolf wiki:
http://lhocds.ligo-wa.caltech.edu:8000/40m/WikiOfRolfCDS?highlight=%28rolf%29

I then changed to the advLigo directory on oms, and "make atf" seemed to run successfully. Before finishing the process, I got the following error when dealing with c2atfepics:

[controls@oms c2atfepics]$ cat iocC2.log
dbLoadDatabase "dbd/a.dbd"
dbLoadDatabase "dbd/atf.dbd"
dbLoadDatabase "dbd/get_local_time.dbd"
registerRecordDeviceDriver(pdbbase)
dbLoadRecords "db/C2/local_time.db"
dbLoadRecords "db/C2/atf1.db"
iocInit
Starting iocInit
############################################################################
### EPICS IOC CORE built on Aug 10 2005
### EPICS R3.14.7 $R3-14-7$ $2004/12/06 22:31:52$
############################################################################
iocInit: All initialization complete
seq &atf,("ifo=C2, site=caltech, sys=ATF, sysnum= 10")
SEQ Version 2.0.10: Wed Aug 10 23:41:07 2005
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 46391,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
Couldn't open `/rtl_mem_atf' read/write
open("rtl_epics"): No such file or directory
  52   Mon May 5 20:32:50 2008 DmassComputingGeneralMEDM, FB, FE, Etc
I restarted the oms box in the rack, and was in the process of trying to get new medm control screens up with Rob. I now have neither the old mislabelled oms screens, nor the new soon to be beautiful screens, as well as no way to finish my measurement of the PMC cavity pole until I get those back up and running.

Will be reading
http://www.ligo.caltech.edu/%7Eaivanov/daq_handbook.html

and if that fails,
Will bug Alex or Stefan tomorrow.
  54   Wed May 7 04:44:31 2008 DmassComputingGeneralDTT and Fast Channels fixed
The playback in dataviewer on the fast channels was semi broken (would not display full data on a playback, but could do all else).

Also, DTT was giving an error "failed to start diagnostics kernel" whenever we attempted to launch it.

I talked to Alex and he managed to fix both of these problems.
  58   Thu May 29 20:00:48 2008 tobinComputingFuglyborkspace compiling
Dmass and I tried to compile and install a new system on the borkspace machine here.
We ran into a few difficulties.

First, the startup script for the EPICS server can't find the channel access library.
A hack to fix this is to enter this command in the terminal before running the start
script:

export LD_LIBRARY_PATH=/opt~/epics-3.14.7-x86_64/base-3.14.7/lib/linux-x86

With this, the OMS system front-end runs fine. But we can't start our new system,
ATF. The ATF front-end dies with the error:

[controls@oms advLigo]$ cat /cvs/cds/caltech/target/c2atf/log.txt
cpu clock 2412402
open failed for write on /rtl_epics (45)

I looked in the controller.c code and it appears that the front-end code wants there
to be a special file /rtl_mem_atf. I made one of these using both a hard link, and
then via mknod ("sudo mknod rtl_mem_atf u 150 132"), mirroring the existing rtl_mem_oms,
but neither attempt worked. Will ask Alex for help.
  59   Sun Jun 1 18:52:49 2008 tobinComputingGeneralborkspace compiling
Following Alex's suggestions, I fixed the front-end problems we were encountering the other day.

To get the shared libraries stuff to work, I inspected the contents of /etc/ld.so.conf.d and 
found it all looking fine.  I ran /sbin/ldconfig, which updates some shared library index 
somewhere, which seemed to fix the problem with the EPICS server finding its libraries.  To create 
the /rtl_mem_atf file, I edited /etc/rc.local, adding "atf" to the list of subsystems.  I believe
that everything now works to compile and run the ATF front-end system.

As a reminder, some useful commands:

cvs update               refreshes the software distribution from CDS
make atf                 recompiles the front-end system
make install-atf         installs new front-end binary and scripts
make install-daq-atf     installs DAQ channel stuff to framebuilder
make install-screens-atf makes new generic MEDM screens

killatf                  Stop the front end code
startatf                 Stop and then start the front-end-code

If you want to change the name of the computer itself, I think you just
need to (1) edit /etc/sysconfig/network and change the hostname; and (2)
etc /etc/hosts on all the machines from which you'll be connecting to the
front-end machine (at the moment, just ws1?).

[fixed command syntax - 7/22/08 DYM]
  62   Wed Jul 16 11:47:18 2008 DmassComputingGeneralFront End Machine Namechange
The front end machine in the Bridge Basement has been renamed "atf" from "oms".

I changed /etc/sysconfig/network on oms(now atf) and
/etc/hosts on ws1 (the dual head control station)
by replacing the "oms" tag with "atf"

When you ssh into atf from ws1, it still says you are logged in as "controls@oms". There appears to be more to change.

Disambiguation of the digital locking system to follow.
  65   Tue Jul 22 18:43:06 2008 DmassComputingfubardigital control broken.
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.
  67   Fri Jul 25 14:59:24 2008 DmassComputingfubardigital control broken.

Quote:
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.


With the assistance of a benevolent Rob, the above problem was identified and fixed.

While looking at the logfile for C2oms, we found the script omsfe.rtl was crapping out because there were no daq channels set to acquire. We fixed this by manually setting one of the channels to acquire in C2oms.ini and uncommenting it. We then dropkicked the framebuilder by telneting in via
> telnet fb0 8087
and doing a shutdown. This should be equivalent to clicking the DAQ Reload button on the oms FE Diagnostic medm screens. This fixed the problem of the daq not starting, and we could get realtime data via dataviewer. To start recording it in the daq again, we just need to edit "C2oms.ini" to reflect which channels we are interested in recording.

It appears we can still not toggle channels to acquire via the daqconfig gui. I will worry about that more when I have a version control screens here that I am happy with, and harrass Alex.

We also found something interesting when we tried to interact with the system via DTT. It seemed that the system wanted there to be a link tpchanm1 pointing to tpchanC2, but the creation and subsequent annhilation of this link seemed to not effect the system. When we looked closer, the file we expected to define all the test points, /cvs/cds/caltech/chans/param/tpchn_C2.par, was full of objects for the atf system. The file that the system appears to actually get its definitions of these from was /cvs/cds/advLigo/build/omsepics/oms.par.

Rob says that this was an indication that something in the series of "make ___" commands is broken, as they should have overwritten this file at some point.
  70   Mon Jul 28 15:58:49 2008 DmassComputingDAQDaq not recording
There is still something wonky with the DAQ. Nothing appears to be writing at the moment, as I can only get 8 seconds of data from the playback in dataviewer. I may table this until I am trying to get the new system up and running.
  73   Fri Aug 1 14:52:27 2008 DmassComputingDAQDaq not recording

Quote:
There is still something wonky with the DAQ. Nothing appears to be writing at the moment, as I can only get 8 seconds of data from the playback in dataviewer. I may table this until I am trying to get the new system up and running.


I abducted Rob from the 40m to look at this, and he thinks it has something to do with the fact that awgtpman (the test point manager) will not run. He beat at it with his kung-fu, but the computer would not yield. Ws1 does not yet know fear, but it shall soon learn.
  74   Fri Aug 1 15:06:11 2008 DmassComputingCDSATF system
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf
  75   Tue Aug 5 15:23:38 2008 DmassComputingCDSATF system

Quote:
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf


The rm /cvs... command should be replaced by make uninstall-daq-atf. It does the removal and slightly more.
  76   Mon Aug 11 14:15:57 2008 DmassComputingCDSATF system

Quote:
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf


I talked to Alex, and he told me something about "your frames file is full, let me empty it and call you back," and he did so.

I did a reinstall of the daq
make unistall-daq-oms
and
make install-daq-oms

then I edited the .ini files with the channel names I wanted information about in

/cvs/cds/caltech/chans/daq/
C2OMS.ini is the file with the information I want in it.
oms.ini is the file which daqconfig interfaces with.

I edited the files via the daqconfig, and then overwrote the C2OMS.ini file with it, then data seemed to be recording and I could access it via dataviewer.

One concern/piece of information:
Apparently at some point they decided to change the convention on file suffixes for channel names. C2OMS.ini has a *_32768 tacked onto the end of
the channel name upon generation by the make scripts, whereas the oms.ini file has a *_DAQ in its place. This seemed to be the cause for some
of the noncooperation between the various sytems. Daqconfig likes the *_DAQ suffix, and this seems to jive with the data now writing, so we shall
go with that.
  79   Fri Aug 15 15:59:07 2008 DmassComputingDAQDAC DAQ and ADC working
The problem was the timing. I changed what the simulink .mdl file wanted for a clock signal to what it was actally getting (64 kHz), and everything was magically ok.

It appears that the ADC can function at 32kHz with a 64kHz clock signal, but the DAC apparently can not.

Several PC board were removed and/or inspected before I realized that I should change this.
  80   Mon Aug 18 23:46:42 2008 DmassComputingDAQMore on the DAQ
It appeared today that the DAQ channels wouldnt record. Only one would write no matter how I edited the .ini file.

I rebuilt everything, and the channels had the _32xxx suffix instead of the _DAQ suffix, and proceeded to write to the DAQ, allowing Masha to continue to slave away.
  95   Mon Sep 22 18:03:34 2008 DmassComputingDAQDAQ IS BACK - as is the 35W
The Chiller appears to not be leaking.
There are no squeaks coming from under the table.
The 35W is on.
The DAQ is recording again (fix detailed below)
The 35W is being trended at a pickoff post-MOPA
The 2W NPRO will be trended when I get my hands on the PD schematic from the Germans. PK emailed them


I talked to Alex, and it seems the problem was in
controls@oms > /frames/full/dataxx

I had changed the filesize apparently (by changing the sample rate), and the software doesn't correct for that in the number of files it keeps.

I had to edit /cvs/cds/caltech/target/fb/daqdrc

I deleted all the files in /frames/full, then decreased the sample rate in
/cvs/cds/caltech/chans/daq/C2OMS.ini to 16 kHz for the channels I am interested in.

Then I upped the number of dataxx files to 120 from 60 to correct for the factor of 2 it was off by before, and the factor of four division in sample rate I gave it in daqdrc.

Then I tried to make everything again in advLigo by running:
* make uninstall-daq-oms
* make clean-oms oms install-oms
* make install-daq-oms
* make install-screens-oms
* startoms


I looked at the log files for the fb in /cvs/cds/caltech/target/fb/logs/* and found errors about the dataxx files (which I had deleted) not existing, so I replaced them by hand with the following in a bash file (filename.sh):
#!/bin/bash
for i in `seq 0 119`; do
mkdir "data$i"
done

and running it with >bash filename.sh in the /frames/full directory.

I then rebuilt everything, restarted the fb by telneting in
* telnet fb0 8087
daqd>shutdown


and reset the daq in the oms medm screens via the reset button. After all this the data was writing again.
  112   Thu Apr 9 11:26:21 2009 alastairComputingDAQDAC now working

The output from the DAQ is now working, and the timing etc looks sensible, though still at 64khz.  I've only tested the four outputs I've setup in my model, but they all work when I use the output matrix to patch the signal to them.

  113   Fri Apr 17 20:04:17 2009 dmassComputingDAQADC no longer working!

I was trying to get the ATF.mdl or OMS.mdl system back up and running, but neither could see fb0.

I telneted in with

>telnet fb0 8087

daqd> shutdown

to reboot fb0. It didn't fix the problem.

I also rebooted oms.

 

I discovered in the course of this that the oms.mdl file was overwritten with Alastair's model. I (saved and) replaced it with an old copy of the oms.mdl file from ws1, and did

make oms

make install-oms

make install-daq-oms

make install-screens-oms

startoms

but was no longer able to get a connection to fb0.

 

I then reinstalled Alastair's model, since it was the last thing I saw communicate with the fb succesfully. I am unsure what I am forgetting, possibly some command I need to run on oms after rebooting it. I was unable to get Alastair's model back up and talking to the framebuilder and I have thus left the DAQ slightly more broken than I found it.

Quote:

The output from the DAQ is now working, and the timing etc looks sensible, though still at 64khz.  I've only tested the four outputs I've setup in my model, but they all work when I use the output matrix to patch the signal to them.

 

 

  117   Mon Apr 20 18:03:44 2009 dmassComputingDAQADC no longer working!

This all started when I did a cvs update. I have forwarded my concerns, trials, and tribulations to the russian.

 

Quote:

I was trying to get the ATF.mdl or OMS.mdl system back up and running, but neither could see fb0.

I telneted in with

>telnet fb0 8087

daqd> shutdown

to reboot fb0. It didn't fix the problem.

I also rebooted oms.

 

I discovered in the course of this that the oms.mdl file was overwritten with Alastair's model. I (saved and) replaced it with an old copy of the oms.mdl file from ws1, and did

make oms

make install-oms

make install-daq-oms

make install-screens-oms

startoms

but was no longer able to get a connection to fb0.

 

I then reinstalled Alastair's model, since it was the last thing I saw communicate with the fb succesfully. I am unsure what I am forgetting, possibly some command I need to run on oms after rebooting it. I was unable to get Alastair's model back up and talking to the framebuilder and I have thus left the DAQ slightly more broken than I found it.

Quote:

The output from the DAQ is now working, and the timing etc looks sensible, though still at 64khz.  I've only tested the four outputs I've setup in my model, but they all work when I use the output matrix to patch the signal to them.

 

 

 

  118   Wed Apr 22 11:33:24 2009 DmassComputingDAQDAQ back up and running

This from Alex:

"Looks like we changed GM nodename from fb into fb0 in the code, so I had
to rename the node in /etc/gm/hostname.

It is up and running"

 

 

  119   Wed Apr 22 14:47:47 2009 DmassComputingDAQDAQ back up and running

This got the oms system back up and running. Data was going into the ADC, through the filters, and back out the DAC.

I got the ATF system up and running, but had to change one more thing.

in the /cvs/cds/caltech/target/fb/master file there is a line which tells you which .ini file to use (in /cvs/cds/caltech/chans/daq/) If this is not set correctly nothing will really work.

We can configure it to have more than one system run at the same time by giving them different dcuids, but until we want to do that, to change to a new system, after you configure your sys.ini file, you have to manually put it in the master file.

 

On to medm screens.

 

Quote:

This from Alex:

"Looks like we changed GM nodename from fb into fb0 in the code, so I had
to rename the node in /etc/gm/hostname.

It is up and running"

 

 

 

  120   Thu Apr 23 15:25:35 2009 DmassComputingDAQATF Screens/DAQ up and running.

I made screens for the lab from the atf.mdl file which is in the /cvs/cds/advLigo/src/epics/simLink/ directory

They live in /cvs/cds/caltech/medm/c2/atf/

C2ATF_MASTER has links to what is there.

We have two 8 in ---> 8 out filtered matrixed subsystems.

 

Pics to be included later.

Enjoy.

 

P.S. The DAQ is now writing at 16 kHz. If you want data at a different speed, there may be funniness that needs to happen with the /frames/full directory.

  121   Sat Apr 25 12:11:54 2009 ranaComputingDAQATF Screens/DAQ up and running.
Cool. For properness all of the medm screens should be in the /cvs/cds/caltech/medm/ directory. We should
also pull down the medm/c1/ directory from the 40m SVN, since its always useful for copy-paste
operations. And all of the FE code (models, etc.) should be in the caltech/target/ dir.

How about second-trend and minute-trend? How far is the lookback? Do we need a bigger disk?
  122   Fri May 1 16:39:12 2009 AidanComputingCDSRCG make screwiness - how do i clean up old and failed makes?

Had problems compiling/making the Realtime Code Generator (RCG) example application in the document T080135-00-C.

Got Dmass onto the case and we tried the following things:
1. Renamed the file AFB.mdl so that it was lowercase: afb.mdl - result: 'make' still failed
2. Replaced the mux/demux elements in the ETMX subsystem with standard 8x8 matrices - called 'Matrix' and 'Matrix1' - result: 'make' still failed
3. Renamed the output elements in the ETMX subsystem so that there were no lowercase names: ULOut -> UL_OUT, UROut -> UR_OUT, etc. Result: 'make' still failed
4. I compared the 'make' output of making oms.mdl, which is a working version of the same example application, with the 'make' output of making afb.mdl. Initially the making of afb.mdl differed because it couldn't find the elements ETMX_Matrix and ETMX_Matrix1. I renamed these matrices in afb.mdl with all uppercase names (IN_MTRX and OUT_MTRX) and the make of afb.mdl progressed further before encountering an error and failing again.

At this point it gave the following complaints:
../AFB/AFB.c: In function `feCode':
../AFB/AFB.c:88: error: structure has no member named `AFB'

To be honest, I suspected that there was some residual junk code somewhere from all the previous failed compliations and the renaming of the filename from uppercase to lowercase

I copied the simuLink model afb.mdl to afc.mdl, a completely clean and shiny new name, and tried making afc.mdl instead. And it worked fine.

So the good news is that the simLink example I created makes and that 'make' itself is working fine.

The bad news is that some combination of the above actions has, presumably, left some junk files somewhere that are screwing up the making of afb.mdl. So ... how do i completely clean up an old and failed make?

  123   Tue May 5 14:43:05 2009 AidanComputingCDSRCG make screwiness - how do i clean up old and failed makes?

 

Found uninstall solution in DMass's elog entry:

 

Quote:

Had problems compiling/making the Realtime Code Generator (RCG) example application in the document T080135-00-C.

Got Dmass onto the case and we tried the following things:
1. Renamed the file AFB.mdl so that it was lowercase: afb.mdl - result: 'make' still failed
2. Replaced the mux/demux elements in the ETMX subsystem with standard 8x8 matrices - called 'Matrix' and 'Matrix1' - result: 'make' still failed
3. Renamed the output elements in the ETMX subsystem so that there were no lowercase names: ULOut -> UL_OUT, UROut -> UR_OUT, etc. Result: 'make' still failed
4. I compared the 'make' output of making oms.mdl, which is a working version of the same example application, with the 'make' output of making afb.mdl. Initially the making of afb.mdl differed because it couldn't find the elements ETMX_Matrix and ETMX_Matrix1. I renamed these matrices in afb.mdl with all uppercase names (IN_MTRX and OUT_MTRX) and the make of afb.mdl progressed further before encountering an error and failing again.

At this point it gave the following complaints:
../AFB/AFB.c: In function `feCode':
../AFB/AFB.c:88: error: structure has no member named `AFB'

To be honest, I suspected that there was some residual junk code somewhere from all the previous failed compliations and the renaming of the filename from uppercase to lowercase

I copied the simuLink model afb.mdl to afc.mdl, a completely clean and shiny new name, and tried making afc.mdl instead. And it worked fine.

So the good news is that the simLink example I created makes and that 'make' itself is working fine.

The bad news is that some combination of the above actions has, presumably, left some junk files somewhere that are screwing up the making of afb.mdl. So ... how do i completely clean up an old and failed make?

 

  124   Tue May 5 16:36:40 2009 AidanComputingCDSRealtime code generation (RCG) troubleshooting

Useful things to try when making Simulink models with RCG


1. When making a new model foo.mdl use the following text
make uninstall-daq-foo
make clean-foo foo install-foo
make install-daq-foo
make install-screens-foo


2. start the MEDM screen C2FOO_GDS_TP.adl

2. A. kill whatever is running:
e.g. on oms > killoms
       > killatf

2. B.  find the .ini (C2FOO.ini) and edit it so that at least one channel is acquiring - do this whenever an install or reinstall are run.
2. C. manually edit the master file in fb0 to point to C2FOO.ini
  /cvs/cds/caltech/target/fb/master
2. D. start foo on oms > startfoo

see if things start to light up on the MEDM screen C2FOO_GDS_TP.adl

check if the front end is running
      /sbin/lsmod
  - should see 'foofe' and 'gm' running

look at the log file in /cvs/cds/caltech/target/c2foo
 - log.txt - will either be a couple of lines with an error message or a lot of stuff that looks like things are working:


3. go to /etc/rc.local and add foo to file. file is read-only so use 'sudo vi rc.local'
e.g. /etc/setup_shmem.rtl ipc sas test oms atf afb afc foo&

update shared library index (see Tobin's entry)
   > /sbin/ldconfig


4. try a restart of oms
   > sudo reboot

try 'startfoo' again - hopefully at this stage parts of the MEDM screen should start lighting up


5. if still problems (parts of GDS MEDM screen are still white), try to reboot fb0
   > telnet fb0 8087
      > shutdown

 
try to start again
   > killfoo
   > startfoo


6. check last line of log file /cvs/cds/caltech/target/c2foo/log.txt -
might require BURT restore

go to C2FOO_GDS_TP.adl MEDM screen and set BURT restore value to 1

should be okay now ...
 

  130   Fri May 15 17:32:30 2009 AidanComputingFiberStarted screen for Fiber Stabilization - and claiming CDS channels

I'd like to use ADC channels 13-16 for the photodiodes in the FS experiment. Also going to use DAC channel 16 for feeding back to the AOM. We should decouple the signals on the MEDM screens so that you can't, inadvertantly, feed gyro error signals to the FS output.

Started work on a FS control screen (C2ATF_FS_CONTROL.adl shown below). It's accesible from the C2ATF_MASTER screen (also shown below). There won't be that much too it ... just an box allowing you to control the in-loop signals and the feedback to the frequency of the AOM. The lower box will simply be the input  signals from the out-of-loop PDs.

 

 

 

Attachment 1: Screenshot-C2ATF_FS_CONTROL.adl.png
Screenshot-C2ATF_FS_CONTROL.adl.png
Attachment 2: Screenshot-C2ATF_MASTER.adl.png
Screenshot-C2ATF_MASTER.adl.png
  141   Wed Jun 24 15:17:59 2009 DmassComputingCDSNokia Wireless Device

To use the small Nokia wireless device:

 

1) Connect to cdsrana

2) Check what the ip of the machine you want to use is (/sbin/ifconfig)   - 131.215.113.56 at the time of this entry

3) run an x-terminal on the nokia (under extras)

4) enter into the command line :   ssh controls@IP

5) It will prompt you for a password, enter.

you can now run simple medm screens of your design from anywhere with wireless access to the cdsrana network!

  149   Thu Jul 2 21:40:57 2009 Aidan, ConnorComputingDAQFrame builder shenanigans

There appears to be something screwy going on with the frame builder - have some things been compiled and others not? Either that or I don't understand the system well enough.

We plugged a signal generator output a 0.1Hz sine wave into CH9 of the DAQ. This showed up in Alastair's medm Gyro screen (C2ATF_GENCONT.adl) in channel C2:ATF-GENERIC_GEN1_INMON. When we want this written to the frame, however, I have to uncomment the channel C2:ATF-CTRL_SIG_1_IN1_32678 in /cvs/cds/caltech/chans/daq/C2ATF.ini. This channel shows up in Dataviewer and the 0.1Hz signal is clearly visible.

I suspect that things have been only partially compiled recently and we need a clean rebuild of the front end and daq and frame builder. Anyway, we can get signals at the moment so we're actually going to do something useful, like characterize the intensity noise of the NPRO.

 

 

  150   Fri Jul 3 19:49:30 2009 AidanComputingDAQDAQ Map medm screen - Connectors and Channel names

I've created an medm screen that displays the current data channels associated with each of the connectors on the front of the DAQ. Basically its supposed to make it really easy to figure out what each channel in the DAQ physically corresponds to. I've added a link (DAQ MAP button) to it on the main medm screen

Eventually this should be automatically generated every time we rebuild the front end. I'd also like to include an indication on there of the units of each channel and whether they are in the frame or not.

medm screen: /cvs/cds/caltech/medm/c2/atf/C2ATF_DAQ_MAP.adl

Please do not edit this screen in the medm editor. I've added some comments to the file and moved the definition of each of the channels to the end of the file. The comments get erased when the screen is edited and the channel definitions get moved back to different places in the file.

 

Attachment 1: C2ATF_DAQ_MAP.png
C2ATF_DAQ_MAP.png
  151   Fri Jul 3 21:26:13 2009 AidanComputingDAQDAQ Map medm screen - added channel frame acquisition status

Quote:

I've created an medm screen that displays the current data channels associated with each of the connectors on the front of the DAQ. Basically its supposed to make it really easy to figure out what each channel in the DAQ physically corresponds to. I've added a link (DAQ MAP button) to it on the main medm screen

Eventually this should be automatically generated every time we rebuild the front end. I'd also like to include an indication on there of the units of each channel and whether they are in the frame or not.

medm screen: /cvs/cds/caltech/medm/c2/atf/C2ATF_DAQ_MAP.adl

Please do not edit this screen in the medm editor. I've added some comments to the file and moved the definition of each of the channels to the end of the file. The comments get erased when the screen is edited and the channel definitions get moved back to different places in the file.

 

 

I've added some indicators to the DAQ_MAP medm that show whether channels are saved to frame ("SAVED") or not ("LOST"). I'll have to add a routine to the frame builder start up so that these are updated whenever the frame builder is rebooted.

Attachment 1: C2ATF_DAQ_MAP_v1.1.png
C2ATF_DAQ_MAP_v1.1.png
  152   Sat Jul 4 12:42:06 2009 Aidan ComputingDAQDAq Map screen complete - just need to work out how to generate it automatically now

I've finalized the DAQ_MAP screen. All the current channels are accounted for. I've added some standard LIGO medm screen paraphenalia, such as the information button and the title bar.

I'd like to incorporate this into the build of a front end so that this screen is generated automatically. I'm a bit stumped as to how to get the LOST/SAVED indicators to work automatically. Maybe we can write something that will run in the startup of fb0.

A couple of extra notes:

1. The names of the channels in the frame builder do not exactly match the names in EPICS. This makes it impossible to drag and drop channel names into data viewer. Example:

C2:ATF-QPD1_SEG1 is the  channel defined in Simulink. C2:ATF-QPD1_SEG1_INMON is the channel as it appears in EPICS and C2:ATF-QPD1_SEG1_IN1_32768 is the channel as it appears in the frame builder. Can we add a channel in the frame builder that has the same name as the corresponding EPICS channel?

2. There seems to be a problem with CH32. It's working, in the sense that the channel exists, but when I plug the signal generator into the corresponding BNC connector on the DAQ I don't see any response on EPICS. Need to triple check that I haven't done made a typo anywhere.

Attachment 1: C2ATF_DAQ_MAP_v1.11.png
C2ATF_DAQ_MAP_v1.11.png
  156   Tue Jul 7 09:26:48 2009 AidanComputingDAQFrame builder not restarting ...

 

I tried to reboot the frame builder last night, as below, and now it won't restart and I can't log into it. If I can find the box then I can try to physically reset it.

[controls@ws1 ~]$ telnet fb0 8087
dadq> shutdown
  157   Tue Jul 7 15:16:35 2009 AidanComputingDAQFrame builder not restarting ... fixed!

Fixed!

The problem was a typo that had cropped up in /cvs/cds/caltech/chans/daq/C2ATF.ini when I was editing this file. I had to fix that file and reboot oms to get the frame builder working again. Now it appears to be fine - I can telnet into fb0 again.

 

Quote:

 

I tried to reboot the frame builder last night, as below, and now it won't restart and I can't log into it. If I can find the box then I can try to physically reset it.

[controls@ws1 ~]$ telnet fb0 8087
dadq> shutdown

 

 

 

  165   Thu Jul 9 10:45:16 2009 AidanComputingDAQAlex's frame builder problem diagnosis ...

 

This from Alex: 

 

The filesystem is full. If you look at the log messages:

[controls@oms fb]$ pwd
/cvs/cds/caltech/target/fb
[controls@oms fb]$ tail -5 logs/daqd.log.19816 
[Thu Jul  9 10:07:51 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194464-16.gwf' for writing; errno 28
[Thu Jul  9 10:07:51 2009] Couldn't open full trend frame file
`/frames/trend/second/data2/C-T-931194420-60.gwf' for writing; errno 28
[Thu Jul  9 10:08:07 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194480-16.gwf' for writing; errno 28
[Thu Jul  9 10:08:23 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194496-16.gwf' for writing; errno 28
[Thu Jul  9 10:08:39 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194512-16.gwf' for writing; errno 28
[controls@oms fb]$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     275G  261G     0 100% /frames


I stopped the frame builder for now until we figure out the data
directories. Can I delete all the data in /frames/full and recreate a new
set of directories? Otherwise this is too messy to rearrange. Let me know.

-alex


On Wed, 8 Jul 2009, Aidan Brooks wrote:


Hi Alex,

I fixed the problem with being able to telnet into fb0. There was just a typo in the file:
/cvs/cds/caltech/chans/daq/C2ATF.ini
Once I fixed that the frame builder rebooted just fine.

The problem at the moment is that the data does not appear to be writing to file. If I rebuild the front end from the start, so I go to oms and run the following commands:

cd /cvs/cds/advLigo
make realclean
make atf
make install-atf
make install-daq-atf
make install-screens-atf

And if I edit the file C2ATF.ini so that a single channel, e.g. C2:ATF-CTRL_PMC_REFL_IN1_DAQ is set to acquire. 

and killatf, followed by startatf and reboot the frame builder

Then: the front end starts okay and I can see signals in the EPICS screen that make sense. I can run StripTool and see the real time time series of a channel, I can start dataviewer and see C2:ATF-CTRL_PMC_REFL_IN1_DAQ in the list of fast channels. I can run the realtime viewer in dataviewer and see that channel realtime in a Grace window. However, I cannot get a playback of that channel to work and if I run dtt I can only get a spectrum if I specify a start time for that spectrum within the last (approximately) 30s in the past.

The data rate in the .mdl simulink model is 16K, the data rate in the C2ATF.ini files is 16K, the data rate in the file:
/cvs/cds/caltech/target/fb/daqdrc is set to 16K and there are 120 data directories in the /frames/full directory.

I can't think of any reason why the data is not being written to file. Can you log in and figure out what's wrong? You should be able to get access via controls@131.215.114.183

Thanks for your help,
Aidan.
 

  166   Thu Jul 9 10:46:52 2009 AidanComputingDAQDeleted old /frame/full directories and rebuilt directory structure ...

 

This was also from Alex:

 

Too late, I deleted /frame/full data already, sorry.

So I changed the number of full frames dirs from 120 down to 60 and
restarted the frame builder and c2atf front-end. Looks like the data is
written out to disk now. Please check it out.

Alex

  168   Thu Jul 9 13:29:08 2009 AidanComputingDAQMore from Alex on frame builder disk being full

 Hey Alex,


I've got a couple of questions (just for my own understanding).

- I thought the frames were supposed to overwrite old data. Why then  
did the disk appear full? And is it likely to appear full in future?  
If so how do we deal with it?

I reduced the total number of data directories from 120 to 60. I think the
frame size has increased and  so the disk filled up. daqd program, the
version you have there, erases old frames based on total number of
directories, it doesn't look at the disk full percentage. I have a new
version which doesn't do that, so we may want to install that new version
at some point, especially when you guys decide to upgrade to the latest
real-time code generator software. The new version of daqd/nds is not
erasing anything but simply relies on a cron job to erase old files.

- why did you reduce the number of directories in /frame/full to 60?

Thanks for your help,
Aidan.
 

  183   Sun Jul 19 09:44:09 2009 AidanComputingGeneralAliases added for standard LIGO tools

 

I've updated the /home/controls/.bashrc file to include some aliases to standard ligo tools. These should now be accessible anywhere from the command line.

alias dtt="/bin/diaggui"
alias dmt="/bin/dmtviewer"
alias foton="/bin/foton"
alias dv="dataviewer"
 
StripTool is already accessible from the command line.

  193   Thu Jul 23 07:22:35 2009 AidanComputingCDSChecked out the 40m MEDM screens from SVN to /cvs/cds/caltech/medm/c1

 

As title says ...

  194   Thu Jul 23 07:33:41 2009 AidanComputingCDSAdded C2 MEDM screens to 40m SVN.

 

I've added our medm screens from the ATF to the 40m SVN. They can be found in 

https://nodus.ligo.caltech.edu:30889/svn/trunk/medm/c2/atf/

  222   Tue Aug 4 15:01:28 2009 DmassComputingDAQTransfer Functions and DTT

So I was trying to take some transfer functions with DTT using an analog sweep.

We don't have AWG or test points, so I was trying to do it with DAQ channels. I set number of A channels as 1, set the rest, then tried to run it.

I get the error "Readback channel unavailable (); Unable to setup test channels" 

I may be SOL to take any transfer functions without either AWG or the test points working if there is some sort of handshake missing.

  223   Tue Aug 4 15:37:17 2009 DmassComputingCDSNokia Wireless Device

Quote:

To use the small Nokia wireless device:

 

1) Connect to cdsrana

2) Check what the ip of the machine you want to use is (/sbin/ifconfig)   - 131.215.113.56 at the time of this entry

3) run an x-terminal on the nokia (under extras)

4) enter into the command line :   ssh controls@IP

5) It will prompt you for a password, enter.

you can now run simple medm screens of your design from anywhere with wireless access to the cdsrana network!

 

The Nokia wireless device was not able to connect to ws1, and for some reason, (probably related ?) we couldn't ssh into ws1 from the outside world either.

I reset the routers, and renewed the DHCP lease. This seems to have fixed the problems.

New IPs:

131.215.113.56 (for cds - same)

131.215.114.120 (for the outside world)


I have also sent Alex an email asking him to fix our awg/test points now that he can ssh in.

  225   Tue Aug 4 18:41:49 2009 DmassComputingDAQTransfer Functions and DTT

Quote:

So I was trying to take some transfer functions with DTT using an analog sweep.

We don't have AWG or test points, so I was trying to do it with DAQ channels. I set number of A channels as 1, set the rest, then tried to run it.

I get the error "Readback channel unavailable (); Unable to setup test channels" 

I may be SOL to take any transfer functions without either AWG or the test points working if there is some sort of handshake missing.

 

Using the Fourier tools, I took a first attempt at getting a good open loop transfer function for my PMC.

The bottom right plot is my error signal in blue, and my noise injection in red.

Attachment 1: OMCOLTF2.jpg
OMCOLTF2.jpg
  226   Tue Aug 4 19:33:47 2009 KojiComputingDAQTransfer Functions and DTT

Oh...This should not be the openloop transfer function. You must multiply the transfer function between two measurement points
unless those two points are just before and after the injection point.

Quote:

Quote:

So I was trying to take some transfer functions with DTT using an analog sweep.

We don't have AWG or test points, so I was trying to do it with DAQ channels. I set number of A channels as 1, set the rest, then tried to run it.

I get the error "Readback channel unavailable (); Unable to setup test channels" 

I may be SOL to take any transfer functions without either AWG or the test points working if there is some sort of handshake missing.

 

Using the Fourier tools, I took a first attempt at getting a good open loop transfer function for my PMC.

The bottom right plot is my error signal in blue, and my noise injection in red.

 

  227   Tue Aug 4 21:55:00 2009 DmassComputingDAQTransfer Functions and DTT

Quote:

Oh...This should not be the openloop transfer function. You must multiply the transfer function between two measurement points
unless those two points are just before and after the injection point.

Quote:

Quote:

So I was trying to take some transfer functions with DTT using an analog sweep.

We don't have AWG or test points, so I was trying to do it with DAQ channels. I set number of A channels as 1, set the rest, then tried to run it.

I get the error "Readback channel unavailable (); Unable to setup test channels" 

I may be SOL to take any transfer functions without either AWG or the test points working if there is some sort of handshake missing.

 

Using the Fourier tools, I took a first attempt at getting a good open loop transfer function for my PMC.

The bottom right plot is my error signal in blue, and my noise injection in red.

 

 The channels are set up in such a way that I am measuring on either side of my injection  point with no filters in between

  228   Tue Aug 4 23:52:06 2009 KojiComputingDAQTransfer Functions and DTT

A working servo loop should not have such a low openloop gain like -60dB or -80dB in the working frequency band.
Please check the setting and the math.

Ultimately any measured openloop tf should be explained by the interferometer model, the filter response, and the actuator response.
(e.g. Ph.D thesis by M.Ando P.142 http://t-munu.phys.s.u-tokyo.ac.jp/theses/ando_d.pdf )

Quote:

Quote:

Oh...This should not be the openloop transfer function. You must multiply the transfer function between two measurement points
unless those two points are just before and after the injection point.

 The channels are set up in such a way that I am measuring on either side of my injection  point with no filters in between

 

Attachment 1: Pages_from_ando_d.png
Pages_from_ando_d.png
  230   Wed Aug 5 15:14:55 2009 DmassComputingCDSAWG and TP now up

I emailed Alex and:

 

Hi David,
looks like you have switched from running om1/om2 pair to running atf.
When you do that you have to alter testpoint.par file:


[controls@oms param]$ pwd
/cvs/cds/caltech/target/gds/

param
[controls@oms param]$ ls -alt testpoint.par
-rw-r--r-- 1 controls controls 330 Aug  5 08:52 testpoint.par

I changed om1 to atf there.

Testpoints are working now.
 
Test points and AWG are now up.

ELOG V3.1.3-