Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Fri, 31 Aug 2012 09:52:31 +0200

Tim Mooney wrote:

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.)

That's the opposite of what we need :-)

The record has to be configured before it starts its work. That means

putting values to several fields (VAL and others).

Dirk

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" <[email protected]>
To: "Dirk Zimoch" <[email protected]>
Cc: "EPICS" <[email protected]>
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" <[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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System