Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 6 Sep 2013 12:57:08 +0000

Hi Ben,

> BTW, using an event flag in addition to testing the value of a (assigned and 
> monitored) variable is redundant, except when you associate the event flag 
> with several distinct PVs.

I have a basic question about this.  If I have a when statement

    when (DMOV == 1) {
    ...
    } state2

When is that block executed?

1) Only when DMOV changes and is 1
2) When any event the sequencer is monitoring occurs and DMOV is 1

I always thought the answer was 2) above, so an event flag was needed to check if it was actually a change in DMOV that has happened.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Benjamin Franksen [[email protected]]
Sent: Friday, September 06, 2013 6:45 AM
To: [email protected]
Subject: Re: seq and synchronous writes

Hi Martin

On Thursday, September 05, 2013 22:30:44 Konrad, Martin wrote:
> > Event flags are very useful for detecting changes that may be too
> > quick to catch by looking at the value.
>
> I looked into them as well but the sequencer documentation says:
>
> "Neither testing the value of a monitored channel in a when clause nor
> associating the channel with an event flag and then testing the event
> flag can guarantee that the sequence is aware of all monitors posted on
> the channel."

Strictly speaking this is true. However, the only situation where an event can
be lost to the sequencer is when events follow in rapid succession: your state
set may 'see' only the last event. In case of the DMOV field, testing for DMOV
in a when-clause:

        when(motorDMOV) {
        } state done

after causing a move (by writing to the record) should work reliably, if you
can ensure that no other agent (state set, record, CA client program) causes
the motor record to process and start moving right after the previously
initiated movement is complete (which would cause DMOV to be reset to zero).

BTW, using an event flag in addition to testing the value of a (assigned and
monitored) variable is redundant, except when you associate the event flag
with several distinct PVs.

> But going through the documentation again revealed that this issue can
> be fixed using queuing monitors:
> http://www-csr.bessy.de/control/SoftDist/sequencer/Tutorial.html#queuing-mon
> itors
>
> However the easiest way seems to be using asychronous pvPuts together
> with pvPutComplete. Unfortunately all these solutions require an
> additional state. But I think I can live with that...

The asynchronous put method works, too, but it relies on the same assumptions
as testing for DMOV. This is because asynchronous pvPut will immediately
'complete' (actually fail, but this is not easily detectable) if one of the
records in the processing chain is already active. Also note that the ASYNC
versions of pvPut and pvGet never time out. If the motor record somehow gets
stuck and never completes processing, your program gets stuck, too. (But this
is true for testing DMOV, too.) If you have already acquired a healthy
paranoia ;-) you can guard against such a possibility with a second when-
clause that contains a delay call e.g.

        when(pvPutComplete(motor)) {
        } state done
        when (delay(timeout)) {
        } state error

Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System