I managed to get pianosa working again with just a single monitor.  I'm done trying to configure it for dual, though.

I'll finish the rest of the config to turn it into a full-fledged workstation tomorrow.

I decided to remove what I thought was the problematic extra nVidia video card, since there are already two DVI outputs build-in.  The card turned out to not even be nVidia, so I don't know what was going on there.

I futzed with the BIOS to configure the primary video card, which is some new Intel card.  The lucid (10.04) support for it is lacking, but it was easy enough to pull in new drivers from the appropriate Ubuntu PPA repository:

controls@pianosa:~ 0$ sudo apt-add-repository ppa:f-hackenberger/x220-intel-mesa
controls@pianosa:~ 0$ sudo apt-add-repository ppa:glasen/intel-driver
controls@pianosa:~ 0$ sudo apt-get update
...
controls@pianosa:~ 0$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa xserver-xorg-video-intel
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,212kB of archives.
After this operation, 25.2MB disk space will be freed.
Do you want to continue [Y/n]?
...
controls@pianosa:~ 0$

After a reboot, both monitors came up fine.

http://www.subcritical.org/running_ubuntu_lts_on_sandy_bridge/

Added zita to the martian host table, and configured his network accordingly:

zita            A       192.168.113.217

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

tdsavg isn't working:

controls@rossa:/opt/rtcds/caltech/c1/scripts/LSC 6$ tdsavg 10 C1:LSC-ASDC_IN1
ERROR: LDAQ - Unable to find NDS host "fb0"
ERROR: LDAQ - Unable to find NDS host "fb1"
ERROR: LDAQ - Unable to open socket to NDS.


When this command is executed inside a script, it doesn't return anything.  eg:

set offset = `tdsavg 10 C1:LSC_ASDC_IN1`
echo $offset

returns a blank line. 

Past elog research said lots of things about test points.  I didn't suspect that, since there aren't many test points occupied (according to the CDS status screens), but I cleared the test points anyway (elog 6319).  Didn't change anything, still broken.

LSCoffsets script, and any others depending on tdsavg will not work until this is fixed.

We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

This means we can't (a) record TRY or (b) add the Q quadrature of the beat PD to the real time system tonight.

We're going to try just using Yuta's pynds script to capture data in real time, so we can keep working for tonight.

As usual, we noticed the frame builder wasn't connecting happily with the rest of the computers just as we were about to lock some stuff (we never notice it being bad when we're not trying to use the frame builder....)

All the big rectangles by each computer were white.  I restarted daqd, and that brought most things back.  c1lsc and c1sus needed their mx_streams restarted manually to get everything green again.

I've had about enough whine with my computers for tonight.

 I'm starting to feel like a wine-o here.  Yuta wanted to glance at the PRM oplev dataviewer, and lo and behold, the fb lost connection just as he decided to do that.  We had checked the front end status screen not 1 minute beforehand, and everything was green.  Lame.

Sorry about that.  I had modified the path environment that pointed to the rtcds util.  The rtcds util is now in /opt/rtcds/caltech/c1/scripts/rtcds, which is in the path.  Starting a new shell should make it available again.

 Added TRX and TRY and POY11_I_ERR and POX11_I_ERR to the c1lsc.mdl using a new-style DAQ Channels block, recompiled, installed, started the model, all good.  Restarted the daqd on the framebuilder, and everything is green.  I can go back and get recorded data using dataviewer (for the last few minutes since I started fb), so it all looks good.

Note on the new DAQ Channels block:  Put the text block (from CDS_PARTS) at the same level as the channel you want to save, and name it exactly as it is in the model.  The code-generator will add the _DQ for you.  i.e. if you define a channel "TRY_OUT_DQ" in the lsc model, you'll end up with a channel "C1:LSC-TRY_OUT_DQ_DQ".

Fcn module in CDS_PARTS is used to include a user defined function in a model.
We should be able to use this by entering desired function, but I found some bugs.

BUG1: Fcn doen't work without ";"

If you put ";" after the function, we can compile.

 sin(u[1]);

But if you put without ";", like

 sin(u[1])

you get the following error message when compiling.

controls@c1ioo ~ 0$ rtcds make c1gcv
### building c1gcv...
Cleaning c1gcv...
Done
Parsing the model c1gcv...
Done
Building EPICS sequencers...
Done
Building front-end Linux kernel module c1gcv...
echo >> target/c1gcvepics/README.making_changes
echo 'Built on date' `date` >> target/c1gcvepics/README.making_changes
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild'

