I have a Skyroof controller for my ROR observatory. SGP is set to slave to the telescope and close after the scope is parked. In the morning, my mount is parked but the roof remains open. The mount is a Paramount MX+. Here’s the appropriate piece of the log:
[12/12/17 05:57:30.208][DEBUG] [Sequence Thread] ********* Run post sequence *********
[12/12/17 05:57:30.208][DEBUG] [Sequence Thread] SGPro capture cal frame mode is OFF…
[12/12/17 05:57:30.208][DEBUG] [Sequence Thread] Clearing timed monitoring events…
[12/12/17 05:57:30.208][DEBUG] [Sequence Thread] Checking RunEndOfSequenceEquipmentOptions, force = True
[12/12/17 05:57:30.208][DEBUG] [Sequence Thread] In RunEndOfSequenceEquipmentOptions
[12/12/17 05:58:01.469][DEBUG] [Sequence Thread] Parking telescope…
[12/12/17 05:58:01.472][DEBUG] [Sequence Thread] ASCOM Telescope: Park message received.
[12/12/17 05:58:01.472][DEBUG] [Sequence Thread] ASCOM Telescope: Dome slave set to park mount first, parking mount.
[12/12/17 05:58:01.477][DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP message received…
[12/12/17 05:58:01.477][DEBUG] [TEC Thread] TEC Change: Starting…
[12/12/17 05:58:01.478][DEBUG] [TEC Thread] TEC Change: Changing temp from -20.03 to 10.00 in 600 seconds…
[12/12/17 05:58:01.486][DEBUG] [Sequence Thread] ASCOM Telescope: Sending park…
[12/12/17 05:58:26.686][DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[12/12/17 05:58:26.690][DEBUG] [MF Update Thread] Performing serialize…
[12/12/17 05:58:34.574][DEBUG] [Sequence Thread] ASCOM Telescope: Parked
[12/12/17 05:58:34.574][DEBUG] [Sequence Thread] Error parking scope, aborting observatory options, cannot verify scope position…
[12/12/17 05:58:34.574][DEBUG] [Sequence Thread] Adding sequence level notification: Telescope parked.
[12/12/17 05:58:34.599][DEBUG] [Main Thread] Aborting sequence timer thread…
[12/12/17 05:58:34.599][DEBUG] [Main Thread] Sending sequence end notification…
It seems that there is an error in parking which aborts the roof closure but the driver is reporting parked. I’ve also included the full log file.
I installed the new version of v3.0.0.4 and the roof doesn’t close again. Same problem. Ascom driver is reporting parked but SGP shows an error parking the scope and won’t close the roof.
Same here - exactly the same 'error parking scope, aborting …
(I have a ROR which is slaved on sequence start and opens and closes before and after park.
Can we have 3.0.0.3 back again, as if it rains now, everything will get wet…
I’ve just experienced the same problem at my home observatory - mount parked but roof did not close (Dragonfly ascom control) with the same line reported in the log 'error parking scope, aborting observatory options.
Sorry, but we can’t roll back betas. You should be able to install 2.6 and 3.0 side by side. I’d recommend keeping 2.6 there for when anomalies happen with 3.0. And they will…thus is beta life.
Yes - exactly the same issue with the roof on my remote installation. The problem is compounded by the fact that if I do go back to 2.6, then all of my carefully worked out 3.0 sequences will not load. If we cannot get 3.0 fixed today, is there an easy way of getting the 3.0 sequence (or a cut down version of it) to load in 2.6?
You can grab it here. I’ll promote this to an actual Beta here in the next couple of days. But it only has this fix in it (which has been very briefly tested, so I would still be interested to know if it’s resolved…which should also be a hint that you probably don’t want to completely trust it at this point.) https://www.dropbox.com/s/arnmt87boza4cfj/Sequence%20Generator%20Pro%203.0.0.5.exe?dl=0
There is not. That would require us to constantly update 2.6 to handle new additions/changes in 3.0.
Jared, you are a star . I did a quick daytime test and the ‘abort/run end of sequence options’ worked fine, closing the ROR after parking the mount.
In addition, you seem to have fixed another anomaly that has persisted for some time: I noticed that loading this beta version did not revert all my telescope centering options to ‘sync’ (in both ongoing sequences and in equipment profiles).
Couldn’t the 3.0 sequence be a superset of the 2.6 sequence? That way 2.6 could use it, ignoring the bits that it wasn’t aware of.
As things are it seems very difficult to run 3.0 as a true beta, this implies that it’s easy to back off to a known good version. Having incompatible sequences means this isn’t possible.
Thanks for getting in touch so quickly, and for the Dropbox link.
Excellent service. I would have thanked you immediately, but I had the
opportunity to test the new version on the remote rig, and I am pleased
to report that it is all working as it should. If you need any logs,
please let me know.
Yes and no. Most things are additions and in those case it would be backwards compatible. But often we change things, and that breaks the contract. We generally try not to do t his but sometimes you have to address the mistakes of the past and Betas are a good time to do that. However if someone has a sequence created with 3.0 that fails with 2.6 I can take a look if they send it over.
Hmmm, well I didn’t address anything there and I don’t see a fix from Ken about that. So maybe just luck? Or maybe it was address with 3.0.0.4? Not sure…
Not sure if I’ve seen that issue (we’re both generally pretty heads down on 3.0 stuff these days). If you have a link I can look into it.
. I did a quick daytime test and the ‘abort/run end of sequence options’ worked fine, closing the ROR after parking the mount.