Dome Slaving Wrong

General
22

Hi Jared,
I’d say yes in general.

But it’s more than just dome slew speed. There’s a tendency for dome “hunting” (that is “back and forth”), after some pier flips.
And some slews (maybe only at startup) result in the dome stopping (10s max) and then resuming its slew.
During both these cases , SGPro does not honor that the dome is still moving to its eventual correct position … and SGPro begins the plate solve (imaging) routine while the dome is still moving.

I’m fairly certain that this behavior started after 2.6.0.20, and includes versions through 2.6.0.24 (which I still use). I’ve not tried 3.0.0.4 yet.

Mark

23

No. The dome does not eventually go to the right position.

Yes. Please do review this in SGP.

I looked through the release notes of each of the current version 3 beta versions and did not see a reference to a fix for the dome slaving problem. Perhaps comments ended because users found a workaround such as described by Mark.

Thank you,
Manning

24

This would have been a while back in 2.6.

Thanks,
Jared

25

Jared,
Mark has reported that the dome slaving problem occurs in versions 2.6.0.21 through 2.6.0.24, and my tests confirm that it persists in 2.6.0.25 which I believe is the most recent 2.6 version.

If the fix is not in any of the version 3 betas, then your statement that, “This would have been a while back in 2.6”, implies the dome slaving problem was fixed in a version prior to 2.6.0.21 and was reintroduced in 2.6.0.21.

It would seem then the clue is in a comparison of 2.6.0.21 to 2.6.0.20. I don’t know where else to suggest looking. As I mentioned previously, the earliest 2.6 version on the Web site is 2.6.0.21 so I have no way of looking for an earlier point at which the problem might have been fixed.

Thanks,
Manning

26

Manning,
I wasn’t suggesting that these were fixed. Just that we fixed a handful of issues in 2.6 a while back and I hadn’t heard much since then.

Sorry if I wasn’t clear.

Thanks,
Jared

27

Hi Mark,
I was able to do some tests today. I connected ASCOM Dome Control to MaxPoint and to LesveDomeNet. I connected SGP to MaxPoint.

At first I tried telling SGP “No observatory”, but I got an error. When I acknowledged the error, I got a pop-up saying the dome would not be slaved; was I OK with that? I said Yes because I wasn’t asking SGP to slave the dome, but when I clicked OK, I got the original error back again. So, since it just seemed to be an endless do-loop, I told SGP the observatory was a simulator. Then SGP didn’t complain.

When I slaved the dome in ASCOM Dome Control, it rotated to the parked scope position. Fine. I ran a sequence and the telescope slewed to the target. After the scope and software confirmed it had reached the target by beeping, then the dome rotated. Apparently ASCOM Dome Control acts synchronously. I think MaxIm DL operates the scope and dome asynchronously. Note to self: I have to be careful then to not move great distances to targets or I may run into a problem with the shutter cables hitting the scope.

In fact, I had to abort the dome move in the first test just because of the danger of running into the shutter cables. Perhaps because of that, when I resumed the test, the scope and dome were not aligned properly. I disconnected dome and scope, parked the scope, and used the LesveDomeNet UI to re-home and park the dome.

Then, I did three more tests with different targets and the dome successfully aligned with the scope in each case.

During none of the tests did the dome behave in the erratic way it had when slaved in SGP. So, even with the small number of successful tests, I think I may have an arrangement that will work.

Now on to testing the automation of all the other functions: camera exposure, focusing, plate solving, centering, filter operation, guiding, etc.!

Thanks,
Manning