Proposal for a New Unified Beam Control & Monitoring Program

The current solution with two beam control/monitoring programs is not optimal and difficult for the users (and programmers). Several functions like e.g. beam intensity safety is duplicated quite unnecessarily. For the future I (JPO) suggest that we merge the two beam programs into one and also include the monitoring/safety of the pyrometer (Oct. 2011). Post the TASCA workshop in October 2011 it was deceided that the Control system should be upgraded and a task force was created to deal with this. The group has meet and corresponded frequently during Nov. and Dec. 2011. Several modifications and changes to the suggestions below has been proposes (but not updated to the wiki...). It would be much better if everybody could write their suggestions and comments directly on the wiki (JPO comment 21st Dec 2011)!

After a video conference 12th December 2011 it was deceided to make a complete list of all parameters involved in controlling TASCA. The list should indicate how each parameter should be sampled (by FPGA, NODAL, analog input, RS-232/484, etc.), needed sampling frequency, needed logging frequency, etc. The list is implemented as table on the Wiki here: TASCAParameterList.

The following principles are suggested:

• All "fast stuff" should be done by the FPGA. This includes analysing the individual macro pulses.
• Triggering of safety tresholds with respect to instant values of macro pulse structure and intensity should be done by the FPGA (i.e. independent of main system (Windows OS), but safety limits should be entered through main system, which will download it to the FPGA.
• The main program should monitor NODAL values, as they can not be read by the FPGA.
• Detector rate should be measured by the FPGA, which also monitor safety limits.
• The FPGA analysis each macro pulse. If certain (critical) conditions are met (e.g. a single pulse having unusual high intensity or a "peak"), the pulse is stored in a dedicated buffer and flagged for the main program to warn the user.
• The FPGA stores each macro pulse in a buffer which can be read (and displayed) by the main program upon user request.
• The main program reads temperature from the pyrometer, but the pyrometer hardware safety limit signal is feed to the FPGA and prosessed in the same way as in the current Pyrometer program (is this really necessary?).
• The main program should produce two log files:
  1. One with an update frequency of e.g. once per minute writes the all parameters (beam intensity, beam integrals, target temparature, trafo readings, faraday cup readings, TASCA gas-flow and pressure, vacuum readings, etc.).
  2. One based on user driven events (engage chopper, start beam integral measurement, change paramer values, etc.) and trigger conditions (safety limits breached, etc.).

-- JonPetterOmtvedt - 05 Oct 2011