It appears it did not build for v2.02, it is included in the source area but not available in the Ekos profile and missing in /usr/bin. Something I missed to generate inclusion?
That would be good. I installed the Raspberry PI OS 64 bits on a RPi4. Then the build succeeded after a couple of non fatal errors.
Just now ran Ekos with simulators for mount and camera which duplicated the problem you were having listing libXISF.so. I picked up the build 4 hours ago, so perhaps I just missed the fix if there was one.
I have a build in progress now. Raspberry Pi official OS, 32 bit. RPi3 1GB so it will take some time. The script took care of building and installing libXISF.so which I had not caught onto previously. It was installed into
/usr/local/lib/arm-linux-gnueabihf/ along with other libraries.
root@rpi3:/home/tg# ls -ltr /usr/local/lib/arm-linux-gnueabihf/
-rw-r--r-- 1 root root 1074728 Jun 25 2022 libstellarsolver.so.2.3
lrwxrwxrwx 1 root root 23 Jun 25 2022 libstellarsolver.so.2 -> libstellarsolver.so.2.3
lrwxrwxrwx 1 root root 21 Jun 25 2022 libstellarsolver.so -> libstellarsolver.so.2
drwxr-xr-x 2 root root 4096 Jun 25 2022 pkgconfig
drwxr-xr-x 3 root root 4096 Jun 25 2022 cmake
-rw-r--r-- 1 root root 954404 May 30 16:06 libXISF.so.0.2.1
lrwxrwxrwx 1 root root 16 May 30 16:06 libXISF.so.0 -> libXISF.so.0.2.1
lrwxrwxrwx 1 root root 12 May 30 16:06 libXISF.so -> libXISF.so.0
The other stuff in there is old from when I last used the build script. Will see when it completes if the directory is included in the search list.
.xisf is a PixInsight file format, support for this was recently added or is in progress. The Raspberry Pi OS should be fine so hold off until someone familiar with the update sees your thread. I have a RPI3B which I think is running the RPi OS and an older version of nou's script, will see if it still boots for comparison,
Might just be missing a prerequisite.
I am not running a Raspberry Pi but on an Odroid:
sudo apt list libXISF
libxisf/jammy,now 0.2.4~202305202331~ubuntu22.04.1 arm64 [installed,automatic]
If it is not installed try installing:
sudo apt install libXISF
I looked at log _21-01-21.txt and see:
[2023-05-29T21:07:53.704 AEST DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI1600MM Pro : "[DEBUG] ASIGetExpStatus failed. Restarting exposure... "
[2023-05-29T21:07:53.705 AEST DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI1600MM Pro : "[DEBUG] StartExposure->setexp : 1.000s "
On my system I get similar failures consistently after 17 exposures if I run with the firs viewer enabled. If you are using the viewer, try disabling it in the KStars settings, to see if that helps.
On whether the roof driver is involved, it is not an obvious suspect. It does though appear to be having problems during the initialization and indicating roof closed during the test.
The Ekos profile does have a duplication under Filter: ASI EFW and ZWO_EFW, might be involved.
I want to submit sources for a roll off roof driver to be added to the 3rdparty drivers.
I forked the indilib/3rdparty repo to github.com/wotalota/3rdparty which has the files added to a directory indi-rolloffino.
- Added the driver to the 3rdparty/CMakeLists.txt
- Added a 3rdparty/indi-rolloffino/indi-rolloffino.spec file similar to other drivers.
A manual build was tested on a system with a indi-full install and the additional need for libindi-dev.
I hope it can be built and be available as part of an install to save users from the hassle of building it. Is there more that I need to do for it to be compliant? Also, can I do a Pull request directly referencing the forked repository or are there interim steps for merging it in?
No longer seeing the backlash.
Tried using the Dark library generation. The camera indi control panel was modified to /astro/collect/Dark and files stored there. But they should have been stored in .local/share/kstars/darks.
Running ubuntu 22.04 KStars 3.6.3 and indi 2.0.0. Having failures saving images.Seems like the problem that comes and goes from time to time.
Whether or not related, do not have control of the directory to use for saving images. KStars/Ekos and the drivers are running on the Odroid but the same issue is happening on a x86-64 system.
In Ekos specify to save the image locally and specify "/astro/collect"
On the indi camera panel specify client "/astro/collect". These local/remote settings do not seem to effect the problem.
I save and reload the indi setting and it is stable.
In the indi panel when it starts taking an image it changes the directory specification to use backward slash "\astro\collect\Light\LPR".
It fails to save the images and has in the past created a directory named "~\astro\collect\Light\LPR" in the home directory, at times placing files in that directory. Usully it just fails without the directory being created.
I don't know where the back slash specification is coming from the .indi directory after failure looks normal:
<newSwitchVector device='ZWO CCD ASI294MM Pro' name='UPLOAD_MODE'>
<newTextVector device='ZWO CCD ASI294MM Pro' name='UPLOAD_SETTINGS'>
The log file indicates the correct expected directory is being used.
With "~\astro\collect\Light\LPR" being set as the directory to use
and two systems showing the same problem. Can that blacklash specification be located and avoided. There was some combination of things that started working yesterday but not finding it again today.
rolloff simulator does not actually use an external device, it provides the framework and simulates the action of opening and closing. I have a driver developed from the simulator that might proved a starting point for you to use.
There is a html sub-directory that provides and overview if you copy that to a local directory. It works via an Arduino controller, various versions of which are provide.
If you were thinking of directly using Raspberry Pi GPIO connections I have one that does that using pigpio but it is not yet fully debugged, it still has a timing issue at startup.