Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Wed, 25 Jul 2012 13:59:42 +0000

I think we really want the devAsynXXXArray device support to work as it should standalone, with no additional records needed. I'm hoping the fix I proposed will fix Zen's problem.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Hinko Kocevar
Sent: Wednesday, July 25, 2012 4:59 AM
To: [email protected]
Subject: Re: asynPortDriver

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System