https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-1026 Instrument control development <p>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.</p> <p>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.</p> <p>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. </p> INSTRM-1026

Add counter for physical SM configuration changes

Task Normal Done Done arnaud.lefur cloomis SPS Wed, 24 Jun 2020 16:31:09 +0000 Wed, 30 Sep 2020 12:50:10 +0000 Wed, 30 Sep 2020 12:46:02 +0000 0 2 <p>After a chat we decided to be dumb and robust:</p> <p>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 <b>not</b> require any external context (visit or counter).</p> <p>Keep a separate counter for each fpa, grating, and hexapod. <tt>xcu_b2.fpaMoved=$ticks</tt>, say. Just use MHS keyword, and let the archiver take care of history,.</p> <p>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). <b>That</b> actor could generate rows for any opDb tables. </p> <p>I will implement the XCU and CCD parts of a slight variant on the above, unless waved off. Specifically:</p> <ul class="alternate" type="square"> <li>xcu_$cam (and enu_$sm) generate MHS keywords fpaMoved=MJD_seconds, etc.</li> <li>ccd_$cam and hx_$cam generate MHS keywords configGeneration=$visit,MAX(xcu_$cam.fpaMoved, enu_$sm.hexapodMoved, enu_$sm.gratingMoved).</li> </ul> <p>For the opDb, I think we should add a new column to the <tt>sps_exposure</tt> 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. <tt>sps_exposure</tt> currently has visit, cam, exptype, exp_start_time, so that seems like a good place to put it.</p> <p>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.</p> <p>Headers would get all the individual components plus the calculated generation date.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=arnaud.lefur" class="user-hover" rel="arnaud.lefur">arnaud.lefur</a><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a>?</p> <p>Agreed.<br/> beamConfigDate is the keyword/column name</p> <p>implemented and currently running at Subaru.</p> Relates INSTRM-1054 INSTRM-1035 INSTRM-1036 INSTRM-1064 INSTRM-1068 Development Rank 0|zzs1mg:020x Sprint SM1PD-2020 G2 SM1PD-2020 H Story Points 3.0