Experimental Physics and
Industrial Control System

[email protected] (Marty Kraimer) · Fri, 21 Jul 1995 09:04:44 -0500

> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System