Re: add fields to an existing record

[Matt Newville via Tech-talk <tech-talk at aps.anl.gov>]

Hi Mark, 

I might be missing something (or misremembering Ophyd Signals and Devices),  but wouldn't an MCA ROI in a PV like "20bmxmap4b:mca1.R0" always be treated as a "single read-only PV" Signal in Ophyd?  It isn't a combined "IOCName:device:Field.VAL" and "IOCName:device:Field_RBV" that downstream code (Ophyd) might want to encapsulate into a single object with set/get methods, an MCA ROI is really read-only.  It does have a bunch of other related PVs (name, limits, background). But those are already in MCA ROI, and wouldn't you either always want those? 

That is, when would you be setting "hinting" on or off? 

On Tue, Jun 20, 2023 at 12:33 PM Mark Wolfman via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hi, Mark.

Thanks for the reply.

Yeah, I was trying to avoid modifying the upstream MCA module, or
vendoring the MCA module into the IOC. I was hoping I could do the
EPICS equivalent of sub-classing the MCA module, but it sounds like
that is not possible.

As suggested, I made a separate ``20bmxmap4b:mca1_R0BH`` bi record. I
then created an ``ophyd.Component`` subclass that modifies the PV with
regular expressions [1], which I'm not thrilled about but I believe
I'm in a lesser-of-two-evils situation here.

Cheers,
Mark

[1] https://github.com/spc-group/haven/blob/45fef324bb3d293cf30008c713c82b8a3a19664f/haven/instrument/fluorescence_detector.py#L53

On Sun, Jun 18, 2023 at 03:07:27PM +0000, Mark Rivers wrote:
> Hi Mark,
>
> Since this new field is intended for use by a single CA client (Ophyd for Bluesky) I think it is a better idea to use additional records and modify Ophyd to handle them.  Then all changes can be external to the MCA module, and Bluesky does not need to depend on a new release of the MCA module.
>
> Note that your gitlab link is not accessible to those of us who are not APS employees.
>
> Mark
>
> ________________________________
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wolfman, Mark via Tech-talk <tech-talk at aps.anl.gov>
> Sent: Monday, June 12, 2023 11:25 AM
> To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> Cc: Delgado, Uriel <udelgado at anl.gov>
> Subject: add fields to an existing record
>
> Hi, tech-talkers.
>
> Apologies in advance if parts of this don't make sense, I'm not that familiar with EPICS yet.
>
> I'm hoping to add a new region-of-interest field [1] to the MCA records used in an existing IOC for our DXP fluorescence detector.
>
> Similar to the other ROI fields, I'd like to have ``20bmxmap4b:mca1.R0BH``.
>
> This will be a 'bi' field that doesn't do anything in the IOC, but is used by bluesky/ophyd during staging to determine whether the specific ROI is hinted in bluesky (hence BH for "bluesky hint") [2] and is included in the calculations for summing ROI's across elements. I've added extra records to an IOC before, and so I tried adding this as a record but EPICS complained because my record name included a '.' character.
>
> One solution is to add a record like "20bmxmap4b:mca1_R0BH", but this makes the Ophyd part more complicated since the Ophyd MCA support expects the ROI to have a ``.Rn`` prefix and then tries to append the ``BH`` on the end[3]. Adding a record like ``mca1_R0BH`` means I have to re-write the MCA support in ophyd so I'd prefer to use the ``mca1.RnBH`` PVs if I can.
>
> The full IOC is available on gitlab, though it's presently a work in progress.
>
> Looking forward to hearing any ideas on how to make this work.
>
> Thanks,
> Mark
>
> [1] https://epics-modules.github.io/mca/mcaRecord.html#Region-Of-Interest_Fields
> [2] https://blueskyproject.io/ophyd/user_v1/reference/signals.html#kind
> [3] https://github.com/bluesky/ophyd/blob/0802c77ec973b0ba9f8554d3bcf3a3001def7f66/ophyd/mca.py#L14
> [4] https://git.aps.anl.gov/20BM/20bmdxp/-/tree/main/

--
My work schedule may not be the same as your work schedule. Please
don't feel obligated to respond to this e-mail outside of your normal
work hours.

This message may be signed or encrypted with Pretty Good Privacy (PGP)
key BE1E3158.

https://keys.openpgp.org/vks/v1/by-fingerprint/BB98174E34193EDCEA0F423C457826FCBE1E3158

--

--Matt Newville <newville at cars.uchicago.edu> 630-327-7411