Luca,
At first glance at the logs the mount doesn’t think it should have flipped. Unfortunately I don’t think I will get a chance to deep dive into your logs and settings until this evening to determine if it was APCC or SGPro that calculated wrong.
-Ray
Luca,
There was no mount flip at 3:11 am. Are you sure you are looking at the right part of the log? APCC says this:
1077707 2020-03-18 03:11:04.064: Info, VPortCheckVPort1(COM4), (RX: GR#), TX: APCC,11,107113,13:16:51.7#
1077708 2020-03-18 03:11:04.080: Debug, SafeSlewStateMachine, New SafeSlew State=GetSideOfPierAndCwStatus
1077709 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, Slewing from RA/Dec = 13.28103 (13h 16m 51.70s), 41.90861 (+41° 54’ 31.0")
1077710 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, Slewing to RA/Dec = 13.28103 (13h 16m 51.70s), 41.90861 (+41° 54’ 31.0")
1077711 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, Starting Meridian Delay = -1.74
1077712 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, Start PierSide/CWUP = WEST, True
1077713 2020-03-18 03:11:04.140: Info, GetDestinationPierSide, RA,Dec,LST,EastMD,WestMD = 13.281, 41.909, 15.016, -1.738. -1.738: PS = WEST: CWUP = True
1077714 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, IsUnsafeSlew = False
1077715 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, END PierSide/CWUP = WEST, True
1077716 2020-03-18 03:11:04.140: Info, SafeSlewStateMachine, Ending Meridian Delay = -1.74
Both start and end pier sides are West and counterweight up. There was no pier flip.
-Ray
Thank you, Ray.
I will update the firmware as you recommended. I need to call George because I bought the mount second hand and need access info to download the firmware.
Am I misinterpreting the log file when I look at this section and read it as the mount went from counterweights up to counterweights down after a successful pier flip?
520585 2020-03-18 03:12:00.988: ASCOM: Info : GET RightAscension = 13.2810277777778
520586 2020-03-18 03:12:00.990: ASCOM: Info : GET Declination = 41.9086111111111
520587 2020-03-18 03:12:00.991: ASCOM: Info : GET Slewing = True, MoveAxis(0)=0, MoveAxis(1)=0
520588 2020-03-18 03:12:01.049: Driver: Info : CommandString TX=‘:GOS#’
520589 2020-03-18 03:12:01.078: Driver: Info : CommandString: APCC response: ‘:APCC,107353,GOS#’, Response=‘129000232P000#’
520590 2020-03-18 03:12:01.078: Driver: Info : CommandString TX=‘:GR#’
520591 2020-03-18 03:12:01.113: Driver: Info : CommandString: APCC response: ‘:APCC,107354,GR#’, Response=‘13:16:51.7#’
520592 2020-03-18 03:12:01.114: Driver: Info : CommandString TX=‘:GD#’
520593 2020-03-18 03:12:01.139: Driver: Info : CommandString: APCC response: ‘:APCC,107355,GD#’, Response=‘+41*54:31#’
520594 2020-03-18 03:12:01.140: Driver: Info : CommandString TX=‘:pS#’
520595 2020-03-18 03:12:01.171: Driver: Info : CommandString: APCC response: ‘:APCC,107356,pS#’, Response=‘East#’
520596 2020-03-18 03:12:01.171: Counterweight: Info : Counterweight Down
520597 2020-03-18 03:12:01.171: Driver: Info : CommandString TX=‘:GS#’
520598 2020-03-18 03:12:01.205: Driver: Info : CommandString: APCC response: ‘:APCC,107357,GS#’, Response=‘15:01:54.9#’
520599 2020-03-18 03:12:01.205: Driver: Info : CommandString TX=‘:pS#’
520600 2020-03-18 03:12:01.238: Driver: Info : CommandString: APCC response: ‘:APCC,107358,pS#’, Response=‘East#’
520601 2020-03-18 03:12:01.239: Counterweight: Info : Counterweight Down
520602 2020-03-18 03:12:01.239: Driver: Info : CommandString TX=‘:GM#’
520603 2020-03-18 03:12:01.269: Driver: Info : CommandString: APCC response: ‘:APCC,107359,GM#’, Response=‘-01:29:19.0#’
520604 2020-03-18 03:12:01.270: SetMeridianDelayUI: Info : Setting Meridian Delay: -1.4886
520605 2020-03-18 03:12:01.273: Driver: Info : CommandString TX=‘:GL#’
520606 2020-03-18 03:12:01.317: Driver: Info : CommandString: APCC response: ‘:APCC,107360,GL#’, Response=‘03:12:01.3#’
520607 2020-03-18 03:12:01.317: Driver: Info : CommandString TX=‘:pS#’
520608 2020-03-18 03:12:01.331: Driver: Info : CommandString: APCC response: ‘:APCC,107361,pS#’, Response=‘East#’
520609 2020-03-18 03:12:01.331: Counterweight: Info : Counterweight Down
520610 2020-03-18 03:12:01.331: SLEW COMPLETE: Info : Slew complete: Setting tracking rates
520611 2020-03-18 03:12:01.331: CheckSlewComplete: Info : Restoring tracking state = 1
520612 2020-03-18 03:12:01.332: User: Info : Start tracking pressed
520613 2020-03-18 03:12:01.332: ASCOM: Info : SET TrackingRate = 0
520614 2020-03-18 03:12:01.332: Driver: Info : CommandBlind TX=‘:Q#’
520615 2020-03-18 03:12:01.343: Driver: Info : CommandBlind TX=‘:RT2#’
520616 2020-03-18 03:12:01.364: ASCOM: Info : GET RightAscension = 13.2810277777778
520617 2020-03-18 03:12:01.364: ASCOM: Info : GET Declination = 41.9086111111111
520618 2020-03-18 03:12:01.364: ASCOM: Info : GET Slewing = False, MoveAxis(0)=0, MoveAxis(1)=0
520619 2020-03-18 03:12:01.516: Driver: Info : CommandString TX=‘:GG#’
520620 2020-03-18 03:12:01.574: Driver: Info : CommandString: APCC response: ‘:APCC,107362,GG#’, Response=‘05:00:00.0#’
Thanks,
Luca
I think I am starting to see what happened but I don’t understand why. When SGP asked for a pier flip at 3:11:03 the mount didn’t flip. The mount initiated a second slew at 3:12:01 (I don’t understand who initiated this slew), which resulted in a pier flip. That was too late and at 3:12:31, SGP initiated the park procedure.
The mount initiated a second slew at 3:12:01 (I don’t understand who initiated this slew), which resulted in a pier flip.
The mount hit the meridian limit and flipped by itself:
1078349 2020-03-18 03:11:16.843: Debug, Command Thread, TX = ‘:pS#’
1078350 2020-03-18 03:11:16.846: Info, Meridian Limits, Limit reached - Flipping mount - Dec=41.9086111111111, RA=13.2810277777778, MeridianAngle=89.1086111111111, Hour Angle=1.73831739818512
1078351 2020-03-18 03:11:16.855: Info, StartPierFlip, Starting Pier Flip (to East) RA/Dec = 13.2810, 41.9086
-Ray
Do you have a theory as to why the mount did not flip at 3:11? Do you have any suggestions for troubleshooting this problem? Have you seen reports of this issue before? I can’t be the first person trying to use APCC Pro with meridian limits and SGP.
Thank you!
Luca
Also, with a Flip Offset of 25 minutes, why did it get so close to the actual meridian limit before attempting to flip? It should have been at least 2 minutes before reaching the meridian limit, given the duration of the subs.
luca, see above, i have had this problem of late but 1) i havent pulled the logs (the telescope and computer are under a tarp and it has been raining) and 2) it was working flawlessly forever and just started happening recently. i have a mach1 and the firmware is at V1. my APCC is now slightly downrev as well. the only thing that changed for me is the recent 3.1 version of SGP.
Thanks, Rob.
SGPro does not determine this value, it just uses what the mount reports.
@Ken, @lucam
I will try to look at the logs tonight. The value APCC sends can be converted to an hour angle where a flip will occur. The issue may be simply one of a different sidereal time in the mount (LST) versus what SGPro thinks. For example a flip might not occur if SGPro thinks LST is later than what the mount thinks. SGPro would think the mount is at the flip point when it actually is not there yet. Sending a command to flip the mount would thus fail. I’m not saying this is what happened, just how it could be possible for an application to try to flip early.
-Ray
I have updated the firmware on the mount.
I have run some tests this afternoon trying to get start the mount close to the meridian and observing the behavior. for a reason that I don’t understand, SGP never sends a meridian flip command, the camera keeps imaging through the meridian and ultimately APCC issues a meridian flip when it hits the meridian limit. SGP keeps imaging through the flips as if nothing happens.
I am a bit frustrated and would like to have a system that can perform a meridian flip unassisted as it - used to a few weeks ago. I appreciate the help - this is hardly an unusual imaging configuration and I hope that we can figure out how to make it work.
Logs and screenshots:
Link to Logs
Useful Info
OS: Microsoft Windows 10 Pro
Ver: 3.1.0.457
To clarify, if I interpret the log correctly, SGP claims that the mount does not require a flip and completely ignores the timer to the meridian flip. I don’t know if my configuration is not setup properly. I would appreciate if you guys can double check how I have everything setup.
Thanks a lot,
Luca
Luca,
Even if the flip isn’t happening when you expected the mount does flip to protect itself so I hope you will have a little patience while this problem is researched. You are at least imaging during the best part of the sky (i.e., across the meridian).
If the problem is in APCC I may not be able to get to it until the weekend. Since you were able to down rev APCC, maybe you could also try down revving SGPro?
-Ray
Ray,
I truly appreciate you taking the time to research the problem. Of course I understand that it may take a bit of time to sort it out. I am running the most recent version of APCC and SGP, and now also of the mount firmware. I have not down rev APCC and would rather not down rev SGP because earlier 3.1 versions had other issues.
I agree that the mount is protected and APCC works properly to avoid pier crashes. I really like both pieces of software and don’t want to abandon either one. I am sure there is a solution to this problem.
thanks again,
Luca
@Ken, do you understand why in the last log I posted as the mount crosses the meridian SGP does not issue a meridian flip command? What is different? There are several meridian crossings on different targets in the log but every single time SGP keeps imaging, does not issue a flip until the mount hits the meridian limit in APCC and then the mount flips in the middle of an exposure.
Well, I understand why SGPro did not perform a meridian flip, but I am unsure of the actual underlying cause.
Somewhere between here:
[03/18/20 19:49:36.866][DEBUG][Sequence Thread][SQ;] Telescope is on the West side of the mount [03/18/20 19:49:36.866][DEBUG][Sequence Thread][SQ;] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: 0.682345833333335 < 1
and here
[03/18/20 19:51:56.546][DEBUG][Sequence Thread][SQ;] Meridian flip not needed, telescope on East side
The mount started reporting it was already on the east (presumably after passing the meridian), but no flip actually occurred.
Thanks, Ken. That’s good information that may be helpful when Ray has a chance to dig into the APCC logs.
Just as a reminder this was the sequence of events I observed in the tests yesterday (in multiple targets in the same log file):
Something is obviously wrong with this sequence of events. As far as I can tell APCC communicated the meridian offset correctly to SGP but SGP chose to ignore it.
This situation is different from the one documented in the logs further up this thread when SGP issued a meridian flip at the right time but the mount did not flip until it actually hit the meridian limit and APCC triggered the flip. In that case, the sequence aborted. I don’t understand why SGP and APCC behave differently and why I wasn’t able to set up a target when SGP issued a meridian flip when the meridian clock reached zero in SGP.
Was there a slew between these two pier side reports? A mount that is tracking should never change pointing state aka Pier side regardless of where it is relative to the meridian.
Chris,
In my last post I described the sequence of events through the meridian crossing. There was a slew triggered by APCC when the OTA reached the meridian limit set in the software. There was no meridian fli triggered by SGP when the meridian limit clock reached zero.
You can see the slew that brought pier side from West to East in the APCC log:
154158 2020-03-18 19:51:52.551: ASCOM: Info : GET SideOfPier = West
…
154220 2020-03-18 19:51:55.582: ASCOM: Info : GET Slewing = True, MoveAxis(0)=0, MoveAxis(1)=0
154221 2020-03-18 19:51:55.671: Driver: Info : CommandString TX=’:GOS#’
154222 2020-03-18 19:51:55.705: Driver: Info : CommandString: APCC response: ‘:APCC,33705,GOS#’, Response=‘129000201P000#’
154223 2020-03-18 19:51:55.707: Driver: Info : CommandString TX=’:GR#’
154224 2020-03-18 19:51:55.735: Driver: Info : CommandString: APCC response: ‘:APCC,33706,GR#’, Response=‘06:39:19.8#’
154225 2020-03-18 19:51:55.735: Driver: Info : CommandString TX=’:GD#’
154226 2020-03-18 19:51:55.767: Driver: Info : CommandString: APCC response: ‘:APCC,33707,GD#’, Response=’+56*50:36#’
154227 2020-03-18 19:51:55.767: Driver: Info : CommandString TX=’:pS#’
154228 2020-03-18 19:51:55.797: Driver: Info : CommandString: APCC response: ‘:APCC,33708,pS#’, Response=‘East#’
154229 2020-03-18 19:51:55.798: Counterweight: Info : Counterweight Down
154230 2020-03-18 19:51:55.798: Driver: Info : CommandString TX=’:GS#’
154231 2020-03-18 19:51:55.854: Driver: Info : CommandString: APCC response: ‘:APCC,33709,GS#’, Response=‘06:44:23.3#’
154232 2020-03-18 19:51:55.854: Driver: Info : CommandString TX=’:pS#’
154233 2020-03-18 19:51:55.859: Driver: Info : CommandString: APCC response: ‘:APCC,33710,pS#’, Response=‘East#’
154234 2020-03-18 19:51:55.859: Counterweight: Info : Counterweight Down
154235 2020-03-18 19:51:55.859: Driver: Info : CommandString TX=’:GM#’
154236 2020-03-18 19:51:55.889: Driver: Info : CommandString: APCC response: ‘:APCC,33711,GM#’, Response=‘00:10:52.0#’
154237 2020-03-18 19:51:55.889: Driver: Info : CommandString TX=’:GL#’
154238 2020-03-18 19:51:55.943: Driver: Info : CommandString: APCC response: ‘:APCC,33712,GL#’, Response=‘19:51:55.9#’
154239 2020-03-18 19:51:55.943: Driver: Info : CommandString TX=’:pS#’
154240 2020-03-18 19:51:55.955: Driver: Info : CommandString: APCC response: ‘:APCC,33713,pS#’, Response=‘East#’
154241 2020-03-18 19:51:55.955: Counterweight: Info : Counterweight Down
154242 2020-03-18 19:51:55.955: SLEW COMPLETE: Info : Slew complete: Setting tracking rates
154243 2020-03-18 19:51:55.955: CheckSlewComplete: Info : Restoring tracking state = 1
…
154273 2020-03-18 19:51:56.613: ASCOM: Info : GET SideOfPier = East
