1 / 8

Triggerless Data Acquisition and Slow Control

Triggerless Data Acquisition and Slow Control. 24 calorimeters. MXI-bus. ethernet. Unix SloCo Alarms. Unix Data Histo’s. VME Evt Bldr. AB Highway. SCSI. tape. Front-end VMEcrates. Slow Control (Allen-Bradley, PC, Vax). Data Acquisition (VME, CAMAC, Fastbus).

drea
Download Presentation

Triggerless Data Acquisition and Slow Control

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. Triggerless Data Acquisition and Slow Control 24 calorimeters MXI-bus ethernet Unix SloCo Alarms Unix Data Histo’s VME Evt Bldr AB Highway SCSI tape Front-end VMEcrates Slow Control (Allen-Bradley, PC, Vax) Data Acquisition (VME, CAMAC, Fastbus) • High Instantaneous rates (6 MHz / detector) Buffered Front-end electronics • 30 msec between Fills Local CPU’s in Front-end VME • High total data rate (6 Mbyte/sec) Evt Builder CPU concatenates and writes directly to DLT tape during 2 sec cycle

  2. A Quick History The design is 12 years old & was limited byexisting technology size of WFD/MTDC internal buffers & 9U VME format cost (including licensing): UNIDAQ, VxWorks OS Pion InjectionSave all 8 spills in local WFD/MTDC buffer – read out between cycles directly to evt bldr Surprises: Flash & narrow pulses increased data size to limit Each MTDC had 3 Calo’s, noisy FSD data, random & derandomTDR claims 10,666 e’s/station can be stored, but buffer full by 1820 e’s/station Signal/noise = 1/250 Muon InjectionFlash down, but gating pushes earlier (noise = 250kB/fill) Buffer to CPU memory between fills (need 7 MB/s to do it in time) Upgrade: Evt builder MVME167 (33 MHz, 8 MB RAM) Pentium (100 MHz, 64MB RAM)CPU’s in each FE crate, DMA transfers across backplane Surprises: MXI clock handling incompatible with MVME167 clock WFD’s don’t reset, buffer overflows & wrap around Corrupt WFD buffer memory length register Upgrade: Replace MXI daisy-chain with SBS Bit3 pairs Againfaster (20 MB/s and in parallel) Write to SBS dual port memory in between fills (more memory) Upgrade to DLT 7000 (13 MB/s tape writing speed) Improve error handling e.g. drop out modules that don’t reset

  3. Original Muon Injection Configuration 7 MB/sDLT Rates measured using UNIDAQ Depends on evt length and NOVA buffer size 2 MB/s MXI bus3 MB/s (DMA) 3-4 MB/s VME backplane5-11 MB/s (DMA)

  4. Final Muon Injection Configuration 13 MB/sDLT7000 Replace MXI with Bit3 No daisy-chain. Pairs of SBS Bit3 from FE EB 20 MB/s Bit3 3-4 MB/s VME backplane5-11 MB/s (DMA)

  5. For the Future… Choices • Hardware is in good shape with headroom If we needed to take data with current system, it could be done Only require faster Front End CPU’s and evaluate tape drive • or • Go to new WFD’s  6U. Easiest change would be to make memory large enough to take full spill and send it to evt bldr only between spills. Then we wouldn’t even have to replace the CPU’s. • Could revisit data compaction in the FE CPU’s to improve throughput • UNIDAQ is no longer supported • However, UNIDAQ is also embedded in the Slow Control system • UNIDAQ chosen because it worked in both VxWorks and Unix and we needed VxWorks for the fastest CPU’s that were available then. We chose dedicated VME interconnect because CPU+ethernet was not powerful enough a decade ago. • With modern processors, and if timescale is right (can we move MuLan system to BNL?) it makes sense to move to MIDAS

  6. SLOW CONTROL SYSTEM Host Computer DIBBUK VAX File mount LeCroy 1440 HV + controller File read CAMAC(SWIC) NMR VAX socket server Sockettask UnidaqWISH Slow Control PC UnidaqWISH FactoryLink“Interchange” Expert PC’s (ladder logic) Cryo PC Cryo PLC Ladder logic Vac PC Vac PLC Det PLC T-back PCpickup electrode Inflect PLC Inflect PC ethernet Alan-Bradley Data HWY

  7. Quick History Vision: Integrated database, alarm and control system Reality: The expert systems became independent Cryo, vac, etc FactoryLink thus became less important The most useful application ended up being the Traceback The alarm system became redundant (and thus annoying) (except for NMR & HV ) A complete database was written, but never used many important details (e.g. the quads) ended going directly into the DAQ stream FactoryLink SQL was proprietary – effort had to be made to create MySQL files for a relational database Without obvious interest, this was not completed. Useful programs appeared to be standalone (e.g. the HV Program)

  8. Points for discussion Is there a use for a Database? If so Finish the MySQL interface and restore ethernet to Cryo, etc or Write it to DAQ stream Is there a use for the Alarm Page? If so Activate it, set proper limits, and insist on its being run in the background. Do we continue to use the LeCroy HV1440? If so Stop griping about how slow it is or abandon overhead of database if not Find/build a different controller Do we stay with UNIDAQ and FactoryLink? if not A lot of work for someone

More Related