This post is to capture insights from the community in case any other user encounters issues between ASCOM parts & Starry Night to help support an open request ticket to help SimC improve the interface with the ASCOM drivers.
In my case, StarryNight Pro Plus 7 (running on the most current windows 10) does not gracefully handle some occasional failure in the "ASCOM Celestron Mount Server"
My SN to AVX mount connection can be stable for over 24 hours continuously.
Hopefully insights from other users can help the developers/code writer who maintains the SN interface with ASCOM tools implement code that protects StarryNight from crashing due to a crash in third party driver(s).
In my case, the occasional fatal problem appears to be when there is a communication error that confuses the "ASCOM Celestron Mount Server" which ASCOM does not handle gracefully, proceeds to an ASCOM crash which then propagates to StarryNight and crashes all of StarryNIght.
Here is an album of screenshots showing the cascading set of failures which seems related to an initial communication failure that crashes the "ASCOM Celestron Mount Server"::
If I just unplug the USB cable, while everything is connected and working...no problem...ASCOM simply sees the port as closed so I just need to plug back in the usb cable going to the AVX mount & close/re-open the Telescope panel & reconnect....StarryNight does _not_ crash & I can continue observing with no/minimal disruption.
My requested objective is to have StarryNight gracefully handle a third party driver crash no matter the source of the driver error...
since errors in any setup can be setup specific...e.g. the "ASCOM Celestron Mount Server", power requirements of the interface with the Advanced VX NexStar+ hand control which can be affected by the quality & length of the usb cable used, power spikes or other disruptions caused by slight movement in cable connections due to temperature changes or touching the handset or bumping parts in the dark, manufacturing variability, or something in the windows environment that over time triggers a crash in some part of the ASCOM drivers....i.e. tons of things that can go wrong that Sim C can do nothing about other than protect StarryNight from crashing when something like this occurs.
This will help when in the middle of a detailed planned observing session where restoring the detailed session windows takes >5 minutes which presents problems for time sensitive viewing such as occultations, transits, satellites, objects close to horizon, etc..
SimC has not yet indicated if there is a specific version or series of versions of ASCOM driver(s) with which SN is specifically built to interface. For example, p.104 of the SN manual does not indicate if the SN installer just pulls the most recent ASCOM version or if there is a specific one for use with SN.
The driver I am currently using is visible in the results from the ASCOM diagnostic tool which are in the folders at this google drive link:
(I continue to tinker with different cables etc since my best guess at the moment in my case is that the source of the crash is hardware connection related.)
Kind regards, Chadwick