| 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 2025 | 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 2025 |
| <== 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