Since I’m new to SGP, the problems I’m having may be me. I did post to info@mainsequencesoftware.com and Ken directed me here.
I’m having issues with a Sequence I’ve made to monitor 21 Variable Stars in UMa. The sequence seems to work on an Alt/Az NexStar mount, with the ASCOM simulators, but fails miserably on my SmartEQ Pro.
Using the newest version of SGP, iOptron ASCOM drivers, and an hand controller firmware I’m getting multiple windows that say the Sequence Complete between each event image in the sequence. Sometimes as many four Sequence Complete, dissmiss, resume sequence cycles to successfully capture the next image event. Like I said, this doesn’t happen on my NexStar.
my log can be found at:
I see problems in the log, but don’t have a clue what they mean.
the variable star sequence can be found at:
Particulars
Mount: iOptron SmartEq Pro
ASCOM scope: iOptron ASCOM Driver for 2013 and earlier
Camera: Camera V2 simulator
The sequence was 21 variable stars in UMa, each with 5 events
Camera and mount connected and grayed out
Pressing “run sequence”… slewing to first target
The message Sequence Complete appeared first at end of slew when the mount beeped end of slew.
I dismissed the window, it took the first event image, downloaded and the Sequence Complete happened again.
Contacting iOptron support says “SGP should work with ASCOM V3.11 directly(no POTH).”
Should and does are two very different things.
Has anyone gotten an iOptron SmartEQ Pro working with SGP and does anyone have any suggestion?
When you click “Run Sequence”, do you get a pop-up dialog telling you that your mount is parked and then SGPro asking of it’s OK to unpark it when the sequence starts? The problem is that every time you click it, SGPro quite because the mount is parked.
[2/15/2016 9:20:47 AM] [DEBUG] [Sequence Thread] Mount is parked! Aborting capture event (and sequence… recovery is not allowed here… assuming mount has been parked for safety).
While I’ve seen reports about the mount being parked and asking to unpark it in other software, I have never seen the popup that you are asking about while running SGPro. I never park/unpark the mount and as far as I know there isn’t any way to do it. Park isn’t even in the SmartEQ’s manual.
Should I ask iOptron about the mount being parked?
I’m not sure… racking my brain. I am not sure how this can happen right now. When you click run sequence, one of the first things SGPro will do is connect your mount (if needed) and then check to see if it’s parked. If it is parked it will ask for your permission to unpark it. Since you are not seeing this, it means your mount is not parked when you click the run sequence button (I think). Then… about 5 seconds later SGPro quits because your mount is parked.
I’ve never turned on ASCOM logging before so I may not have done as asked.
I tried a run at this morning with the same results. The link to the sequence remains the same as above. The Park problem shows up at 11:12:00 near the bottom of the SGPro log. Problems show up in the ASCOM log at 11:11:54.871
with Index was outside the bounds of the array messages.
It’s not obvious why there should be a parked message from SGP, AtPark is false and there’s no obvious park exception. But maybe the index errors are interpreted as a park error. It’s strange that some get SideofPier commands work and some seem to give exceptions.
Maybe the two logs will make sense to Ken, it may also be worth involving iOptron, they may be able to give further information - or want to fix that index exception.
@Chris is right about the side of pier issue… you’ll need to contact iOptron about that… for the issue you are reporting though, it is not relevant (it might lead to problems later though).
The problem here is kind of disguising itself as a park issue… it does not appear to be related to this since your mount is not able to park. SGPro is actually quitting because it is not able to convince your mount to track (and not doing a great job of logging or reporting it)… we can fix that part, but I’m not sure why your mount reports it is not tracking.
11:12:00.751 Tracking Get False
I have made one change that I hope will accommodate for situations like this in a more user friendly manner…
I loaded 2.5.0.12 this morning, but I’m not sure much has changed although you may not have addressed the problem yet. I still get the window with dismiss about 1/2 the time and then have to resume
Yes, 2.5.0.12 should have addressed any remaining issues in SGPro. If it didn’t, it seems like a problem with your mount or the driver. You can see here, within the span of a couple seconds, your mount reports both true and false for “IsTracking” with no command in between to actually toggle the tracking state. Something is wrong here:
09:17:25.724 Tracking Get GET Tracking - .NET > 09:17:25.724 Tracking Get True
09:17:25.750
09:17:25.750 Slewing Get GET Slewing - .NET
09:17:26.423 Slewing Get False
09:17:26.433
09:17:26.433 AtPark Get GET AtPark - .NET
09:17:26.433 AtPark Get False
09:17:26.434
09:17:26.434 Tracking Get GET Tracking - .NET > 09:17:27.145 Tracking Get False
Looks like it is the SmartEQ Pro mount and not the ASCOM driver. I have an older iOptron original MiniTower that uses the same driver. I connected to SGPro today with it and the run was flawless.
Now to get the MiniTower on a wedge
Thanks for the help and I’ll watch to see if anyone has success or problems with the SmartEQ Pro.
