Hi there, I have an exploradome with fostersystems control for the dome.
In SGP there are several ways to operate the dome. I can slave the dome inside SGP or just opt to operate the shutters and parking.
When I am doing the latter, i.e. using SGP to only control parking/unparking and shutter behavior, I use AstroMC from fostersystems to perform the slaving and track.
In this situation, at the end of the sequence if I ask SGP to park the dome and close the shutters, it faithfully does so by sending the appropriate ASCOM commands, but one step that seems to be missing is to issue an ASCOM command to AstroMC to turn off slaving after the park. Without this, after park, since slaving is still active inside AstroMC it just comes back to where the telescope is parked.
If slaving was performed inside SGP, I can see how this is not a problem, since SGP is not longer issuing move commands post park.
Does this sound like a bug? I am of course postulating based on black box observations.
Hi Manoj,
I also have an Exploradome and have experienced the same behavior - dome never stops slaving to scope, even after sending park commands. In fact, in my experience the dome actually looks like it parks/homes itself but then reverts back to slaving to the mount (mount park and dome park are not the same direction for me). You could probably find some older posts on this here, and on Foster’s forum as well as Exploradome Yahoo group.
The Foster developer is apparently aware of the issue and working on a fix. Not sure when it will be released but he was testing it a couple weeks ago.
Hi Dave. Yes, I am on those threads as well. One of the reasons I started this post is because a poster on the foster forums had an animated gif of control from ccdap (which seemed to work as expected) and from that it seemed like ccdap was in fact sending a “disable slave” command after using a park command. I am fairly certain sgp is blog doing that and started this thread to see if it should.
If SGP could adjust something to get it working, I think that would be great. I’m not familiar with the ASCOM protocol details or specific command options - is there an actual “disable slave” or similar option? I don’t recall seeing this kind of message in the SGP Log. I have seen commands like these:
[Sequence Thread] ASCOM Telescope: parking observatory…
[Sequence Thread] ASCOM Telescope: closing observatory shutter…
[Sequence Thread] Dome: Closing Shutter
I would have thought that “parking observatory” should be interpreted by the observatory control system to include sending the dome to it’s Park or Home position and disable the slaving to mount. However, Stan at Foster seemed to indicate that the way the program currently works, disabling slaving would also disconnect the dome from ASCOM which means manual intervention before SGP could reconnect. This is supposedly what he is currently working to change.
Having said that, it’s been many months without movement from Foster. Agree that if Ken/Jared could suggest an alternative it would be greatly appreciated by Exploradome/Foster owners.
SGPro does not use the ASCOM dome properties “CanSlave” and “Slaved” and instead handles this relationship locally. Because of this, there is no SGPro logic to decouple the two. If the “Slaved” ASCOM property is set to True it was done so outside of SGPro.
Hi Ken, understood. Makes sense you would not be using the ASCOM dome properties since you are not exposing an ascom dome interface.
What I was suggesting was that the dome you are connecting to is ASCOM and that should be exposing those properties. So if inside SGP one has connected to the dome, whenever there is an ASCOM Park command issued to the dome, is it possible to also issue an ASCOM Slaved=false command to the same ASCOM dome driver?
Of course people could be using different equipment combinations, but the only side effect I see is that if Slaving is done outside, then upon restart, slaving might have to be enabled manually.
The primary use case here is, of course to just have SGP close up the dome when done with everythign else being handled outside. There might be a better way to do this. AstroMC does provide for scripting but it seems to be a bit clunky and I am yet to figure out how to get personal scripts to run there. I also tried running something like this inside SGP but it did not work.
option explicit
sub Main()
Dim AstroMC
Dim Dome
set AstroMC = createobject(“AstroMC.obscontrol”)
set Dome = createobject(“AstroMC.Dome”)
Dome.GoHome
do while AstroMC.AtParkStatus <> True
AstroMC.waitfor(5)
loop
Right… that is what I was saying. SGPro does not set this property to True and has no business setting it to False at the end. Whatever application is setting this property should manage that. Domes do not need to implement this property (not required). That said, you can certainly write an end of sequence script to run that stuff if it’s the behavior you desire.
The problem in this circumstance is it’s a physical checkbox, so the whoever here is a person and that person may not be awake when sequence ends.
Script is fine. Did the one I posted look ok? I am not sure why it’s not doing anything. Should have grabbed the right COM object, but does not seem to.
makes sense on the broken one way logic.