Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 25 Feb 2010 22:05:47 +0100

On Donnerstag, 25. Februar 2010, Mark Rivers wrote:
> I think every one of my state programs does pvPut and monitors on the
> same PV.  Generally they do the following:
>
> - Put a monitor and an event flag on a PV which is a bo or busy record
> int     build;       assign build        to "{P}{R}Build.VAL";
> evflag buildMon;       sync build        buildMon;
>
> - Have a when clause like the following:
>
>   when(efTestAndClear(buildMon) && (build==1)) {
>         } state build

Using an event flag here looks redundant to me. There should be no 
difference to the simpler

  when(build==1) {
  } state build

>  - Set boVal back 0 to, do a pvPut
>
>    /* Clear build command, post.  This is a "busy" record, don't want
>     * to do this until build is complete. */
>      build=0;
>      pvPut(build);
>
> The check for build=1 is needed because the event will also fire as a
> result of the pvPut of the boVal back to 0.  That behaviour actually 
> changed in some version of the sequencer several years ago (previously I
> could avoid the event flag being set as a result of the pvPut in the SNL
> program).
>
> I don't see anything wrong with the above logic, 

Neither did I until I had these strange failures (they started to appear 
about two months ago), tried some half-hearted fixes that didn't help and 
then finally reduced the program to the simple test case, massaged and 
instrumented it until I could reliably reproduce the error, and after that 
me and my colleague thought very long and hard about it.

This doesn't mean your logic is wrong. What you do may be perfectly safe, 
for all I know.

> and I hope I don't a 
> bunch a warnings in a new version of the sequencer.  

Yes, maybe this is a bit too conservative. Any other ideas?

> Is the problem that 
> was recently discussed limited to the case of multiple state sets
> monitoring the same PV?

Well, the exact instance of the problem appears as I stated it only if one 
state variable is used to communicate both start _and_ completion between 
two state sets working together like co-routines. However, there may lurk 
similar problems in other programs. The problem, the reason why I posted 
the result of our analysis, is that these things are so very hard to see it 
in the code. I was almost certain that my logic was flawless and nothing 
bad should happen. I was wrong.

BTW, there are very simple measures to avoid the (my) problem. One can use 
two state variables, both assigned to the same PV, each one used by only 
one state set. One can also use two event flags and no PV, where one event 
flag starts the worker, and the other signals completion.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System