Combining the advantages of LXI and scripting (Part 1)

Search(2.5, 0.001)

Instruments have features that complement scripting engines. If the scripting environment provides programmatic access to the instrument's front panel, users can create interactive scripts that prompt the user to enter parameters or display results on the front panel. Instruments can also provide nonvolatile on-board script storage so that these stored scripts can be automatically executed when the instrument is powered on. This allows pre-loaded applications to be executed without any user action other than turning on the power to the instrument.
Embedded scripting offers significant advantages to test and measurement instrument users. Although embedded scripting has some minor disadvantages, such as the unfamiliarity of the queries described earlier, most users can easily use or adapt to it.

Scripting languages ​​usually manage memory automatically, so the user does not need to allocate and free storage for strings or matrices. While this is convenient for the user, the scripting engine needs to periodically reclaim memory that is no longer in use, a process called "garbage collection." Although garbage collection can be done automatically, it takes time and can cause problems if it occurs during critical time periods in the test sequence. These problems can be prevented, but first the user must understand the impact of the garbage collector and know how to avoid garbage collection during critical time periods in the test sequence.

Here is an introduction to LXI and scripts

The current LXI standard for test instruments does not require instruments to be programmable or implement scripts. However, many features in the LXI standard anticipate programmable instruments and provide useful functionality to enhance the scripting capabilities of LXI-compliant instruments.

The LXI standard requires Class A and Class B instruments to support peer-to-peer messaging via LAN messages, and allows Class C instruments to support this messaging. LAN messages can be used to notify other LXI instruments of events or to trigger another instrument to perform some function. Upon receiving a LAN message, the user must be able to specify what action to take. To achieve this, the most flexible method and the method recommended by the LXI standard is to allow the user to download executable code (i.e., scripts or programs) into the instrument, which is then executed upon receiving the appropriate LAN message. This provides great flexibility because the user is not limited to a set of predetermined actions.

In addition, the LAN message format defined by LXI contains a small space for including arbitrary data as part of the message. Executable code (such as a short script) can be transmitted as part of the LAN message. This allows one instrument to control another instrument via a LAN message without having to pre-set up a response. For example, assume that one instrument can measure a device under test (DUT). Based on the results of the measurement, the first instrument must be able to change the stimulus applied to the DUT by another instrument. The new stimulus value is calculated based on the first measurement, so it is not known to the first instrument beforehand. In this case, the first instrument can send a LAN message containing a short script to the second instrument to adjust the stimulus value.

Part IV Advantages of Using Scripts in Test and Measurement

The following are the advantages of script-based instrumentation. Many of these advantages are enhanced when the instrumentation is also LXI compliant.

For many test and measurement applications, it is a good idea to use a PC as a controller to communicate with individual instruments or use a slot-based system with an integral controller. But for other cases, those approaches are either too expensive because they are overkill or not up to the task. These applications can benefit from the additional power and flexibility provided by script-based instruments. This section describes the advantages of scripting in test and measurement applications.

1. Structural flexibility

Small test systems with a few instruments can be built without separate controllers; one instrument acts as the controller and manages the work of the other instruments. Large systems can be divided into subsystems containing a few instruments each, where each subsystem is managed by script-based instruments. This simplifies system design and helps improve performance. For example, in assembly lines, scientific applications, or RF test applications, such subsystems can be physically separated to a large extent using LXI script-based instruments.

2. Improve performance

Dividing large systems into subsystems managed by script-based instruments spreads control and data handling functions across multiple processors, increasing the total processing power available to the system and often improving overall speed and throughput. In addition, this division of work supports parallel testing: instruments or subsystems do not have to remain idle while the central controller is busy with other tasks.

Because there is less latency caused by communicating with the controller when transferring commands or data, scripts running on the instrument can run at maximum speed. This is especially important when the instrument is executing a repetitive test sequence. With a single controller, the command sequence must be sent to the instrument for each pass, even if the same sequence is run hundreds or thousands of times. Compare this to the scripting approach, where the script is transmitted only once and can be run as many times as desired using short commands.

Conditional processing (for example, when the result of a measurement determines the next function to execute) provides another means of improving performance. Performing conditional checks locally in the script can remove the delay caused by sending the first result to the controller, waiting for the controller to process it, and then sending the next instruction to the instrument.

In systems involving high data rates and/or large data sets, communication delays, bandwidth limitations, and controller throughput can all be severe bottlenecks. Script-based instruments can compress data to reduce bandwidth requirements and/or buffer data and transmit it in the background when bandwidth is available. Script-based instruments can also filter data, such as by transmitting only data that exceeds normal limits. As mentioned earlier, scripts also reduce the communication bandwidth consumed to send commands from the controller to the instrument, thereby improving performance in bandwidth-limited applications and minimizing delays caused by communication delays.

3. Reduced costs
Building smaller or less complex test systems using script-based instrumentation does not require a separate controller, saving the cost of the controller and the cost of any separate test runner software used to control the instrument. The same cost savings can be achieved when building large test systems when subsystems are built from script-based instrumentation.