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: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Tue, 29 Jan 2019 17:00:23 +0000
Hi Bruno,

On 1/29/19 10:09 AM, Bruno Martins via Tech-talk wrote:
> I noticed something odd when using the calc record. This is the
> database I have:
>
> record(ai, "A") {
>   field(PINI, "YES")
>   field(VAL,  "1")
> }
>
> record(calc, "CALC") {
>     field(INPA, "A")
>     field(CALC, "A")
>     field(SCAN, "1 second")
> }
>
> 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.

Normally when you do a put to a record field the dbPut() routine posts a
CA monitor on that field immediately after setting its value. However if
the put is directed to the record's VAL field and it could cause the
record to be processed (which actually happens slightly later on) that
monitor is explicitly skipped, on the assumption that the record's
process() routine will be posting a monitor on the VAL field soon anyway.

Strictly speaking the skip only happens when the record type's VAL field
is marked PP(TRUE), but most Base record types are like that anyway. It
also doesn't depend on the record's SCAN field, unlike the later code
that subsequently calls the record's process() routine as long as SCAN
is "Process Passive".

The assumptions built into the design are obviously and unfortunately
incorrect in your specific case, but have been baked into the code of
the dbPut() routine for a long time. You could force a monitor event to
be generated every time the record processes by setting CALC.MDEL to -1
but you probably don't want an event for every 1-second scan, only after
you've triggered it with a put.

If you changed your client to monitor and caput to the A field of the
CALC record that would work, but we are concerned about breaking
existing databases if we were to change this code.

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon


Replies:
Re: calc record odd behavior Bruno Martins via Tech-talk
Re: calc record odd behavior Ralph Lange via Tech-talk
References:
calc record odd behavior Bruno Martins via Tech-talk

Navigate by Date:
Prev: Re: Support for GBS MCA527 Hinko Kocevar via Tech-talk
Next: Re: calc record odd behavior Bruno Martins 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: calc record odd behavior Bruno Martins via Tech-talk
Next: Re: calc record odd behavior Bruno Martins 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 ·