User Tools
Sidebar
handover:r1911
This wiki is not maintained! Do not use this when setting up AuScope experiments!
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. The schedule restarted at scan# 252-2154b after attempting the reboot multiple times. (Prad).
- 2156UT - scan_check reports mk5 data format problem (letter E issue) for scan# 252-2154b. Will require a module swap if the issue persists (Prad).
- erc displaying wrong DOY and UT.
- 04:52 UT recorded data ahead of scheduled by 112 GB (warren)
- 09:47 UT Waiting at limit for several scans. Field system had forced antenna to limit and would not take new source commands. Restarted the field system and schedule at scan 253-1025a. Scans 253-0953 through 253-1019 not on target (Ross)
/home/www/auscope/opswiki/data/pages/handover/r1911.txt · Last modified: 2019/09/10 10:19 by Pradyumna Kiran Kummamuru
Discussion
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
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!