Addressed in 3.1.0.327
http://mainsequencesoftware.com/releases
Jared
Wonderful, thank you for the new release. I will report back with my findings.
Enjoy the Star Party - hope you have good clear skies. I’m off to one next weekend and the forecast is horrendous!! Looks like it will be an opportunity for theoretical rather than practical astronomy!
@Jared, I have just tried the new Beta, v.3.1.0.327 and the results were not good. Here is my order of events:
Connect everything up
Click Run Sequence
Dome started moving to sync with mount in home position (az = 356 ish) - incorrect az for target
Mount slewed to target position
Dome arrived at sync point az = 356
Auto Centre did a slew
Dome started slewing to correct az for target
Auto centre started taking its first plate solve image… of the inside of the Dome
Dome arrived at correct az for target
I aborted the sequence
Arrgh!!
So, the dome is still being sent to sync with the mount in the home position at the very start of the sequence, which is messing everything up.
SGP log: Dropbox - File Deleted - Simplify your life
Dome log: Dropbox - File Deleted - Simplify your life
Something seems a little off in the dome logs. SGPro issues command to slew to azimuth 180 at 23:22:15. This is almost 180 degrees from its synced position and the dome reports it is done slewing just 11 seconds later:
23:22:26.218 Slewing Get False
In the dome’s logs you can see that the dome is actually still moving… but seems to reporting that it is not. As soon as SGPro finds the dome to be done slewing, it moves on to the next step in centering.
Hi @Ken, thank you for looking through the logs and for your swift reply.
Mmm, yes, something strange is going on. Looking through both logs, I see the following:
To begin with, SGP sends the Dome to an azimuth of 356:
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Observatory: Calculating new position using:
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Azimuth: 357.460700035754
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Altitude: 51.3652076796753
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Hour Angle: 90.9183136689682
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Pier Side: East
[10/26/19 23:20:48.086][DEBUG] [Sequence Thread] Observatory: Adjustment needed, slewing to Azimuth: 356.611890493781
[10/26/19 23:20:49.092][DEBUG] [Sequence Thread] ASCOM Telescope: Observatory slaving complete
[10/26/19 23:20:51.118][DEBUG] [Sequence Thread] Mount startup good, reports not parked and tracking…
The Dome reports:
23:20:48.086 SlewToAzimuth Start 356.611890493781
So, this is syncing the Dome to the Mount in the home position.
SGP then does this:
[10/26/19 23:20:51.233][DEBUG] [Sequence Thread] DoEventGroupChange: Slewing to target
[10/26/19 23:20:51.241][DEBUG] [Main Thread] Adding sequence level notification: Slewing to target “M74”…
[10/26/19 23:20:51.244][DEBUG] [Sequence Thread] Sending Notification: Status - Slewing to target “M74”…
[10/26/19 23:20:51.244][DEBUG] [Sequence Thread] Handling monitoring event (Good Night System, Status): (Edge8-Mesu) Slewing to target “M74”…
[10/26/19 23:20:51.245][DEBUG] [Sequence Thread] GNS: Sent status message to GNS ((Edge8-Mesu) Slewing to target “M74”…)…
[10/26/19 23:20:51.256][DEBUG] [Sequence Thread] Telescope: Slewing to J2000 RA: 1.61078888888889 (01h36m38.84s) Dec: 15.7796555555556 (15°46’46.76")
[10/26/19 23:20:51.256][DEBUG] [Sequence Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[10/26/19 23:20:51.256][DEBUG] [Sequence Thread] Telescope: Slewing to JNOW RA: 1.62862014316158 Dec: 15.8803095123202
[10/26/19 23:20:51.256][DEBUG] [Sequence Thread] Telescope: Calling Observatory Slave Slew
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Observatory: Calculating new position using:
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Azimuth: 153.972696015124
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Altitude: 52.2685050322084
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Hour Angle: -15.9466892030366
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Pier Side: West
[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Observatory: No adjustment needed.
So SGP slews the mount to the target position and does a new dome sync azimuth calculation using the new coordingates, but that results in "[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Observatory: No adjustment needed. " - how is that possible when the coordinates are so different?!
We then have a whole period of this in SGP:
[10/26/19 23:21:09.375][DEBUG] [Sequence Thread] Telescope: Observatory is reporting slewing
[10/26/19 23:21:10.376][DEBUG] [Sequence Thread] Telescope: Observatory is reporting slewing
So, SGP knows that the Dome is slewing and is waiting before doing anything. The Dome is still slewing to sync with the mount in the home position, meanwhile the mount has slewed to the target position.
Finally the Dome reports that it has finished its slew and SGP sees that:
Dome Log says: 23:22:04.423 Slewing Get True
SGP Log says:
[10/26/19 23:22:05.425][DEBUG] [Sequence Thread] Telescope: Slewing has completed
[10/26/19 23:22:05.425][DEBUG] [Sequence Thread] Telescope: Settling for 10 seconds
We then get the following:
[10/26/19 23:22:15.612][DEBUG] [Telescope Thread] Auto center slewing scope to match reference…
[10/26/19 23:22:15.626][DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 1.61078888888889 (01h36m38.84s) Dec: 15.7796555555556 (15°46’46.76")
[10/26/19 23:22:15.626][DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[10/26/19 23:22:15.627][DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 1.62862014288309 Dec: 15.8803095167005
[10/26/19 23:22:15.627][DEBUG] [Telescope Thread] Telescope: Calling Observatory Slave Slew
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Observatory: Calculating new position using:
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Azimuth: 154.504636883159
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Altitude: 52.3640625202812
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Hour Angle: -15.5941432622477
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Pier Side: West
[10/26/19 23:22:15.717][DEBUG] [Telescope Thread] Observatory: Adjustment needed, slewing to Azimuth: 180.81186955877
[10/26/19 23:22:17.432][DEBUG] [Main Thread] Background load target 11-0
[10/26/19 23:22:17.432][DEBUG] [Main Thread] Adding table row controls for Group: 11; Event: 0
[10/26/19 23:22:17.477][DEBUG] [Telescope Thread] Scope reports it is done with synchronous slew, verifying…
[10/26/19 23:22:17.485][DEBUG] [Telescope Thread] Telescope: Observatory is reporting slewing
[10/26/19 23:22:18.486][DEBUG] [Telescope Thread] Telescope: Slewing has completed
[10/26/19 23:22:18.486][DEBUG] [Telescope Thread] Telescope: Settling for 10 seconds
In the Dome Log we see:
23:22:15.717 SlewToAzimuth Start 180.81186955877
Which is good, SGP finally works out the correct azimuth for the dome to sync with the mount position pointing to the target and the dome starts its slew to sync up.
The Dome then finally reports that it is slewing with this:
23:22:26.218 Slewing Get False
repeated Slewing Get False until:
23:23:30.389 Slewing Get True
So, looking back at the SGP log for that section, SGP does indeed think that the Dome has finished slewing at 23:22:18.486 because the Dome has not even started reporting that it is slewing until 23:22:26.218, some seven seconds later…
And it all falls apart as the dome is slewing, but SGP is convinced that the dome has finished its slew and all is fine to proceed with the auto centre routine…
The whole problem here comes about from this line in the SGP log: “[10/26/19 23:20:51.338][DEBUG] [Sequence Thread] Observatory: No adjustment needed.” when in reality there definitely is an adjustment needed because the two sets of coordinates are 180º apart!
Does that make sense, am I interpreting things incorrectly? Do you agree that the dome should be synced to a new azimuth value when it isn’t? Are you able to find the reason why that new sync az is not being generated?
The problem is indeed exacerbated by the fact that the dome doesn’t report it is slewing to the correct azimuth for several seconds, but this is secondary to the main issue of the dome not being sent to the right place at the right time.
Many thanks,
Gav.
P.S. Apologies for the very long message, but hopefully we will get to the bottom of this. Also, the foreacast is finally clear for tonight and I really want to get some data collection going! I am going to try starting a sequence with the dome already at an azimuth of 356, ie. the position of sync with the mount in its home position, and see if that makes things work by eliminating the long initial dome sync movement. The reason why I have the dome home position set to 180º and not 0º (or 356º to be precisely in sync with the mount) is that I want the solar panel on the outside of the dome to be facing south so that it can charge up the dome shutter battery efficiently during the day.
Who said that astrophotography was easy…!!!
*** UPDATE ***
I am in my dome right now running some tests and things are working perfectly! When I start a sequence, the dome is being sent to sync with the mount in the home position, but as soon as the mount is sent to slew to the target, SGP is now correctly issuing an updated dome sync azimuth value, which the dome is then immediately starting to slew to. Everything is then perfectly in sync to continue with the sequence.
Why did that not work last night??? Nothing has changed and it now works properly this morning.
The weird vagueries of software de-bugging!
Anyway, @Ken & @Jared, thank you for your attention and patience with this matter. It looks like you can ignore this issue for a while! I will be testing in earnest tonight, I hope, and will report back with my findings. Fingers crossed!
We can take a look at foregoing the initial slew so that SGPro does not need to wait for the dome to get to the scope’s park position before going to target.
I can confirm that at least on my initial tests tonight the slew to and center routines work perfectly.
I’m running two sequences tonight to get M31 Ha data then LRGB on LBN 782. I’m going to set it up to start automatically and see if it runs unattended normally. High hopes!
I can also confirm total success with the sequence I have been running tonight. It started perfectly, (I had a small hiccup with focussing, but that’s another story and mainly down to user error!), then gathered lots of data flawlessly, ending with a perfect meridian flip and a few more subs before gathering haze led me to abort the sequence.
It appears that the initial slew is interrupted with the new azimuth for the target that the mount slews to, so @Ken, if it always does that it won’t be necessary to change anything about the initial slew.
Further testing will be done when weather conditions allow.
Thanks for the great support for an excellent bit of software!
Gav.
I had actually removed the initial “unpark” slew but reverted that change as I felt it could be too dangerous without some additional testing. We will likely add it back in but it needs more testing. There really isn’t a reason that the dome should be synced to the park position of the mount right before we slew it.
Jared
Jared, it does seem unnecessary to sync the dome before the mount is unparked. If you would like me to spend some time testing a version that doesn’t have that initial Unpark slew, I would be happy to do so.
Gav.
I’m not sure if my dome problem is the same as here as I am new to SGP. I have noticed the dome moving back and forth a few inches during imaging. It hasn’t moved the slot where the telescope is blocked but it is adding unnecessary stress to the motor. It did this the night of January 1 and the object I was imaging was near zenith.
These issues should all be resolved in the latest 3.1 releases. If you’re having issues please make sure you’re on the latest 3.1 release and post logs where the issue occurred.
Thank you,
Jared
Hi Jared,
I am running version 3.1.0.425 on a Windows 10 64 bit desktop.
Here is the log from the session on 1/1/2020: https://www.dropbox.com/s/b7mpnxyzho6mn47/sg_logfile_20200101162259.log?dl=0
Thanks
Dale
Hi @Jared,
I have the same problem with my dome. I have to turn off the slaving and use the slaving in the underlying dome driver in order to avoid it, which I think has the unintended side-effect of not closing the dome at the end of the session. I’m assuming if the dome is connected, but not slaved, this is why the dome did not close last night at the end of the sequence (you’ll see in the log I closed it from the module at 7:30am).
However, the issue only seems to manifest during a plate solve.
SGP will move the dome about (roughly) 10 degrees, which is sufficient to have the scope blocked during the imaging. If I turn off the slaving in SGP, and turn it on in the underlying driver, the dome goes to the correct position.
Because I have the dome setup through a hub with different polling times, I can see that:
a) the position is reported correctly - both SGP and the underlying dome driver see the same azimuth reading
b) the parameters for the dome geometry are confirmed as being the same in both SGP and the underlying dome driver.
c) when just running in a sequence, it seems to position correctly (although I’ve not watched this constantly over the entire night to confirm, but no subs seem affected).
d) when running a plate solve, it goes out of position
I’m running 3.1.0.454
The log is here:
NOTE: I think I turned off the slaving in SGP around midnight and then started relying on the underlying driver to do the work.
My Dome setup parameters are here:
My main reason for trialling SGP (vs other software I’ve been using like APT) is to be able to ensure I can close the dome at the end of a night’s imaging while I sleep. I believe if I can be confident that I can control the dome correctly with SGP, then it’s probably the software I will run moving forward.
Thanks.
Rob
For the “radius” in SGP try setting the diameter.
Thank you,
Jared
Jared,
So you’re suggesting that instead of 914mm for my 6 foot dome, I put in a radius of 1828mm.
Does this mean the field is mis-labeled?
Just for reference, the ASCOM driver config is here:
I’ll give this a try tonight, weather permitting.
Thank you.
Hi @Jared,
I’ve set the “Dome Radius” to be double (ie the Diameter) of 1828.
It appears to have solved the issue (during the plate solve certainly), and so far, during the sequence.
We’ll see I guess, in the morning when it’s finished it’s sequence 
Can you please explain what this issue is? Just a mixup with the labelling of the parameter?
It’s always been diameter but we changed it a while back as some folks seemed to have better success with radius for some unknown reasons. My guess is that they were seeing some other issues (which have been resolved) around the slave slewing. Only the label was changed as it seemed more correct at the time but I had no other evidence to prove them wrong or right and the slaving math is fairly complex.
Thanks,
Jared
Well, so far so good.
My rig is about to do the meridian flip shortly, so that should full exercise the routine!
Actually, from what I have seen, ASCOM seems to ask for the RADIUS, so for consistency, I’d leave it that way and double the number when passing it in to the algorithm. A lot of descriptions of those measurements are difficult to understand, so keeping it consistent should help.