User Reference:Operator Module Scripting

From BCI2000 Wiki
Revision as of 18:27, 24 May 2012 by Jhill (talk | contribs)
Jump to navigation Jump to search

Operator scripts automate actions that the otherwise would be performed by the user, e.g. starting or suspending system operation. Scripts may be contained in script files, or given immediately in the operator module's preferences dialog. There is also an option to specify scripts from the command line when starting the operator module. When using the BCI2000Shell, or the Operator Library from your own application, you may execute scripts at any time.

In addition, the operator scripting language may be used to control an operator module over a telnet connection.

Syntax

Command separation. Scripts consist of sequences of the commands listed below. A command must be terminated with either a newline, or a semicolon (;). This allows to put multiple commands into one line, separated by semicolon characters. Commands are case-insensitive, variables and values may be case-sensitive, depending on context.

Comments. Lines starting with a '#' character are ignored. Such lines may be used to hold comments. In addition, when any of the first two lines of a script contains "#!" (the Unix shell invocation sequence), it will be ignored. In conjunction with BCI2000Shell, this may be used to write Operator scripts that may be treated as executables.

Escaping. In order to resolve ambiguity about command arguments that contain white space, they must be included in double quotes, or the white space must be encoded in URL-fashion, e.g. %20 instead of a space character. Similarly, when an argument contains a semicolon (;), it must be included in double quotes, or the semicolon must be encoded in URL-fashion, i.e. as %3B. Also, "$" characters indicate command substitution, so they should be encoded as %24 if substitution is not desired.

Substitution. When part of a command is enclosed with ${...}, this subexpression will be substituted with the result of its execution as a command. E.g.,

LOG "Current system state is: ${GET SYSTEM STATE}"
LOG "The path environment variable is: ${PATH}"

Note that the last example uses the short form of the GET command, which will return the value of a PATH parameter or a PATH state if such exists. To make sure that only environment variables are matched, use the long form of the GET command:

LOG MESSAGE "The path environment variable is: ${GET VARIABLE PATH}"

Substitutions may be nested, i.e. the following will work:

SET MyVar "LIST STATES"; LOG "States are: ${${MyVar}}"

Mathematical Expressions. A command may consist of a single mathematical expression. This expression is then evaluated, and its result is returned as the command's result. As a special case, this allows the use of expression variables in ${...} substitutions. Consider for example

x:=0; WHILE x<10; LOG ${x:=x+1}; END

There, the first command creates and initializes the expression variable x. In the WHILE condition, an expression is allowed as well as any command. In the LOG command, an expression appears in ${...}, which executes the expression in braces, and substitutes the result of the expression as an argument into the LOG command, which adds an entry to the Operator log. This results in a sequence of 10 log entries, containing the numbers from 1 to 10.

Commands

Control commands

These commands allow conditional execution of parts of a script. When a condition is expected, any other scripting command may be given. Its result will be considered to represent a boolean value of "true" if it is empty, a nonzero number, or the string "true". It will be taken to represent a boolean value of "false" if it contains a numeric value of zero, or any string that does not evaluate to a nonzero number. Note that identification of an empty value with "true" differs from string handling in the EVALUATE CONDITION command. This is because most scripting commands return nothing on success, but an error message on failure.

The output of the SYSTEM and START EXECUTABLE commands is handled specially. There, the result code of the created child process is translated into a boolean value in the ordinary manner, treating a result code of zero as "true", and any other result code as "false". This allows to use external commands in the same way as in a native shell.

IF <condition>; <if commands>; [ ELSEIF <condition>; <elseif commands>;] ... [ ELSE; <else commands>;] END

Executes if commands if condition evaluates to "true". Otherwise, the elseif commands of the first matching elseif condition are executed. When none of the elseif conditions evaluates to "true", else commands are executed. ELSEIF and ELSE blocks may be omitted.

WHILE <condition>; <loop commands>; END

Executes loop commands while condition evaluates to true.

DO; <loop commands>; UNTIL <condition>

Executes loop commands until "condition" evaluates to true.

FOR <name> IN <item1> <item2> ... ; <loop commands>; END

