Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 6 Sep 2013 17:23:19 +0200

Hi Mark

sorry, my remark was wrong, or at least misleading, because I did not provide
enough context. Here are the details:

On Friday, September 06, 2013 12:57:08 you wrote:
> > 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,

You are absolutely right.

> so an event flag was needed to
> check if it was actually a change in DMOV that has happened.

That certainly depends on the details of your program and the underlying
database. Consider the following more complete code (which I had in mind when
writing the above); the important step I failed to mention is that you must
reset the motorDMOV variable before doing the pvPut to the motor record:

	state start {
		when (foo) {
			motorDMOV = 0;
			pvPut(motor);
		} state check
	}
	state check {
		when(motorDMOV) {
		} state done
	}

It is certainly true that 'state check' might be entered before the motor
record had a chance to set DMOV to zero, so if you do not reset the motorDMOV
variable the program might actually see a motorDMOV that is /still/ non-zero.
Using an event flag in addition to the value as in

	state start {
		when (foo) {
			pvPut(motor);
		} state check
	}
	state check {
		when(efTestAndClear(ef_motorDMOV) && motorDMOV) {
		} state done
	}

would achieve the same result.

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