When I used used 0.5.2 for the first time last night I had a problem with AT hanging when recentering.
I was using a Canon 500D controlled by APT and a EQ5 (EQASCOM) mount. My images were solved OK, however when I had the sync & recentre options selected the AT status bar would show recentreing but the mount did not move and AT stopped responding to user input. I needed to use task manager to shutdown AT.
Last time I was imaging with 0.5.1 this worked fine.
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've seen this issue with 0.5.2 as well. It was being caused by the scope being more than 45 degrees away from the coordinates of the sync command sent by AT. EQASCOM therefore ignores the sync, but AT appears to get stuck after the sync is ignored.
The solution is to either slew the scope (say with Stellarium or CdC) to the approximate location of your target image, or use the Goto feature of AT rather than Capture and Solve.
I've got some more detail on the issue in some forum posts that may help you diagnose if you're seeing the same thing. Here are the links to the posts:-
My problem was different, the scope was only a few arc minutes out of position. The sync appears to have worked, looking at CdC the position had been undated.
I haven't had chance to try again since I had the problem due to cloud, light summer skies and having to get up early for work :-(
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I to have the same issue, tried both the X86 and x64 bit versions. I'd slew to a target (Dahib) with the Sky6 -> Vixen SS2K-PC controlling a Vixen Atlux. Plate slew - generally pointing was 2 arc minutes off (which is pretty large for my permanently mounted rig). I had sync and repoint ticked - it would say Centering but no slew seemd to occur; there was no observable change of coordinates, the SS2K didn't show a change of alignment stars after the sync and it wouldn't get out of the Centering feedback loop. At the camera the stars hadn't moved at all.
Be great if folks have ideas (otherwise try version 0.5.1 might be on the cards)!
Thanks all, Matthew
PS
Opening a saved image M20) and issuing a Solve and goto worked fairly fine - so not sure how localised this bug is!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well just gave v0.5.1 32 bit a try - same result, plate solved a 120 second shot of M20 that was about 3 arc minutes off centred in about 40 seconds Both sync and slew - were selected. The ASCOM mount selected was a Sky Controlled Telescope; However when I went into properties - well oopsie! I had set a The Sky 6 - correct version, but I had ticked disable sync to protect the Tpoint model. I guess this eliminated the re-pointing - silly me! Will try it with sync enabled and see how it performs soon!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So still more errors on the re-centering. I ensure the ASCOM driver was selected for the Sky6 and syncs were enabled, regardless of the Tpoint model, and that the Sky6 didn't ask for syncs to be confirmed.
Solved for M4 - which was a few arc seconds off in RA and an arc minute or two in DEC off, but the sync and re-slew failed. Checking the log it refused the sync because the reported RA DEC had a 44 degree pointing error! Meaning the conversion of RA / DEC must have been in a format that the Sky6 really didn't like!
Well next tests I am seeing if direct connecting AT to the Vixen SkySensor2000-PC hand controller (bypassing The Sky6 totally) will work. If it does work then the issue is either with The Sky6 or the SS2K driver it is using.
Next I will try The Sky6 -> Telescope API -> Latest V2.0.6 Vixen SS2K driver and see if AT pointing to the Sky 6 with that telescope driver option also allows syncs. By Default The Sky6 -> Vixen SS2K driver (which I intuit is a bit dated, but when you put Telescope API into the drive chain you lose (diasble) all the useful Telescope Initialisation and end of night Park options)!
Determined to get to the bottom of all this!
Last edit: Matthew 2013-06-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had another chance to try think last night and didn't have the problem. So I'm not sure if the problem is real or I did something wrong the first time it happened, as I have made no changes to my set up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried linking Astro Tortilla v0.51 32 bit directly to the latest Vixen SkySensor2000-PC driver and it worked correctly for sync and repoint. So It looks to me my error with the sync being ignored stems from within the Sky6.
Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just checked with Software Bisque, Tom Bisque states the the Sky6 does allow sync's and there are VB scripts to test this...
Tom Bisque replied on Tue, Jun 4 2013 3:01 AM
Maybe you can ask them.
I mean there is no reason that you can't use third party applications (or a simple VB script like the ones that show exactly how this is done) to Sync with TheSky6/TheSkyX.
Although keep in mind when using TPoint this is simply a big no no or "should not" be (with good reasons) be allowed! Other apps. I see are now letting the user check or uncheck "Prohibit Syncs" this exact reason. If you are Syncing when a TPoint model is present you have just polluted all the modeling.
Like others who are already doing it, this should be an option in the third party application. Allow Syncs or not allow Syncs. The problem is not with TheSky pre se or it should not be "preventing" this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Syncing is pretty much the point of using AT. If you're off the mark after a slew, either the TPoint model creation was faulty, or there was a significant failure in the mount (such as motor binding or axle clutch slip). With the latter, a model of the sky doesn't help if you're not pointing at the real target with your scope :-)
With the former, did you use plate-solving for creating it? If not, all bets are off when trying to locate yourself with a plate-solve.
AT does have the "see where I am" mode with all the check-boxes turned off, but then you simply know whether your pointing model is accurate or not, and AT can't automatically go to the right place as the model is not getting updated at the scope driver. Adjusting the sky model is mathematically feasible, as you do know your scope RA-axis angle to true RA axis and cone error, so all you "need" to do is effectively rotate the model around a bit to compensate for the slippage to match the current plate-solved position on the sky.
EQAscom builds its model from the sync-points as you go thru the night, although there isn't that much need for it with plate-solve based syncing and decent polar alignment. I'm thinking of adding a EQAscom feature to clear the sync-points periodically, having a couple of sync points in close proximity isn't good, and with long slews there might be mechanical error sources.
One basic setting I use to overcome the EQASCOM 45 degree sync limit is using a 30 degree search radius. If a plate-solve fails, I know there's a real need to crawl back outdoors into the freezing night and see what's going on.
-Antti
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fail message - trying The Sky6 -> Telescope Simulator (had slewed to M8 and solved image for M20) first with Tpoint enabled, then Tpoint removed:
2013-05-27 01:01:41,388 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 804, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'ASCOM TheSky Driver', u'Cannot sync because TPOINT is in use.', None, 1000440, -2147220480), None)</comobject>
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 813, in OnBtnGOButton
File "astrotortilla\gui\MainFrame.pyo", line 774, in showTracebackDialog
AttributeError: 'str' object has no attribute 'format_exc'
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 876, in OnScopePollTimer
AttributeError: 'NoneType' object has no attribute 'RA'
2013-06-03 19:56:34,505 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 802, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'TheSky', u'Permission denied', None, 1000070, -2146828218), None)</comobject>
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 813, in OnBtnGOButton
File "astrotortilla\gui\MainFrame.pyo", line 774, in showTracebackDialog
AttributeError: 'str' object has no attribute 'format_exc'
2013-06-03 19:58:31,470 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 802, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'TheSky6.Document', u'Limits exceeded.\n\nError code = 218 (0xda).', u'C:\PROGRAM FILES (X86)\SOFTWARE BISQUE\THESKY6\Help\TheSkyV6.hlp', 98419, -2147220286), None)</comobject>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
More than welcome! One other suggestion. Could you plate solve and allow a corrective slew to be issued without enforcing a sync? By this I mean offer the option to preserve the telescope systems pointing model, but once you have the target's pointing error determined - issue a slew to those revised coordinates (current coordinates + pointing error). At present if you un-tick sync then you can't tick slew to target - that is what I would love enhanced!
I expect what AT is doing now (quite reasonably) is after a successful solve - is to re sync to the real pointing position then it issues a slew to original target coordinates.
What I would like an option of is not to sync but still to re-slew! This should allow my shots to be correctly framed without having to fight the Sky6's preservation of its Tpoint model (or not) at any cost!
In future what I will probably do is:
Switch on mount, check time
Connect Sky6 to scope - slew to a target,
Disconnect Sky6 from scope
Image and plate solve in AT - with it directly connected to Vixen SS2K-PC hand controller
Repeat steps 2-4 twice more - to get a 3 star alignment model at the SS2K-PC hand controller.
Re-connect Sky6 to SS2K
Create a 50 - 150 point Sky model in Tpoint
Use AT for plate solves and try its go to this image (seems to work okay - need to determine its pointing accuracy
This is the stage I would like to use AT to refine my pointing by 2-3 arc minutes generally, but I have to find a way to do it that doesn't fight with The Sky6 and Tpoint!
Many thanks,
Matthew
Last edit: Matthew 2013-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any updates on this bug and feature request (re-centre without the sync option)? Could you please give us a time frame by which this might be achieved?
Thanks, Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No timeframe at the moment, the math is non-trivial and there's no way to try out different options until August due to light summer skies. Most of the AT development is done during astrophotography nights, when trying out new things is easy.
The current version is also pretty much at the end of its road, new version is on the drawing board, this time with a user interface instead of engineering interface.
-Antti
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the re-centre without issuing a sync option that difficult?
Surely its just subtract target RA / DEC from image RA / DEC and issue a goto for the delta? So just a couple of subtractions?
Once the Plate solve is done - isn't that the really hard part, I'd imagine the re-point the scope - either if SYNC is selected by issuing the SYNC followed by issuing a goto the original target RA / DEC; or if No SYNC is select but re-point could be selected then you'd simply issue a goto (RA + Plate Solved RA delta) / (DEC plus Plate Solved DEC delta) was rather straight forward by comparison - all the logic would have to be already there!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spherical coordinate systems are annoying away from equator. Combining the mechanical pointing errors with conical error and polar alignment error, the simple subtraction becomes a bit more involved. That's why AT prefers to sync the mount and have the mount driver take care of the more complex math.
We have been looking at the issue for a better polar alignment routine, where we can't sync the mount.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for that explanation - I'd simplified to reason if the pointing is say 2 arc minutes high in RA and 45 arc seconds East in DEC - then a sync and re goto - versus a slew in RA 120 arc seconds and DEC 45 arc seconds East was a simple solution - you could do that then use a bit of fuzzy logic to loop a few more times - shoot, plate solve and weight the correction to get within a targeted amount.
Totally agree that spherical trig wasn't my cup of tea - dad loved it - he was a surveyor and deep sea racer (navigator) - wished I had absorbed more of what he tried to pass on to me!
Best regards, Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone,
I realise that this is an old thread, but I think I ran into the 'freeze on recentering' problem last night. In fact I've think I've experienced it previously but didn't realise what was happening. This is what happened last night when I was going after the M82 supernova with my 10" Meade LX200GPS.
I slewed to target with the Meade handset, took a 5 second exposure, connected AT (0.5.2) to the scope, checked the sync and re-slew boxes, then solved the image. The imaged solved and reslew occured. I next took another second 5 sec exposure in which I could see M82 in the corner of the image, so to center the image I asked AT to solve again which it did but then frooze with message recenering displayed. I gave it approx 5 minutes then had to Ctr-Alt-Del to force close AT. I restarted AT and tried again with the same result, but since by now I had cloud cover, I let AT the re-centering step run for maybe 15 mins, but again had to force close the application.
Does AT v6 fix this issue and if yes, which version x64 or x86 should I download. I am using a Windows 7 Professional i5 (2 core) x64 based laptop, which suggests I need the x64, but my current AT version (0.5.2) is installed under program x86 directory, so not being overally IT literate I am confused...!
Thanks for your help.
Geof
PS the cloud never cleared so the only image I got was the 5sec AT solve exposure, which did in fact show the supernova ;-). I'm hoping to go after it again in the coming days if I can get AT to slew to and center the target.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use AstroTortilla to plate-solve, sync and re-slew to the target till its within a certain limit.
I note that if I set the limit small, then EQASCOM will often NOT re-slew to the target. This causes AstroTortilla to crash "displays re-centering" but because EQASCOM did not issue a slew, AT never gets a slew complete message and hangs. This is with the latest v6 release of AT. It is repeatable.
Robert Brown
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Robert,
This sounds identical to my experience with v0.5.2 posted a couple of weeks ago, since when I have installed v6. I have a slightly better experience with v6 in that last time out at least it did not hang on re-centering, but also it did not make any slew to center the target. I was after SN2014J in M82 and the first AT slew put M82 in the corner of the displayed FOV, which I estimate was within approx 20 Arcmins, same as with v0.5.2, but despite AT solving the new image location and stating that it was re-centering, on completion of that no slew adjustment occured. I therefore had to resort to the old method of using the hand controller to center the target. This still represents a vast improvement on getting on target without AT, but it most certainly did not center it to within 1 Arcmin, so I'm interested to learn if their is a solution.
Cheers,
Geof
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am using AT v6 with EQMOD and Nebulosity. Solving works perfectly and 'goto image" as well. However both "sync scope" after solve and "reslew to target" cause AT to lock up. Using ASCOM trace on EQMOD, I note that "goto image" is sending a slewtocoordinatesasync() command, but that "sync scope" is using synctocoordinates() rather than an a Async equivalent. Could this be the cause?
Trace from failed "sync scope"
22:26:39 GET Tracking :True
22:26:39 GET Slewing :False
22:26:39 GET RightAscension :6.61072149401405
22:26:39 GET Declination :10.6973046875
22:26:39 GET TargetRightAscension :6.69632434844971
22:26:39 GET TargetDeclination :9.87802314758301
22:26:39 COMMAND SyncToCoordinates(6.79281718128953,9.29832249570382)
22:26:39 GET RightAscension :6.61071364631417
22:26:39 GET EquatorialCoordinateType :0
22:26:39 GET Declination :10.6973046875
22:26:39 GET RightAscension :6.6107104480691
Trace from succesful "goto image"
21:50:03 Let TargetRightAscension(6.79275967196484)
21:50:03 Let TargetDeclination(9.30477352736584)
21:50:03 GET CanSlewAsync :T
21:50:03 COMMAND SlewToCoordinatesAsync(6.79275967196484,9.30477352736584)
21:50:03 GET Tracking :False
21:50:03 GET Slewing :True
21:50:03 GET RightAscension :7.90793627139761
21:50:03 GET Declination :-26.4766015625
21:50:03 GET TargetRightAscension :6.79275967196484
21:50:03 GET TargetDeclination :9.30477352736584
21:50:04 GET TargetRightAscension :6.79275967196484
21:50:04 GET TargetDeclination :9.30477352736584
21:50:04 GET RightAscension :8.14618194898641
21:50:04 GET Declination :-29.715625
21:50:04 GET Tracking :False
21:50:04 GET Slewing :True
Regards
astroman2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well its been quite a while, rebuilt my Astrolab PC after a CPU fail and had to do some small soldering to replace the lithium battery in my SkySensor2000-PC controller. So once the clouds clear I'd like to give this another try.
I ponder if anyone else has got Astro Tortilla's syncs working when using the Sky6 and Tpoint to control an ASCOM scope?
Also the bug I noted on the 5th June 2013 - does anyone know if that got solved yet (the sync failure error handling Antti said that would get worked on)? Software Bisque seem to think their code is operational correctly...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I used used 0.5.2 for the first time last night I had a problem with AT hanging when recentering.
I was using a Canon 500D controlled by APT and a EQ5 (EQASCOM) mount. My images were solved OK, however when I had the sync & recentre options selected the AT status bar would show recentreing but the mount did not move and AT stopped responding to user input. I needed to use task manager to shutdown AT.
Last time I was imaging with 0.5.1 this worked fine.
James
Hi James,
I've seen this issue with 0.5.2 as well. It was being caused by the scope being more than 45 degrees away from the coordinates of the sync command sent by AT. EQASCOM therefore ignores the sync, but AT appears to get stuck after the sync is ignored.
The solution is to either slew the scope (say with Stellarium or CdC) to the approximate location of your target image, or use the Goto feature of AT rather than Capture and Solve.
I've got some more detail on the issue in some forum posts that may help you diagnose if you're seeing the same thing. Here are the links to the posts:-
http://www.astronomyforum.net/astronomy-software-forum/159481-need-help-astrotortilla-part-ii.html#post1057727652
http://www.astronomyforum.net/astronomy-software-forum/159481-need-help-astrotortilla-part-ii.html#post1057728526
Hope this helps.
Richard
My problem was different, the scope was only a few arc minutes out of position. The sync appears to have worked, looking at CdC the position had been undated.
I haven't had chance to try again since I had the problem due to cloud, light summer skies and having to get up early for work :-(
James
James,
I to have the same issue, tried both the X86 and x64 bit versions. I'd slew to a target (Dahib) with the Sky6 -> Vixen SS2K-PC controlling a Vixen Atlux. Plate slew - generally pointing was 2 arc minutes off (which is pretty large for my permanently mounted rig). I had sync and repoint ticked - it would say Centering but no slew seemd to occur; there was no observable change of coordinates, the SS2K didn't show a change of alignment stars after the sync and it wouldn't get out of the Centering feedback loop. At the camera the stars hadn't moved at all.
Be great if folks have ideas (otherwise try version 0.5.1 might be on the cards)!
Thanks all, Matthew
PS
Opening a saved image M20) and issuing a Solve and goto worked fairly fine - so not sure how localised this bug is!
Well just gave v0.5.1 32 bit a try - same result, plate solved a 120 second shot of M20 that was about 3 arc minutes off centred in about 40 seconds Both sync and slew - were selected. The ASCOM mount selected was a Sky Controlled Telescope; However when I went into properties - well oopsie! I had set a The Sky 6 - correct version, but I had ticked disable sync to protect the Tpoint model. I guess this eliminated the re-pointing - silly me! Will try it with sync enabled and see how it performs soon!
So still more errors on the re-centering. I ensure the ASCOM driver was selected for the Sky6 and syncs were enabled, regardless of the Tpoint model, and that the Sky6 didn't ask for syncs to be confirmed.
Solved for M4 - which was a few arc seconds off in RA and an arc minute or two in DEC off, but the sync and re-slew failed. Checking the log it refused the sync because the reported RA DEC had a 44 degree pointing error! Meaning the conversion of RA / DEC must have been in a format that the Sky6 really didn't like!
Well next tests I am seeing if direct connecting AT to the Vixen SkySensor2000-PC hand controller (bypassing The Sky6 totally) will work. If it does work then the issue is either with The Sky6 or the SS2K driver it is using.
Next I will try The Sky6 -> Telescope API -> Latest V2.0.6 Vixen SS2K driver and see if AT pointing to the Sky 6 with that telescope driver option also allows syncs. By Default The Sky6 -> Vixen SS2K driver (which I intuit is a bit dated, but when you put Telescope API into the drive chain you lose (diasble) all the useful Telescope Initialisation and end of night Park options)!
Determined to get to the bottom of all this!
Last edit: Matthew 2013-06-02
I had another chance to try think last night and didn't have the problem. So I'm not sure if the problem is real or I did something wrong the first time it happened, as I have made no changes to my set up.
Hi James,
I just tried linking Astro Tortilla v0.51 32 bit directly to the latest Vixen SkySensor2000-PC driver and it worked correctly for sync and repoint. So It looks to me my error with the sync being ignored stems from within the Sky6.
Matthew
Just checked with Software Bisque, Tom Bisque states the the Sky6 does allow sync's and there are VB scripts to test this...
Tom Bisque replied on Tue, Jun 4 2013 3:01 AM
Maybe you can ask them.
I mean there is no reason that you can't use third party applications (or a simple VB script like the ones that show exactly how this is done) to Sync with TheSky6/TheSkyX.
Although keep in mind when using TPoint this is simply a big no no or "should not" be (with good reasons) be allowed! Other apps. I see are now letting the user check or uncheck "Prohibit Syncs" this exact reason. If you are Syncing when a TPoint model is present you have just polluted all the modeling.
Like others who are already doing it, this should be an option in the third party application. Allow Syncs or not allow Syncs. The problem is not with TheSky pre se or it should not be "preventing" this.
Syncing is pretty much the point of using AT. If you're off the mark after a slew, either the TPoint model creation was faulty, or there was a significant failure in the mount (such as motor binding or axle clutch slip). With the latter, a model of the sky doesn't help if you're not pointing at the real target with your scope :-)
With the former, did you use plate-solving for creating it? If not, all bets are off when trying to locate yourself with a plate-solve.
AT does have the "see where I am" mode with all the check-boxes turned off, but then you simply know whether your pointing model is accurate or not, and AT can't automatically go to the right place as the model is not getting updated at the scope driver. Adjusting the sky model is mathematically feasible, as you do know your scope RA-axis angle to true RA axis and cone error, so all you "need" to do is effectively rotate the model around a bit to compensate for the slippage to match the current plate-solved position on the sky.
EQAscom builds its model from the sync-points as you go thru the night, although there isn't that much need for it with plate-solve based syncing and decent polar alignment. I'm thinking of adding a EQAscom feature to clear the sync-points periodically, having a couple of sync points in close proximity isn't good, and with long slews there might be mechanical error sources.
One basic setting I use to overcome the EQASCOM 45 degree sync limit is using a 30 degree search radius. If a plate-solve fails, I know there's a real need to crawl back outdoors into the freezing night and see what's going on.
-Antti
Fail message - trying The Sky6 -> Telescope Simulator (had slewed to M8 and solved image for M20) first with Tpoint enabled, then Tpoint removed:
2013-05-27 01:01:41,388 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 804, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'ASCOM TheSky Driver', u'Cannot sync because TPOINT is in use.', None, 1000440, -2147220480), None)</comobject>
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 813, in OnBtnGOButton
File "astrotortilla\gui\MainFrame.pyo", line 774, in showTracebackDialog
AttributeError: 'str' object has no attribute 'format_exc'
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 876, in OnScopePollTimer
AttributeError: 'NoneType' object has no attribute 'RA'
2013-06-03 19:56:34,505 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 802, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'TheSky', u'Permission denied', None, 1000070, -2146828218), None)</comobject>
Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 813, in OnBtnGOButton
File "astrotortilla\gui\MainFrame.pyo", line 774, in showTracebackDialog
AttributeError: 'str' object has no attribute 'format_exc'
2013-06-03 19:58:31,470 - astrotortilla.Main - ERROR - Sync failed: Traceback (most recent call last):
File "astrotortilla\gui\MainFrame.pyo", line 802, in OnBtnGOButton
File "astrotortilla\engine.pyo", line 572, in gotoCurrentTarget
File "astrotortilla\telescope\ASCOMTelescope.pyo", line 222, in position
File "<comobject thesky.telescope="">", line 3, in SyncToCoordinates
com_error: (-2147352567, 'Exception occurred.', (0, u'TheSky6.Document', u'Limits exceeded.\n\nError code = 218 (0xda).', u'C:\PROGRAM FILES (X86)\SOFTWARE BISQUE\THESKY6\Help\TheSkyV6.hlp', 98419, -2147220286), None)</comobject>
Thanks for these, they'll come handy to fix the AT failure of handling the sync-error.
-Antti
More than welcome! One other suggestion. Could you plate solve and allow a corrective slew to be issued without enforcing a sync? By this I mean offer the option to preserve the telescope systems pointing model, but once you have the target's pointing error determined - issue a slew to those revised coordinates (current coordinates + pointing error). At present if you un-tick sync then you can't tick slew to target - that is what I would love enhanced!
I expect what AT is doing now (quite reasonably) is after a successful solve - is to re sync to the real pointing position then it issues a slew to original target coordinates.
What I would like an option of is not to sync but still to re-slew! This should allow my shots to be correctly framed without having to fight the Sky6's preservation of its Tpoint model (or not) at any cost!
In future what I will probably do is:
Repeat steps 2-4 twice more - to get a 3 star alignment model at the SS2K-PC hand controller.
This is the stage I would like to use AT to refine my pointing by 2-3 arc minutes generally, but I have to find a way to do it that doesn't fight with The Sky6 and Tpoint!
Many thanks,
Matthew
Last edit: Matthew 2013-06-08
Any updates on this bug and feature request (re-centre without the sync option)? Could you please give us a time frame by which this might be achieved?
Thanks, Matthew
No timeframe at the moment, the math is non-trivial and there's no way to try out different options until August due to light summer skies. Most of the AT development is done during astrophotography nights, when trying out new things is easy.
The current version is also pretty much at the end of its road, new version is on the drawing board, this time with a user interface instead of engineering interface.
-Antti
Is the re-centre without issuing a sync option that difficult?
Surely its just subtract target RA / DEC from image RA / DEC and issue a goto for the delta? So just a couple of subtractions?
Once the Plate solve is done - isn't that the really hard part, I'd imagine the re-point the scope - either if SYNC is selected by issuing the SYNC followed by issuing a goto the original target RA / DEC; or if No SYNC is select but re-point could be selected then you'd simply issue a goto (RA + Plate Solved RA delta) / (DEC plus Plate Solved DEC delta) was rather straight forward by comparison - all the logic would have to be already there!
Spherical coordinate systems are annoying away from equator. Combining the mechanical pointing errors with conical error and polar alignment error, the simple subtraction becomes a bit more involved. That's why AT prefers to sync the mount and have the mount driver take care of the more complex math.
We have been looking at the issue for a better polar alignment routine, where we can't sync the mount.
Thanks for that explanation - I'd simplified to reason if the pointing is say 2 arc minutes high in RA and 45 arc seconds East in DEC - then a sync and re goto - versus a slew in RA 120 arc seconds and DEC 45 arc seconds East was a simple solution - you could do that then use a bit of fuzzy logic to loop a few more times - shoot, plate solve and weight the correction to get within a targeted amount.
Totally agree that spherical trig wasn't my cup of tea - dad loved it - he was a surveyor and deep sea racer (navigator) - wished I had absorbed more of what he tried to pass on to me!
Best regards, Matthew
Hi everyone,
I realise that this is an old thread, but I think I ran into the 'freeze on recentering' problem last night. In fact I've think I've experienced it previously but didn't realise what was happening. This is what happened last night when I was going after the M82 supernova with my 10" Meade LX200GPS.
I slewed to target with the Meade handset, took a 5 second exposure, connected AT (0.5.2) to the scope, checked the sync and re-slew boxes, then solved the image. The imaged solved and reslew occured. I next took another second 5 sec exposure in which I could see M82 in the corner of the image, so to center the image I asked AT to solve again which it did but then frooze with message recenering displayed. I gave it approx 5 minutes then had to Ctr-Alt-Del to force close AT. I restarted AT and tried again with the same result, but since by now I had cloud cover, I let AT the re-centering step run for maybe 15 mins, but again had to force close the application.
Does AT v6 fix this issue and if yes, which version x64 or x86 should I download. I am using a Windows 7 Professional i5 (2 core) x64 based laptop, which suggests I need the x64, but my current AT version (0.5.2) is installed under program x86 directory, so not being overally IT literate I am confused...!
Thanks for your help.
Geof
PS the cloud never cleared so the only image I got was the 5sec AT solve exposure, which did in fact show the supernova ;-). I'm hoping to go after it again in the coming days if I can get AT to slew to and center the target.
I use AstroTortilla to plate-solve, sync and re-slew to the target till its within a certain limit.
I note that if I set the limit small, then EQASCOM will often NOT re-slew to the target. This causes AstroTortilla to crash "displays re-centering" but because EQASCOM did not issue a slew, AT never gets a slew complete message and hangs. This is with the latest v6 release of AT. It is repeatable.
Robert Brown
Hi Robert,
This sounds identical to my experience with v0.5.2 posted a couple of weeks ago, since when I have installed v6. I have a slightly better experience with v6 in that last time out at least it did not hang on re-centering, but also it did not make any slew to center the target. I was after SN2014J in M82 and the first AT slew put M82 in the corner of the displayed FOV, which I estimate was within approx 20 Arcmins, same as with v0.5.2, but despite AT solving the new image location and stating that it was re-centering, on completion of that no slew adjustment occured. I therefore had to resort to the old method of using the hand controller to center the target. This still represents a vast improvement on getting on target without AT, but it most certainly did not center it to within 1 Arcmin, so I'm interested to learn if their is a solution.
Cheers,
Geof
Hi,
I am using AT v6 with EQMOD and Nebulosity. Solving works perfectly and 'goto image" as well. However both "sync scope" after solve and "reslew to target" cause AT to lock up. Using ASCOM trace on EQMOD, I note that "goto image" is sending a slewtocoordinatesasync() command, but that "sync scope" is using synctocoordinates() rather than an a Async equivalent. Could this be the cause?
Trace from failed "sync scope"
22:26:39 GET Tracking :True
22:26:39 GET Slewing :False
22:26:39 GET RightAscension :6.61072149401405
22:26:39 GET Declination :10.6973046875
22:26:39 GET TargetRightAscension :6.69632434844971
22:26:39 GET TargetDeclination :9.87802314758301
22:26:39 COMMAND SyncToCoordinates(6.79281718128953,9.29832249570382)
22:26:39 GET RightAscension :6.61071364631417
22:26:39 GET EquatorialCoordinateType :0
22:26:39 GET Declination :10.6973046875
22:26:39 GET RightAscension :6.6107104480691
Trace from succesful "goto image"
21:50:03 Let TargetRightAscension(6.79275967196484)
21:50:03 Let TargetDeclination(9.30477352736584)
21:50:03 GET CanSlewAsync :T
21:50:03 COMMAND SlewToCoordinatesAsync(6.79275967196484,9.30477352736584)
21:50:03 GET Tracking :False
21:50:03 GET Slewing :True
21:50:03 GET RightAscension :7.90793627139761
21:50:03 GET Declination :-26.4766015625
21:50:03 GET TargetRightAscension :6.79275967196484
21:50:03 GET TargetDeclination :9.30477352736584
21:50:04 GET TargetRightAscension :6.79275967196484
21:50:04 GET TargetDeclination :9.30477352736584
21:50:04 GET RightAscension :8.14618194898641
21:50:04 GET Declination :-29.715625
21:50:04 GET Tracking :False
21:50:04 GET Slewing :True
Regards
astroman2
Finally solved my problem. If EQMOD is set to "append on Sync", then AT locks up. Once EQMOD is set to "Dialog based" sync, AT works fine.
Cheers
Astroman2
Well its been quite a while, rebuilt my Astrolab PC after a CPU fail and had to do some small soldering to replace the lithium battery in my SkySensor2000-PC controller. So once the clouds clear I'd like to give this another try.
I ponder if anyone else has got Astro Tortilla's syncs working when using the Sky6 and Tpoint to control an ASCOM scope?
Also the bug I noted on the 5th June 2013 - does anyone know if that got solved yet (the sync failure error handling Antti said that would get worked on)? Software Bisque seem to think their code is operational correctly...