Experimental Physics and Industrial Control System
> From [email protected] Fri Jul 21 06:56 CDT 1995
> Date: Fri, 21 Jul 1995 12:55:08 +0100 (BST)
> From: Andy Foster <[email protected]>
> X-Sender: ajf@orc
> To: Epics Questions <[email protected]>
> Subject: Monitoring Strings
> Mime-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII>
> Content-Length: 1861
>
>
> To Jeff Hill,
>
> I have a problem with monitoring a string variable in
> a record.
>
> I have a record which is capable of putting out a string
> across an output link. The receiving record (which is
> actually a Gemini CAR record) takes the string
> in as a value (i.e it is not an input link). The CAR
> record as part of it's processing simply copies the
> input string to an output string.
>
> The idea is that this output string will be used to
> convey error messages and this is what I am trying to
> monitor.
>
> If I run the record which is supplying the input string at
> 1 Hz, and simply change the string it is supplying between
> two states i.e. "Starting" and "Ending", I can run CAU and
> monitor the output from the CAR record and indeed it shows:
>
> "Starting"
> "Ending"
> "Starting"
> etc
>
> Now however, if I run a fanout record at 1 Hz from which
> link1 goes to a record which is supplying "Starting" and link2
> goes to a second record which is supplying "Ending", I find that CAU
> gives the following:
>
> "Ending"
> "Ending"
> "Ending"
> etc
>
> I don't understand why it does not pick up the "Starting" string?
>
> I have tried to trace through the relevant EPICS code and got as far
> as "db_post_events" which is called from the "monitor" routine within
> the CAR record. The string has definitely been set correctly before
> "db_post_events" is entered.
>
> I don't know where the processing goes after the statement:
>
> /* Notify the Event Handler */
> SemGive...
I am going to guess that both links end up processing the same record,
i.e. the statement
goes to a second record which is supplying "Ending"
is not quite correct. If my guess is right then here is the explaination.
Record processing runs at higher priority that the channel access servers.
Thus the server will not get a chance to run until record processing completes.
If the same record is processed more than once in a chain of records,
the channel access server only runs once. The routine db_post_event, which
record support calls to CA events, does buffer values but not in all cases.
If it does buffer values then the client does receive all changes. If it
does not buffer then client only gets the latest value stored in the record
when the server finally gets to run.
Channel access will buffer in the following cases
1) Value must be numeric scaler.
2) Allowed options are Time stamp, and alarm status/severity.
The rule 1) excludes DBF_STRING fields and all array fields. The above example
happened because the field is a DBF_STRING field.
Marty Kraimer
- Navigate by Date:
- Prev:
Monitoring Strings Andy Foster
- Next:
FDDI/CDDI to the crate? 312
- 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:
Monitoring Strings Andy Foster
- Next:
FDDI/CDDI to the crate? 312
- 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