Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: state notation code flags
From: Tim Mooney <mooney@aps.anl.gov>
To: Eric Norum <norume@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Sun, 04 Oct 2009 18:01:23 -0500
I've never had much success reliably distinguishing a user write from
an SNL write to the same record without help from the database.  Here's
what I always do:

Three records: "SNL_write", "user_write", and "SNL_notify", where
SNL writes only to SNL_write, the user writes only to user_write,
and SNL puts an event flag on SNL_notify.  The records are linked as
follows (in what should be a sort of VDCT-like picture, if you're
displaying with a fixed-spacing font):

|---------|    |----------|    |----------|
|SNL_write|    |user_write|    |SNL_notify|
|         |    |          |    |DISV=1    |
|---------|    |----------|    |----------|
    OUT------------VAL
                   OUT-------------VAL
    PACT---------------------------SDIS

The OUT links are PP; the SDIS link is NPP.
So, whenever the user writes to user_write, it processes SNL_notify,
and the SNL program receives an event.  When SNL writes to SNL_write,
it causes user_write to process, so the user gets a monitor event, but
SNL_notify is prevented from processing by its SDIS link, so SNL doesn't
get an event.

Maybe there is a way to accomplish this with SNL code only, and maybe
the strategies you guys are outlining do this, but the things I've tried
haven't been as reliable as the above.

Tim Mooney

Eric Norum wrote:
That approach doesn't sound really robust, either. How long a sleep is "long enough"? Could you forward link the PV to, say, a calc record that incremented its value? Then have the sequence program watch for changes in the calc PV value. Mark Rivers has a similar suggestion, I think.

On Oct 4, 2009, at 11:30 AM, Patrick Thomas wrote:

I don't think I am able to do Mark Rivers' approach in my case because I am not looking for the user to enter a particular value, so I can't differentiate between values the user enters and values done by the pvPut. Would it be safer to put a short sleep in the while loop?

Eric Norum wrote:
Again, that sort of code is not a good idea since it introduces a busy loop. On systems with strict priority-based schedulers (i.e. vxWorks and RTEMS) this can cause deadlock. Mark Rivers' approach of adding an extra qualifier to the when statements is a better technique. It would be good if some SEQ/SNC expert could step in here and explain why the SYNC causes two callbacks, and why this behaviour seems to have appeared between R3.13 and R3.14.

On Oct 4, 2009, at 11:10 AM, Patrick Thomas wrote:

As far as I can tell, it seems that the pvPut without SYNC does only one callback, but it may occur sometime after an immediate efClear. However, with the SYNC option it appears to do two callbacks. My workaround is to remove the SYNC option and do the following:

