Page History

...

Once the server is started, you can start the client side in the
second the second shell with:

./xtcmonclientexample -p yourname -c clientId

The first parameter that must be given to the client software is the
partition the partition tag. This must exactly match the partition tag
given tag given to the server side software.

The parameter given with the "-c" option is the client ID. If you are
the are the only user, then just give it a value of zero.

Once running the server will keep supplying the client with events
until events until it runs through the file. It will then exit, unless the optional
optional "-l" command line parameter was given. If the looping option is given
on given on the command line, then the server will endlessly repeat the sequence
of sequence of L1Accept (Laser shot) events in the file and will not terminate
until terminate until the process is killed.

Sample output from running the above can be found here.

To write your own monitoring software, all you have to do is subclass the
XtcMonitorClient the XtcMonitorClient class and override the XtcMonitorClient::processDgram()
method  method to supply your own client side processing of the DataGram events
in events in the XTC stream or file supplied by the file server. Below is the example
implemented example implemented by XtcMonClientExample.cc.

...

The returned integer controls whether the method will be called again
with again with more data. If the method returns a non zero value, then it
will it will not be called again. This allows the client to end the interaction
cleanly interaction cleanly if it chooses to do so.

This method is the callback from the client monitoring when it receives
a receives a buffer in the shared memory. The example above uses an XtcIterator
subclass XtcIterator subclass to drill down into the data and label it. You can provide your
own your own functionality there instead.

Building the example will require you to find the appropriate shared libraries
and libraries and include files. The data format definitions and shared memory support are
in are in a package called 'pdsdata'. You can find the data formats in include
files include files in this directory ...

/reg/g/pcds/package/ana/release/pdsdata/

...

Each hutch has a server machine dedicated to recording a copy of the data for use of a
quick a quick turnaround file-based analysis. In the AMO hutch, this machine is named daq-amo-ana01;
other  other hutches have similarly named machines. This machine "spies" on the data acquisition
system acquisition system and records all data it sees, whether or not the data acquisition system is directed
to record them.

Official runs (recorded for offline analysis) will be found at the path
path "/u2/pcds/pds/<hutch>/<expnum>/<expnum>-r<runnum>-s<slice>-c<chunk>.xtc".

Unofficial runs (not recorded for offline analysis) will be found at a
similar a similar path, where <expnum> is "e0", and <runnum> is derived from the date/time and
can and can be found in the DAQ Control message window.

Files have a typical lifetime of ~3 hours on this server. All official runs should be
found be found on the offline file server (/reg/d/psdm/...) by this time.

The "myana" analysis programs (more info) have a command-line paramater "-L" which directs them to
read to read files still open for writing. This changes the behavior to wait for more data when
endwhen end-of-file is reached until the end-of-run marker is encountered.

...