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-980 Instrument control development <p>spsActor needs to handle synchronisation between hx and ccd actors.</p> <p>I suspect it will require some debugging to do this correctly, and we obviously don't want to do that with real hardware.</p> <p>The simulator does not need to create realistic frame, an empty frame would do it.</p> <p>What really matters is command flow/timing etc ..</p> INSTRM-980

provide a hxActor simulator that can fake exposure

Task Normal Done Done cloomis arnaud.lefur NIR SPS Wed, 13 May 2020 16:31:19 +0000 Tue, 19 Jul 2022 19:55:58 +0000 Wed, 30 Mar 2022 14:09:09 +0000 ics_hxActor 0 3 <p>The single command which matters is <tt>ramp nread=N visit=V</tt>. Before that is sent you will have the <tt>readTime</tt> keyword value, which is how long a single read takes. That will be between 5.57 and 11.14 seconds, depending on how we end up configuring reference pixel interleaving ("IRP").</p> <p>For the purpose of SPS/ICC sequencing it is worth keeping in mind that during a ramp the detector continuously reads out from top to bottom, then immediately continues at the top. That said, we always start a ramp with a reset frame, which takes the same readTime as a real read: the start of your requested ramp will be delayed by one readTime. [ We might want to add more resets under some circumstances, but don't worry about that yet. ]</p> <p>Part of the puzzle will be whether we can reliably synchronize the read edges with any interesting SPS changes: shutter transitions, lamp transitions, ccd transitions. At worst we will lose a read at the start and a read at the end, because they overlap with shutter or lamp changes. <span class="error">&#91;I have some more detailed notes on this which I will try to recover and merge with these comments. &#93;</span></p> <p>I am nearly certain that we will want to continue taking reads while the ccd are reading out, for two reasons. One is that we will not need to get the relative timings exactly right. And we will be able to get our first measurement of persistence from the exposure.</p> <p>I still need to understand how to figure out when the first read <em>will</em> start. That may not matter: if we started the ramp along with the ccd wipe (I think we will want to) we can synchronize the shutter/lamp start events <em>after</em> the ramp has started. At which point I <em>think</em> we will know when the first read started. <span class="error">&#91;But remember the reset frame time. &#93;</span></p> <p>Given those various points I suggest that the starting design should be to send the ramp command along with the ccd wipe command (or earlier if possible), and that nread be set to the expected time between the end of the reset frame and the end of the ccd readout. <span class="error">&#91;We need to generate a ccdReadTime keyword, hmm.&#93;</span></p> <p>The main keywords are:</p> <ul class="alternate" type="square"> <li>readTime=seconds. The time a single read will take; this should be good to microseconds. This keyword will come when the DAQ is initialized or reconfigured: before you would send any <tt>ramp</tt> command. A ramp is a completely synchronous sequence of these per-read times.</li> </ul> <ul class="alternate" type="square"> <li>read0Start=timestamp. This is the timestamp for when the first read started. I do not yet know how good I can get this, but am guessing to better than 0.1s. Given read0Start and readTime, you can reliably calculate all later transition times. I hope to generate a decent guess for this shortly after the ramp command has been started, but have not yet tried.</li> </ul> <ul class="alternate" type="square"> <li>spsFileIds=camName,dateDir,visit,smNum,armNum &#8211; same as for ccdActor. When this arrives the visit has been entirely finished and all files flushed and closed. (the camName field is there just for humans, etc.)</li> </ul> <ul class="alternate" type="square"> <li>hxRead=visit,readN,ofN &#8211; a running report of completed reads. This is generated after any file writes for that read have been flushed.</li> </ul> <p>We will need handle the shutter close, etc. times differently from the CCDs for the purpose of EXPTIME, etc.. There is no clean wipe/read split like for the ccd. I think a shutterClosed keyword similar to the new lampX keywords will have to do.</p> <p>This ticket, and subsequent related tickets, will be scheduled for implementation one month prior to the shipping date of N1 to LAM.</p> <p>Merged at a5afcc, tagged 2.3.0</p> <p>Only simulates the ramp command and its keywords.</p> <p>If the actor config has simulator=True the ramp command is replaced by a simulator, which does not touch or need and hardware, nor does it create files.</p> Blocks INSTRM-1137 Relates INSTRM-1563 INSTRM-1336 Development Rank 0|02qpuc:i6001gr068fhw9qo4o0m38y Sprint SM1PD-2020 K SM1PD-2020 L SM1PD-2021 A 2 SM1PD-2021 A 3 SM1PD-2021 A 4 SM1PD-2021 A 5 SM1PD-2021 A 6 SM1PD-2021 A7 SM1PD-2021 A8 SM1PD-2021 A9 SM1PD-2021 A10 SM1PD-2021 A 11 SM1PD-2021 A 12 SM1PD-2021 A 13 SM1PD-2021 A 14 SM1PD-2021 A 15 SM1PD-2022 B SM1PD-2022 C Story Points 6.0