evblite::evblite

Name

evblite::evblite -- Encapsulste EVBLite instances

Synopsis


package require evblite

set instance [evblite::evblite name option value...]

$instance configure option value...
set value [$instance cget optname]

$instance start
$instance stop
      

DESCRIPTION

The NSCLDAQ Tcl package evblite provides a snit::type evblite::evblite which creates encapsulations of event builder lite instances. These instances are configured via object options which can be provided either at creation time or using the instance's configure subcommand/method.

evblite instances are given a name either explicitly by the program at instantiation time or assigned an instance name if the special instance name %AUTO% is used at instantiation. Instantiation returns the instance name. The example below shows the creation of two event builder instances, one named evb, the other assigned a name by snit.


set name [evbinstance::evbinstance evb];    # Name is evb.
set name [evbinstance::evbinstance %AUTO%]; # Unique name assigned by snit.
            

Each instance is a command ensemble whose subcommands operate on the instace.

OPTIONS

The following options can be used to configure an evblite instance either at creation time or via the configure subcommand of the instance:

-dt ticks

The value of this option is passed as the --dt option value to the glom stage of the EVBLite pipeline. The value represents the event building coincidence window in units of timestamp ticks.

-nobuild bool

If the boolean value is true, then --nobuild is passed on the glom command line. In this case, glom does not perform event building but just strips the fragment headers from the incoming ringitems.

--timestamp-policy value

The value of this option is passed as the value of the glom --timestamp-policy option. Valid values are earliest, latest and average. The value chosen selects how the timestamps of the events produced by glom are generated from their fragments.

-outsid INT

Provides the value of the source id for fragments emitted by glom (glom's --sourceid option). If not provided, this defaults to 0.

-maxfragments INT

Provides the largest number of fragments that can be grouped together in an event. This protects glom in the event the clock providing the timestamp is not counting. This is the value handed to glom's --maxfragments option. It defaults to 1000.

-inbuffersize INT

Provides the evbtagger's --buffersize parameter. The value is the number of kilobytes of input buffer the evbtagger program allocates. Note that in this case a kilobyte is 1024 bytes. If not provided the default is 1024 which resuls in a megabyte input buffer.

-resetts BOOL

If true, the evbtagger program will reset its idea of the most recent timestamp to zero when it sees a new begin run. If 0, no action is taken on the begin run item. In most cases this should be 1, however if using an XIA system as the data source with Infinity clock enabled, it should be 0.

-insid INT

Provides the default source id to use for input data. There are some NSCLDAQ ring items that, historically, have no source id associated with them. This provides a source id to put in those item's fragment header.

-inring ringname

Mandatory option that provides the name of the ring buffer from which input event fragments are taken. This ringbuffer must already exist. Note it is a name not a URL.

-outring ringname

Mandatory option that provides the name of the output ringbuffer that will receive built events. If this ringbuffer does not exit, it will be created.

METHODS

In addition to the standard configure and cget methods to manipulate instance configuration values, Two methods are important:

start

Starts the event builder pipeline. The event builder pipeline will continue to run until it is stopped. Note that the if the output ring buffer has a producer, it's assumed that the event building pipeline is already running and nothing is done, however the PID of the final element of the pipeline (the ringbuffer producer) is memorized. See stop below.

stop

All of the processes in the event builder pipeline are killed with SIGKILL.

It's worth, at this point, saying a bit more about the start method. If the output ring exists, and has a producer, it's assumed that the producer is the stdintoring process on the end of the event builder pipeline. In that case start will just remember the PID of this producer and not start a new pipeline. Otherwise all the PIDs of the processes in the event buidler pipeline will be memorized.

The SIGKILL will, if start determined there was already a producer for the output ringbuffer, stop that producer (if it has permission to do so). If the remainder of that pipeline is active the next flow of data will destroy it due to the resulting cascade of broken pipes.

Invoking stop without first, at some point, invoking start will fail to stop anything.