PS2 Suddenly Unreliable in Centering?

Sequence Generator Plate Solving
1

Hi All:
SGP v.2.4.2.10
Sad to say I am having plate solving difficulties that just started recently.
PS2 has become very unreliable. Solves reference frames fine.
When centering it has become hit and miss. Usually, but not always succeeds with the first solve to determine how far to slew from the reference. Scope slews successfully.
Step 4 of the procedure, the validation frame, usually fails to solve although it succeeds
occasionally. Failover to astrometry.net (remote) invokes successfully.

I am in the process of going from a Win 7 machine to a Win 10 machine.
Also from an earlier version of SGP to v.2.5.0.23. I have the same PS2 unreliability
on both machines, with both the earlier and the latest release of SGP.

The log and the profile from last night’s run, on the Win 7 machine, with SGP v. 2.4.2.10 are at Dropbox link: Dropbox - File Deleted

One failure occured about 12:30AM. Another about 01:50AM

Would appreciate some advice as to what has gone wrong after many months of flawless and lightning fast PS2 solves.

2

Having exact same issue…version 2.5.0.23…plate solve 2 works fine then moves mount a fraction to center and then plate solve 2 fails…I didnt have astrometry fail over checked but since I had internet connection I went in and turned on fail over and it solved it…I can post my log as well if needed…will have to go dig it up…I was shooting M51 and it was clearly visible on the PS2 capture…

Well log files are not there…run was on 4/5/16 and the only thing in the “help/open log folder” dated 4/5 is an empty temp folder…

3

yup, same here. Using 2.5.0.23 . PS2 was working great , now very slow or fails.

4

PS2 integration has not changed since its original implementation and many, many people are using it successfully (in 2.4 and 2.5). It is important to remember that all plate solvers can fail and moving to a new target that has less data, or has a lower altitude can appear to be sudden failure, but is really just bad data. Also it is important to note that your problems occurred (based on your log file) before you upgraded software. This makes updating SGPro far less likely as the source of the issue.

I looked through the logs of those who could or felt compelled to provide them and nothing looks amiss. There is one things that might affect long-ish FL imaging. Anyone doing this? If so there might be a real problem that I can actually see in the code and make a pretty easy adjustment.

5

Thanks, Ken.
Not sure if it qualifies as “long-ish FL imaging.” My OTA is an iDK of FL 2465mm.

I am puzzled that these failures are now pretty much “the way it is” both on the machine with v.2.5.0.23 and on the older machine that has provided such highly reliable PS2 solves for the past year. I changed nothing on that machine.

Now, all this has occurred since shifting target to M94. So, these failures have all been on the same target. I will have to experiment to see if I continue to have these consistent failures on targets where I had no such failures before. Up until now, I have found PS2 to be reliable to the extent of near infallibility!

I am disappointed there was nothing in the log to suggest just why the solves failed. M94 was actually near culmination on the second failure as it occurred with the flip. So, certainly not an elevation problem. A previous night, I also tried increasing exposures for the solve to 18 secs from the normal 5 sec (binned 3X3).
Still had failure.

6

This definitely does. I have made changes this evening to add more precision to the RA and DEC hints. That said, I don’t know if it will help… this change increases the decimal precision of radian RA and DEC from 10 to 14 decimal places.

Me too. Especially since you indicated that this period for which your solves were highly reliable was with the same older version of SGPro you used to submit logs in this post. If you changed nothing, the only variable is target and data. No plate solver is perfect.

If you’d like, you can remove SGPro from the picture completely by:

  • Finding an image where SGPro fails to solve via PS2
  • Saving that image to disk
  • Attempting to plate solve this image with PS2 completely independent of SGPro.

There actually is. It’s not super helpful, but the logs say that PS2 successfully searched all 999 regions and found no match.

Does all of this look accurate to you? It’s what we pass to PS2 for the hint data.

