RE: [ASCOM] Dome standard
- View Source
From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Bob Denny
Sent: Friday, June 30, 2006 7:06 AM
Subject: Re: [ASCOM] Dome standard
With respect to the ShutterError or adding a new ShutterManual and reporting that:
(1) What would a dome control client do differently with shutterManual? Either
shutterError or shutterManual mean the same thing to me as a dome control
client: "I don't know what state the shutter is in".
My dome and dome driver don’t support manual operation so I don’t really have to worry about anything but error. In my case if the dome controller detects that the current is failing to run thru one of the actuators for more than 4 seconds then it shutsdown the attempt to close and reports an error. This means that if I tried to continue to force the shutters closed I could have an asymmetrical open/shut dome scenario ( I have split shutters) and it could twist the shutters and shatter them.
That would be a bad thing.
If I did have a manual control and had partially opened the shutters, then the software could ask for a open or a close and just go on with business when it established a known state. If I have a shutter error, I don’t want anything to go on until I fix it, and I need to be warned. ACP should not go on running scripts, etc.
(2) Adding a new state would mean revving the spec. Clients written to the
current spec might barf on a new unknown non-standard shutter status.
We could use a new property to set the reporting of the shutter status. AllowIndeterminateShutterPosition. Clients that want to know could just use that to let the driver know to use the new state.
So... in my opinion, report ShutterError.
Errors should be for exceptional state situations, not for a normal occurrence. We need to say what it is.
The other worm to come out of this can is that sometimes not only is the shutter “Indeterminate” but could also be “uncontrollable” because of being used manually. Error might work for that scenario.