\documentstyle[a4,psfig,12pt]{article} %\setlength{\textwidth}{6.375 true in} \setlength{\textwidth}{6.000 true in} \setlength{\textheight}{655 pt} %\pagestyle{empty} \renewcommand{\thefootnote}{\fnsymbol{footnote}} \newcommand{\cc }{$^{12}$C} \newcommand{\oo }{$^{16}$O} \newcommand{\mg }{$^{24}$Mg} \newcommand{\be }{$^{8}$Be} \newcommand{\neon }{$^{20}$Ne} \newcommand{\he }{$^{4}$He} \newcommand{\al }{$\alpha $} \newcommand{\degree }{$^\circ $} \newcommand{\micron }{$\mu $m} \begin{document} \setlength{\unitlength}{1cm} \noindent \begin{picture}(0,0) \put(0,2.5){\makebox(0,0)[l]{CH/Tech/92/06}} %% Reference number of document \end{picture} \noindent \begin{minipage}[t]{10cm} \fbox{ \parbox[t]{6.5cm}{ {\large {\bf Update}}\\[2mm] Data Acquisition }}\\[7mm] \makebox[2.5cm][l]{Author:} Brian Fulton\\[2mm] \makebox[2.5cm][l]{Date:} 19 May 1992\\[2mm] \end{minipage} \hfill \raisebox{-2.5cm}{ \psfig{figure=char-encap.ps,height=3cm}}\\[2mm] \noindent Distribution: \parbox[t]{12cm}{ WNC,NMC,PVD,BRF,RAH,JSL,VP,WDMR,GT,DLW\\ }\\[2mm] \begin{center} \begin{tabular}{l@{\hspace*{14cm}}l} \hline ~ & ~ \\ \hline \end{tabular} ~\\[1cm] \end{center} \begin{center} {\large {\bf Computing, Data Acquisition and Control}}\\ {\bf Report of Meeting of Subgroup at Daresbury\\ 13 May 1992} \\[1cm] \end{center} Present: Paul Drumm, Dick Hunt, Brian Fulton and Vic Pucknell.\\[1mm] The meeting was held to summarise the position on data acquisition and online experimental control. As a result of the discussion on data acquisition a number of distinct phases on the data acquisition were identified which are outlined below. On the control side, the intended strategies were established which are summarised at the end of this document. \section{Data Acquisition} \centerline{{\bf Phase 0}} The first phase involves the change-over from the existing GEC computer network to the replacement VME system. This is based on an 88000 MVME187A Motorola processor board running an OS4000 emulation (GEC call it the 4300 series). The board is in a small portable VME crate, with an interface board (SCSI, ethernet and RS--232), two 140Mb disc boards and a CAMAC interface board (two slots remain free in the crate). There is an exabyte drive, system console and SUN workstation running off the interface, and network access is possible. In the final system we will need a laserprinter and a large disc for spectrum storage. Vic reported that the system is now running with the exception of the CAMAC driver. This needs some software which will be started in July and should only take a few weeks. At present the system is running the emulator code ported directly in from the existing R, C and A machines - no recompilation was needed. The longer term plan is to replace the cpu intensive bits of code with native mode code (there is no problem of mixing native and emulator code), but this will not be attempted until the system is running and we can see where the bottlenecks are. One software change needed immediately is to extend the sort software to uncode events with more than 128 channels (there was no problem writing the events to tape, only in the online sorting and display). \hfill \fbox{ACTION: Vic}\\[1mm] This phase 0 system will be available in August. At that time Vic will assemble a second system for Dick to use at Oxford on the data acquisition hardware development. This system will also act as a backup. Sometime later this year we will use the system in place of the GEC's in a run on the NSF.\\[2mm] \centerline{{\bf Phase 1}} This phase of the development involves a change in the readout process to make use of the opportunities available with the move to VME. The function of the existing Daresbury Read and Store Module (RSM) will be shared between the current cache module (LeCroy 2375) and a link to a memory unit in the VME crate, and a Starburst will be put into the CAMAC crate to augment the event readout. Code in the Starburst will enable it to read the non-FERA modules over CAMAC and install them in the LeCroy Cache module as is presently done by the RSM. In addition, the Starburst will also read the event header and hit words from the Event Controller and write them into the cache memory. It will then instruct the Cache to write out event buffers on the FERA port into a High Speed Memory unit (HSM 8170) in the VME crate. The HSM module is made by CSE and is also being used on the EUROGAM project. This development will need software changes in two areas - to download code into the Starburst to set it running for the particular setup and to read data buffers from the HSM rather than the RSM. The readout phase will be greatly improved as the transfer of buffers will be from the HSM in VME rather than across the CAMAC serial highway. This will remove the current bottleneck in data rates and should allow a far higher event rate to be achieved. It is hoped that Phase 1 might be available for testing in February 1993. It will be used as soon as it is available for experiments on the NSF, and would also be the form of the system which we might port with us for overseas experiments during the period between NSF closure (April 1993) and startup of the new array at Strasbourg (early 1994). \centerline{{\bf Phase 2}} The work in this phase is much more extensive and has been outlined in a previous document from Dick Hunt. In brief, the amplifiers will be modified to include a charge-to-time chip, and the current CAMAC TDC and ADC's replaced with a multi-hit TDC. The pattern registers could be replaced by a LeCroy 2375 data stack combined with a single time channel on the TDCs to time the data within a specific event period. This might be simplified into a single time channel for each telescope which would receive an OR of all pileup signals from associated amplifiers. This change not only provides energy and timing information for each channel at a low cost, but also means all the units are now in FERA so removing the need for mixed CAMAC / FERA readout. The TDC modules will be grouped 4 to a crate, with a Cache and Starburst controlling each group. These will then read into the HSM as previously. However, the TDC modules do not produce their data in the same format as the present modules, and some processing will be necessary to reconstruct the data in the current Daresbury format for storage on tape. Part of this function will be done in the Starburst, but in addition a separate processor in the VME crate will be needed which will modify the contents of the HSM before the data buffers are read out. Initially the code in the Starburst and VME processor will be written to produce an identical data structure to the current Daresbury format, ensuring the existing setup and replay software will work. However, it is recognised that for larger numbers of channels, and the different modules in the new system, this may not be optimum. Further development of the code in the Starburst and VME processor will be possible to improve performance, and perhaps undertake some rudimentary front end processing. It is estimated that rates of up to 1Mbyte/sec may be needed (roughly a factor of ten up on present). Vic reported two schemes being developed for EUROGAM which would help here --- data compression units on the storage stream or writing to more than one exabyte in parallel. It is planned to have the full phase 2 scheme ready for the beginning of 1994 (anticipated start up date for the new array at Strasbourg).\\[2mm] \section{Experimental Control} Two separate areas requiring control have been identified --- the gas system for the detectors and the electronics modules (high voltage supplies and amplifiers). Several principles were established: \begin{enumerate} \item everything would have hands on capability (i.e. knobs and buttons) as well as the computer control; \item the two areas had to be linked (e.g. there shouldn't be bias on detectors if the gas system wasn't in the correct state) and also had to be linked to the outside world (chamber pressure, beamline vacuum etc); \item the users would prefer not to have to interact with too many different systems (and the fewer we had to cart about the better); \item the system had to have local intelligence so that it could cope with potentially dangerous situations without need for user intervention or links to remote processors. \end{enumerate} The gas system is likely to be based around a VME crate since there is already experience of this with existing systems at Daresbury. Paul Drumm outlined the initial thoughts on this. The control for amplifiers and bias supplies would be arranged over a standard serial connection RS--485 (similar to RS--232). Each cluster of amplifiers (16 have been suggested) would have its local processor which would be programmed to recognise and act on a particular message within a serial stream. These cluster control cpu's would also be capable of handling power up / down situations and fault situations independant of the main controller. Both could be controlled by a processor running in a local VME crate (``local'' in the sense of sitting by the equipment). User control would be from a terminal which could be any distance away (RS--232 link in cable to the processor). The crate would have to be close to the gas system controller, but the electronics modules could be remote as the link was a simple RS--232 cable connection. Paul Drum agreed to think further about this area. This latter discussion raised the question of the location of various parts of the system. The present (Daresbury) arrangement means the electronics is readily accessible to the user, but requires many analogue cables between the experiment and the control room. The alternative is to site the VME at the experiment in which case a simple ethernet connection from the SUN to the VME crate is all that is needed (although exabyte tapes would be by the experiment as well). This matter needed some further thought.\\[2mm] Brian Fulton 14.5.92 \end{document}