I'm curious if there's a common thread among the people who experience this leak (e.g. I still can't replicate it, and as of recently, I don't believe Jasem could either--I know he's hard at work looking into it). For instance, are you all DSLR users? RGB camera users with debayering, etc?
If you experience this leak, could you please post more details about the minimum configuration you use that will trigger this leak.
camera model and type, e.g. Canon DSLR with resolution WxH, ZWO 1600 monochome resolution WxH, ...
fits, raw, ???
Running fitsviewer while you capture?
Processor (e.g. RPi4) on what OS (Raspbian? Ubuntu 18.04? Stellarmate?)
How did you install KStars (Stellarmate, AstroPi3, AstroBerry, ...)
What release are you using when you observed the leak? (released 3.3.9, nightly at what date),
Also, can you tell how much is leaked per image? (e.g. by running the linux command 'ps aux | grep kstars" after every 5th or 10th image for as long as makes sense) and how that relates to the size of the image your camera captures
Thanks you two. It turned out that plugging the 290 into the 1600 did the trick (whereas plugging both into the powered hub didn't work).
Love this forum!
I'm trying to configure Ekos with a ZWO 1600 for imaging, and a ZWO 290 for guiding.
I don't see how to do that. In the configuration setup, I selected ZWO CCD for both Guider and CCD in the Profile editor.
I connect both cameras, start up Indi, but we only get one camera tab in the indi window, and don't think we have the guider connected.
Is this possible? How should we proceed?
Glad you fixed it. Funny thing is that a similar thing just happened to me the other day--my Moonlight focuser wasn't working and I discovered that even though the indi focuser driver tab showed movement, the physical focuser was not moving. It turned out I hadn't connected the serial cable between the focuser-controller and the focuser-motor. I was about to respond to you asking if you might have bad cables.
I guess many of these focusers don't really have an accurate mechanism for knowing their current position.
I was wondering, for the folks with the memory leak--do you have the option "Single Preview Tab" checked? (I think you should have it checked).
You find that under the KStars options, then FITS, then it's a checkbox on that page.
I believe that KStars/fitsviewer would leak tabs if you had it unchecked (perhaps it should limit the number of tabs, I don't know if it does or doesn't).
Sorry, there was a bug in 3.3.9 that results in your issue. It was fixed last night. It only occurs with focusers that cannot move to absolute positions, but clearly, yours is one of those (given the FOCUS_TIMER_VALUE message).
A work-around for now would be using the nightly build indilib.org/download.html
I know that the fix is in the latest code, and it may be in the latest nightly build release, but I'm not sure. For sure by tomorrow.
This bug affects all focuser algorithms, not just the experimental one.
BTW, once things are working for you, I'd love to hear if the new algorithm is an improvement for you. It's still a work-in-progress, though. Make sure you start it up reasonably close to focus (e.g. fine tuning, but not major focus changes). Also, I'd recommend checking the full-field button, and experimenting with the step size.
I believe the max travel setting is a relative one, meaning max-travel-from-the-start-position, controlling both in or out directions.
So, if the focuser is positioned at 20000 at the start of auto-focus, and maxTravel is set at 1000, then the auto-focus algorithm is allowed to move the focuser between 19000 and 21000.
There are probably other min and max movement parameters in the Indi control panel for your focuser that control the minimum and maximum absolute position.
FWIW, I use a fast USB stick (
) on my RPi4, of course on the usb3 port, and capture directly to the stick. In the morning, I walk the stick over to my Mac, plug it in there, and backup my images. This seems to be fast-enough (takes a second or two to write an ASI1600mm image). I've never tried an SSD (though I plan to), but this approach was a big improvement over writing to the SDCard, then copying from the SDCard to a usb , ...
Can I also walk the SSD over to the mac? That sneaker-net approach works great!
I'll try to answer but I'm not familiar with the time-based module you speak of. My new algorithm only runs if (a) you select it from the drop-down menu, and (b) if currentFocuser->canRelMove() is true, or if currentFocuser->canAbsMove() is true. If neither of those is true, then it won't run. From the name (timer-based) is sounds to me like, unfortunately, it wouldn't run.
I'll let Jasem answer more fully, though.
That said, if I'm right in what I said above, and you think it would be valuable, and you would be willing to help me test I don't see why we couldn't translate stepper steps to milliseconds that a motor runs and allow it to run.