Rewrite Gen2 daemon to use full WPU info

[mileslucas]

https://github.com/scexao-org/scxkw/blob/1e8c3ab4838e071000470dfa28f18137360e71d5/scxkw/daemons/gen2_pull.py#L123-L128

Okay, so currently the gen2 daemon here does not populate the RET-POSX or RET-MODX keywords. These are, indeed, manually set as camera keywords in the hwpdaemon, but I want to have my camera classes fall back on the 10s polled values.

I propose adding the code required to update ALL our special WPU parameters here. This would include either porting the WPU interface I added to swmain or else depending on swmain

@DasVinch thoughts? I can write the code no issues just want some guidance

[DasVinch]

Idea is sane... howevah, you'll still have the latest RET-POSx and RET-ANGx and RET-MODx in you SHM, however old... and even if they're stale they'll still supersede the one from the auxFITSheader?

[DasVinch]

And if you make the g2pull daemon force-push to SHM, they're gonna race condition at all times with the HWP daemon.

UNLESS you actually make g2pull fetch from garde and not from gen2, in which case you're gonna double the pushes to the SHM, and should not race condition?

[mileslucas]

And if you make the g2pull daemon force-push to SHM

and even if they're stale they'll still supersede the one from the auxFITSheader?

No, not at all what I'm going for. I mean for data that is typically non-polarimetric these values are clobbered by the default SHM keywords, which are always -1. I can add code to camstack to get the RET-ANG1 values from redis IF they are not set, but only that keyword, not the POS or MOD keywords.

[mileslucas]

big hole in this:

directly asking garde for anything will not work unless the WPU processes are running. So that means we'll be getting bad data bad data bad data unless we restart the process from garde. Even worse, we'll just be getting errors and need to handle appropriately.

This problem affects the current implementation, too, since you're asking garde directly for the values.

[mileslucas]

or another way would be that camstack is always pulling the redis value as the default, but then things like the hwpdaemon will overwrite the SHM value and supersede it

[DasVinch]

No, not at all what I'm going for. I mean for data that is typically non-polarimetric these values are clobbered by the default SHM keywords, which are always -1. I can add code to camstack to get the RET-ANG1 values from redis IF they are not set, but only that keyword, not the POS or MOD keywords.

What is the mechanism that makes them go back to -1? I can only think of the camstack ctrl restarting and overwriting the SHM (*). If garde is currently sending -1's, that means P_RTAGL will be -1 too anyway. If the SHM went back to -1 because garde said -1, then redis is gonna say -1 too?

Workaround for (*) behavior: poll P_RTAGL on camstack startup / set_camera_mode and force feed it to the shm.

[mileslucas]

What is the mechanism that makes them go back to -1?

That is the default value in the BaseVCAM.KEYWORDS

I can only think of the camstack ctrl restarting and overwriting the SHM (*).

I mean, the camstack ctrl crash frequently and doesn't it have to create a new SHM when the crop size changes?

---

Correct me if I'm wrong, but there should be a way that I am able to use the redis values as defaults for the SHM keywords (in _fill_keywords or something like that, right?) that will still be overridden with the SHM keyword set by the HWP daemon. This is what I am asking.

[DasVinch]

Yup, our explanations converges. There's just a little bit of fidgeting in the camera class with HAS_REDIS and error catching, but otherwise _fill_keywords seems like the right place. It is called at every SHM reallocation too.