Indeed, alignment succeeds, and it remains find when then the focus routine kicks in at 02:19:49.757. Focusing takes a while, needs some separate investigation, but it completes at 02:31:16.453. This is part of the post-MF activities.

What I do not understand is the event at 02:23:31.679, when the new meridian flip is planned for RA = "03h 23m 39s" (The RA position for the MF that just completed was 23h 24m 25s). And there is no entry indicating a slew during the focus routine. Remember, we are still in the post-MF procedure, focus running.

Any ideas?

That's why I meant that you should try to make a dry run with your mount connected, but using the CCD Simulator and no alignment and no focusing.

So it looks like a number of odd things
1) the focus after flip was not focusing on the CURRENT filter of the sequence - it went back to HA which was already complete - does focus now ONLY use the filter selected inthe tab and not in the sequence file?
[2021-08-31T02:18:20.309 EDT INFO ][ org.kde.kstars.ekos.align] - "Changing filter to HA..."
[2021-08-31T02:18:20.312 EDT INFO ][ org.kde.kstars.indi] - ASI EFW : "[INFO] Setting current filter to slot 5 "
[2021-08-31T02:18:20.820 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Scheduler iteration never set up.
[2021-08-31T02:18:21.773 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Scheduler iteration never set up.
[2021-08-31T02:18:22.311 EDT INFO ][ org.kde.kstars.ekos.focus] - "Focusing inward by 50 steps..."

2) I have positive confirmation that the flip coordinates worked long with align as the image AFTER focus was perfectly placed (and inverted as expected) to a point between the Bubble and M52 - [2021-08-31T02:16:17.718 EDT INFO ][ org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "23h 23m 39s" DEC= " 61° 29' 18\"" Hour Angle "00h 00m 48s" - so west facing east and east facing west DID capture that point

3)[2021-08-31T02:23:31.679 EDT DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "23h 42m 53s" scope RA= "03h 23m 39s" ha= 8.32047 , meridian diff= 0.13 , hrstoFlip= -8.19047 , flipDelayHrs= 0 , "Pier Side: East (pointing West)"
[2021-08-31T02:23:31.680 EDT DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to "FLIP_PLANNED"

Yeah this is really odd - hours to flip -8.19??? - I think there was an input/replace of the target coordinates and that forces a bunch of calculations that result in incorrect values and eventually a crash - what for hours to flip with a negative even mean to other code - this indicates time travel ? - this spot in the sky is actually very close to where my session STARTED in the NE about 45 degrees up (to clear trees) and could easily be alone the same line as the bubble - since some of that info is coming from scheduler this gives me the feeling that a buffer has been overrun and we are now seeing another objects data (how many time have I done THAT in structs in c!)

Add to that those warning from align about not enough memory and I am suspecting this is a basic corruption

Day before this I used all the real scope during daytime to slew and flip but never died - and all the numbers looked good - I will try again but turn off logging to reduce IO and load - will see it completes

My big bugaboo here is why when in the middle of shooting OIII the sequence does not take priority of the tab...I could be in the middle of 5 filters and it should STAY on what it is using from sequence - perhaps this is a setting in the focus tab? or I need to NOT select a filter?...I dunno

Regarding the HA miracle: did you check your filter settings? Maybe you set HA as lock filter for focusing O-III...

A lot went wrong last night - some things went right but check this out:  an extremely short flip pending->flip operation and flip complete marked as the flip happens - GUIDING suspends then tries again constantly DURING the flip - I had logs reduced to specific modules and of course NO LOGS were written so I cannot even see what was happeing - but from the analyzer output and the hours of trailed (driven) images I and see that:
1) MF and Guiding are not listening to each other
2) MF is still being marked far too early - it is not complete and mount is still slewing - this means there is another place in the code that status is not being checked correctly
3) focus is failing which I think  is the reason align is failing (WAY out of focus)
4) after the flip Guiding goes NUTS and all images after the flip are captures of huge movements of the mount

