cRIO as a hardware platform for Machine Protection.

1. cRIO as a hardware platform for Machine Protection. W. Blokland S. Zhukov

2. Introduction • The Beam Instrumentation Group at the Spallation Neutron Source is responsible to measure aspects such as losses, charge and position of the accelerating particle beam. • Some of these measurements are tied to the Machine Protection System (MPS) and must be able to turn the accelerator off. The requirements can be: • Turn the machine off before the next pulse (SNS: < 15ms) • Turn the machine off within the pulse (SNS: 10-1000µs) • Additional requirements can be: • Use a hardware (analog or digital) solution to implement the abort function • The cRIO platform supports both a Software (Real-Time) and Hardware (FPGA) implementation of Machine Protection Aborts

3. Beam Loss Monitor One unique instrument for use in a test facility. Similar to a standard Beam Loss Monitor but resources to modify existing systems was scarce. cRIO was identified as viable alternative. • RF Test Facility Beam Loss Monitor Specifications • Sample 12 channels at 100kHz • Alarm in 20usec when integrated beam loss is above threshold • Control and read back HV power supplies voltages • Send test pulse to test Photo Multiplier Tubes * CPU, Crate, Power supply, ADC, DAC, DIO

4. Beam Loss Monitor cRIO Not needed anymore, we have at least two ways of running EPICS on cRIO without gateways

5. Beam Loss Monitor software • Three different pieces of hardware but one programming environment: • LabVIEW FPGA (on cRIO backplane) • point-by-point processing of the data such as integration and comparison to threshold, baseline correction, and LED enable • LabVIEW Real-time (in Controller) • Implements the real-time calculations such as Rads/sec (This can also be done on the FPGA if needed for Beam Abort) • LabVIEW for Windows (separate PC) • Implements the gateway to the EPICS-based control system.

6. LabVIEW Programming Environment • Integrated programming environment for both RT and FPGA programming • Single vendor! No dealing with multiple vendors to solve problems. • Same programming constructs for both RT and FPGA • EPICS is supported • FPGA code must be compiled and this takes time: 10 min – 40 minutes sequence loop Only FPGA specific: Access to cRIO Analog In

7. Sequential versus point-by-point The LabVIEW FPGA programming environment brings the FPGA into the same realm as CPU programming!!! - Caveat: FPGA programming increases in complexity when programming in single cycle loops (aka full speed) Sequential processing

8. Sequential versus point-by-point point-by-point (pipelined) processing beam 10 µs acquisition data processing data Transfer To RT First Abort option in 10-20us

9. Beam Loss Monitor Diagram • Impressive: • Adding PMT test feature required minimal code and development time

10. Beam Loss Monitor cRIO BLM IOC CPU with EPICS BLM cRIO BLM Amplifiers HV Power supply RF Cavity Video System PXI crate

11. Beam Loss Monitor VME Rack Abort System Modules VME Controller, Digitizer, Digital IO, Custom Timing Card Custom Analog Card HV modules Power Supply Analog Front-end

12. Scrapers * CPU, Crate, Power supply, ADC, DAC, DIO Thin foils scrapes the beam halo in HEBT of SNS. The scraped particles are collected by collimators. Need an MPS to prevent excessive power being dumped into collimator. There are 2-4 foils per collimator. The secondary electron emission presents itself as current source that is measured. • HEBT Scraper Specifications • Sample 4 channels at 200kHz • Trip the beam in 20usec when integrated beam loss is above threshold for one foil • Trip the beam if 1s average of sum over all foils (for particular collimator) is above threshold (total power on collimator) • Communicate with AFE boards (over serial port, 115kbit/s RS-485) to check amplifier health, HV • The Trips have to be generated by hardware (FPGA) • Since the signal is AC coupled (due to HV bias applied to the foil) alleviate signal droop 12

13. cRIO implementation (under development) • Space saving: 3U per collimator • Modularity: one IOC fails, corresponding scrapers must be retracted, but the other can be used • All sorts of digital correction: baseline, droop etc • 20uS requirement met: is limited by current driver speed 10uS • Communication can be done in FPGA or RT (drag and drop will work) • All sorts of rolling averages (1s)easy to implement

14. Comparison • Sample-by-sample processing fitted requirements very well and got rid of issues such as: • Sequential processing bottlenecks: Waveform acquisition takes 2 ms, then the transfer to slot zero, then processing. This must fit within 16.6msec. Balancing act between digitizing speed, backplane data transfers and CPU processing. FPGA can process data point-by-point without data transfers. • Separate hardware board to perform Abort functions. An analog board with integrator and analog threshold is used to implement an abort within 20 µs. FPGA can set alarm in each 10 µs cycle. • cRIO Hardware integration takes care of low-level drivers • Our projects requirements matched very well with cRIO capabilities and no FPGA hardware knowledge was required • EPICS integration is available • VME approach is standard in accelerators • Custom timing decoding card and software is available • Experienced people • EPICS integration is standard • No special FPGA knowledge required

15. Future • Scrapers 3 IOCs (Feb 2011) • Beam power on Beam Line Dump using cRIO • Replacement of BLM VME hardware? (more fantasy than future)