limit change subscriptions not supported

[Jeff Hill]

From Dave Reid

I'm trying to lay out some EDM screens, and I'd like to use the .HOPR and .HIHI values in the visibility settings for some items. However, this doesn't seem to work. If I put in the actual number values, things work like I want them to, but it would be great if this could be a more dynamic thing.

Anyone have any experience with this or have a good work around?

Additional information:
Unfortunately, it's not currently possible for EDM, or any other EPICS client, to subscribe for updates to be sent when there are changes in the limits. Therefore, most clients fetch the limits when they connect and assume that they don't change after that. Perhaps that might explain EDM's behavior.

PS: This could be fixed in the database by creating a new subscription trigger option bit (in addition to DBE_VALUE, DBE_LOG, and DBE_ALARM). In the current system the limit changes wouldn’t be stored on the event queue, but notification would be, and a current value would be fetched by the server when sending the subscription update message, and that would probably be a fully suitable behavior considering that limits don’t change very often. Nevertheless, changes are coming in R3.15 which will allow almost any data structure to be potentially stored on the event queue (including the limits).

Original Mantis Bug: mantis-303
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=303

[Andrew Johnson (anj)]

We added the event type DBE_PROPERTY in R3.14.11 which provides the basis for a solution to this issue but doesn't actually result in the events being generated inside the IOC yet. The IOC will need some extra infrastructure added to inform it that specific record fields provide property values for other fields, so it knows that for example when someone sets the HIHI field it needs to post a DBE_PROPERTY event on all fields that use HIHI when filling in a DBR_ALARM_DOUBLE value.

[mdavidsaver (mdavidsaver)]

As of R3.15.0.2 events with DBE_PROPERTY are posted for recordtypes including the "prop(YES)" field modifier in their definitions to mark field storing CA meta-data. All Base recordtypes do this.