Total Failures on Second Object

Version Notes - I am using SGP Version 2.5.1.17 and SGP 2.6.1 on Windows 10 Professional x64.

For the past few days, I have been photographing two objects per night - I start one at about 9:15pm and go to bed, and it switches to the second object between 11:45 and midnight. It is worth noting that, two nights ago (so the 5th), I upgraded to the latest version (2.5.1.17) because the version I was already using kept crashing on launch. It is that same night (and last night) where I lost about 4 1/2 hours of imaging each night due to a complete failure.

In both instances, imaging of the first object worked just fine. I can tell that the telescope slewed to the second object (based on its position in the morning when I get up), but it never started imaging. This morning, on the screen was a plate solve frame that had short lines instead of stars - that tells me that plate solving never completed due to tracking. But when I look at the logs, it seems to be a PHD2 error, so I am really confused.

Also, the “star lines” were a quite a bit longer than I would expect for a five-second exposure plate solve frame - my tracking is good enough that five-second exposures should be solvable.

Also different between the two nights were the fact that I changed what object number two was, and since the two objects last night were almost identical on declination, I turned the “force PHD to recalibrate” option off.

On the first of the two nights, I am pretty sure that recovery mode was off. However, last night I double checked and made sure it was on before I went to bed.

My log files are available at: http://www.scodavis.com/temp/sgplogs.zip

I would appreciate any guidance you can give me. If we can’t figure out I do plan to get up and babysit it as it goes to the second object, but I would rather not do this as it defeats the purpose of having an automated system. :slight_smile:

Thank you!

I can 2nd this issue and perhaps add a little information.

I’ve seen this also starting a couple of weeks ago. The Auto Center plate solve
fails when SGP moves to the 2nd target. I started some debugging, but
then our monsoons started in earnest and I have not been able to continue.

From what I saw, the target centering plate solve times out waiting for
an image from the camera. The image actually completed in the normal
amount of time and was displayed on the screen way before the plate
solve gives up. As the scodavis noted, SGP seems to run normally for
the first target and then fail on the 2nd.

Log is here:
http://www.kor-astro.net/SGP_Support/SGP_5/sg_logfile_20160728205426.txt

  • Plate solve initiated around 11:48:23 PM
  • Image completed and displayed around 11:48:34 PM
  • Auto Center aborted around 11:52:26

And a screen shot showing that the image actually did download is here:
screenshot

  • OS: Win 7 Home Premium SP1
  • SGP Version: 2.5.1.17
  • PHD2 Version: 2.6.1dev11

When I started debugging, I opened the sequence again and did a Center
on Target. This failed with the image displayed and the timeout a few
minutes later. I then pulled up the plate solve tool and tried it. It
worked correctly. Back to the Center on Target and it failed. Back to
plate solve tool and it worked. Being confused and tired and with
clouds moving in, I called it a night. It’s been cloudy ever since …

My next step will be to back off to the previous version of SGP that I
know worked and test that. My camera broke and I did no imaging between
early May and mid July. Since no one else had reported anything like
this, I decided to test with an older version and make sure it wasn’t my
camera. Now that someone else is seeing it …

  • Shane

In all 3 cases it looks like we’re not getting a response from PHD2. The following message is repeated over and over in the log:

