|
Today we are releasing the first version of our SCPI command application. This is the first of several releases that delivers a Python based, multi-instrument, "hardened" software application that can be used for simple bench testing as well as more sophisticated design validation. There are many examples of Python scripts that are freely available for specific instrument use cases, but when building solutions for our customers we haven't come across many general purpose frameworks that allow for resiliency, failure recovery, logging, and multi-instrument control. We've designed this from the ground up with many of those capabilities included. Read below for more on how it works. Requirements First, you'll need to make sure you have the below software packages installed:
Usage The scpi_runner.py reads a scpi_script file to open a connection with an instrument and send commands. The commands and their responses are logged to a log file. A sample script is provided in scpi_script.sample for you to modify as needed. We've added features in the program to make it more "hardened". These include resiliency features for exception handling and other errors that can be caught without crashing the application. Timeouts The scpi_runner will time out commands and scripts that take too long to run. The command timeouts will raise an exception and run the next command. If the whole script times out then an exception is raised and the remaining commands are not run. These timeouts can be modified by editing the values set in settings.py GradientOne Script Logic The scpi_runner.py supports basic loops and sleeps (delays). The syntax for the GradienOne ScriptLogic objects is not case-sensitive, so G1:StartLoop and g1:startloop are equivalent. To start a block of commands to loop, a StartLoop command is needed. G1:StartLoop:Max=<NumberOfTimes>:BreakOn=<ResponseToBreak> The Max is required, otherwise the block of commands will only run once. The BreakOn is optional. The string G1:StartLoop:Max=3 will start a loop that runs 3 times. You then enter as many commands as needed in the next lines and end the block of code to loop with a line with G1:EndLoop Example: G1:StartLoop:Max=3 *IDN? G1:EndLoop Will run the *IDN? command 3 times. Sleeps To add a delay to your script in between commands, use a G1:Sleep. G1:Sleep=<NumberOfSeconds> For example, to sleep 2 seconds: G1:Sleep=2 This calls python's time.sleep() function to delay running the next line. This can also be used within a loop. Example SCPI Script
1. Establish a connection to the instrument: The above script opens a connection to the instrument using the IP address of 192.168.1.238, which can be found on most instruments network/LAN settings. 2. The next several lines include the SCPI commands *IDN?, *RST, and :SAVE:IMAGE D:\screenshot.png. These commands will obtain basic instrument information, reset the devoce, and download the screenshot to onboard instrument storage. 3. The next two commands are GradientOne specific commands for inserting a sleep and a loop. These are followed by a SYST:ERR? which checks to see if there is an error. 4. The last line is another GradientOne specific command signifying the end of the loop. See below for the example in action: Terminal output
Below is an example of the logging: Log Output
Stay tuned...more advanced features to come.
0 Comments
Oscilloscope Test Automation For Tektronix MDO3012 With Function Generator and RIGOL DS1054Z6/10/2019 GradientOne's test automation can be used to remotely control multiple instruments over the web. In this video we demonstrate how that is done, along with the instrument screenshots and waveforms that are acquired. 1) Setup: The function generator on the Tek MDO3012 is connected to Channel 4 on the RIGOL DS1054Z.  2) Instrument Programming: The RIGOL needs to be programmed to enable channel 4, set the trigger, and the horizontal scale. The Tektronix needs to have the function generator enabled. In this example two types of commands are used: i. A previously stored test recipe of SCPI commands are used to program the test setup. An example is shown below. ii. Abstracted commands for common test routines such as saving the screenshot and waveform. RIGOL DS1054Z Setup
3) Data Acquisition: The data that is acquired from the test setup includes the raw waveform (times and voltages) as well as the screenshot of the oscilloscope and the current instrument settings. This gives engineers the ability to post-process the data, compare it to other results, and collaborate with their teammates.  Video DemonstrationHave you ever needed to compare a saved waveform to another waveform? Historically you may have needed to save a waveform on your oscilloscope, then load it on the same screen as a different waveform that you captured. GradientOne offers a new way to do this using your web browser.
GradientOne automatically stores waveforms and metadata when tests are run. So in addition to things like screenshots, test setups, and measurements, the raw waveform data, including times and voltages is stored. While storing the screenshot gives the ability to view what the oscilloscope captured, storing the waveform data itself provides the ability to perform various measurements and analyses, including overlays. In the video below, we show how you can compare waveforms using the overlay feature, use cursors (some engineers refer to these as rulers) to perform custom measurements, and use the integrated collaboration features to review with your teammates. If you are interested in seeing for yourself, give the 14 day free trial a try, it is the best way to get familiar with some of the capabilities of the product. Automation in test & measurement equipment unlocks many benefits across the entire industry, from scientific research, to R&D, to Manufacturing, and customer support. Industry standardization drove broad adoption of common command language of SCPI (Standard Commands for Programmable Instruments), that has formed the basis for controlling instruments, and building drivers and test system applications. GradientOne offers a new approach for multi-instrument support for engineers to connect their devices to the web and send SCPI commands via any web browser for remote programming and control. The ability to pass SCPI commands in conjunction with a GradientOne’s mix of pre packaged test routines for capturing waveforms, screenshots, and instrument setups unlocks new capabilities for remote control as well as troubleshooting/debugging test rigs, bench setups, and more. Setup Getting set up is pretty easy. No need to program drivers, deal with VISA, etc. GradientOne takes care of this for you. Simply connect your instrument to the same network as your computer. Then download a configuration file that registers your setup with the GradientOne cloud. Then install the GradientOne agent.  In the video below you can see a quick demo of how you can easily send SCPI commands to control an instrument for troubleshooting, while also sending test routines to view screenshots, acquire data, and more. We've set up an oscilloscope you can remotely control to try for yourself. To send a SCPI command try the following:
1) Click on the button below 2) Select "SCPI" from the drop down menu (chevron) on the upper right next to Get Data. 3) Enter a name for this configuration in the "Enter Config Name" field 4) Below that select "Ask" from the drop down menu 5) Enter "*IDN?" in the "Enter SCPI Command" field 6) Click "Get Data" and you should see the results of the oscilloscope processing the *IDN? command. I2C Decode Example
 With GradientOne you can decode serial bus signals. We've set up an example customer instance that gives you the ability to take it for a test drive and see for yourself. You can reach this demo by going to the home page: www.gradientone.com, and then clicking on the image underneath "Acquire An I2C Signal". It will take you here. In this setup, the RIGOL DS1054Z oscilloscope is connected to a demo board (see above), with Channel 1 to an I2C clock, and Channel 2 to I2C data (Channel 3 is connected to a UART signal). If you click "Get Data" you will initiate the GradientOne feature set that configures the RIGOL oscilloscope to capture the I2C waveform, screenshot, and instrument settings/metadata. Then you can click 'Decode', 'I2C', then 'Run Decode' to get the decoded waveform. The initial capture will look like this:  GradientOne also offers the ability to zoom in for close inspection of the waveform. Below you see the zoom, as well as the tool-tip feature that will easily tell you the X-Y values of time = 2.47 msec and voltage = 3.38 volts.  You can also upload a CSV file of an I2C waveform and decode that as well. The first thing you need to do is capture the waveform and upload it to GradientOne. There are two ways to do this:
