I used to have a time out problem too. I solved it by decreasing the search radius. If you know that the scope is close to the target, decreasing the search radius can help.
Just a thought.

Wim

@Eric, thank you very much! As a newbie, I inadvertently posted a whole folder of logs.

Here's just the last session (much smaller file!), which includes a bunch fo alignment failures.

I've never heard of QCustomPlot. Is there something I need to turn off so I don't get all these errors?

@Wim, thank you -- I will give that a try tonight.

No problem, thanks for updating. You have a 174MM Mini as guide CCD and a 094MC Pro as main CCD. What the log shows is that the first capture leads to a successful solution in 115 seconds, and that solving further captures fail.
The first capture at 20:57:48 is sent to the solver, which returns a solution at 20:59:58. A sync point is created, and the mount slews to the corrected coordinates. There seems to be a settle time of 15 seconds after slewing.
The second capture at 21:02:06 is also sent to the solver at 21:02:20, but there the solver is somehow failing at 21:05:20, after 3 minutes, and requests a new capture. That new capture fails because another capture - invisible in the log - is in progress, but is retried. An additional capture is requested at 21:05:21, sent to the solver, but there you apparently stopped the solver after less than one minute.
Next captures are producing essentially the same sequence of events, but I assume you tried with the online solver. What I find weird in the first attempt is that a new capture is requested before the solver times out, but that might only be messages ordered in a strange way in the code. The fact the second capture fails because of a capture already running is strange too. I'd suggest trying with a single CCD connected, just for testing.
For the online solver, no idea right now, could you provide your Ekos settings?

-Eric

Can you also install index-4215.fits ? I have almost same scale as yours 400x 600 (135mm on zwo 1600) and I do not have any issues plate solving with ekos.
Takes about 4-8sec on Tinker board for offline solving.

@Eric, I've attached screenshots of the settings panels for the Ekos Align module below. I notice that on my mac I also have a 4th panel that allows me to directly edit a conjuration file for this, but there's no such 4th panel on my ubuntu machine. Also, thanks for the suggestion to try disconnecting the guide camera in case the image scale is being taken from the wrong place. I will try that tonight.

@tkottary, I have index-4215.fits installed. As you can see in the attached screenshot, I have all the indexes from 4206 through 4219, so it should solve quickly and easily.

I must have something wrong in a setting someplace, but I don't know how to find the problem.

I am trying to test this during daylight by solving images from .fits files, and I have the same problem.

Following Eric's suggestion, I disconnected my guide camera so that I only have one camera active in INDI.

Then I fired up Ekos and connected the camera and mount. In Kstars I selected the Veil Nebula in Cygnus, which I've been imaging.

Then in the Align module in Ekos I clicked "Load and Slew" and selected a .fits image of the Veil from last night. As far as I can see, both the initial guess of the coordinates and the field width passed to the local solver are very close to the correct values.

Brief but verbose log is attached below.

The solver is called and does a bunch of things, some of which I don't understand. It finds 2258 light sources. In my previous post, I included screenshots of all the Options panels from the Ekos Alignment module.

After a long time (several minutes), Ekos reports it's taking an image, which I didn't ask for. Then it reports the image has been aborted (again, not my doing).

Finally I tried the whole thing again. No solve, no error.

Thanks very very much for your help!

Scott

Would it be possible to have the Veil FITS you used for this log, so that we have the same inputs? I will run the same command on my Linux system for comparison.

-Eric

Sure! Here's a link:
www.dropbox.com/s/ccnqt6n0bm5xuie/Veil_L...-04-32_014.fits?dl=0

I'm going to learn how to use the /usr/bin/solve-field command line and try to debug the problem without Kstars and Ekos. Then maybe I will understand why the solver fails inside of Ekos.

I *really* appreciate your help!

I just figured this out yesterday...
Command line arguments to solve a fits file using solve-field

The solve-field command line arguments are documented at: manpages.ubuntu.com/manpages/xenial/man1/solve-field.1.html

The part I'm interested in are the options -L and -H, and their relation to your FOV. Basically, these affect which catalog/index files will be used. If you increase the interval, solve-field will use more indexes while searching.
Given your imager is 7376x4928, and your FOV is assumed 600'x400', this makes a rough resolution of 4.9 arcsec/pixel. So theory would tell that the options seen in the log would be OK, and that there is even room for improvement in terms of search time.
Now, there is the parity option, which tells the solver if the frame is optically inverted or not compared to the catalog data. Normally the first solve is not using that, and when successful, the parity is deduced and used afterwards by Ekos in the options, theoretically halving search time.
We're then left with a few options. The FOV of your setup could end up not being what you think: you can use one of your frames directly on nova.astrometry.net and have a solver job provide you with the information. Or your timeout could be too short, although 3 minutes is already very long. My 1.6GHz atom with 1GB of ram usually solves the first frame under a minute.

-Eric

Just a suggestion but check the number of stars being resolved. If it very high ( i limit it to < 500) you can modify the "down sampling" from the default 2 to say 10 to lower the number of stars used - for me this helps platesolve work 99% of the time and faster.

Note on poor seeing nights you will have to lower the value back down towards 2 depending on the number of stars recognised.

Hope that works for you too !!!