Alright, thx for the feedback, let’s try this one:
Thanks Ken…I have just started a run for the night. If I am still up pre-dawn, I’ll load this up & give it a try.
During the day today, I installed 2.6.0.2501. I connected to the scope & dome via the SGP interface and after several moves of the scope (via Sky X)…the dome failed to follow. The dome did not move at all. (In case you want to ask…yes the dome was slaved to the scope). there was just no follow…I did not persist in playing with this version.
I reinstalled 2.6.0.24 and again connected up the equipment. Again via Sky X, I moved the scope (not too much)…and the dome followed. (Using this method (moving the scope with Sky X) it is usual that the scope completes its move and the dome then follows to align itself.
On the scope tab, within SGP, I instructed the scope to park. (After acknowledging the normal warning that the dome was connected) the dome actually went to its park position first…the scope did not move. When the dome was at its park position (and I can confirm that it was at its assigned park position)…then the scope proceeded to move to its park position. Simultaneously, as the scope began to move, the dome came off its park position and proceeded to align itself back with the scope (that is, where the scope was before it started the move to park). Now we had a situation for an instant, where the scope had reached its park position and the dome was back around to where the scope had previously been a few seconds earlier. At this point the dome, moved back again to align itself with the scope.
So at the end of the moves…the scope was in its park position, the dome was not at its park position but lined up with the scope again.
I hope the logs attached are a help.
sg_logfile_20170704110905.txt (24.7 KB)
ASCOM.DriverAccess.1110.314090.txt (988.5 KB)
…just some additional information to add to the above post:
I redid the above experiment (SGP 2.6.0.24) and exactly the same scenario. This time I noted the final dome position at the end of all movement and it was at an angle (azimuth) of 122.9°. (The park position for the dome had been set prior to this at 123.2°). I now reset the dome park position to 122.9°…so that the dome park position and final position if aligning to the parked scope were exactly the same.
I now moved the scope again 30° or 40° (dome followed as expected) and then from within SGP instructed the scope to park. This time the dome went to (the newly set) park position and stayed there …next the scope parked…and all movement was completed.
So it seems if Dome and Scope park positions are aligned (not necessarily the same azimuth)…no problem but if you want to park the dome away from aligned with scope park position…then things get messed up.
Again, I hope this extra piece of info is a help.
I’ve been following this thread closely. It bears similarities to my post “Erratic Behavior Between Scope and Dome”.
For testing I used the same simple sequence as in that post.
Slew to a star, take a 10s exposure, and then return to home position. Simulated camera and filter, and real Celestron and LesvedomeNet drivers and hardware.
Like Brendan, I made it easier on scope and dome by having their home positions agree at startup. By doing this the dome did not move but one or two degrees at startup to be aligned with the scope (that is prior to moving to target).
I tested different version of SGPro, in this order:
v 2.6.0.25 (1 test), v 2.6.0.2501 (1 test), v 17 (3 tests), v 18 (2 tests), v 17 again (4 more tests), v 18 again (4 more tests), v 20 (4 tests), v 21 (3 tests), v 23 (4 tests), v 24 (3 tests), v 20 again(3 more tests)
Here are some common features or behaviors:
-
Version has Disconnect Equipment at End of Sequence Feature
a) v17, v18, v20 — No
b) v21, v23, v24, v25, v2501 ---- Yes -
If Dome stops, and then continues to target, Camera will begin imaging without it
a) All versions -
If Dome rotates continuously to target, then Camera will wait on Dome
a) All versions (I think) -
Dome Slaves to Scope (i.e. it moves when told to do so)
a) v21, v2501 —No
b) v17, v18,v20, v23, v24, v25 — Yes -
Upon completion of imaging, Dome and Scope return Home at same time
a) v17, v18, v20 — Yes
b) v21, v23, v24, v25 (v21 and v2501 never move) NOTE: these versions move the Dome first and then the Scope once the Dome is Home
I. With one exception, all of v17, v18, and v20 behaved as expected. There was one (1) flyer out of twenty (20) tests. These versions started properly, and at the conclusion Scope and Dome returned home together. At sequence end, the dome stayed home. The one exception (v18) had the dome wander off by 88deg from home after everything was done.
II. The rest of the versions (excepting v21 and v2501, which never moved the dome) would randomly move at sequence end.
a) v23: two out of four times
b) v24: one out of three times
c) v25: one out of one time
The problem may have something to do with whether the dome and scope return to home together (v17, v18, v20), rather than the dome goes first (v23, v24, v25).
I can Dropbox the logs from the test if they are of any interest. There are a lot of them.
Mark
Hello Ken,
Apologies for the delay in trying out the new version - I blame work and aliens… I got involved in creating a short video of a crop circle that has appeared near home. You can have a look at the video here:
Apologies, I digress…
Anyway, I installed v2.6.0.2501. I unparked the mount, slewed to a point in the sky, clicked to slave the dome and nothing happened. So, I uninstalled v2.6.0.2501.
I reinstalled v2.6.0.25. I tried this out: unpark / slew / slave / park - all worked perfectly. I then unslaved the dome. Then I did the sequence of unpark / slew / slave / park - and it all worked perfectly again. So, I conclude that at the end of the Park actions, the dome needs to be unslaved. It can then be reslaved when the next Unpark happens, this can be manual or as per the On Sequence Start slaving option.
Thanks,
Gav.
Strictly speaking dome slaving needs to be turned off before any park operation is started, dome or mount.
With slaving on there’s a chance of a slave managed dome slew being commanded after the dome park command. The exact behaviour depends on how long it takes the dome to reach its park position, how long to the next slave check and maybe how long it takes the mount to complete parking.
SGP may be reading the mount park state from the mount and this is either parked or unparked. If a park command has been sent there may be a period when the mount is parking and IsParked returns false. There may need to be a separate ObservatoryState state machine in SGP that has more states:
- Unparked - both mount and dome are unparked, slaving is allowed.
- DomeParking - park command sent to dome, waiting to complete
- MountParking - park command sent to mount, waiting to complete
- Parked - both dome and mount park commands completed
- MountUnparking - unpark command sent to mount, waiting to complete
- DomeUnparking - may not be required, there’s no dome unpark command
- Unparked.
Slaving the dome is separate but for a slave slew to be done the observatory must be in the Unparked state.
This is tricky to get right, especially if there are multiple tasks which have to be synchronised.
Absolutely Chris, the fact that the dome is slaved when it is parked is the knub of the problem here. Hopefully your detailed analysis will help Ken & Jared come up with the best solution. Thankfully it is not a show stopper, so imaging can continue when atmospheric conditions allow!
Hello everyone, I’m just putting together dome automation using LesveDome software/Velleman Vm110N board and am having the same issues of the dome trying to park before the mount, but then returning to where the mount is pointing, then the mount parks leaving the dome in the old position.
Using Ver 2.6.0.23 o SGP
Wondering if there was a fix to this
Cheers Geoff
Hi Geoff,
I’m using the current release of version 3 and it works as it should. Upgrade time!
Gav.
Thanks Gav for the info
Geoff
I would at least try updating to the latest version of SGP2 as there were some dome changes made a while back. Also you can do a V3 trial and see if that meets your needs before purchasing if that’s what you decide to do.
Thanks,
Jared
Thanks Jared for the suggestion, I’ll try it out
Cheers Geoff