The Germanium Detector Liquid N2 Autofill Control System

T.P.Morrison

28th July 1989

The philosophy of the new computer controlled autofill system is one which is intended to make it possible to ensure that the cryostats of a large variable number ( 70) of germanium detectors on the new array at Daresbury get filled at defined times and that the correct human intervention happens when necessary. For the large number of detectors foreseen, this will have to be done in a way which allows sensible presentational sub-division into groups of detectors. Such high hopes would be rather more difficult to achieve using the previous NIM modules, would be physically large and cumbersome and more expensive.

1 Hardware Details

Space in a 39u high rack will be shared by the computer crate, disc drive unit, valve and sensor interface units, warning LED panels, and fans. A nearby terminal will provide user communication with the functions of the system and a cable connection, which may later be changed into an ethernet connection, will provide remote access from other terminals and computers. It will also be possible for a user to assess the instantaneous state of valves and other features by observing the indicator LED’s on the front panels of some of the units. The computer crate will contain the following items:

1) A processor card with 2Mbytes of memory- PME68-22
2) A 6 port serial interface card     - PME-SIO-1
3) Connector panels for 8 serial ports
4) Analogue to digital converter cards- XVME-560
5) Relay output cards                 - XVME-260
6) TTL input/output cards             - XVME-240
7) All necessary power supplies etc.

The disc drive unit will contain a 50Mbyte hard disc drive, a 3.5inch floppy disc drive, the interface cards for the drives and their power supplies.

The sensor and solenoid valve interface units are being designed and built at York University. They will contain all the necessary electronics to condition the signals from the sensors before they go to the ADC cards and will also contain conditioning circuitry to put the signals from the relay output cards into a suitable form for the solenoid valves to be operated. This will include LED’s to indicate ’vital signs’ and switches to allow manual override. They will be connected to the VME cards with short lengths of ribbon cable. Connections to the solenoid valves require cables carrying mains voltages to be routed from the rear. These will be available in groups of eight and six will be for normal connection to the primary valves of 6 detectors. One is intended to give control over a manifold shutoff valve to provide a fail-safe in case of other valves freezing. The eighth is for use as a spare channel or some could be programmed to provide power to alarm systems. Connections from the sensors will first go to small sockets in some convenient place near the exhaust points and from these panels of sockets, they will be carried by ribbon cable to the sensor interface electronics.

2 Software Philosophy

An OS9 operating system and C compiler have been bought to prepare software at Liverpool University. OS9 is similar to UNIX, allowing multi-tasking and multi-user access. Program modules can be kept in memory when not in use to remove unnecessary disc access. A terminal emulator program called EMU has been already been written to provide terminal access from the autofill computer to the network via a connection between a PAD port and one of the 68-22 serial ports. This terminal emulator can also provide a simple but effective means of file transfer and software to implement this under GEC OS4000 also exists. Hence files can be moved from the GEC to OS9 or vice-versa.

The autofill system will use a series of 3 specially written OS9 drivers. These will communicate with the 3 special VME cards used by the autofill system. One will return ADC readings from the XVME-560, another will allow software to write to the XVME- 260 relay output cards for closing or opening the valves and a third will allow one to write to the XVME-240 TTL i/o cards to switch error indicator LED’s on or off. The user need have no knowledge of this as this software will just be the way that the rest of the system talks to these input/output devices in a neat way.

Initial values which define the relationship between detectors, valves, sensors, and VME cards will be read from disc by a master task at startup time. This configuration file can be edited and will provide each detector with a name to make it easy to identify. Such data can be grouped into named chunks such as ’Front detectors’ or ’Manifolds 1 to 4’ for example. The master task will also read the required filling times for all detectors from its configuration file. It will provide a visual display of the system state and interactive communication with the user as well. Such interaction will be simplified by the subdivision of the detectors into logical chunks as already mentioned.

Pertinent variables and configuration data will all be held in a memory module which will also be available to further tasks which will be responsible for updating the database from the ADC cards or updating the output cards from information placed in the data base. These tasks will have been created by the master task at startup time. A summary of the software requirements is as follows:

1) Three device drivers for XVME560, XVME260 and XVME240.
2) An input task to put sensor readings into database.
3) An output task to put values from database to the relay modules.
4) An output task to put error status values to the LED display.
5) A master task to control the above and do user input and output.