Re: Rec Proc Monitor no longer in EPICs 7 record reference documentation.

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Andy,

On Sep 26, 2021, at 9:37 AM, Wang, Andrew <wang126 at llnl.gov> wrote:

Greatly appreciate your answer. Regarding your comment about the generation of the Record Reference documentation from the DBD files, are you also referring to the HTML files for each record type within the epics-build directory? 

Yes, which I also publish on the Argonne EPICS website and link to under the individual Base version page.

Secondly, regarding camonitor, it was based upon a misunderstanding on my end. For some reason, I had thought that the absence of the Rec Proc Monitor column meant that camonitor would not work as expected for EPICS 7.

Monitor events are a fundamental part of how EPICS reduces the network and processing bandwidth needed by a control system, their functionality would never get removed.

Lastly, does the CA PP column share a similar definition as the PP column in previous EPICS versions, where writing to a given field causes the record to process? 

Yes, the IOC reads that flag for each field from the DBD file so the documentation publishes that information taken from exactly the same source.

- Andrew

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Saturday, September 25, 2021 7:58 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Rec Proc Monitor no longer in EPICs 7 record reference documentation.

 

Hi Andy,

On Sep 25, 2021, at 1:12 AM, Wang, Andrew via Tech-talk <tech-talk at aps.anl.gov> wrote:

Quick question. Why do the tables for fields of the records in the record reference documentation not list Rec Proc Monitor anymore? 

Good question. The tables in the new versions of the Record Reference documentation that describe the record fields are now generated automatically from the DBD files at build time, so they will always match the definition used by the code (with the exception of a few columns for fields that can be configured at load-time, such as the VAL field of a waveform record). The main text does have to be edited by hand though, so it can still get out of date.

The information in the Rec Proc Monitor column that was present in previous versions of the field tables cannot be extracted from the DBD file. It showed “Yes” if the record-type’s process() routine could post monitors on that field, and the answer for that has to come from the C code. As a result it is more likely to get out of date as the C code changes.

It would be possible to add the column back into the tables and require hand-annotation of the fields that should show “Yes”, but this would take a combination of some programming effort and edits to all of the record type DBD files to add that annotation. I’m not too keen on adding the column back though, since it would easily get out of date as the code gets changed, but it would be relatively easy for the text to provide a list of the fields that have monitors posted on them by the process() routine. That still requires all the DBD files to be edited to add the list, but that might make it more obvious that the information is provided by hand so is more likely to be fallible.

Follow up question is whether or not this affects how camonitor behaves in EPICs 7.

It does not (I’m not sure how it could, is there something deeper in your question?). The set of fields that do post monitor updates has changed slightly over the years, in most cases we have added monitors rather than take them away though.

HTH,

- Andrew

-- 

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

-- 

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