Description
This morning found the telescope on the pier, it seems that the meridian flip was not triggered by SGP and/or the recovery failed (plus my fault in not setting the limit in EQMOD, I did it in the simulator but missed doing that for the real mount, that should at least avoided the crash).
Same sequence on the target A1367 worked fine previous nights. Meridian flip was due at around 5:00.
4:46: recovery mode kicks in due to guider settling time
5:02 recovery fails => select next target. Here it keeps staying on the same target (A1367), rather than aborting the sequence (as I though it should do, because A1367 is the last target)
it then keeps attempting to recover on A1367 even after meridian is passed
6:02 sequence shut down as planned with end time flag
I noted some strange event at 4:31 (telescope disconnect?), yet I am not sure if the handling of the subsequent events is fine (e…g not aborting the sequence)
thanks for the support
cheers
Luigi Link to Logs
Useful Info
OS: Microsoft Windows 10 Pro Ver: 3.1.0.431 .NET: 4.8
I am honestly not sure what is going on there. You seem to have had a partial loss of connectivity with the mount. SGPro does monitor equipment connectivity (every 10 seconds), but the mount never reported it wasn’t connected… it just stopped responding to most commands.
There does seem to be a bug in selecting the next target… I think I know what that’s from. I think the bug is literally for failure on the last target, but yes, it should have aborted the sequence.
In terms of parking, the mount failure put the mount in a state where it reported it was still connected, but also reported it was no longer capable of parking, so it was skipped. This is, of course, why external limits are important… weird stuff happens.
The issue with continually selecting the last target on recovery failure will be resolved in 3.1.0.433.
Thanks Ken,
for the benefit of other users: I am using an USB-232 Prolific cable connected to the Handset in PC direct mode. I have found reports in the web of disconnection induced by the h/s, this seems to happen rarely, but it may well be.
I am moving to a direct EQDIR cable.
cheers
Luigi
Dear Ken
After some thoughts, I would suggest to include, in the SGP aborting sequence, the option to
switch off the equipment (in this case the mount) via ASCOM switches, that are used by power boxes (eg Pegasus), at the end of the sequence. This would add a fail proof option to any failure, including disconnects from the PC/ASCOM driver to the mount.
If this happens, (as in my case), EQMOD is no longer connected to the mount, so the mount continues to track the source (in the worst case crashing on the pier) . This would have happened even if I had set the mount limits in EQMOD or SGP aborted the sequence. In addition, such an implementation would provide the option to physically switch off all equipment powered by power boxes compliant with ASCOM switches.