For ASIAIR users that have seen issues regarding successful meridian flip execution to permit unattended operation with an Ioptron CEM40 or perhaps other CEM/GEM series mounts, I have been living with that problem for a while, only to see a rare moment of success from time to time...and that is an unexplained rarity.
Firstly, my current firmware and meridian handling settings:
ASIAIR v1.9.7, Ioptron CEM40 V210605 with 8407 HC V20210420
DST - Off
Mount - STOP at position limit of 5 degrees past the meridian
ASIAIR - Stop tracking 4 minutes prior to meridian, and perform AMF 5 minutes after meridian.
Having finally remembered to view my autorun.log file and look for issues there, it appears that the "Stop Tracking" meridian option setting in the ASIAR app is exactly for that....stop tracking. In the case of the Ioptron mounts this would appear to be essentially "stop communicating" so that further commands cannot be sent to the mount. The "gotcha" here is that it seems a few more commands are actually handled, such as slewing the mount to or close to the intended target position, but otherwise if you look at the hand controller or the Guide page of the app, you will see that the mount has in fact stopped tracking. Prior to the ASIAR commanding a "Stop Tracking", it also issues a Guide command of "Stop Guiding", which is correct...the ASIAIR is responsible for Guiding and does stop, by a transition into Looping.
However, the ASIAIR is not responsible for tracking...that is the mount's job, and should not be interfered with so that the mount can continue to track and move on through the meridian, leaving it active for the ASIAIR to perform plate solves, mount syncs, and auto-centers. The current problem in the ASIAIR firmware appears to be that both "Stop Guiding" and "Stop Tracking" commands are issued; if one watches the meridian timer countdown and the mount tracking status, then re-enables tracking from the hand controller upon seeing it disabled by the ASIAIR, then the autoflip session will proceed successfully. Having to manually intervene and perform that operation should not be required, but until ZWO can implement a fix, at least it is a simple step to perform. That is far easier than my typical solution of rebooting the ASIAIR, cycle mount power, and fight to get USB serial control of the mount re-established, which I've found usually requires a 2nd ASIAR reboot.
The attached image shows snips of the autorun.log file for an unsuccessful flip session alongside a successful flip session once tracking has been manually re-enabled.
Tonight I will download and install the Beta 2.0 release to see if perhaps it already addresses this issue.