Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Thu, 30 Aug 2012 10:21:58 -0500 (CDT)

I think it's good for EPICS to cede responsibility for the posting of VAL fields to record-support code (when that code will run) because this permits the record more effectively to reject an unsuitable new value.  If a client has a monitor on the VAL field, the client will never see the rejected value, so it won't trigger unwanted processing, etc.

I do agree that EPICS could do a more thorough job of determining when the record will process.  DISA is a problem because it won't be updated until the record actually is processed, which won't happen until after dbPut() returns.  But I'm not sure I really would want EPICS to post changes to VAL when disa==disv, and again the worrisome scenario is a client ready to process when it receives a monitor.  While the record is active, the client is shielded from certain values, but while the record is disabled, the client responds to whatever anybody writes.  I can imagine a use case for that behavior, but I think more often I'd want a VAL-driven client to be disabled while the record is disabled.

Tim

----- Original Message -----
From: "Dirk Zimoch" <[email protected]>
To: "EPICS" <[email protected]>
Sent: Thursday, August 30, 2012 4:36:23 AM
Subject: put to disabled records and monitors

Hi folks,

A colleague of mine has seen the following strange effect:

If a disabled (DISA=1) record is written then monitors do not show the 
change. To be exact: If the VAL field of a passive record is modified 
multiple times, then a monitor shows only the first change. But if the 
record is scanned periodically, or any other field with pp(TRUE) has 
been written before, then even the first change is not shown. However, a 
caget can confirm that the value has changed.

Even when the record is re-enabled (DISA=0), the monitors do not update 
before the record processes the next time.

Other fields than the VAL field are not affected, all of their 
modifications are immediately shown by monitors.

So it seems if any attempt has been made to process a disabled record, 
then any later modification of the VAL field and only the VAL field does 
not trigger a monitor.

Is this the correct behavior? IMHO no. It leads to inconsistent displays 
for the same value. As for any other field, people also want to see any 
change that someone else makes on the VAL field.

The problem appeared when a epid record had to be configured (KP, KI, 
and KD set, as well as the setpoint VAL), before is is activated. Other 
displays did not show the modified setpoint. I could confirm that the 
problem is not limited to the epid record but affects standard base 
record like ao as well.

The code in question seems to be dbPut in dbAccess.c:

     /* Propagate monitor events for this field, */
     /* unless the field field is VAL and PP is true. */
     pfldDes = paddr->pfldDes;
     isValueField = dbIsValueField(pfldDes);
     if (isValueField) precord->udf = FALSE;
     if (precord->mlis.count &&
         !(isValueField && pfldDes->process_passive))
         db_post_events(precord, paddr->pfield, DBE_VALUE | DBE_LOG);

What about changing this to

     if (precord->mlis.count &&
         !(isValueField && pfldDes->process_passive &&
           precord->disa != precrod->disv))
         db_post_events(precord, paddr->pfield, DBE_VALUE | DBE_LOG);

or skip the whole test for VAL and do

     if (precord->mlis.count)
         db_post_events(precord, paddr->pfield, DBE_VALUE | DBE_LOG);

?

Any opinions?

Dirk

-- 
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System