Open noralinn opened 6 months ago
Mount 8 is known to be disturbed in communication by EMI, caused by the motors when tracking, much more than other mounts. I think I had an estimate of 1 corrupted command every 100, or something like that. This is why we switched to the Copley communication protocol with checksums, and implement retries. The messages of the first kind thus are to be intended as warnings, but prove that things succeeded when retried.
The verbose list of messages below is typical of trying to communicate with an offline controller. I could guess, that unless a Unit.Mount.disconnect
was deliberately issued, the problem could be that the usb-232 dongle went fishing (typical of EMI as well). Only, I'm not sure, but probably on last08e we are usinga PCI serial card for that reason - I'll check.
Yes, M8 is connected to the card serial port. Maybe also these cards join the fishing party, differently than what I assumed.
In such cases I could suggest to try Unit.Mount.connect
again, maybe from what is reported we could get a bit of hint.
Simone reported similar issues, with Unit.Mount.Reset
not reconnecting and dumping lots of reports about failed queries like in the above. Looking at his matlab session though, there seems to be more going on, like slaves in parallel querying mount position and failing, because there are Messenger complaints when he tried to abort with Ctrl-C
Throughout the night, there were many errors that were remediated automatically. (Every few minutes.)
Examples:
But in the end, while slewing with Unit.Mount.goTo, the mount became completely unreachable (see below). I've had this issue before, it seems to happen once every few nights.
I only called Unit.shutdown afterwards. Parking probably didn't work, I asked observers to check to mount position in the morning.