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
- References:
- Re: Sequencer bug? Benjamin Franksen
- Re: Fwd: Sequencer bug? Andrew Johnson
- RE: Fwd: Sequencer bug? Mark Rivers
- Navigate by Date:
- Prev:
Re: Fwd: Sequencer bug? Tim Mooney
- Next:
asyn R4.12 and streamdevice R2.4 Szalata, Zenon M.
- 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:
RE: Fwd: Sequencer bug? Mark Rivers
- Next:
Re: Fwd: Sequencer bug? Tim Mooney
- 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
|