...
if (data != new_data) {
 data = new_data;
 pvPut(data);
 while(!(efTestAndClear(dataFlag));
}
...
I don't know if this is the best way to do it, but it seems to work.

Patrick

Mark Rivers wrote:
On this topic I know that I observed a change in the behavior of monitor events in SNL when I changed from EPICS 3.13 to 3.14.4. This is a snippet of code from one of my current SNL programs:
long read_complete;
assign  read_complete to "{P}{Dmm}read_complete.VAL";
monitor read_complete;
evflag  read_complete_mon;
sync    read_complete read_complete_mon;

  state read_channel {
...
          read_complete=0;
          pvPut(read_complete);
          efClear(read_complete_mon);
          pvPut(dmm_read);
      } state single_read_response
  state single_read_response {
      when(efTestAndClear(read_complete_mon) && read_complete) {
          pvPut(Dmm_raw);
          done_read = 0;
          pvPut(done_read);
      } state wait_read
  }

Back in 2003 when switching from 3.13 to 3.14.4 I made the following change and CVS log comment to this code:
revision 1.5
date: 2003/09/02 14:24:34;  author: rivers;  state: Exp;  lines: +2 -2
Work around bug (?) in seq for 3.14
----------------------------

corvette:2-9/ipApp/src>cvs diff -r1.4 -r1.5 Keithley2kDMM.st
Index: Keithley2kDMM.st
===================================================================
RCS file: /net/beams-nfs/export/local/cvs/support/ip/ipApp/src/Keithley2kDMM.st,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Keithley2kDMM.st    2002/11/09 00:47:48     1.4
+++ Keithley2kDMM.st    2003/09/02 14:24:34     1.5
@@ -370,14 +370,14 @@
       } state next_channel
   }
   state single_read_response {
-        when(efTestAndClear(read_complete_mon)) {
+        when(efTestAndClear(read_complete_mon) && read_complete) {
           pvPut(Dmm_raw);
           done_read = 0;
           pvPut(done_read);
       } state wait_read
   }
...
In this code I do a pvPut to read_complete, and then immediately clear the event flag on read_complete_mon. In an older version of the sequencer this worked fine, the event flag for the value that was just written with pvPut was cleared with the efClear. When upgrading to 3.14 this stopped working, and I had to add code to ignore the events for the value that pvPut had just written. Now what Patrick has found is that the pvPut can in fact lead to 2 callbacks resulting from the pvPut, not just 1.
Mark

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Eric Norum
Sent: Sat 10/3/2009 9:59 PM
To: Patrick Thomas
Cc: tech-talk@aps.anl.gov Techtalk
Subject: Re: state notation code flags



Yes, it would appear that something in the pvPut causes pvCaMonitorHandler() to be invoked twice. I think that the "take away" message from all this is that there is no way to rely on a a one-to-one correspondence between pvPut calls and sequencer event flag assertions.

On Oct 3, 2009, at 9:28 PM, Patrick Thomas wrote:


Maybe the pvPut sends two monitors, at varying times apart?

Eric Norum wrote:

I added a
 dbpf "H3:TEST_PUT" 1
to the st.cmd script before starting the sequencer. The pvPut in the sequencer program now results in pvCaMonitorHandler() being invoked just once. So, I think you have to live with the fact that a single 'pvPut' can result in an 'sync'd sequencer event flag being set more than once (once from status change, once from value change).

With the dbpf done first, I've run the IOC with following program 500 times without getting a 'flag set' message.

program sncTest

float test_put;
assign test_put to "H3:TEST_PUT";
monitor test_put;
evflag test_putEvent;
sync test_put test_putEvent;

ss ss1 {
 state init {
     when () {
         test_put = 40;
         pvPut(test_put, SYNC);
     } state clear
 }

 state clear {
     when(efTestAndClear(test_putEvent)) { } state wait
 }

 state wait {
     when (efTest(test_putEvent)) {
         printf("flag set\n");
     } state loop
 }

 state loop {
     when (delay(1000)) { } state loop
 }
}


On Oct 3, 2009, at 7:56 PM, Eric Norum wrote:


Tracking this down a little farther. It appears that the pvCaMonitorHandler in <sequencerTop>/src/pv/pvCa.cc is being invoked twice. Perhaps once when the PV status changes from 'invalid' and perhaps once when the PV value is changed? If these happen on either side of the efTestAndClear call then you'll get the 'flag set' message.

On Oct 3, 2009, at 7:32 PM, Patrick Thomas wrote:


It happens frequently on this one too, and also prints "should clear it here"

program sncTest

float test_put;
assign test_put to "H3:TEST_PUT";
monitor test_put;
evflag test_putEvent;
sync test_put test_putEvent;

ss ss1 {
 state init {
     when () {
         efClear(test_putEvent);
         test_put = 40;
         pvPut(test_put, SYNC);
                } state clear
 }

 state clear {
     when(efTestAndClear(test_putEvent)) {
         printf("should clear it here\n");
         efClear(test_putEvent);
     } state wait
 }

 state wait {
     when (efTest(test_putEvent)) {
         printf("flag set\n");
         sleep(500);
     } state wait
 }
}



Eric Norum wrote:

Clarification.  I ran the example, *with busy loops removed*.
On Oct 3, 2009, at 6:30 PM, Eric Norum wrote:


I ran the example in a script. It's been started 250 times now and never printed, "flag set".

On Oct 3, 2009, at 5:37 PM, Patrick Thomas wrote:


I'm sorry, I should clarify. It doesn't print the message after sitting there for a long time. It sometimes prints it when it is started over again multiple times.
-Patrick


Eric Norum wrote:

I forgot to mention, that I tried your example (with busy loops removed) on R3.14.11. My test IOC has been sitting there for half an hour now without printing the message.

On Oct 3, 2009, at 5:13 PM, Eric Norum wrote:


There seems to be a fundamental misunderstanding in your use of the sequencer. The default action, if no state transition 'when' statement is true, is to stay in the same state waiting for a statement to come true. Your examples have lots of statements like:


state clear {
 when(efTestAndClear(test_putEvent)) {
     efClear(test_putEvent);
 } state wait

 when () {
 } state clear
}

The above code is bad. It sets the sequencer into a busy loop consuming all available CPU.
I think what you want is the following:


state clear {
 when(efTestAndClear(test_putEvent)) {
     efClear(test_putEvent);
 } state wait
}

This code blocks the sequencer until something 'interesting' happens at which point it rescans the 'when' statements and checks to see if any of them are now true.

I suspect that your 'flag' problem is occurring because the busy loops you've constructed are preventing other threads from getting the CPU they need.

On Oct 3, 2009, at 4:46 PM, Patrick Thomas wrote:


Hi Mark,

Why does this still sometimes print out the flag?

program sncTest

float test_put;
assign test_put to "H3:TEST_PUT";
monitor test_put;
evflag test_putEvent;
sync test_put test_putEvent;

ss ss1 {
state init {
 when () {
     efClear(test_putEvent);

     test_put = 40;
     pvPut(test_put, SYNC);
 } state clear
}

state clear {
 when(efTestAndClear(test_putEvent)) {
     efClear(test_putEvent);
 } state wait

 when () {
 } state clear
}

state wait {
 when (efTest(test_putEvent)) {
     printf("flag set\n");
 } state loop

 when () {
 } state wait
}

state loop {
 when () {
 } state loop
}
}



Mark Rivers wrote:

Hi Patrick,
What is it you are trying to do? You are doing both pvPuts and looking for external changes to the same PV? If so, then one solution is to ignore events which correspond to the value that your SNL program set with pvPut, and only act on events with values that must have been done by some external agent. Here is an example from one of my programs:
int     abort;       assign abort        to "{P}
{R}Abort.VAL";
monitor abort;
evflag abortMon;        sync abort      abortMon;
...
ss xpsTrajectoryAbort {
state monitorAbort {
when ((efTestAndClear(abortMon)) && (abort==1) &&
     (execState==EXECUTE_STATE_EXECUTING)) {
...
   abort=0;
   pvPut(abort);
} state monitorAbort
}
}
In this case abort can be set to 1 by the user from outside the SNL program. If that happens then the SNL program takes some appropriate action, and does a pvPut of abort back to 0. That would cause another event to be received, but I ignore that event in the when clause()
when ((efTestAndClear(abortMon)) && (abort==1) &&
     (execState==EXECUTE_STATE_EXECUTING)) {
This will always clear event flags on the abort PV, but will only do the logic inside the when if abort is 1 and execState is EXECUTE_STATE_EXECUTING.
Mark

________________________________

From: Patrick Thomas [mailto:thomas_p@ligo-wa.caltech.edu]
Sent: Sat 10/3/2009 12:37 AM
To: Mark Rivers
Cc: jemian@anl.gov; tech-talk@aps.anl.gov
Subject: Re: state notation code flags



I see, thank you. So is there a way around this, that is to make sure the monitors are received and the flag is set before the call to efClear is made, or some way to make a particular pvPut not have channel access
send out monitors for that record?

Mark Rivers wrote:


I think I have figured it out, the following code shows it the most clearly. Adding SYNC to the pvPut command does not seem to ensure that
it will finish before the next command is processed:


The pvPut command did "finish" before the efClear command was executed. That means that it wrote its value to the record, and processed that record and any records that process as a result of processing that record. That record told channel access to send out monitors on that PV to all clients, including your SNL program. It does NOT wait for those monitors to be received; it simply requests channel access to send them, which is then done asynchronously. So the event flag in your SNL program will be set some time after you do the pvPut. What you are observing is the expected and documented behavior of EPICS.

Mark




________________________________

From: Patrick Thomas [mailto:thomas_p@ligo-wa.caltech.edu]
Sent: Fri 10/2/2009 7:03 PM
To: jemian@anl.gov
Cc: Mark Rivers; tech-talk@aps.anl.gov
Subject: Re: state notation code flags



I think I have figured it out, the following code shows it the most clearly. Adding SYNC to the pvPut command does not seem to ensure that
it will finish before the next command is processed:

program sncTest

float request_maximum_velocity;
assign request_maximum_velocity to "H3:TEST";
monitor request_maximum_velocity;
evflag request_maximum_velocityEvent;
sync request_maximum_velocity request_maximum_velocityEvent;


ss ss1 {
state init {
       when () {
               efClear(request_maximum_velocityEvent);

               request_maximum_velocity = 40;
               pvPut(request_maximum_velocity, SYNC);
               efClear(request_maximum_velocityEvent);
       } state wait
}

state wait {
       when () {
if (efTest(request_maximum_velocityEvent)) {
                       printf("flag set\n");
               }
       } state wait
}
}



Pete R. Jemian wrote:


sounds a bit off ... show the code

Patrick Thomas wrote:


I think I have it narrowed down. It appears that when I set variable1 equal to variable2 and variable2 has a flag synced to it (variable1 does not), and then do a pvPut on variable1, sometimes the flag is set on variable2 and sometimes it isn't. Am I correct? Why does this
occur?

Thank you,
Patrick

Mark Rivers wrote:


Patrick,

Event flags can be explicitly set, which is typically used to allow communication between state sets. Or event flags can be synced to a
PV,
and will be set whenever a monitor is received for that PV, as in the
example I sent you.

You can use the efTest() function outside of a when statement, just
like
any other function.

Mark


-----Original Message-----
From: Patrick Thomas [mailto:thomas_p@ligo-wa.caltech.edu
] Sent:
Thursday, October 01, 2009 5:20 PM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
Subject: Re: state notation code flags

Hi Mark,

Are the flags on a monitored variable set whenever the monitored variable is used in the code, including a pvPut, pvGet, assignment, calculation, or print statement? Is there a way to test if the flag
is set besides an efTest in a when statement?

Thank you,
Patrick

Mark Rivers wrote:



Hio Patrick,

Here are some code snippets from one of my SNL programs. It has a


variable nelements assigned to a PV, and a monitor on that PV. It has an event flag, nelementsMon that is synced to nelements. Whenever nelements changes the event flag will be set. In the init state I
clear
the event flag, just to be sure it is clear when the SNL code starts running (after all PVs connect). I then use efTestAndClear in a when statement to take actions when that event flag is set, and to clear it.
This works fine for me.



int     nelements;   assign nelements    to "{P}
{R}Nelements.VAL";
monitor nelements;
evflag nelementsMon;    sync nelements  nelementsMon;


/* Initialize things when first starting */
state init {
when() {
   /* Clear all event flags */
...

   efClear(nelementsMon);
} state monitor_inputs
}


...

state monitor_inputs {

...

when(efTestAndClear(nelementsMon) && (nelements>=1)) {
/* If nelements changes, then change endPulses to this


value,



* since this is what the user normally wants. endPulses


can be



* changed again after changing nelements if this is


desired. */



   if (moveMode == MOVE_MODE_RELATIVE)
       endPulses = nelements;
   else
       endPulses = nelements-1;
   pvPut(endPulses);
} state monitor_inputs
}

Mark

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Patrick Thomas
Sent: Wed 9/30/2009 10:35 PM
To: tech-talk@aps.anl.gov
Subject: state notation code flags



Hi,

I was wondering if there is a way to track at what point in the state notation code evflags are getting set and cleared, or if someone could clarify under what conditions they get set. I'm having trouble with


them



getting set somewhere and not being cleared, but I'm not sure where.

Thank you,
Patrick








--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793



--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793



--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793




--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793










--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.

References:
state notation code flags Patrick Thomas
Re: state notation code flags Patrick Thomas
RE: state notation code flags Mark Rivers
Re: state notation code flags Patrick Thomas
RE: state notation code flags Mark Rivers
Re: state notation code flags Patrick Thomas
Re: state notation code flags Eric Norum
Re: state notation code flags Eric Norum
Re: state notation code flags Patrick Thomas
Re: state notation code flags Eric Norum
Re: state notation code flags Eric Norum
Re: state notation code flags Patrick Thomas
Re: state notation code flags Eric Norum
Re: state notation code flags Eric Norum
Re: state notation code flags Patrick Thomas
RE: state notation code flags Mark Rivers
Re: state notation code flags Eric Norum
Re: state notation code flags Patrick Thomas
Re: state notation code flags Eric Norum

Navigate by Date:
Prev: Re: state notation code flags Eric Norum
Next: Re: EPICS Python client application survey Michael Abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: state notation code flags Eric Norum
Next: RE: state notation code flags Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·