[INSTRM-1182] Use live telescope status when using SuNSS Created: 16/Feb/21 Updated: 17/Feb/21 Resolved: 17/Feb/21 |
|
| Status: | Done |
| Project: | Instrument control development |
| Component/s: | ics_gen2Actor |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | cloomis | Assignee: | cloomis |
| Resolution: | Done | Votes: | 0 |
| Labels: | SuNSS | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
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. 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. eric – 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? |
| Comments |
| Comment by rhl [ 16/Feb/21 ] |
|
eric 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.
|
| Comment by eric [ 16/Feb/21 ] |
|
We do have something called the "status relay" that we can start on a simulator to basically replicate the summit status there. 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. 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. |
| Comment by cloomis [ 16/Feb/21 ] |
|
So if we turn on the relay, all 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. 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? |
| Comment by eric [ 16/Feb/21 ] |
|
> PROPOSAL/OBSERVER, certainly. Actually, these are FITS.PFS.OBSERVER and FITS.PFS.PROP_ID, so they are unlikely to be overridden. > Where would conflicts and confusion usually come from? 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. > What is involved in enabling the relay? |
| Comment by eric [ 16/Feb/21 ] |
|
Ok, the status relay is enabled for g2ssim2. The status is now synced to the summit status. |
| Comment by cloomis [ 16/Feb/21 ] |
|
Thanks! 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. |
| Comment by cloomis [ 17/Feb/21 ] |
|
Fixed by configuring g2sim2 server to feed pfs live data. |