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: [email protected] on behalf of Eric Norum
Sent: Sat 10/3/2009 9:59 PM
To: Patrick Thomas
Cc: [email protected] 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:[email protected]
]
Sent: Sat 10/3/2009 12:37 AM
To: Mark Rivers
Cc: [email protected]; [email protected]
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:[email protected]
]
Sent: Fri 10/2/2009 7:03 PM
To: [email protected]
Cc: Mark Rivers; [email protected]
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:[email protected]
] Sent:
Thursday, October 01, 2009 5:20 PM
To: Mark Rivers
Cc: [email protected]
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: [email protected] on behalf of
Patrick Thomas
Sent: Wed 9/30/2009 10:35 PM
To: [email protected]
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 <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
