User Tools

Site Tools


handover:r1911

This is an old revision of the document!


R1911

Yarragadee 12m

Disk VSN: MED-0027/3200 | Data volume at beginning: 0.256 GB

  • 1700UT - Experiment started OK (Prad).
  • Unusually delayed response at the FS to commands entered from erc . Hence, just using the oprin window in the vnc viewer. The disk module graphic in the erc is not updating (Prad).
  • 1919UT - Antenna stuck at scan# 252-1928b. Tried 'source=disable', 'antenna=open', switching drives on and off and rebooting central in the HMI, but to no avail. The schedule restarted at scan# 252-2154b.
  • 2156UT - scan_check reports mk5 data format problem (letter E issue) for scan# 252-2154b.

Discussion

Ed Himwich, 2019/09/11 20:53

I looked at two of the incidents:

1. 1919UT Antenna stuck. The log shows:

2019.252.19:25:02.12#trakl#Source acquired 2019.252.19:25:04.16#flagr#flagr/antenna,acquired 2019.252.19:27:11.08#trakl#d-cs0/timed_out

The previous source had been acquired. The key thing is that the antenna “timed-out“. That is really odd because in your version of the ‘trakl' program, we don't enable the time-out. My best guess is that either there was a glitch or if the HMI program was running maybe there was errant click that enabled the time-out (is there a button for that?).

The status indicators for the drive status should have gone inverse video. In this situation (and other times), the 'antenna=status' command can be your friend to help determine what is wrong. The status bits are displayed as mnemonics with the ones in an abnormal state in inverse video. Normally an 'antenna=operate' command should restore operation. I can see that was tried but in this case didn't do the trick. I think that is because this version of the ‘trakl' program doesn't use the time-out feature and therefore did not reset it. As a result the only way to recover was to restart, which you did (good work!). An alternative might have been to use the HMI program to disable the time-out and then clear it. I do have a new version of ‘trakl' that does know about the time-out, which I encourage you to switch to (it has a lot of other improvements), but that is for another occasion.

2. 0947UT Antenna waiting at limit. The log shows:

2019.253.09:22:20.12#trakl#Source acquired 2019.253.09:47:05.12#trakl#Waiting at limit

It looks like what happed is that the antenna reached the new source for a scan (I don’t know why the ‘flagr’ output is missing) and then *tracked* into the limit (25 minutes later). BTW, the antenna probably did not actually reached the limit. The 'Waiting at limit’ message means that ‘trakl' is holding the antenna *just* off the limit. The problem of course is that FS stopped processing commands. It looks like this is related to the running of the script in 'checkmk5'. Dave and I think we have seen this issue before. Maybe Dave even sent a message with a suggestion for how to fix it. However, neither of can find that message. Do by any chance remember/have such a message?

Thanks, Ed

Ed Himwich, 2019/09/12 16:08

Dave points out that with eRemoteCtl tailing the log, the inverse video escape sequences won’t display properly. However, it appears you are running 9.13.0, which replaces inverse video escape sequences with parenthesizes (in the log only), so the “abnormal“ values antenna status values in the rRemoteCtl display should appear within parenthesizes. Whew!

You could leave a comment if you were logged in.
/home/www/auscope/opswiki/data/attic/handover/r1911.1568066464.txt.gz · Last modified: 2019/09/09 22:01 by Pradyumna Kiran Kummamuru