make[1]: Entering directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
make -C /lib/modules/2.6.34.1/build SUBDIRS=/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv modules
make[2]: Entering directory `/usr/src/linux-2.6.34.1-cs'
  CC [M]  /opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c: In function 'feCode':
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c:615: error: expected expression before ';' token
make[3]: *** [/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv] Error 2
make[1]: *** [default] Error 2
make: *** [c1gcv] Error 1

BUG2: sindeg doesn't work properly

sindeg should work as cosine with input in degrees.
I made a simple model to test this(below).



Output of the filter module C1:ALS-BEATY_FINE_PHASE goes to "PHASE_in"
sindeg of this goes to C1:ALS-BEATY_FINE_I_ERR
cosdeg of this goes to C1:ALS-BEATY_FINE_Q_ERR

If you sweep the phase input, you should get sin and cos, but you get the following.
cosdeg (C1:ALS-BEATY_FINE_Q_ERR) looks OK, but sindeg (C1:ALS-BEATY_FINE_I_ERR) looks funny. It looks like ~20000 is its period.

...Perhaps related to the fact that Jamie is copying a lot of stuff over the network to back up Ottavia before converting her to Ubuntu, perhaps totally independent. 

After restarting the daqd, c1lsc was the only computer whose mx_stream came up on its own.  I restarted c1sus. c1ioo, c1iscey, c1iscex by hand.

ottavia has been reinstalled with Ubuntu 10.04 LTS, and has been configured as a CDS workstation.

I have been maintaining a script that takes a stock 10.04 install and configures it as a workstation.  I've attached it here, but it lives at:

/users/controls/workstation-setup.sh

The script is designed to be idempotent, i.e. it can be run on a machine that has already been configured and it will either have no affect or update.

I tried to restart c1ioo becuase I can't live without him.

I couldn't ssh or ping c1ioo, so I did hardware reboot.
c1ioo came back, but now ADC/DAC stats are all red.

c1ioo was OK until 3am when I left the control room last night. I don't know what happened, but StripTool from zita tells me that MC lock went off at around 4pm.

 c1ioo was still all red on the CDS status screen, so I tried a couple of things.

mxstreamrestart (which aliases on the front ends to sudo /etc/init.d/mx_stream restart) didn't help

sudo shutdown -r now didn't change anything either....c1ioo came back with red everywhere and 0x2bad on the IOP

eventually doing as Jamie did for c1sus in elog 6742, rtcds stop all, then rtcds start all fixed everything.  Interestingly, when I tried rtcds start iop, I got the error
Cannot start/stop model 'iop' on host c1ioo, so I just tried rtcds start all, and that worked fine....started with c1x03, then c1ioo, then c1gcv.

 LSCoffsets is working again. 

tdsavg (now, but didn't used to) needs "LIGONDSIP=fb" to be specified.  Jamie just put this in the global environment, so tdsavg should just work like normal again.

Also, the rest of the LSCoffsets script (really the subcommand offset2) was tsch syntax, so I created offset3 which is bash syntax.

Now we can use LSCoffsets again.

There seems to be a problem with how models are coming up on boot since the upgrade.  I think the IOP isn't coming up correctly for some reason, which is then preventing the rest of the models from starting since they depend on the IOP.

The simple way to fix this is to run the following:

ssh c1ioo
rtcds restart all

The "restart" command does the smart thing, by stopping all the models in the correct order (IOP last) and then restarting them also in the correct order (IOP first).

After plenty of work, NDS2 can now be used to get site data within MATLAB using the following machines:

• allegra
• megatron
• ottavia
• pianosa
• rosalba
• rossa

What I did

NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it

/users/zach $ tar -xvf nds2-client-0.9.1.tar

/users/zach $ cd nds2-client-0.9.1

/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab

/users/zach $ sudo make

/users/zach $ sudo make install

Even with the new version, it still didn't work.

Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:

$ sudo aptitude install lscsoft-auth

This group installs both the SASL protocol and the package python-kerberos

I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.

Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:

>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a

>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b

>> savepath

Now everything works fine on all these machines. As in Rana's original post, you get data in the following way:

$ kinit albert.einstein %then enter password

$ matlab -nosplash -nodesktop

>> d = NDS2_GetData({'H1:LSC-NPTRX_OUT16.mean'},963968415,6000,'nds.ligo.caltech.edu:31200')

d = 

            name: 'H1:LSC-NPTRX_OUT16.mean' 

            chan_type: 'm-trend'             

            rate: 0.0167       

            data_type: 'real_8'     

            signal_gain: 1   

            signal_offset: 0     

            signal_slope: 1     

            signal_units: ''   

            start_gps_sec: 963968415     

            duration_sec: 6000             

            data: [100x1 double]           

            exists: 1

>> quit % since you've seen that the data is really here

$ kdestroy % so that no one uses your credentials

Some thoughts

• I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/
• It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice.

No no, this is totally unnecessary.  NDS2 was already installed on every machine from the official packaged releases (apt-get install nds2-client), and it's known to work fine. We use it with pynds all the time. If the matlab component is not working we should figure out the right way to fix it with the existing packages.

In general, please only manually install software as a very last resort.  Manually installed software doesn't get maintained, where as the officially packaged stuff is being actively maintained by the collaboration. If there is a problem with the distributed packaging we should report it and get it fixed (and hint I was the one who built the original Debian packaging for nds2, so I know how to fix all the issues).  I'm trying to bring the 40m out of the dark days of complete chaos, where random software was installed in random locations.

That's because this wasn't the problem!

This sounds like it's more likely the issues. You did the right thing by going to apt to fix the authentication packages.  It's curious to me that you did that here, whereas you went totally out of band for the nds2 client stuff.  Why?

The matlab mex files are the other problem.  But there is also a nds2-client-matlab Debian/Ubuntu package for that as well.  The problem is that the package just distributes the source, and it needs to be compiled.  I'll help figure out a good way to do that.

Again, this is handled by the packaging!  Just use apt and the right architecture is installed automatically.

But what 32 bit machines are you referring to?  I think basically everything is 64 bit nowadays.

We are now using lalapps_tconvert for tconvert.  We're not using that ligotools crap anymore.  I've aliased that to tconvert on the command line, but maybe matlab isn't getting the message.  I'll try to think of a more robust solution (e.g. make a wrapper script).

From my conversations with JZ and Leo, it seemed there was no package that generated the appropriate mex files. It was clear that the right ones weren't there from the absence of a /cvs/cds/caltech/apps/linux64/lib/matlab2010b directory. I'm sorry if I screwed anything up with pynds, but I have repeatedly asked for help with NDS2+matlab and no one has done anything.

It would be nice to do it via apt if there indeed is a versioned package that can make the mexs. Sorry again if I jumped the gun, but I didn't think anyone was going to do anything.

I guess the only 32-bit machine I can think of is mafalda.

About tconvert, I think the best solution is to make a new wrapper M-file. gps was just a convenient remnant of mDV, but all that we need is some matlab function that can output a GPS time given a date/time string. We can use whatever command-line utility you want.

I was trying to use a new BLRMs c-code block that the seismic people developed, instead of Mirko's more clunky version, but putting this in crashed c1sus.

I reverted to a known good c1pem.mdl, and Jamie and I did a reboot, but c1sus is still funny - none of the models are actually running. 

rtcds restart all - all the models are happy again, c1sus is fine.

But, we still need to figure out what was wrong with the c-code block.

Also, the BLRMS channels are listed in a Daq Channels block inside of the (new) library part, so they're all saved with the new CDS system which became effective as of the upgrade.  (I made the Mirko copy-paste BLRMS into a library part, including a DAQ channels block before trying the c-code.  This is the known-working version to which I reverted, and we are currently running.)

 The reason I started looking at BLRMS and c1sus today was that the BLRMS striptool was totally wacky.  I finally figured out that the pemepics hadn't been burt restored, so none of the channels were being filtered.  It's all better now, and will be even better soon when Masha finishes updating the filters (she'll make her own elog later)

Why do we have these timing blanks?

There is a package that provides the mex source, but it doesn't actually provide the mex binaries.  The problem is that the binary depends on the matlab version, so you can't possibly provide binaries for every version.

The solution is to just build the binaries from the source package.  We should put together a nice script that builds the binaries from the source, and installs them in the directory of your choosing.  If we get something nice working, we can probably get them to include it with the package, to make it easier in the future.

Here's what's included in the source package:

controls@pianosa:~ 0$ sudo apt-get install nds2-client-matlab
...
controls@pianosa:~ 0$ dpkg -L nds2-client-matlab | sort
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/nds2-client-matlab
/usr/share/doc/nds2-client-matlab/changelog.Debian.gz
/usr/share/doc/nds2-client-matlab/changelog.gz
/usr/share/doc/nds2-client-matlab/copyright
/usr/share/matlab
/usr/share/matlab/NDS2_GetChannels.m
/usr/share/matlab/NDS2_GetData.m
/usr/share/matlab/NDS_GetChannels.m
/usr/share/matlab/NDS_GetData.m
/usr/share/matlab/NDS_GetMinuteTrend.m
/usr/share/matlab/NDS_GetSecondTrend.m
/usr/share/matlab/src
/usr/share/matlab/src/NDS2_GetChannels.c
/usr/share/matlab/src/NDS2_GetData.c
/usr/share/matlab/src/NDS_GetChannels.c
/usr/share/matlab/src/NDS_GetData.c
/usr/share/matlab/src/nds_mex_utils.c
/usr/share/matlab/src/nds_mex_utils.h
controls@pianosa:~ 0$ 

The c1oaf model hasn't been running for a few days (since the leap second problems we were having last week).  I had looked into it, but finally figured it out (with Jamie's help) today. 

The BURT restore has to be given to the model during startup, but for whatever reason it wasn't BURT restoring until *after* the model had already failed to start.  The symptoms were:  no 'heartbeat' for the oaf model, no connection to the fb, NO SYNC on the GDS screen, 0x4000.  the BURT restore button was green, which threw me off the scent, but that's just because it did, in fact, get set, just way too late.

I ended up looking in the dmesg of the lsc computer, and the last set of stuff was several lines of "[3354303.626446] c1oaf: Epics burt restore is 0".  Nothing else was written after that.  Jamie pointed out that this meant the BURT restore wasn't getting sent before the model unloaded itself and decided not to run.

The solution:  restart the model, and manually click the BURT restore button as soon as you're able (after everything comes back from being white).  We used to have to do this, but then there was a "fix", which apparently isn't super robust and failed for the oaf (even though it used to work just fine).  Bugzilla report submitted.

I used APTITUDE to install texlive-full on rosalba so that I could work on a paper. pdflatex was not found on pianosa, rosalba, megatron, etc. I used this command:

sudo aptitude install texlive-full

While this was installing, I read a bunch of forums which claim that its better to bypass the apt-get and use the 
TexLive installer instead so that we can use its own package updater 'tlmgr'. Otherwise, the standard Ubuntu distributions
are years out of date (e.g. doesn't have RevTex 4.1).

I'm seeing LOTS OF STUFF NOT CHECKED INTO THE SVN!!!  both modified things that haven't been updated, and things that looked like they haven't been checked in at all.

Please check in your stuff to the SVN!  We need the record!

Look through EVERYTHING that you think you might have touched, or even care about, and make sure it's checked in.

The c1lsc and c1sus screens are red in the front-end status. I restarted the frame builder, and hit the "global diag reset" button, but to no avail. Yesterday, the only thing Den and I did to c1sus was install a new c1pem model. I got rid of the changes and switched to the old one (I ran rtcds build, install, restart), but the status is still the same.

 The issue you're seeing here is stalled mx_stream processes on the front ends.  On the troublesome front ends you can log in and restart the mx_streams with the "mxstreamrestart" command.

I installed pyepics version 3 (http://cars9.uchicago.edu/software/python/pyepics3/overview.html) in ..../scripts/pylibs    .   I also added an "epics.conf" file to /etc/ld.so.conf.d/ , which points to the place in /ligo/apps/epics/base/lib/linux-x86_64/ where the DLLs live.  All .conf files in /etc/ld.so.conf.d/   get included in the path, so python should always automatically be able to use epics now, after you "import epics" in a script.

This is supposed to give us direct channel access to all epics channels, rather than using Yuta's wrapper scripts for ezca stuff.  I was going to write a tdsavg equivalent using camonitor, since it's unclear whether tds tools are being supported anymore.

However, I'm not getting it to connect to the server that serves epics, so I can't get the values of any channels.  All of the info in the link above assumes that you automatically get a connection, and I'm out of ideas right now of things to try.  Does anyone else have any ideas?

I cleaned up my directory (/users/masha) today. A lot of the files are just code that I experimented with, but the important files for training the classification neural network are in "neural_network_classification". The "EarthquakeData" subdirectory contains my entire dataset. Files of the form "GenerateRNNInput" are used to create input vector sets to the network, while files of the "*NeuralNetworkClassification* actually run the code that generates the neural network vectors for the classification code block in the c1pem model.

Also, the folder "feed_c", which can also be found in Den's directory, contains the neural network controller code we played around with.

Video Capture with the Sensoray works again. Pianosa just needed mplayer installed for it to play properly.

To capture video with the Sensoray, open the GUI (python ./demo.py), simply press "Save," enter a filename, and hit "Stop" when you wish to stop recording. If you want to change the video format, there is a dropdown menu labelled "Format." I recommend MP4 for standard video, and nv12 for RAW video.

 I also installed mplayer on rossa, so we can play the videos there.

Even though Mike won't admit it, the video stuff is all in /users/sensoray/ .  I opened the demo.py from there, and it also works.

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

For context, there's a is stand-alone cymac test system running at the 40m.  It's not hooked up to anything, except for just being on the martian network (it's not currently mounting any 40m CDS filesystems, for instance).  The machine is temporarily between the 1Y4 and 1Y5 racks.

Evan and I are starting to lock, and there is lots of new, unfortunate white stuff on several different screens.

C1:TIM-PACIFIC_STRING is gone, C1:IFO-STATE (MC state) is gone, C1:LSC-PZT..._requests are gone (all 4 of them), C1:PSL-FSS_FASTSWEEPTEST from the FSS screen is gone (although I'm not sure that that one is newly gone), lots of the WF AA lights on the LSC screen are gone.

Those are the things I find in a few minutes of not really looking around.

EDIT:  IPPOS is also gone, so I can't see how my current alignment relates to old alignments.

Solved. The power code of c1iscaux was loose.
Has anyone worked around the back side of 1Y3?

I looked into the problem. I went around the channel lists for each slow machines and found the variables are supported by c1iscaux

controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ cd /cvs/cds/caltech/target/c1iscaux
controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ grep C1:IF *
C1IFO_STATE.db:grecord(ai,"C1:IFO-STATE")

It seemed that the machine was not responding to ping. I went to 1Y3 and found the crate was off. Actually this is not correct.
The key was on but the power was off. I looked at the back and found the power code was loose from its inlet.
Once the code was pushed in and the crate was keyed, the white boxes got back online.

Just in case I burtrestored these slow channels by the snapshot at 6:07am on Sunday.

I was working around 1Y2 and 1Y3 when I wired the DAC in the c1lsc IO chassis in 1Y3 to the tip-tilt electronics in 1Y2.  I had to mess around in the back of 1Y3 to get it connected.  I obviously did not intend to touch anything else, but it's certainly possible that I did.

When Evan and I were dithering the BS and ITMY (see his elog), I noticed that c1lsc was acting weird.  the IOP was the only one with the blinky heartbeat.  The IOP was all green lights, but all the other models had red for the fb connection, as well as the rightmost indicator (I don't know what that one is for).  I logged on to c1lsc and ran 'rtcds restart all'.  The script didn't get anywhere beyond saying it was beginning to stop the 1st model (sup, the bottom one on the lsc list).  Then all of the cpus went white.  I can still ping c1lsc, but I can't ssh to it.

I'm not sure what to do here Jamie.  Heelp. 

We've been talking for a while about how we want to store data.  I'm not in love with keeping it on the elog, although I think we should always be able to reference and go back and forth between the elogs and the data.

I have made a new folder: /data    EDIT: nevermind.  I want it to be on the file system just like /users, but I don't know how to do that.  Right now the folder is just on Ottavia. Jamie will help me tomorrow.

In this folder, we will save all of the data which goes into the elog. 

I propose that we should have a common format for the names of the data files, so that we can easily find things.

My proposal is that one begins ones elog regarding the data to be saved, and submit it immediately after putting in the first ~sentence or so. One should then make a new folder inside the data folder with a title "elog#####_Anything_Else_You_Want" Then, data (which was originally saved in ones own users folder) should be copied into the /data/elog#####_AnythingElse/ folder. Also in that folder should be any Matlab scripts used to create the plots that you post in the elog.  One should then edit the elog to continue making a regular, very thorough elog, including the path to the data.  Elog should include all of the information about the measurement, state of the IFO (or whatever you were measuring), etc. 

Riju will be alpha-testing this procedure tonight.  EDIT: nevermind...see previous edit.

 After some system updates this evening, firefox can no longer handle the html input encoding for the elog.  I'm not sure what happened.  You can still use the "ELCode" or "plain" input encodings, but "HTML" won't work.  The problem seems to be firefox 17.  ottavia and rosalba were upgraded, while rossa and pianosa have not yet been.

I've installed chromium-browser (debranded chrome) on all the machines as a backup.  Hopefully the problem will clear itself up with the next update.  In the mean time I'll try to figure out what happened.

To use chromium: Appliations -> Internet -> Chromium

Koji and I figured out what the problem is.  Apparently firefox 17.0 (specifically it's user-agent string) breaks fckeditor, which is the javascript toolbox the elog uses for the wysiwyg text editor.  See https://support.mozilla.org/en-US/questions/942438.

The suspect line was in elog/fckeditor/editor/js/fckeditorcode_gecko.js.  I hacked it up so that it stopped whatever crappy conditional user agent crap it was doing.  It seems to be working now.

Edit by Koji: In order to make this change work, I needed to clear the cache of firefox from Tool/Clear Recent History menu.

I've installed the new nds2 packages on the control room machines.

These new packages include some new and improved interfaces for python, matlab, and octave that were not previously available. See the documentation in:

  /usr/share/doc/nds2-client-doc/html/index.html

for details on how to use them.  They all work something like:

  conn = nds2.connection('fb', 8088)
  chans = conn.findChannels()
  buffers = conn.fetch(t1, t2, {c1,...})
  data = buffers(1).getData()

NOTE: the new interface for python is distinct from the one provided by pynds.  The old pynds interface should continue to work, though.

To use the new matlab interface, you have to first issue the following command:

   javaaddpath('/usr/lib/java')

I'll try to figure out a way to have that included automatically.

The old Matlab mex functions (NDS*_GetData, NDS*_GetChannel, etc.) are now provided by a new and improved package.  Those should now work "out of the box".

 I've tried new nds2 Java interface in Matlab. Using findChannels method of the connection class I see only slow, DQ and trend channels. I could even download data online using iterate method. When it will be possible to do the same with fast non-DQ channels?

>> conn = nds2.connection('fb', 8088);
>> conn.iterate({'C1:LSC-XARM_OUT'})
??? Java exception occurred:
java.lang.RuntimeException: No such channel.
    at nds2.nds2JNI.connection_iterate__SWIG_0(Native Method)
    at nds2.connection.iterate(connection.java:91)

NDS2 is not designed for non DQ channels - it gets data from the frames, not through NDS1.

For getting the non-DQ stuff, I would just continue using our NDS1 compatible NDS mex files (this is what is used in mDV).

The NDS2 protocol is not for non-DQ, but the NDS2 client is capable of talking both the NDS1 and NDS2 protocols.

fb:8088 is an NDS1 server, so the client is talking NDS1 to fb.  It should therefore be capable of getting online data.

It doesn't seem to be seeing the online channels, though, so I'll work with Leo to figure out what's going on there.

The old mex functions, which like I said are now available, aren't capable of getting online data.

Leo fixed an issue with the new nds2-client packages that was preventing it from retrieving online data.  It's working now from matlab, python, and octave.

Here's an example of a dataviewer-like script in python:

#!/usr/bin/python

import sys
import nds2
from pylab import *

# channels are command line arguments
channels = sys.argv[1:]

conn = nds2.connection('fb', 8088)

fig = figure()
fig.show()
for bufs in conn.iterate(channels):
    fig.clf()
    for buf in bufs:
        plot(buf.data)
    draw()

Be Prepared

http://xkcd.com/936/

Message I get from dmesg of c1sus's IOP:

[   44.372986] c1x02: Triggered the ADC
[   68.200063] c1x02: Channel Hopping Detected on one or more ADC modules !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[   68.200064] c1x02: Check GDSTP screen ADC status bits to id affected ADC modules
[   68.200065] c1x02: Code is exiting ..............
[   68.200066] c1x02: exiting from fe_code()

Right now, c1x02's max cpu indicator reads 73,000 micro seconds.  c1x05 is 4,300usec, and c1x01 seems totally fine, except that it has the 02xbad.

c1x02 has 0xbad (not 0x2bad).  All other models on c1sus, c1ioo, c1iscex and c1iscey all have 0x2bad.

Also, no models on those computers have 'heartbeats'.

C1x02 has "NO SYNC", but all other IOPs are fine.

I've tried rebooting c1sus, restarting the daqd process on fb, all to no avail.  I can ssh / ping all of the computers, but not get the models running.  Restarting the models also doesn't help.

c1iscex's IOP dmesg:

[   38.626001] c1x01: Triggered the ADC
[   39.626001] c1x01: timeout 0 1000000
[   39.626001] c1x01: exiting from fe_code()

c1ioo's IOP has the same ADC channel hopping error as c1sus'.