skip fine acquisition for repeat targets

[astronomerdave]

This is a simplification of PR #457

@cfremling please verify this meets your intent but according to our slack conversation I believe it does.

[cfremling]

@astronomerdave no this doesn't stop acam acquire and offset and introduces a bug where fine acquire would never be ran on any target.

repeat_target() is true for every target at line 755: move_to_target writes last_ra_hms at 2255 and is awaited at 733, so dofine is always false and fine acquire never runs. Fix: latch is_repeat_target = repeat_target() once before the workers spawn, and read that bool everywhere.

for BOTH fine acquire ON and OFF you must skip acam acquire.
do_acam_acquire() (759) is ungated. On an offset-star row it re-centres the star and moves the telescope from science position

in fine acquire ON mode both do_acam_acquire() and the target_offset() still fires applying a double offset, since its gate is_fineacquire_locked will be "true". Skip both do_acam_acqure and target_offset(), keep slit_set(VSM_EXPOSE). Also make sure to NOT do wait_for_user() in fine acquire ON mode.

[astronomerdave]

@cfremling Sorry, I need to picture this better and design, then code, rather than just code. Here is a flowchart of how the system works as designed:

In order for this repeat to even come into play, the user must have disabled the do all. That means after any one of the green Expose boxes completes, the system is idle doing nothing and the arrow looping back Next target in list does not happen.

I already created a repeat function which I thought you had tied to a button. Sending the repeat command jumps directly to the green box, it just does the exposure. That works, so you are looking for something else.

In your PR #457 you say that they user clicks GO. I don't know what that does since there is no "go" in the system -- does that start with Load target? I'm assuming it does, so then it goes to the Configure subsystems box (you want that, right?) but since it's the same target it should skip the Wait for TCS Operator, ACAM Acquire, and Fine Acquire stages and jump from Configure to Expose. Is that right?

[cfremling]

@astronomerdave currently the gate on RA, DEC doesn't care about do one or do all modes it is active in both. (this behavior is fine, and does not need to be changed in either mode).

the user clicks 'go' in the python GUI, which I believe issues startone. your interpretation is otherwise correct skip to adjust slit width + expose. do not do any acquisition steps on acam or scam fine acquire, no offset after fine acquire lock

Anyway, because the repeat function does not allow changing the slit width, the observers must use 'go' on the same target to observe the same target with different configurations, which typically change slit width, binning, exptime. this is done practically every night on standard star calibrations. the repeat function could be used if it was able to change slit width and binning and exptime and then all the gating logic on same coordinates we are trying to introduce in the acquisition logic here would then be unnecessary.

[astronomerdave]

You say:

this is done practically every night on standard star calibrations

If that is the case then just make a standard star calibration target list! You're asking for a software redesign instead of showing observers how to use the software to do what they want.

And for the record, a cleaner design would be to insert a new line in the table and click go. You used to be able to click copy/insert, and you used to have the ability to edit columns right in the table. It was so intuitive and easy and solved all the problems, no new buttons and no new code logic needed. We are doing a LOT of work-arounds in the back end to make up for functionality we lost in the new GUI.

[cfremling]

Currently, as the system is designed using several rows in a target list would not work, and it does not achieve what is needed (same coordinates, multiple settings, no re-acquisition). I am fine with creating multiple rows, or updating the db and re-sending an updated row. Any of that does not negate the need for the logic of skipping acquisitions steps. New entries in the target list would go through all the acquisition steps, which can't be happening when repeating a target.

[astronomerdave]

this should do what you want

[cfremling]

@astronomerdave yes this is good. cleaner than #457 and has the essentials. The one final request I would have is to allow seq clearlasttarget as a seq command that the pygui could send if manual observer really wants to force re-acquisition. (so take it off the seq test and make it official command)

[astronomerdave]

The one final request I would have is to allow seq clearlasttarget as a seq command that the pygui could send if manual observer really wants to force re-acquisition. (so take it off the seq test and make it official command)

That's bigger than it appears. An observer would have to know what "clear last target" means, which is unique in the context of how the code works, an unnecessary detail. Clear it from what? or where? The database?

Alternatives I considered:

• newtarget. but that reads like it takes an argument. An observer could reasonably think it loads or goes to a new target.
• clearrepeat. the observer never issued repeat, that was inferred from the coordinates being the same so a "clear" implies undoing something that they did, or understanding the software.
• forceacquire. except it doesn't reacquire now. It only "arms" the next target load. Plus it forces a slew, not just an acquire.

The other problem is that this is silent. An observer has no way to ask "will the next target skip acquisition?"

I'm sure there's a way to do what you want (everything can be done in software) but this is kinda late to get into this. I don't think that just putting something together without a though-out design at 4:58 PM on the last day that funding runs out is a good idea.

[cfremling]

Approved.

[cfremling]

@astronomerdave I see your point with that. lets keep it as seq test as is