ASCOM ITelescopeV3.Slewing property and error reporting

[Alexey Harchenko]

Hello!

Not sure this is a real bug, but at least some problem here.

In short:

How ASCOM driver can (should) inform client(NINA) about problems during motion (mechanical limitations, motor overload, sensor failure etc) ? Assume errors is not fatal, but telescope isn’t pointed to target. If possible, this situation shouldn’t break scheduled tasks.

Long description:

ITelescopeV3 has a number of methods to point telescope to, like SlewToCoordinates. Such methods can throw exceptions to indicate positioning error.

“Blocking” functions may indicate error any time during motion, because they do not return until motion completes. But they’re not recommended, and I see NINA using SlewToCoordinatesAsync() to initiate motion.

Imagine that telescope, or it’s driver, encountered a problem during motion. How can driver inform client application? I suggets Slewing property is good place for this and try throw exceptions in get_Slewing to indicate errors. But I see strange behaviour from NINA, which is often just silently(!) disconnects from mount. In AscomTelescope.cs i see only handling of PropertyNotImplementedException while i trying to throw ASCOM.DriverException, TimeoutException and even ASCOM.NotConnectedException (thinking last may be not correct, but problem is present with another exceptions too).

Not sure how to do correctly and where implementation shoud be changed (in driver or in NINA?), I initiate discussion in [e-mail] and get answer that I really should throw exceptions in get_Slewing to inform client about mount problem, and client shoud handle all exceptions thrown.

Direct link to discussion: https://ascomtalk.groups.io/g/Developer/topic/81009369

I agree this situation is not documented clear in ASCOM developer help and ready for discussion.

Thank you.

[Stefan B]

Hi,

NINA is using SlewToCoordinates and not the Async method (yet) - see line 1031 https://bitbucket.org/Isbeorn/nina/src/develop/NINA/Model/MyTelescope/AscomTelescope.cs.

Handling an exception for the Slewing property is not handled currently, as it most likely was not mentioned explicitly in the ASCOM docs when I have added the implementation. When this property fails to be fetched it won’t be handled gracefully.

We can enhance this, when the common consensus is, that this property should throw problems.

[Dale Ghent]

ASCOM.DriverException is a catch-all for when there is a fault condition that does not match the (very few in number) exceptions that indicate more specific problems. The problem the client is confronted with is a very basic one: What do we do with such an exception? Does it mean a fatal condition is present, or is it recoverable in some way? Could it be ignored? What should I consider my state to be if this type of exception were emitted? And so on. There is no context that can be properly reacted to in a programmatic sense. The only thing NINA knows is that it now has an exception and must do something with it, and there can be only one course of action.

The issues you speak of (motor stalls, limits reached, and other operational conditions) would be great for a client know about, but there is no formal way for a client to know that any given driver is trying to signal such various conditions by using a generic exception such as ASCOM.DriverException. The exception’s message might be meaningful to the user (“The RA axis motor has stalled”) but it is still meaningless in a programmatic sense.

I’ll check out the topic on the ascom-dev list when I get a chance. Maybe we can come up with ideas for basic differentiation of fault stats (fatal, recoverable, etc). At least those basic categories would give a client an idea about what to do without trying to enumerate every possible failure mode a device could have as its own exception.

‌

‌

[Alexey Harchenko]

About SlewToCoordinates: Sorry. Really magic that this works through ASCOM Remote. Thanks, I found mistake in trace code of my driver.

I look at this file in local clone (maybe master branch?) and found public void SlewToCoordinatesAsync(Coordinates coordinates) at line 1062 of the same file. This function is not used now?

Very strange that exception from SlewToCoordinates can lead to problem, all exceptions are handled. Maybe there is anotner problem in driver. I will attach part of NINA’s log.

[Alexey Harchenko]

Ignore focuser errors, it's not a problem.

[Alexey Harchenko]

Sorry. Real problem was in driver, which sometimes threw exception twice, in SlewXXX(), and then in get_Slewing(). Now fixed, real world testing planned later…

I think it’s almost improbably catch smth in get_Slewing() calling sychronous versions of SlewXXX (but, f.ex you can catch exception when trying to get Slewing when mount is disconnected), but if you planning to use SlewXXXAsync, problem may arise.

Because ASCOM not standartized possible exceptions here, maybe good solution is just display notification (and log), assume Slewing is false and continue?

What NINA will do after slew, if Slewing is false, but Ra and Dec differs from target?

Thank you again.

[Alexey Harchenko]

Works.

[Stefan B]

Removing version: 1.11 Nightly (automated comment)