1. Overview of My Experience With C++
duncan scott

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

3. 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

4. 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

5. 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

6. Example Front Page After Recon.

7. 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

8. 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

9. 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

10. BPM Monitor GUI

11. 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

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

13. 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

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

15. 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

16. 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.

17. 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