Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: calc record odd behavior
From: "Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>
To: Ralph Lange <ralph.lange@gmx.de>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Wed, 30 Jan 2019 19:33:19 +0000
On Jan 30, 2019, at 2:20 AM, Ralph Lange via Tech-talk <tech-talk@aps.anl.gov> wrote:
> 
> On Tue, 29 Jan 2019 at 18:00, Johnson, Andrew N. via Tech-talk <tech-talk@aps.anl.gov> wrote:
>> 
>> On 1/29/19 10:09 AM, Bruno Martins via Tech-talk wrote:
>> > CALC's value is initially 1, as expected. However, if I do "caput CALC
>> > 0", a monitor event is never issued again when CALC.VAL goes back to
>> > being 1. Shouldn't a monitor event be issued in this case?
>> Your "caput CALC 0" is pointed at the VAL field, which has some special
>> handling.
>> [...]
> 
> One could say that the VAL field of a CALC record is not intended to be written to, as its value will always be updated by the result of the calculation.
> 
> The same effect (with the same possible surprise about unexpected behavior) applies to all output record types that don't consider VAL as the original source of the value to write, but calculate VAL using some algorithm, e.g. from base:
> 	• the calcout record as it does the same as the calc,
> 	• the mbboDirect record that overwrites VAL with the or'ed up Bn fields,
> 	• the sel record that overwrites VAL with the result of the selection algorithm.

Record types do have some control over the behavior. The db_post_events() call in dbPut() is only skipped for the VAL field if it's marked pp(TRUE) in the Record.dbd file.

Hmm, the CALC record does *not* have pp(TRUE), and when trying Bruno’s database I see that the IOC *does* send out a monitor when I do caput CALC 0, but it never posts the update when the value subsequently goes back to 1. My original analysis of the report was thus wrong.

The problem is that dbPut() doesn’t update the CALC.MLST field when it generates that monitor, so the record doesn’t know anything about it having been sent. When CALC next processes it sets VAL back to 1, which equals the MLST field so the monitor() routine skips sending out an update for that value. Using MDEL=-1 will enforce the monitor updates, but it isn’t the ideal solution since it wastes bandwidth by sending out an update even when the value hasn’t changed.

There is an easy change that might resolve this particular problem, but I don’t think it’s actually the right fix: Set MLST to VAL at the top of the process() routine. It seems wrong because it's ignoring MDEL, but the dbPut() monitors ignore MDEL too...

> Would making the VAL field SPC_NOMOD make the behavior more clear by rejecting writes? Feels like it could have side effects that break existing databases, though…

That does seem like it should be a better fix, but I think it would break too many existing applications. For example another record in the same IOC that writes to the VAL field through a DB link with the PP flag set just to trigger record processing. If VAL were marked SPC_NOMOD that would cause dbPut() to return S_db_noMod which would prevent processTarget() from being called by dbDbPutValue(). The correct database should be writing to the PROC field (or forward-linking). Another problem would be any time the CALC expression uses VAL, which would see the last value which was put.

Other ideas welcome here…

- Andrew


References:
calc record odd behavior Bruno Martins via Tech-talk
Re: calc record odd behavior Johnson, Andrew N. via Tech-talk
Re: calc record odd behavior Ralph Lange via Tech-talk

Navigate by Date:
Prev: Re: AsynDriver with delayed and async communication Eric Norum via Tech-talk
Next: FW: AsynDriver with delayed and async communication Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Re: calc record odd behavior Ralph Lange via Tech-talk
Next: EPICS CSS with OPC UA Abhijit Bhopale via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 30 Jan 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·