[INSTRM-1026] Add counter for physical SM configuration changes Created: 25/Jun/20 Updated: 30/Sep/20 Resolved: 30/Sep/20 |
|
| Status: | Done |
| Project: | Instrument control development |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | cloomis | Assignee: | arnaud.lefur |
| Resolution: | Done | Votes: | 0 |
| Labels: | SPS | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||
| Sprint: | SM1PD-2020 G2, SM1PD-2020 H | ||||||||||||||||||||||||
| Description |
|
It would be useful to note mechanical changes which could affect data reduction. The obvious parts are the FPA motors, the slit hexapod, and the red exchange mechanism. The proposed mechanism is to have per-SM counters which are incremented when moves are made. Some listener, in the icc or alerts actors, will listen to keywords and will increment an opdb table. The value in that table will be added to the headers so that DRP can know whether exposures were taken with possibly different configurations. FPA moves and the red exchange mechanism affect only a single camera, so perhaps there should be 12 counters. We do not expect to move FPAs very often, but the rexm will be. |
| Comments |
| Comment by cloomis [ 18/Aug/20 ] |
|
After a chat we decided to be dumb and robust: Do not bother to maintain counters, and just use MJD or Unix seconds minus some fixed offset. That allows the enu and xcu actors to not require any external context (visit or counter). Keep a separate counter for each fpa, grating, and hexapod. xcu_b2.fpaMoved=$ticks, say. Just use MHS keyword, and let the archiver take care of history,. The CCD/HX actors can put the dewar-appropriate keys into the header, and synthesize a single monotonically increasing counter (fpaMoved + hexapodMoved + gratingMoved would do fine). That actor could generate rows for any opDb tables. |
| Comment by cloomis [ 01/Sep/20 ] |
|
I will implement the XCU and CCD parts of a slight variant on the above, unless waved off. Specifically:
For the opDb, I think we should add a new column to the sps_exposure table ("configGeneration"?), and the sps actor should populate that when it populates the rest of the per-frame row. That is what reductions would use. sps_exposure currently has visit, cam, exptype, exp_start_time, so that seems like a good place to put it. Oh, why MJD seconds (e.g. 59085.84979714)? MHS keyword do not have a timestamp type, nor do they have an int8 type which we would require for unix seconds. Headers would get all the individual components plus the calculated generation date. |
| Comment by arnaud.lefur [ 03/Sep/20 ] |
|
Agreed. |
| Comment by arnaud.lefur [ 30/Sep/20 ] |
|
implemented and currently running at Subaru. |