Conform 64bit fails connection to CoverCalibrator

[jeffd69]

Hi all,
I've developed a CoverCalibrator device for ASCOM 6.5 SP1 in VB.net 2017 but I'va a problem with Conform in 64bit mode.

If I compile the ASCOM driver for 32bit and check the conformance in 32bit mode, it works fine and passes the validation. The driver works fine also with a 'stand-alone controller' built starting from an ASCOM Driver application test template.

But when I compile the driver and the 'stand-alone controller' for AnyCPU or x64 the Conform fails the validation.

Looking at logs of 32bit version, at the moment of connection the SW sets Connected = True then polls the driver few times until it reports Connected state True, giving time to the driver to connect and configure the HW device ( some hundreds milliseconds via USB chip ).

But looking at logs in 64bit mode it seems that Conform doesn't give time to connect to HW. Conform sets Connected = True and immediately check for connection status ( sometimes the timestamps in logs are the same millisecond ) and since the driver reports False, Conform goes ahead with code execution without retrying and the result is a lot of Not Connected Exceptions.
11:04:33.181 Connected Set Set Connected to True
11:04:33.182 Connected Set Failed to connect

The strange is that using the ASCOM Driver application test in 64bit, the application itself and the driver work without any problem!

Seems that Conform in 64bit handles the connection in different mode compared to 32bit mode and the ASCOM platform in both modes.

Attached the logs from Conform and from application test.

BR, Jeff

Log_test_application_64b.txt
Logs 64b_debug_calls.zip
Log_test_application_32b.txt
Logs 32b_debug_calls.zip

[Peter-Simpson]

Hi Jeff,

Given the conversation here is it Ok to close this issue?

Best wishes, Peter

[jeffd69]

Hi Peter,
to be honest no, but not because someone didn't solve my problem, but because I still think there's a bug in Conform.
Let me explain:
If I've undestood well, 'The Core Team has discussed several times about being clear that method calls that initiate a command should be asynchronous.'
So the driver must set the variables that are supposed to be affected by the method call before returning from it (e.g. immediately set 'moving' as OpenCover is received then return, right? )

Let's suppose Conform calls the Connect method, and in the driver I set a local variable so that IsConnected = true BEFORE returning from Connect. I'm cheating Conform, because the HW is not connected yet, but I've said it is.
Conform may then calls OpenCover (still before the HW is connected. It has no way to know this and no reason to wait for an arbitrary time as you can see from my logs: there's 1ms delay from Connect call and IsConnected check)
The driver should then set CoverState.Moving before returning, despite HW is not connected yet... (HW connection may require 50ms, 200ms or even more, which is an extremely long time compared to Conform code execution speed)
The result is that Conform could queue lot of calls that are supposed to be valid, calls at which the driver should reply in a proper way, still before the HW is connected.

And over that, the 'ASCOM Driver application test' works fine in both 32bit and 64bit. Also Conform in 32bit works fine.
But in 64bit mode it fails the connection but keeps going on with the validation process.
In my opinion Conform should act as the application test: try few times (considering some timeout) to get the IsConnected=true before giving up or going on with validation.

BR, Jeff

[Peter-Simpson]

Hi Jeff, There is no doubt that all method calls need to be asynchronous, but not all of them are asynchronous today. OpenCover for example is asynchronous because it has an initiation method and a status property that the client can test to determine whether or not the operation has completed. When implementing this method CoverState should be set to “Moving” before OpenCover returns control to the client. Since it was first defined over 10 years ago, the Connected Set property has been expected to operate synchronously. We will need to release updated interfaces in order to create a revised asynchronous connection mechanic with an initiator and a status property. Like all other clients, Conform expects Connected Set to operate synchronously and this is why you do not get expected behaviour if you return control before your hardware is ready to respond to other commands. From a software perspective, both 32bit and 64bit versions of Conform are identical, it is just compiler switches that are different. Conform does make several connection attempts when testing devices but each attempt uses a different mechanic e.g. directly as a COM object or by using DriverAccess. Conform doesn’t make a second identical attempt to connect if the first attempt fails. The different behaviour you are seeing between the 32bit and 64bit Conform versions is likely down to small timing differences within the .NET CLR in how it treats the two versions of Conform and your device. Hopefully this explains why Conform operates in the way that it does. Best wishes, Peter

[Peter-Simpson]

Hi Jeff,
One more thought occurred overnight.

If your cover powers up in an unknown state, it is OK to let the client know what has happened by setting the CoverState to CoverStatus.Unknown and returning quickly from Connected Set. It is then up to the client to command your device into either an open or closed state as required.

Hope this helps.

Best wishes, Peter