I queried the behaviour of how SGPro v4 manages switches a few months ago (here) .
I’ve been using V3 since but thought I’d try v4 again - installed the latest stable release 4.0.0.700.
I have another app that connects to and manages the switches in my observatory (two sets of switches - power controls and a dew controller). SGPro seems to try to connect to my dew controller device every 5 seconds. The driver throws an exception but SGPro keeps trying. I ended up with a 10GByte trace log file from the driver two nights ago …
I control when to connect to all the other equipment SGPro uses - why can I not control when SGPro should connect to the switches?
We will be modifying version 4.1 so that you will be able to connect to switch devices manually. In terms of auto connect on sequence start, if you ask SGPro to alter the state of any switches at sequence start or end, then it will require a connection to that switch prior to starting the sequence. If SGPro can’t connect to the switch then it won’t start the sequence.
I’ve installed beta 4.1.0.712 and am trying to understand what it’s doing.
SGPro is continuously polling the switch drivers and I can see the Connect and Disconnect when I press the switch button in the Control Panel (if my app isn’t also connected).
One observation is that SGPro sends a “MaxSwitchValue” which returns 1023 for the Dew Controller but then sends both a “GetSwitchValue” and a “GetSwitch” - it only needs to send the “GetSwitchValue” . The “GetSwitch” has to return an unsupported exception as it’s used for a boolean switch.
I’m puzzling over how many threads are running in SGPro trying to talk to my switches. When I start SGPro, three separate ASCOM Trace Log files are opened. The first is very short, the second opens after the first closes, then a third opens shortly after that. These two log files just continuously fill up with calls from SGPro.
There are simultaneous duplicated calls as though multiple threads are trying to talk to the drivers?
I have fixed an issue that may cause SGPro to incorrectly identify a multi-state switch as a 2 state switch. It will be available in the next beta.
Just 2 and one is only on SGPro start. I makes an attempt to connect to any switch that it finds, queries it for information, then disconnects. For the other, it should only query connected switches for state. 712 had a defect that was based on the old “all switches are connected” philosophy. The next beta will correct this issue.
There may be further cleanup needed here, but this is not a result of multiple threads, but rather trying to force ASCOM’s topological view of switches into ours. SGPro views a switch a discrete object and in ASCOM, it’s not… it’s just a property within a single parent object and managed with an index value. Because of this, when we operate on a switch, there is some duplication because modifying a switch is actually modifying the same underlying ASCOM object over and over. While we do poll often, I have removed “name” polling from the list of props we sync. It is nice to auto reflect the name change for a switch, but ultimately I don’t think the COM chatter is worth it for the number of people that would use it.