RE: OPI updates when enum strings/values change

[Mark Rivers via Core-talk <core-talk at aps.anl.gov>]

Hi Andrew,

 

Thanks.  Asyn device support is already calling db_post_events with DBE_PROPERTY when the enum strings change.

https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/asyn/devEpics/devAsynInt32.c#L722

https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/asyn/devEpics/devAsynUInt32Digital.c#L557

 

It is not testing whether the DBE_PROPERTY macro exists.  What version of base was that first supported?

It is passing the pointer to the VAL field, rather than NULL.  Is that OK?

 

Thanks,

Mark

 

From: Andrew Johnson <anj at anl.gov>
Sent: Tuesday, May 2, 2023 12:07 PM
To: Mark Rivers <rivers at cars.uchicago.edu>; Michael Davidsaver <mdavidsaver at gmail.com>; core-talk at aps.anl.gov
Subject: Re: OPI updates when enum strings/values change

 

Hi Mark,

I believe it's the Asyn device support (or something similar) that is changing the strings inside its own mbbo record, is that correct? If so there is an additional db_post_events() call that it needs to make (after updating the string(s)) to notify clients about the metadata change:

    db_post_events(prec, NULL, DBE_PROPERTY);

DBE_PROPERTY is a macro defined in the caeventmask.h header, you can use the existence of that macro as a test for whether to make this call (older Base versions didn't have it).

HTH,

- Andrew

On 5/2/23 11:48 AM, Mark Rivers via Core-talk wrote:

Hi Michael,

 

At the EPICS Core workshop last week I made a comment that one limitation of Channel Access was that OPI clients are not informed when enum strings or values change, and so OPI displays don’t update to reflect these changes.  I said that one needs to close the display and re-open it in order to see the changes.

 

You said this was because I was using a very old OPI client, i.e. medm.  You said that modern clients handle this correctly, by having 2 subscriptions to the PV, one for the value and one for the metadata.  You said that Phoebus is one of the clients that handles this correctly.

 

I just tested this with Phoebus.  I used the asyn/testAsynPortClient application.  In that application when the VerticalGain record is changed the enum choices for the VoltsPerDivSelect and VoltsPerDivSelect_RBV fields are changed.

 

VerticalGainRecord: https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/testAsynPortDriverApp/Db/testAsynPortDriver.db#L105

 

Code where enum values for VoltsPerDivSelect are changed: https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/testAsynPortDriverApp/src/testAsynPortDriver.cpp#L369

It does callbacks to device support where the record values are changed: https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/asyn/devEpics/devAsynInt32.c#L726

 

I have converted the medm .adl file for testAsynPortDriver to a Phoebus .bob file: https://github.com/epics-modules/asyn/blob/master/testAsynPortDriverApp/op/bob/autoconvert/testAsynPortDriver.bob

 

When I change the vertical Gain in Phoebus I observe exactly the same thing as in medm.  The enum menu choices for VoltsPerDivSelect mbbo and the enum string for the selected VoltsPerDivSelect_RBV do not update automatically.  They only update when I close the Phoebus window and re-open it.

 

I presume the behavior I observe with Phoebus must be due to one of the following 3 reasons:

 

1. The asyn code for updating enum values is incorrect.
2. The fact that the .bob file is autoconverted from medm rather than created natively in Phoebus is causing the undesired behavior.
3. Phoebus cannot in fact update the screen when enum values change.

 

Thanks,

Mark

 

 

 

-- 

Complexity comes for free, Simplicity you have to work for.