From: Kaike Subject: Re: auto-pilot switching -- [sloan-25mlog 7273] Re: 2.5m obslog Date: Sat, 1 Jun 2024 11:54:10 -0600 --Apple-Mail=_B5D1C9F7-0DE1-4D6E-A46D-648834E6A447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Baes on the HAL, the acquire is highlighted when I switch to auto-pilot. = Thanks, -Kaike > On Jun 1, 2024, at 11:49=E2=80=AFAM, Jos=C3=A9 S=C3=A1nchez-Gallego = wrote: >=20 > Actually, looking at the code, there is a subtlety. If the goto-field = fails (or anyway runs the cleanup stage and all the stages before = acquire have been run), then the design is marked as goto-complete and = auto-pilot won't try to rerun the goto-field. But if you're still = running the goto-field, even if you're at acquire, then it will not yet = know the goto-field can be considered complete. >=20 > I think it should behave the way I initially described (if the = goto-field is still running and you start the auto-pilot it should wait = for the goto-field to finish and then evaluate if it was successful). = It's an easy change, I can probably release a new version today. >=20 > Thanks, >=20 > Jos=C3=A9 >=20 >=20 > On Jun 1, 2024 at 10:44:09, Daniel Oravetz > wrote: >> Thanks, Jos=C3=A9. >>=20 >> So when Kaike stated that "gotoField was at acquire stage when I = switched >> to the auto-pilot mode", I took that to mean the acquire stage had = already >> started, which means the auto-pilot should NOT have re-run = goto-field. So >> if 'acquire' had already started and goto-field was re-run, then it's = a >> bug, but if "at acquire stage" meant "acquire was the next thing to = run >> but hasn't started yet", then there isn't a bug and the sequence is = doing >> what it's supposed to do. >>=20 >>> On Jun 1, 2024 at 10:30:59, Daniel Oravetz > wrote: >>>=20 >>> > 2. Don't switch to the auto-pilot mode during gotoField. After a = robot >>> > >>> > > collision (on 995), I run gotoField manually. The gotoField was = at >>> > >>> > > acquire >>> > >>> > > stage when I switched to the auto-pilot mode. I intended to have = it to >>> > >>> > > start exposure automatically with switch to auto-pilot, but it >>> > >>> > > immediately >>> > >>> > > start the gotoField sequence. I consider this is a feature, = don't need >>> > >>> > > Jose >>> > >>> > > to work on this. >>> > >>> > > >>> > >>> > >>> > That is also expected. A design is considered to have completed = its >>> > >>> > goto-field when it reaches the acquire stage. Until then, it will = be >>> > >>> > marked >>> > >>> > as not goto-field'd and the goto-field will be run. But maybe an >>> > exception >>> > >>> > to that should be if the goto-field is already running ... >>> > >>> > >>> > To clarify, if the auto-pilot mode had been switched on AFTER the >>> > 'Acquire' stage were completed and not only in-progress, then the >>> > auto-pilot would have started the 'Expose' macro? I.e., if the = 'Acquire' >>> > stage fails (which sometimes happens if the target guide_rms isn't >>> > reached >>> > in the default number of iterations), then an entire goto-field = sequence >>> > would be re-run if auto-pilot were re-tried? >>> > >>>=20 >>> If the goto-field for a design reaches the acquire stage (even if = the >>> acquisition is not complete) and then you switch the auto-pilot = while on >>> that design, it should not try to do a goto-field again (or at least >>> that's >>> what I coded it to do, the reality as usual could be different). In = that >>> case it would not load anything (the current design has not yet been >>> observed/exposed), would skip the goto field and move to exposing. >>> Exposing >>> would not start unless the guider is running, and it will wait until = the >>> RMS is >>=20 >>> More specifically answering your question, if the acquire stage = fails >>> while >>> on auto-pilot, the auto-pilot will fail. But if you then manually = start >>> guiding and re-enable the auto-pilot, then it should go directly to >>> expose, >>> wait until the RMS is good, and then start exposing. >>>=20 >>> I don't think it's unreasonable to manually re-run a goto-field as = Kaike >>> > did last night after triaging a robot collision, and then turning = the >>> > auto-pilot on after the goto-field completes, we just need to be = clear >>> > that's how we choose to handle these situations. Otherwise, it = seems as >>> > though we'd need auto-pilot to know which stages of goto-field = completed >>> > or failed so it has some kind of record of which stages need to be >>> > re-run >>> > and which don't, which might be more trouble than its worth = compared to >>> > the manual option (which I'm fine with, personally). >>> > >>> > >>> I agree that seems reasonable. Tracking individually completed = stages in >>> goto-field would be non-trivial and I think prone to errors. I think = if a >>> macro fails during auto-pilot, it's best to manually make sure that = macro >>> has been run correctly, then re-enable auto-pilot. >>>=20 >>=20 >>=20 --Apple-Mail=_B5D1C9F7-0DE1-4D6E-A46D-648834E6A447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Baes on the = HAL, the acquire is highlighted when I switch to auto-pilot. Thanks, = -KaikeOn Jun 1, 2024, at 11:49=E2=80=AFAM, Jos=C3=A9 = S=C3=A1nchez-Gallego wrote:Actually, = looking at the code, there is a subtlety. If the goto-field fails (or = anyway runs the cleanup stage and all the stages before acquire have = been run), then the design is marked as goto-complete and auto-pilot = won't try to rerun the goto-field. But if you're still running the = goto-field, even if you're at acquire, then it will not yet know the = goto-field can be considered complete.I think it should behave the way = I initially described (if the goto-field is still running and you start = the auto-pilot it should wait for the goto-field to finish and then = evaluate if it was successful). It's an easy change, I can probably = release a new version today.Thanks,Jos=C3=A9= On Jun 1, 2024 at 10:44:09, = Daniel Oravetz = wrote: =20 Thanks, Jos=C3=A9.So when Kaike stated that "gotoField was = at acquire stage when I switchedto the auto-pilot mode", I took that = to mean the acquire stage had alreadystarted, which means the = auto-pilot should NOT have re-run goto-field. Soif 'acquire' had = already started and goto-field was re-run, then it's abug, but if = "at acquire stage" meant "acquire was the next thing to runbut = hasn't started yet", then there isn't a bug and the sequence is = doingwhat it's supposed to do. On = Jun 1, 2024 at 10:30:59, Daniel Oravetz = wrote:> 2. Don't = switch to the auto-pilot mode during gotoField. After a = robot>> > = collision (on 995), I run gotoField manually. The gotoField was = at>> > = acquire>> > = stage when I switched to the auto-pilot mode. I intended to have it = to>> > = start exposure automatically with switch to auto-pilot, but = it>> > = immediately>> > = start the gotoField sequence. I consider this is a feature, don't = need>> > = Jose>> > = to work on this.>> = >>>> That = is also expected. A design is considered to have completed = its>> = goto-field when it reaches the acquire stage. Until then, it will = be>> = marked>> as not = goto-field'd and the goto-field will be run. But maybe = an> = exception>> to = that should be if the goto-field is already running = ...>>> To = clarify, if the auto-pilot mode had been switched on AFTER = the> 'Acquire' stage were = completed and not only in-progress, then the> auto-pilot would have started the 'Expose' macro? = I.e., if the 'Acquire'> = stage fails (which sometimes happens if the target guide_rms = isn't> = reached> in the default = number of iterations), then an entire goto-field = sequence> would be re-run = if auto-pilot were re-tried?> If the = goto-field for a design reaches the acquire stage (even if = the acquisition is not = complete) and then you switch the auto-pilot while = on that design, it should not = try to do a goto-field again (or at least that's what I = coded it to do, the reality as usual could be different). In = that case it would not load = anything (the current design has not yet = been observed/exposed), would = skip the goto field and move to exposing. Exposing would = not start unless the guider is running, and it will wait until = the RMS is < threshold (I = think 1 arcsec for APO). More = specifically answering your question, if the acquire stage = fails = while on auto-pilot, the = auto-pilot will fail. But if you then manually = start guiding and re-enable = the auto-pilot, then it should go directly = to = expose, wait until the RMS is = good, and then start exposing. I don't think = it's unreasonable to manually re-run a goto-field as = Kaike> did last night = after triaging a robot collision, and then turning = the> auto-pilot on after = the goto-field completes, we just need to be = clear> that's how we = choose to handle these situations. Otherwise, it seems = as> though we'd need = auto-pilot to know which stages of goto-field = completed> or failed so it = has some kind of record of which stages need to = be> = re-run> and which don't, = which might be more trouble than its worth compared = to> the manual option = (which I'm fine with, personally).>> I agree = that seems reasonable. Tracking individually completed stages = in goto-field would be = non-trivial and I think prone to errors. I think if = a macro fails during = auto-pilot, it's best to manually make sure that = macro has been run correctly, = then re-enable auto-pilot. = --Apple-Mail=_B5D1C9F7-0DE1-4D6E-A46D-648834E6A447--