Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 6 Sep 2013 13:45:07 +0200

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