ONCS PresentationRun control from user’s perspective

Common ToolboxInterface to RHIC control

C.Witzig

PHENIX Core Week

June 9, 1999

http://www.phenix.bnl.gov/publish/gaius/1999/computing/computing_meeting_june9.ppt

Data Collection Module(DCM)

Data Collection Module(DCM)

Sub-EventBuffer(SEB)

Partition Module(PM)

Data Collection Module(DCM)

Front End Module(FEM)

Front End Module(FEM)

Front End Module(FEM)

Front End Module(FEM)

Assembly &TriggerProcessor (ATP)

Assembly &TriggerProcessor (ATP)

Assembly &TriggerProcessor (ATP)Assembly &Trgger

Processor (ATP)Assembly &Trigger

Processor (ATP)Assembly &Trigger

Processor (ATP)Assembly &TriggerProcessor (ATP)

Assembly &TriggerProcessor (ATP)

Assembly &TriggerProcessor (ATP)

ATM Switch

to RCF

Busy

Global Level 1

Local Level 1Master Timing

Module(MTM)

Granule TimingModule(GTM)

BusyAccept

Timing Fiber

Serial ControlARCNET

Sub-EventBuffer(SEB)

. . .

Software Overview

FEM

FEM

FEM

Arcnet

Sun Workstation

Sun Enterprise 3000

Timing

DCM

GL1

LL1

PPC

PPC

PPC

PPC

SEB

SEB

ATP

ATP

162/167

Anc. System

CustomHardware

VME crates

PC running NTPPC,68kVxWorks

ONCS software

Event Pool

Data Loggers

Sun Workstation / PC Linux

Run Control

Corba

Servers

EPICS clients

Monitoring Monitoring

PC Linux

Subsystem Software

Run Control Considerations

• Present the user with a “standard” (uniform) interface/entry point into the DAQ

• PHENIX partitioning requirement

• Must talk to many distributed processors (VME crates, work stations) by the design of PHENIX DAQ

• There must be complementary ways to send commands

• from within the run control

• for debugging

Current Situation:• Rapid changes in 1008

• Hardware is arriving, user has “special wishes”, quick changes, not everything works in hardware/software

• Reading out individual granules by themselves in standalone mode

• Reading out multiple granules

• Reading out via alternative paths (DCM over VME, over PM, over SEB)

• Current setups include• EMCAL, DC, PC, TEC, BB, GL1, TS

• 2 TM crates, 2 DCM crates, 1 GL1 crate

Current ER Setup at BNL

EMCAL FEM

Arcnet

Sun Workstation

Sun Workstation

DCM

PPC

PPC

Event Pool

Data LoggerRun Control

Corba

Servers

GTM

GLINK

GLINK

Event Server

TCP/IP

Basic concepts (1)

• Run control is a standalone server (process on phoncs0)

• Every user starts its own copy that is characterized by

• a unique arbitrary string ( user input - eg your initials)

• a unique tag (an integer) (handled invisible to the user)

• 2 scripts:

• daq_start.sh bj PBSC.W

• daq_cleanup.sh bj

• daq_start.sh

• checks whether there are not too many run controls running

• builds up the cleanup scripts

• starts the run control server, which reads the configuration files for the granule(s)

• waits for user commands

• daq_cleanup.sh

• executes the cleanup scripts

ASCII based configuration files// //configuration file for PBSC setup in ER//#define IP_PORT 5027

ONCS_GTM, GTM.EMC.W, TMserver10, 0x17000000, … \ $ONLINE_CONFIGURATION/GTM/GTM.EMClaser

ONCS_ROOBJECT, ro1b, daq1bobjmanager,… IP_PORT

ONCS_PAR, par.1b, daq1bobjmanager, … , vme, ro1b

ONCS_FEM2, dcm.pbsc.w0, ….., dsp5, ….ONCS_DSP5, dcm.pbsc.75, ….. Vme, … par.1b

FEM.PBSC, FEM.EMC.W.0, dcm.pbsc.w0, \i: $ARCNET_DATA/jwemal21.hex \i: $ARCNET_DATA/jwemal42.hex

DD_SERVER, dd_server1b, default, EVT_BIN/ndd_event_server, IP_PORT

After the startup….• Run control waits for user commands (next slide)

• All components of DAQ system are brought into data taking mode through the following sequence:

– initialisation (done once at the beginning)

– download (could be done several times)

