NSCL DAQ Software Documentation
PrevNext

controlscript

Name

controlscript -- Virtual slow controls module to execute TCL scripts

Synopsis

controlscript name [-controllertype type] [-initscript path] [-updatescript path] [-monitorscript path] [-monitorproc proc]

DESCRIPTION

The controlscript package provides a snit::type called controlscript that can be used to source Tcl scripts as a result of slow control requests. The idea is that the user can create an instance of the snit::type and then register it as a Module with type=tcl. The behavior can be useful you have special Tcl code that might need to execute on the server side during a run. It is also a means for the using some of the low-level Tcl drivers provided by the CCUSBReadout and VMUSBReadout.

The only required option is -controllertype, whose argument specifies whether the driver will be handling VMUSB or CCUSB requests. The rest of the options are truly optional.

OPTIONS

-controllertype type

The -controllertype parameter is the only required option. Its argument, type, must be either "vmusb" or "ccusb". If neither is provided, an error will occur.

-initscript path

The -initscript option specifies the path to a Tcl script that will be evaluated in the global scope. It is executed at the startup of the slow controls server (i.e. at program startup) and any time the user calls the init from within the Readout program it is associated with. If this option is not provided, it will be ignored.

While the script executes, the Globals::aController variable will refer to the VMUSB or CCUSB object managed by the Readout program. The object is either a cvmusb::CVMUSBusb or cccusb::CCCUSBusb object and has methods provided by the cvmusb or cccusb package, respectively.

-updatescript path

The -updatescript option specifies the path to a Tcl script that will be evaluated in the global scope. It is executed whenever an update request is received for the associated slow-controls module. If this option is not provided, it will be ignored.

While the script executes, the Globals::aController variable will refer to the VMUSB or CCUSB object managed by the Readout program. The object is either a cvmusb::CVMUSBusb or cccusb::CCCUSBusb object and has methods provided by the cvmusb or cccusb package, respectively.

-monitorscript path

The -monitorscript option specifies the path to a Tcl script that will be evaluated in the global scope. It is only meaningful in the context of VMUSBReadout. In this script, you should add stack commands to the "Globals::aReadoutList" object, which is a CVMUSBReadout object. The commands that are added to the stack will be executed periodically during the run and the resulting data will be processed by the proc identified in the -monitorproc option. This will be executed on at program startup. If this option is not provided, it will be ignored.

While the script executes, the Globals::aReadoutList variable will refer to the VMUSB or CCUSB object managed by the Readout program. It can be manipulated using the methods provided in the cvmusbreadoutlist or cccusbreadoutlist package.

-monitorproc proc

The -monitorproc option specifies a proc that will be used to parse the data generated by the commands added in the script passed as an argument to the -monitorscript option. It should parse the byte data and then return the number of bytes that it processed.

EXAMPLE

Example 1. An example usage in VMUSBReadout

Consider that you are running VMUSBReadout and need to execute some code contained in a file myScript.tcl at the startup of the program. After the initial program startup, you do not require it to be executed again unless you choose to do so via an init command. In this case, you would want to use the controlscript. This should go in your ctlscript and it might look something like: 


        lappend auto_path [file join $::env(DAQROOT) TclLibs] (1)
        lappend auto_path $::env(DAQLIB)

        package require cvmusb    
        package require cvmusbreadoutlist   
        package require controlscript                         (2)
        
        controlscript _myScript -controllertype vmusb         (3)
        _myScript configure -initscript [file join /path to myScript.tcl]

        Module create tcl myScript                            (4)
        Module config myScript -ensemble _myScript
(1)
The first two rows ensure that the cvmusb and controlscript package can be found. This assumes that the DAQROOT and DAQLIB environment variables point to the NSCLDAQ installation of you choosing.
(2)
Here we need to require the packages that might be used. The cvmusb and cvmusbreadoutlist packages are necessary in order to manipulate the Globals::aController or Globals::aReadoutList objects. We also need to require the controlscript package so that we can use it.
(3)
An instance of the controlscript snit::type is instantiated. It is told that it is dealing with the VMUSB device and also that the script it is to source is located at /path/to/myScript.tcl.
(4)
Finally we need to register a tcl module to the slow controls server that will call the controlscript object we just created. It will repsond to slow-control requests sent to the module named myScript.

Your myScript.tcl file might look something like this if it were to write 1 to a register in some module (address=0xa2020100) using A32 single data access (0x09) and then verify that the write succeeded. 


        set ctlr $::Globals::aController

        # write, read, and then check the value
        $ctlr vmeWrite16 0xa2020100 0x09 1
        set newValue [$ctlr vmeRead16 0xa2020100 0x09]

        if {$newValue != 1} {
          puts "ERROR! Write did not successfully set the value in the module"
        }
PrevHomeNext
VMUSB VME accessUpreadoutscript