DAQ and Slow Control from a subdetector point of view

1. DAQ and Slow Control from a subdetector point of view • 1/09/2009 • M.Incagli - INFN Pisa • (with contributions from F.Pilo)

2. Part 1:sending commands to the detector

3. LUSS (and previous) tests • In LUSS tests performed in april-june 2009, but also in previous tests (test beams, cosmic rays,...), a set of tools have been developed by each subdetector to setup, control and modify the status of the apparatus • These tools depend upon the interface (EPPCAN, JMDC, ...) and the set of base routines (pcamsw, DAQlib, ...) used to talk with the detector

4. Different experts from subdetectors have written several versions of specialized code used during the tests • For AMS Test Beam, and for Data Taking, these codes must be rewritten, or at least adapted, using a common environment (=“common base libraries”) • These libraries must be well defined and documented (work in large part already done by several people)

5. DSP code • First job for subdetectors is to check that all DSP functions are correctely implemented • All documentation in http://ams.cern.ch/AMS/DAQsoft/Welcome.html must be checked and validated by subdetectors (who ckecks JLV1?): major work done by subds these last months

6. Commands must be sent to subdetectors: • choose the path (HRDL, 1553, ...) • choose the node, e.g. EDR-0-0-A (NODE_ADR as defined in “AMS-02 Command and Data Handling. Interface Control Document”) • build and send the command using: • DAQlib : set_JINF_... , get_JINF_... , write_FLASH , ... • AMSWlib : RX and TX commands -> toAMSW(...) routine Not the scope of this meeting Values already defined Main topic of this meeting

7. DAQlib • All routines that send AMSwire blocks to nodes must be in this library. Is this a correct statement? • If this is true, then: • are all necessary routines in the library? • is the library documented? • if a new routine is written for a subdetector, who is responsible of testing and inserting it in the official library?

8. Example: sdprord • To read ECAL parameters in configuration file (e.g. HV settings) and compare them with loaded values, the procedure sdprord, corresponding to Data Type 0x14, is defined • No corresponding function exists in DAQlib, so F.P. has written his own version for ECAL

9. Part 2:modifying parameters

10. Configuration files • Parameters can be modified temporarely with a command to the node (e.g. trigger threshold for ECAL -> command to EDR with new DAC value ) • However to make this modification permanent, a new configuration file must be loaded to the node (EDR, JINF, …): • write a new configuration file • load it into the node

11. Questions onconfiguration files • Is this the procedure that will be used in flight? • Is this documented? Yes, see link in previous slide • Is a common tool to prepare configuration files foreseen? • Problems in writing “large” data blocks through 1553 ?

12. Part 3:checking parameters

13. Stability of parameters • How do you check that parameters (e.g. trigger thresholds) have not changed? • What actions are taken if a parameter is different wrt configuration file?

14. Automatic procedures • (Here I will not refer to safety procedures or to temperature control!) • Parameters (eg node status) must be read automatically; (almost) no commands from ground to ISS during normal operation • What checks are automatically done by JMDC? • What checks are done offline based on output from Qlist?

15. JMDC vs Qlist • JMDC commands are (can be) related to current run, while Qlist commands are asynchronous • Example: online check of the “synchronization block”, as done during LUSS tests, can be done only by JMDC

16. Summary (=open questions) • Content of DAQlib library: how can subdetectors contribute? • How to write and send configuration files? • Automatic procedures to check hardware status: JMDC vs Qlist • Other issues exist (e.g. hrdl vs 1553, decoding data blocks to write monitoring tasks,…); questions for another meeting!