×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Meridian flip interrupted on EQMOD mount - Alignment Module?

  • Posts: 85
  • Thank you received: 19
Today I recreated a dummy run without the Alignment and Guide Steps checked. Here's an abbreviated log of what happened:

[2019-12-03T11:50:26.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:50:26.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:50:27.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "16h 36m 39s" scope RA= "16h 33m 38s" and meridian diff= 0.05
[2019-12-03T11:50:27.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 1
[2019-12-03T11:50:27.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:50:27.835 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

[...]

[2019-12-03T11:51:12.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:12.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.599 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Image Received"
[2019-12-03T11:51:13.600 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "Searching in path '/home/astroberry/netdrive/photos/Capture/M107/Light', files 'MeridianTest_Light*' for prefix 'MeridianTest_Light'..."
[2019-12-03T11:51:13.688 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_001'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_002'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_003'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Frame map summary:
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "/home/astroberry/netdrive/photos/Capture/M107/Light/MeridianTest_Light" : 3
[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2019-12-03T11:51:15.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:15.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

So here it has started the meridian flip.
[...]
And a little over a minute later it completes the flip:

[2019-12-03T11:52:37.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:37.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-03T11:52:38.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:38.836 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:38.853 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2019-12-03T11:52:38.854 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Idle"

So this is interesting, and I don't know if this happened or not on my previous dummy run, but it attempts to align when the Align step isn't actually checked:

[2019-12-03T11:52:38.854 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2019-12-03T11:52:39.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 0
[2019-12-03T11:52:39.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:39.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:40.349 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:52:40.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:40.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:41.672 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:52:41.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:41.838 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

[...]
Naturally it fails:

[2019-12-03T11:53:04.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:04.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:04.976 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Failed"
[2019-12-03T11:53:04.976 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2019-12-03T11:53:05.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:05.836 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:06.469 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:53:06.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:06.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:07.744 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:53:07.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:07.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:08.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:08.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:09.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:09.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:10.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:10.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:11.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:11.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:12.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:12.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:13.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:13.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:14.790 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Aborted"

And I finally aborted it.
4 years 3 months ago #46526

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 0
I can't help with the log files, but I have had similar behavior from my EQ6-R Pro with it starting to flip and then just stopping. A subsequent GoTo command put it on target on the wrong side of the pier.

So, after reading some other forum posts, I now have the meridian flip set to trigger at + 0.2 hours instead of the default of 0. At that hour angle, the mount has no doubt that it is past the meridian, so it completes the flip.

Tim
4 years 3 months ago #46527

Please Log in or Create an account to join the conversation.

  • Posts: 85
  • Thank you received: 19
Thanks Tim, I'll give that a try.

One thing that vaguely concerns me though is that Ekos' (or INDI's) idea of where the meridian is doesn't quite match up with the sky itself: it's quite evident that the mount itself has passed the meridian some time before the software thinks it has. Time and again I can tell KStars to go to an object that is just west of the meridian only for the mount to slew to it with the head still on the west side, including occasions in which it has slewed from an object even further west when the head was on the east side. So given this behaviour, plus the 0.2h trigger point past the meridian plus the delay to complete a capture, I'm concerned it could get kind of hairy for high elevation targets.
4 years 3 months ago #46542

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
There is nothing wrong with the meridian in KStars. Many mounts have a limit (usually expressed in degrees) up to which it will keep the telescope on the east side while the object already is west of the meridian. Please check that value for your mount using the hand controller. That probably explains the behaviour you see.


Wouter
4 years 3 months ago #46546

Please Log in or Create an account to join the conversation.

  • Posts: 85
  • Thank you received: 19
Sorry, which behaviour are you referring to?

The one I described in my last post of the mount head slewing to the west side for a just-west-of-meridian object?

Or the behaviour I described in my initial post whereby a dummy run successfully meridian flips but a night time run with a guide camera in the mix gets interrupted seconds after the flip starts?
4 years 3 months ago #46568

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
I was referring to the first one (describing the mount head slewing to the west side for a just-west-of-meridian object) though perhaps the second one might be a symptom of this as well.
4 years 3 months ago #46571

Please Log in or Create an account to join the conversation.

  • Posts: 85
  • Thank you received: 19
I've read through the Synscan manual - the only reference to meridian flipping is with respect to whether it's auto or, for the next goto movement only, forced or disabled. As far as I'm aware, the EQ6 doesn't have mount limits at all. Left to its own, it will eventually strike the tripod through normal tracking.


At any rate, none of this particularly explains the behaviour that far more concerns me, the interruption of a just-started meridian flip when there's a guide camera attached. Is it perhaps because I'm using the guide camera for both alignment and guiding, so when the guiding gets turned off by the meridian flip it's available to take an image for alignment? I would guess that under most use cases one would preferentially use the main imaging camera for alignment?

I still have to investigate Tim's suggestion of increasing the meridian offset but even if does that does seem like a workaround given that it *does* work with a minimal offset when there is no guide camera attached.
4 years 3 months ago #46578

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
So I think you are misunderstanding something about the meridian flip. Mounts generally do not really have concept of a meridian flip, and they will not do it automatically, nor can they be told to do one using a simple command. Software like Ekos can use the mount's features to effectively perform a meridian flip, but you need to know how it works to use it effectively.

Two key points:
1. Most telescope mounts will go to an object and then when you tell them to track the object, they keep tracking and tracking and tracking until either the telescope limit is reached or it hits the tripod legs.
2. Most telescope mounts, when told to go to an object will make the telescope orient itself in on whichever side of the pier makes the most sense (Note: the most sense in the mount's mind, not always in your mind). You cannot tell most mounts which side of the pier to orient themselves on.

So to make pier flips happen, typically what will happen is the software will wait till an object crosses the meridian (or goes an angular distance past the meridian that you decide), and then it will issue a goto command to the object (even though it is already pointing at that object). If the mount thinks that it would make more sense to go to the object on the other side of the pier since it is past the meridian (which is what you are hoping), then the meridian flip will happen when the goto command is issued. If the object is really close to the line though, the mount may not actually do the meridian flip, because it decided the scope was able to point at this object on its current side of the pier.

Now there could still be a bug, since I think there are some people currently working on the code for alignment, guiding, and meridian flips. But from your discussion I don't think you understood how it was supposed to work.

Hopefully this helps,

Thanks,

Rob
4 years 3 months ago #46579

Please Log in or Create an account to join the conversation.

  • Posts: 85
  • Thank you received: 19
Here again is what is - and is not - happening with emphasis on the differences between two scenarios where flips do and do not occur. It's all been nicely colour-coded to aid in following along. You can pretend I'm a dimwitted idiot who shouldn't be anywhere near an equatorial mount at all if it makes you feel better about being dismissive, but that still doesn't change what the logs say.


Scenario 1:
Live EQMOD mount, simulated camera, no guide camera real or simulated. Accordingly, in the Schedule tab, the 'Align' and 'Guide' boxes are UNCHECKED. Meridian flip set to >0.05h

When I set up a schedule that involves a meridian flip with this scenario and run it, the mount successfully carries out a meridian flip, as expected.

So, under this circumstance, I am able to get the mount to flip.

Fwiw, these dummy runs were carried out during the day, but I see no reason it wouldn't work under clear night skies either. I could test that out too on the next clear night.

Scenario 2:
Live EQMOD mount, simulated camera, live ZWO ASI guide camera on a real guidescope. So, in the Schedule tab, the 'Align' and 'Guide' boxes are now CHECKED. Meridian flip is set to >0.05h

As there is no live camera, alignment is being carried out by the guide camera on the guidescope. This run is also being carried out under clear night skies, so Ekos goes through an alignment routine after the mount has been aimed at the target.

When I set up a schedule that involves a meridian flip with this scenario and run it at night under clear skies, here's what happens:
-the mount is moved to the target, with the mount head on the west side
-once on target Ekos goes through an alignment routine to centre the target
-once the alignment routine is satisfied that the target is centred, a guide calibration is initiated
-once the guide calibration is successful, the guiding begins
-once guiding begins, the capture sequences are initiated
-at this point, on the Mount tab, I can see a count down to the meridian flip
-once the meridian flip countdown gets to 0, it goes into a waiting stage while the current capture finishes
-once the current capture finishes, a meridian flip *IS INITIATED*
-but almost instantly the meridian flip is INTERRUPTED or stopped
-Ekos then proceeds to carry out an alignment using and recentres back on the target
-on the Mount tab the meridian flip status is now Inactive


So just so we're clear, with a live mount and a live guide camera on the guidescope and the guide camera serving as the alignment device, with 'Align' and 'Guide' checked in the Schedule tab, under clear night skies, a meridian flip is initiated and then almost instantly stopped. That's in contrast to when it did fully carry out a flip when there was no guide camera set in the profile and the 'Align' and 'Guide' steps were unchecked in the Schedule tab.

And you can see for yourself in the logs I've attached. In my first post, i.e. 'Scenario 2':

[2019-12-02T21:19:22.226 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-02T21:19:22.232 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "01h 58m 47s" DEC= " 37° 55' 49\""
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-02T21:19:22.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:22.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-02T21:19:25.877 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:25.879 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-02T21:19:25.923 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3

That's 3 seconds.

Now take a look at the log from my second post, where it does carry out the flip fully, i.e. 'Scenario 1':

[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5

That's a minute and twenty four seconds (1:24), i.e. the time it took for the mount to flip.


So, quite frankly, whether or not I understand how a meridian flip is supposed to work is a moot point given that under both scenarios the flip is initiated. It's just that it will complete the flip under a limited scenario but won't under a slightly more involved scenario with more equipment attached. For some reason, the meridian flip is initiated but it is stopped in the scenario where the guide camera is attached and operating. It's repeatable - I've run both scenarios thrice and get the same results each time, so it's not a one-off fluke.

I'll run them again with logging of the INDI messages as well to see if that turns up any more useful information.
4 years 3 months ago #46587

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
Here's how I would interpret your log:

In the case where the meridian flip failed (ie took only 3 seconds),
when EKOS determined it was time for a meridian flip, it sent a slew command to the mount.
It was "hoping" the mount would switch to the other side of the pier (which normally takes a minute and a half) but the mount decided to
stay on the same side of the pier and only took a few seconds to finish its slew to a very nearby coordinate. That is, I believe it was probably
not interrupted, but rather it probably just finished quickly. Once the slew was complete the normal post-meridian-flip-slew alignment process started up.

To try and fix your situation, I'd try setting the meridian flip threshold to >0.1hour or maybe even a little more and seeing if you have more luck
(assuming that would be safe--e.g. the camera/telescope would not hit tripod, and so on). Going that much further past the meridian might
cause it to go to the other side of the pier.

If that doesn't work, or perhaps even before trying that, another, less likely possibility, is that your mount somehow has the wrong time, or geographic
coordinates, etc so that it doesn't have the same meridian in mind as your software. You can test that by commanding it to point to some star e.g. 15 degrees
east of the meridian, and another one 15 degrees west of the meridian and making sure picks the appropriate (different) side of the pier for both stars.
Make sure you have your finger near the stop-the-slew button just in case it really is off.

I've had (and solved) both of the above issues in the past 6 months! Moving to .1h definitely improved my meridian flips.

Hy

PS Please be civil, I'm certain Rob was genuinely trying to help you and not being dismissive.
4 years 3 months ago #46588

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
BTW, I checked, and I'm actually using "Flip if HA > 0.2h" for my Orion Atlas Pro mount.
Again, make sure your OTA/Camera can safely go this far past the meridian without hitting anything.
4 years 3 months ago #46589

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
It looks as if we've got all out of those logs that we can. As you say, in your Scenario 2 the meridian flip slew takes 3 seconds which is far too short. Either the slew is being commanded before the meridian has been reached from the mount's POV or something has stopped the slew.

Finding out what is going on from the mount side is vital so enabling the INDI logging should help. Set all the options, select log to file and look in ~/.indi/logs. The driver log will show something useful. Maybe something is stopping the slew early.

The ASCOM specifiction has to work round the same issues and in addition to the SideOfPier property has a DestinationSideOfPier(rightAscension, declination) method which reports the pier side that the mount will be on if a slew to the destination coordinates is started. This would give the client a chance to decide what is likely to work. When a plip is required the client checks the DestinationSideOfPier and only starts the meridian flip process when it is different to the current pier side.

With a mount that reports pier side, which eqmod does, Ekos should be able to check, see that the pier side is still West, and leave the pier side required flag set so it tries again after another acquire.
4 years 3 months ago #46593

Please Log in or Create an account to join the conversation.

Time to create page: 0.633 seconds