I can answer this one, it’s an easy one:
If you check that then the sequence will wait for camera cooldown with no manual intervention needed before the sequence starts.
Andy
This means what is says. You passed hints to your solver to help with the solve and the solve way way out of tolerance with the provided hint. No way to turn this off. How is it that you are getting this and are OK with ignoring it? Not a rhetorical question. Honestly want to know if there is a workflow we missed.
No way to disable this. SGPro needs to do stuff with the mount and it is parked.
I think there might be a bug here that occurs only on sequence start. We’ll look at this one. Just uncheck it for now.
We do actually block and wait for dome movement to be complete. This issue (seen by others) usually means that your dome has reported it is done moving in error.
On Plate solve too far from expected position of mount:
This is kind of a mystery to me. I am getting this with both Platesolve2 and Astrometry.NET local. It is therefore coming from SGP code.
It baffles me because the mount is at the CWD position, or within about 1 degree if I did some balancing. I have Astrometry.NET set to 5 degree tolerance. I click ok and all works fine, as expected. Seems like a bogus error, but I don’t know what other hints might be going to the solver. This message is new in the last week. The Three weeks prior I was using essentially the same setup in the new observatory. Will check again tomorrow night.
I am also not sure why ignoring this could be a problem. If the hints are bad, so what? Won’t the mount get synced to the plate solve location, as we want it to, and then proceed correctly on its way?
On Mount is parked. Unpark it?:
I understand you need the mount unparked. Why not just unpark it? Put a timer on the dialog box like you have done else where, and if the user does not respond (like I am not around to watch the screen), just answer yes to unpark it.
On the Dome comm issue, I may need to get a real serial port for my obs pc. The driver suggests many serial to usb converters can produce comm problems.
And thank you @Andy. Suggestion should work fine.
This is true… we are checking this for safety.
If this happens again, please send logs so we can see the behavior (it is easier than having it described to us). Maybe our tolerances are too tight?
It can be very dangerous to some folks so we default toward safety (always). You can get successful solves that are bad (even on the other side of the hemisphere). This can cause subsequent slews to move in very dangerous (unintended) directions. Since SGPro is largely designed to be run unattended, we do a little sanity check here. Losing a night is better than losing a scope.
Maybe… This should not be a blocking issue for automation though. We should never ask this question except when you click Run Sequence (immediately after). If we are asking at other times, it is unintentional. We figure that we are allowed to ask questions immediately after clicking Run… after that is a different story.
Often I need to start the imaging process in late afternoon, say before going out to dinner, so that during dinner the whole imaging process can take off on the optimum schedule. So I power on all the components, load SGP and click Run, at say 5:00pm. So the mount connects and starts tracking. I must turn off tracking so the mount does not track for several hours before the start time. Then the Unpark mount question comes up.
Looks to me like I am going the have to program AutoIT to do all these things on exactly the best schedule. I was hoping to be able to just use SGP and start the process early in the day. Are there any command line options available, particularly to load a specific sequence?
Then my AutoIT script will have to deal with the Unpark question when the start time arrives.
Just set a start time on your first target and click Run Sequence. This will leave everything stationary and won’t slew or even start tracking until that time comes. At which time it will jump to life, which sounds like what you’re after.
Also plate solving at the pole can cause issues for many mounts. I would recommend using the slew option in addition to auto center (on all targets for that matter)
Hope that helps,
Jared
I can add some background context for this one… see this post for some history on why this safety check was added. Essentially, it is protecting you from a bad plate solve causing your gear to crash into your pier. The assumption is that during an automated run, your mount will always know roughly where it is pointing, and if a plate solve is wildly different it could be a bad plate solve. SGP will only put up the the error if the plate solve / mount coords mismatch happens in the course of a running sequence (that is, presumably unattended.)
If you do an explicit Solve and Sync before you start your sequence you should never see that message, unless you get a true bogus plate solve while the sequence is running – rarely or never – in which case it may have saved your gear from damage.
I’m not sure what kind of mount you have or how you park it, but there may be some procedural way to do it so that it does not lose track of where in the sky it is pointing. If not, then I think you will need to do an explicit Solve and Sync or Blind Sync before you start your sequence.
Andy
I think solving away from the pole (using both slew and auto center) will likely remove this issue. When you sync near the pole you can introduce all sorts of error. If I sync very close to the pole my G11 is pretty much worthless and has to be completely rebooted before it knows heads from tails. But this may vary between mounts. However it’s still not a great idea. Any small amount of error is compounded.
Jared
1 Like
Thanks for the tips. When I click Run, it immediately connects to all the equipment, which is why I have to turn off the mount tracking. Then when the start time arrives, it stops with the Unpark question.
Plate solving at the pole (which is where it initially is for me) may be the cause of the Plate solve hints issue. Good tip to also slew. Will give it a try.
I have a Losmandy Titan, and I have Eastern and Western limits that prevent the mount from touching the pier, and those work fine for me, so I am not too concerned about this. And I can’t do the explicit Solve and Sync at 5:00pm. But Jared just pointed out that plate solves at the pole can be problematic, and always doing a Slew in addition to a Center eliminates this possibility for error, and saves time. Thanks for the background info.
Hm, I’ll have to check this on my G11. I think it does turn on tracking on connect but stopping tracking while the sequence is in a waiting state should be ok (as it expects it to not be tracking).
FYI those are relative to where the mount thinks it’s pointed. So a bad sync can effectively change your limits since they’re software, not hardware, limits. Having said that the majority of my automation issues with the Gemini almost always point to a sync at the pole. This generally makes the mount get confused about pier side and causes the OTA to point to the ground.
I’m thinking it might be a good idea to always do a slew prior to an auto center. I can’t see any reason why not. We may change this behavior so auto center always slews prior to doing the first solve and sync.
Jared
I think this is a great idea. And thanks a bunch for the clarification on how the limits work. Did not occur to me that it is a software issue, and Gemini does not actually know where the mount is.
Just reviewed the code. You are using a workflow that we did not account for… If your mount was parked before running the sequence, SGpro would ask you the correct questions and the sequence would work the way you want it to. The issue is that you click Run Sequence and then park the mount. We’ll try and figure out how to deal with this better. In the meantime:
- Manually connect the mount
- Park it
- Click “Run Sequence”
- Tell SGPro to unpark the mount when the sequence start time occurs (it will prompt you)
The way you are running, SGPro sees no problem with the mount and does not ask the right questions.
Also… this message, as you describe it, I’m not sure what it is or when you encounter it. We do not seem to have anything like this in the code. Can you describe what series of actions lead you to this? I want to make sure, in addition to what I wrote in the message above, that we are fixing the right thing.
Maybe this is something coming from the Gemini software when we try to perform operations on a parked mount? I just can’t find anything resembling it in our code.
I have rerun the whole process this morning with plate solve and guiding turned off, and I cannot reproduce the same error. It was a 1 line error (as I remember it). The only difference I can think of is I was connecting all equipment before doing the sequence Run.
A couple of times this morning got this error during the initial Run process:
Sorry, but I am not sure exactly what was different with my process then. Difference may be whether or not the mount has been freshly powered up at the start of the process.
My last carefully recorded event process (done twice) was:
- Power on all equipment.
- Open SGP and Run sequence.
SGP connects all. Mount is tracking. - Stop Tracking
- Start time arrives, Slews to target and Integrates.
No error messages came up. Sequence runs normally.
Looks like this may be a non-issue if I follow the above process.
I’m seeing the same problem as Jmacon and this is a new problem that has cropped up. It was not like this before.
What I see is that as soon as I hit ‘run sequence’ SGP decides to unpark the mount. Before, it would wait until the awaited time to unpark the mount. This is repeatable.
Here is the log files:
This is a problem because if you didn’t notice this, your mount will potentially hit a limit. What changed?
Nothing that I know of in SGPro… Maybe a change with your driver? This is not repeatable with the ASCOM sim. You can / should give it a shot to see if we are doing the same thing.
- Create a target with start time in the future
- Connect and Park the scope
- Run the sequence, click “Yes” when SGPro asks if it’s OK to unpark the mount for you…
- Mount remains parked until sequence starts
Lastly, if SGPro makes a request to unpark the mount, you will always see “ASCOM Telescope: Unpark message received.” in the logs. Your logs do not have this.
1 Like
It’s interesting, because I can shoot you a video if you’d like showing that my mount is unparked.
What does SGP do differently when you hit ‘start sequence’?
Of note, I parked the mount manually after starting a sequence last night. SGP was able to unpark it and slew it around after that without issues.
To the best of my knowledge… absolutely nothing. On top of this, I cannot reproduce this behavior with a “normal” mount driver. Normal is in quotes because there is really no such thing (despite the ASCOM contract). No video is necessary. I would suggest you go through the set of activities that causes the mount to unpark and find the exact time this command is received from the mounts ASCOM log. We can cross ref this with the SGPro logs to see if your mount is unparking itself via some other command that we would never expect to unpark it.
1 Like
Wilco, I’m sure it’s a setting I remembered to set back in the day and haven’t set this time around.
Thanks Ken,
Chris