Required Functions of the TASCA Control System

Return to main document: Return Top

  1. Interlock generation
    1. The monitoring of interlock conditions will be performed on an FPGA target to be detemerministic and fast.
    2. One output interlock signal, TTL level, is generated if the valid range of at least one process variable is exceeded. [NEW COMMENT JUN2012 (JPO):] I do not agree. The control system should be more inteligent than this. E.g. if a noise pulse is encountered in the Macro Pulse an interlock should not immediately be genereated, but trigger a "possible trouble condition". Target temperature and avarage beam intensity should be checked - if either is close to their safe limits then an interlock is immediately generated. On the other hand, if they both are well below limits we can afford to defer the interlock to after the next macropuls - if this is ok then it probably was noise. If it also is high then we generate and interlock. There is a lot of "Artificial Intelligence" (AI) which can be built into the FPGA which probably will be able to take care of more than 90% (even 99%) of the interlocks currently (E119 run) needing a manual respons. See separate sub-document for more on TASCA AI
      1. Additional 8 TTL interlock signals are provided for external systems.
    3. The state of the interlock signal depends on the following process variables:
      1. Macro pulse
        1. Macro pulse frequency
          The frequency must be less than 50Hz.
        2. Macro pulse width
          The width of the macro pulse must be greater than 0,2ms and greater than width limit configured by user.
      2. Trafo currents of DT2 & DT3
        1. The electrical currents must be derived from 8MHz signal in combination with range signals signals.
        2. The current is monitored for interlock conditions
          1. Fast IL: Current during macro pulse -> Period measurement
          2. Slow IL: Averaged pulse current, average time is one MP(<8ms).
        3. Refer to the FPGA implementation of TASCA Beam Monitor.
      3. Detector rates
        Monitor upper limit of
        1. DSSSD Detector rate
        2. Rutherford detector rate
      4. Target temperature, analog value must be monitored for upper limit
      5. EVR 1&2
        Refer to the FPGA implementation of TASCA Beam Monitor.
      6. Per target segment
        1. Monitor range of Rutherford rate/DT3 current.
      7. Interlocks from external systems
        A logical OR of all binary external interlocks is calculated.
        Vaccum System Relais
        Gas System Relais
        Target Wheel TTL level
        Magnet TTL
        FSV (X8) Relais
        FSV (Unilac) Relais
        HV5/SV3/4 Valves Relais
        Rutherford TTL
        Veto Relais
        Hydrogen Relais
        Manual TTL
        External TTL
    4. Valid ranges and Limits are read from configuration file at startup of programm.
    5. Valid ranges and Limits are sent to FPGA at startup and on change.
  2. Monitoring of fast signals and interlock status
    1. The monitoring of fast signals and rates will be performed on an FPGA target to be detemerministic and fast enough.
    2. Derived process variables will be transferred to a host system for data logging and user interface with an update rate on 1 Hz.
    3. Process variables are published as Shared Variables
      1. Process variables are logged to the Citadel realtime database.
      2. Alarm limits are monitored and logged by the Shared Variable engine.
  3. External devices
    1. Configuration parameters are read from configuration file at startup of programm.
    2. Configuration parameters are sent to external devices at startup and on change.
    3. All external devices are periodically queried for device status.
    4. Process variables are mapped to Shared Variables are used as interface for the user interface.
      1. Process variables are logged to the Citadel realtime database.
      2. Alarm limits are monitored and logged by the Shared Variable engine.
    5. Device layer
      1. Simple VI's are used to configure and monitor external devices, or
      2. Proposal: DSC Custom-IO-Server are used to configure and monitor external devices.
  4. Data logging
    1. Data items to be logged: To be defined!
      1. If ASCII format is desired, somebody has to define it.
      2. Write data to TDSM format. Advantage: Data items can have describing meta data.
      3. Proposal: Log all data to DSC (Citadel) realtime database.
        1. Data can be exported to ASCII from the historical database on request.
        2. Histical database could be evaluated directly using DIAdem.
    2. Data format: To be defined!
    3. Data should be logged to separate directories for different experiment runs.

-- JonPetterOmtvedt - 19 Jun 2012
Topic revision: r1 - 2012-06-19, JonPetterOmtvedt
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)