Since yesterday after updating to the latest version of SGP, I can no longer connect to my Planewave focuser via SGP. The PWI3 software launches and connects to the focuser successfully, however I then receive an error as below
I have tried installing a prior version of SGP but the issue is still there. I also downgraded to Win10 from Win11, but still no difference. I also uninstalled PWI3 and reinstalled, but no difference again.
For reference the PWI3 software does connect to the focuser successfully, TheSKyX can also successfully connect to the focuser as can ASCOM diagnostics utility. The ASCOM log file (link to that and other logs below) shows an error as below:
UNHANDLED EXCEPTION DURING REFRESH: System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize —> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.serviceModel. (C:\Program Files\Sequence Generator Pro 64bit\Sequence Generator.exe.Config line 522)
It’s worth noting that you installed a 64-bit version of SGPro. You did not say from what version you upgraded, but if it was from a 32-bit version of SGPro, you’ll need to ensure that ALL of your equipment drivers are 64-bit compatible. SGPro can’t tell if a driver is a 32 or 64 bit driver so it will always try to connect (and just fail) even if they are incompatible.
Thanks for the prompt response Ken, it’s the 64 bit version I’ve been using for a while now. The odd thing is, it worked a few night last ago and the only change I’ve made is to upgrade from 4.1.0.767 to 4.1.0.772 via the SGP app, which I assume automatically matches the version you use. I’m also using TheSkyx64 so I’d assume that wouldn’t work if it was a 32/64 issue and that connects and can move the focuser fine.
Ok, thanks. Looked into this a bit. It’s not exactly clear what’s happening and, even more confusing is that there are not a lot of changes between 767 and 772. That said, I would be curious how the focuser reacts if you were to try with 767 again. In any case, I am not 100% certain, but it seems as though the SGPro config file is causing the initialization of some child processes to fail because you don’t have some older WCF components installed and it fails to initialize.
Based on your reports and how you submitted the issue, you seem like you’d be fairly comfortable running a quick test (with 772). I’d like to try and remove the config section that is causing PWI to try and use WCF and see what happens. In the exe.config you noted above, can you just remove completely the <system.serviceModel> that goes from line 522 to 537 and then retry to connect?
Thank you Ken. Well that does appear to have resolved the issue. Its a bit cloudy, but still managed to get a reasonably good V-curve so focuser is definitely moving and no errors. The next question is of course, is it OK to leave it with the system.serviceModel section removed?
Everything else appears to work fine, PHD2, TheSkyX, etc.
In addition, separately I uninstalled 772 (made sure the SGP folder was removed from program files as well and rebooted in between) and installed a fresh 767 and the issue was still there, which is very odd given I imaged a few days ago with 767 and had no issues.
Yes, I have already removed it from the release. It is a very old part of SGPro and oddly enough, that config setting has been in place for more than 5 years now and who knows why it’s suddenly a problem now. In all honesty, I have no earthly idea why PWI even picks up on that setting or why it chokes when it encounters a section it does not understand (vs just ignoring it). That said… we’ve got plenty of other things to do right now and right now this seems like a problem for future me.
Kevin from PlaneWave here. Interesting problem… I can offer a few more details that may help.
The PWI ASCOM driver is implemented as an in-process DLL that communicates with the PWI application via a local socket. When the socket is created, it looks like .NET is looking in the .exe.config file to see if IPv6 support should be enabled:
Since this DLL code is running as part of the SGP process, the config lookup resolves to Sequence Generator.exe.config. For whatever reason, when the internal framework code parses this file, it doesn’t recognize system.serviceModel as a valid section in the config file.
I don’t have any experience with WCF so I’m not sure what conditions are necessary for the system to be able to parse this section correctly. In particular, it surprises me that the parsing fails in this context but (presumably) succeeds in other parts of the SGP process. But in any case, this at least explains why the PWI ASCOM driver is unexpectedly affected by the contents of the SGP config file.
Thanks Kevin. As of this moment, I think we are OK just not having that section, but if we encounter a scenario where we need to implement something with the system.serviceModel section we’ll dig deeper. Most of the time .NET is great, but sometimes, it provides so many luxuries and shortcuts that when it breaks, nobody has any idea where to start.
