Skeleton Class Reference

Inheritance diagram for Skeleton:

Public Member Functions
virtual void	addCommands (CTCLInterpreter *pInterp)
virtual void	SetupRunVariables (CTCLInterpreter *pInterp)
virtual void	SetupStateVariables (CTCLInterpreter *pInterp)
virtual void	SetupReadout (CExperiment *pExperiment)
virtual void	SetupScalers (CExperiment *pExperiment)
virtual void	addCommands (CTCLInterpreter *pInterp)
virtual void	SetupRunVariables (CTCLInterpreter *pInterp)
virtual void	SetupStateVariables (CTCLInterpreter *pInterp)
virtual void	SetupReadout (CExperiment *pExperiment)
virtual void	SetupScalers (CExperiment *pExperiment)

Member Function Documentation

void Skeleton::addCommands ( CTCLInterpreter *  pInterp )

virtual

Add new Tcl Commands here. See the CTCLObjectProcessor class. You can create new command by deriving a subclass from this abstract base class. The base class will automatically register itself with the interpreter. If you have some procedural commands you registered with Tcl_CreateCommand or Tcl_CreateObjCommand, you can obtain the raw interpreter (Tcl_Interp*) of a CTCLInterpreter by calling its getInterp() member.

Parameters

pInterp

- Pointer to the CTCLInterpreter object that encapsulates the Tcl_Interp* of our main interpreter.

void Skeleton::SetupReadout ( CExperiment *  pExperiment )

virtual

Setup the Readout This function must define the trigger as well as the response of the program to triggers. A trigger is an object that describes when an event happens. Triggers are objects derived from CEventTrigger

Note

This function is incompatible with the pre 10.0 software in that for the 10.0 software, there was a default trigger that did useful stuff. The default trigger for this version is a NULL trigger (a trigger that never happens. You must create a trigger object and register it with the experiment object via its EstablishTrigger member funtion else you'll never get any events.

The following are trigger classes you can use:

• CNullTrigger - never fires. This is the default.
• CTimedTrigger - Really intended for scaler triggers, but maybe there's an application you can think of for a periodic event trigger.
• CTestTrigger - Always true. That's intended for my use, but you're welcome to use it if you want a really high event rate.
• CV262Trigger - Uses the CAEN V262 as a trigger module.
• CV977Trigger - Uses the CAEN V977 as a trigger module.

Parameters

pExperiment

- Pointer to the experiment object.

void Skeleton::SetupRunVariables ( CTCLInterpreter *  pInterp )

virtual

Setup run variables: A run variable is a Tcl variable whose value is periodically written to to the output event stream. Run variables are intended to monitor things that can change in the middle of a run. One use of a run variable is to monitor control system values. A helper process can watch a set of control system variables, and issue set commands to the production readout program via its Tcl server component. Those run variables then get logged to the event stream.

Note that the base class may create run variables so see the comments in the function body about where to add code:

See also:

SetupStateVariables

Parameters

pInterp

- pointer to the TCL interpreter.

void Skeleton::SetupScalers ( CExperiment *  pExperiment )

virtual

Very likely you will want some scalers read out. This is done by creating scalers and adding them to the CExperiment object's list of scalers via a call to that object's AddScalerModule.

By default, the scalers are read periodically every few seconds. The interval between scaler readouts is defined by the Tcl variable frequency.

You may replace this default trigger by creating a CEventTrigger derived object and passing it to the experiment's setScalerTrigger member function.

Parameters

pExperiment

- Pointer to the experiment object.

void Skeleton::SetupStateVariables ( CTCLInterpreter *  pInterp )

virtual

Setup state variables: A state variable is a Tcl variable whose value is logged whenever the run transitions to active. While the run is not halted, state variables are write protected. State variables are intended to log a property of the run. Examples of state variables created by the production readout framework are run and title which hold the run number, and the title.

Note that the base class may create state variables so see the comments in the function body about where to add code:

See also

SetupRunVariables

Parameters

pInterp

- Pointer to the tcl interpreter.

---

The documentation for this class was generated from the following files:

• readout/Skeleton.h
• readout/Skeleton.cpp