1 / 10

DCS meeting Feb. 20th, 2001

DCS meeting Feb. 20th, 2001. Subdetector Reports : 1 TGC S. Tarem, N.Lupu 2 RPC Stefano Veneziano 3 MDT Henk Boterenbrood 4 TRT Zbyszek Hajduk 5 Pixel Greg Hallewell 6 Radiation measurements of Interlock Box Martin Imhäuser

shaman
Download Presentation

DCS meeting Feb. 20th, 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DCS meeting Feb. 20th, 2001 Subdetector Reports : 1 TGC S. Tarem, N.Lupu 2 RPC Stefano Veneziano 3 MDT Henk Boterenbrood 4 TRT Zbyszek Hajduk 5 Pixel Greg Hallewell 6 Radiation measurements of Interlock Box Martin Imhäuser 7 Tilecal HV control Helfried Burckhart 8 Radiation measurements of ELMB Hallvard Kvedalen 9 DAC for the ELMB all 10 DCS-DAQ-Comm. DDC: Status and availability Slava Khomoutnikov 11 PVSS Framework Wayne Salter Announcements (H. B.) ELMB production due in March, 250 CHF (10pcs->Mainz +?) DCS workshop NIKHEF ~ Okt.8, 2001

  2. 1 ThinGapChamber S. Tarem, N.Lupu • using ELMBs for monitoring (ADCs, histogramming) and • JTAG configuration of Altera 10K10 via DCS standard control path: • SCADA (PVSS2)-OPC server-CANopen-ELMB-JTAG • works for single data access, problems transmitting long strings • net data rate of 34kbit/s @125kbaud using NiCAN2 interface in PC • complaint: PVSS documentation still available in Austrian language only • ELMB based charge measurement system presented

  3. 2 ResistivePlateChambers Stefano Veneziano Using ELMB along with a Xilinx FPGA for SingleEventUpset recovery: reload FPGA / rewrite flash ROM if data corruption is detected 3 MonitoredDriftTubes Henk Boterenbrood Using full ELMB along with ADC-only ELMB (SPI-connected) for temperature, magnetic field, and frontend electronics monitoring 4 TransitionRadiationTracker Zbyszek Hajduk Temperature monitoring of 7000 electronics boards for fire protection 6 NTCs read out into a single ADC channel, test results (taken with LMB) shown 7 ELMB for Tilecal HV control Example for special algorithms running in an ELMB along with ELMB standard CAN firmware

  4. 5,6 Pixel M.Imhäuser: irradiation tests on interlock box (fast shutdown on breakdown of cooling) G.Hallewell: Pixel cooling flow control. ELMB based with PID algorithm inside ELMB microcontroller PID control loop via compressed air line (~100m) controlling coolant flow via linear valves. Temperature and pressure feedback via ELMB. Control previously done with LMB / BridgeView, now ELMB/PVSS2 long discussion whether PID algorithm can be done in PVSS2 rather than locally in ELMB --> possibly too slow (~ few readings/second!) + standard use of ELMBs (voltage monitor etc.) a total of ~100 ELMBs/Atlas presentation of a highly redundant UPS system

  5. 8 Radiation measurements of ELMB Hallvard Kvedalen -irradiation of ELMB at 66 Gy/h, total of ~ 80Gy 2 ELMBs (different flavours) tested. Standard ELMB (including opto couplers !) survived. However supply current increases by factor of 10 (starting at ~30 Gy) Flash memories turn into ROMs after irradidation (ERASE broken) Measurements with neutrons and protons will follow. Lengthy discussion on interpretation of ATLAS radiation hardness requirements and formulae... 9 Discussion: Digital/Analog converter for ELMB Pixel, TGC, LHC-b require DACs: incompatible requirements in terms of range and type (V vs. I). Conclusion: there may be an external SPI-connected DAC in standard box, if everyone agrees on a common output range.

  6. 10 DDC: Status and availability Slava Khomoutnikov • DAQ-DCS communication: • Messages (eg. alarms) are transmitted from DCS to DAQ (available) • DAQ sends commands to DCS (will be implemented in next release) • release 0.2 scheduled for end of February • DDC runs on red hat linux (v6.1/6.2), tested with PVSS2 on WinNT • complete DDC prototype expected in April, 2001 11 PVSS Framework Wayne Salter PVSS is the (commercial) DCS high level control software package. CERN (JCOP group) is providing a common framework. - purpose of common framework for PVSS and guidelines for code development. (recycling code, coherent system,.....) - hints (never change standard panels...) --> Read the documents at http://itcowww.cern.ch/pvss2/index.htm PVSS seminar March 26/27. Documentation in English available end of March.

  7. ELMB for calorimeter trigger: • Credit card size CAN processor module too large for some of us? • 2 processors, unnecessary? -> firmware update via CAN ! • on-chip low resolution 8-ch ADC • 64-ch muxed ADC 16 bit + 7 bit range unnecessary? -> optional • Digital I/O • SPI, JTAG,I2C ports • External DAC via SPI not for us • No modifications to ELMB envisaged ...... well, we need a modification we need geo. Address based CAN node address !

  8. ELMB for calorimeter trigger: • We want a coherent DCS interface throughout the calorimeter trigger electronics. • ATLAS DCS group takes responsibility for a single access path: ELMB -> CAN/CANopen -> OPC server -> PVSS2 • We are allowed to enter this path anywhere in the middle of the chain if we take responsibility for all software development required. • We presently know about three options: a) RAL Fujitsu design comprising of single-chip CAN controller on processor boards and a bridge located on TCM b) standard 'one size fits all' ELMB daughter board, no crate-based bridge, one separate CAN link required for ~ 1-4 crates (ie. 20-80 ELMBs) c) homegrown ELMB-compatible circuitry on processor main boards (schematics to be provided by ATLAS/DCS)

  9. Considerations for all home-grown flavours of CAN nodes: I'm not an expert, but: We have to decide where to plug into the standard DCS path -> CAN/CANopen -> OPC server -> PVSS2 So as to enter into the OPC server we will probably (does anybody know for sure?) have to speak CANopen. This has some implications: • We need to obtain CANopen libraries for the microcontroller chosen • We have to restrict the CAN node count to 127 per CAN cable segment The OPC server is by definition a PC running a Microsoft operating system and the server software (commercial or CERN), connecting to the physical interfaces (eg. NiCAN) We do not have to go through the OPC server and we (who?) can rather write our own PVSS2 drivers. Discussion, please.....

  10. Whatever CAN controller we choose: We will have to write some PVSS2 high level code. Training on PVSS2 provided by CERN. We will be charged for that invaluable service !

More Related