Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

In D18235#396579, @mutlaqja wrote:

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

Could you please be more specific when it happens? When I test it with the mount simulator, no meridian flip happens.

In D18235#396659, @wreissenberger wrote:

In D18235#396579, @mutlaqja wrote:

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

Could you please be more specific when it happens? When I test it with the mount simulator, no meridian flip happens.

Nothing. I wasn't even testing this. The mount was parked so I started a 2-image capture process and it said it wants to do a meridian flip! Of course it failed several times in a row while I was simply trying to capture a couple of images in the sequence. The check for meridian flip should never be made when the mount is parked.

I also don't think meridian flip should be done when the mount is NOT tracking.

OK, I could reproduce the case. The problems occur when tracking is stopped while Mount is in the state FLIP_WAITING. In this case, things get out of order.

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

In D18235#398264, @mutlaqja wrote:

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

I had it running during the lunar eclipse on Monday and it ran fine. So for normal operations, it should be stable enough to test it in reality.

The changes for non tracking, parked/parking etc. are not that stable yet and are slightly tricky. It's not only about adding one or two checks. Since I currently work only in the evening and on weekends on it, I cannot promise it.

In D18235#398264, @mutlaqja wrote:

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

OK, please use the latest update. Now the meridian flip only happens when the mount is tracking.

There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?
Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long. This situation could be pre-planned by Scheduler.
I'm sorry, I couldn't test all this. But this seems really good.

In D18235#398781, @TallFurryMan wrote:

There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?

No, we don't. If we stop tracking, the meridian flip state is set back to "none" and nothing happens. As soon as we turn on tracking, a new target position is set. When this target position crosses the meridian, a flip is requested and executed.

Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long.

Nope, that’s why I introduced the request-accept mechanism. The mount requests to execute a flip, as soon as the meridian has been crossed by the given distance. If a capture is ongoing, capture answers with „wait“. As soon as the capture is completed, capture interrupts the sequence and sends an „accept“ to mount. Now mount executes the flip. As soon as the flip is completed, capture continues.

This is nothing new, this behaviour did not change. What changed is that the meridian flip is executed by mount and no longer by capture. The advantage is, that a meridian flip will be executed even if no capture takes place. This is especially important, if a capture sequence is interrupted by clouds. In the past, this prevented a meridian flip. Now, the meridian flip takes place as soon as the meridian has been crossed - no matter whether capturing takes place or not.

This situation could be pre-planned by Scheduler.
I'm sorry, I couldn't test all this. But this seems really good.

Good point. Personally, I would like to shift the meridian flip parameters from capture to the scheduler. But let's come back to this point as soon as we have this diff stable.

Cristal clear, thanks.

Can you please rebase again? I can't apply the patch now to test.

In D18235#400029, @mutlaqja wrote:

Can you please rebase again? I can't apply the patch now to test.

work in progress, hope to complete it today

