EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: asynPortDriver
From: Hinko Kocevar <[email protected]>
To: [email protected]
Date: Wed, 25 Jul 2012 11:58:46 +0200
On 07/25/2012 12:35 AM, Mark Rivers wrote:
Hi Zen,

I think we were on the right track with the gotValue check, but the timing problem is a little different.

Here is the problem I thought might be happening:

- Your driver calls doCallbacksInt32Array.
- This results in a call to interruptCallbackInput in asyn/devEpics/devAsynXXXArray.h
- interruptCallbackInput copies the data to the waveform record VAL field and then calls scanIoRequest
- Another interrupt occurs before the record processes and calls devAsynXXXArray::processCommon
- gotValue will be 1 because the processCommon has not yet reset gotValue=0

You showed that this problem can happen, but only at higher callback rates.

Here is the problem I now think is happening:
- Your driver calls doCallbacksInt32Array.
- This results in a call to interruptCallbackInput in asyn/devEpics/devAsynXXXArray.h
- interruptCallbackInput copies the data to the waveform record VAL field and then calls scanIoRequest
- scanIoRequest calls processCommon, which sets gotValue=0
- Another interrupt occurs before the record has finished posting monitors.  It overwrites the data in the record.  It calls scanIoRequest again.
- The waveform record then processes twice with the data from the second callback.

This appears to be what you are seeing.

I just realized that the problem is that there no mutex preventing the callback from overwriting the waveform data at any time when the waveform record is processing, which is bad.  Note that is problem is confined to I/O Intr scanned waveform records, it does not happen on other records that use a ring buffer.

Could this situation be avoided by using longin record "in front" of waveform record?

Longin is processed with SCAN=I/O Intr, its FLNK points to (first) waveform which is processed with SCAN=Passive. Longin is just incremented at each trigger to make Asyn happy and get things rolling for the waveform.

Would this make use of the ring buffer (for longin) and still allow the user to see the data at every trigger?

Regards,
Hinko

--
Hinko Kocevar
Software development engineer
Instrumentation Technologies d.d.
Velika pot 22, SI-5250 Solkan - Slovenia
T:+386 5 3352600, F:+386 5 3352601
E-mail: [email protected]
http://www.i-tech.si

The information transmitted is intended solely for the
addressee and may contain confidential and/or privileged
information. Any review, retention, disclosure or other use
by persons other than the intended recipient is prohibited.
If you received this in error, please notify the sender and
delete all copies.

Replies:
RE: asynPortDriver Mark Rivers
References:
asynPortDriver Szalata, Zenon M.
RE: asynPortDriver Mark Rivers
RE: asynPortDriver Szalata, Zenon M.
RE: asynPortDriver Mark Rivers
RE: asynPortDriver Szalata, Zenon M.
RE: asynPortDriver Mark Rivers
RE: asynPortDriver Szalata, Zenon M.
RE: asynPortDriver Mark Rivers

Navigate by Date:
Prev: RE: asynPortDriver Mark Rivers
Next: RE: asynPortDriver Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: asynPortDriver Mark Rivers
Next: RE: asynPortDriver Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024