I posted awhile ago about having the scheduler quit on the first job -- the issue was that it was trying to rerun the same sequence and saw the frames in the target folder, and so figured it was done.

Now I have essentially the opposite problem. I'm still trying to set up a fairly simple schedule. I have eight RA/DEC coordinate pairs to shoot, and I want to do exactly the same thing with each of them. It would be helpful if the output wound up in a single folder, but that's not a showstopper.

So I have the scheduler set up to do eight jobs. There is a separate sequence file for each job, even though it's doing the same thing. The trouble is, the scheduler endlessly cycles on the first job, slewing and shooting frame after frame.

I had to turn off all the job constraints so I could test this in the daytime, but it should still work, no?

I can post the schedule and sequence files if anyone wants to load them up and look.

Thanks!

Certainly worth posting. Maybe also a screenshot of the scheduler tab.

My RC is sitting on the shelf for now, as I acquired a 130mm refractor. Haven't sold the RC yet, so I still want to keep up with how Ekos works for the wavefront collimation. (frac has a bit of a violet problem - not terrible, more like just enough to annoy me and keep me from selling the RC yet)

Sure, thanks.Here are shots of it in operation. The only bit missing is the additional line appearing in the output window that says that the job is complete.I selected two stars that are up so I could at least have the "Alt" checkbox selected, just in case one of those was required.Setup: Running: Still running:

To provide a little background here, I'm trying to streamline the workflow for producing collimation images for SkyWave, Innovation Foresight's software. I want to analyze images of the same defocused star spaced around the periphery of the FOV. Another SkyWave user did the spherical trig and wrote a helpful spreadsheet that, given your imaging train characteristics and the RA/DEC of your target star when centered, generates the set of coords to put it in the right places.

I wrote a Ruby script that would start with a template esl file, read the numbers out of the spreadsheet, and insert the correct <J2000RA> and <J2000DE> elements. I also had it put in the name, so that when the schedule runs the Target is filled in as e.g. Top or TopRight.

When I encountered this problem, I wondered if my script was borking something so I generated new schedule and sequence files from scratch in Ekos. Same result. This is KStars 3.6.4 from a fresh install of StellarMate OS 1.7.6, BTW.

Edited to add: I was also curious about whether the "Name" slot in the esl would fill in the filename template in the sequence, as it does when you look up a target and then run the sequence. If I search for, say, Capella and slew to that, Ekos appears to "know" about it and include that in the lights' names. Which would be awesome, it would be great to have the outputs labeled "Top.fits", "TopLeft.fits", etc..

Rick,

I downloaded your .esq and .esl files and was able to reproduce what you were seeing using the simulator.

I believe that the issue is that you have a relative path in your .esq file in the "Directory" field, where apparently you need a full path.
So, inside your .esq file, if you replacewith, for example,I'll bet it will work.

If you use the file picker to enter the directory field, I believe it should give a full path, but it is true that one can enter a relative path by hand (or by editing the file). I'm not sure why the relative path causes the scheduler and capture modules to "disagree" about where files are saved, but I'll try and look into it.

A few other comments.
If you wanted, you could always uncheck the schedulers option "Remember Job Progress" in situations like that (a bandaid, not a fix for the underlying issue).

Also, when you mentioned you removed constraints to allow the job to run during the daytime--that's fine, but FYI, another approach is to use the KStars "Time" menu to set the time to whenever you want.

Hope that helps,
Hy

Rick,

Actually, I'm not 100% sure the fix I gave you would work.
However, I think if you made sure the directory you gave it ended with a separator, e.g. slash '/' on non-windows machines, then I think you're good. SoI did find an issue in the code and I'll send it in for review.
Hy

Hy, thanks so much! Good to know that I'm not just imagining things. It's easy-peasy to add that slash to the path, of course, so I will try that out. I had started with a schedule file created on my PC, polluted with all kinds of nonsense like drive letters -- who does that in the 21st century?!! -- and backslashes as path separators. Hand-edited that, welp, there's your problem, kid.

I'll let you know how it goes. I have no idea of the overlap between SkyWave and INDI users, but I'd be more than happy to contribute my script back to that community, if it exists!

Dang. I regret to report that modifying the path as you suggested yields the same behavior, Hy. I tried some other things, like "Classic" instead of "Greedy" scheduling and setting the priority of the second job higher or lower. Same result.

I've never seen this happen in the field with older KStars versions -- I can't be the only one using the scheduler, it must be something idiosyncratic about how I'm using it. But for the life of me I can't figure out what that is.

Can you send your updated .esq and .esl files?

Sure.

Hi Rick,

I took your two files and ran them in the simulator (after making a few of modifications):
1- I changed any directory names to directory names that would work on my machine, keeping all the other particulars like trailing / the same.
2- I changed to the greedy scheduler algorithm. There is no reason to run the classic algorithm IMHO, and no one maintains it. I really want to delete it.
3- I removed all capture fits files created during previous debugging.

After doing this, I ran the esl in the scheduler.
Note--you too should be able to run with the simulators profile to check things out.

It ran the first job, then completed--without running the 2nd job. Is this what happened for you too?

I looked into it, and the reason the 2nd job didn't run is that it has the exact same file naming as the first job. That is, you're not using the job name in the filename.
Instead of the Format: %T_%F that you chose, instead I'd recommend something like:
/%t/%t_%T_%F_%e_%D

Perhaps you thought that %T meant target? Actually it's %t (%T means type, as in Light Dark Bias). The explanations are in a mouse-over over the word "Format:".
Believe me, I wish it wasn't this complicated too.

Attached are new versions of your .esl, but with your directory names put back in, and with the file naming set back to yours.

Summary: I think that the issue was your choice of file format, which didn't contain the target name. Other than that, I think your files should have worked. They probably would work with the classic scheduler too, but as I mentioned, I'd prefer if you used Greedy.

Hy

I do not see any attachments to your post, Hy. Am I missing something?

Anyway, I tried your suggestions with the simulators and it worked perfectly -- I didn't even get the quit-after-one problem that you did. I altered the filename template to remove the initial /%t, because I really would prefer that all the lights wind up in the same folder, just with different names. And that is exactly what happened. I had two jobs in the scheduler, one named "Top" and one named "TopLeft" and I got two FITS files out, whose names started with the appropriate target name. Perfect!

Then I tried it with my hybrid setup -- I have my imaging cam, guide cam, and filter wheel sitting on my desk connected to the Pi. I restarted Ekos (the profile connects automatically) and...huh. Endlessly cycling to the first scheduled job again! I was using exactly the same sequence file and exactly the same scheduler setup as had just worked with the simulators. Color me gobsmacked for sure!

I tried trimmed the profile down to just the imaging camera and the telescope simulator. Same result.

Something weird with the ZWO driver? Hardly anyone uses that, right? I'm fairly baffled why it would work fine with the simulated camera but glitch with the real one.