Yuta reported many of the signals being displayed by dataviewer "fuzzier" than normal. And diaggui was not working.
Running "diag -i" reported:
awg 21 0 192.168.113.85 822095893 1 192.168.113.85
awg 36 0 192.168.113.85 822095908 1 192.168.113.85
awg 37 0 192.168.113.85 822095909 1 192.168.113.85
tp 21 0 192.168.113.85 822091797 1 192.168.113.85
tp 36 0 192.168.113.85 822091812 1 192.168.113.85
tp 37 0 192.168.113.85 822091813 1 192.168.113.85
This seems to be missing an nds type line between the 3 awgs and the 3 tp lines.
The daqd code (the framebuilder) is being especially flaky today, and I'm starting to see new errors.
[Thu Oct 28 16:13:46 2010] Couldn't open full trend frame file
What was done today that might have affected it:
A new c1ioo chassis from Downs was connected to c1ioo. I also connected c1ioo to the DAQ network (192.168.114.xxx) which talks to the frame builder.
I started downloading the necessary files to be able to follow Keith's instructions for a standard control / teststand setup in /opt/apps , /opt/rtapps, etc. However, it has not actually been installed yet.
Yuta added additional OL channels to the DAQ config for being recorded.
I reverted the inittab changes I made in this elog. Didn't help.
I disconnected c1ioo from the DAQ network. Didn't help.
Rebooted the frame builder machine. Didn't help.
I've sent an e-mail to Alex describing the problem to see if he has any idea where we went wrong.
Yuta may try restoring the old DAQ channel choices and see if that makes a difference.
daqd framebuilder code still won't stay up. So no channels at the moment.