So I really do not know where to go from here - I think if the FLIP propelry reports and Guide listens the cascade will not happen - and if focus worked , align would have also (as it id at the start of the session)
Park worked and KSTARS did not crash - since I have no logs I suspect the crash the night before is due to IO and logging

A lot went wrong last night - some things went right but check this out:  an extremely short flip pending->flip operation and flip complete marked as the flip happens - GUIDING suspends then tries again constantly DURING the flip - I had logs reduced to specific modules and of course NO LOGS were written so I cannot even see what was happeing - but from the analyzer output and the hours of trailed (driven) images I and see that:
1) MF and Guiding are not listening to each other
2) MF is still being marked far too early - it is not complete and mount is still slewing - this means there is another place in the code that status is not being checked correctly
3) focus is failing which I think  is the reason align is failing (WAY out of focus)
4) after the flip Guiding goes NUTS and all images after the flip are captures of huge movements of the mount

So I really do not know where to go from here - I think if the FLIP propelry reports and Guide listens the cascade will not happen - and if focus worked , align would have also (as it id at the start of the session)
Park worked and KSTARS did not crash - since I have no logs I suspect the crash the night before is due to IO and logging

  

This is the "successful" focus on OIII - whihc would be what ALIGN would be seeing so no wonder it failed - that is a good failure

and this is AFTER the flip and how guiding was operating - something VERY not right as I am guiding via guide scope and NOT through this camera - guide scope was fine and stars sharp 

I JUST had a thought - this guide behavior can 100% be seen IF the guide module is no longer listening to its OWN flip dec - as I have "save and reuse" calibration enabled and have checked the flip DEC if on other side of meridian flip enabled, if those are no longer working the mount would be driving itself out of position on every guide

Since all the guide module here looks new, can I suspect that some old function no longer applies and I must FORCE a recalibration after meridian flip?

I JUST had a thought - this guide behavior can 100% be seen IF the guide module is no longer listening to its OWN flip dec - as I have "save and reuse" calibration enabled and have checked the flip DEC if on other side of meridian flip enabled, if those are no longer working the mount would be driving itself out of position on every guide

Since all the guide module here looks new, can I suspect that some old function no longer applies and I must FORCE a recalibration after meridian flip?
 

Found the reason for focus problem - NOT SW...good old cold weather and slippage - so the pattern now becomes clearer for me and I do see a lack of communication between layers

1) focus is bad - due to known reasons
2) MF happens - marks complete
3) align knows full slew is done - this is good - align starts after full term MF has occurred
4) align FAILS due to #1 - no way it could align
5) HERE is what I think is the problem - at this point all guiding goes to hell because I believe it does not know it is now flipped since we failed ALIGN....so it is using the stored calibration without swapping DEC!!!!

so it is a cascade that (once I get another test with logs on) I should be able to prove - and solve by setting abort schedule on focus fail or align fail - yikes! -

can anyone confirm if ALIGN after flip fails, will GUIDE still decide to swap DEC as it is on the other side of the mount? - Thanks

Hi Jamie,

I’ve been following the FLIP topic, which I’m very interested in, but I have a couple of things.

1.  Does the arrangement you made of INDI-OnStep works on OnStep frimware version 2.2.xx?
2.  If I don’t have autofocus, the thing will work for the discusion that you have had and I’ve been able to interpret from all the advances you’ve made, right?
3.  And, is the modification already uploaded so that you can install it and test it (in any platform: PC/Astroberry/ ...)?

Thank you all very much for your answers and your huge job.
Pep

Regarding OnStep 2.2, it is quite ancient now.
I really recommend that you upgrade to 4.24.

The fixes in this thread are already in Jasem's PPA repository packages. So if Astroberry points to this repo, you should get them when you upgrade.

Hi Khalid,
Thanks for you quick answer.
I know it may not be the place but, to update the firmware: what file should I not touch and/or save it, to just update and not modify the current settings I have?
Pep