I just had my first 100% automated night using the Ekos scheduler. It was near perfect !!! but I had some small issues coming from misunderstood concept, so I have now some questions I scheduled two targets, one was high in the sky early, the other after 2am, so I use an object altitude constraint (>65°).
My first questions are :
- The first target drop below the 65% constraint at ~90% of job done, but the scheduler pauses until the next day, pausing also the second job, so I had to delete the first target to start the 2nd one (may be a "live" reorder has been enough ??)
- Is the scheduler able to start a job "in the middle" of another job with less priority - as soon as the highest priority constraint is reached - and then resume lowest priority job when it's finish (assuming the low prio job doesn't have any constraint so it can start before the highest one)
- what is the mount behavior between two targets when there is some time to wait between both ? does it park ( even with preemptive shutdown uncheck)
- Is there any examples of startup/shutdown scripts more complex that the one in the documentation ? (using indi to talk to devices for examples...)
I also had a display bug in the job list : the end time of the running job decreases each time a frame was done (it seems its calculated this way : start time + job remaining time instead of current time + job remaining time)
I'm using kstars 3.5.0 nightly build
Thks for support and for this amazing tool !
What an explaination
So yes, I was always starting my DSLR (and then ekos) in Bulb mode... so it explain why it was working w/o bulb force
@Herrhausen, Are you sure Force Bulb to ON has any effect when camera is in bulb mode ? i've not seen any difference in my tests.
I'm using kstars/ekos with a 5D Mark III and experienced problems when it was time to capture flat frames.
The 5D mark III is part of the canon DSLRs where the bulb mode is separated from manual mode on the dial.
I've try to make some test to clarify things, here is what I've noticed :
Hello, I'm working on a INDI client and while testing it I had a strange behavior with the CDD Simulator CCD_COOLER property.
When I set the vector to :
no problem, the property vector is perfectly changed, but when I want to stop the cooling, sending :
it's strange : first I received a setSwitchVector message with the correct updated state, but then immediatly the indi server send me a new one where COOLER_ON and COOLER_OFF are both "On" (strange for a "One Of Many" switch)
Between thoses two updates, I received a message saying the sensor has reached the temperature.
I first believed an error in my code, but a simple telnet in parallel show me the same values.
Any ideas ? This is the only switch having this problem, may be a bug in the simulator drivers ?
So, I've been able to reproduce the problem. For this, closing/restarting kstars hsn't been enough.
- reboot my computer
- start kstars
- open Ekos and connect simulators
- add a new sequence without changing the pre-filled "Directory" parameter
- start the sequence
then, Ekos is not incrementing the frame index in filename.
As soon as I open the browser UI of the "Directory" param, no problem anymore (even if I restart kstars, this is why I suspect a link with OSX app permissions)
wcreech19, I don't know stellarmate, but in this case, kstars/ekos is on the stellarmate board ? or do you connect it through INDI on a computer with its own kstars ?
In the first case, it can kill my diagnostic, because there is nothing about OSX and its permissions system in your stack. Btw, may be re-browse the destination folder can have some effect in ekos, so it would suggest a bug somewhere ? I've been unable to reproduce it since a rebrowse, even after a kstars complete restart
Ok, I think I've pointed the problem.
When I started Kstars/Ekos, I have been to the capture module, and the document folder was already set, so I didn't open the file brower to select it. I think the consequence is kstars hasn't "unlock" the osx security on the document folder or something like that... As soon as I've opened the folder to select one (or even reselect the same after that) no more problems it has just ruined 45 minutes of shoots astro life ......
knro, may be you point the problem. Permissions ..... OSX has some f$*#% permissions system to allow application to access to some folders... but the strange thing is kstars has been able to save files, so I don't usderstand why it could not "read" thoses files to determine the next name to use.
The base folder is /Users/anthonyhinsinger/Documents/Ekos/test1
The light files have all been saved as :
Last night I had a problem with Ekos (3.4.1 on MacOSX). If I start the sequence (for example a 15 lights) from the capture tab, all frame are named with the 001 index, so next frame overwrite the previous one. If I save the sequence definition and use it with the scheduler, no problem there, the suquence number is correctly increment.
Do I miss anything crucial in my understanding/settings of Ekos capture module ? or is it a bug/problem ?
The package is available on NPM and the code on github.
I hope it can interest anyone there the primary goal for me is to start the development of the full-web observatory management app.
There is a lot of work to do yet, as only the client part of the INDI library is bound now.