CODA 3 Getting Started Notes March 2014 ---------------------------- 1. UNPACKING THE DISTRIBUTION The CODA distribution should be unpacked under a common directory (e.g. /usr/local/coda/3.0). The top level includes the following directory structure: common docs examples extensions Linux Linux-i686 linuxvme Linux-x86_64 src There is a hidden setup script (i.e. /usr/local/coda/3.0/.setup that should not have to be changed other than to provide alternative default directory paths if certain ENV variables are not set. This is the general CODA setup script. It sets paths and environment variables necessary to use CODA. There is an example User setup script (in examples - user_setupcoda_example) that you can copy into your own home directory. It will need to be modified (i.e. hostnames, user specific paths) but it is necessary for setting user specific environment variables. Make sure it is executable as well, or simply imbed the code in your .cshrc . One should note that the User script will actually call the generic script provided in the distribution. 2. SETTING YOUR ENVIRONMENT CODA 3 includes both 32bit (Linux-i686) and 64bit (Linux-x86_64) binaries and libraries as well as JAR files that were built with the jdk version 1.6.0_24 or later. You will need a JAVA runtime (1.6 or 1.7) available that will support this. The provided setup scripts will define the proper PATH for your machine architecture. You must set several environment variables either prior to running them or in the user setup: # Define the CODA distribution directory (for example): setenv CODA /usr/local/coda/3.01 # Define a path to the jdk you want to use (should be /usr if you want the Linux default): setenv JAVA_HOME /group/da/Java/jdk/1.6.0_27/Linux-x86_64/jdk1.6.0_27 # Define the location of the COOL Database directory (for Afecs Run control) setenv COOL_HOME /home/abbottd/coda/cool # Define the name of the COOL Database (EXPID) and User (SESSION) setenv EXPID experiment_0 setenv SESSION davetest JAVA_HOME should be set such that $JAVA_HOME/bin will point to the java bin directory. Then after logging in the user needs only to execute his setup script to initialize the environment for running CODA (i.e. source user_setupcoda_example). 3. SETTING UP the COOL DATABASE CODA 3 replaces the old mSQL database used in 2.6 with a homegrown alternate. It is used to store component definitions and run configuration information. The information stored there is both static as well as dynamic during the operation of any coda components. Everything is stored in flat files in a directory hierarchy with the root defined by $COOL_HOME/$EXPID. The utility used to create and maintain the static information within the COOL database is the Java application called "jcedit". Jcedit is a GUI that allows the user to create new experiment databases within COOL_HOME, Sessions, Components like ROCs EBs ERs etc... as well as different Run Configurations which are combinations of components that define a DAQ system. Once a database is created then at runtime the Run Control "platform" will use it to store dynamic information during DAQ operations. 4. JAVA RUNCONTROL ( The "Platform" ) The main experiment control server that must be running is a JAVA application called the "platform". The Platform contains the intelligent agent framework (Afecs) as well as a CODA messaging (cMsg) server. It can be started up in a shell/window with no arguments (as long as $EXPID has been set). The variable $EXPID defines the name of the platform and no other platform with the same name can be run at the same time. If there is no COOL database setup the Platform will create a default directory structure under $COOL_HOME. This will allow CODA components that are started up to register and become remotely accessible, but until a Run Type is defined with jcedit there is no actual DAQ system to control. In general the Platform should always be running. It is not necessary to kill it. It is effectively a daemon to provide access to the COOL Database. It can be run on any host in the subnet being used for the DAQ systems. All CODA components that register with it do so via multicast discovery. The Platform however does not have to be running prior to starting up individual CODA components. All components will continue to ping for a platform with the correct $EXPID until one is started. Then they will connect automatically. The Run Control GUI is also a JAVA application - "rcgui". It can be run from any host as well, and one can run multiple copies on multiple hosts. It can take several arguments (see the -h option) but none are required. The rcgui is the User interface to the Platform and the way Run Configurations are selected and controlled. From the GUI menus the user can access/change various options, or bring up component messaging browsers etc... If the Platform is ever shutdown (or killed) for some reason, all rcgui and component processes should be able to reconnect with the platform once it is restarted. However if a Run Config is in an active state, it will have to be reset and a new Run will have to be started from scratch. 5. STARTING CODA COMPONENTS If you wish to startup a component interactively (for debugging, monitoring etc...) execute one of the following commands in an xterm window: for a CODA ROC or TS component: % coda_roc -i -n -t ROC % coda_ts -i -n -t TS for a CODA Event Builder (Primary, Secondary or Data Concentrator) % coda_emu_peb % coda_emu_seb % coda_emu_dc for a CODA Event Recorder % coda_emu_er for a CODA Farm Control Supervisor % coda_emu_fcs You can also use the generic CODA Event Management Unit "coda_emu" script by also defining the EMU Type eg % coda_emu PEB or % coda_emu ER Note that ROC and TS components are 32-bit only binaries. They are intended to run on Intel-based VME Single Board computers running a 32-bit Linux operating system. VxWorks-based ROCs are no longer supported under CODA 3. One can run a ROC or TS component on a 64bit Linux OS as long as it also has 32-bit libraries installed on the OS. 6. COMPILING READOUT LISTS for ROCs The directory $CODA/linuxvme contains all the core drivers and libraries that a User will need to create a dynamically loadable "readout list" for the CODA ROC or TS component. Additional libraries for new VME modules and other hardware can be installed ins this directory as needed. Within the "examples" directory are a number of general readout list examples that can be copied and modified as needed. In general the User can copy the whole examples directory to his local home directory and modify the Makefile to complile just the readout lists he needs add new ones. Standard readout lists for CODA 3 are now C, code however there is still support (for a limited time) for the old CRL format. There are example CRL readout lists that are useful for testing and they can be compiled with the Makefile or one can use the "makelist" script as in 2.6: % makelist test_list_v3.crl native (Note that compiled readout list objects are shared object files (ie with .so extension)) ********** DISCLAIMER ********** This is only a rough guide as to how things can/should be done. Contact the DAQ group for more help at coda@jlab.org or check out the DAQ website at https://www.jlab.org/coda