When I’m using the Astro Physics APPM program for making a pointing model - and have the model start near the Zenith as its first point - the dome does not move until the mount finishes moving to the Zenith. This causes an issue where the camera starts taking a picture before the dome has a chance to finish getting into position. I’ve spoken with Ray over at Astro Physics and the RA/Dec coordinates for the mount are sent as soon as I hit “Run” on the APPM program. Why isn’t SGP immediately moving the dome once the mount starts to move?
I’m guessing that SGP is using J2000 coordinates (which I imagine AP is using as well). Being as how this is math - and computers tend to be pretty good at math - the time to calculate that Azimuth position the dome needs to go to happens in a nanosecond? So why does the dome just sit there and not move almost immediately once it receives the RA/Dec info from APPM?
Is it the Nexdome driver that should be moving the dome physically and SGP just provides the Azimuth?
SGP will do “pre-emptive” slews when SGP issues the slew or when the slew comes from the API. If something else is issuing the slew then SGP has to react to it since the slew is done without our notification…what’s worse is that SGP doesn’t know where the slew was commanded to go (we just see RA/Dec changing) so we have to wait until the slew is complete and then we can move the dome accordingly. I’m assuming since APPM talks directly to the mount that it is issuing the slew without SGP’s knowledge.
To enable pre-emptive dome slews without scope slews we’d need to create something on the API side that would allow external applications to send us the coordinates for the slew but not actually do the slew in SGP. Or to allow this now the application could invoke the slew through SGP which would then handle the slaving correctly.
this is an interesting topic, I have a nexdome and a 10micron on order. 10micron uses model creator to build the model, from what I can tell it will use SGP for camera control and plate solving ,but will do its own mount control and dome slaving.
from what you describe I suspect APPM is talking to the dome ascom driver ? if so, you could minimize the dome polling time so it would react in the shortest possible time, consider increasing the dome rotation to max speed, or if APPM allows increase the settle time of the mount before taking the image for plate solving to give the dome time to catchup.
Actually the developer of the APPM model creator (Ray Gralak) gave me a new ver of APCC in which he did just that - increased the settle time to ensure the dome had a chance to get to where it needed to be.
Heres a quick vid showing the behavior of the dome while doing the modelling run. Its not ideal - but it works better than it did. I still don’t know why the dome can’t move in time with the mount?
I think Jared said it earlier - my experience is that if SGP initiates the slew - then the dome & mount slew at the same time. If the slew is initiated from outside SGP - then SGP waits to see where the mount settles then ‘intructs’ the dome to line up. Seems logical to me.
Just to add to my last post…since SGP is actually automatically ‘running the show’ all night i.e. initial slew to 1st target, any other slews to 2nd or 3rd target etc…then I never see the mount waiting on the dome to commence its slew…they are both always on the move together.
Presently I don’t think there is a way around the delay seen in your initial video …but do read again what Jared said in his second paragraph above.
I don’t require any modelling on my Takahashi mount - the plate solves (used on the slews and meridian flip) handle the positioning of the mount without problem and it is all handled from within SGP.
This is all to get a decent model so I can do 5 - 10 min unguided (or longer) imaging. Would save a bit of time if the scope/dome moved together when doing 200-300 pts.
Yes - I understand why it is a problem for you but do you need to do that model every night you are imaging? Surely not…but I don’t know, I have never had to do it.
I use a guide scope and, depending on the camera I use, do up to 20 or maybe even 30 minute subs without problem.
same as a few other things I can think of just now
I have sat up long enough …time to let SGP continue on its own for the rest of the night here in Spain. Good luck with sorting out your ‘problem’…maybe a feature request for SGP Ver. 4.0 ?
it seems that the solution is what jared said, or have ray improve the way appm informs the dome of what the mount is doing, so that appm works in the same way sgp does.
Since I built the hardware solution to automate the movement of my ProDome 10, I needed a hardware-specific solution, even though my design was largely based on the Lesvedome architecture. My solution is an application/driver combination. It pings the mount (Orion Atlas) via EQMOD or GS Server to get its’ current location and (this is important) whether or not it is slewing. My program can operate in two different modes: “Simultaneous” or “Sequential”. If in simultaneous mode, the dome simply follows the current location of the mount. More than that, it’s really tracking the scopes’ position relative to the domes’ shutter opening. If in sequential mode, the dome will not move while the scope reports it is slewing; it waits until the slew has completed. When the scope is in tracking mode, the program is just monitoring where the scope is pointing relative to the shutter and makes adjustments every few minutes to assure the scope has a view through the shutter. NOTE: the program has no idea where the mount is headed; it ONLY cares about where it currently IS.
So, why have two different tracking methods? In sequential mode, the dome can move faster than the mount. As a result, since the dome can only move at one speed, simultaneous mode causes a “stutter”-type motion, which is harder on the dome hardware. Sequential mode moves the dome only once during the slew, which is much easier on the hardware. And, of course, it moves periodically when the mount is in tracking mode.
Bottom line: yes, you can have the dome track simultaneously, but you may not like what you hear from the hardware. Simultaneous mode will get the dome where you want it quicker than sequential mode, but the difference is really measured in seconds.
Another note: as I said earlier, my program talks only to the mount and the dome hardware. To know ahead of time where the mount is GOING, it would have to also talk to the program that issues the slew command. That really complicates things.
Yes, this could also be an option in SGP but it would end up sending the dome to some potentially weird positions based on when the poll happened and what the scope was pointing. For may slews your scope is pointing below the horizon for some of the time (especially where meridian flips are concerned). Basically we’d need to change the current sync behavior to disregard that the mount was slewing and then you could decrease the polling amount to less than 60 seconds (like 5-10 or even less). Currently we will wait until the scope reports it has completed the slew before we attempt to slave it though.
What I would recommend for @GeneralT001 is to use the ASCOM Device Hub to slave in these situations as you can set the polling frequency pretty low and it is made to be more of a reactive slaving VS SGP that is more proactive. Basically taking SGP out of the equation for slaving when building models outside of SGP.
I use ascom device hub and since it’s connecting to the dome driver and the mount driver it seems it should be able to communicate one move to the other device? Still most of my moves are simultaneous between devices. But there are times the dome waits, or moves the opposite direction then stopped and reverses. I have never done a pointing model with APCC pro but I would like to.
You might try running device hub. Connect it to the mount and dome. Then in SGP connect to the device hub.dome and device hub.mount so that the device hub can share information between the two devices. Just a hunch.
