GEM meridian flip and dome position

Issue #38 invalid
George Silvis created an issue

I assume that the dome will move for a german equatorial mount flip when the dome controller software which is talking to the Nexdome driver (eg ASCOM Dome Control or MaximDL) tells it to.

Is that true? That is, the Nexdome driver/firmware makes no judgement as to which side of the pier the scope is.

Thanks,
George

Comments (5)

  1. George Silvis reporter

    Scope is a CEM120 which does report pier side. MaximDL is managing the dome position. Flip set on the scope to 14deg past the meridian. I tracked Jupiter to that point and the scope dutifully flipped. But the dome did not move. I toggled the slave-to-scope; nothing. I disconnected the dome and reconnected. Ah: the dome moved to where the scope was pointing from the East side of the pier.

    So, there is a failure to communicate here. Maxim not recognizing the change? According to it’s status it knew that the scope was east of the pier and that the scope was a GEM.

  2. ron crouch

    Hi George! i do not think the dome firmware knows or cares about pier side. Just goes to azimuth on command. It is all up to the client to deduce the correct azimuth based on actual scope position and the 3 scope offset parameters (in client) needed to sort the geometry. It is quite common for the dome to be at an apparent opposite side from the mount especially with my 8” newtonian where the offset from Mach 1 dec shaft to center of OTA is really big. Also whenever pointing near straight up dome can be miles away from “scope azimuth” in order for the OTA to look through the slot.

    I know that You know all of that!! The observation you see with the the dome not moving is exactly like what I would see if slaving were turned off in my client and scope flipped.. Something is definitely amiss in the interactions between your scope driver the dome and the client.

    I see 100% perfect dome control during pier flips.. typically 2 to 4 each night.. I use ACP as client and my prefs there allow up to 10 minute tracking past meridian to allow wiggle room for subs ensuring ACP is using the nice straight up time rather than wait til pending flip tiime for the object. I also know that if I’m playing around with POTH connected to both my mount (Mach 1) and ASCOM.Nexdome with again The Sky X asking for positions it is also all fine.

  3. ron crouch

    This sounds like a problem in Maxim to me. If you do something like turn off the big ~1 hour flip delay (14 degrees in your test with Jupiter) does it behave properly? I know for sure that in order for my automation with ACP to work Maxim is never EVER connected to the mount because if I do so Maxim will mess up the guiding corrections on pier flip. ACP and ACP alone determines pier side and reverses guiding on flip to west. Point is that one and only one client can be in control. Having said that Maxim GUIDER is connected mount driver to allow ASCOM direct guiding but that is completely different from connecting Maxim to the mount per-see. So in my world Maxim never has knowledge at all about mount, pierside, or dome. It just takes frames and guides.

    In fact during imaging nothing is connected to mount or dome except the ACP client which controls all. Occasionally during engineering for easy pointing to objects using graphical click I connect The Sky X to mount but through the ACP hub. In that case ACP sees where TSX wants to go and moves the dome accordingly.

  4. Tim Long

    @George Silvis: @ron crouch's reply is correct, dome slaving is an application level concern and neither the ASCOM Dome driver nor the firmware has any visibility of what the telescope is doing. ASCOM drivers are forbidden from communicating with other drivers, so things like dome slaving are done up at the application level (or, possibly, by a middle-ware application such as POTH or ASCOM Dome Control Panel). MaxIm DL and ACP both have their own dome slaving logic, as does TheSky X although some apps manage it better than others.

    So this is really a non-issue as far as the ASCOM driver is concerned and is most likely a MaxIm idiosyncrasy. On that basis, it’s not a valid issue so I’m closing it as ‘invalid’ just because it doesn’t really fit under any other heading. I am very grateful for the feedback though!

    If you wish to discuss this further then I'd be happy to meet you on the ASCOM-Talk group or similar.

  5. Log in to comment