Creates a local variable with the specified name. Then, sequentially assigns each item to that variable, and executes loop commands. If an item contains newline characters, it is split up into multiple items, corresponding to the lines contained in the item. E.g.,

FOR i IN top ${LIST FILES} bottom; LOG ${i}; END

will first write a log entry "top". Then, it will create a log entry for each file in the current directory, and finally, it will create a log entry "bottom".

Commands operating on Conditions

EVALUATE CONDITION <left> [<op> [<right>]]

Evaluates a comparison between the left and right operands. As a comparison operator, the following may be specified: ==, !=, ~=, <, >, <=, >=. There, the != operator behaves identically to the ~= operator. When a test for equality is performed, the two operands are treated as strings, and compared in a case-insensitive manner. When any of the inequality tests is performed, the two operands are converted into floating-point numbers before comparison.

The right operand may be omitted, in which case it is treated as if an empty string were specified. Also, the op operator may be omitted, in which case the following rules apply regarding the remaining operand: If it is an empty string, or equal to the string "false" in case-insensitive comparison, the result is "false". If entirely consists of the text representation of a floating-point number, the result is "false" if the number is 0, and "true" if the number is not 0.

Inspired by the GNU bash shell, there exists a short form of the EVALUATE CONDITION command, where the arguments of EVALUATE CONDITION may appear within square brackets. This allows constructs such as

IF [ ${MyVar} == MyValue ]; LOG Is equal; ELSE; LOG Is different; END

Note that the arguments to EVALUATE CONDITION must always be separated by white space, no matter whether its long or short form is used.

Commands operating on Environment Variables

These scripting commands allow to read and modify environment variables. Changes to environment variables will be visible to child processes started with SYSTEM or START EXECUTABLE. Variable values are stored as strings. Variable names may not contain the equals sign.

SET ENVIRONMENT <name> <value>

Sets the named variable to the specified value.

CLEAR ENVIRONMENT <name>

Removes the named variable from memory.

GET ENVIRONMENT <name>

Returns the variable's current value. When the variable does not exist, an empty value is returned rather than an error message.

Commands operating on Local Variables

Besides environment variables, there exist local variables in scripts. Local variables are inherited by sub-scripts executed with the EXECUTE SCRIPT command, but changes to the variable's values will not be propagated to the calling script.

SET VARIABLE <name> <value>

Sets the named variable to the specified value.

CLEAR VARIABLE <name>

Removes the named variable from memory.

GET VARIABLE <name>

Returns the variable's current value. When the variable does not exist, an empty value is returned rather than an error message.

Commands operating on Scripts

SET SCRIPT <handler names> <scripting commands>

Associates a sequence of scripting commands with the named handler. Handlers are specified by names as given below. Multiple handlers may be specified by concatenating their names with a pipe character, e.g. "OnStart|OnResume".

Scripting commands must be included in double quotes, unless they consist of a single word. When specifying a sequence of scripting commands, they must be separated with a semicolon character: "SetConfig; Start". In order to use double quotes or semicolons within the commands themselves, encode these as you would in a URL, i.e. replace a double quote character with %22, and a semicolon with %3B: "Load Parameters %22my file%22".

To use a script file rather than a literal script, use the EXECUTE SCRIPT command:

SET SCRIPT OnConnect "EXECUTE SCRIPT myscript.txt"
GET SCRIPT <handler name>

Returns the script associated with the specified handler.

CLEAR SCRIPT <handler names>

Clears scripts for the given handlers. Equivalent to calling SET SCRIPT with an empty script.

EXECUTE SCRIPT <file or handler name> [<Arg1> <Arg2> ... <Arg9>]

Executes a script contained in a file, and optionally sets the script's local variables Arg1 to Arg9 to the specified values. To execute script commands already associated with a handler, provide an handler name rather than a file. When the script is executed successfully, the result of the last executed script command becomes the result of the EXECUTE SCRIPT command itself. Use "SET Result <value>" as the last command in a script in order to return a certain value.

Commands operating on Parameters

LOAD PARAMETERFILE <file>, LOAD PARAMETERS <file>

