Page History

...

The core online monitoring can be specialized by supplying plug-in modules containing user code. Two types of These modules can be added - either analysis modules for generating additional plots or filter modules for selecting a subset of
(1) compute variables to be used in the monitoring GUI,
(2) generate additional plots to be displayed, and
(3) provide a filtering decision for events to be used by in the monitoring. 

The steps to creating a user module are:

1. Copy /reg/g/pcds/package/amiuser to your area

   Code Block
   cp -rf /reg/g/pcds/package/amiuser ~/.

   
   
2. Edit the ExampleAnalysis.{hh,cc} files or ExampleFilter.{hh,cc} files

   Code Block
   Code Block
   cd ~/amiuser; gedit ExampleAnalysis.cc

   
   
3. Build the libamiuser.so and libamiuser_filter.so libraries library

   Code Block
   make all

   
   
4. Copy the libamiuser.so and libamiuser_filter.so to your experiment's home area

   Code Block
   cp libamiuser.so ~amoopr/. cp libamiuser_filter.so ~amoopr/.

   \\\\

The "~amoopr/libamiuser.so" plug-in module is specified explicitly in the "-L" command-line option for the monitoring executable that appears in /reg/g/pcds/dist/pds/amo/scripts/amo.cnf, for example.  It is possible to specify a comma separated list of libraries in the "-L" option to include more than one plug-in module. Similarly, the "~amoopr/libamiuser_filter.so"

The plug-in module is specified in the "-F" command-line option.The plug-in modules will be picked up the next time modules will be picked up the next time the DAQ system is restarted. The new plots will appear in the "User" selection. Image Removed
These instructions also appear in the amiuser/README file.

The ExampleAnalysis UserModule class contains several member functions that must be implemented:

• clear() - unregister plots and disable analysis
• create() - register plots and enable analysis
• reset(featurecache) - called prior to a new configuration with a reference to the cache of event variables
• clock(timestamp) - called once for each event or configuration
• configure(detectorid, datatype, data*) - called for each detector datum in the configuration
• event(detectorid, datatype, data*) - called for each detector datum in the event
• analyzeaccept() - called once after all 'event()' callbacks have completed
  ; returns a filter decision
• name() - returns the module name
  

The 'detectorid' arguments are of the form Pds::Src and may be cast for comparison against detector identities such as Pds::DetInfo or BLD identities such as Pds::BldInfo (Pds:: classes from pdsdata/xtc package).  The 'datatype' arguments are of the form Pds::TypeId which is a class denoting the data format (image, waveform, etc., and version, also from pdsdata/xtc package).  The 'data*' arguments are pointers to the configuration or event data (from pdsdata/<type> package). For the 'configure' callbacks with relevant data, the data should be copied. For the 'event' callbacks, the pointers may simply be copied and referenced when the 'analyze' function is called.

...

The new plots will appear in the 'User' a section of the online monitoring with a separate tab title matching the 'name()' method of the module. By default a separate page is created for each added plot. Multiple plots may appear in the same tab if their titles end in the same string - '#' followed by a page title; for example, two plots titled 'First energy plot#Energy' and 'Second energy plot#Energy' will appear on a page titled 'Energy' with the individual titles 'First energy plot' and 'Second energy plot'. This should allow users to add a few additional plots using operations not supported by the generic monitoring.

The ExampleFilter class contains several member functions that must be implemented:

• name() - return a string name for the module
• clock(timestamp) - called once for each event or configuration
• configure(detectorid, datatype, data*) - called for each detector datum in the configuration
• event(detectorid, datatype, data*) - called for each detector datum in the event
• accept() - return a filter decision
  

The filter module names will module names will also appear in the 'Event Filters' section of the online monitoring for selection as global filters, and the any added variable names will also appear in the 'Env' section of the monitoring for use as filters on individual inputs to other plots. This should allow users to improve the generic monitoring for infrequent or specially classified events. It is also a testbed for how users may be able to reduce recorded data volumes, if so desired.

...