Hi everyone
I have a job of 6 captures to repeat 12 times with track, align and guide checked.

The alignment is only performed once before the first capture.

Expected behavior: alignment is performed before each batch of 6 captures. Could anyone help me get align to run before each batch begins?


logs esl etc: drive.google.com/drive/folders/1GwoTvGbi...qr6Yw012?usp=sharing


TIA,
Steve

If you are still within the tolerance limit specified by the solver, the realignment procedure may not take place (Eric would have to comment on that).
I would think the workaround that is to slew to a target a few arc min away from the center of your image, then retrigger the alignment.
That's a crutch, of course, but that should work, I would think.
Cheers
Jo

So checking the code, it appears that it checks if it is guiding, then it will continue capturing. If guiding was stopped and align was enabled, then it will re-align again. If neither, it would slew back to target. Eric would have to weight in, I suppose for some instances and while guiding is running, users expect everything to continue as is.. why would you want to re-aligned again if guiding is working? Maybe for other users , they need a fresh start.

I guess the point is that if guiding fails then you might need to be re-aligned. E.g., if clouds come by, and the guide star is no longer seen, it can be a while until the guider fails, and then it may be a while until the scheduler retries, and the clouds might be there for a while for the guider to fail again. If the guider is out for several minutes, and if you have enough drift in your mount, then the image could move a hundred pixels. I think that is the issue they want addressed.

Hy

Hi everyone
This is very much a workaround as we don't have anything to re-align if guiding fails. At least this way you will only lose -in my case at the most- six captures due to mis-aligment.

Really would like to get this fixed. there are requests here:
indilib.org/forum/ekos/7498-guiding-resume-after-cloud.html
and here:
www.indilib.org/forum/wish-list/7513-des...-recovery.html#58264

Cheers and clear skies all,
steve

Let's say a cloud has passed by and the guide star was lost and another found: the target is now off centre.
It's a workaround.

The solution to realign every time seems to be to NOT to be use the scheduler repeat n times check box, rather copy the same job repeatedly into the scheduler. It then realigns at the start of each batch.

Cheers,
Steve

I understand the need to re-align on guiding failure but if guiding never failed, then is re-alignment necessary for job repeats?

At any rate, I found a more important issue. Currently the alignment module captures the current mount coordinates as the "target coord" and then uses this for all subsequent operation. So this could explain some issues in re-alignment, like post meridian flip, or after guiding. So now EVEN if alignment is called, it's going to start from where ever the mount currently is and then go there, so that's not entirely useful in this case, it would capture and solve at the "wrong" place. So one solution is to re-slew and then re-align... however, a better long term approach is to make the alignment module accept an external target and not always assume we're starting from the current mount position, so I'll work on that next.

So I'm trying to figure out the best way to do this. Current plan is as following:

1. Add a new function to set TargetCoord. This function should be called by two places (planned not yet implemented).
1.1. startAlignment in scheduler, to make sure the target is set correctly.
1.2. Before meridian flip is started, we set this so that post-flip meridian alignment ends up on the exact target when the capture was started.

So TargetCoord right now is set in captureAndSolve function, it is set from the currentTelescope coordinates. So if this is disabled, we would always rely on TargetCoord being set. But for a user that simply slews somewhere and hit capture and solve, they expect this to work as it is now, and whatever TargetCoord was set previously should be overwritten by the current telescope coords. So I see a couple of ways to resolve this:

1. When the user physically clicks the button, then we reset targetCoord to telescopeCoord. OR;
2. When we detect a SLEW event that was not triggered by the alignment module itself, then we reset targetCoord. This is harder to implement of course, but I think theoretically it works as well.

Please share your thoughts on this.

Hi, no it's not necessary. It's a workaround for the lack of, 're-align on guiding failure'.
Please see here:
www.indilib.org/forum/ekos/7516-schedule...batch-job.html#58275

Cheers,
Steve

Hi

I believe that we now have align as part of the 'repeat for this many runs'.in git.

Is this correct?
Cheers.

Hi again

No, it still only aligns the first time. Subsequent batches just go straight to capture.

log and esl: drive.google.com/drive/folders/1Iuf0PKZc...rw9JZWT8?usp=sharing

the only way i can get it to align is put multiple batches on separate lines in the scheduler.
Cheers.

So this behavior makes sense. If you're guiding, why would you want to stop to realign again? Maybe a different behavior to force align for each job regardless can be added.