Have a read of this How to report issues or ask for help
Thank you for your help. I have placed my log files for May in Dropbox. Here’s a link.
It is likely that APT is just not checking the connected state and therefore unlikely to expose something like this. We are checking the connected status fairly frequently. The check is pretty minimal, we’re literally just asking the ASCOM driver “IsConnected?” and it is returning “False”. For the most part APT’s interaction with the telescope is pretty limited. You’d probably get a better idea of things using something like Stellarium which is frequently polling the telescope.
Thank you, that makes some sense. I haven’t really looked at the log files before. When is a new log file created? If I know the rules I can really try and target it down next time I get a failure.
Is there anyway in SGPro I can influence the connection check behaviour (i.e to try and fix it) by changing retries, timeout or baud rate.
Really appreciate your help, I’m desperate to keep running SGP !
You mention Stellarium. Haven’t done that yet, and will try, but for your information Cartes De Ciel doesn’t disconnect either. Is that similar to Stellarium?
OK Jared, I just had a failure… THIS IS IN MY DROPBOX FOLDER as BAD_ONExxxxx.log
I got this in the log…
[05/20/20 22:25:20.492][DEBUG][TEC Thread][NONE] SGM_CHANGE_COOLER_TEMP complete…
[05/20/20 22:26:46.684][DEBUG][Telescope Thread][NONE] Telescope Dispatch loop: Received SGM_TELESCOPE_CONNECT…
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] Failed to connect to telescope. : Object reference not set to an instance of an object.
at ASCOM.DriverAccess.MemberFactory.SetTargetInvocationExceptionHandler(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 636
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 373
at ASCOM.DriverAccess.AscomDriver.set_Connected(Boolean value) in C:\ASCOM Build\Export\ASCOM.DriverAccess\AscomDriver.cs:line 144
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] SGM_TELESCOPE_CONNECT complete…
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] Telescope thread is IDLE…
[05/20/20 22:26:57.087][DEBUG][CP Update Thread][NONE] Error in control panel UI updater: Object reference not set to an instance of an object.
[05/20/20 22:27:07.166][DEBUG][CP Update Thread][NONE] Error in control panel UI updater: Object reference not set to an instance of an object.
Later on I had another similar failure. This is the dropbox folder as BAD TWO xxxx.log.
It looks to me like an unhandled exception. If you want me to do any specific tests, or run any special diagnostic code, I’d be very happy to do so, I used to be a software developer…
[05/21/20 01:35:08.959][DEBUG][Telescope Thread][NONE] Telescope Dispatch loop: Received SGM_TELESCOPE_CONNECT…
[05/21/20 01:35:13.892][DEBUG][Telescope Thread][NONE] Failed to connect to telescope. : The callee (server [not server application]) is not available and disappeared; all connections are invalid. The call may have executed. (Exception from HRESULT: 0x80010007 (RPC_E_SERVER_DIED))
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object args, Boolean byrefModifiers, Int32 culture, String namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object providedArgs, ParameterModifier modifiers, CultureInfo culture, String namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 266
at ASCOM.DriverAccess.AscomDriver.get_Connected() in C:\ASCOM Build\Export\ASCOM.DriverAccess\AscomDriver.cs:line 131
[05/21/20 01:35:13.892][DEBUG][Telescope Thread][NONE] SGM_TELESCOPE_CONNECT complete…
Whoops, I thought I had included the link.
Here are the links to the two files, in order…
Sadly I don’t have a great answer for you. It seems the possible solutions are:
1 - SGP stops checking if the devices are connected.
2 - Stop the device from stating it is disconnected (when maybe it’s not?)
Do you happen to have an ASCOM log from the telescope that corresponds to one of those SGP logs?
Appreciate your help Jared. I’m not sure, I’ll have a look into it, and if I haven’t I’ll and create one and come back to you…
Jared, if it takes me a few days to do that, shall I post in this thread, or would I need to start a new one?
This one is fine.
Did more testing… In EQMOD log…
13:28:38.090 RX =1C0501
13:28:38.090 TX :s2
13:28:38.106 RX =1C0501
13:28:38.106 TX :V200
13:28:38.122 RX =
13:28:38.122 TX :q1010000
13:28:38.138 RX !0
I’m guessing the !0 MEANS NOTHING CONNECTED
IN SGPRO LOG…
[05/24/20 14:21:39.025][DEBUG][MF Update Thread][SQ;CC;] Performing serialize…
[05/24/20 14:28:38.270][DEBUG][Equipment Connectivity Thread][SQ;CC;] SGPro thinks the telescope is connected, but it’s not, syncing UI…
[05/24/20 14:28:38.271][DEBUG][Main Thread][SQ;CC;] Adding sequence level notification: External disconnect of telescope detected…
[05/24/20 14:28:38.325][DEBUG][Equipment Connectivity Thread][SQ;CC;] Sending Notification: Warning - External disconnect of telescope detected…
[05/24/20 14:28:38.328][DEBUG][Main Thread][SQ;CC;] Disconnecting ASCOM Telescope: EQMOD.Telescope
The two logs are in Dropbox…
I’m not sure if those logs match up or not. But they seem to be an hour off (maybe DST error?). Regardless something does seem up a little higher in the log:
13:28:36.817 TX :j2 13:28:36.829 RX TIMEOUT! 13:28:37.036 TX 13:28:37.036 TX 13:28:37.239 TX 13:28:37.239 TX 13:28:37.443 TX 13:28:37.443 TX 13:28:37.646 TX 13:28:37.646 TX 13:28:37.849 TX 13:28:37.849 TX 13:28:37.964 TX :e1
That RX timeout certainly seems suspect. Maybe a USB or driver problem? I’m not sure. But it seems that the driver is dropping communication with the mount occasionally.
Really appreciate you sticking at this
I’m not sure of all of the software layers involved here.
1)Does SGPro talk to Ascom, which then talks to the mount? … and that this timeut is the Ascom driver not getting a response from the mount.
I did try on a completely seperate computer and got the same disconnect issue. I also tried swapping the USB PC to mount lead, again to no avail.
2)Is that then implying that it could be the mount itself? The mount was damaged, but the electronics were changed twice, and I had he same problem after each repair. I DID NOT have the problem before the mount blew up though. I’m going to try and borrow another ascom mount to see if that has the issue. Won’t be an HEQ5 though.
Nightmare this, thanks for your patience…
The layers look like this:
SGP <==> ASCOM Telescope Driver <==>
Telescope Driver <==> Telescope
I think SGP is self explanitory
- ASCOM Telescope Driver sits on top of the telescope and makes your telescope “look like” other telescopes to SGP. It makes it so we don’t have to have a separate implementation for each telescope.
- Telescope Driver is what ASCOM uses to talk to the actual hardware. For most telescopes this is not really a “driver” per say but just a serial connection, thus it is crossed out.
- Telescope - the actual telescope hardware… your mount.
The log you attached is a record of communications between the mount’s ASCOM driver and your Mount. So the communication was dropped/timed out at that point. Some ASCOM logs also show the SGP side (where we’re asking it for things and what those values returned) but I don’t see it in that log.
Maybe? It’s somewhere between ASCOM and your mount. This could also be a cable or a USB->Serial adapter. Or if you’re using a USB extension those are also highly suspect. I would try changing out the Serial Adapter as well as any usb cables and even trying another dedicated USB port on your machine just to rule out everything…and then if you still have issues try borrowing a mount.
Ive started having the same issue, only started a few weeks ago I think I did an upgrade to the latest version but also changed guide cam and to a proper Lynx astro Eqmod cable. Carted Du Ciel does not see a drop in connection and guiding continues fine, with no PHD2 error messages about it not being able to send guide commands but SGPro drops the connection to the mount. For the reason that PHD Can continue to guide, I suspect its an SGPro issue since PHD is constantly issues guide commands and it will throw an error if the mount is disconnected
I have tried replacing all hardware elements, and even tried on a different computer. I have also uninstalled Ascom and drivers, and SGPro and re-installed. Still have the problem.
Hi BLINKY. Interesting. Same issue has appeared recently on my local forum too.
# HELP! Please. HEQ5 erratic behaviour.
Full details at…
But in essence it’s the same issue. Random disconnection from SGPro with an HEQ5 mount. Whilst the discussion continues in a hardware related way, it sound exactly like what we have both seen. And feels more software related if other programs don’t disconnect.