Introduction

Like many instrument operators, you may have a comfortable preference toward SCPI as the foundation for your instrument automation needs. If, however, you are looking for a means to reduce your test time and cost and are open to suggestions to help you accomplish your goals, then this technical brief might lead you to exactly what you are looking for.

Test Script Processor (TSP®) technology from Keithley has many proven benefits, and we are very excited to share the power of this technology, so let us start with the basics. Simply put, there are three key concepts we should cover before you start your TSP journey: TSP is a scripting engine, a command set, and a means for promoting system scalability.

TSP is a Scripting Engine

TSP is an embedded script execution environment built on top of Lua, a permissive, free license script-based programming language [1]. The TSP + Lua combination localizes all the benefits of a true programming language within your instrument including:

• Global and local variables
• Functions or subroutines
• Loops and conditionals
• Typical arithmetic, relational and logical operators
• Advanced math and string operation libraries
• String concatenation
• Commenting
• Aliasing
• File I/O and management
• Powerful, flexible data structuring in the form of tables

The TSP command language is implemented in tables, and this becomes more evident as you get acquainted with the Lua syntax and how other custom, built-in data structures use the dot-based dereferencing to access their deeper levels. The code snippet shown in Figure 1 helps to illustrate a variety of the programming features you might use in a TSP script.

In short, the embedded programming language allows you to virtually create your own instrument command set. You can create a wrapper around a command tailored to your preference. If you want to encapsulate a series of commands and computations within a function identified by a short name then execute it and get just the results, you can do that, too. The example shown in Figure 1 can be uploaded to the instrument, your program can invoke "res_test()" and extract the sourced current and measured voltage values when they are available in the output queue. This puts you in control of how the returned data are formatted. While the sourced current then measured voltage are returned in that order, you could just as well swap the two.

To illustrate the potential for simplification, consider Table 1 which establishes the same test setup to extract current and voltage measurements upon testing a resistor.

In looking at the “TSP Function Call” sample in the table above, you could just as easily have embedded the print() statement within the res _ test() function itself and removed the need to add it as a wrapper, allowing it to operate more like a SCPI query: send the command, get the data.

The preceding details are used to help illustrate what a script might be composed of. Even more important is where all this next-level programming capability is called into action: at the instrument level. An embedded scripting engine allows you to add features or customize the behavior of the TSP-enabled instrument and run even without a PC connected.

The value of executing the script on the instrument is that you are able to lower the processing burden on the PC. TSP technology localizes complete test programs within the instrument for best-in-class system-level throughput. This may be inclusive of any advanced math operations that need to be performed on the acquired data. Offloading processing to the instrument, reducing communication bus traffic, TSPenabled instruments have run production tests as much as 60% faster [2].

An example of the TSP throughput improvement potential can be found in the application note entitled Increasing Production Throughput with Data Acquisition Systems [3]. With just a single instrument we show a >16% reduction in test time using the embedded scripting method over traditional transactional command issuing.

TSP is a Command Set

Another important thing you should understand is that TSP is a command set – a textual framework composed of specific program messages, expected instrument responses, and data formats. While we recommend you take full advantage of the available embedded scripting capability, you still have the option of sending individual TSP commands to a TSPenabled instrument the same way you would when sending SCPI commands using any other instrument.

While SCPI allows for short command string formatting, one of the strategies of TSP is to enhance readability by enforcing the use of the full commands such as shown in the following string:

smu.source.levelv = 10.0

One other difference you might immediately recognize when using TSP is how it returns instrument data to the user. Consider the entries in the following table:

While visually different, both commands perform the same functionality: they initiate a reading acquisition, place it in the output queue, and send the textual measurement back to the calling program.

For interested readers, more information and examples on these two command sets can be found in the How to Transition Code to TSP from SCPI application note on tek.com.

TSP Promotes System Scalability

If you are asking how such efficiencies can be realized with just a single instrument, we ask you to think bigger. Rarely is a test system composed of a single instrument which is exactly what the teams at Keithley had in mind. In addition to TSP as a scripting engine and command set, a multitude of instrumentation “nodes” can be interconnected over the TSP-Link system expansion interface.