Loads a parameter file specified by its path and name. Relative paths are interpreted relative to the operator module's working directory at startup. Usually, this matches the executable's location in the prog directory. As the parameter file name must not contain white space, please use HTML-type encoding for white space characters, such as Documents%20and%20Settings when referring to a user's "Documents and Settings" folder.

ADD PARAMETER <parameter definition>

Adds a parameter to the system. The parameter is specified as a parameter line. This command may not be used after system initialization has completed, i.e. its use is restricted to the "Idle" and "Publishing" phases of system operation. In terms of handlers, its use is restricted to the OnConnect handler.

SET PARAMETER <name>[( idx1, idx2 )] <value>

Sets the named parameter to the specified value. Values that contain special characters, or whitespace must use the parameter value encoding. Use parentheses to specify indices or labels.

SET PARAMETER <parameter line>

Replace a parameter's value and definition with the information given in the parameter line. The parameter must exist in the system when this command is executed. 0

GET PARAMETER <name>[( idx1, idx2 )]

Prints the value of the named parameter. Use parentheses to specify indices or labels. Use parentheses to specify indices or labels.

LIST PARAMETER <wildcard expression>, LIST PARAMETERS

Prints all parameters with names matching the wildcard expression, in form of parameter lines.

CLEAR PARAMETERS

Clears the list of parameters in the system. May only be executed in Idle and Publishing system states.

Commands operating on States

ADD STATE <name> <bit width> <initial value>

Adds a state variable to the system. State variables are defined by name, bit width, and initial value (see Technical Reference:State Definition). This command may not be used after system initialization has completed, i.e. its use is restricted to the "Idle" and "Publishing" phases of system operation. In terms of handlers, its use is restricted to the OnConnect handler.

SET STATE <name> <value>

Sets the named state variable to the specified integer value. Setting the Running state to 1 will start system operation, setting it to 0 will suspend the system.

GET STATE <name>

Gets the value of the named state. Note that state values are not updated from the application module when the OperatorBackLink parameter is 0. In that case, GET STATE will return the state's initial value.

LIST STATE <wildcard expression>, LIST STATES

Lists all states, or states with names matching the given wildcard expression, in form of state lines.

CLEAR STATES

Clears the list of states in the system. May only be executed in Idle and Publishing system states.

Commands operating on Events

Events are a special type of state, which are recorded asynchronously, at single-sample resolution. Events may only be added while the system is in "idle" state. This kind of events is not related to Operator Events as defined below.

ADD EVENT <name> <bit width> <initial value>

Adds an event to the system. Like state variables, events are defined by name, bit width, and initial value (see Technical Reference:State Definition). This command may not be used after the system has started up, so it is typically executed within a telnet session before STARTUP has been called.

SET EVENT <name> <value>

Asynchronously sets an event to the given value. Recording events requires the EventLink logger component to be present in the source module.

GET EVENT <name>

Gets the value of the named event. Note that evemt values are not updated from the application module when the OperatorBackLink parameter is 0.

LIST EVENT <wildcard expression>, LIST EVENTS

Lists all events, or events with names matching the given wildcard expression, in form of state lines.

CLEAR EVENTS

Clears the list of events in the system. May only be executed in Idle state.

Commands operating on VisProperties

SET VISPROPERTY <visID>.<name> <value>

Sets the named visualization property for the specified visualization ID to the given value. If the visualization ID contains a dot character, it must be encoded in parameter value encoding. E.g., setting the window width for the visualization ID "2.D1" would be written SET VISPROPERTY 2%2ED1.Width 200.

GET VISPROPERTY <visID>.<name>

Prints the value of the named visualization property for the specified visualization ID.

SET VISPROPERTIES <property set ID>

Applies a set of visualization property values as given in the VisPropertySets parameter. In that matrix-valued parameter, row labels specify visualization properties such as "SRCD.Left", and columns represent sets of property values. Column labels are IDs of the corresponding property sets.

Commands operating on the Control Signal

GET SIGNAL( <channel index>, <element index> )

Prints the value of the control signal at the given indices. Indices are 1-based.

Commands operating on Expressions

EVALUATE EXPRESSION <expression>

