There are multiple sessions in the log.
The first one or two had only the mount device with focuser connected via AUX port. Some focuser properties are reported in the log by the Celestron AVX device. OT drop down showed no focusers.
After some tinkering I re-connected the focuser with a USB cable, added the Celestron SCT device to the profile, and it became available in the OT configuration. This is how it worked for the rest of the night. It works fine this way, except cabling is less convenient.
It just got worse with the last release of KStars. Optical trains configurator does not recognize the focuser presense. So both trains have no focuser rendering Focus module unusable. Focuser tab is there under mount's INDI device and I can tinker with it directly.
Here is more detailed log from last night. KStars made it almost to the end but still crashed at 5 AM
This is the latest version from PPA. Similar crashes have been happening to me over several last months. Though I cannot promise it is the same spot.
On some nights it is going solidly. On others, with the same config, it's tripping multiple times. Last night it crashed after 3 hours of running. I restarted it and it crashed again in 2 hours.
INDI server and drivers keep running after crash, it's only KStars itself gets a segfault.
See the log, the focusing is just started. It is likely starting an exposure or receiving the image.
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:131 #1 0x00005644b84ca49f in INDI::BaseDevice::setBLOB(_IBLOBVectorProperty*, xml_ele_*, char*) () #2 0x00005644b84caf37 in INDI::BaseDevice::setValue(xml_ele_*, char*) () #3 0x00005644b84ceed7 in INDI::BaseClientPrivate::dispatchCommand(xml_ele_*, char*) () #4 0x00005644b84cfe4c in INDI::BaseClientPrivate::listenINDI() () #5 0x00005644b84d01c9 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<std::_Bind<void (INDI::BaseClientPrivate::*(INDI::BaseClientPrivate*))()> > > >::_M_run() () #6 0x00007fd6742f52b3 in std::execute_native_thread_routine (__p=0x5644bf908640) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82 #7 0x00007fd673f7cb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 #8 0x00007fd67400ea00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
If absolute focuser means that it can move to specific position directly rather than moving in or out then Celestron's focuser is absolute.
I second everything Ron said above. A few versions back it worked fine and displayed the activity correctly as a short bar. Then it broke and now focuser activity is displayed only when session is read from file. Also, as it appears to me, all the bars start at the session start and end at different times when each focus procedure actually ended. So they effectively overlap and look like one long bar.
As a quick guess, can it be that the live session does not show the focuser because there is no dedicated INDI device? It goes via the mount device.
I have a Celestron AVX mount and Celestron SCT focus motor.
When the focuser is connected with an AUX cable via the mount, Ekos Analyze module appears to think there is no focuser. So it doesn't show its actions on the time line. Focus tab and all other functionality work fine. If I open the analyze record later, all focuser activity is there and displayed. Only current live session is affected.
When the focuser is connected with a USB cable directly to the PC, everything is fine, except cabling gets more awkward, so I don't want to do that.
Proper versioning is the answer to the problem. Say, if the new version of INDI would not work with previous version of drivers, as it is usually the case, its version number should be bumped high enough to not match the drivers' dependency lists. Then, in case of Launchpad slowness, you as a user would see nothing (in Software Updater UI), or some conflict warnings (from apt CLI). At worst, it may offer you to upgrade INDI and uninstall drivers, which is still suspicious enough so that most users would cancel that.
I would love extra resiliency too. Until then, there is an option to re-align at the beginning of each job. So you simply have short sequence and let the scheduler repeat it indefinitely or until certain time. In case when guider locks in wrong direction, you would only have a few remaining subs misaligned, then it re-aligns and continues nicely. My sequences are like 18×60s or 36×15s. Once in a while I get that cloud and the scheduler recovers soon enough.
That is what I read on the internet about high speed mode too. Funny enough, I do not see the ADC width reduction with my ASI294MC (that is MC, not MM). I kinda see a slight difference in dark noise patterns with high speed enabled or disabled. But in both cases the data numbers seem quantized at 14 bit. I guess, this is why I had this mode enabled, apparently harmless. Better disable it for good.