Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Thu, 5 Sep 2013 22:39:18 +0000

Hi Konrad,

I ran into a similar problem, for which I found a problematic solution using pvPut(xxx, ASYNC).
Here's an excerpt from synApps/optics/opticsApp/src/orient_st.st.  Essentially, the problem is
that your completion notification is the same event flag that tells you the PV you wrote to has
posted a new value.

		/*
		 * Detect motor events.  There are two possible event types: a new motor value, and
		 * the completion message resulting from a pvPut(<motor>, ASYNC) call that we made.
		 * We try to distinguish these event types, using three pieces of information:
		 * A) weWrote_motXXX        - a flag we set when we write to the motor
		 * B) waiting4motXXX        - a flag we set when we write to the motor
		 * C) pvPutComplete(motXXX) - returns false after pvPut(<motor>, ASYNC), and continues
		 *                            to return false until the EPICS calls SNL back to say the
		 *                            motor (and any processing it may have triggered) is done.
		 *
		 * If the event is a new value, there are three possibilities:
		 * 1) We caused the event directly by writing to the motor, which resulted in
		 *    an immediate posting of the new value.  In this case, we simply clear the flag
		 *    (weWrote_motXXX) that we set at the time we wrote to the motor.
		 * 2) We caused the event indirectly by causing the motor to move, which resulted
		 *    in a delayed posting of the motor value when the motor stopped.  In this case
		 *    we expect the event will coincide with the done event, and will be masked by it.
		 * 3) We had nothing to do with it.  Some outside agent wrote to the motor.
		 *    In this case we start the process of reconciling HKL and angles with the new
		 *    motor position.
		 * Note that if the motor motion is short enough, we expect (1) and (2) to coincide with
		 * each other, and with the done event, which we expect to mask them both.
		 *
		 * If the event indicates completion, we clear both flags and start the process of
		 * reconciling HKL and angles with the new motor position (in case the motors did not
		 * get where we told them to go).
		 */
		when (efTest(motTTH_mon) && waiting4motTTH && pvPutComplete(motTTH)) {
			if (orientDebug) {printf("orient: motTTH done moving\n");}
			efClear(motTTH_mon); PVPUT(waiting4motTTH, 0);
			/*
			 * If motor completes immediately, the monitor and done events will
			 * set the (shared) event flag twice.  There's no way we can tell if
			 * this happened, except to assume the done event must come after the
			 * monitor event.
			 */ 
			if (weWrote_motTTH) PVPUT(weWrote_motTTH, 0);
		} state checkDone

Tim
________________________________________
From: [email protected] [[email protected]] on behalf of Konrad, Martin [[email protected]]
Sent: Thursday, September 05, 2013 2:54 PM
To: [email protected]; [email protected]
Subject: seq and synchronous writes

Hello,
I am using a state machine to control a motor setup. In each step it
basically sends a command to the motor record and waits for it to
complete. This can be detected by the "done moving" field (DMOV).

Here is how I implemented this:

state1 {
   entry {
     sprintf(stateMsg, "state 1");
     pvPut(stateMsg);
   }

   when(foo) {
     motor = bar;
     pvPut(motor, SYNC);
   } state state2
}

state2 {
   entry {
     sprintf(stateMsg, "state 2");
     pvPut(stateMsg);
   }
}

Unfortunately this leads to a long delay between the motor starting to
move and the update of the status message (sometimes 10 seconds!).

I suspect I'm using sequencer the wrong way here. Are synchronous pvPuts
necessary to make sure the command has been send to the motor record?
Should I move the pvPut line to the end of the entry block of state2?
Are there some best practices how to keep the state machine code clean
and readable?

Thanks,

Martin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System