It seems the library in ASI SDK (and thus repository as I've copied those verbatim) has some debug info included, but the one in deb-package has been stripped of those, at least the size matches exactly if I copy libASICamera2.bin to libASICamera2.so and run "strip" (or llvm-strip actually as I tested this on x64 machine and regular strip doesn't recognize aarch64 binaries) on it:
jpaana@thinkpad:~/src/indi-3rdparty/libasi/armv8$ ls -l libASIC*
-rwxrwxr-x 1 jpaana jpaana 2243289 Jan 5 00:47 libASICamera2.bin
-rwxrwxr-x 1 jpaana jpaana 1887712 Feb 24 00:35 libASICamera2.so
Yes, there is an option to force the target pier side, which does what you want. It has safety limit so that it allows the mount to go only one hour to the "wrong" side by default, but is useful for "pre-flipping" the mount. The option has to be set before making the slew, it doesn't do anything by itself. It's also not saved between sessions by design, setting back to auto restores the normal flipping behavior.
Cooling down is triggered by sequence and set on top left of the sequence screen, remember to check the box to apply:
It is totally dependent on whether the ASI SDK supports it or not. The nightly builds use the newest SDK available so if that doesn't work, then we need a new one, but I'd assume ZWO would have added that a while ago already. You can check the SDK version your driver uses from the Info tab of the driver panel, it should show 1.16.3 for the current version.
Excellent, thank you! I think the driver is now in complete enough state to be useful to people. If there are things you notice that would be nice to have or fix, feel free to ask. There is some functionality I didn't expose like weather information (which in your data seemed to be missing anyway) and rotating the dome CW/CCW like the hand controller does or emulating relative moves, but probably not important enough to bother at this point. Hopefully I'll get to our club observatory at some point to use this as well
Found a stupid mistake I made in the previous version when I cleaned the state transition handling when controller completes the move command (and shutter operation too) that I accidentally overwrote the previous state too early. So here goes, hoping this finally fixes the slaving issue. Again pushed to github.com/jpaana/indi/tree/ddw_state_fix_again and github.com/indilib/indi/pull/1351
Thanks I'll have a look and try to figure out why the dome doesn't want to move more than once without abort. Dome not following when parking the mount is a feature, it only follows the mount when it's unparked, not while parking or being parked.
As for the SX and other 3rd-party drivers crashing the issue most probably is that they have been compiled against an older INDI base library version and it has changed quite a bit in the recent weeks. So they would have to be recompiled against the same version you have compiled with the DDW driver. Fortunately that is also quite straight forward CMake project though the repository is now separate from the main one. Instructions you can follow are on the same page indilib.org/forum/general/210-howto-buil...st-libindi-ekos.html but it's similar to how you have compiled this driver, just create a separate build directory and point cmake to either the indi-3rdparty repo root to build all drivers (or disable the ones you don't want with cmake-gui for example) or you can create a separate build directory for each and point cmake to indi-3rdparty/indi-sx for example.
Yes please, it seems you forgot to attach the log earlier. The combined log is more useful as it helps to see both sides of the snooping and what they were doing at what time.
If you run KStars/Ekos, it overrides the logging settings done via INDI panel, which is a bit confusing, but you should enable them from the Ekos logging panel:
Ok good. The slaving issue is a bit harder to figure out as the movement state should now be correct. Could you take logs of both the dome and scope for this sequence:
- starting both from park state
- unpark dome
- unpark scope, dome might move to match the scope azimuth, wait until it reaches target
- slew to somewhere south-west-ish
- wait until scope is idle and if dome doesn't move with the scope, hit abort if that helps
- wait until both scope and dome are idle
- slew to somewhere south-east-ish (scope should flip, dome shouldn't go around but use the shorter route)
- again wait until scope is idle and hopefully dome has followed
- park scope first, wait until it has parked and then park dome
The KStars log would be nicest as it has both device logs in the same file and in correct order, but separate logs work too.
Ah, that would explain it, as the controller doesn't then actually know the state of the shutter if it's in between. I already pushed an update that changed the value,but I reverted it now. But now I avoid sending the state multiple times so it doesn't print that warning more than once. Pushed to github.com/jpaana/indi/tree/ddw_shutter_state_fix and github.com/indilib/indi/pull/1349
The unknown shutter status warning is a "feature" of the controller which I didn't expose before, it reports the shutter status as open/closed/unknown. Upon reboot it doesn't seem to know the status until an open or close command has been issued and completed. I'm not sure what I should do about it, but at least I can make it less spammy by not setting the state to the base class if it already is the same so it would trigger the print only once. But there also seems to be some bug in there as the status should be valid after you have opened and closed the shutter but the warning is still printed. From the log it seems the status numbers are incorrect in the documentation.
DEBUG 127.478333 sec : GINF packet: V4,690,25,3,29,0, --> 0 <--,1,0,20,31,0,128,255,255,255,255,255,255,255,999,3,0
DEBUG 1151.965279 sec : GINF packet: V4,690,25,3,25,0,--> 1 <--,1,0,20,31,0,128,255,255,255,255,255,255,255,999,3,0
but documentation says:
/* GINF packet structure:
Field Content Note (each datum is separated by comma)
1 V# Denotes Version Data. E.g., V1
2 Dticks DTICKS is dome circumference in ticks 0-32767. Value is sent as a string of characters, e.g., 457. Leading zeros not transmitted.
3 Home1 Azimuth location of the HOME position in ticks 0-32767
4 Coast Coast value in ticks (0-255)
5 ADAZ Current dome azimuth in Ticks 0-32767
6 Slave Slave Status 0=slave off 1=slave on
7 Shutter Shutter status 0=indeterminate, 1=closed, 2=open <---
8 DSR status DSR Status 0=indet, 1=closed, 2=open
9 Home Home sensor 0=home, 1=not home
10 HTICK_CCLK Azimuth ticks of counterclockwise edge of Home position
11 HTICK_CLK Azimuth ticks of clockwise edge of Home position
12 UPINS Status of all user digital output pins
13 WEAAGE Age of weather info in minutes 0 to 255 (255 means expired)
14 WINDDIR 0-255 wind direction (use (n/255)*359 to compute actual direction), subtract dome azimuth if weather module is mounted on dome top.
15 WINDSPD Windspeed 0-255 miles per hour
16 TEMP Temperature 0-255, representing -100 to 155 degrees F
17 HUMID Humidity 0-100% relative
18 WETNESS Wetness 0 (dry) to 100 (soaking wet)
19 SNOW Snow 0 (none) to 100 (sensor covered)
20 WIND PEAK Windspeed Peak level over session 0-255 miles per hour
21 SCOPEAZ Scope azimuth from LX-200 (999 if not available)
22 INTDZ Internal “deadzone”- angular displacement around the dome opening centerline within which desired dome azimuth can change without causing dome movement.
23 INTOFF Internal offset- angular distance DDW will add to the desired azimuth, causing the dome to preceed the telescope’s position when a slaved goto occurs.
24 car ret
25 car ret
So I think I'll change that to match what the hardware actually sends instead.
Beeping I'm don't know anything about, haven't done anything to produce those or not, I just send commands
As for slaving I'm not sure what the problem is as it seems to always calculate the scope azimuth as 0 in your log and thus not move anywhere:
DEBUG 247.678610 sec : JD: 2.45925e+06 - MSD: 11.4864
DEBUG 247.678695 sec : MC.x: 0 - MC.y: 0.07 MC.z: 0.34
DEBUG 247.678723 sec : HA: 6.00029 Lng: -107.985 RA: 334.307
DEBUG 247.678808 sec : OTA_SIDE: -1
DEBUG 247.678832 sec : OTA_OFFSET: 0.33 Lat: 32.4878
DEBUG 247.678852 sec : OC.x: -2.48124e-05 - OC.y: -0.10725 OC.z: 0.0616431
DEBUG 247.678874 sec : Mount Az: 0 Alt: 32.4878 <
Hm, the log doesn't show the sequence I was expecting, it should have printed "Dome already moving, latching the new move command" and not "Please stop dome before issuing any further motion commands." which comes from the base class. Have to trace things a bit more as I haven't had this issue with my own dome (different driver, but also mine). Might be I'm not resetting some state correctly when the motion ends.