Telescope failed to perform meridian flip


#1

Hello,
as I was running a session yesterday evening, it ended up failing in the middle of the night with a meridian flip error.
It seems to be around [10/23/2016 12:58:58 AM] but I do not understand the East/West issue.
Attached is the SGP log, but I can attach more if needed. I am running an AVX mount with POTH.
Thanks for your help!
Olivier

SGP log: sg_logfile_20161022225012.zip (66.7 KB)

NB I need to say that the AutoFocus is just a work of beauty :slight_smile:


Sequence Generator Pro 2.6.0.11 Beta is Released for Testing
Sequence Generator Pro 2.6.0.12 Beta is Released for Testing
Sequence Generator Pro 2.5.2.6 Beta is Released for Testing
Sequence Generator Pro 2.5.2.7 Beta is Released for Testing
Sequence Generator Pro 2.5.2.8 Beta is Released for Testing
Sequence Generator Pro 2.6.0.0 Beta is Released for Testing
Sequence Generator Pro 2.6.0.8 Beta is Released for Testing
Sequence Generator Pro 2.6.0.2 Beta is Released for Testing
Sequence Generator Pro 2.6.0.3 Beta is Released for Testing
Sequence Generator Pro 2.6.0.4 Beta is Released for Testing
Sequence Generator Pro 2.6.0.5 Beta is Released for Testing
Sequence Generator Pro 2.6.0.6 Beta is Released for Testing
Sequence Generator Pro 2.6.0.7 Beta is Released for Testing
Sequence Generator Pro 2.6.0.1 Beta is Released for Testing
Sequence Generator Pro 2.6.0.10 Beta is Released for Testing
#2

