Hello Ken & Jared. I have a problem that has been around for ages, but I haven’t pursued it in the past. This just feels like the moment to quiz you about it!
I am using a Dome and it has trouble staying at the right azimuth at sequence start up when the target is close to the meridian. Tonight my target is just east of the meridian, but the mount has decided to point west, going a bit past the meridian in the east to point west ‘early’, if you get what I mean. The Dome has synced with the mount perfectly and the autocentre routine has started. When it goes to move the mount to centre up after the first plate solve, the Dome is sent to an incorrect sync azimuth - I’m guessing that it is moving ‘the other side of the meridian’? The auto centre routine fails because the next plate solve image is of the inside of the dome…
I aborted the run, turned off dome slaving with the dome in the correct position and then started the sequence again, with no problems. Once it had started the first exposure, I slaved the Dome again.
I’m interested to hear what you reckon could be going on here…
Thanks,
Gav.
Aprox time of issue: Not sure, but it is at the beginning of the first Sequence run.
Link to Logs
Useful Info
OS: Microsoft Windows 10 Education Ver: 3.1.0.451 .NET: 4.8
Basically we have to make a guess as to which side of the meridian your scope is going to end up on when we issue a slew. Your scope is favoring the east side but we don’t know that until after the slew has completed and we’ve already told the dome to move like it is on the west side based on calculating the side that it should end up on.
We don’t really have a great way around this. You can set your mount’s preferences so that it doesn’t favor the east side (basically have a more “normal” pointing preference…even though I realize “favor east” is preferable for other reasons). The other option would be for SGP to have an option to stop the preemptive slew and just wait for your mount to finish and then slew the dome. I guess we could also allow for some “wiggle room” but that is very mount and user specific.
Hi Jared, thank you for your swift reply. I understand what is going on here and see why it is going wrong. My preference would be for the dome to slave to an actual mount position rather than a predicted mount position. I would happily accept the slight delay while waiting for the mount info to be reported as an incorrect slave point creates a very long delay (and attended operation) to get it working properly.
I leave this with you for now. It seems you know exactly how to solve the issue, it’s just a question of priorities! I know where this is likely to stand in the scheme of SGP priorities. I will work on getting lots of people to generate error reports about this!!!
Best wishes. Gav.
The DestinationSideOfPier property is suppoed to help with this but I don’t think many mounts support it. Given that the dome controller should be able to know where the mount will end up.
Another possibility is to assume that the slew hasn’t finished until both the telescope and dome have finished moving. This might be tricky because the final dome position may depend on the routine dome updating raather than special slew handling.
We already do this…but we don’t do a final check to make sure that the dome and the scope are in agreement. We assume that they’re both going to the right place. Then the timer that handles the dome sync fires and moves the dome to the correct position after the incorrect slew.
I think @PhotoGav can likely get around this by removing “Favor East” in his driver for the time being. I’ll have a look at DestinationSideOfPier sounds like that may be the best option to resolve this if that works!
Thanks for your input too Chris. I’m using a Mesu 200 mount and am not aware of any ‘favour’ options. I can set mount limits either side of the meridian, which I have set quite generously as I have plenty of room to go below horizontal on either side of the pier. It will go east to point west early if it can, I guess, which is something I really like! In last night’s situation, where my target was under half an hour from the meridian and I was shooting 1800s subs, it would have just sat waiting for a meridian flip rather than getting on with gathering data, had it gone west pointing east first.
I have my fingers crossed that DestinationSideOfPier comes and saves the day. If you have any pre-release versions that need a quick test, I’d be delighted to oblige.
Gav.
Maybe they’re called “favor” My G11 had something similar to that. I can’t recall what the actual option was. I can probably get you a pre-release later today/early tomorrow for you.
I have now tried the DestinationSideOfPier fix in earnest and it works perfectly. It did a very early meridian flip last night with no issues at all. Thank you Jared for the fix and thank you Chris for the suggestion.
My G11 had something similar to that. I can’t recall what the actual option was. I can probably get you a pre-release later today/early tomorrow for you.