This command treats the remainder of the command as a literal mathematical expression (for a description, see User Reference:Expression Syntax. An expression may contain variable assignments; such variables may then be used in later expressions. Note that expression variables are different from local and environment variables that may be accessed by GET/SET VARIABLE/ENVIRONMENT. Expression variables hold numerical values, while local and environment variables hold string values. Also, environment variables are accessible to child processes started with SYSTEM or START EXECUTABLE, while expression variables are accessible only to scripts. When a script is executed using the EXECUTE SCRIPT command, it will inherit a copy of all expression variables present. Changes to these variables from the executed script will not be visible in the parent script.

CLEAR EXPRESSION VARIABLE <name>

Clears the named expression variable from storage.

Commands operating on Files, Directories, and Paths

EXTRACT DIRECTORY <path>, EXTRACT FILE <path>, EXTRACT FILE BASE <path>

Extracts the directory or file portion of a given path. When the path specifies a non-existing directory, the directory name must be followed with a separator ("/") in order to be recognized as a directory. The EXTRACT DIRECTORY command always returns its result with a trailing separator. The EXTRACT FILE BASE command returns the file portion without extension.

IS DIRECTORY <path>, IS FILE <path>, IS PATH <path>

Determines whether the specified path points to an existing directory, file, or any of the two. The result is returned as one of the strings "true" or "false".

PARENT DIRECTORY <path>

Returns the parent directory of the specified path, independently of whether the path points to a directory, or to a file.

CURRENT DIRECTORY

Returns the current working directory.

CHANGE DIRECTORY <path>

Changes the working directory.

MAKE DIRECTORY <path>

Creates a new directory with the given path. The directory's parent must exist for the command to succeed.

LIST DIRECTORY [<path> or <wildcard expression>]

Returns a listing of the specified directory, or the current working directory if no path is specified. The listing is in long form. You may use wildcard expressions in order to restrict the output.

LIST FILE <wildcard expression>

Returns a list of file names matching wildcard expression in the current directory.

LIST FILES [<directory> [<wildcard expression>]]

Returns a list of file names from the specified directory, matching wildcard expression. When wildcard expression is missing, all files are listed. When directory is missing, files in the current directory are listed.

LIST DIRECTORIES [<directory> [<wildcard expression>]]

Returns a list of directory names from the specified directory, matching wildcard expression. When wildcard expression is missing, all directories are listed. When directory is missing, directories in the current directory are listed.

RENAME FILE <current path> <new path>, RENAME DIRECTORY <current path> <new name>

Renames a file resp. a directory. For files, a different path may be given in the second argument, resulting in that the file is moved to the location specified by the new path. For directories, the path up to the directory's name must stay the same.

REMOVE FILE <path>, REMOVE DIRECTORY <path>

Removes the specified file or directory. This command cannot be undone. The directory must be empty for the command to succeed.

FORCEREMOVE DIRECTORY <path>

Removes the specified directory and its contents. Symbolic links are treated as ordinary files, i.e. they are not followed. This command cannot be undone.

CANONICAL PATH <path>

Translates the given path into canonical form, i.e. into an absolute path without symlinks. All directories along the path must exist in order for the command to succeed.

Commands operating on Lines of input/output

WRITE LINE <line>

Writes a line of output. Destination depends on the context in which a script is executed. If the context is an Operator Handler , output written as a log entry. If the context is a telnet session, output is written to the telnet connection. If the context is a BCI2000Shell, output is written to the shell's stdout.

READ LINE

Reads a line of input from the current execution context's input. If the command is executed within an Operator Handler, it will fail. If executed within a telnet session, the other side of the connection is prompted for input. If executed from within a BCI2000Shell, input is read from the shell's stdin.

Global commands

HELP [<type>]

When called with a type argument, lists commands that exist for the specified type (e.g., SYSTEM, or FILE). When called without argument, lists all commands and their synonyms.

SET <name> <value>, GET <name>, <name>

Allows to set or retrieve the value of local and environment variables. The name is matched against local and environment variables. When no variable with the given name is found, SET will create a local variable, while GET will result in an error. GET may be further abbreviated to only consist of a name.

GET further allows evaluation of mathematical expressions. When the expression is invalid, or contains an unknown variable, an error is triggered.

GET SYSTEM STATE

Prints the current system state. This will be one of Unavailable, Idle, Startup, Initialization, Resting, Suspended, ParamsModified, Running, Termination, Busy.

WAIT FOR <system state> <timeout seconds=5>

Waits until the system is in the specified state. This may be one of Unavailable, Idle, Startup, Connected (a synonym for "Initialization" - the latter is also valid since it is compatible with the nomenclature in StateMachine.h, but it is avoided because it is easily confused with, but very distinct from, the actions performed in the Initialize() phase), Resting, Suspended, ParamsModified, Running, Termination, Busy, or a combination of these, separated with a pipe character: "Resting|Suspended". When timeout occurs, an error message is returned.

SLEEP

Waits (sleeps) for the given amount of time. Timing resolution is 50ms. Tends to sleep a little longer than specified, with the error growing with duration.

GET SYSTEM VERSION

Prints BCI2000 version information.

SETCONFIG, SET CONFIG

Applies current parameters to the system. Corresponds to the SetConfig button in the GUI version of the Operator module.

START

Starts or resumes system operation, corresponding to the Start/Resume button in the GUI version of the Operator module.

STOP

Stops system operation. Corresponds to the Stop button in the GUI version of the Operator.

STARTUP

When in idle state, starts up the system to wait for incoming connections from core modules.

SHUTDOWN

Shuts down core modules, and enters idle system state.

QUIT, EXIT [<result>]

Quits the operator module after terminating all BCI2000 modules. The optional result argument determines the result of the executed script.

SYSTEM <command line>

Executes a shell command, redirecting any console output into the command's script result. E.g., to obtain a directory listing, under Windows, you would enter

SYSTEM DIR
START EXECUTABLE <command line>

Starts the specified executable with options. This command returns immediately after the started program has finished initialization.


LOG <message>

Append the specified message to the system log.

WARN <message>

Append the specified message to the system log, formatted as a warning.

ERROR <message>

Append the specified message to the system log, formatted as an error message.

CAPTURE MESSAGES <message types>

Captures system log messages into a background buffer. When no message type is given, all messages are captured. When "None" is given as a message type, message capturing is disabled. Otherwise, the message type must be one of "Errors", "Warnings", "Debug", "Log". Multiple message types may be specified in a single command. When "None" appears within a single command, all preceding message types are ignored. Multiple CAPTURE MESSAGES commands are cumulative, except when "None" is specified as a message type.

FLUSH MESSAGES

Clears the background message buffer, and returns its previous content. Use CAPTURE MESSAGES to capture messages into the background message buffer.

Operator-module defined Commands

HIDE WINDOW [<name>], SHOW WINDOW [<name>]

Hides or shows the specified window. When called without a window name, the Operator module's main window is hidden or shown. The window name may be one of Main, Configuration, or Log.

SET TITLE <title>

Sets the title of the main Operator window.

Predefined Variables

The following variables exist when an Operator script is executed. Some of these variables are marked with local. This means that they are not environment variables, i.e. they are invisible to child processes that are launched using the SYSTEM or START EXECUTABLE commands, and their values may be different between script invocations. In script code, they are accessed like ordinary variables.

BCI2000LAUNCHDIR

The full absolute path to the working directory when the Operator module was launched. This is also prepended to the PATH environment variable, such that executables from the current BCI2000 installation will have precedence over any other executable with the same name.

BCI2000BINARY

The full absolute path to the Operator module.

Result (local)

The result of the last executed scripting command. When a script is executed by calling EXECUTE SCRIPT, the script's last executed command determines the result of the EXECUTE SCRIPT command itself.

Arg0, Arg1, ... Arg9 (local)

When a script file is being executed, these variables contain the arguments of the EXECUTE SCRIPT command. Arg0 contains the full absolute path to the current script file. Within scripts, all of the Arg variables are defined, and those that do not have a matching argument are empty. Outside of scripts, these variables do not exist.

YYYYMMDD (local)

Local time at execution of the current script, in YYYYMMDD format. In interactive sessions, reflects the time when the session was initiated.

HHMMSS (local)

Local time at execution of the current script, in HHMMSS format. In interactive sessions, reflects the time when the session was initiated.

Abbreviated commands and synonyms

To minimize the need of consulting documentation, as well as for backward compatibility, a number of synonymous commands are provided. E.g., states may be added by INSERT STATE as well as ADD state, and the existence of a file may be queried by IS FILE as well as EXISTS FILE. For an overview over all allowed forms of commands, enter the HELP command.

To simplify operation in interactive sessions, abbreviated commands exist. Currently, these are:

cd for CHANGE DIRECTORY,
pwd and cd without argument for CURRENT DIRECTORY,
ls and dir for LIST DIRECTORY,
mkdir for MAKE DIRECTORY,
echo for WRITE LINE.

Handlers

In the Operator GUI, script execution is bound to a number of Operator Events (not to be confused with Event states, above) that occur during various stages of BCI2000 system operation:

OnConnect

This handler runs at startup, as soon as all modules are connected to the operator module.

OnSetConfig

This handler runs each time a set of parameters is applied to the system. This happens when the user clicks the SetConfig button. Execution of the SETCONFIG command also triggers this handler.

OnStart, OnResume

These handlers are triggered by the Start/Resume button. One of these handlers is also triggered when the Running state variable is set to 1 from a script. Whether OnStart or OnResume is triggered depends on whether the system has been running before with the current set of parameters.

OnSuspend

Triggered when the system goes from running into suspended mode. This happens whenever the Running state variable changes from 1 to 0. This may happen when the user clicks Suspend, when the application module switches the system into suspended mode, or when a script sets the Running state variable to 0.

OnShutdown

Triggered when the operator module shuts down connections, and switches into idle state.

OnExit

Triggered when the operator module exits. Execution of the QUIT command also triggers this handler. This handler is not available to the SET SCRIPT and CLEAR SCRIPT commands. Also, when both an OnShutdown and an OnExit script are defined, the OnExit script will be executed before the OnShutdown script.

Associating Scripts with Operator Events

In the operator module's preferences dialog, script commands may be entered for each of the handlers listed above. Scripts may be specified as paths to script files, or as immediate one-line scripts. Entries that start with a minus sign (-) are treated as one-line scripts, which may contain multiple commands separated with semicolons.

Scripts may also be specified from the command line used to start up the operator module. There, handler names are followed with the content of the respective preference entry, enclosed in double quotes ("...").

Finally, scripts may be specified using the SET SCRIPT command of the scripting language itself.

Examples

Making use of the Operator module's Function Buttons

To add a state variable called "Artifact", and to set it using the operator's function buttons, do this:

  • Enter the following line under "After All Modules Connected" in the operator's preferences dialog (note the minus sign):
-ADD STATE Artifact 1 0
  • Under "Function Buttons", enter "Set Artifact" as the name of button 1, and as its command, enter (note there is no minus sign):
SET STATE Artifact 1
  • Enter "Clear Artifact" as the name of button 2, and as its command, enter
SET STATE Artifact 0

A fully automated BCI2000 session

Echo Please enter a subject ID:
Set SubjectID ${Read line}

Startup system
Start executable SignalGenerator
Start executable SpectralSignalProcessing
Start executable CursorTask
Wait for Connected
Load parameterfile "../parms/examples/CursorTask_SignalGenerator.prm"
For i in 1 2 3
  Load parameterfile "../parms/MyExperiment/Session${i}.prm"
  Set parameter SubjectName ${SubjectID}
  Set parameter SubjectSession ${i}
  Set config
  Wait for Resting
  Start
  Wait for Suspended 1000
End

Automating BCI2000 by Operator command line arguments

The following example shows how to specify script commands from the command line. It fully automates BCI2000 operation by loading a parameter file, applying parameters, starting the system once the parameters are applied, and quitting the system once the run is over. For better readability, the example is broken across lines, using the ^ DOS line continuation character.

operator.exe --OnConnect "-LOAD PARAMETERFILE ..\parms\examples\CursorTask_SignalGenerator.prm; SETCONFIG" ^
             --OnSetConfig "-SET STATE Running 1"  ^
             --OnSuspend "-QUIT"

See also

User Reference:Module Command Line Options, User Reference:Operator Module, Technical Reference:States of Operation