Hello folks, I have an issue with the latest 64-bit version of TSX. If I try and park my MyT or MX from SGP using ASCOM, TSX parks the mount and then disconnects the mount from TSX. The same occurs with other apps using ASCOM on all of my 3 PCs. The 32-bit version of TSX works just fine (using the same X2 ASCOM driver), parks the mount and stays connected. A few other users have noted it too. The park facility is an important part of the safe shutdown/recovery process and as many devices connect to the mount, they are all stuffed after a park command.
Although I have spent a lot of time testing and validating, SB have not acknowledged the issue and I feel they still think it is an isolated case.
I would really like to know if there are any SGP users who are successfully parking their Paramount using the 64-bit version of TSX? It would be immensely useful.
Based on some of your other posts, I was under the impression that the issue you are experiencing is not an “issue” per say, but rather it is intended behavior. Is it not true that, for TSX:
Calling on the Park() method performs Park + Disconnect (by design)
If you want to park without disconnect, one would need to call on a different method ParkAndDoNotDisconnect() (or similar… I forget the exact name)
Hello Ken . Apologies for the long note.
When SGP (or any imaging app using ASCOM) parks a Paramount, it calls the ASCOM Park() command in their ASCOM 2X mount driver. This translates into calls to TSX’s own API. There is only one ASCOM Park command but there are two possible TSX API calls, Park and Park+Disconnect. The disconnect happens between TSX and the mount, tripping up all mount-connected apps.
The latest ASCOM 2X driver has several options to boot up different version of TSX, including the latest 32- and 64-bit versions on connection. Much older Sky versions default to using the Park+Disconnect API call but that was superseded years ago and all later versions are supposed to only use the TSX Park API call. (This is clearly documented in the TSX ASCOM help file.)
Selecting the 32-bit version of TSX in the ASCOM driver and ASCOM Park() happily parks and remains connected but selecting the 64-bit option in the driver, causes it to park and disconnect. This happens with SGP, my own control app and a simple Visual Basic script using ASCOM. It happens in NINA too, but it notices the disconnect and reconnects… but the mount status is no longer at Park. It messes up SGP recovery modes.
I am having difficulty convincing SB that this is a real issue. They are inclined to speculate that external apps are at fault. A few users have reported the same issue but I suspect many are still using the 32-bit version of TSX. The forum’s moderator’s instance of Voyager seems to work through ASCOM, though my demo version fails. Voyager also have their own direct interface using the TSX API, so if there was any special-case handling, this would more likely be it.
If any SGP users report they can park (and not disconnect) a Paramount, with the 64-bit version of TSX selected, I’ll rebuild by three imaging computers from scratch and take up fishing. The prior two ASCOM drivers were written by Bob and Chris. I expect the latest is also by a hired third party and a pain to open up again for revision. A simple log of ASCOM and TSX API calls of any Park commands would quickly highlight that the ASCOM driver is incorrectly choosing the wrong TSX API call when it gets an ASCOM Park() command.
Oh, I see. I thought this was an extension of ASCOM like QSI used to do. Makes more sense now. I wish I had a paramount to help test, but hopefully you’ll find a resolution soon. That mount trace log I analyzed doesn’t help to clarify that ASCOM clients are “misusing” the driver and that there is a clear mount disconnect despite no disconnect call showing in the trace?