The EVM (Event Manager) test bench is a small cluster of PCs and network switches. Primary aim of this setup is the research and development of the EVM, which is responsibility of us, Fermi-MIT EVM group. It is also used as common DAQ test ground for US CMS detector sub-components, like EMU and HCAL.
Picture on the right is the entire test bench (plus, the EMU slice test crate in the middle left). It consists of two support PCs, one dual-CPU node PC used as the EVM, eight single-CPU node PCs used as either RUs or BUs and one MVME-2300 VME board computer running VxWorks used as a dummy GTP (all other PCs run Linux). These node PCs are connected each other via a 16-port Myrinet-1280 switch and a 16-port FastEthernet switch (both are private network). The VME board CPU and the EVM PC have point-to-point Myrinet connection.
Machine names are following. (all in .fnal.gov domain)
If you would like to have an account on the test bench, please contact to Dinker Charak (dinker@fnal.gov) or Ichiro Suzuki (ichiro@fnal.gov).
Following instruction is not yet tested. So, please try it.
There are two ways to compile your XDAQ applications.
If your development involves modifying a part of XDAQ distribution code, or you plan to include your code into a future release of the XDAQ, take the first way. Otherwise, second way is easier and saves disk space. (In the following instructions, Bourne shell syntax is used. If you are using 'csh' variant, use bash or zsh :-)
We assume the name of your application is 'YourApp' in the following example.
# Copy the XDAQ tree and compile core libraries
cmsevm> export PROJECTDIR=~/work/tridas
cmsevm> rm -rf $PROJECTDIR; cp -a /usr/local/tridas $PROJECTDIR
cmsevm> cd $PROJECTDIR/config
cmsevm> ./xdaq_build_new -w 2>&1 | tee log.xdaq
cmsevm> ./xdaq_build_new EventBuilder 2>&1 | tee log.evb
# Make your application directory
cmsevm> cd $PROJECTDIR/daq
cmsevm> mv SampleApp YourApp
cmsevm> vi YourApp/src/linux/x86/Makefile
# change all occurrence of 'SampleApp' or 'sampleapp'
# to appropriate names.
Now, you also change file names
in YourApp/include and YourApp/src/common
These files can be used as a skeleton of your application.
After writing your code, you compile your application into
a shared library.
cmsevm> cd $PROJECTDIR/config cmsevm> ./xdaq_build_new YourApp 2>&1 | tee log.app
Core XDAQ library is already built in /usr/local/tridas.
You need a different make file here.
cmsevm> export PROJECTDIR=/usr/local/tridas
cmsevm> cd work/app
cmsevm> cp -p $PROJECTDIR/daq/SampleApp/{include,src/common}/* .
cmsevm> cp -p $PROJECTDIR/daq/SampleApp/src/linux/x86/Makefile.local Makefile
cmsevm> vi *
cmsevm> make
And, make sure the location of your application shared library
is included in $LD_LIBRARY_PATH
when running xdaq.exe.
First, you start a XDAQ executive from a terminal.
cmsevm> export LD_LIBRARY_PATH=\ /home/foo/work/app:$PROJECTDIR/lib/linux/x86:\ $PROJECTDIR/Auxiliary/xerceslinuxx86/lib cmsevm> $PROJECTDIR/bin/linux/x86/xdaq.exe \ 131.225.52.76 40000 -verbose
Then open anoter terminal and start xdaqWin. It is a GUI to control XDAQ based applications. Using the xdaqWin, you can load an XML configureation file, configure all hosts/applications and run your application.
cmsevm> cd $PROJECTDIR/daq/xdaqwin cmsevm> ./xdaqWin
Read the XML configuration file, sampleapp.xml, from File->Open. Select a host 'http....' and configure it with Command->configure. Then, select the application, SampleApp, and cofigure it. You can also access to the variables in the SampleApp class. Please refer 'HelloWorld' examples in the XDAQ introductry document, 'Getting Started'.
XDAQ control library is a Java library to control XDAQ executives easily.
(Download)
It supports almost all operations xdaqWin can do.
Therefore, you can use this library as a building block for
your own run control, for a test suite driver or for any utility tools.
Let me explain a sample code.
Complete sample code is here.
At first, package name is net.hep.cms.xdaqctl.
You instantiate an XDAQDocument object giving an XML file.
7 import net.hep.cms.xdaqctl.*;
8 import org.w3c.dom.*;
9
10 public class sample
11 {
12 public static void main(String argv[])
13 {
14 String appClass = "TestXctl";
15
16 try {
17 // Create an instance of XDAQDocument reading from
18 // a sample XML configuration file, 'sample.xml'.
19 //
20 XDAQDocument xdaq = new XDAQDocument("sample.xml");
Then, if you use 'auto' target IDs
in your XML configuration file, assign real IDs.
21 xdaq.assignTargetIDs();
Please run a XDAQ executive (xdaq.exe) on an appropriate host.
Now, the system is ready to be booted.
Let's configure the host.
24 System.out.print(xdaq.configureHost());
A configureHost() method will give you a String like
'ConfigureHost: 0: Success'.
The format is <command name>, <host ID> and <status>.
Upon successful request, status is 'Success'.
If not, <faultstring> returned by the XDAQ executive is given.
After successful configureHost() you can command to applications.
To do so, commandApplication() method is used.
33 // Then, configure the application
34 System.out.print(
xdaq.commandApplication("Configure", appClass));
35
36 // 'Enable' the application
37 System.out.print(
xdaq.commandApplication("Enable", appClass));
38
39 // After waiting for 10 seconds, stop it
40 Thread.sleep(10000);
41 System.out.print(
xdaq.commandApplication("Disable", appClass));
The return string of commandApplication() is pretty similar to
that of configureHost() except this has extra <target ID>
field after <host ID>, like
'Configure: 0: 11: Success'.
To select an application, you can specify an application class
like the example above and all applications of that class receive the command.
Or, you can also select it with a integer target ID.
If you don't specify any, the command is issued to all applications.
Parameters of a XDAQ application is accessed
via a 'XDAQParameter' class.
28 XDAQParameter param = xdaq.getParameter(appClass);
29 System.out.println(
"Old number: " + param.getValue("number"));
30 System.out.println(
"New number: " + param.set("number", "7"));
31 param.update();
You get an instance using XDAQDocument:getParameter().
The application is again selected by its class or target ID.
When you specify a class name and there are multiple applications
in the class, the parameter of the first found in the XML file is returned.
You get a value from and set a value to a parameter
within a XDAQParameter instance.
At this point, the modified value stays in the control application.
To reflect the change to a XDAQ executive,
use XDAQParameter:update().
For both XDAQDocument and XDAQParameter classes,
implemented methods may not enough for you to do what you need.
In this case, you can get underlying DOM object and modify it
as you want.
import org.w3c.dom.*;
...
Document xdaqDOM = xdaq.getDOMDocument();
Document paramDOM = param.getDOMParameter();
Finally, this library comes with a set of unit test code. You may want to add methods or modify class behavior eventually. Unit test code helps you debug your modification and ensure no existing methods are affected from that. It also works as a sample code for each class/method.
Complete API reference is here.(not yet ready)
Here are patches I applied to the XDAQ V1.2 release listed in the order to be applied. Items in red are bug fixes. Others are just for my convenience.
I also made a build script,
xdaq_build_new.
(This script requires that the makefile patch listed above was applied.)
It is essentially same as config/*_build scripts except following.
Here is some examples to use the script.
# Print the usage cmsevm> ./xdaq_build_new --help # Compile XDAQ core libraries + xdaqWin cmsevm> ./xdaq_build_new --win # Compile 'EventBuilder' and 'evbdm' packages cmsevm> ./xdaq_build_new EventBuilder evbdm # Arbitrary flags can be given to make # (single long line is wrapped.) cmsevm> ./xdaq_build_new --flag 'SOAP_INCLUDE=-I/usr/include/xercesc' --flag 'SOAP_LDDFLAGS=' --flag 'SOAP_LIB=-lxerces-c' --clean EventBuilder
All files mentioned here is available in this directory.