[8/7/2016 6:05:10 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[8/7/2016 6:06:10 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status...

I’ll look to see why this isn’t being caught by Recovery Mode. I’m not sure if @Andy has any insight to what might be causing this.

It looks like we stop PHD2 while doing some plate solve/slew activities and then can’t communicate with it to get it started back up.

Thanks,
Jared

Hi Jared,

Before moving to the next target, PHD have been stopped:

[quote]
[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “stop_capture”, “id”: 1004}

[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[8/6/2016 11:28:46 PM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[8/6/2016 11:28:47 PM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[8/6/2016 11:28:47 PM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[8/6/2016 11:28:47 PM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[8/6/2016 11:28:48 PM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[8/6/2016 11:28:48 PM] [DEBUG] [Sequence Thread] PHD2: Successfully stopeed PHD2…
[/Quote]
After that, I could not find a start command in the log anymore, just the “GetPhdStatus” request.

Regards,
Horia

Prior to issuing a “Start” we need to know what the current state of PHD2 is. Thus the GetPhdStatus requests that all appear to be failing. All commands go over the same “pipe” so if we can’t get the status we can’t start guiding.

Thanks,
Jared

Hi Jared,

Most probably I am misinterpreting the log. Anyway, as far as I can understand it, SGP requests the status every minute:

And then instantly (i.e. the same second) gets the answer:

Is this not the answer SGP is waiting for?

Regards,
Horia

@kor: Can you confirm what version you were using prior to experiencing the issue with 2.5.1.17? I will try downgrading tonight to a previous version that works so that I don’t lose another night of imaging.

I have been experience what i believe is the same problem
Intermittently the plate solver does not execute.

  1. The telescope skews to a target,
  2. the image of the target is getting downloaded.
  3. Platesolver never appears

Sometimes restarting the sequence works, sometimes I have to restart SGP, sometimes I require a full reboot

I have placed my log here
https://drive.google.com/folderview?id=0B91c8lY19utvOThmZWRZSnFUd1E&usp=sharing

sg_logfile_20160807002424

[8/7/2016 4:16:52 AM] [DEBUG] [Pier Flip Thread] Runtime terminating: True
[8/7/2016 4:16:52 AM] [DEBUG] [Main Thread] Meridian flip was user aborted…

I had to abort after the plate solver never showed up. Here’s my guess on the relevant part of the log.
(just a guess)

I aborted and restarted the sequence and everytning worked fine
[8/7/2016 4:19:34 AM] [DEBUG] [Camera Thread] Display image preview using asynch task…
[8/7/2016 4:19:34 AM] [DEBUG] [Camera Thread] ---------> Save file took 194ms
[8/7/2016 4:19:34 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE complete…
[8/7/2016 4:19:56 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[8/7/2016 4:19:56 AM] [DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[8/7/2016 4:19:56 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[8/7/2016 4:19:56 AM] [DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[8/7/2016 4:19:56 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[8/7/2016 4:20:57 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[8/7/2016 4:20:57 AM] [DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[8/7/2016 4:20:57 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[8/7/2016 4:20:57 AM] [DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[8/7/2016 4:20:57 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[8/7/2016 4:21:04 AM] [DEBUG] [Main Thread] Centering: User abort…

Running latest versions of SGP 2.5.1.17 , PHD 6.2 and the latest SBIG drivers.
Camera SBIG STT-8300 with the FGW filter wheel

Sure, but you are not going to like this–it was back in early May, so it was v2.5.0.23 with the older autofocus routines and lots of missing bug fixes! Looks like I was using PHD2 v2.6.1dev6 at that time–if you think that matters.

Looks like I get another week of thunderstormy nights; hard to complain about rain when you live a desert, but …

  • Shane

I would need to see the PHD2 debug log. The log will show the messages PHD2 received from SGP and the responses it sent back.

I do not think the message PHD2 - No messages received from PHD2 for 1 minute, checking socket with status... necessarily indicates any problem with the PHD2-SGP communication. PHD2 does not send guide frame updates when guiding is stopped. If SGP tells PHD2 to stop guiding so SGP can do something like centering an object, then PHD2 has no updates to send to SGP and SGP logs the message about not getting any updates.

Andy

@Andy @Jared - As an update, last night I did downgrade to a previous version (I can’t remember if it was 2.5.1.15 or 2.5.1.16) but I did an early test of two objects, and then ran the same exact sequence that failed the night before. Both the test and the main sequence worked perfectly. So I will cautiously state that .17 seems to introduce a problem, though I would have to re-upgrade to .17 and test again to know for sure. Let me know if you want me to do so.

If that’s the case then it’s probably intermittent. The difference between 15, 16 and 17 is actually quite small and no changes to the guider or sequencer were made in any of those. Mostly it was logging and addressing a fast fame download issue.

It’s up to you to try .17 again. I will say that 15 and 16 have a fairly large flaw in them when taking frames in rapid succession which was addressed in 17.

I’ll attempt to reproduce this locally as well as it seems we received about 3 reports of this same issue within about 48 hours. Which is odd since .17 has been out for a bit now. Not sure what else could have changed.

Thanks,
Jared

If PHD2 works fine with slewing to the first target and starts up ok, is it safe to say that the same sequence of PHD2 commands will work for any subsequent target?

A couple of nights ago, I got tried to image in between some clouds. That didn’t work out, but I did get a log of the center target plate solve timeout in which no sequence was yet running. PHD2 was calibrated, but was neither looping nor guiding.

Here is the log:
SGP Log

  • 8:43:07 - I right-click the target and started the Center Target plate solve
    ** Center Target Steps 1, 2, and 3 completed as normal
  • 8:43:23 - Center Target Step 4 starts and the camera takes an image
    ** A few seconds later the image displayed
    ** The plate solver (PlateSolve2) did not start
  • 8:47:26 - Auto Center timed out and aborted
  • 8:47:38 - I opened the tools panel, selected Plate Solve and pressed “Solve and Sync”
    ** A few seconds later, the image returned and was solved as normal.
  • 8:48:47 - I tried the Center Target again
    ** Step 1 completed
    ** Step 2 started, the image was taken, downloaded and displayed
    ** The plate solve window did not appear
  • 8:52:50 - Auto Center timed out and aborted
    ** I shut down SGP to preserve the log in a form that clearly showed the failure.

I hope that this is useful. As you can see, there is no PHD2 interaction. For some reason, PlateSolve2 just never starts.

FYI: The first time I used 2.5.1.17 was about a month ago as my camera had been in for repairs and took a long time to get back. When I started imaging again, the first couple of nights, only my first target completed. After the 2nd time that happened, I reconfigured my sequence so I could do the whole night on one target. When I finally got a weekend and could stay up, I caught the error and started troubleshooting. That was the first log I posted in the previous message. So, though it took me a while, this issue has occurred with 2.5.1.17 since the first time I used it. I never ran 2.5.1.16, but will likely try that tonight.

Thanks for your help - Shane

After upgrading to .17 this has started happening to me. Downgraded again to .16

@Jared I wanted to provide another update after doing another test. I installed version .17 and the issue returned. I removed it and installed .15 again and the issue went away. I’m definitely going to stay with .15 for now as I prefer to be able to sleep. This issue definitely doesn’t sound at all intermittent.

I’m looking into this. I can’t really explain what from 16 to 17 would cause this but I’m investigating it. Slow going as I’ve been migrating to a new machine.

Thanks,
Jared

1 Like

Any progress made on this, I experienced this issue as well? For the first time I programmed 2 targets in a sequence and after taking 3 photo’s (of a 3 event program for the 2nd target) it stopped working resulting in the same PHD2 communication errors.

I use the latest Beta version 2.5.2.7 and PHD2 version 2.6.2.