Re: put to disabled records and monitors

[Tim Mooney <mooney@aps.anl.gov>]

By the way, you can do a more thorough job of disabling a record by writing 1 to DISP ("Disable putField"), in addition to disabling processing via SDIS or DISA.  (But note that DISP==1 means you can't write to the DISA field, so you have to write to DISA, DISP, DISA in that order.)

It's not perfect, though, because DISP only disables channel-access puts.  The combination of DISP and DISA completely disables channel-access puts, but the first database put still succeeds in changing the VAL field and getting it posted; subsequent database puts change the VAL field but are not posted.

I think it might possible for a record's VAL to be completely shielded even from database puts.  If the VAL field were marked special (SPC_MOD), and the record's special() routine rejected all puts while DISP!=0, I think the VAL field would not change.  I haven't tried it, though, and I don't know if that first post would still occur.

Tim

----- Original Message -----
From: "Tim Mooney" <mooney@aps.anl.gov>
To: "Dirk Zimoch" <dirk.zimoch@psi.ch>
Cc: "EPICS" <tech-talk@aps.anl.gov>
Sent: Thursday, August 30, 2012 10:21:58 AM
Subject: Re: put to disabled records and monitors

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" <dirk.zimoch@psi.ch>
To: "EPICS" <tech-talk@aps.anl.gov>
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 (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


-- 
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab