EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  <19971998  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: Problem of monitoring 15,000 channels within EPICS
From: Matthias Clausen DESY -MKS-2/KRYK- <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Wed, 26 Mar 1997 11:20:15 +0100 (MET)
Chris

you might find some information @ CERN they have to solve the same problems for their new 
LHC detectors:

	"[email protected]" 	Fabien Perriollat
	 "[email protected]"	Helfried Burckhart

My approach would be to reduce the data flow at the source. I.e. use local (simple) CAN 
controllers with embedded ADCs to read the voltage and send monitors on change to the IOC. 
The IOC itself could reduce the data flow by setting propper limits to the monitors.
You might also want to combine the readings from one 1HV channel with its readings from 48 
PMTs to one EPICS record which will fire a monitor whenever one of the 48 PMTs changed.
This would lead to about 3'000 records which an IOC can easily handle. Taking into account 
that your readout scan time is really slow you could connect 100 CAN nodes to one CAN 
controller on a dedicated VME CPU (i.e. 162) which can handle four of these. This CPU will 
handle the IO-interrupt and communicate to the main CPU over VME which runs the EPICS 
database. Each of the CAN nodes will handle the readout of 8 HV channel with the 
associated 48 readouts. In this case each readout could keep its own CAN -ID or you could 
combine the 48 readings into one CAN object that you transfer to your dedicated EPICS 
record for the 48 readouts.

Reasonable approach?

Matthias



Navigate by Date:
Prev: Time granularity in archive data streams Matt Bickley
Next: Compilation error in EPICS extension Janet B. Anderson
Index: 1994  1995  1996  <19971998  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: Problem of monitoring 15,000 channels within EPICS Chris Witzig
Next: dm / medm applet? William Lupton
Index: 1994  1995  1996  <19971998  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·