SCPI is a programming language for controlling instrumentation using a computer. It consists of ASCII characters, sent over Ethernet, USB, GPIB, RS232. Many test equipment vendors offer libraries and tools for their equipment. Serving as the bedrock of test engineering, it’s reach spans the engineer’s test bench to the manufacturing production line, with broad support across the test equipment vendor community.
However, the S in SCPI stands for "Standard", not "Simple". Using it in conjunction with contemporary computer science fundamentals such as conditional statements, loops, and comparisons, with appropriate logging, error handling, and resiliency, requires a solid foundation in both software programming and the specifics of the hardware you are using in your test.
We’ve recently introduced an open source, Python based, multi-instrument, "hardened" software application, called Simple-SCPI, that can be used for simple bench testing as well as more sophisticated design validation. While there are many examples of Python scripts that are freely available for specific instrument use cases, none of them were good solutions with failure recovery, logging, and multi-instrument control. We've designed ours from the ground up with those capabilities included to provide an extensible and resilient tool for users.
How it works:
Getting started is easy. It requires downloading and installing free software packages, via our instructions on Github.
Once installed, the user creates a configuration file for instrument control. It contains addressing details (e.g. TCP/IP address resource string) and any additional SCPI related commands and control features.
Then all the user needs to do is execute the scpi_runner.py program and it reads the configuration file and processes the SCPI commands accordingly. The basic steps for getting started are available at the Github repository. In this blog post, there are more detailed examples for various use cases that may prove helpful, ranging from simple, to more advanced.
These examples use a Rigol oscilloscope connected via an ethernet cable to a Windows laptop. This example would apply to any instrument that supports SCPI, though some of the SCPI related commands may vary.
#1: Perform *IDN? query
A common SCPI command in test plans includes using the *IDN? query to collect instrument specific metadata such as manufacturer and model number, serial number, firmware version, etc. To do that, using simple-scpi, create a configuration file that includes the address of the instrument, and then the command for obtaining instrument info (*IDN?).
The below log output shows the output into the terminal after running the scpi runner application. It shows the instrument being initialized, the script construction, and then the response to the SCPI commands. The response to the *IDN? is: RIGOL TECHNOLOGIES,DS2202A,DS2D180100040,00.03.05.SP1
#2 Take voltage measurements in 1 second intervals for 5 seconds using GradientOne commands
Now imagine you wanted to take waveform measurements in 1 second intervals. The command is: :MEASure:VAMP?. Additionally, in this case, you also wanted to do this over a 5 second period. We've also added a host of GradientOne specific commands. In this case, to add a delay to your script in between commands, use a GradientOne provided command that inserts a user specified delay G1:Sleep(<NumberOfSeconds>) . To simplify and minimize errors we've also provided loop commands G1:StartLoop:Max=<NumberOfTimes>. In this example we will have a 1 second sleep and will perform the loop 5 times. More details of the GradientOne specific commands are available in the Github repository.
See below for the log output which includes the voltage measurements, in 1 second intervals.
#3: Save a screenshot of the Rigol DS2202A
Saving the screenshot of the instrument is a common task. For many instruments there may be multiple SCPI commands and other data manipulation required to get the screenshot saved. We've designed in a framework to allow for abstracted, common sets of SCPI commands such as fetching a screenshot, to be reduced to a one line entry in your configuration file. In this case, you can use the GradientOne specific command: G1:FetchScreenshot. In a future blog post, we will walk through how to add a new instrument that supports this type of command.
Below is the screenshot that was saved:
#4 Save the waveform of the Rigol DS2202A
Similar to saving the screenshot, saving a waveform is also a multi sequence set of SCPI commands with post processing of the data. We have also streamlined this set of commands to the GradientOne specific command: G1:FetchWaveform.
Waveform JSON Excerpt
Simple-SCPI provides a quick, easy to use, free tool for a variety of test automation use cases, from the hobbyist to the compliance lab. It is also possible to use it in conjunction with the GradientOne service that automatically archives and plots your waveforms and screenshots. In the next blog post we will show you how that works. If you're interested in learning more about his, feel free to reach out and we can help you get started.
Current events highlight the need for enabling efficient and effective remote work environments around the world. The impact on test engineers and lab managers is particularly acute due to the needs of accessing equipment and instrumentation in a lab. If lab access is restricted, how can teams minimize the impact to product development while maintaining high levels of quality and test coverage? This post will highlight different ways GradientOne can help support remote instrument control and collaboration via automatic waveform upload when lab access may be limited.
Remote Instrument Control
With lab access potentially limited the test engineering function will be impacted by challenging access to instruments, developing test plans, and accessing/viewing test data in a collaborative approach. Some tools such as VPNs and Remote Desktop Software have historically been used to address some of these issues, but they come with various limitations. GradientOne’s approach is purpose built from the ground up to leverage contemporary technologies to enable instruments without the need of any software installed on the computer trying to access the instrument. Regardless of whether it is a laptop, desktop, tablet, or smartphone, a user can securely log into a portal via a web browser, select an instrument to use, and then configure the device and execute tests.
Below are example use cases of how an engineer might use GradientOne to control instruments and run tests remotely:
Automatic Upload of Test Results
Another common challenge in remote environments is accessing the test results and archiving them for review, report generation, and collaboration.
Our approach provides an automatic upload capability of every bit of relevant information from the test and index and archive it in the secure GradientOne cloud or a local server in the customer environment for users to access at any point in the future:
Enabling remote lab operations historically has required home grown solutions or technology designed for a different purpose, shoehorned into the lab environment. In our next post we'll describe how we can help make data driven decisions around instrument asset utilization to optimize budgeting and lab allocations to meet your current operating environment. We've developed an approach from the ground up, to address these issues in a way to simplify and streamline remote or local work flows. We offer this to customers directly or via consulting services. If you'd like to learn more click below to let us know how we can help.