SGPro requested that your mount flip (when it was past the meridian, but it ignored the request (reported flip was done in less than 1 second) and stayed where it was. Without telescope logs, we don’t have any additional information:

[10/23/2016 12:58:58 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[10/23/2016 12:58:58 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[10/23/2016 12:58:58 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using sideOfPier
[10/23/2016 12:58:58 AM] [DEBUG] [Telescope Thread] Setting Pier East
[10/23/2016 12:58:58 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[10/23/2016 12:58:59 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Failed to flip because starting pier side and ending pier side are the same!
[10/23/2016 12:58:59 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope command to meridian flip has completed
[10/23/2016 12:58:59 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope failed to perform meridian flip


#4

Here you are the Celestron ASCOM log (via Dropbox, too big to uppload here) https://www.dropbox.com/s/wqy8np6so25roqk/ASCOM.Celestron.2136.184960.txt.zip?dl=0
Let me know if you need any further log or info?
Thanks!
Olivier


#5

Thanks, it took a bit of chasing but having the time helped a lot.

The position, sidereal time and pointing state are all consistent and I can see that the mount has tracked past the meridian about 5 minutes earlier.
I can see the driver getting the set side of pier command at 00:58:58.
The slew takes place and I can see the position changing and the slewing state remaining at true until 00:59:52, nearly a minute later. The pointing state has now changed as expected but it does not change when the slew starts, it reflects the mount state and changes when that changes.

What I think may be happening is that SGP is sending the set pier side command and immediately reading the pointing state. The slew is still in progress, in fact barely started so the pointing state has not changed. It changes when the mount state changes at 00:59:10.

@Ken, it looks to me as if you should wait for the set side of pier slew to complete before checking the pointing state.

Chris


#6

We do certainly wait… in this case, setting the property appears to be asynchronous and returns immediately. The ASCOM docs do not specify if setting this property will result in a synchronous or asynchronous slew so we support both. We do not, however, immediately check the pointing state (it appears as though we do). Once sideOfPier is set we check the mount’s slewing state (isSlewing) to block the check of pointing state until the mount reports it’s done. In this case, the mount did not report it was slewing (in time for the check) so the code assumed it was done. I think maybe a reasonable alternative to this is to block on pointing state changing (with a reasonable timeout), then continue blocking until the mount reports it is done slewing.


#7

I’ve checked the driver log and code in detail, this is the relevant section, with annotations to explain what is going on

SGP checks if the pier side can be set
00:58:58.430 CanSetPierSide True

SGP send the message to change the pier side
00:58:58.430 SetSideOfPier set to pierEast

checks if this is possible
00:58:58.430 SideOfPier throttled pierWest
00:58:58.430 SendMessageTerminated send c0001
00:58:58.447 SendMessageTerminated received 00000001#
00:58:58.447 MeridianMode get favourWest
00:58:58.447 MeridianMode set favourWest
00:58:58.448 SendMessageTerminated send C0001,00000001
00:58:58.470 SendMessageTerminated received #
00:58:58.470 SendMessageTerminated send g1258DD00,24BEDE00
00:58:58.499 SendMessageTerminated received W#
00:58:58.499 DestinationSideOfPier from hw, Ra 1.72004270553589, Dec 51.6734647750854 = pierEast
checks completed, the specified pointing state can be reached

00:58:58.499 SetSideOfPier Slew to pierEast
async slew command sent
00:58:58.499 IsGuiding isGuiding (False || False) = False *** part of the slewAsync method
00:58:58.499 SendMessageTerminated send r1258DD00,24BEDE00

00:58:58.512 IsGuiding isGuiding (False || False) = False *** not sure, could be from SGP

00:58:58.566 SendMessageTerminated received #
slew started, checks of the pointing state, slewing state and position will check the hardware

SGP asking for the tracking state, before SetSideOfPier has returned
00:58:58.566 SendMessageTerminated send t *** read tracking state command

00:58:58.566 SlewAsync Ra 1.72004270553589, Dec 51.6734647750854 *** part of SetSideOfPier

SetSideOfPier returns here.

00:58:58.570 SendMessageTerminated received [02]# *** reply to ‘t’ command
00:58:58.570 Tracking get Tracking True, mode eqN

SGP asking for the pointing state
00:58:58.616 SideOfPier throttled pierWest
00:58:58.672 SideOfPier throttled pierWest
00:58:58.933 IsGuiding isGuiding (False || False) = False

SGP asking for the position
00:58:58.933 SendMessageTerminated send e
00:58:59.001 SendMessageTerminated received 12976F00,24FD5500#
00:58:59.001 GetRaDec Ra 1.74295663833618, Dec 52.0165944099426

SGP asking for the sidereal time
00:58:59.048 SendMessageTerminated send l
00:58:59.104 SendMessageTerminated received 1337C200#
00:58:59.105 Sidereal time From mount 1.80166912078857

SGP asking for the pointing state, before checking the slewing state
00:58:59.106 SideOfPier throttled pierWest
00:58:59.173 SideOfPier throttled pierWest

SGP asking for the sidereal time
00:58:59.318 SendMessageTerminated send l
00:58:59.375 SendMessageTerminated received 1337F600#
00:58:59.375 Sidereal time From mount 1.80174350738525

SGP asks for the slewing state for the first time after set sideOfPier returns
00:58:59.376 IsGuiding isGuiding (False || False) = False
00:58:59.376 SendMessageTerminated send L
00:58:59.380 SendMessageTerminated received 1#
00:58:59.380 Slewing state True
Slewing state returned as true

The driver is checking that the new pointing state can be reached and sends a async slew command to start the slew to that position.
This has completed sucessfully before the time of the error reported in the SGP log.

There are then several reads of the pointing state BUT no check on the slewing state until after that. The first check on the slewing state reports that slewing is in progress.

It looks as if SGP is reading the pointing state before it checks the slew state.

Chris


#8

I’m having what appears to be exactly the same problem with my 10micron mount. Was this issue ever resolved, and if so how?


#9

See my answer Peter in the separate thread you have raised.

I’m happy if you want to pm me.

Barry


#10

Thanks Barry. I believe I’m using all of the correct parameters as per this forum:

Flip Slew Tolerance 3
Flip Guide Tolerance 5
Minutes past Meridian -5
Wait for Meridian
Auto Center after Meridian Flip.

It might be significant that 2 things have changed.

  1. I upgraded from SGP release 2.5.2.7 to 2.6.0.23
  2. I switched from the Per Frejvall driver to the new Baader-provided driver.

#11

Thanks Peter.

I have the latest SGP beta and also 10 Micron beta firmware and do not have any issue with flips. I use Per’s ascom driver though - maybe that is significant.

Give Per’s driver a try?

Are you able to share a link to the Baader ascom driver?

I have posted the above on the 10 Micron forum too.

All the best, Barry


#12

That’s interesting Barry. My GM1000 works fine - with exactly the same settings - but it uses the older release of SGP and also Per’s driver.

I would try switching back to Per’s driver but it doesn’t seem to be available for download any longer (I’ve already loaded the latest beta firmware). I can’t recall the link for the driver I’m using but it’s called ASCOM 10Micron Mount Driver 1.2.2.0. I downloaded it only a month ago. The driver currently on the 10Micron site looks different!


#13

Managed to find Per’s driver and have installed it.
BTW what SYNC settings do you have? I’m confused with OFFSET TARGET and OFFSET SCOPE!


#14

I use ‘Synch’ and this will perform a Synch Align (assuming you have this set in the control box) and all works well.

Clear Skies!


www.mainsequencesoftware.com