Next, select the type of decode you want to do and configure it. GradientOne currently offers decode for I2C (7 or 10 bit addressing) and UART. The waveform is then decoded, the plot annotated, and a decode table presented to the user. Multi-Byte Search Once the signal is decoded a full range of search capabilities is available to you. Perhaps you wanted to find 'Start', 'Stop', 'Nack/missing acknowledge' bits, you could enter those text and find it on the signal. That is relatively trivial. You can also search for multiple byte patterns. If you had a decoded signal and wanted to look for a specific pattern that is unique to your data stream, you can construct that search term and GradientOne would identify that byte sequence in your signal. E.g. If want to look for 0x474F as a search term, it finds all cases where 0x47 then 0x4F occurred chronologically/sequentially.  Demonstration Video For Waveform Upload and DecodeIf you are interested in learning more, check out our white papers on Protocol Decode and Instrument Automation. Start decoding your signals using the web today with a free trial of GradientOne.
Debugging glitches is a common task for engineers. Modern oscilloscopes have good tools for triggering on a glitch, but what happens next can be cumbersome, time consuming. We'll show you how GradientOne's automated measurements simplifies the process, turning a multi-hour exercise into an exercise that takes a few minutes. Oops You Detect A Glitch The first thing to do when you detect a glitch is try to acquire the signal for further analysis. This can be done by setting up your scope with the appropriate trigger (glitch, runt, etc). Now that you have the signal captured, what do you do with it? Next steps typically include analyzing the signal further, performing some measurements, involving other members of your team for debug. This might entail:
There are ways to do these tasks using features on the scope, writing a software script, or a bit of both. But they take time and programming expertise. GradientOne Automation The GradientOne approach to test and measurement automation was designed to address all of those steps each time a test is run. In this case, the you can still configure your oscilloscope manually, or you can configure it over the web. Once it is setup, you click the run button from the GradientOne web interface, and the test is run, automating steps 1-6, and providing a range of tools for post-acquisition analysis. Demo of Automated Acquisition: After the data is stored, you can easily use the the mouse and the GradientOne cursor feature to perform arithmetic calculations such as measuring the peak amplitude of the glitch. In the example below, the glitch is approximately 0.89 Volts.  The time savings for automating simple tasks is impactful on an individual level and transformative on an organization wide level. Compressing tasks that take an hour or two to a few minutes, several dozen times, during the course of a project, for a team of engineers, may mean the difference between shipping early, on time, or late. Automation with a cloud approach as the backbone can help make this happen.
A common challenge I see in many lab environments is a limited understanding of what test equipment exists in the lab. In the best case scenario, someone maintains a spreadsheet containing instrument model, vendor, serial number, calibration date, etc. But let's face it: maintaining an Excel file with what equipment is being used, what is gathering dust, what is being rented, what is being loaned out to a partner, etc.... is hard to keep up with, and will likely be inaccurate in the due course of time.  What is the best way to track these assets? GradientOne developed a feature to automate discovery and utilization of test equipment (you can read about our utilization feature here). Customers simply install our Discovery agent on the same network as their lab. Our Discovery agent subsequently monitors traffic and when it senses a new piece of test equipment on the network, it characterizes it, uploads information to the customer's GradientOne web portal, and allows the user to register the device for tracking and utilization. Take a look at the below video that shows our Discovery feature in action. 
How It Works Getting started is simple. An engineer logs into their GradientOne web interface (Figure 1), registers a Test Rig with the following information:
 Figure 1 After a Test Rig is registered, the GradientOne Agent is provisioned and installed on the Test Rig. The Agent operates in the background. It activates itself upon Test Rig bootup and reports to the GradientOne cloud platform usage of the test rig and provides integration into the scheduling system, with no involvement required by the Test Engineer.  Figure 2 The Summary page (Figure 2) provides a global, comprehensive view of all Test Asset utilization information. Filter and sort to customize views (Figure 3) based off test rig type, location, product line usage, and more.  Figure 3 View Test System utilization trends to plan for future purchases. Figure 4 shows increasing weekly utilization of a test system, alerting Engineering management of the need to procure a new system, aligning capital expense with business demand.  Figure 4  Figure 5 Scheduling is integrated to book Test Rig use for your teams. Test Engineers can check in/checkout test rigs. Test Labs can book Test Rig time and allocate it to specific customer engagements.
