But you should be able to do the following:
myValue = 0;
myPrevValue = myValue;
pvPut(myValue);
when(efTestAndClear(myEventFlag) && myValue != myPrevValue) {
myPrevValue = myValue;
do_something
}
________________________________
From: Patrick Thomas [mailto:[email protected]]
Sent: Sun 10/4/2009 11:30 AM
To: Eric Norum
Cc: Mark Rivers; [email protected]
Subject: Re: state notation code flags
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: [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
>>>
>>>
>>>
>>>
>>>
>>
>
- References:
- state notation code flags Patrick Thomas
- Re: state notation code flags Pete R. Jemian
- 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
- Navigate by Date:
- Prev:
Re: EPICS Python client application survey Matt Newville
- Next:
Re: state notation code flags Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: state notation code flags Tim Mooney
- Next:
Re: state notation code flags Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|