[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (HRS) - 12.8472491749536
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (RAD) - 3.36340196890599
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (DEG) - 41.122689100107
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (RAD) - 0.717726322070852
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: SCALE - 2.2622228994323
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Width - 1336
[4/14/2016 12:26:34 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Height - 890

7

Ok, I think I know what is going and but not why. It appears that SGO is sometimes failing to provide the plate solver with the image scale or is providing a bogus one. Like others all of a sudden my plate solves are failing. This is a sequence that just happened to be. Slew to Capella, center – all fine. Establish best focus. Slew to NGC4565. Start center and rotate. First solve fine (PS2) move mount request a 42˚ rotation (manual rotator), 2nd solve fine request a 4˚ rotation, next solve failed. Blind solve fail over to my local astronometry.net failed (this may be because I just upgraded from Win 8.1 to Win 10). Now I deperatey try Pinpoint - fails, PS2 again fails, astrometry.net on the web, fails (it is possible I did not wait long enough). Scratch my head do some imaging. Slew back to Capella, center – no problem. Slew back to NGC4565, center fails (PS2). Ok, so I’m suspicious. I invoke the solver on the last plate solve frame. It asks me for an image scale and I give it .39 which is the 1x1 scale even though this was a 2x2 frame. PS2 solves it in a flash. Go try center and rotate again the first plate solve succeeds but the next fails. It seems as if the routine is wiping out theimage scale value which I assume it gets from the camera spec and scales as needed by the binning. Of course I don;t really know what is happening here, but plate solving (not the solver itself) is failing badly and greatly impacting my imaging flow (one the first decent imagin night in weeks – isn;t that always the way)

8

This is simple to check. If you think there is a bug here, the logs very clearly express what scale hint is passed to the solver. You just have to post the logs and we can check (there is also an example 2 posts up that show what that area of the logs look like).

Maybe the width and height are not correct for your binning or there is some other issue… Please send the logs or validate that all of that information looks correct for the camera image image SGPro is attempting to solve.

9

BTW: I’m sorry I forgot to mention that I am using the latest beta 2.5.1.3. I went and looked at the logs and they show the proper image scale ( 2 times my .39 1x1 image scale) is identified for the solve attempts, even those that fail. I don’t see where that is passed to platesolve2.exe since I do not know what its parameters are. The first and second are RA and DEC, the last in the image to solve, the one before that the search limit. I assume the third parameter is somehow the image scale but it is not obvious how it is encoded. But, that must not be the issue since that third parameter is the same for solves that succeed and those that fail. SO, I’m still mystified. Lets take two data point from tonight:

  1. PS2 failed during centering. I then invoked PS2 on the very image it just failed on by right click plate solve. It asked me for the scale, I gave it .39 (not the effective .78) and it quickly solved the very frame it had just failed to solve – that is why I thought is was not getting an image scale hint.

  2. PS2 failed during center and rotate. The first solve went off without a hitch, that got RA & DEC very close. It then worked on rotation. It told me to rotate ~ 40˚. It then successfully resolved and told me to move ~4˚ . The solve to confirm that extremely tiny rotation failed! The plate solve frame looked fine and there where no clouds.

Sorry, if I am not providing enough info. Until tonight I had not looked at the SGP log file. I’m going to head back outside now and see if I can see anything odd.

10

You are providing plenty of useful information, we just need the full log file to make correlations.

Also, the scale is not encoded in any way. It should be visible in the command line we print out.

11

Ok. I have the log file. How do I get it to you? BTW: I just did a meridian flip (not automated). Ifter the flip I asked it to center on target. The first plate solve work just fine and made a minor adjustment, the second to confirm the move failed. Once again right clicked on the image it had just failed to solve. PS2 did not have the image scale so I filled it in and it promptly solved it. Is PS2 pulling the image scale from the FITS header? If so, is that perhaps not always being written? I see a share link, I’ll see if that is how I share the log with you.

12

This should work for the log file
https://drive.google.com/file/d/0B0D0ZS2PaFEEZW9IVC1VZVh2bTA/view?usp=sharing

13

Yes, although I am unsure of the precision required. Nothing here seems “wrong” although it’s the first time I ever looked at my binned 3X3 plate scale (0.75 a-s/px X 3=2.25 a-s/px).
Seems height should be 891 rather than 890? Actually height of STL11002 array is 2672. So, binned 3X3 that parameter rounds to 891. It has been truncated rather than rounded. Surely irrelevant?

Of course I did not save any of my plate solve images to disc. Will try that next time out. So far, I have never, even once, experienced failure on an image saved to disc with PS2. Only on the images actually taken while solve and center is running.

14

Actually, the 3rd and 4th params deal with scale. They are essentially scale (in "/px) and width in pixels expressed as radians. The 4th param is the same, but for height. Like you say though, params 3 and 4 are (essentially) the same for those requests that fail as those that are successful.

Right… I don’t think this is contributing to the problem. Essentially we want to make sure that a proper scale is actually being passed to the solver during sequence execution and I think we can prove this without much doubt.

Agreed. This might produce a very small error, but sure not enough to kill the solve. Might be able to prove this by solving at 1x1 or 2x2.

I’ll need to think about this a bit more… The problem seems less about bad hint or image data and more about “back to back” calls to the solver. Anyone seeing evidence that this is not true?

15

Ken,
It does seem like it might have to do with the timing of the request. My image scale is 0.39 binned 1x1 and my centering shots are 2x2 so .78.

I’m become quite confused by its behaviour. This might be an interesting log section to look at. Here we are doing a center and rotate. It appears the first solve in this section is a successful solve after I made what should have been the final manual rotation since the solve measured 91.74˚, my goal was 90˚ and the tolerance was 3˚. The second solve was of the confirmation frame and it failed

[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Center telescope message received…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Solving with Plate Solver PlateSolve2…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Performing auto center step 1…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Skipping step 1…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Auto center reference frame solved successfully…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Performing auto center step 2…
[4/15/2016 12:32:22 AM] [DEBUG] [Telescope Thread] Created full file name: C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:32:22 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE message received…
[4/15/2016 12:32:22 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[4/15/2016 12:32:22 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[4/15/2016 12:32:22 AM] [DEBUG] [Camera Thread] SetAscomNormalSpeed…
[4/15/2016 12:32:22 AM] [DEBUG] [Camera Thread] Cannot set readout speed, not supported by camera…
[4/15/2016 12:32:54 AM] [DEBUG] [Camera Thread] Created full file name: C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:32:54 AM] [DEBUG] [Camera Thread] Internal Interface: Set Preview…
[4/15/2016 12:32:54 AM] [DEBUG] [Camera Thread] Display image preview using asynch task…
[4/15/2016 12:32:55 AM] [DEBUG] [Camera Thread] =========== Save file took 238 ms
[4/15/2016 12:32:55 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE complete…
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] Capture complete, attempting to plate solve image C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (HRS) - 12.6048417956974
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (RAD) - 3.29993986541871
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (DEG) - 25.9874007574431
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (RAD) - 0.45356570725265
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: SCALE - 0.77602
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Width - 1694
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Height - 1352
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Regions - 999
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] PlateSolve2 Command Line:
[4/15/2016 12:32:55 AM] [DEBUG] [Telescope Thread] C:\Users\Richard\AppData\Local\SequenceGenerator\PlateSolve2.exe 3.2999398654,0.4535657073,0.00637325341108,0.00508656352525,999,C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\psXSolve_9.fit
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Auto Center scope frame solved successfully…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 12.6511201872671 Dec: 26.1358227668943
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope Sync: Passed in J2000 but mount requires JNOW, converting…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to JNOW RA: 12.6647610780828 Dec: 26.0461556356974
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Attempting to write fits header info for C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Opening fits file…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Successfully opened fits file…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Writing fits headers…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Closing fits file
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Syncing the rotator to 91.74 degrees…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Performing auto center step 3 (scope)…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Auto center slewing scope to match reference…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 12.6058333333333 (12:36:21) Dec: 25.9877777777778 (25° 59’ 16")
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[4/15/2016 12:32:57 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 12.6195102595363 Dec: 25.8979252896868
[4/15/2016 12:32:59 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[4/15/2016 12:32:59 AM] [DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[4/15/2016 12:32:59 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[4/15/2016 12:32:59 AM] [DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[4/15/2016 12:32:59 AM] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[4/15/2016 12:33:01 AM] [DEBUG] [Telescope Thread] Scope reports it is done with synchronous slew, verifying…
[4/15/2016 12:33:01 AM] [DEBUG] [Telescope Thread] Telescope: Slewing has completed
[4/15/2016 12:33:01 AM] [DEBUG] [Telescope Thread] Telescope: Settling for 10 seconds
[4/15/2016 12:33:11 AM] [DEBUG] [Telescope Thread] Telescope: Settling has completed
[4/15/2016 12:33:11 AM] [DEBUG] [Telescope Thread] Auto center slew complete…
[4/15/2016 12:33:11 AM] [DEBUG] [Telescope Thread] Performing auto center step 4…
[4/15/2016 12:33:11 AM] [DEBUG] [Telescope Thread] Created full file name: C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:33:11 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE message received…
[4/15/2016 12:33:11 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[4/15/2016 12:33:11 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[4/15/2016 12:33:11 AM] [DEBUG] [Camera Thread] SetAscomNormalSpeed…
[4/15/2016 12:33:11 AM] [DEBUG] [Camera Thread] Cannot set readout speed, not supported by camera…
[4/15/2016 12:33:14 AM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[4/15/2016 12:33:14 AM] [DEBUG] [MF Update Thread] Performing serialize…
[4/15/2016 12:33:44 AM] [DEBUG] [Camera Thread] Created full file name: C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:33:44 AM] [DEBUG] [Camera Thread] Internal Interface: Set Preview…
[4/15/2016 12:33:44 AM] [DEBUG] [Camera Thread] Display image preview using asynch task…
[4/15/2016 12:33:44 AM] [DEBUG] [Camera Thread] =========== Save file took 236 ms
[4/15/2016 12:33:44 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE complete…
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] Auto center verification frame complete. Plate solving image C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\plate_solve_image-2.fit
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (HRS) - 12.6057663603016
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: RA (RAD) - 3.30018191586607
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (DEG) - 25.9877860544782
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: DEC (RAD) - 0.453572431954511
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: SCALE - 0.77602
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Width - 1694
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Height - 1352
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSove2 Param: Regions - 999
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] PlateSolve2 Command Line:
[4/15/2016 12:33:44 AM] [DEBUG] [Telescope Thread] C:\Users\Richard\AppData\Local\SequenceGenerator\PlateSolve2.exe 3.3001819159,0.4535724320,0.00637325341108,0.00508656352525,999,C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\psXSolve_10.fit
[4/15/2016 12:33:51 AM] [DEBUG] [Telescope Thread] Auto center validation frame failed to solve. Solve failed! Maximum search limit exceeded.

The RA/DEC are very close since the prior move was small. Parameters 3&4 passed in which specify image scale are the same. So, it would appear it should have solved. And while I can’t say I did it this time, every time I tried to solve a plate solve frame left behind by a failed solve by right clicking, selecting solve and providing the image scale it worked.

This seems to have the smell of something asynchronous. Another thread interfering somehow?

16

I have a suggestion for something to try to gain some more info about this problem.

Why not try the following:

  1. first run the sequence exactly as you have been doing that fails with PS2. I that fails like it has, then do:
  2. make Astrometry.NET local your primary solver, and run the same sequence again.

If the Astrometry.NET also fails, then you have learned that this is not a PS2 specific problem and is more generic.
Otherwise, you know that this is a PS2 specific problem.

As an aside, for me PS2 has never been consistently faster than Astrometry.NET, which gives me average total solve times of 6 to 7 seconds, and ALWAYS works.
PS2 is incredibly slower if it is not somewhat close to the target, always taking a full 999 cycles before quiting, then an Astrometry.NET solve has to be done anyway.

17

jmacon,
There is a small chance I can try that tonight – skies are iffy but it may clear from 10pm to 1am. My setup had astrometry.net local as my backup solver. When the first two solves failed it tried my backup and after what seemed like a long time with no solve, I killed it. I was suspicious since just the day before I had upgraded the machine from 8.1 to Win 10 and I thought maybe I needed to reinstall AN local. So, I switched the backup to the online server. It too did not succeed. Now, I only gave it a few minutes and perhaps I did not wait long enough. A further data point is that I have PinPoint installed and I switched it in as my primary solver for a bit – it never solved. I did not read too much into that since I know from experience you have to be quite close for it to succeed. In fact I have never had a session where the first PinPoint solve works (because I never bother to sky align my mount, I just let the first plate solve do it) However, after that first solve PinPoint almost always succeeds so it should have solved in this case, but did not. So, while I do not yet have definitive data. It appears that this is not a PS2 issue. Perhaps a complicating issue is that the region of sky I was solving was fairly lower and rather star poor (SGP counted something like 36) thanks to seeing. But I totally dismiss that as an issue since on at least 3 occasions last night I did a manual solve with PS2 of the plate solve frame left on display when center failed. In every case PS2 solved the frame almost instantly (I did not time it, but I’d guess always under 2 sec). I do not think it likely that this is a solver issue.

As to your speed comments, they are directly contradictory to my experience which is limited as I only switched to PS2 two sessions ago. But I have found it to be blazingly fast. And last night when it went through 999 regions before failing, the logs proved that was 9 seconds!. Astronmetry.net local has always been noticably slower for me and the net version is very much slower – minutes (that may be because my mount is far enough way from the house that the wifi link is very slow. but I fixed that two days ago with a wifi repeater). Perhaps our difference in experience is a function of the iron. I am not a windows guy and sort of was forced to get a windows laptop when I started AP about a year ago. I tried using windows under bootcamp on an old 17" MBP, but low level driver issues kept popping up. So, I chose a pretty fast windows laptop (actually a gaming system even though I never play computer games) with 16GB of RAM.

18

Astrometry.NET was down for most of yesterday.

Not that I can think of… the thread that kicks off the solver is synchronous with respect to calling PS2. Meaning that it cannot call the validation solve until the reference solve is complete. That said, the solver does stay open ofr 10 seconds after the solve completes. SGPro ignores this. I wonder if having 2 instances of PS2 running at the same time is problematic. Do you ever have 2 instances running at the same time?

19

I don’t recall that, but I will check tonight. I think I have my mount settle time set to 10s so that should pretty much make an overlap impossible. It looks like I may have some patches of clear sky tonight to experiment with so I just hauled my gear out and set it up. Is there anything you would like me to look out for? I will for sure double check that each failed frame solves when explicitly handled to PS2. I’ll post the log file when I’m done and in general I’ll try to look for patterns. I’ll give Astrometry.net more time to solve on failovers. Who knows, maybe with all this attention every solve will work tonight :wink:

20

I guess making sure the image that PS2 is trying to solve is actually in place in the

"C:\Users\Richard\AppData\Local\SequenceGenerator\Temp\"

directory. When I think about what could cause possibly random issues it is almost always some type of uncontrolled timing issue. For this issue in particular, I wonder if:

  • The FITS file is sometimes marked as owned by another process (SGPro) and PS2 fails to get some information from it
  • The FITS file is present, but when PS2 opened it, the file was not completely written (meaning something like the last buffer flush had not yet executed).

Again, I don’t know how any of that could happen… the file write phase prior to solve is pretty tightly controlled and even validates byte sizes. Just throwing spaghetti at the wall right now…

It might be an interesting test (not a solution) to write code that calls different PS2 executables (alternating). This might tell us if the last PS2 run left some kind of lock on something that the next instance is having trouble obtaining…