I know a lot of folks have been having issues getting meridian flip to work with EQMOD, and after following all the advice I’m still having a problem when selecting the option to flip early. The situation starts when SGP tells me that the time to flip is less than the next exposure length so it waits until it is time for the flip. After some time it gives me the option flip now instead of waiting the rest of the time. On two occasions that I’ve done it this way it fails. Looking at the log is a bit confusing to me because if I am reading it correctly, the log says that the slew command was given and that the scope reported it was complete and that the flip was completed, but then immediately afterwards it says that it failed. The scope did not actually do the flip. I just waited until the object was across the meridian and resumed the sequence and it slewed to the object correctly and finished. Keep in mind that I had made a successful flip earlier in the evening but I just let it run and didn’t get or accept the option to do it early. I’m running SGP version 2.4.3.12, EQMOD 1.28m, Side of Pier option is set to ‘Pointing’, User Interface is ‘Dialog based’ and I have EQMOD’s auto meridian flip option turned ‘off’ (this is on the mount limits editor screen). I’m not sure what is going on. Below are the links to my log and sequence file.
EQMOD rejects syncs on the wrong side of the meridian and erases any offsets from previous syncs. The problem arises when your initial ‘home’ RA position is a little out. When the pointing adjustment is erased the mount position can revert to a position on the same side of the meridian. Then when SGP issues a slew command it doesn’t result in a flip.
From your log:
[11/23/2015 6:49:10 PM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 22.2505492429533 Dec: 49.8862686799699
…
[11/23/2015 6:49:12 PM] [DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 22.2938054174085 Dec: 50.9447074468085
Note the difference in RA values
@Ken - We should add this to the EQMOD help section. I suspect it is the reason for the lion’s share of failed EQMOD pier flips. I would be happy to draft something up if you like.
Hi Ross,
I have had a similar issue when flipping within one degree of the meridian and have not tracked down the exact cause.
However, the solution is to allow the mount to move well past the meridian before the flip. That is why I recommended the flip at least 2 deg past the meridian. When the option to manually flip occurs, I ignore it.
I assume the failed flip when very close to the meridian is caused by slight pointing errors or rounding errors or perhaps by alignment errors per Paul’s suggestion. In field testing, on my mount flips at less than 1 deg sometimes worked and sometimes not. At 2 deg flip has been very robust.
Paul,
Thanks for that explanation. I should have specified that the particular flip I had an issue with began at 9:29:27PM in the log. In the part of the log you referred to, that flip actually worked.
Scott,
I have the value ‘2’ in the meridan flip options box for how far past meridian to flip, bu I’m not sure if it is minutes or degrees. The label says minutes, but the tool-tip says degrees. If it is indeed minutes then I need to increase it 8, correct?
If I understand this correctly what is happening is that the pier flip is attempted but the mount does not do it. It stays in the original pointing state. SGP reports this as an error and gives up.
SGP’s method of doing the pier flip at a defined hour angle will be vulnerable to this because the destination pointing state does not depend on the hour angle, it’s a function of the mount model. Even with a mount that’s expected to flip at an hour angle of zero there can be small differences amounting to a few minutes.
There are a couple of ways to get round this:
ASCOM provides a DestinationSideOfPier(double rightAscension, double declination) method. This reports the pointing state that a slew to the defined position at this time will use. As the mount tracks past the meridian the DestinationSideOfPier (DSOP) for the current position will initially report pierWest but when a slew would do the pier flip it will change to reporting pierEast.
SGP could monitor the DSOP and when it reports the flip can be done it does it. No need to rely on the user setting a good value for the hour angle, rely on the mount to say what it will do.
Not all mounts implement DSOP. For these an hour angle based slew is the only option, however if the flip fails - as shown by the pointing state not changing - SGP could try again at the next opportunity.
I use 2 deg past meridian. I think more recent versions of SGP use minutes as the unit of measure, so 8 min is correct.
Note that I chose 2 deg, because I ran into mount clashes if I went more than about 3 deg and I wanted to leave some margin. Luckily 2 deg was enough to ensure flips worked reliably.
Chris,
When I experienced flip fails with the flip happening say at 1 deg or less past meridian, the mount sometimes would sync, flip, plate solve in new position and then straight flip back again! Sometimes it would not flip at all, sometimes it would work perfectly. This was all rectified by making sure the flip was at least 2 deg past meridian.
Slewing back and forth when close to the flip position will be because each plate solve and sync could change the mount model and so change the pointing state a slew will use.
That rather undermines my suggestion of using DestinationSideOfPier because it looks as if it’s worth waiting a bit after the destination state changes but maybe the state change plus an hour angle offset would be better than just an off set from the meridian.
These offsets can be expressed in time or degrees, it’s just a matter of multiplying or dividing by 4.
I’ve taken a look at the code and EQMOD will currently zero its sync offsets if the sync offset (encoder based) is ridiculously “large”. This is intended as a sanity check and to put everything back to the startup state if “bad” syncs occur. I could easilly change this to retain the previous sync offsets rather than zeroing them - in fact the code to do this is already in there but has been commented out for some reason - which makes me a little nervous about a change as someone obviously thought better of it previously.
Also I note that EQMOD currently doesn’t raise any exception error when syncs are rejected for this reason but I could probably change that also - then at least SGP would know that a sync had failed, though what it would do about it I don’t know.
Making these changes might tighten things up a bit but I think having SGP avoid syncs altogether when close to the meridian would still represent best practice.
[quote=“Chris_Shillito, post:11, topic:2612”]
Also I note that EQMOD currently doesn’t raise any exception error when syncs are rejected for this reason but I could probably change that also - then at least SGP would know that a sync had failed, though what it would do about it I don’t know.
[/quote]I don’t recommend this, SGP will, I believe, detect the error and give up.
[quote=“Chris_Shillito, post:11, topic:2612”]
Making these changes might tighten things up a bit but I think having SGP avoid syncs altogether when close to the meridian would still represent best practice.
[/quote]I’ve tried to persuade Ken and Jared not to do a sync just before the meridian flip slew but to no avail. As you know it doesn’t help and can make the task of pointing after the slew harder.
If you can’t get data that you can use to modify your pointing model safely then silently doing nothing seems the least worst option. Hopefully that will prevent the situation where the mount turns out not to have tracked past the meridian.
SGP developers really do need to give some serious consideration to your advice on this. Drivers have every right to reject syncs (or any other method) and the usual ASCOM way to signal such a rejection is via an exception. At some point SGP may well come up against a driver that does raise an exception to near/past meridian syncs and presumably at that point SGP developers will be forced to work around it.
For the moment I’m happy for EQMOD to silently ignore any syncs it regards as erroneous. Of course if in future some other application complains about this behaviour, or if those those ASCOM cops catch up with me, I may be forced into a change of mind. So SGP developers, cover this possibility now and just stop synching before flipping!.
We’ve added checking “CanSync” for all syncs going forward. Really this has nothing to do with meridian flips. Just that the position of the scope at a meridian flip helps to exacerbate the issue.
Syncs can be invoked lots of places within SGP. A user could manually invoke a Solve and Sync, Center Here, or Auto Center at a location that could cause this same issue.
So adding the CanSync check should solve this provided that the driver implements this correctly. We don’t really want to (and shouldn’t be expected to) add hardware specific checks into SGP. Some mounts are just fine to sync across the meridian (like my Gemini on my G11) other mounts cannot. Using CanSync should solve both cases.
[quote=“Jared, post:14, topic:2612”]
We’ve added checking “CanSync” for all syncs going forward. Really this has nothing to do with meridian flips. Just that the position of the scope at a meridian flip helps to exacerbate the issue.
[/quote]You should really catch ASCOM.InvalidOperationException instead. That’s the exception that is specified to be thrown when the current state of the hardware prevents an operation. The Can* properties are intended to provide a generic indication that an operation can be done so an application can set up its UI appropriately.
It hadn’t occurred to me that you were using the generic acquire image, solve, sync, slew to target process to do the pier flip,
I agree. The CanSync property only provides confirmation that a driver has general syncing capabilities. Whether a driver with sync capabilities then chooses to reject a sync at a given moment in time, for a given set of coordinates/mount position etc. can only be determined by catching exceptions raised when performing the ASCOM sync methods.
When dealing with ASCOM drivers application designers have to consider that fully ‘compliant’ support of an ASCOM method includes right to raise an exception in order to reject the service request. Adjusting the control strategy in response to exceptions is an inherent part of ASCOM applicaiton design. So whilst you shouldn’t be expected to write hardware specific checks- you do need to perform ASCOM specific checks (which are just abstracted haedware checks).
No disagreement there. We’re also adding additional exception handling around this as well. That comment was more directed at:
This is specific to the EQMOD driver (maybe others?) and we have no way of knowing if it will break prior to issuing the sync. So we’ll check CanSync and also handle exceptions. I’m not sure what else can be expected of us.
We aren’t. We do use it for the validation side. To complicate things more there are actually 2 paths for meridian flips. One where slew is used and another where SideOfPier is used. I was merely stating that this issue can easily happen outside of a meridian flip. One way, for instance:
Slew to meridian
Wait a minute while tracking
Invoke “Solve and Sync”
Same issue…
The same could happen if you did steps 1 and 2, then invoked Center Here or Auto Center. Pretty much anything that dose a sync. So Meridain Flips aren’t so special it just so happens that you can almost guarantee that they put the mount into the exact perfect position to cause this.
[quote=“Jared, post:17, topic:2612”]
The same could happen if you did steps 1 and 2, then invoked Center Here or Auto Center. Pretty much anything that dose a sync. So Meridain Flips aren’t so special it just so happens that you can almost guarantee that they put the mount into the exact perfect position to cause this.
[/quote]I wasn’t aware there was a specific slew to meridian option. Do you mean the generic slew and centre operation? If so then a slew to a random position, wait a minute then solve and sync will only hit the problem for one minute in 12 hours - a one in 720 chance.
On the other hand for flip a sync that fails when the mount has tracked past the meridian will fail 100% of the time. Using a 1:720 chance as a reason to do nothing about a certainty seems strange to me.
Not doing the sync just before the meridian flip will resolve this. This sync achieves nothing because sync can only be relied on to make pointing better close to the sync position. Another solve and sync is done immediately afterwards.
It’s still a good idea to trap the InvalidOperationException on the other syncs of course. I’m not sure this need be fatal.
I really can’t speak for other equatorial mount drivers but for EQMOD at least the meridian represents something of a discontinuity - perhaps that is bad coding/structur on our behalf, but after 8 years of layering functions on top of it I can’t see it changing now. So for EQMOD I would say syncs very close to, and certainly beyond, the meridian are best avoided.
As it currently stands EQMOD is purposely ignoring syncs that break its pointing model but has to do this silently so as not to cause problems for apps like SGP. If a future SGP will trap sync exceptions then once it is available I will happily change EQMOD to raise them. That way SGP can take full control/responsibility for what ever happens subsequently. I would imagine that so long as a failed sync doesn’t inhibit a flip folks will get by just fine.
Would giving SGP users an advanced option to restrict the areas of the sky in which syncs are performed be such a bad thing? As I understand it SGP offers control/automation over where and when so many other operations take place - would it be a big stretch to extend this to platesolves, syncs and gotos? Do that and SGP users/customers get a generic workaround that might just avoid some of these driver issues at source rather than SGP having to deal with the consequences of them through exception handling.
The next beta of SGPro will not redesign the workflow for flips or centering, but I did add code to trap InvalidOperationException and return success on this specific exception (meaning whatever operation was dependent on it will not fail). This behavior essentially mimics the behavior seen when !telescope.CanSync is encountered… we still return success so the dependent process can continue.
In short, if a telescope reports that it can sync and then throws an InvalidOperationException, we will assume the driver is protecting itself and return success. Any other type of exception will report failure and the dependent process will likely fail.
Note, that this applies only to flipping and centering. If the user’s action is specifically to Solve and Sync (and nothing else) and ANY exception is thrown, we will still consider that a failure.
So… @Chris_Shillito, if you’d like, feel free to throw that exception when the mount is in a compromising position. SGPro will not abort the underlying process because of it.
This is probably best left to the implementing drivers. I am also very “anti-option”.
it just so happens that you can almost guarantee that they put the mount into the exact perfect position to cause this.
it just so happens that you can almost guarantee that they put the mount into the exact perfect position to cause this.