Meridian Flip on EQ8-R (SyncScan) tries to go the wrong direction

[Sven Eklund]

Running Nina 2.0 with EQ8-R Pro (SyncScan, not EQMOD) and suddenly the EQ8-R started trying to make the Meridian Flip in the wrong direction - the EFW hit the pier :-(
The sequence has been the same for several weeks without any problems (three targets, two flips) and the only change that has been done is upgrading NINA from Beta022 to Beta023. Now on Beta024 and the problem is still there.
"Do not sync" is off and Use SideOfPier is True. The sequence forces a "Solve and Sync" at start. Flip between 5-6 minutes after the Meridian.

2022-01-03T19:27:14.3508|INFO|SequenceTrigger.cs|Run|100|Starting Trigger: MeridianFlipTrigger
2022-01-03T19:27:14.3598|INFO|MeridianFlipVM.cs|DoMeridianFlip|152|Meridian Flip - Initializing Meridian Flip.
Current target coordinates RA: 00:47:02 Dec: -11° 51' 06" Epoch: J2000
Remaining wait time: 00:00:24.8590000
Pause Time Before Meridian: 0
Minutes After Meridian: 5
Max Minutes After Meridian: 6
AutoFocus After Flip: False
Recenter: True
Use SideOfPier: True
Settle Time: 10
2022-01-03T19:27:14.3648|INFO|MeridianFlipVM.cs|StopAutoguider|323|Meridian Flip - Stopping Autoguider
2022-01-03T19:27:16.4860|INFO|MeridianFlipVM.cs|PassMeridian|233|Meridian Flip - Stopping tracking to pass meridian
2022-01-03T19:27:26.9572|INFO|StarDetection.cs|Detect|221|Average HFR: 1.57300420238825, HFR σ: 0.484241244226812, Detected Stars 11
2022-01-03T19:27:27.0722|INFO|BaseImageData.cs|FinalizeSave|144|Saving image at C:\Users\AstroCamp\Google Drive ([e-mail])\Aktuella Objekt\Skallnebulosan\O3\2022-01-03\Raw\11stars_120.00s_SQM=18.97_235026_Temp-20.00_No0173.xisf
2022-01-03T19:27:40.6066|INFO|MeridianFlipVM.cs|PassMeridian|245|Meridian Flip - Resuming tracking after passing meridian
2022-01-03T19:27:40.6116|INFO|MeridianFlipVM.cs|DoFlip|127|Meridian Flip - Scope will flip to coordinates RA: 00:47:02 Dec: -11° 51' 06" Epoch: J2000
2022-01-03T19:27:56.9084|ERROR|AscomDevice.cs|GetProperty|304|An unexpected exception occurred during GET of ITelescopeFacadeProxy.Azimuth:
ASCOM.DriverException: Conversation timeout ---> ASCOM.DriverException: Conversation timeout
at ASCOM.SynScanMobile.AscomConversationManager.Converse(Command command, ArgsChecker argsChecker, ConverseParams convParams)
at ASCOM.SynScanMobile.Telescope.get_Azimuth()
--- End of inner exception stack trace ---
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 613
at ASCOM.DriverAccess.MemberFactory.GetTargetInvocationExceptionHandler(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 664
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 230
at ASCOM.DriverAccess.Telescope.get_Azimuth() in C:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 266
at Castle.Proxies.Invocations.ITelescopeFacade_get_Azimuth.InvokeMethodOnTarget()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.Proxies.ITelescopeFacadeProxy.get_Azimuth()

/Sven, E-eye, Spain

[Dale Ghent]

Yes indeed, it does look like the SynScan driver blew up when NINA queried it for its azimuth. It certainly should not be doing this. Perhaps the SyncScan driver has its own logs that might shed light on the reason? Perhaps the mount/controller needs a power cycle.

[Sven Eklund]

A thought, maybe far fetched:
I am a Swede running a remote setup in Spain. Switched Windows language from Swedish to English so I could get computer support from the Spanish techs. All good. But sometime around when this problem appeared, I changed back the regional formats only (date, numbers, etc) to Swedish? Could this confuse the parse of the Azimuth?

[Dale Ghent]

That is certainly possible and has been seen before. We have seen such localization issues with various ASCOM drivers where they use the user’s culture information when parsing strings into numbers instead of using the “invariant” culture which, in the case of numbers, uses the . as the decimal, not ,

Can you set up your system so that it uses . for the decimal separator or switch back to English as the locale? If the driver no longer crashes, this would be a strong indicator of the cause, and is still something that Sky-Watcher/Synta will have to address in their driver. Of course, you can also try alternative drivers such as EQMOD or GSS if switching locales is not possible.

[Sven Eklund]

Yes, I will switch back to US regional format so it is in line with the overall language settings and try again later today.

Thanks for your input!!

/Sven

[Sven Eklund]

Nope, no luck. Still insists on banging the EFW on the pier when doing a Meridian Flip…

[Dale Ghent]

Is the driver still throwing an exception when the Azimuth property is queried by NINA?

One other thing to check is a configuration parameter - the longitude. I’m not sure where E-eye is in Spain, but if it’s west of the prime meridian, make sure that the longitude value is negative under Options → General → Astrometry. Also ensure that your mount’s and imaging system’s clock are not off and are synced to known-good time source. Because it’s the only other time-related event that has recently happened, did this stop working with the new year, perhaps? Or did the problem exist prior to the new year?

This really smells like some sort of driver issue, or perhaps a mount setting issue, and not only because of the internal exception it is throwing when NINA queries the driver for the Azimuth. The meridian flip logic is the same for all regardless of mount driver, so if it were an issue in NINA it would very likely be more widespread than just your particular EQ8.

A suggestion that’s not related to the fix, but more for protecting your gear in such cases, is to have the EFW’s long end pointing “up” instead of the common “down” orientation relative to the vertical axis of the mount. The will give your gear more clearance around the pier/tripod legs and protect the EFW’s fragile USB connector from being bashed into the pier. You may need to tweak your RA axis counterweight a little to compensate for the slightly increased moment-arm, but it can save you some potential grief in the future by keeping the EFW’s USB connector out of harm’s way.

[Sven Eklund]

Yes, the same exception.
Yep, got -6 degrees longitude.
Time of the computer/NINA is in sync with time of the mount.
It worked OK on the 2:nd of January, 2020, but not the next night.
Yeah, thought of having the techs turn the EFW, but that would only put the asi6200mm in the pier instead…

The MF is really only a GOTO after the M is passed, right? The mount just have to detect that it is on the wrong side when the GOTO comes (that works ok) and then slew in the correct direction (not ok).
And the GOTO:s do work, I can start a sequence and GOTO a position close prior to the MF. I also tested a sequence that stopped 5 min prior the M, waited 15 min passed the M (but still tracking) and then issued a “normal” GOTO to the same target. Worked OK - this “manual MF” detected that it was on the wrong side, but also managed to slew in the correct direction!

Also noted in the log that just parking the mount upsets the driver:
2022-01-05T00:49:56.2130|ERROR|AscomDevice.cs|GetProperty|304|An unexpected exception occurred during GET of ITelescopeFacadeProxy.AtPark:

‌

Any new thoughts after reading this?

‌

[Dale Ghent]

There is clearly something faulty in the driver. I suggest reinstalling it and, if the issue persists with the internal exceptions, contact Sky-Watcher support.

[Sven Eklund]

Re-installed it, same issue.

[Dale Ghent]

Yeah well perhaps the driver is getting garbage from the mount itself and these exceptions are a result of that. Either way, it’s time to engage Sky-Watcher support. I do not think there is anything we can do for you here. You can try further checks using the EQMOD and/or GSS drivers.

[Sven Eklund]

Yes, exactly my line of though! This error in the log might be the effect and not the cause of the problem!

I am thinking of a bad position sync between nina and mount that gradualy got worse. Will try som extreme MF.

And yes, will check in with SkyWatcher!

‌

Thanks!!

[Stefan B]

Driver issue

[Stefan B]

Removing version: 2.0 Beta (automated comment)