Tried posting this via Report-a-Problem but kept getting an error.
Encountered evening of Jan 12th around/after 9pm local time.
I’ve been encountering this problem for a couple years. Have posted about it before although I can’t seem to find my previous posts on the issue. The problem is intermittent in that it only happens when a sequence is initiated and the first target happens to be close to, but not past, the meridian (let’s say up to ~30-60 minutes before meridian).
In this scenario, during the auto center routine, the dome opening slews away just before the camera takes an image to solve. The camera/scope ends up taking an image of the inside wall of the dome. Obviously the image solver fails because there are no stars. Interestingly, the dome slews back to the proper orientation after the camera finishes taking the image.
Not sure why this happens. Meridian flips work flawlessly and consistently, if the sequence starts when the target is well before the meridian. Only thing I can think of is that when the dome receives the slew command (as part of auto centering) and the target is already near the meridian, it somehow thinks the mount/telescope has already flipped to other side of pier (and it therefore needs to “flip” as well)? And then maybe slews back because the “slave to mount” kicks in?
So perhaps this is a dome driver issue? The dome is MaxDome II running through ASCOM Device Hub Dome (because 64 bit SGP and MaxDome is 32 bit only). Mount is MX+ and the TSX ASCOM driver has “Can get pointing state” checked.
Would appreciate your input before I try chasing this with MaxDome/Diffraction Limited. Is it possible that the dome slew command during auto center is different than a regular slew command? Or possible that dome slew calculation would get messed up if target close to meridian?
Attached is a diagram outlining the series of events and when the problem occurs.
Also - I encountered an additional error situation this time around. It may or may not be related to the “dome slewing during auto center when target is close to meridian” situation. Screen shot attached (Pier Flip delay window pops up but the count-down is a negative number and getting larger). Attempt Flip Now button is greyed out. Had to abort sequence at this point.
Just to add that my system suffers from exactly this issue too. I am using a Mesu 200 mount and Pulsar dome, so I am sure that the issue is originating from SGP. It has existed for many versions and many years, probably ‘forever’! It has been addressed in the past, but persists. As far as I remember, SGP ‘guesses’ the azimuth for the dome on the initial slew, and when very close to the meridian, it gets it wrong. I am interested to hear the latest thinking.
This is happening because of some logic that we have for pre-emptive slewing of the dome. When a slew is issued to the telescope we calculate out the dome position and send the dome there so the slewing happens in parallel vs having to wait for the telescope to finish, then start the dome motion.
Most of the time this works rather well…especially when dealing with larger slews or changing targets. But it’s certainly been a problem when the slews are close and especially when they’re near the meridian. If SGP “guesses” the side of the meridian incorrectly then that results in a large dome slew that almost certainly blocks the scope. I’m guessing this is exactly what’s happening here.
We’ll need to create an option to disable the pre-emptive slewing behavior for the dome and instead wait for the scope to finish slewing and then slew the dome to a position that matches.
Some drivers implement a DestinationSideOfPier that allows us to ask the mount what side of the pier it will end up on given a set of coordinates. Unfortunately your mount does not implement those properties, so SGP is assuming that you’ll end up on the other side of the meridian and it is wrong.
I’ll see about making these changes in an upcoming release.
Thanks for the explanation. It would be great to at least have the option to turn off pre-emptive dome slewing if it will solve the near-meridian dome slew errors. The extra dome slew times will be worth it in order to avoid my existing issue (especially when existing errors happen during unattended imaging and it shuts things down for the night!).
Just wondering - could there be a way/option to only turn off pre-emptive dome slewing when the mount is “near” the meridian (say, < 1 hour?).
I have also considered that option. I think if anything there will need to be 3 options: Enabled, Disabled, Disabled near Meridian.
I don’t like the idea of completely disabling it as it does provide some nice optimization most of the time. But there are also cases when near the meridian that you’d specifically want the pre-emptive behavior, like when performing a meridian flip.
I’ll have to get in there and see what all makes sense. But I’m sure we can certainly make this better. Initially it may be just having an Enabled/Disabled state and then refining from there.
Hi,
I did think that my Dome slew settings are wrong before I see this topick
I face the same issue near meridian.
Even with prefferd pier side set in the mount controller.
The mount controller is Onstep, Dome controller is Nexdome with fw v.4 if remember correct.