mount.cpp and mount.ui still fail to patch :(

meridianFlipTimeBox is not in the ui file. Also, please don't use C-style casts (int), use static_cast<int>(...)

Thanks, it was applied cleanly now. I had a brief window to test but then clouds rolled in :(

Is the Meridian control in the mount tab synchronized with the one in the capture type? It seems when I activated (checked) the meridian control in capture, nothing happen to the control in the mount tab.

In D18235#400606, @mutlaqja wrote:

Is the Meridian control in the mount tab synchronized with the one in the capture type? It seems when I activated (checked) the meridian control in capture, nothing happen to the control in the mount tab.

Not yet to the full extend. Currently it is only propagated from Capture to Mount when a sequence file is loaded.

I haven't thought it entirely through what is the best way to keep these parameters in sync. Maybe synching it while loading the sequence file is not be the best place. Would it make more sense to propagate the value when the imaging sequence is started?

Right, maybe if an imaging sequence is started, it should override whatever value in the mount module AND disable the edit in the mount module entirely as long as the sequence is active. This would prevent uses from changing it in mount by mistake while imaging is still active.

Thanks I just tested this in my observatory. The flip was started, but it got stuck on post-flip alignment. The alignment actually finished OK, but it seems no signal was sent to capture module regarding this. Please check.

D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?

In D18235#402892, @TallFurryMan wrote:

D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?

Hm, I did not implement a timeout at all, a slew may take as long as it takes. Do we really need such a timeout that checks, whether the meridian flip slew has completed?

Therefore, my implementation makes this change D18627 obsolete. On the other hand, it depends, how long we need to get the new implementation mature enough for distribution.

In D18235#402892 https://phabricator.kde.org/D18235#402892,
@TallFurryMan https://phabricator.kde.org/p/TallFurryMan/ wrote:

D18627 <https://phabricator.kde.org/D18627> requires attention. Is
it compatible/complementary/unnecessary with this diff?

Hm, I did not implement a timeout at all, a slew may take as long as
it takes. Do we really need such a timeout that checks, whether the
meridian flip slew has completed?

Therefore, my implementation makes this change D18627
https://phabricator.kde.org/D18627 obsolete. On the other hand, it
depends, how long we need to get the new implementation mature enough
for distribution.

I believe yes, this change makes it non necessary. No Timeout, no need
to adjust it :-)

View Revision https://phabricator.kde.org/D18235
wreissenberger edited the summary of this revision. (Show Details)
https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-vg656fdldlbpink/

*CHANGES TO REVISION SUMMARY*
...
If capturing is not running, the meridian flip is started immediately.
...

I just checked the changes and confirm it is running as expected (tests
1 to 4)

I noticed that the capture.ui still contains "Meridian Flip if HA" input
field and interfers with the field in the mount tab when capture
sequence is started.

In D18235#403009, @alainz wrote:

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

In D18235#403062, @wreissenberger wrote:

In D18235#403009, @alainz wrote:

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

I will do more intensive testing,, I would like to make sure each test is reproducible.
Will ceme back to you in any case.

In D18235#403130, @alainz wrote:

In D18235#403062, @wreissenberger wrote:

In D18235#403009, @alainz wrote:

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

I will do more intensive testing,, I would like to make sure each test is reproducible.
Will come back to you in any case.

I did run all tests again and found no issue, Must say all the test were done in simulation, it's raining in France :-(

Selecting checkbox in the Capture tab alone is not sufficient, the Mount Tab checkbox must be selected too, Right?

The fact that we have two places whith meridian cflip checkbox and setpoint is a bit confusing to me and will probably raise many questions by other users later on, but this is a cosmetic thing, the code works!

I did not see the meridian flip beeing forwarded from capture to mount tab, I still had one value in capture tab and another in mount tab, and the value in mount tab is the one that triggered the flip. Is my interpretation correct?

In D18235#403245, @alainz wrote:

Selecting checkbox in the Capture tab alone is not sufficient, the Mount Tab checkbox must be selected too, Right?

At the end, the values on the Mount tab count. But when you start an imaging session from the Capture tab, the values from the Capture tab are forwarded to the Mount tab and overwrite the settings there.

The fact that we have two places whith meridian cflip checkbox and setpoint is a bit confusing to me and will probably raise many questions by other users later on, but this is a cosmetic thing, the code works!

Agreed. I would prefer shifting it from the Capture tab to the Scheduler tab, since the Scheduler contains data of other tabs as well. But I do not want to make the steps too big.

I did not see the meridian flip beeing forwarded from capture to mount tab, I still had one value in capture tab and another in mount tab, and the value in mount tab is the one that triggered the flip. Is my interpretation correct?

The value from the Capture tab is not forwarded immediately when changing the values on the Capture tab but they change, when you press the "Start" button on the Capture tab.

Le 01/02/2019 à 18:02, Wolfgang Reissenberger a écrit :

View Revision https://phabricator.kde.org/D18235
wreissenberger added a comment.

In D18235#403245 <https://phabricator.kde.org/D18235#403245>,
@alainz <https://phabricator.kde.org/p/alainz/> wrote:

Selecting checkbox in the Capture tab alone is not sufficient, the
Mount Tab checkbox must be selected too, Right?

At the end, the values on the Mount tab count. But when you start an
imaging session from the Capture tab, the values from the Capture tab
are forwarded to the Mount tab and overwrite the settings there.

I see!

The fact that we have two places whith meridian cflip checkbox and
setpoint is a bit confusing to me and will probably raise many
questions by other users later on, but this is a cosmetic thing,
the code works!

Agreed. I would prefer shifting it from the Capture tab to the
Scheduler tab, since the Scheduler contains data of other tabs as
well. But I do not want to make the steps too big.

I did not see the meridian flip beeing forwarded from capture to
mount tab, I still had one value in capture tab and another in
mount tab, and the value in mount tab is the one that triggered
the flip. Is my interpretation correct?

The value from the Capture tab is not forwarded immediately when
changing the values on the Capture tab but they change, when you press
the "Start" button on the Capture tab.

This was what I expected but id doesn't happen, I have to test again!

Anyhow, good job!

*REPOSITORY*
R321 KStars

*REVISION DETAIL*
https://phabricator.kde.org/D18235

*To: *wreissenberger, mutlaqja, TallFurryMan, alainz
*Cc: *kde-edu, narvaez, apol

I tested again the value forward from Capture tab to Mount Tab,
it works as you said.

Anyone else has comments/issues with this PR?

Congratulations to all of you, this really is an improvement to the platform.