Suggestion for passing information from drivers


I have a situation where the Dome controller I’m writing the software for has two safety checks. One is low battery voltage and the other is a rain sensor.

When the voltage is low the dome will refuse to rotate (don’t want to damage the battery if it’s on a battery system) and the shutter will refuse to open (though it’ll still try to close).

The other is the rain sensor triggering will make the shutter close and refuse to re-open until the status is cleared.

This is great but because they aren’t separate ASCOM safeties there’s nothing in the Dome implementation that lets a client check for these conditions and the Supported Actions list would only be useful if the client knew to look for them.

What was suggested to me was to have the driver throw an InvalidOperationException with a string explaining the reason. With POTH a dialog appears without showing the reason. With SGP there’s no indication in the UI, just a refusal to move the related part. If logging is turned on then the exception with the reason is in the log.

I’m not really liking this situation since many users never bother learning how to look at logs never mind turning them on.

So my suggestion is to somehow show that there’s an error/exception in the device UI and maybe show the text the exception supplies?

Having said that, I don’t know if any other controllers include these kinds of safety checks or the setups use separate safeties with their own drivers so it might not be worth the effort.


Your controller could implement a safety and/or weather ASCOM driver as well as the dome controller. That’s how this sort of thing is expected to be handled.

The dome controller would still throw exceptions if the safety interlock stopped it operating but the application could use the safety driver to know that the dome wasn’t safe to open and hopefully would not try to do so.


How would you do that when there’s only one serial port?

Or… I guess the driver could use a safety driver through a COM interface or use a file on disk and have the safety driver check for it’s existence or contents.



You would use a “local server”. I believe there are examples of this in the ASCOM developer templates. I did something similar for my dome. The same hardware controlled the dome and a flatbox.



I saw that but didn’t read up. I thought it meant running ascom in the local computer and having the result available on a remote. I use VirtualHere to get my USB devices usable on remote computers and it works great so didn’t look further. I’ll finish the current driver then look into this.