Experimental Physics and
Industrial Control System

> From: [email protected]
> To: [email protected]
> Date: Tue, 21 Jan 2014 17:42:46 -0500
> Subject: SNL monitor and pvPutComplete
>
>
> Hi,
>
> I'm using SNL to perform a potentially long put_callback, using pvPut with the ASYNC option in one state, followed by the use of pvPutComplete in the following state. Then on completion, I read another PV immediately, which has an SNL monitor on it, something like:
>
> unsigned short start_pv; assign start_pv to "{RC}:Start"; monitor start_pv;
>
> unsigned short login_pv; assign login_pv to "{DAS}:Login";
> unsigned short status_pv; assign status_pv to "{DAS}:Stat"; monitor status_pv;
>
> state idle {
> /* When we detect a user start. */
> when (start_pv == 1) {
> login_pv = 1;
> pvPut(login_pv, ASYNC);
> } state login
> }
>
>
> state login {
> when (pvPutComplete(login_pv)) {
> if (status_pv != 1) {
> /*handle error here*/
> } else {
> /*it worked */
> }
> } state thenextstate
> }
>
>
> I have a race condition between the completion of the put_callback and the status_pv variable updating due to a monitor. I sometimes read the value the status PV had before the callback completes. I've tested the underlying system quite a bit, so I suspected a problem with my SNL. I added in a pvGet(status_pv) just before I test that variable, and it seems to have solved it (which maybe just due to the extra time taken to execute the pvGet).
>
> Am I handling this situation incorrectly, or do we know of a problem with monitors in SNL (SEQ Version 2.0.14)? Is the use of pvGet on a monitored variable a bad idea? From reading tech-talk, it might be frowned upon...
>
> Or, is there a better way of doing this, using event flags?
>
> Cheers,
> Matt
>
>
>
>