I recently bought a berry crumble from Wal-Mart that didn't live up to my expectations: it had way too much sugar and no oatmeal or cake batter, so the entire crumble went into the compost after a few bites. Was it that I had confused crumble with cobbler? In order to prevent wasting another 5 dollars in the future, I did what any data scientist would do: run Principal Component Analysis on text-mined recipes from the internet. I formatted the data into a table, where the first column is whether either crumble or cobbler appears in the title, and then each column is either 1 or 0 for whether the word in the header appears in the recipe's text. I uploaded and ran PCA as described in a previous post. The scatterplot of component 1 vs component 2 looks like:  From the scatterplot, there's no clear distinction between the two, except for the cluster of cobblers on the lower right-hand side. The first component is able to separate a few cobblers from the rest of the recipes using the equation: pca1 = drink*0.120 + alcoholic*0.103 + quail*0.081 + christmas*0.072 + liqueur*0.063 Turns out there is a type of cocktail called a "cobbler", and that is what this first component is successfully separating out of the recipe set. The next component is: pca2 = bake*0.353 + fruit*0.333 + gourmet*0.307 + dessert*0.217 This component is pulling out that cobblers are slightly more likely to be baked than crumbles, and are more likely to contain fruit (as opposed to vegetables). However, unlike the alcoholic cobblers, there's no clear dilineation between the two. But now that I've written the script for grabbing recipes and creating these tables, why not attempt to ask another thing I've wondered about - what is the difference between a lunch food and a breakfast food? Doing the same process, the scatterplot looks like:  It's possible to separate a lot of the lunch recipes from the breakfasts, but almost all the breakfasts overlap with the lunch space and so could be considered lunches. The first component is:
pca1 = oyster*0.390 + shrimp*0.365 + low cholesterol*0.240 + prune*0.208+ celery*0.202 + dried fruit*0.202 + parsley*0.149 + seafood*0.113 So seafood and low-cholesterol are indicators of a recipe being a lunch food and not a breakfast food. This seems right; eggs are not a low-cholesterol food, and there are few breakfast foods that involve seafood. Unlike in the crumble vs cobbler example, this first component explains far more of the variance than the next components. PCA can explain similar questions across many domains. Instead of identifying the groups of ingredients that define one different types of food, you might be identifying the common words in the human-written feedback and descriptions of failures. Or, you might be looking at the space of all descriptions of other products to find new potential products, or products that may be most familiar. For example, we might take our knowledge that breakfasts don't have seafood to open a seafood restaurant that is open in the morning in order to take advantage of an untapped market.
This blog is the first in a series on how to integrate equipment and tasks into GradientOne's API. These blog posts will use the hypothetical example of robots making shape sandwiches.
In the last post in this series, we covered generating TestPlans and Commands. Now that we have commands in the queue, we need to generate TestRigs that can execute the commands, and so that we can record the utilization. In the sandwich factory, we have stations and robots. The stations can produce only one type of shape, but in any color. The robots move the stack of shapes around from station to station, and deliver them to the delivery zone. 
Now that we have a list of commands with TestPlans, we need to find and reserve the appropriate stations and robots to complete each stack. These stations and robots will be bundled into individual TestRigs. One strategy would be to make our Testrigs contain one station of each type and a robot. However, since we have ten robots and 3 stations of each type, we would only be able to create 3 TestRigs. Since not every sandwich stack needs a station of every type, we could have more operations happening concurrently if we dynamically created TestRigs based on need.
To create a TestRig, make a post to /testrig:
from json import dumps
from urlparse import urljoin
from requests import session
equipment_ids = ["s1", "s8", "r1"]
data = {"name": "robots"+"".join(equipment_ids),
"location": "robotsandwichdemo",
"description": "robot in robot demo",
"equipment_ids": equipment_ids}
response = session().post(urljoin(BASE_URL, "/testrigs"),
data=dumps(data), headers=HEADERS)
# get the unique id for this testrig
testrig_id = response.json()["id"]
Once this testrig is created, we can record that this TestRig is in use by making a post to utilizations:
from datetime import datetime
now = datetime.now()
data = {"testrig_id": testrig_id,
"start": now.strftime("%Y-%m-%d %H:%M"),
"duration": 100, "ignore_in_use": False}
response = session().post(urljoin(BASE_URL, "/utilizations"),
data=dumps(data), headers=HEADERS)
When the sandwich stack is complete, we can record that this TestRig is no longer in use by making a new post to utilizations:
now = datetime.now()
data = {"testrig_id": testrig_id,
"end": now.strftime("%Y-%m-%d %H:%M"),
"ignore_in_use": True}
response = session().post(urljoin(BASE_URL, "/utilizations"),
data=dumps(data), headers=HEADERS)
When making our start utilization post, we set ignore_in_use to False, so that we don't double-book a testrig. When making our end utilization post, we set ignore_in_use to True, because we previously told utilizations that the TestRig was going to be used for 100 minutes, so we are interrupting our previous booking.
Now that we have logged our utilizations, we can look at the data aggregation to look for ways to optimize our sandwich factory. We'll cover this in the next post. |
RSS Feed