My bad. libasi is the ZWO SDK and I didn't notice that the Linux Mint Update Manager wanted to install v1.28 (running version was 1.21). I was able to connect after completing the update.
Read More...
I also encountered this bug after a fresh install of Kstars 3.6.4 Stable on Linux Mint 21.1 and ZWO EAF firmware update 3.7.7.
I created a GitHub issue ticket in the INDI project
ZWO/ASI EAF: can't connect with INDI Library v2.0.1 (undefined symbol: EAFStepRange) #1895
INDI Library v2.0.1
ZWO EAF firmware v3.3.7
Device no longer appears in INDI Control Panel. It does appear in ASILive's EAF control panel so physical connection is valid.
When trying to Run Service "ASI EAF" using KStars Device Manager:
2023-05-08T05:03:16: FIFO: start indi_asi_focuser -n "ASI EAF"
2023-05-08T05:03:16: With name: ASI EAF
2023-05-08T05:03:16: FIFO: Starting driver indi_asi_focuser
2023-05-08T05:03:16: Driver indi_asi_focuser: pid=6603 rfd=10 wfd=10 efd=11
2023-05-08T05:03:16: Driver indi_asi_focuser: indi_asi_focuser: symbol lookup error: indi_asi_focuser: undefined symbol: EAFStepRange
2023-05-08T05:03:16: Driver indi_asi_focuser: stderr EOF
2023-05-08T05:03:16: Driver indi_asi_focuser: read: Connection reset by peer
2023-05-08T05:03:16: Driver indi_asi_focuser: Terminated after #0 restarts.
Read More...
I got it working! I had to disable pulse mode and then re-enable it in the INDI control panel for the AM5 (Options tab). Before testing Ekos calibration after toggling pulse mode off+on, I also sent a few zero length pulses using the Guide tab in the INDI control panel but that may not be necessary.
Read More...
Thanks, Jasem. The pulse property in the AM5 INDI control panel is enabled. I also posted this question on the Cloudy Nights forum. A member suggested I try issuing the pulse commands through the INDI control panel and I'll try that but it's looking like ZWO didn't implement pulse mode correctly so I'll post this bug on their forum later this week.
Read More...
Thank you for the quick response, Jasem.
I couldn't find any :Mg[n,s,e,w] commands in the logs. But there are :Me# and :Mw# commands like this one:
[2023-04-04T21:09:22.610 PDT DEBG ][ org.kde.kstars.indi] - ZWO AM5 : "[SCOPE] <MoveTo> "
[2023-04-04T21:09:22.610 PDT DEBG ][ org.kde.kstars.indi] - ZWO AM5 : "[SCOPE] CMD <:Me#> "
[2023-04-04T21:09:22.610 PDT DEBG ][ org.kde.kstars.indi] - ZWO AM5 : "[DEBUG] Moving toward East. "
[2023-04-04T21:09:22.793 PDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Moving E"
I've attached an extract from the Kstars debug log (log_extract.txt) containing the entries where calibration goes from RA drifting forward (west) to RA drifting reverse (east)
If CMD <:GR#> is the command to retrieve the mount's RA position, then you can see in the log extract that the RA continues to increase even after the :Me# command.
Read More...
Hello everyone,
Before I file a bug report, I wanted to check if anyone has successfully used the Ekos internal guider with the ZWO AM5 in pulse mode. I'm able to use the AM5 with the Ekos internal guider & ST4 but not with pulse mode control. When I try a calibration run, RA outward drift shows the green dots moving out along the an X or Y axis as it should, but the RA inward drift doesn't reverse direction. The white dots continue moving out along the axis. ST4 calibration works correctly.
I'm aware of needing to change the Guide selection in the Optic Train to "ZWO AM5" and I've double checked the INDI control panel for the AM5 under the Options tab to make sure Pulse Mode is ON/Enabled.
I'm on Linux Mint and updated Kstars/INDI yesterday (Kstars 3.6.3 stable, INDI library 2.0.1)
I have verbose Kstars & INDI log files to include with my bug report but maybe this is not an indilib.org problem and I need to file the bug report with ZWO since they provide the INDI driver (I think?) ?
Thanks for reading!
Read More...
Thank you, Jasem and Dirk, for your quick responses to my post. I originally included a quote of Dirk's post #66607 (which is at the end of page 2 of this topic) in my submission but unfortunately it looks like it didn't make it through so some of what I said won't make sense.
Anyway, the Mount Type (also termed Mount Code) is 0x06 as reported in the "Mount type not supported. 6" error message. A minor point to note: this error message only appears when connecting via Ethernet (for the AZ-EQ5 I used the Skywatcher WiFi adapter). A serial connection only returns the CheckIfDCMotor & SkywatcherAPIMount::Handshake - Result: 0 messages that Dirk describes in #66607. Maybe the code for the "Mount type not supported" message doesn't get triggered with failed serial connections but the underlying cause is the same.
#66607 also mentions that Jean-Luc did modify SkywatcherAPI to support his AZ-EQ5 and that's what I'm referring to in the first sentence of my initial post.
Thanks again!
Read More...
It seems that the code supporting the AZEQ5 mount that's described in the above post didn't make it to the current stable release of the Skywatcher drivers (v1.9.0)? I tried the alt-az driver v1.3 with my new AZEQ5 in ALT-AZ configuration and get the error message "Mount type not supported. 6"). Looking at skywatcherAPI.h from the master branch, I see there's no enumerated MountType for AZEQ5. skywatcherAPI.cpp from the master branch doesn't have the IsAZEQMount() code.
Was this an oversight since the AZEQ6 fixes suggested in this thread are in the master branch?
Thanks!
Read More...