STAR Hardware Controls

1. STAR Hardware Controls Michael Cherney

2. STAR • Solenoid Tracker At RHIC • Focus is hadronic physics • Gold-Gold collisions (100 GeV/c/A) • Up to 5000 particles per event

3. Brookhaven National Laboratory

4. The Brookhaven Accelerators STAR

5. The STAR Detector

6. The STAR Facility The detector can be rolled in and out of the interaction region.

7. STAR in the Assembly Building

8. Side View of STAR

9. Controls Planning Studies • CERN experiments • Fermilab experiences • CEBAF facility • Advanced Light Source • Advanced Photon Scource • Industrial Systems • Power Company • Railroad

10. Proposed STAR Controls • Integrated system • Hardware controls • Run control • Online • Logging • Messaging • Alarms • User Interfaces

11. Actual End Product • Stand-alone hardware controls • Reason: System Test (1995) • Hardware Controls was ready for system test • Many staff changes in the early days of Online • Provisional Run Control and Data Acquisition were used • Hardware controls established by the time Online became a reality

12. System Requirements • Easily understood user-interface • Operators “fly in” for shift • Robust • Documentation • Graphical Databases • Plan for maintenance • Limit number of interfaces and field buses • Multi-site development • Student training

13. Data Acquisition

14. Access

15. Standardized Access to Front End Electronics • HDLC • Used by TPC, SVT, and EMC • Can readout and insert control parameters • Can readout and insert data • GPIB

16. On the platform

17. Overview • 16000 channels monitored • 25000 projected for final system • EPICS-based • Experimental Physics and Industrial Controls System

18. Timeline • Design started in 1991 • Software started in 1993 • System test in 1995 • First beam in 1999 • originally planned for 1997 • first physics in 2000 • upgrades in progress

19. The First Collisions (July 2000)

20. Manpower • About 20 years (full time equivalent) to date • About 5 additional years projected • Significant student participation • One post-doc

21. Student Participation

22. EPICS • Toolkit • Developed primarily by: • Los Alamos National Laboratory • Argonne National Laboratory • primarily for accelerator control

23. Why EPICS? • EPICS existed • Good support • Good user base • Basic development tools • Mastered in a day by a good programmer • Mastered in a few days by a new student • Students proficient in all tools in a few months • Only the best students become developers • Professionals used for these tasks where possible

24. Architecture • Input / Output Controllers (IOC’s) • VME processors (167, 162, 147) • on platform or in DAQ room • User Interfaces • Sun workstations • in control room • Independent Subsystems • can operate independently • or as a single system

25. Data Flow Other TPC Subsystems HDLC STAR Hardware Controls TPC FEE C++ CDEV STAR Trigger Accelerator STAR Magnet Online DAQ

26. Controls System • User Interface • Database • Real Time Code • Alarm Handler • Archiver

27. User Interface • Standard Tools - MEDM • Buttons, Slide Bars, Text Boxes, ... • Color-coded • Green - operating in safe region • Yellow - operating with warning • Red - operating outside safe region • White - invalid data (transmission error)

28. TPC Top Level

29. VME Crate Control

30. Drift Voltage Controls

31. Compatibility of Hardware and Software • EPICS records used for all data • EPICS records used for control where possible • Some real-time code was required • Some situations precluded the use of EPICS for control • RHIC systems • TPC gas system

32. TPC Gas System

33. Database • Standard Tools - GDCT • Graphical tool for database display • Devices can be hardware or software • Analog input, Calculation, Fanout, ... • Creates and shows links • Has “fill-ins” for devices • Can be done in text version • intended for arrays of non-interacting records

34. Graphical Database

35. Real-Time Code • Available programmers found it difficult to think graphically for complex tasks • Sequencer in EPICS • C (and C++) code • Weak Link • Little documentation • Flow of program seldom clear • Difficult to maintain

36. Anode High Voltage Controls

37. Alarm Handler • Tree Structure • subsystems can be moved in and out • Color-coded according to status • also coded alphabetically • Requires constant updating • everything in • no false alarms

39. Archive • Hardware controls archive • 2000 parameters • web accessible • Experiment online database • 800 parameters • stored with run information • Data Stream • 20 parameters • stored with event information

41. Standardization • User Interfaces • Naming • Hardware Interfaces • Documentation • Safety Requirements • Failsafe outside of Hardware Controls

42. More Compatibility Issues • Subsystems needed to factor in cost of software development for unsupported hardware • Favors use of same interface • Favors use of single specialized field bus • Inventory of monitored devices obtained early and updated yearly • Great benefit in identifying need for new software and in redirecting efforts in less labor intensive ways

43. Major Constraints • Mission • Hardware Costs • Political Considerations • Available Software • High Turnover in Technically Qualified Personnel

44. Other Observations • Programmers need to work with end users as well as hardware developers. • Documentation is essential, but hard to obtain • Standardization is worth enforcing. • An early inventory enables identification of common tasks, places where enforcement of standardization is needed.

45. Reliability and Response • Very Stable • Less than 2% of dead time was related to hardware controls • Startup • Hardware/Driver failures • Error recovery for new (STAR specific) records • Advantage of collaborative development