Folks,
Release R7-0 of the synApps mca module is now available. This is from
the release notes at
http://cars9.uchicago.edu/software/epics/mcaReleaseNotes.html
SIS3801 and SIS320 multi-channel scaler support
The SIS3801 and SIS3820 support has been completely rewritten. In
previous releases the driver was "synchronous", meaning that the MCA
records blocked while the arrays were read from the FIFO on the VME
modules. FIFO reads were done with VME program I/O, which can only do
about 1000 32-bit words per ms. This was acceptable if the arrays were
small (e.g. 2048 channels) because it only took a few ms to read each
array. However, some users were beginning to use very large arrays (e.g.
2,000,000 channels). In this case it took several seconds to read each
array. Because the MCA records were synchronous, this blocked execution
of other EPICS records and tasks while reading the hardware. This was
unacceptable, leading to channel access disconnects and other bad
effects.
One way to fix this would be to make the drivers asynchronous, meaning
that device support will do the I/O in a separate thread, and the
records will not block. This is how other slow drivers for the MCA
records work, for example the Canberra AIM and the XIA DXP modules.
However, this approach cannot be used with the SIS drivers because they
must support the EPICS "scaler" record, and the scaler record does not
work properly with asynchronous device suppport.
Instead, the drivers were rewritten so that the FIFO is read out into a
driver buffer in a low-priority background thread. When the MCA records
process they now just read the data from this driver buffer using a
memcpy() call, which is very fast. Furthermore on the 3820 the driver
now reads the FIFO using DMA over the VME bus. This yields a factor of
10 improvement in speed, over 40MB/s, compared to 4MB/s with program
I/O.
The new drivers have excellent performance with very large arrays, and
arrays with more than 10 million elements can now be used if the VME CPU
has sufficient memory. For example, a test was done with the following
configuration:
* SIS3820 module with 512MB of FIFO memory
* MVME 5100 CPU with 512MB of memory
* vxWorks 5.4.2 with Andrew Johnson's BSP with DMA support
* 2 active inputs
* 10,000,000 channels per waveform
* 2 waveform records
* Internal channel advance
* 1 microsecond dwell time
* ReadAll.SCAN = Passive
The theoretical time for this acquisition to complete is 10 seconds. The
following is the output from the EPICS "camonitor" program on a Linux
client looking at the Acquiring PV, and the first 2 channels of each
waveform record:
>camonitor -tc -#2 SIS:3820:mca1 SIS:3820:mca2 SIS:3820:Acquiring
SIS:3820:Acquiring (2011-05-01 11:19:35.050808)
Acquiring
SIS:3820:mca1 (2011-05-01 11:19:46.017134) 2 50 50
SIS:3820:mca2 (2011-05-01 11:19:46.017223) 2 0 0
SIS:3820:Acquiring (2011-05-01 11:19:46.017264) Done
So the time between when acquisition started and when the client
received the data and the Acquiring=Done status was 10.97 seconds. There
is thus less than 1 second of overhead in collecting 2 waveforms of
10,000,000 elements each, which is 80MB of data.
Canberra support
- Added support for windows-x64 by including the 64-bit support files
from WinPcap.
This is the home page:
http://cars9.uchicago.edu/software/epics/mca
This is the latest tar file:
http://cars.uchicago.edu/software/pub/mcaR7-0.tgz
Cheers,
Mark
- Navigate by Date:
- Prev:
Re: Erros running st.cmd Andrew Johnson
- Next:
Steven Banks passed away last night Richard Farnsworth
- 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:
mca R7-0 Mark Rivers
- Next:
EPICS on RTEMS crashing on CA access, due to GNU readline?!? Angus Gratton
- 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
|