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
<2019>
2020
2021
2022
2023
2024
- 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
<2019>
2020
2021
2022
2023
2024
|