RE: OPI updates when enum strings/values change

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

Hi Andrew,

I looked to see how PREC and other fields support DBE_PROPERTY in EPICS base.  I see that the ao, ai, etc. record dbd files put the attribute "prop(YES)" on fields that should generate DBE_PROPERTY callbacks.

I just added prop(YES) to the PREC field in motorRecord.dbd and now when PREC changes Phoebus updates the window to the new precision instantly, without needing to close and re-open the window.  This is great!

A couple of questions:
- If we were to add prop(YES) to fields in the motor record then it would require a minimum of base 3.14.11?
- What fields in the motor record would you suggest adding prop(YES) to?

Thanks,
Mark


From: Andrew Johnson <anj at anl.gov> 
Sent: Tuesday, May 2, 2023 12:51 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,

DBE_PROPERTY was added in 3.14.11, I guess that may be older than your earliest supported version.

IIRC the difference between passing &pr->val and NULL is that the latter should trigger monitors of the relevant event type on any field. Your code is fine since only the VAL field has those strings for metadata, but for a record type that also had an OVAL (old-VAL) field with the same set of choice strings, using NULL would trigger monitors on both.

dbAccess.c also uses NULL when posting DBE_PROPERTY changes after a put() to any field that is marked prop(YES) in the DBD file since it doesn't know which field(s) might use the newly-updated field in their metadata.

The mbbo and mbbi records don't need prop(YES) markings on the *ST fields since they're all marked special() and handled explicitly by the record code.

- Andrew

On 5/2/23 12:22 PM, Mark Rivers wrote:
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 mailto:anj at anl.gov 
Sent: Tuesday, May 2, 2023 12:07 PM
To: Mark Rivers mailto:rivers at cars.uchicago.edu; Michael Davidsaver mailto:mdavidsaver at gmail.com; mailto: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.


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