3

When I run the conformance checker against a driver I'm developing, it uses CommandBool and CommandString to send null commands. Since these are invalid commands for the mount, the calls return a 'timeout' error - the scope is not going to respond to them. But this behavior is flagged as an error by the conformance checker. Reading the V2 telescope spec, I don't see any expected behavior defined for invalid commands - I assumed it was "caveat caller" :-). What is the result expected by the conformance checker?

Thanks.

Bruce W.

flag

2 Answers

1

The CommandXXX commands need not be tested in Conform, use Menu->Options->Conformance Options, then the Command Tests tab and uncheck all the tests.

But your driver ought to raise a not implemented error if these commands are not implemented, that's what I do for CommandBool in the Celestron driver and Conform is happy.

Chris

link|flag
Thanks Chris. I should have realized there was a good way to control the testing behavior of Conform. I actually raised a timeout exception for these invalid commands, but Conform didn't like that. :-) – Bruce Waddington Dec 25 at 23:39
1

A general principle for ASCOM drivers is "do it or throw an exception". CommandString is a request / response mehtod and so clients will wait expecting something - either a string response or an exception.

In this case your driver received a request even though the command was a null string so it is a good idea to follow Chris's advice and throw an exception if you are not going to process the command, a good one would be the ASCOM InvalidValueException.

The CommandXXX commands are intentionally open ended to provide maximum flexibility for clients, this however is no help to Conform! :) Since every driver will have its own valid and invalid CommandXXX calls and data, Conform supports the IConform interface. This is an interface that drivers can implement, which allows the driver to specify the commands that Conform should use during testing. The interface also allows whole tests to skipped if particular methods are not supported by the driver.

Use of IConform is documented in the Conform Help file and the interface is completely documented in the 5.5 help file in Start\ASCOM Platform\Docs\ASCOM Platform Update 5.5.

As Chris suggested, you can use the MethodNotImplemented ASCOM exception if your driver does not support a particular CommandXXX method at all.

link|flag
Thanks for the response. In this case, my driver did return an exception - a timeout exception on the command. This seems to me like a more accurate return than something like "invalid value". In other words, I don't think it makes sense for the driver to parse and validate the command strings because they can span the entire command set of the mount. Am I out of step with this thinking? But I wasn't aware of the iConform facility - I will definitely look at that. Thanks. – Bruce Waddington Dec 25 at 23:38
Specifically for CommandString, this as an input - output method and if the driver doesn't understand the input (very reasonably if its a null string!) then for me, that's an invalid input. Personally, I try and steer clear of using time-outs wherever I can but that perhaps is a personal preference. IConform is definitely the way to go though as it puts the driver author completely in control and also ensures that Conform runs properly when customers use it. – Peter Simpson♦ Dec 27 at 21:47
Bruce, I've thought about this overnight and can see your point of view. What is your timeout exception, is it the framework system.timeoutexception or something else? I can adapt Conform to accept additional responses and exceptions as OK if I know exactly how they will appear to Conform. Regards Peter – Peter Simpson♦ Dec 28 at 16:32

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.