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-1182 Instrument control development <p>When PFS is not the active instrument, the gcamActor is connected to g2sim2, which feeds it a single, static, snapshot of the telescope positions, configuration, environment.</p> <p>When observing with SuNSS, we need real telescope pointing, etc. We currently get that through an alternate feed from g2stat, but that is currently only used to drive the sunssActor observing logic.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=eric" class="user-hover" rel="eric">eric</a> &#8211; can g2sim2 provide live status? If not, is it sane to run a g2stat "stream_status" feed from within the same process as always runs the main Instrument? Or should I keep the two separate?</p> INSTRM-1182

Use live telescope status when using SuNSS

Task Normal Done Done cloomis cloomis SuNSS Mon, 15 Feb 2021 15:27:35 +0000 Wed, 17 Feb 2021 02:54:18 +0000 Wed, 17 Feb 2021 02:54:18 +0000 ics_gen2Actor 0 4 <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=eric" class="user-hover" rel="eric">eric</a> this isn't just academic.  We offset the telescope to sort out the geometry on the sky and the headers are wrong.  Obviously in the short run we can extract the data from some DB somewhere.</p> <p> </p> <p>We do have something called the "status relay" that we can start on a simulator to basically replicate the summit status there.</p> <p>However, there is a catch associated with using it–namely that the simulator effectively has it's own status completely overridden by whatever values come down the stream.  This can effect operations that depend on status items being set/checked on the simulator.  I don't think currently you are doing anything but snoop the status values, but at some future point if you are archiving frames (e.g. calibration, etc?) via the simulator, it could be problematic if the local status is overridden.</p> <p>However, in the short term it sounds like this might be the best bet for taking sunns data, if you need to do that via the g2cam.  In that case it is not necessary to run the separate stream.</p> <p>So if we turn on the relay, <em>all</em> status becomes that from the summit? Where would conflicts and confusion usually come from? PROPOSAL/OBSERVER, certainly. I see what you mean for bias/dark/etc frames taken when we are totally offline.</p> <p>My hunch is that starting with the relay and overriding some keys would be good for us, certainly when acquiring with SuNSS. What is involved in enabling the relay?</p> <p>&gt; PROPOSAL/OBSERVER, certainly.</p> <p>Actually, these are FITS.PFS.OBSERVER and FITS.PFS.PROP_ID, so they are unlikely to be overridden.</p> <p>&gt; Where would conflicts and confusion usually come from?</p> <p>I cannot forsee too much, until we know more about what PFS will be doing when not observing.  I suspect such things will become apparent as we go along.</p> <p>&gt; What is involved in enabling the relay?<br/>  <br/> I merely need to add it to the "g2ssim2" configuration and make sure it is started up.  I'll check that it is working and let you know when I've confirmed it.</p> <p>Ok, the status relay is enabled for g2ssim2.  The status is now synced to the summit status.</p> <p>Thanks!</p> <p>I'll leave this open until after the SuNSS night tomorrow. And I'd to continue using the status stream for a while to plan and drive the sunss observing strategy, until I can refactor the main gcamActor.</p> <p>Fixed by configuring g2sim2 server to feed pfs live data. <br/> No changes made on PFS side.</p> Relates INSTRM-1183 Development Rank 0|zzs45c: