I have been using SGP for years. I am using a Paramount MX and always start my sequences from park.
On the few occasions I have been able to image over the last few months, the mount has slewed to the target but the tracking has not turned on. I immediately checked the ASCOM settings and the tracking option had not been disabled - and the initial AF run was trying to do HFR on streaks. Mount control was still working fine through ASCOM and a resume worked fine.
Has anyone else seen this? I wonder if something changed in the last few releases, The order of start up events changed recently (AF before centering) and I wonder if something got trampled.
I’ve seen the same behaviour but not over the last week. I’ve also had trouble with the centre feature not moving the mount even when the target is within a couple of pixels of centre. Centering then fails. I’m blaming ASCOM 6.5 as this all started after I updated the platform. I’ve gone back from Device Hub to Generic hub and all seems (touch wood) to be operating as before. It might be worth trying Generic Hub to see if you get the same behaviour.
Excellent point. I’m using latest ASCOM but not the device hub for mount. I should be able to do a back to back experiment, even in daylight to see if it turns on and off with ASCOM version. Thanks
Did a swap back and forth with earlier SGP version. Inconclusive. Rolled back to ASCOM 6.4 and we will see how we go. I only use Device Hub for my ROR. I have been using it all year without any issues. The TSX driver is a hub. Another thread is reporting some comms issues and I have tacked onto there, as it might be related.
I’ve seen something similar with ASCOM’s 6.5 Device Hub.
I’ll run Device Hub to connect scope and dome and go to the target prior to opening SGPro. This is done when first starting a new target to see if the trees are cleared.
If all is OK I shut down Device Hub and start up SGPro while the dome and scope are at (near) target. The scope does not move and SGPro requires a restart.
If I shut down the scope driver after shutting down Device Hub, and then start SGPro, all works fine.
That sounds like the driver is not releasing the connection and disposing. If you can, could you try a simple slew and center from park, without using the hub. It would be useful to try and collectively establish if it is 6.5, since I see the same problem without using the device hub for the mount.
Hmmm… The Device hub was available for some time before the ASCOM 6.5 release. I used it with ASCOM 6.4 for my ROR, but not the mount.
I had been using ASCOM 6.4 with SGP in the early part of the year without any issues. I am having issues with ASCOM 6.5 // SGP 544 - but significantly, not every time. I have gone back to ASCOM 6.4 with SGP 544 and when it is dry, will try repeated tests.
This may be a timing thing - there may also have been some changes to the device hub (it will be documented on GIT). I’ll check.
If this helps, I have been having an ASCOM error message saying “DeviceHub caught a fatal exception during startup Hour value must be greater than or equal to 0 and less than 24”. This error has come up mid-sequence when trying to move the telescope (G53F) to either a new target or re-centre the current target. It doesn’t come up on startup as stated in the error message.
Already sent on another thread as there is also some odd behaviour connecting to my Atik Horizon II camera. SGP won’t connect on first click but does on second click. Here is the link to the logfile.
Tried 544 with ASCOM 6.4. It worked 5 times out of 6. I cannot recall this issue occurring before July.
So - as far as I can tell, I only get failures with SGP 544, but not all the time. I get failures with ASCOM 6.4 and 6.5 but not, as far as I know, with SGP 479.
This is a simple sequence, slew and center enabled, starting from park.
I’m going back to 479 and ASCOM 6.4 and confirm this combination is reliable as I recall.
[ update ] so far, I have not been able to make 479 with ASCOM 6.4 or 6.5 cause any issues. @Jared - maybe worth putting some more log entries in around this and running for diagnostics? As the issue is intermittent - I’m wondering if it is a timing thing - or a clash of instructions (synchronous vs asynchronous)
cheers - I’ll do a dozen dry runs with this version and note the exact times I set things running. I can do this in daylight. I just need to wait for a break in the rain. For each run, I start from the park position and after the sequence start, note whether the mount is tracking in TSX as the AF routine starts up. I fully disconnect SGP and close it down in-between sequence runs.
@Jared
Here you go. Hopefully something springs forth. Dropbox - File Deleted
I made four startup attempts from scratch: pass, fail, fail, pass at 19:35, 19:38, 19:42 and 19:46 respt
In between each, I disconnected and exited SGP, parked the mount and then ran SGP and ran sequence.
Not entirely sure. Unless I’m missing something the attempt at 19:35 looks like the only failed one. The logs are at least reporting that tracking started successfully for the other 3.
Here’s the 19:35 log where we attempted to start tracking but failed:
[08/24/20 19:35:09.954][DEBUG][Sequence Thread][SQ;] Attempting mount startup…
[08/24/20 19:35:09.983][DEBUG][Sequence Thread][SQ;] Mount is parked, unparking…
[08/24/20 19:35:09.986][DEBUG][Sequence Thread][SQ;] Dome: Shutter is open or is opening, will not send open command again
[08/24/20 19:35:09.986][DEBUG][Sequence Thread][SQ;] ASCOM Observatory: Reports shutter is open, continuing…
[08/24/20 19:35:09.986][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: OpenShutter command sent.
[08/24/20 19:35:09.986][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Waiting on Obs Shutter to open before unparking scope.
[08/24/20 19:35:10.987][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Observatory shutter opened.
[08/24/20 19:35:10.987][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Observatory slewing? False
[08/24/20 19:35:10.987][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Unpark message received.
[08/24/20 19:35:12.575][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Start tracking
[08/24/20 19:35:12.870][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Blocking for observatory slaving to complete
[08/24/20 19:35:13.585][DEBUG][Main Thread][SQ;] PopulateDataModel: Transferring view to the data model…
[08/24/20 19:35:13.591][DEBUG][MF Update Thread][SQ;] Performing serialize…
[08/24/20 19:35:13.872][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Observatory slaving complete
[08/24/20 19:35:14.974][DEBUG][Sequence Thread][SQ;] Mount is not tracking, start tracking…
[08/24/20 19:35:14.975][DEBUG][Sequence Thread][SQ;] ASCOM Telescope: Setting tracking state to True
Unfortunately not a lot to say from the SGP side of things here. It would be interesting to see a corresponding ASCOM log to see what the driver thought was going on. But as far as I can tell we asked the mount to unpark…then waited for the mount to state that it was indeed unparked and tracking…but after 30 seconds it times out. If the unpark was unsuccessful it should have thrown an error. Same if we set tracking to enabled and the device was parked.
thanks - I have added the ASCOM mount log files to the dropbox folder.
A couple of things I noted.
If I look at the telescope status in TSX at start of sequence, it goes through a number of states before it starts slewing. I have never monitored it before but I was puzzled by the intermittent delay between unparking and slewing. Sometimes it would all happen in a second or two, at other times, it would unpark, cycle through tracking on and off and then maybe 3-5 seconds later, start the slew to target.
When I noticed the mount was not tracking as the AF routine kicked in, I would intervene and cancel the AF. SGP then goes into the centering routine and I noted that on a few occasions, the mount started tracking as that process continued.
Unlike some others - I am not using the new ASCOM device hub, I am directly connecting Chris R’s ASCOM driver which is itself a hub. I know this driver has a defense mechanism that disables properties if the TSX API throws specific exceptions. I checked the driver setup - nothing was altered and can set tracking was still enabled.
I can construct a simple VBScript to test the ASCOM interface - does one have to explicitly tell the mount to track after a slew, or is it automatic?
The other thing is - while trying to home in on a root cause(s), it seems a few of us have similar issues and additionally round the new device hub, I am not certain if they are restricted to Paramount or TSX users.
That’s interesting! My mount is a GTD G53F and seems to have similar behaviour. Now that you mention it, I have randomly had a pop-up message saying that my mount wasn’t tracking and would I like it to start tracking. I’ve been focused on other things and didn’t relate the issues. I’ll be quite interested to see how this unfolds.
But I can’t correlate that with what we’re seeing in SGP. We literally enter a loop waiting for Tracking to be true and Parked to be false and it seems like those criteria are met above unless those values are not getting back to SGP how they’re stated above.
This is a log from the ASCOM driver for TSX. I was looking directly at the telescope tab in TSX, which has a status box (parked, homing, not tracking, slewing etc).
This suggests the ASCOM driver thinks it is tracking but TSX has other ideas. If SGP is going by the driver, then I guess I need to do my VBscript testing to evaluate what is going on, probably through a hub that has a comms monitor, so I can see it in real time.
as this all started after I updated the platform. I’ve gone back from Device Hub to Generic hub and all seems (touch wood) to be operating as before. It might be worth trying Generic Hub to see if you get the same behaviour.