After a couple of days of struggle, I made some progress on the CDS upgrade today:
/opt/rtcds/rtscore/release -> tags/advLigoRTS-2.9.4
/opt/open-mx -> open-mx-1.5.2
We have new GDS overview screens for the front end models:
It's possible that our current lack of IRIG-B GPS distribution means that the 'TIM' status bit will always be red on the IOP models. Will consult with Rolf.
There are other new features in the front ends that I can get into later.
40m daqd compile flags:
./configure --enable-debug --disable-broadcast --without-myrinet --with-mx --enable-local-timing --with-epics=/opt/rtapps/epics/base --with-framecpp=/opt/rtapps/framecpp
install daqd /opt/rtcds/caltech/c1/target/fb/
However, daqd has unfortunately been very unstable, and I've been trying to figure out why. I originally thought it was some sort of timing issue, but now I'm not so sure.
I had to make the following changes to the daqdrc:
set gps_leaps = 820108813 914803214 1119744016;
That enumerates some list of leap seconds since some time. Not sure if that actually does anything, but I added the latest leap seconds anyway:
This updates the silly, arbitrary GPS offset, that is required to be correct when not using external GPS reference.
Finally, the last thing I did that finally got it running stably was to turn off all trend frame writing:
# start trender;
# start trend-frame-saver;
# sync trend-frame-saver;
# start minute-trend-frame-saver;
# sync minute-trend-frame-saver;
# start raw_minute_trend_saver;
For whatever reason, it's the trend frame writing that that was causing things daqd to fall over after a short amount of time. I'll continue investigating tomorrow.
We still have a lot of cleanup burt restores, testing, etc. to do, but we're getting there.