This is an old revision of the document!
Disk VSN: MED-0027/3200 | Data volume at beginning: 0.256 GB
I looked at two of the incidents:
1. 1919UT Antenna stuck. The log shows:
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: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?
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!