On Dec 29, 2020, at 16:14, Xentex <firstname.lastname@example.org> wrote:"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving. Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.
With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it. I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal". And then I started wondering what exactly is happening.The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.
So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.
Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.
This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.
Second question, how am I supposed to actually use the ReCal thing in APCC? For example, last night I wanted to center a particular star as part of an alignment routine. I used Stellarium to command the mount to the star. It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on. To my surprise, it wouldn't center. And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was. There was about an arcmin difference between them.You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.