GSI - BEA Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Spill Counter & I/O-Controller ======

TH-Notiz-2011-03

SD

** Walterkisten Concept Brainstorming
 
** 24.01.2011
	
Author(s): T. Hoffmann	Tel: 2318

**
History**

21.01.2011	1. Version
24.01.2011	2. Version (HBr)

**
Requirement**

For SIS-18 and the HEBT six stand-alone 3HE boxes, called ‘Walterkisten’, are currently installed at the BD electronic room. They are used to control the IFCs for devices like ionisation chambers and SEMs plus the self test option for scintillators. For future enhancements and to prevent off-time due to broken parts a replacement is foreseen. All control features of the existing boxes must be available in a new design. Only the data acquisition – pulse counter part - shall be skipped as this will be done by the Ablass/Lassie system. 
Besides slow and simple I/O RW settings for device id, polarity and gas flow the requirement for the range setting needs careful consideration. The ranges have to be switched within a cycle pause (Fig. 1). The exact duration of that pause is so far not known, but is assumed to be between 50 and 100ms for a cycle rate of 4 Hz, SIS-18. The new I/O system should be able to do that in real-time to assure the right range setting for every virtual accelerator. The new range values may be changed at any time by the operator/user, the final set to the hardware has to be triggered with a SIS-18 machine event, foreseen is #55.
 
{{:projects:spill_cnt_io_ctrl:image002.jpg?direct|SIS cycle}}

**Figure 1:** Scheme of a SIS-18 super-cycle with pauses to be used for event triggered range switching. 

In addition other users of I/O shall have their own I/O module ready to fit in the new crate. This can be the timing for the BPM preamplifiers (DPX). 



**
IFC3 Features**

The IFC3 provides the following functionality, which has to be addressed:

1. Ranges (R/W)

3 Ranges: 2 Bits

Range 	/RANGE1 	/RANGE2 
100 nA 	0 	        0 
1 μA 	1 	        0 
10 μA 	1 	        1 
		
		

The FESA server sends packages to the I/O controller in e.g. following format:
Channdeladdress-VirtAcc-Range for one or all channels.
On the next given event plus a delay time the ranges are written to the channels.
That means, on every cycle the range is written for all channels. This can lead to a higher use of the IFC relays and to a shorter lifetime. The advantage is the possibility to use many devices on different VirtAccs in parallel.
As the range can differ between the VirtAccs (max 16), the FPGA needs a 16 channel array for 16 different range settings per device. To create adequate memory space the total amount of connected devices is required. This can be given by a constant from FESA or somehow detected in the crate via RS485 bus.


2. Test (W)

Activation of the test signal creates internal current (1% full scale). This signal shall be released after an accelerator event (e.g. #55) for a fixed duration. The length of the test signal is required. For the period the bit is set, the channel must be read out via LASSIE or ABLASS and its actual range must be read out.
This functionality could also be realized as a self test for all channels at the same time. 
Regardless, a machine event with a delay to initiate the self test and the duration have to be settable by the user.
It must be clear, that a self test can not be performed, while the range setting is in progress.

3. Overload bit (R)

The usage in unclear -> H. Reeg
The overload bit is dynamically on the IFC. When the overload goes down, also the bit is off. So the FPGA from the I/O controller shall record the bit for a cycle and add it to the status information for that cycle. It gives a flag for a general overload somewhere in the cycle.
In addition, the dynamic overload bit should be available on the front-panel as a NIM signal. This allows for future applications like gating the counter signals.

4. Device ID (R)

Three data lines are used to define the device type.
Device type; 0: no I/F, 1: CD1010/CD1011, 2: CD1020, 3: IFC, 4: IFC3

5. Gasflow (R)

Two floating lines used to transmit the status of the IC/MWPC gas flow (ok, not ok)

6. Polarity (R/W)

One line is used to set the polarity (minus is default). Discussion is required to do that manually on the I/O module or via software. As FAIR is a large area campus, the usage of a software setting is maybe suitable.

7. Pulse

Two differential lines are used to transmit the data pulses. There is no feature for the I/O. The signals will be converted to NIM and are fed into the DAQ via LEMO outputs. 




Required amount of channels


The following gives a rough estimate of the required channels:

IFCs (16 bit per channel):
•	IC: 		25
•	SEM:		25
•	Collimators:	25
•	Reserve:	25 minimum

DPX amplifiers for SIS18 (8 bit per channel)
•	12

Scintillators (self test)
•	30



**Requirements**

Parameters

Following parameters must be fulfilled:

•	Modular setup
•	Connector panel with 
o	16 - 32 Cannon Sub-D connectors (15 or 9 pin)
(15 for IFC,  8 for DPX)
o	8 or 16 BNC connectors for scintillator self test
o	Preferable at backside of the crate
•	IFC controller board
o	3 front-panel outputs per channel for data pulses (NIM level)
(only for GSI IFC version, at FAIR signal is maybe separated from I/O)
o	1 front-panel output per channel for overflow signal (NIM level)
o	Full implementation of the IFC functionality described below
•	Scintillator control board
o	Self test for scintillators
o	3 front-panel outputs per channel for data pulses (NIM level)
(only for GSI IFC version, FAIR signal is maybe separated)
•	DPX amplifier control board
•	Crate master controller module(s)
o	Functionality may be separated into different modules
o	Ethernet interface
o	Machine timing (GSI and later FAIR, White Rabbit)
o	Machine event triggered settings (Real Time)
o	All existing properties must be available to clients
o	FESA compatible / controlled. Options are:
	Intelligent controller running FESA directly (i.e. SCU)
	TCP/IP connection to FESA class running on standard PC server

Settings

The following hardware fields must be accessible:

•	Range 				(bits, R/W)
•	Range event 			(short, R/W)
•	Range delay in ms		 	(short, R/W)
•	Test on/off				(bit, R/W)
•	Test duration in ms 		(short, R/W)
•	Test event 				(short, R/W)
•	Test delay in ms 			(short, R/W)
•	Polarity 				(bit, R/W)
•	 Overload latched status 		(bit, R)
if set, overload has happened sometime during the spill
•	Device ID 				(bits, R)
•	Gas flow 				(bit, R)
•	Version Code FPGA 		(short, R)

In the list above ‘bit(s)’ means one or more bits, which may be grouped with other fields for transport. ‘short’ means 16 bit unsigned integers.
The FESA class will be the interface between the clients of the control system and the hardware. The FESA class will read and write these fields and publish them to clients via FESA properties. The FESA class must comply with the ‘Guideline for designing FESA equipment software at the GSI and the FAIR facility’. This guideline is currently being prepared (contact: Harald Bräuning).

Operational issues

Clients like ABLASS/LASSIE required knowledge about range settings, self test request etc. for calibration and display purposes. If these clients do not have this information, wrong data will be presented to the users with unforeseen consequences. Automatic synchronization between the actual hardware settings and the clients is thus essential. 

On the FESA level, this can easily be accomplished. Using the ‘Composition’ or ‘Association’ mechanism of FESA 3.0 (or equipment links and direct RDA communication in FESA 2.10) can be notified of any changes in the settings (of the controlling FESA class) and even send new settings.

To assure synchronization between the actual hardware (FPGA etc.) and the controlling FESA class is more difficult but equally essential. The following concepts for realization are suggested:

•	FESA runs on an intelligent controller (i.e. SCU) in the crate and controls the RS485 bus directly. 
•	the TCP/IP to RS485 interface allows only one single client (FESA class) to connect. 
o	Clients must be able to determine a loss of connection and reconnect.
o	Controller may publish or clients may poll status information (overload bit, etc).
•	The TCP/IP to RS485 interface maintains a list of registered clients and publishes any changes in the hardware settings as well as status information.
o	UDP could be used (simpler to implement? But reception of packet not guaranteed.)
o	SNMP protocol for data transfer?


Further open questions

The following design parameters need still to be discussed:

•	Should a soft reset of I/O controller set failsafe values or the last values send by the FESA class
•	Remote Management of crate (Power Supplies, On/Off, Temperature)
•	List of connected channels obtainable by clients (DB? FESA device instances?)
•	Self test for single or all channels at the same time? VirtAcc dependend?



**Possible solution**

So far a stand-alone solution for the SIS-18 collimator system is available. This non-intelligent modular system is accessed via a Lantronix TCP/IP to RS485 interface. The modules in the crate are all addressed by this RS485 bus. The bus can be enhanced by daisy chain to max. 64 x 8 channels which would be more then required.
This crate can be used as a base for a new development.  To fulfill the RT requirements a new FPGA board can be added to the bus. This FPGA decodes GSI timing and gets new settings and commands via the Ethernet. The new values can be set on a given GSI timing trigger.
With this FPGA solution also the self-test function can be implemented. The detector signals are converted to NIM and fed into ABLASS or LASSIE. 
Another module for the scintillator self-test, if not realized on the FPGA board, has to be developed. The interface to the control system is a FESA class installed on a server in the network. 



**Replacement of control system functionality**

To replace the requirements for online transmission and ‘Zintilla’ of the old ‘Walterkistensystem’ the following solution is proposed.

Online Transmission: 

As FESA in connection with the middleware can access all devices and their properties within the network, a dedicated FESA class for the transformer S09DT_ML has to be developed. In addition the scaler signals for all experimental signals are available via LASSIE. A GUI can combine these values for every cycle for logging and evaluation. The exact specification for that has to be discussed also with the controls department.

Zintilla:

Zintilla and LASSIE (ABLASS) are almost the same. Missing features of Zintilla in LASSIE have to be realized (eg calibration factor). 
 

There is also a possible solution to use existing control system software with FESA by integration of the dedicated gateway, which already exists at GSI (Cosylab development).

**Specification Keywords**

White Rabbit:
requires GbE with fast serial I/O FPGA (minimum Spartan 6) and SFP output port.


The device model of the old GSI version is found here:
http://bel.gsi.de/mk/di/gm_di.html
GSI - BEA Wiki

User Tools

Site Tools

Page Tools
