Experimental Physics and
Industrial Control System

Ned Arnold <nda> · Thu, 31 Oct 2002 16:53:03 -0600 (CST)

The short answers are ...

> 
> My big questions are thus
> 1) Under what circumstances does pushing a value over a CA link cause the
> target record to process? 

... if the destination field is defined as "PP" (with the statement "pp(TRUE)"
in the *.dbd file and so documented under the PP column in the record 
reference manual) and the record scan field is set to "Passive". If these
two conditions are true, the record will process when ANY channel access
client (including a sequence programs, CA links, etc) writes to that field.

> 2) Under what circumstances do pvPut or pvGet cause the assigned record to
> process?

pvPut : same circumstances as above. A sequence program is a CA client
pvGet : never. Currently, "gets" can not cause a record to process.

I believe things were behaving as designed.

	Ned

> Date: Thu, 31 Oct 2002 12:25:33 -0800
> From: "Redman, Russell O." <[email protected]>
> Subject: 
> To: "Tech-Talk (E-mail)" <[email protected]>
> Cc: "Wooff, Robert" <[email protected]>, "Ebbers, Angelic" 
<[email protected]>, "'Rees, Nick'" <[email protected]>
> MIME-version: 1.0
> List-Help: <http://www.aps.anl.gov/epics/mail.php>
> 
> 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.
> 
> 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.
> 
> This message is a plea for someone who understands channel access and SNL
> better than I to clarify the documentation on when we can expect records to
> process.
> 
> =====================================================================
> 
> Here was my specific problem.  For the record, I am using EPICS R3.13.5, SNL
> 1.9.5, and all of this runs in a single IOC running a PPC CPU  on an
> MVME2700 motherboard.
> 
> I have two databases, the first being a controller (conb) and the second
> being a simulator (simb).  Corresponding bits of these two databases
> control/simulate a Galil Motor Controller.  The relevant parts for the
> moment are two mbbo records, which for brevity I will refer to as conb:cmd
> and simb:cmd.  These both have the possible states:
> 
>    ZRST = WAIT
>    ONST = MOVE
>    TWST = HOME
>    THST = STOP
>    FRST = INIT
> 
> The field conb:cmd.SIOL contains a CA link to simb:cmd (dbpr gives
> "SIOL:CA_LINK simb:cmd CA NMS" for this field). Thus, processing conb:cmd in
> simulation mode causes its value to be pushed through a CA link into
> simb:cmd.
> 
> Hovering over these I have two SNL state machines named gunnTuner and
> gunnTunerSim for the controller and simulator respectively.  The gunnTuner
> connects to conb:cmd, and uses code like
> 
>    int ccmd;
>    assign ccmd to "conb:cmd";
>    . . .
>    ccmd = MOVE;
>    pvPut( ccmd); 
> 
> to push values into conb:cmd.  Similarly, gunnTunerSim uses code like
> 
>    int scmd;
>    assign scmd to "simb:cmd";
>    monitor scmd;
>    . . .
>    when (scmd == MOVE) {
>      scmd = WAIT;
>      pvPut( cmd);
>      errlogPrintf("transition to state \"moving\" with cmd=%d\n",cmd);   }
> state moving
> 
> which monitors changes to simb:cmd and resets it to WAITING after it
> interprets each command.
> 
> My first problem (one of understanding) is that I do not know why "pvPut(
> ccmd);" causes conb:cmd to process, although it clearly does.  The "State
> Notation Language and Sequencer Users Guide" clearly states that CA is used
> to get and put values into the database, but is pretty vague about what
> actions might cause a record to process. the documentation for pvPut just
> says:
> 
>    pvPut
>    int  pvPut(db_variable_name)
>    This function puts or writes the value to the database channel. 
>    The function returns the status from the channel access layer 
>    (e.g. ECA_NORMAL for success). 
> 
> The documentation for pvGet states that the call will block until the get is
> complete (unless the -a option is on), but does not discuss whether the
> assigned record immediately returns its current value or processes itself
> first.  FWIW I am using SNL v1.9.5, but the documentation says the same
> thing for 1.9 and 2.0.  Regardless, executing this command does cause
> conb:cmd to process and in simulation mode pushes the new value over to
> simb:cmd.
> 
> Here, the Record Reference Manual is very explicit.  In Section 1.3, in the
> subsection titled "Passive Scanning and Channel Access Links", we read:
> 
>    Channel Access links, be they between records located in 
>    different IOCs or between records located in the same IOC, 
>    cannot be process passive, e.g., they cannot cause the 
>    record they specify to process when written to or read from.
> 
> Thus, simb:cmd should NOT process when conb:cmd puts a new value into it
> over a CA link.  Section 2.2 discusses the same issue in the subsection
> labelled "Channel Access Links":
> 
>    Output links can also specify CA, in which case they will be 
>    forced to be Channel Access links. When an output link becomes 
>    a Channel Access link, a buffer is allocated the first time a 
>    "put" operation occurs on the record containing the link. Each 
>    time a "put" occurs for the record, the data is retrieved from 
>    the buffer. And the buffer is updated. The CP and CPP options 
>    are not available for output links.
> 
>    . . .
> 
>    Because of the nature of Channel Access links, they cannot be 
>    process passive. For example, if an input link that specifies 
>    another record in another IOC but also specifies PP, the 
>    PP attribute will be ignored.
> 
> The significance of updating the buffer is a bit obscure, but it again seems
> clear that simb:cmd should NOT process when conb:cmd puts a value into it
> over a CA link.
> 
> Notwithstanding, simb:cmd DOES process and posts monitors so that
> gunnTunerSim picks up the new value and starts the move.  I consider this to
> be desirable behaviour, but somewhat surprising in view of the
> documentation.  To verify that simb:cmd really processes, and does not just
> trigger the monitors, we can set simb:cmd.TPRO to "1":
> 
>    -> dbpf "simb:cmd.TPRO","1"
>    DBR_UCHAR:          1         0x1
>    value = 0 = 0x0
>    -> dbpf "conb:cmd","1"
>    DBR_STRING:          MOVE
>    value = 0 = 0x0
>    -> process:   simb:cmd
>    process:   simb:cer
>    process:   simb:cmd
>    process:   simb:cer
> 
> The record simb:cer checks for invalid values of cmd and is forward linked
> from simb:cmd.  Note that simb:cmd processes twice - first when conb:cmd
> pushes the value "1" to it through the CA link (!), and a second time when
> gunnTunerSim resets its value back to WAIT.
> 
> When I first wrote this code, I did not expect pvPut to cause conb:cmd to
> process, so I added a bit of extra code to be sure that it happened:
> 
>    int ccmd;
>    assign ccmd to "conb:cmd";
>    int ccmdProc;
>    assign ccmdProc to "conb:cmd.PROC";
>    . . .
>    ccmd = MOVE;
>    pvPut( ccmd); 
>    ccmdProc = 1;
>    pvPut( ccmdProc);
> 
> This gave me great grief because conb:cmd processed twice in VERY rapid
> succession, too fast for any of the normal EPICS reporting mechanisms to
> react.  In gunnTunerSim the errlogPrintf reported that scmd still had the
> value MOVE two lines after I had set it to WAIT!  Evidently, the first time
> conb:cmd processed it triggered the clause "when (scmd == MOVE)", which set
> simb:cmd back to WAIT with a small delay while pvPut executed.  During that
> delay conb:cmd processed a second time, setting simb:cmd back to MOVE and
> triggered the monitor that reset scmd back to MOVE.  All of this happened
> BEFORE errlogPrintf had a chance to print the value.  
> 
> What I found most bizarre is that everything worked exactly as I had
> expected if I pushed a value directly into simb:cmd from the shell or an
> MEDM display.  This, I now understand, worked because I was not triggering
> conb:cmd twice in rapid succession.
> 
> My big questions are thus
> 1) Under what circumstances does pushing a value over a CA link cause the
> target record to process? 
> 2) Under what circumstances do pvPut or pvGet cause the assigned record to
> process?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System