[INSTRM-1696] Store offset values in gen2 MEMORY status dict Created: 14/Sep/22  Updated: 12/Oct/22  Resolved: 12/Oct/22

Status: Done
Project: Instrument control development
Component/s: PFS_kansoku
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: cloomis Assignee: Yoshida, Hiroshige
Resolution: Done Votes: 0
Labels: EngRun
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks INSTRM-1702 Relay gen2 MEMORY.PFS status to MHS/opdb Done
Relates
relates to INSTRM-1703 Add columns to tel_status for accumul... Done
Story Points: 1
Sprint: preEngRun07Sep

 Description   

When any gen2 script makes an offset, that should be recorded in some MEMORY slots. These will be relayed into the PFS system and recorded at the start of each AG/SPS exposure. Among other things, this means that the MEMORY values should be cleared when the actual offsets are cleared by slewing, etc.

The "dither offsets" are by far the most important.  Rotator and focus "guide offsets" are also desirable, but any other applied moves (az and alt) should be stored if possible.

All keys should go into the MEMORY.PFS table space. Under that, I think we can just use a flat namespace, with DITHER_RA and DITHER_DEC, etc. for the dithers, and AG_IR, AG_FOCUS, etc. for guide offsets.

If we ever expect to make user offsets for other reasons (i.e. not just dithering), I propose we use USEROFFSET_RA, etc. instead of DITHER_RA.



 Comments   
Comment by Yoshida, Hiroshige [ 14/Sep/22 ]

Following the proposed design, for dithering offsets, at least the AG actor wants

DITHER_RA (arcsec) : offset to the RA coordinate, not angular separation on the tangent plane
DITHER_DEC (arcsec)
DITHER_INST_PA or DITHER_PA (arcsec)

For field acquisition and auto-guiding, 

AG_RA (arcsec) : cumulative guide offset to the RA coordinate, not angular separation on the tangent plane
AG_DEC (arcsec)
AG_INSROT or AG_INSTROT or AG_INR (arcsec) : correction to INSROT made by offsetting INST_PA

The longest key among the proposed above is MEMORY.PFS.DITHER_INST_PA

Comment by eric [ 14/Sep/22 ]

So, can we fix the names?  How about DITHER_PA and AG_INR instead of the alternate spellings?

Comment by Yoshida, Hiroshige [ 14/Sep/22 ]

I am OK with your suggestion.

Comment by cloomis [ 15/Sep/22 ]

Agreed:

DITHER_{RA,DEC,PA}

and

AG_{RA,DEC,INR}
Comment by Yoshida, Hiroshige [ 15/Sep/22 ]

To clarify:

DITHER_RA : user offset in RA "on the sky" (arcsec)

AG_RA : cumulative value of applied RA offsets (errors) sent from the AG actor, which is a change in the RA coordinate value, without projection on to a tangent plane (arcsec)

Comment by cloomis [ 15/Sep/22 ]

Please use the table in INSTRM-1702 to find the official keyword names.

Comment by eric [ 15/Sep/22 ]

Yoshida, Hiroshige, so I am summing -1 * offset for every ra, dec, rot offset....correct?  This is easy to change if later you decide otherwise.

Comment by Yoshida, Hiroshige [ 15/Sep/22 ]

Please give us the sum of values that are sent from the PFS side and actually applied to the telescope command position, without any scaling or sign flipping. Cumulative guide offsets are not something regular observers or support scientists have to deal with.

Comment by eric [ 15/Sep/22 ]

To clarify: we are applying the negation of the values you are sending for guide offsets. This seemed to be working in the last engineering. BUT, you want me to sum the non-negated values, is that right?  Just want to make sure...

 

Comment by Yoshida, Hiroshige [ 16/Sep/22 ]

Sorry, negated values (errors -> offsets) are what I initially proposed. So please sum up negated values that were actually applied to the telescope command position.

Comment by yuki.moritani [ 07/Oct/22 ]

Yoshida, Hiroshige is it OK to close this, as MEMORY statuses were stored correctly during the last run?

Comment by yuki.moritani [ 12/Oct/22 ]

It can be closed as the gen2 MEMORY statuses were passed to agActor as MHS statuses in the last run. (If a bug/missing item is fount, it will be addressed under a new ticket.)

Generated at Sat Feb 10 16:38:27 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.