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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Waveform record I/O interrupt. asyn |
From: | "Hill, Jeff" <[email protected]> |
To: | "Dalesio, Leo" <[email protected]>, Vishnu Patel <[email protected]>, "techtalk " <[email protected]> |
Date: | Tue, 25 Feb 2014 17:15:17 +0000 |
Ø
Is it a database, driver or CA fix?
There are generic changes to both the database and the CA server. The LANSCE specific beam species tagging require LANSCE
specific mrf timing and device support. Ø
Will it go into a future release? Our requirements here at LANSCE govern our priorities. Our new RF system must be ready for the beginning of the next
run cycle, but we are open to merging our changes in the future as you see fit. Jeff From: Dalesio,
Leo [mailto:[email protected]] That sounds great Jeff. Is it a database, driver or CA fix? Will it go into a future release? Bob From: Hill, Jeff [mailto:[email protected]]
Ø
the event queue does not buffer arrays – it only queues up the pointer to the
Ø
array. If you are reusing the same buffer (as the waveform record does) it may
Ø
also be overwritten if the client is not taking the data fast enough. Ø
We are working on ways to better support very large arrays in EPICS V4 – these
Ø
must be done for us over the next 12 months – but only pieces are done now. We are deploying a fix for this issue at LANSCE which is, in contrast, implemented into V3. Jeff From:
[email protected] [mailto:[email protected]]
On Behalf Of Dalesio, Leo Yes – this is true. Some options: There are some options You could write something in the driver that allocates memory on initialization and puts the arrays in there – point the device support at the buffered data. Disable the digitizer until it is rearmed Look are areaDetector for processing the arrays under the EPICS database Channel Access also does not buffer arrays – it only queues up the pointer to the array. If you are reusing the same buffer (as the waveform record does) it
may also be overwritten if the client is not taking the data fast enough. We are working on ways to better support very large arrays in EPICS V4 – these must be done for us over the next 12 months – but only pieces are done now. Bob From:
[email protected] [mailto:[email protected]]
On Behalf Of Vishnu Patel Hello, I am facing problem in I/O Interrupt for waveform record in the asyn. If the value of waveform record change very fast then some of the samples missing or same sample repeat twice even if before p_interruptInt32Array->callback ()
function the value is scanned properly by driver. But i think the read value is pushed to the callback but it is not handle that much fast in the callback. I checked the code for interruptCallbackInput in devAsynXXXArray.h. In devAsynXXXArray.c dbScanUnlock has been used before scanIoRequest(). Can it create problem for repeating same value? My assumption is as dbScanUnlock and before scanIoRequest() execute, value change and second time triggers interrupt. This result same value for both interrupts. I checked interrupt callback code in devAsynInt32.c where epicsMutexUnlock has been used after scanIoRequest(). Thank you Vishnu
|