Re: add fields to an existing record

["Wolfman, Mark via Tech-talk" <tech-talk at aps.anl.gov>]

Hi, Matt.

> wouldn't an MCA ROI in a PV like "20bmxmap4b:mca1.R0" always be treated as a "single read-only PV" Signal in Ophyd?

I don't think so. Ophyd has built in support for ROI records[1], and it treats each ROI as a device whose prefix goes through the ``mca1.R0`` part of the PV. The ROI device then has components for *hi_chan* and *lo_chan*, etc. with suffixes ``HI`` and ``LO`` etc., and a component for *counts* with an empty suffix so that it stays as ``mca1.R0``. The original goal was then to also add a component *is_hinted* with the suffix ``BH`` to make it ``.R0BH``.

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

My plan is to use the hinting to indicate that a given ROI is scientifically interesting. Since we're using a database and storage is cheap, I plan to save the counts and net counts (e.g. ``mca1.R0`` and ``mca1.R0N``) to the primary data stream for all ROIs and MCAs on the detector. This is too much data to present to users during analysis, but this challenge can be overcome using bluesky's hinting mechanism.

The idea is that the "is_hinted" PV can be set interactively by a caqtdm/pydm widget while setting up the experiment. Then when the bluesky plan is started (possibly on a different computer), each ROI runs its ``stage()`` method which checks the value of the "is_hinted" field and makes itself either ``kind=Kind.hinted`` or ``kind=Kind.normal`` before the plan starts. During unstaging, the ROI returns itself to whatever it was previously.

An added benefit is that I can use it to set up the calc records for saving the summed counts for a given ROI number across all MCAs. Let's say that the peak for ROI0 on MCA2 is not great and we want to ignore it. My top level device in ophyd has e.g. ``device.mcas.mca1.rois.roi0`` components, so I will add an ROISum() device as e.g. ``device.roi_sums.roi0`` to represent the corresponding calc record. During staging, this ROISum device will look for ROI0 on all MCAs, check its ``is_hinted`` PV, and then write the appropriate formula to the calc record's ``.CALC`` field (e.g ``(A + C + D) / 3`` since MCA2 is ignored). During unstaging, it gets reset to its original value.

Hope that all makes sense. Thanks for the input.

Cheers,
Mark

[1] https://github.com/bluesky/ophyd/blob/1006de0555e2d078c46f629296858323f427b8c4/ophyd/mca.py#L14

---
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.

________________________________________
From: Matt Newville <newville at cars.uchicago.edu>
Sent: Tuesday, June 20, 2023 14:55
To: Wolfman, Mark
Cc: Mark Rivers; Delgado, Uriel; tech-talk at aps.anl.gov
Subject: Re: add fields to an existing record

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<mailto: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<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Wolfman, Mark via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
> Sent: Monday, June 12, 2023 11:25 AM
> To: tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov> <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
> Cc: Delgado, Uriel <udelgado at anl.gov<mailto: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<http://cars.uchicago.edu>> 630-327-7411