TC plugin: add Alpaca #4148
TC plugin: add Alpaca #4148
Conversation
gzotti
added
os: windows
|
I suggest that we keep the legacy ASCOM for Qt5 (disabled for Qt6) and just add one more protocol that would be supported regardless of toolkit. And when the new one proves reliable, we can drop the legacy together with Qt5 itself. |
|
If ASCOM7 now works well with Qt6, we can reactivate it. But somebody with actual equipment has to start testing, not reverting to 0.20 on the slightest problem. So, in principle, the first commit here can be cherry-picked into master (and 25.1) if we want that. And yes, Alpaca also needs to come. However we can (if it makes a difference) limit that to Qt6. |
Why would it? It's still based on COM, and this is exactly what conflicts with Qt, not the actual payload API being called. |
|
We never actually identified what is the problem with ASCOM6.5, or did we? And now with ASCOM7 I cannot trigger a crash so far. Allegedly you just would run the simulator and some other program (SharpCap in one report, but it was not required to trigger the silent crash/vanishing), switching between them, having Stellarium in the background for a few minutes, then switching back. Unfortunately I cannot find the report that describes it best. So, for now, I'd like to have clear instructions to trigger a crash, else it could come back any time. |
We did, more or less, I remember having discussed this while my experimental |
|
So a manual search over a hundred issues yielded #2874, particularly this comment. |
|
Ah, that branch, right. I just could not find it. While you did a lot of diagnosis there, there was no final test with ASCOM7. Regardless, I keep it active in this branch to allow further testing until proven faulty again (it "should not" :-) disturb normal operation without an ASCOM telescope), but will try to add Alpaca. |
|
I am not a regular user of CdC. But for a test I installed it and activated tracking the same ASCOM simulator telescope. Now I can trigger a slew in Stellarium and observe the simulator telescope pointer moving in CdC, and vice versa. So far no issues. EDIT: One day later, laptop was in hibernation during the day with a running instance of Stellarium attached to an ASOM simulated Telescope (ASCOM.simulator) and an ASCOM.OmniSim.Telescope. It survived hibernation and just continued. Howewer, the OmniSim telescope does not slew, it stopped sometime yesterday. Separating and reconnecting did not help (it moved to some location on reconnect, but stays there), but here I suspect this is not Stellarium's fault. So, for now ASCOM7 looks more robust, but I must invite actual telescope users who use also particular other programs and who had trouble last year, to compile with Qt6 and see if this version works for them. |
|
After days of nocturnal hibernation and trying a few slews each evening, switching eagerly between applications, I never experienced the crash that was present with ASCOM6.5. @alex-w, @10110111 shall I reactivate ASCOM with Qt6 in master, ready for 25.1, just requiring ASCOM7? Either it works now again for all, or it still doesn't work, we can only find out when testing with equipment combinations probably none of us has or uses. The Alpaca client will not be ready in 25.1, but I am reading the docs to prepare. |
Is it possible to get and check sufficient the version of ASCOM for and show alert dialog (Stellarium required ASCOM 7+) with blocking connection to ASCOM devices when version is lesser than required? |
Could you try, just to be sure that it's really the new version that fixed things and not your PC, whether you reproduce the crash if you replace ASCOM7 with ASCOM6.5?
If it's really the version that matters, and there is a way to check it, I'd make the requirement hard, e.g. saying about incompatibility in an error message, refusing to make any connection until the user fixes the installation. |
|
The latter requirement is fulfilled by modifying the test in ASCOMSupport::isASCOMSupported(). If I find time, I can install ASCOM 6.5 on yet another PC (2012 gaming notebook, W10/deprecated...) and try to trigger an error. Just that these spurious errors need to be triggered by actually operating the program in "observing simulation conditions", i.e., needs time. But maybe I have a result next weekend then. |
|
Intermediate update. Built this with Qt6.5, ran with ASCOM 6.6, plus v23.4, both driving same ASCOM simulator and seeing each other's slew actions. After a day-long standby, 23.4 finally crashed, but seconds later also this build "stopped working". Now updated to ASCOM 7, let's see. |
|
With ASCOM7 and running both versions plus Meshlab (just for another OpenGL app), 23.4 crashed twice, this build survived. I recommend adding ASCOM7 support to RC1 (the first 3 commits in this branch) and ask actual telescope users (bug reporters) for a test run with their real gear. If it still fails, we then know. @alex-w , @10110111 ? |
It's OK for me |
|
What happens if the user has ASCOM6? Do they get prompted to upgrade? |
|
With ASCOM<7 there is no option to configure a new ASCOM telescope. However, I inadvertently had built and launched this while ASCOM6.6 was installed. It occurred that an already configured ASCOM telescope simulator was available. After deleting it, I could not add a new one as ASCOM was not displayed as valid option. If you think it is really worth the effort, I could add a QMessagePanel when first activating the plugin that tests for ASCOM version number and shows a popup warning to upgrade or ignore warning and continue into the unmarked minefield. But I hope telescope users keep their gear up to date and most should run ASCOM7 by now, as it brought significant improvements for them. |
I wouldn't rely on this. Their gear may be up to date (lubricated, aligned etc.), but the software might be what worked last time. It's better to urge the users to upgrade if our stability depends on it. |
- Testing with ASCOM7 simulated telescope and switching between programs, so far it did not crash.
- removed all COM stuff - disabled any functionality - just compiles without function. - start point of developing further from Alpaca specs
gzotti
force-pushed
the
telescope-ascom-alpaca
branch
from
412354c to
8bb2527
Compare
|
@gzotti please fix compiling in non-Windows operating systems |
|
The plugin itself is not ready of course, only the (now) first two commits could be picked. Building the main program reportedly completed. I will see what is wrong with tests. |
|
I'm interesting how you will tests connection to Alpaca server? I fear unit tests is not applicable here... |
|
This is highly likely. As stated, I copied the ASCOM client for a start (because the mental concept of Apaca is equal to ASCOM) and just replaced the letters "ASCOM" by "Alpaca", then disabled all COM stuff. This plugin extension IS IN NO WAY ready for review or automatic tests. What I propose is REACTIVATING ASCOM support as ASCOM7 SEEMS TO BE stable. This can be done by cherry-picking the first two commits of this unfinished branch to master. Nothing that says Alpaca currently is expected to work before I switch to "Ready for merge". |
After the recently added warning message box I'm OK with this. |
|
Thanks. Right, studying the Python package and client may provide some insights what's actually necessary. Then the first great hurdle is the discovery protocol. |
|
There's already been some python client, someone opened a Discussion or something a month or two ago. |
Here it is: #3823 (comment). |
This breaks everything ASCOM attempting to upgrade to ASCOM7 protocol
Description
This branch shall be used to add support for ASCOM/Alpaca
Motivation: Our ASCOM support was reportedly prone to frequent crashes when built with Qt6
Qt5 is announced EOL in late May 2025.
Meanwhile ASCOM7 is out, and Alpaca, a platform independent IP based protocol, is the new player. So, replacing COM with that seemed the longer-time solution.
As first step I reactivated running ASCOM with Qt6.
Testing with ASCOM7 simulated telescope and switching between programs, so far it did not crash!
So, if anybody of the affected users can remember, how can I trigger a crash with the ASCOM simulated telescope? Or can anybody test that with a real telescope? I don't know what problem to look for!
If it keeps running stable, we can also make an ASCOM reawakening for 25.1.
I understand the Alpaca standard is platform independent, so it would be a new client for all platforms. When Alpaca works and ASCOM still occasionally fails, we can then bury it.
Fixes # (issue) [uncountable]
Screenshots (if appropriate):
Type of change
How Has This Been Tested?
Test Configuration:
Checklist: