Overview of My Experience With C++ duncan scott

Contents Why C++? Fermilab Tomoscope Application Design VELA BPM Monitor VELA Magnets app

Tomography And Related Diagnostics In Synchrotrons Why C++ ? Spent a 18 months writing a successful Longitudinal Phase Space Tomography programme at Fermilab Tomography And Related Diagnostics In Synchrotrons Everyone in my group used c / c++ (particle physicists) Fermilab Accelerator Controls Network, library, ACNET Very mature 30+ years of development Written in c++ CERN Root had all the GUI, visualisation and Analysis tools needed After initial pain I came to really enjoy working with c++ found it very powerful (ultimately) very rewarding

Setting up Tools Initial set-up can be painful Installing Root Integrated Development Environment CodeBlocks, text editor linking to libraries (ACNET, EPICS, Root, vxi11 etc.) Linux: makefiles Windows things c++ compiler Compiler differences etc. Compiler Pre-Processor Commands etc. Parallel, optimising, Learning the language In some sense once you’ve learnt one language you’ve learnt them all Debugging Valgrind, etc. Planning your application

GUI Interface: Pop-Up Windows, Expert Panels Front Page Layout Colour Schemes Configure Tomo- graphy Expert Pre-Processing DAQ Configuration Load / Save / Apply Set-ups

Example Front Page After Recon.

Application Design This is a huge rabbit hole of potential time wasting Really need to know and understand the systems you want to control and how they work before jumping in I have managed to get reasonable solution for magnets / BPMs After trying with screens I stopped Go back and learn the systems and try and form a better plan TARDIS DAQ and pre-processing Block Diagram

EPICS & VELA On return to DL started using some of the techniques I’d learnt for VELA Include one EPICS header file #include <cadef.h> Add some EPICS directories to search path in makefile Learn some new functions ca_search, ca_get, ca_put, ca_create_subscription Create some simple programmes Simple programs for learning Planning for more complex applications

BPM Global Definitions BPM monitor Design GUI Widgets BPM Choice, SA Values, Num shots Histograms Emit signals from widgets BPM Global Definitions All ‘offline Data’ Controller Signal Handler from GUI EPICS Interface Holds all BPM Objects Callback Functions update BPM Obj Set SA Start monitors (e.g. get 50 shots) DATA OBJECT Talks to Interface Holds raw data to be plotted

BPM Monitor GUI

BPM interface 6 BPM objects hold all info about each BPM Monitor structs are passed to each callback to allow update of bpm Objects and switches Easy to add more parameters if required

VELA Magnet Controller Linked to EPICS database Monitors Read / Set Values PSU status Set, Switch off / on Degauss Load / Save files

Magnet Global Definitions Magnet Monitor Design GUI Widgets Magnet, values PSU, Status Emit signals from widgets Magnet Global Definitions EPICS Interface Holds all Magnet Objects Callback Functions update Obj 4 Basic Functions Switch on / off Set Current Set and Wait / Timeout Read Current Intricacies of different magnet types, negative currents, etc, hidden from user code Master Controller Signal Handler from GUI Magnet Controller

VELA Magnet Interface Holds a ‘magnetObject’ for each magnet Contains all info. (30+ items (!) )

Monitoring Read, Set and PSU state are continuously monitored magnetObject are passed to callback functions through a pointer to monitorStruct Any parameter can be easily added

Why two controllers? The magnet controller can be used in other programmes E.g. an emittance measurement app. Will require, screen capture screen movers laser shutter magnet controller Longer term Goal have set of libraries that can control all the parts of the machine we are interested that can combined as needed.

Summary I was strongly encouraged to start working with c++ There was much initial pain, Learning the Root libraries enabled me to do all the GUI / data analysis / visualisation I needed for free and open source, good forums Writing hardware classes requires much thought knowledge of how parameters / hardware will develop to minimize refactoring I (hope) I have a good basic design on which to build larger applications Global class holds all offline info Epics interfaces with separate controllers Hardware objects hold all possible info. Monitor structs hold all info to handle call-backs, data update etc. Master controller and GUI