I am having problems since the upgrade to 2.6.0.17 (I have since upgraded to 2.6.0.20, but problem persists). When the dome is connected and I click ‘Open’, it opens, but the Observatory module doesn’t update to ‘opening’ and then ‘open’ takes an age to appear. Once the dome is slaved to the mount, all works fine, but when I click ‘Park’, the shutter shuts, but then it takes quite a while before the mount and dome park. Looking at the log file, you will see ‘Close shutter timeout!’ four minutes after the ‘Closing Shutter’ message.
Any ideas anyone? Jared & co, I understand that you are busy, but please help!! Is it an SGP code problem or an ASCOM problem or a Pulsar problem? Am I the only one with this issue or is somebody else using the latest releases of SGP with a Pulsar Dome and having the same problem?
Thank you.
I haven’t seen or heard any other reports of dome slaving issues. You can attempt to use the dome simulator that comes with ascom to attempt to narrow down the problem. I’ll also add some logging around the park command. Maybe your hardware isn’t liking something about how we’re calling it.
If you have the ASCOM log for the dome that would also help.
I don’t have a Pulsar dome - hopefully others will respond here.
However, I have had some similar issues with my Exploradome I (Foster Systems - AstroMC). I had been assuming the issue was on the Foster Systems side, as there is already a known ‘bug’. My issue is that the dome does not always respond to a shutter close request from SGP - and eventually there is a “timeout” message in the SGP log. Particularly disturbing because I rely on the dome closing itself while I am asleep (and avoid potential incoming weather). Get something like this in the log:
I’ve also experienced long delays for dome responding to commands (ie. when request “dome open” by SGP) to the extent that I now always open the dome using AstroMC directly and not SGP. Again, I have always considered this to be an AstroMC issue.
By the way - the AstroMC “known bug” is that it will continue to slave to mount, even after the mount is parked (instead of going to its own park position). Foster Systems is working on a fix - new version currently in testing.
One thing to note with mount/dome parking - there is an option to delay shutter closing until after mount parks (Park Mount First). This can make it seem like shutter response is sluggish when in fact, it is just a sequential timing thing.
So @PhotoGav, similar but different experience to yours. Not convinced my issues are SGP related.
Thank you for your response, Jared. I will turn the dome ASCOM trace on and post the log tomorrow. It’s strange that it has only started happening since the most recent upgrade. Have you actually changed anything in that section of the code??!
I believe it goes much longer than recent revisions of SGP (back to last Fall or earlier). Wasn’t really watching it that closely as I always seem to be dealing with bigger issues.
And as mentioned before, I’m not so sure it is an SGP issue (vs. AstroMC). But I will be following this thread closely.
Same shutter issues seen, but at least it was clear and I managed to finally get some half decent subs!!!
Looking at the ASCOM log, it does appear that the status of the shutter is not updating correctly. Is that an issue for the ASCOM publisher to deal with or is it something to do with how SGP interfaces with it? Why would it have worked perfectly in the past and only now start to play up when I haven’t changed the ASCOM driver for the dome, I’ve only updated SGP??? I am begining to think that it is impossible to get everything working properly all at the same time!
@PhotoGav, I’ve been testing my dome today (new version of AstroMC control software has been released). I noticed that when I select “Open” in the “Observatory” module, “Opening” flashes up briefly (<1sec) but then goes back to “Closed” (see screen shot). However the dome does eventually open and the Shutter: status does eventually change to “Open”. Perhaps this is something @Jared or @Ken can have a look at.
Also, when I selected “Park” (telescope), my observatory shutter did close. I believe the “slave to telescope” (Control Panel - Other) must by checked for this to work. My past issues with this was intermittent (ie. shutter not closing at end of sequence and Telescope Park), so only time will tell (fingers crossed that new version of AstroMC has addressed this).
I also note that my observatory successfully parked itself as well, which is something the new version of AstroMC was meant to address (in previous version, observatory would continue to slave to scope, instead of going to its own park position).
Dave, you are describing exactly what I experience too. On ‘Open’, it flashes ‘Opening’ very briefly, then goes back to ‘Closed’. The shutter does open and eventually after several minutes the status updates to ‘Open’.
On ‘Park’, with the dome slaved, the shutter closes immediately, but the status remains ‘Open’. After 4 minutes the status changes to ‘Closed’, the dome rotates to its home position and the mount parks.
In the past, on both open and park everything happened immediately or at least as soon as the first action completed the second action would commence.
I’m thinking that it must be an SGP thing as we are using different ASCOM drivers, but suffering the same issues.
I look forward to hearing what Jared discovers. Thankfully the issues are not show stoppers!
Hi @Ken, @PhotoGav had already posted SGP and ASCOM logs earlier in this thread. If these are not sufficient, I can look at generating logs - let me know.
From a look at the ASCOM driver log it seems to me that it’s really only going to be able to be interpreted by the developer.
Slewing get seems to return true when the dome azimuth doesn’t seem to be changing and false when the dome azimuth is changing. Not sure if that’s relevant. It’s difficult to see the wood from the trees with a 50 Mb log file.
What I’d do is run the ASCOM Conform application on the dome. This will exercise the dome and shutter and generate logs and a conformance report showing if the dome appears to meet the ASCOM specification.
Eventually we give up. The reason you see the status go from Open → Closing (briefly) is because we assume that the driver is closing the dome and preimtively set the “Closing” status. In reality we expect the driver to return that it’s closing the next time we poll it. However in this case it’s still Open and not “Closing”. I don’t actually ever see the driver go into a “Opening” or “Closing” status. So maybe they decided not to implement those. I’m not sure if they’re required. SGP doesn’t really care about those two statuses, it will just give a “not so great” user experience if they’re absent.
However the issue seems to be that your dome hardware is not responding to our requests to close.
So, I tried to run the Conform app to test the dome and I immediately got an alert when trying to select the Pulsar Dome saying: “Incompatible Driver - This 64bit capable driver is only registered as a 32bit COM driver.”. I will contact the developer and see what he has to say in the matter.
Thank you for that, Chris. I have just run the conformance tests and all worked perfectly. The shutter was operating exactly as it should and there were no timeouts. I have also run SGP to test if it works normally and indeed it all does again.
This morning the developer sent me a new ASCOM driver, which I tried to install, but the installation failed half way, reporting that the Wizard ended prematurely because of an error and the system had not been modified. I tried to do the installation before running the conform app and can only conclude that either something to do with the dome driver was modified in the failed installation process or in the conformance test and nudged things back into shape to make it work normally again.
Whatever, the headline is that the system now works normally and I am a happy astrophotographer again!!
Thank you all for your time and assistance with this.
