12-4
Return to
2600AS-901-01 Rev. B / September 2008
Section 12: TSP Fundamentals and Script Management
Series 2600A System SourceMeter® Instruments Reference Manual
any number of scripts can be made available simultaneously within the limits of the memory
available to the run-time environment.
Named scripts are stored in the run-time environment which means that when the unit is powered
off, they are lost. There is nonvolatile storage on the instrument that can be used to store
downloaded scripts across power cycles. See
for more information.
Renaming Scripts
It may be useful to rename user scripts after they have already been stored. Renaming may be
necessary because scripts are saved to internal nonvolatile memory by name and there can be
only one script in nonvolatile storage with each given name. It may also be useful because scripts
loaded from a USB memory stick will not overwrite scripts already loaded with a given name.
The name of a script can be accessed by using the
MyScript.name
command. To change the
name of a script, use the following example:
MyScript.name = “TestScript”
Where:
MyScript
is the global variable and
“TestScript”
is the new name of the user script.
This command renames the script that
MyScript
was previously referencing. Changing the name
of a script does not change the name of any variables that reference that script. After changing the
name, the script will be found in the
script.user.scripts
table under its new name.
For example,
“TestScript”
can be run using the
script.user.scripts.TestScript()
command. It can also be run by using the command
MyScript.run()
until
MyScript
is set to
nil
.
Functions
As previously explained, named scripts behave like TSL functions. Executing a script is just like
executing a function with the same name as the script. Scripts, like functions, may return values.
Unlike functions, scripts may not take any parameters. In order to pass parameters to a chunk, you
must include a TSL function (referred to in this example as
function body
).
Functions are created with a message in one of the following forms:
MyFunction = function (parameter1, parameter2)
function_body
end
or
function MyFunction(parameter1, parameter2)
function_body
end
Where
function body
is a TSP chunk that will be executed when the function is called. The
above function can be executed by substituting appropriate values for
parameter1
and
parameter2
and inserting them into the following message:
MyFunction(value_for_parameter1, value_for_parameter2)
Where
value_for_parameterN
represents the values to be passed to the function call for the
given parameters. Note that when a function is defined, it is just another global variable in the run-
time environment. Just like all global variables, functions will persist until they are removed from
the run-time environment, overwritten, or the unit is turned off.
Scripts that create functions
It is inconvenient in most cases to define a function in one message. The solution is to create a
script that defines a function. The scripts will be like any other script. It will not cause any action to
be performed on the instrument until it is executed. Remember that creating a function is just
creating a global variable that is a function. That global variable will not exist until the chunk that