EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: SNL monitor and pvPutComplete
From: "Pearson, Matthew R." <[email protected]>
To: Emmanuel Mayssat <[email protected]>
Cc: EPICS mailing list <[email protected]>
Date: Wed, 22 Jan 2014 16:01:49 -0500
Hi,

Thanks for the response. After a bit more testing, I'm convinced the server side database processing is happening in order. In my Asyn driver I am updating status_pv (via callParamCallbacks), before the callback is processed. I enabled TPRO and put some print statements in the Asyn device support. Here I am doing a put_callback on 'BL7:CS:CvInfo:Start':

epics> CAS-client: Process BL7:CS:CvInfo:Start
processBo name: BL7:CS:CvInfo:Start
2014/01/22 14:35:20.239 BL7:CS:CvInfo:State devAsynInt32::interruptCallbackInput new value=1
2014/01/22 14:35:20.239 BL7:CS:CvInfo:Start devAsynInt32 process value 1
cbLow: Process BL7:CS:CvInfo:State
processMbbi name: BL7:CS:CvInfo:State
2014/01/22 14:35:20.239 BL7:CS:CvInfo:State devAsynInt32::getCallbackValue from ringBuffer value=1
processBo name: BL7:CS:CvInfo:Start
cbLow: Process BL7:CS:CvInfo:StartProc

Here, 'BL7:CS:CvInfo:State' is my status_pv. I forward link 'StartProc' from the start record, so I can see the end of processing using TPRO. 

On my client side, in the SNL, I am seeing the monitor update on the 'State' PV occasionally arrive after the completion of the callback. So, it looks like the sequencer is behaving ok, as it's just processing callbacks in order. 

In the sequencer, I put a print statement in 'pvCaMonitorHandler', with the name of the record. I also print the value of 'state_pv' in the SNL, before and after the pvPut(start_pv ,SYNC) statement. This was one that worked:

state_pv: 0
0x7f9f94052f90: caVariable::putCallback( 1, 1 )
0x7f9f94053450: pvCallback::pvCallback( 1, 1, 0x7f9ff7207509, 0xb87cb0, 9 )
0x7f9f90000900: caSystem::flush()
   pvCaMonitorHandler name: BL7:CS:CvInfo:State
   pvCaMonitorHandler name: BL7:CS:CvInfo:Start
0x7f9f94053450: pvCallback::~pvCallback()
state_pv: 1

and this was a fail:

cvinfo_state_pv: 0
0x7f9f94052f90: caVariable::putCallback( 1, 1 )
0x7f9f94053450: pvCallback::pvCallback( 1, 1, 0x7f9ff7207509, 0xb87cb0, 9 )
0x7f9f90000900: caSystem::flush()
   pvCaMonitorHandler name: BL7:CS:CvInfo:Start
0x7f9f94053450: pvCallback::~pvCallback()
cvinfo_state_pv: 0
   pvCaMonitorHandler name: BL7:CS:CvInfo:State


Now I'm wondering how the callback reply can arrive at the client before the monitor.



Cheers,
Matt



On Jan 21, 2014, at 7:58 PM, Emmanuel Mayssat <[email protected]> wrote:

> Although I haven't programmed the seq for a while, here is what I believe is happening
> The "monitored" variable is (in concept) similar to a volatile C variable.
> The variable is automatically updated based on what is in the EPICS database (not the hardware!).
> 
> If the update of status_pv is completing after pvPutComplete, then you will experience what you describe.
> If you want to trigger state changes or processing on an update (i.e. monitor) you need to use event flags
> * efTest check that the flag is at 1 ( a monitor has been received since it was last cleared)
> * efTestAndClear does the same and reset the flag to 0
> Those commands are most often found in test (when) conditions.
> Otherwise use efClear and efSet
> 
> sample code:
> 
> /*  Monitored variables */
> double  voltageAO;
> assign  voltageAO to "{deviceName}:{channelId}VltgAO";
> monitor voltageAO;
> evflag  monitorVoltageAO;
> sync    voltageAO monitorVoltageAO;
> 
> [...]
>   state channel_idleState {
>     entry {
>       seqLog("--> channel_idleState\n");
>       seqLog("efAO=%d, efMO=%d\n", efTest(monitorVoltageAO), efTest(monitorVoltageMO));
>     }   
>     when(efTest(monitorVoltageAO) ) { 
>       efClear(monitorVoltageAO);
>     } state channel_updateVoltageMIState
>     when(!efTest(monitorVoltageAO) && efTest(monitorVoltageMO)) {
>       efClear(monitorVoltageMO);
>     } state channel_updateVoltageAOState
>     exit {
>       seqLog("<-- channel_idleState\n");
>     }   
>   }
> 
> 
> 
> 
> 
> > 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
> > 
> > 
> > 
> > 



Replies:
Re: SNL monitor and pvPutComplete Benjamin Franksen
References:
SNL monitor and pvPutComplete Pearson, Matthew R.
RE: SNL monitor and pvPutComplete Emmanuel Mayssat

Navigate by Date:
Prev: EPICS Collaboration Meeting 5/19 - 5/23 Institute of Modern Physics in Lanzhou, China Dalesio, Leo
Next: Re: SNL monitor and pvPutComplete Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: SNL monitor and pvPutComplete Emmanuel Mayssat
Next: Re: SNL monitor and pvPutComplete Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·