Meridian Flip failure

Sequence Generator
1

Last night, I had a meridian flip that appeared to work, but the flip failed and the sequence was aborted. I saw the meridian flip happen and it appeared as though the scope was pointed in the right spot. Attached is a log indicating the communication with the mount had failed. I’m not sure what that meant since it received the park command just fine after aborting the sequence. I’m using the latest PHD2 (2.6.2) and SGP (2.5.1.17).

Any help would be greatly appreciated!

sg_logfile_20160910200008.txt.zip (85.3 KB)

2

I have noticed in the v2.5.2.1 release notes that this bug fix was implemented:
Bug fix: Fixed an issue where centering (and meridian flips) might hang SGPro and report that the camera has timed out.

I wonder if this is related to my issue. It seems the pier flip occurred, but PHD was stopped? I’m having a hard time reading these logs and deciding what’s normal and what’s not. Here’s the snippet around where everything went south:

[9/11/2016 3:20:49 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Procedure complete
[9/11/2016 3:21:00 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[9/11/2016 3:21:00 AM] [DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[9/11/2016 3:21:00 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[9/11/2016 3:21:00 AM] [DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[9/11/2016 3:21:00 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[9/11/2016 3:21:51 AM] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (True)
[9/11/2016 3:21:51 AM] [DEBUG] [Sequence Thread] Adding sequence level notification: Failed to meridian flip, aborting sequence.

There’s also a bunch of entries for lost communications with mount:
[9/11/2016 3:20:40 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetCurrentPos : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.
— End of inner exception stack trace —
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 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Telescope.get_RightAscension() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 769
at fp.f0(Boolean A_0)

and…

[9/11/2016 3:20:32 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetLst : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.
— End of inner exception stack trace —
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 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Telescope.get_SiderealTime() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 910
at fp.f4()

1 Like
3

It is not related. I can’t explain what went wrong, but your description of the issue makes it seem like the physical bahvior of the flip caused some issue where cable became loose or stretched.

4

Thanks Ken for the reply. I was thinking the same, but the fact the parking command was executed makes me wonder. We’ll see how it goes tonight with another meridian flip.

Gabe

5

Had another issue last night during the meridian flip. It’s odd since the flip occurs, but doesn’t seem to recover after the flip. This time, it appeared to stall during plate solving, so I dismissed that in favor of the blind solve. Once that was finished, the sequence was aborted for some reason.

I thought that what might be causing issues would be the APCC meridian limits, but I’ve verified that none are enabled. Do people use the meridian limits with success in combination w/ SGP? There’s an option to stop tracking once the limit has been reached, but I’d think that would be fighting the guiding and SGP session unless there’s some sort of communication of when the meridian limit will be reached to SGP.

Anyway, this is the second night in a row that I’ve had a meridian flip failure. I’ve verified that all my cables are securely plugged in and there’s no snagging or pulling of the cables. I’m at a loss for the cause if it isn’t a bug in SGP or APCC.

sg_logfile_20160911193610.txt.zip (56.3 KB)

6

Hi Gabe,

I have used SGP 2.5.1.17 with a slightly older PHD2 (phd2-2.6.1dev11 but I have not yet tried 2.6.2) with my A-P1100GTO and never once had a Meridian Flip issue. Every single SGP Sequence with Meridian Flip enabled, it has worked perfectly. The only difference is I don’t have APCC.

Peter (AKA Peter in Reno from CN)

7

Gabe you realize you can practice meridian flips during the day right? Just turn of guiding and plate solving, slew to a star near the meridian during the day and tell SGP to perform a flip.

It’ll work, or it won’t.

8

Thanks guys for the responses. Good to hear that you don’t have this issue Peter. That suggests it might be something boneheaded I’m doing. I’ll revisit

I didn’t know you could force the meridian flip. I’ve only had SGP for the past 9 months or so and have never needed to force a flip. That will make debugging the issue faster for me. Thanks for the suggestion!

I’ll write back with what I find.

Gabe

1 Like
9

It was huge for me when I figured that out. I’m so sorry I didn’t mention it before now :weary:.

Hopefully you can find the problem. That was a frustrating couple of weeks for me.

10

Gabe,

I am not sure what you mean by force a Meridian Flip. It all depends on your SGP’s Meridian Flip settings. In my case, if I am imaging an DSO located at Southern Sky south of Zenith, I do not allow SGP to force a Meridian Flip because I know my A-P1100GTO mount will continue to image past the Meridian without the scope colliding with the pier. This really depends on your latitude.

But if you know that there’s a possibility that the scope could collide with the pier depending on where DSO is located (typically north of Zenith if you live in North Hemisphere), I simply enable Meridian Flip in SGP set to perform Meridian Flip 4 minutes past the Meridian and it’s always pretty successful. When the mount crosses the Meridian and it’s already at or at least 4 minutes (equivalent of 1 degree) past the Meridian, all SGP does is resend the same DSO’s coordinates to the mount and the mount will automatically perform Meridian Flip. There is no such a thing as sending a command to perform “Meridian Flip”.

Peter

11

Peter,

You can tell SGP to run its meridian flip manually. I used the term ‘force’ to imply a user directed flip.

12

@AstroGabe

Sorry you are having issues with this. Unfortunately the bottom line is that there is nothing SGPro can do when it receives an error like this:

[9/12/2016 1:37:48 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetCurrentPos : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.

This is an absolute dead end in the eyes of SGPro. I would recommend getting a hold of your mount’s logs to see its state at the time it first reported loss of communication and then bringing it up with the driver’s author.

13

@Ken,@AstroGabe:

Looking at the log there seems to be lots of unexplained “Lost communications” messages. The driver will report “Lost communications with mount” if there are 3 consecutive timeouts, but the driver will recover afterwards if the mount starts responding.

However, it’s not hard to tell that the mount probably did not “flip” because it seemed to complete in just 4-5 seconds, assuming the log details are accurate here:

[9/12/2016 1:37:43 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[9/12/2016 1:37:44 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[9/12/2016 1:37:44 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using slew
[9/12/2016 1:37:44 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 0.0571327092940147 (00h03m25.68s) Dec: 67.1593931918044 (67°09’33.82")
[9/12/2016 1:37:44 AM] [DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[9/12/2016 1:37:44 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 0.0728055555555556 Dec: 67.2516666666667
[9/12/2016 1:37:48 AM] [DEBUG] [Telescope Thread] Scope reports it is done with synchronous slew, verifying…
[9/12/2016 1:37:48 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetCurrentPos : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.
— End of inner exception stack trace —
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 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Telescope.get_RightAscension() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 769
at fp.f0(Boolean A_0)

@Astrogabe, you probably should send your driver/apcc logs to AP and copy me @ groups3 at gralak dot com. I’m not sure if I will be able to get to them in a timely manner but maybe Howard or George at A-P will have some time.

-Ray Gralak

1 Like
14

Thanks all for the help. It’s much appreciated. I’ll send the APCC logs along to that address Ray.

Thanks!

15

@AstroGabe:

You should use APCC’s file zipper function in the tools menu to create a zip file with all the logs. If the zip file is too large to email then you may need to send it via a public google docs or dropbox link.

-Ray

16

Logs have been sent. Thanks Ray

17

I got them, thanks. I’ll be able to look at them tonight.

-Ray

18

@AstroGabe:

I have had a look at the driver and APCC logs and there seems to be some very odd pauses in responses from APCC. The responses are currently handled by the user interface thread, but background polling and incoming commands are handled by background threads. Background polling and received commands were expediently handled by APCC during the “response pauses”, so APCC as a whole was still running. However, if the UI thread was hung up doing something this would likely cause the timeouts that are seen in your driver log file.

The solution I intend to pursue is to move the responses into a background thread, but that will be a bit of work. However, I would still like to find out what might be causing this. For instance, do you think you might have had the 3D Telescope view window open at this time? That particular window can take a lot of CPU time if the graphics card in your computer is not very powerful. Were there any other applications on your computer running at that time possibly doing a lot of graphical or CPU work? (BTW, what are the specs on your computer?)

That said, looking at the logs the mount did actually “flip”, but SGPro could not read status from the driver because APCC’s replies were stalled. Later, APCC sent out all the replies, causing the driver to clear it’s buffers and resync communications. Then APCC and the driver were in sync again.

-Ray

1 Like
19

Hi Ray,
Thanks for the reply. I appreciate you looking through the logs to try and track down what has happened.

I had a run last night and had another meridian flip failure, but this time it was a slew to a new object on the other side of the meridian, rather than to the same object. I was viewing the SGP screen during this time and noticed something peculiar that is shown in the logs and was noticed by you. The meridian flip slew is reported to have taken 4-5 seconds, but this is not possible since I’m slewing at 600x to keep the noise down. I looked at what SGP was doing and noticed that it was taking an image for plate solving while it was slewing. It seems somehow, there’s a command of a completed slew being sent too early that may be a result of your findings. In the meantime, I suppose I could put in a settling time of 30 seconds or so as a quick fix. I’ll try that next time I’m out.

I’m running on a Quantum Access PC stick and have it headless. I VNC into the PC to check its status sometimes. The problem doesn’t matter if I have a VNC session active or not - I viewed it live last night and the other times just after the flip. I’ve been running it successfully for the past 9 months or so with SGP and with APCC since around June. I only have SGP, APCC and PHD2 running and no other background applications loaded. This PC stick is solely for astroimaging and like to keep it lightweight.

Here’s the latest log. The trouble starts around 12:51:15.
sg_logfile_20160914161645.txt.zip (97.5 KB)

Here’s a snippet:
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] DoEventGroupChange: Slewing to target
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] Handling monitoring event (Good Night System, Status): (Sept2016-TMB130) Slewing to target “ngc7380”…
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] GNS: Sent status message to GNS ((Sept2016-TMB130) Slewing to target “ngc7380”…)…
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] Telescope: Slewing to J2000 RA: 22.7830305555556 (22h46m58.91s) Dec: 58.0696861111111 (58°04’10.87")
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[9/15/2016 12:51:15 AM] [DEBUG] [Sequence Thread] Telescope: Slewing to JNOW RA: 22.795000914191 Dec: 58.1602528824476
[9/15/2016 12:51:20 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetLst : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.
— End of inner exception stack trace —
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 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Telescope.get_SiderealTime() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 910
at fp.f4()
[9/15/2016 12:51:20 AM] [DEBUG] [Sequence Thread] Scope reports it is done with synchronous slew, verifying…
[9/15/2016 12:51:20 AM] [DEBUG] [Sequence Thread] Telescope: Slewing has completed

20

Oh, and I didn’t use the 3D scope viewer at any of the times where this problem came up.

Thanks again!

Gabe