Unity (UPB V2) response issues

Feature requests / 3rd party software development
Post Reply
cwoodhou
Posts: 12
Joined: Fri Mar 26, 2021 9:27 pm

Unity (UPB V2) response issues

Post by cwoodhou »

I have an observatory control application that has been running my own ASCOM switch driver and then the UPBv2 driver for several years. This application polls the switch state every few seconds and can set switches too. It recently has become unreliable and stalling. I have tracked it down to some incompatibility with the Unity driver.

If I update to the Unity driver, my control application becomes unresponsive when I connect to the switch driver and makes the app unusable. Uninstalling Unity and returning to the older Pegasus ASCOM drivers makes everything good again.

My control app is a simple windows form app and uses the standard ASCOM commands for setting switches, checking switch status, switch name and switch description. Clearly something between them is causing issues. Might the control app need to have different code to work with the unity server, or is the Unity ASCOM server at fault ?
User avatar
Evans
Site Admin
Posts: 324
Joined: Wed Dec 02, 2020 3:06 pm
Contact:

Re: Unity (UPB V2) response issues

Post by Evans »

Unity implements ASCOM switches v2 which are different from switch v1 that older ASCOM driver was using.
It should be an incompatibility with this software and new ASCOM >= 6.5 switches v2 implementation
cwoodhou
Posts: 12
Joined: Fri Mar 26, 2021 9:27 pm

Re: Unity (UPB V2) response issues

Post by cwoodhou »

thanks Evans - I thought I had updated my Visual Studio ASCOM developer resources - I will double-check tomorrow. The problem is entirely repeatable, so it should be quick to establish if that is the issue. For info, I had the UI running too.

regards
cwoodhou
Posts: 12
Joined: Fri Mar 26, 2021 9:27 pm

Re: Unity (UPB V2) response issues

Post by cwoodhou »

I have had some sleep and time to work through this. Still no joy though. My control application was already up to date with ASCOM changes but for good measure, I refreshed my development and observatory machines, recompiled and re-tested.

I had already added the GetSwitchDescription method (which came out in V2) to my observatory control application when I first switched to the Unity driver to identify specific power controls. When I evaluated the older driver yesterday, it happened to work too as this method was not called during the evaluation period.

My application is extremely unresponsive to mount control button presses (button highlights do not occur when mouse is over button) but ultimately, it seems to perform the functions eventually. For instance, connecting the switches, I can home my Paramount, but I cannot seem to park it (or it starts parking several minutes later). If I use the older Pegasus driver, the mount control buttons and response is immediate.
My control app, however, is still reacting quickly to show a power switch status change made in Unity UI or from another app, like NINA.

The latest Unity driver passes ASCOM conform (without switch actions)

I'm using GetSwitch, SetSwitch, GetSwitchName, GetSwitchDescription, Connected. I poll the switch state every few seconds.

My guess is it seems to be a conflict of some kind (with TSX ASCOM driver perhaps). If I do not connect my app to the Pegasus unit, everything is fast again.

I have limits to my knowledge - although I have written many ASCOM drivers and Windows utilities for my own use, things like asynchronous commands and servers still catch me out.

I'm running out of ideas. Just a thought - could this be because the response time from the Pegasus driver is slightly longer than my polling interval... and my application sits continually waiting for the status update and never frees itself from the GetSwitch delay?
cwoodhou
Posts: 12
Joined: Fri Mar 26, 2021 9:27 pm

Please Read: Unity (UPB V2) response issues

Post by cwoodhou »

I have certainly managed to improve things, by increasing the polling interval for the status read of the relays. It was originally 1 second and it is now 2 seconds. That seems to make the entire control application more responsive to form button presses. Changing back to 1 second interval makes it worse, kinda proving the theory.

I ran into some issues with my own ASCOM switch driver and the ASCOM developers. They expect an immediate response to a status, requiring me to keep a local value, rather than take 100ms to probe the relay board and respond back. It may be the Unity server is a bit slow to respond and this is hanging up my application. I do not call the status read asynchronously, so it waits for a reply before continuing with other code (apart from the form timer).

This might also affect other applications. Worth a thought or two, as it seems I can find a solution for my own app, but that does little for others.
User avatar
Evans
Site Admin
Posts: 324
Joined: Wed Dec 02, 2020 3:06 pm
Contact:

Re: Unity (UPB V2) response issues

Post by Evans »

It has to do with the asynchronous read. ASCOM switch conformity test allows to control the delay between reads and writes.
However, It is a known issue, and we know we need to fix it and make it synchronous. (immediate read switch status after write)

Thanks for the feedback!
cwoodhou
Posts: 12
Joined: Fri Mar 26, 2021 9:27 pm

Re: Unity (UPB V2) response issues

Post by cwoodhou »

Many thanks Evans, FWIW I think Dale and I reached similar solutions, our com port transmissions updated local variables and a status read uses the local variable, rather than making a fresh enquiry.
Post Reply