• Between initialisation and download the user normally configures the components, e.g. change GTM mode bit file, selects the files to download into the FEM etc

• If the download is successful the run control is “ready”

• start_run - end_run commands

• start_run has the following parameters:– run number

– event_limit, volume limit, time_limit [all optional]

Example:• select FEM and GTM file• download•start_run for 1000 events - end_run•select another FEM and GTM file•download•start_run…..

Internally ...• Run control server has the following objects:

• one partition object

• one control object for every type of DAQ component (process_stage)

– FEMstage controls all FEMs and reflects their state

– DCMstage controls all DCMs and reflects their state

• Every component has a proxy object that knows what to do when (eg at download time). [The process stage knows nothing about the internals of the component]

How to send commands to the run control??

• 3 modes of operation:

• in “local” mode run control accepts commands from standard input

• in “remote” mode run control accepts commands from remote processes (same host, another host)

• from a “GUI”

• Development of Java GUI just started

What’s next?

• GUI for single run control

• Coordination of several run controls running in parallel

• a common server that keeps track of GL1 configuration and which granules belong to which granules

• Integration of SEB/ATPs into the run control

• Integration of subsystem monitoring programs into the real time environment

• Databases [longer term item - post ER]

Toolbox news: running meansThe most-often used tool for gain monitoring of your detector is the running mean value. You compute the running mean of some laser response, or a test pulse, which is supposed to be stable over time.

Mathematically accurate running means are simple to do but true memory hogs.

We introduce two classes, fullRunningMean and pseudoRunningMean, which allow you to compute many running mean values in parallel, no frills. Full is the “memory hog” accurate running mean, while pseudoRunningMean is the faster and smaller pseudo value.

For gain monitoring where the values don’t change much normally (20, 30% at most), the pseudo is a very good approximation of the real running mean at a fraction of cost and time of the “real thing”.

RunningMean *bbmean_p = new pseudoRunningMean(128,50); // 128 channels, 50 values deep RunningMean *bbmean_f = new fullRunningMean(128,50); // 128 channels, 50 values deep

“pseudo” and “full” both inherit from and abstract class “RunningMean” so you can easily compare “full” to “pseudo” and see if pseudo is good enough.

Running mean example (PBSC)

RunningMean *pm = new pseudoRunningMean(144,50); // 144 channels, 50 values deep

for (i=0; i<500; i++) {

if (! ( evt = it->getNextEvent() ) ) break; Packet *p = evt->getPacket(8002); // get pbsc packet 8002 if (p) { p->fillIntArray(array, 144, &nw); // get all 144 values delete p; pm->Add(array); // update the running means } delete evt; } for (j=0; j<144; j++ ) cout << “running mean “ << j << “ “ << pm->getMean(j);

Runs as ROOT macro, as shared lib, standalone.rn = ( ro * (d-1)+ x ) /d

d = running mean depthrn new mean valuero old mean valuex new reading

Algorithm:

How good is it? For “realistic” gain values with typical drifts, the deviation of “pseudo” from “full” is less than 0.5%. You should test what you get though. (The experiment at CERN used this for all PM-based detectors routinely).

Title:c1.epsCreator:ROOT Version 2.21/08Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

The upper plot is the values over time

middle: real running mean,

lower: deviation in %

Response to a “jump”, extreme case

Title:pseudo-full2.epsCreator:ROOT Version 2.21/08Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

Upper: The values over time, with the “jump”

middle: response of the “full” running mean over time

lower: response of the pseudo running mean over time

How good is it? For “realistic” gain values with typical drifts, the deviation of “pseudo” from “full” is less than 0.5%. You should test what you get though. (The experiment at CERN used this for all PM-based detectors routinely).

Title:c1.epsCreator:ROOT Version 2.21/08Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

The upper plot is the values over time

middle: real running mean,

lower: deviation in %

Example (some random numbers)Title:

c1.epsCreator:ROOT Version 2.21/08Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

When the “fill depth” is reached, is scrolls to the left.

Looks like a real polygraph…

rGraphsOften you want to see a value change over time, such as

luminosity over timeevents/second over timescaler values over timetemperature over timeDow Jones index over time...

rGraph gives you a simple “strip chart” of a value you want to look at over time.

Example (some random numbers)Title:

c1.epsCreator:ROOT Version 2.21/08Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

When the “fill depth” is reached, is scrolls to the left.

Looks like a real polygraph…