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.