Main imaging locations for me are one with a semi-permanent setup and another one with a permanent setup in an observatory. Latter one has the Lunatico Dragonfly installed the control the roll-off roof, while the former one does not have any observatory controller. The same imaging computer is used on both sites. So, even when at the non-observatory site a computer is used that does have the Dragonfly driver and related software installed. The SGP sequence however does not have any observatory controller specified. Nevertheless, as soon as I launch SGP4 it will also trigger the launch of the Dragonfly software, which then obviously can not connect with the Dragonfly controller as that is not available on this location.
This only happens with SGP4, not with SGP3. Most likely this is because it treats the Dragonfly not only as an observatory controller, but also as a switch (it can indeed operate as a switch, but I only use it to control the roof). SGP Control Panel however does not show the Dragonfly. Instead it shows the ASCOM Simulator Switch (SGP even lists this one as Connected and I do not seem to able to disconnect it) as well the Prima Luce Eagle (which I do not have, but can at least hide from this list).
Dragonfly software is continuously trying to connect to the unavailable Dragonfly controller and it eats up a signifcant amount of CPU doing so. There is no stopping it as SGP triggers its launch again as soon as I kill that process. Correction: SGP does not spawn a new Dragonfly process if I kill it. So this part is OK.
This issue (as well as the unavailability of the Equipment Profile Manager, SGP4 crashes when I hit +P) makes it impossible to use SGP4 for me. I do try once in a while when new Beta versions become available, but the last few have all had this same issue for me. SGP3 is still fine though.
Link to Logs
Approx time of issue: 07-Mar-21 15:12
Useful Info
OS: Microsoft Windows 10 Pro Ver: 4.0.0.661 .NET: 4.8 ASCOM: 6.5.0.3091
SGP4 works fine with my Lunatico Dragonfly (Observatory roof controller and Switch), but it still triggers launching the Dragonfly software every time I open SGP. Even when using SGP at a site where I do not have the Dragonfly available and thus also not included in the current sequence.
It still looks like SGP loads all equipment profiles on launch and then creates an ASCOM switch object for every ASCOM switch profile it can find (regardless even of specfication in any of the available SGP equipment profiles), so also for ASCOM.Simulator.Switch and Dragonfly.Switch. Or perhaps SGP scans the ASCOM profile for every avaiable switch?
[DEBUG][Main Thread][NONE] Making ASCOM switch: Dragonfly.Switch…
[DEBUG][Unknown][NONE] Found switch “Seletek Dragonfly”, but failed to connect! : Unable to contact device (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Unable to contact device
It could be that Lunatico have constructed their Dragonfly ASCOM driver in such a way that calling the driver also launches their application, but it is bit annoying to have to close that every time again when I open SGP at my other site. Is this something that can be avoided?
Yes, this. On start, SGPro can get a list of all available switch devices, but it can’t (typically) know the actual switches available until it connects. To rectify this issue, SGPro does a quick connection in order to interrogate the switch inventory and then disconnects. I think I will add an option to disable this interrogation step.
yes, it is true, due to the fact our system was designed to connect to several devices from the same driver, we launch that application every time somebody tries to connect. That’s something that won’t happen in future versions, but for the moment it is unavoidable.
I take it you are using a laptop and imaging from different places, right?
I also do not understand why SGP scans all installed switches, but there must be a reason for that for sure.
I take it you are using a laptop and imaging from different places, right?
Yes, I am using a single imaging computer (actually a mini PC) on two sites. One location with and one without that Dragonfly observatory controller.
I can understand why the Dragonfly application lauches when a connection attempt is made and I can also see why SGP at startup scans all switches in the ASCOM profile to see which ones are online. Would prefer though to leave that choice to me and only consider switches defined in the current sequence. I am sure this was a valid design choice when switches were introduced in SGP4.
I think I will add an option to disable this interrogation step.
Glad to see that Ken is considering to add this option. Again: it is not a real problem that SGP auto launches Dragonfly, just a bit annoying, especially when dealing with some issue in the middle of session where the only solution is closing and restarting SGP (or even having to reboot the imaging computer). At those times you don’t want to be dealing with unneccessary things.
Because SGPro allows “offline” editing of sequences. This means that, at your home computer, not attached to your observatory, you can work on and edit your sequence. This, of course, means that SGPro must be aware of switches that can be used when running the sequence. To accomplish, this SGPro builds a local cache of available switches on start and then makes all of those switches available for use in the sequence.