Up until now mosaic and plate solving has work perfectly but last night after running a two panel mosaic on NGC7822 SGpro moved the mount to target correctly and took an image. After plate solving the Scope ran out of control into the mount. Fortunately I was in the observatory at the time as I was also piggybacking. Normally I set the camera to cool and operate remotely. I tried to run this this sequence three times with the same result. I had to switch the mount off at the supply to prevent damage. Aborting the sequence had no effect. I checked the mount and it seemed to be working perfectly so I run an earlier created sequence which worked fine. It seems this particular event is the problem. The event was created with the same equipment profile as usual. I have recently installed the latest version of SGPro and this sequence was created with it. I will delete this sequence and recreate in the hope it will work correctly and test when clear skies allow. Has anyone any idea of what could have gone wrong or have experienced the same problem. I have an Ioptron CEM60 EC mount.
The only time I have had my CEM60 do anything like that was when it had a cable drag and lost its zero position. However, that does not seem to be the problem in your case since you said you were able to run a different sequence and everything worked okay. You could verify this is not the problem by just sending your mount to the zero position. If it goes to the correct position, you can cross that off the list.
Fred
Mount goes correctly to zero and park positions.
Would have thought that the mount or ASCOM would have prevented this.
I am checking to see if there is a log file I can look at.
Xsg_logfile_20170810210339.txt (223.3 KB)
I think this the correct log for the problem I had.
Hope this may help identifying the problem.
do you have any slew limits set to protect the equipment just in case ? I know this doesn’t answer your question but I just don’t trust any of this stuff to work all the time.
Thank you for your comments.
Yes the default limits are set. It usually does a meridian flip when required to move past a safe limit.
I had my iEQ30 Pro go completely out of control when I turned on a pulsed dew heater. It is just starting to get dewy at night now and that might be it. I tried the same dew heater with two other mounts since and they have worked fine.
It is not the dew heater. Runs fine on other targets. Been running with the dew heater for a year or two no problems with it. Note it repeatedly failed on this one target yet still works on other targets. I am hoping someone will analyse the log I have put up. I have rebuilt the same target in SGPro and will run it to test as soon as clear skies allow.
As a possibility…
I get a problem with this object with my Gemini. It it close to an RA of 00h and if your center is 23 h 59m at J2000, then conversion to JNow will wrap it across the 00h line. The Gemini just does not like this area.
When I was imaging CTB 1 (Abell 85), my scope would try to go off to somewhere around 13 hours, or just return an RA on the other side of the sky and the plate solve would fail.
So there could be a problem with the J2000/JNow conversion in the iOpton driver or what is passing to ASCOM/SGP.
I haven’t tried this object with the scope on my iOptron mount yet (bad weather this time of year and prepping for the eclipse), but I’ll give it a go when I get back…weather permitting.
Frank Z…
Thank for this info.
My mount is actually going to the correct co-ordinates and taking an image. This is not that close to the meridian so should not pose a problem. At my location it is at least 3 hours from the meridian. Will consider this when I get the chance to image again. Have set up a single target and another mosaic on this target for testing. Forecast is clear for a time tonight. Fingers crossed.
Would be nice to get some input from tech support.
I have made and tried other targets and all seem well.
NGC7822 still throws the scope towards the mount.
I seems that the fts header for the automatically NGC7822 image downloaded for the mosaic may have an error in it.
Stallarium gives a different co ordinate for it. The entries into the target are correct but the mount is sent to what seems to be the incorrect information in the foots error and then fails to solve. Finally sending the scope into the mount.
Attached image details the differences
My conclusion here is that SGpro is sending thew mount to the downloaded reference image and not to the selected target position within that image. I may be wrong but it would be nice if tech support would comment.
Peter did you ever find a solution to your issue?
This rings a bell in the back of my mind. I remember I did a mosaic and something quirky happening (I do not have log files, so I cannot confirm the old grey cells). I remember thinking that the mount appeared to center on the last image and did a relative slew to the next image. It would be entirely repeatable and one could verify by doing a simple mosaic with several panes and short exposures and watch what happens. I’m guessing now, but I expect that might get entertaining around the meridian and would require some careful logic to avoid issues.
In my case, it did work though!
No. Just avoid that target now.
Would have been nice to have tech support commented.
Always worry now that it could happen on another target.
I control the observatory remotely once opened up but now have to be there to be sure it does not run away.
I am also having an issue with the same mount non ec & plate solving. Many issues on here with AP mounts using JNow. This is your log & it appears this is where the trouble started, on a centering command. I am no programmer so hopefully the owner will step up & check this out.
[08/10/17 21:52:47.571][DEBUG] [Telescope Thread] Could not sync the rotator to 359.6 degrees (not connected)!
[08/10/17 21:52:47.574][DEBUG] [Telescope Thread] Auto center complete…
[08/10/17 21:52:47.749][DEBUG] [Center Scope Thread] Retrying auto center. Total Error > Allowable error: 1300094.3 > 50.0
[08/10/17 21:52:47.749][DEBUG] [Center Scope Thread] RA Error: -1300091.9
[08/10/17 21:52:47.749][DEBUG] [Center Scope Thread] DEC Error: -2514.2
[08/10/17 21:52:47.769][DEBUG] [Telescope Thread] Center telescope message received…
[08/10/17 21:52:47.769][DEBUG] [Telescope Thread] Solving with Plate Solver PlateSolve2…
[08/10/17 21:52:47.778][DEBUG] [Center Scope Thread] Error in auto center update thread, Thread was being aborted.
[08/10/17 21:52:47.904][DEBUG] [Telescope Thread] Performing auto center step 1…
[08/10/17 21:52:47.905][DEBUG] [Telescope Thread] Skipping step 1…
[08/10/17 21:52:47.905][DEBUG] [Telescope Thread] Auto center reference frame solved successfully…
[08/10/17 21:52:47.905][DEBUG] [Telescope Thread] Performing auto center step 3 (scope)…
[08/10/17 21:52:47.905][DEBUG] [Telescope Thread] Auto center slewing scope to match reference…
[08/10/17 21:52:47.908][DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 0.0660333333333333 (00h03m57.72s) Dec: 66.9190055555556 (66°55’08.42")
[08/10/17 21:52:47.908][DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[08/10/17 21:52:47.909][DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 0.0821863032282013 Dec: 67.0131596178861
[08/10/17 21:52:50.971][DEBUG] [Telescope Thread] ASCOM Telescope: Error in Slew : SlewToTargetAsync failed. (ASCOM.InvalidOperationException: SlewToTargetAsync failed.
at ASCOM.iOptron.Telescope.SlewToTargetAsync()
at ASCOM.iOptron.Telescope.SlewToCoordinatesAsync(Double , Double )
at ASCOM.iOptron.Telescope.SlewToCoordinates(Double , Double ))
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 543
at ASCOM.DriverAccess.MemberFactory.MethodTargetInvocationExceptionHandler(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 678
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 422
at ASCOM.DriverAccess.Telescope.SlewToCoordinates(Double RightAscension, Double Declination) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1030
at p6.js(TelescopeInformation A_0, String& A_1)
[08/10/17 21:52:50.971][DEBUG] [Telescope Thread] Auto center slew to reference failed (Slew failed! SlewToTargetAsync failed.)…
[08/10/17 21:52:50.972][DEBUG] [Telescope Thread] Adding sequence level notification: Slew to reference failed. Slew failed! SlewToTargetAsync failed.
[08/10/17 21:52:55.241][DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[08/10/17 21:52:55.266][DEBUG] [MF Update Thread] Performing serialize…
[08/10/17 21:53:03.783][DEBUG] [Sequence Thread] Recovering the sequence (when centering the target)
[08/10/17 21:53:03.783][DEBUG] [Sequence Thread] Adding sequence level notification: Something has gone wrong when centering the target
This appears to be an iOptron ASCOM driver issue, the line above says it cannot slew - if so, there is not much SGP can do about that. Just a thought - would this slew cause a meridian flip? I wonder how iOptron handle slews about the meridian. I cannot recall what my one did – I was still battling with extreme PE when I sent it back.