Experimental Physics and Industrial Control System

["Redman, Russell O." <Russell.Redman@nrc.ca>]

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?