Redman, Russell O. wrote:
>
> I have spent much of the last week tracking down a strange problem that
> seems to show behaviour directly contrary to the documentation in the
> "Record Reference Manual". Specifically, I find that pushing a value
> through SIOL on an mbbo record using a CA link causes the linked record to
> process, when the RRM specifically says it should not.
If the output link SIOL of the mbbo record is processed, and the link is
a CA link, then processing of the target record does NOT depend on
properties of the mbbo record's SIOL field definition. Processing a CA
output link ultimately results in a ca_put to the target field, and now
it depends on the TARGET field's properties if this results in a
processing of the target record. Specifically, the target record will be
processed if and only if the target field has the PP property as defined
in the record's dbd file.
Since your target field is VAL and VAL almost has PP property, it
follows that the target record gets processed.
Mind that this is different if the output link is a normal database
link. In this case it depends SOLELY on the NPP/PP property of the LINK.
In short: Wether the target record gets processed by an output link
depends
for CA links: only on the (static) target record type
for DB links: only on the (dynamic) link properties
> In a possibly related issue, I find that pushing a value into an mbbo record
> from an SNL state machine using pvPut causes the record to process. It is
> extremely unclear in the SNL users guide whether writing a value to a record
> using pvPut, or reading a value for the record using pvGet, will cause the
> record to process.
It is not extremely unclear. The manual says that all pvXXX operations
go over CA. So, pvPut must be assumed to issue a ca_put.
The situation is in fact identical to the CA outlink problem above.
What is indeed not so clear is if or when pvGet processes the target.
The answer is: never. This is because pvGet uses ca_get (resp.
ca_get_callback) and this never causes the target to be processed. The
only way to 'actively read' from a record is via a normal DB input link,
that has the PP flag set.
Warning: If the target of a PP input DB link has asynchronous device
support, you will always get the old value, not the new one, because
normally the new value will be set when the record gets re-processed by
the device support - at some later time.
Ben
--
Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung
(BESSY) GmbH, Control System Group
Albert-Einstein-Straße 15, 12489 Berlin, +49 30 6392 4862, www.bessy.de
- Replies:
- Re: When does a link process its target record? Benjamin Franksen
- References:
- [no subject] Redman, Russell O.
- Navigate by Date:
- Prev:
Re: Your Message Sent on Thu, 31 Oct 2002 12:25:33 -0800 Andrew Johnson
- Next:
Re: When does a link process its target record? Benjamin Franksen
- 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:
[no subject] Redman, Russell O.
- Next:
Re: When does a link process its target record? Benjamin Franksen
- 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
|