Hi,
I have just installed APCC and found that the mount has stopped working with the plate solve. As far as I can see, the plate solves works and issues a slew, after the slew, the mount appers no to be moving at all and that happens every time. With APV2 it’s working fine.
Attached you will find the log.
sg_logfile_20151221190430.txt (551.5 KB)
I think APCC is expecting J2000 coordinates.
Manuel,
APCC and the driver expect “JNow”.
I’m not sure if this is the problem but looking at your log I see that the decimal point in your location is a “comma”.
-Ray Gralak (Author of APCC)
Please provide an approximate time of the incident you are describving.
I don’t understand this. The mount is always not moving after a slew is complete (with the exception of tracking… maybe that’s what you are saying?).
This should’t be an issue… just a regional display setting.
Hi Ken,
Look at 19:30:01, for example:
Seems the problem is here:
[DEBUG] [Center Scope Thread] Error in auto center update thread, Thread was being aborted.
A bit of more info:
[22/12/2015 19:06:18] [DEBUG] [Telescope Thread] Telescope: Syncing to JNOW RA: 0,924913647437857 Dec: 57,2213725121046
0052579 2015-12-22 19:06:18.284: Info, VPort1(COM3), RX: :Sd+5713:17#
0052580 2015-12-22 19:06:18.309: Info, ProcessVPortCommand, RX from VPort 0: :Sd+5713:17#
0052581 2015-12-22 19:06:18.311: Info, VPort1(COM3), (RX: :Sd+5713:17#), TX: 1
0052582 2015-12-22 19:06:18.347: Info, VPort1(COM3), RX: :Sr00:55:29,7#
0052583 2015-12-22 19:06:18.371: Info, ProcessVPortCommand, RX from VPort 0: :Sr00:55:29,7#
0052584 2015-12-22 19:06:18.373: Info, VPort1(COM3), (RX: :Sr00:55:29,7#), TX: 1
0052585 2015-12-22 19:06:18.412: Info, VPort1(COM3), RX: :APCC,3304,GR#
0052586 2015-12-22 19:06:18.437: Info, ProcessVPortCommand, RX from VPort 0: :APCC,3304,GR#
0052587 2015-12-22 19:06:18.437: Info, ProcessVPortCommand, APCC Seq= 3304, CMD=GR#
0052588 2015-12-22 19:06:18.438: Info, VPort1(COM3), (RX: GR#), TX: APCC,11,3304,00:53:46.1#
0052589 2015-12-22 19:06:18.470: Info, VPort1(COM3), RX: :APCC,3305,CMR#
0052590 2015-12-22 19:06:18.497: Info, ProcessVPortCommand, RX from VPort 0: :APCC,3305,CMR#
0052591 2015-12-22 19:06:18.497: Info, ProcessVPortCommand, APCC Seq= 3305, CMD=CMR#
0052592 2015-12-22 19:06:18.498: Error, SyncTarget, Valid Alt/Az or RA/Dec has not been received!
0052593 2015-12-22 19:06:18.498: Debug, Serial Thread, TX (from VPort) = ':CMR#'
0052594 2015-12-22 19:06:18.547: Debug, Serial Thread, RX = 'Coordinates matched. #'
0052595 2015-12-22 19:06:18.547: Debug, Serial Thread, TX = ':GOS#'
0052596 2015-12-22 19:06:18.549: Info, VPort1(COM3), (RX: :CMR#), TX: APCC,33,3305,Coordinates matched. #
0052597 2015-12-22 19:06:18.579: Debug, Serial Thread, RX = '129000210O000#'
0052598 2015-12-22 19:06:18.580: Debug, Serial Thread, TX = ':Rr#'
0052599 2015-12-22 19:06:18.582: Info, VPort1(COM3), RX: :APCC,3306,GR#
0052600 2015-12-22 19:06:18.595: Debug, Serial Thread, RX = '0#'
0052601 2015-12-22 19:06:18.595: Debug, Serial Thread, TX = ':Rd#'
0052602 2015-12-22 19:06:18.601: Info, ProcessVPortCommand, RX from VPort 0: :APCC,3306,GR#
0052603 2015-12-22 19:06:18.601: Info, ProcessVPortCommand, APCC Seq= 3306, CMD=GR#
0052604 2015-12-22 19:06:18.602: Info, VPort1(COM3), (RX: GR#), TX: APCC,11,3306,00:53:46.1#
0052605 2015-12-22 19:06:18.611: Debug, Serial Thread, RX = '0#'
0052606 2015-12-22 19:06:18.630: Info, VPort1(COM3), RX: :APCC,3306,pS#
0052607 2015-12-22 19:06:18.652: Info, ProcessVPortCommand, RX from VPort 0: :APCC,3306,pS#
0052608 2015-12-22 19:06:18.653: Info, ProcessVPortCommand, APCC Seq= 3306, CMD=pS#
0052609 2015-12-22 19:06:18.653: Debug, Serial Thread, TX (from VPort) = ':pS#'
0052610 2015-12-22 19:06:18.673: Debug, Serial Thread, RX = 'West#'
0052611 2015-12-22 19:06:18.674: Info, VPort1(COM3), (RX: :pS#), TX: APCC,5,3306,West#
0052612 2015-12-22 19:06:18.699: Debug, Serial Thread, TX = ':pS#'
0052613 2015-12-22 19:06:18.719: Debug, Serial Thread, RX = 'West#'
0052614 2015-12-22 19:06:18.719: Debug, Serial Thread, TX = ':GH#'
0052615 2015-12-22 19:06:18.748: Debug, Serial Thread, RX = '-00:53:44.3#'
0052616 2015-12-22 19:06:18.748: Debug, Serial Thread, TX = '#:GR#'
0052617 2015-12-22 19:06:18.776: Debug, Serial Thread, RX = '00:53:46.1#'
0052618 2015-12-22 19:06:18.776: Debug, Serial Thread, TX = '#:GD#'
0052619 2015-12-22 19:06:18.802: Debug, Serial Thread, RX = '+5643:25#'
0052620 2015-12-22 19:06:18.803: Debug, Serial Thread, TX = ':GOS#'
0052621 2015-12-22 19:06:18.832: Debug, Serial Thread, RX = '129000210O000#'
0052622 2015-12-22 19:06:18.833: Debug, Serial Thread, TX = ':GM#'
0052623 2015-12-22 19:06:18.860: Debug, Serial Thread, RX = '00:00:00.0#'
0052624 2015-12-22 19:06:18.860: Debug, Serial Thread, TX = ':HRG#'
0052625 2015-12-22 19:06:18.889: Debug, Serial Thread, RX = '-16607:02#'
0052626 2015-12-22 19:06:18.889: Debug, Serial Thread, TX = ':HDG#'
0052627 2015-12-22 19:06:18.917: Debug, Serial Thread, RX = '-17234:11#'
0052628 2015-12-22 19:06:18.917: Debug, Serial Thread, TX = '#:GC#'
0052629 2015-12-22 19:06:18.944: Debug, Serial Thread, RX = '12/22/15#'
0052630 2015-12-22 19:06:18.944: Debug, Serial Thread, TX = ':GL#'
0052631 2015-12-22 19:06:18.971: Debug, Serial Thread, RX = '19:06:18.8#'
0052632 2015-12-22 19:06:18.971: Debug, Serial Thread, TX = ':GG#'
0052633 2015-12-22 19:06:18.999: Debug, Serial Thread, RX = ‘-01:00:00.0#’
This is not the issue… not sure what led you to believe this.
OK.
OK. This is:
RA: 4,16654438792779 Dec: 30,8179705684438… not sure what Y has to do with it… this solve just lets SGPro know where the scope is pointed right now.
Correct… Slewing to JNOW RA: 4,17163805118088 Dec: 30,8205473996486
Solve and Sync at RA: 4,16656850309845 Dec: 30,817984004653… slightly different, not sure here. You can see that SGPro did ask the mount to move though.
As far as I can see, SGPro is behaving normally. It solves your current frame, does the math decides it is not within your expected tolerance, asks the scope to slew there and checks again. It is never getting under your tolerance, but SGPro successfully asks it to 3 time before quitting.
Beyond this, we do not have much insight…
APCC did reject the RA coordinate because it is malformed (comma instead of decimal point: “29,7” is wrong). This is coming from the AP V2 ASCOM driver, which I think should be using the ASCOM conversion routine, but I will have to double check.
Manuel, which version of the ASCOM platform do you have installed? Which version of the Astro-Physics V2 driver?
BTW, as I mentioned to you on the ap-gto Y! forum, a short term solution to the problem would be to swap the meaning of “.” and “,” in your Windows Regional settings in Control Panel.
-Ray
I don’t think that the ASCOM Util methods have ever returned a locale independent string, nor are they intended to.
Chris
Chris, are you sure of that? That particular utility function I thought was made to make it easy to format output for the Meade protocol, and it (Meade Protocol) never uses commas for decimal points.
-Ray
[quote=“rgralak, post:12, topic:2741”]
Chris, are you sure of that? That particular utility function I thought was made to make it easy to format output for the Meade protocol, and it (Meade Protocol) never uses commas for decimal points.
[/quote]Pretty sure, DegreesToDM and its friends call the VB.NET Format method and that’s said to be internationally aware.
AFAIK they are intended for user IO.
Simplest fix may be to replace commas with full stops in the output from DegreesToDM.
Chris
Yes, but before .Net there was the VB6 (I think) implementation. My guess is this might have changed in the .Net implementation. If it’s been like that all along it’s amazing this hadn’t been reported after many years of use. In fact looking at the driver log I had just fixed this exact issue in v5.07.01 of the driver so I am wondering if something changed recently in the ASCOM platform. It will be interesting to know which version of the ASCOM driver Manuel is using (5.07.02 is the latest public version).
Anyway, thanks Chris for posting on this.
-Ray
Hi,
My versions:
Workaround with US locale worked!.
Regards,
Manuel.
I’ve had a check through the ASCOM source archives and the format method hasn’t changed since the .NET component appeared in 2009. It uses a format method like
str = Format(mins, “00.00”)
and MSDN says that even though the format string uses a full stop it will use the local decimal separator.
I think that the VB6 version also uses the local decimal separator, It’s always been tricky in VB6 to format numbers using anything but the local format and the conversion from string to angle has code that explicitly looks for the local separator.
Chris