Download PPT

24
Unix
Unix
SloCo
Alarms
Data
Histo’s
VME
Evt
Bldr
calorimeters
SCSI
ethernet
AB Highway
Triggerless Data Acquisition and Slow Control
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
A Quick History
The design is 12 years old & was limited by
existing technology
size of WFD/MTDC internal buffers & 9U VME format
cost (including licensing): UNIDAQ, VxWorks OS
Pion Injection
Save 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 Injection
Flash 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
Again
faster (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
Original Muon Injection Configuration
7 MB/s
DLT
Rates measured using UNIDAQ
Depends on evt length and
NOVA buffer size
2 MB/s MXI bus
3 MB/s (DMA)
3-4 MB/s VME backplane
5-11 MB/s (DMA)
Final Muon Injection Configuration
13 MB/s
DLT7000
Replace MXI with Bit3
No daisy-chain.
Pairs of SBS Bit3 from FE EB
20 MB/s Bit3
3-4 MB/s VME backplane
5-11 MB/s (DMA)
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
SLOW CONTROL SYSTEM
DIBBUK VAX
File mount
NMR VAX
socket server
Host Computer
LeCroy
1440 HV
+ controller
File
read
Socket
task
Unidaq
WISH
CAMAC
(SWIC)
Unidaq
WISH
FactoryLink
“Interchange”
Slow Control PC
Expert PC’s
(ladder logic)
Cryo PC
Cryo PLC
Vac PC
Vac PLC
Ladder logic
Det PLC
Inflect PC
Alan-Bradley Data HWY
Inflect PLC
ethernet
T-back PC
pickup electrode
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)
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