It has been nearly 40 years since the introduction by Hewlett-Packard of the Hewlett-Packard Interface Bus (HP-IB), designed to control instrumentation. HP-IB became a de facto industry standard formalized as IEEE-488, and also commonly known as the General Purpose Interface Bus, or GP-IB. In the past 40 years, a lot has been done to improve the software programming environment for the IEEE-488 interface. Enhancements such as the IEEE-448.2 extension to the standard defined a set of low-level bus and instrument commands that an instrument needed to support in order to be compliant.
The industry has also adopted the standardization of higher-level programming commands for instruments referred to as Standard Commands for Programmable Instruments, or SCPI, which has led to an appreciable improvement in test development time, as well as in reduced time for maintenance of existing software. Although the implementation of SCPI is widely accepted by instrument vendors, an engineer automating instrumentation is still responsible for much of the instrument coding.
Efforts to create a higher level abstraction for instrument automation led first to proprietary programming environment instrument drivers, and then to more interoperable standards-based drivers. Today’s instruments perform a variety of complex measurements and analysis, and many have been designed to operate as an application under a Microsoft operating system. Microsoft’s .NET infrastructure allows instrument vendors to enable access to the measurement science in the instrument without ever having to open the SCPI programmer’s guide, or learn how to use a specific set of drivers. The advent of instrument-controlling software hosted on a Microsoft.NET technology has provided the automation engineer with faster test software development and easier access to complex measurement science developed by the instrument.
This article will illustrate how .NET technology implemented by an oscilloscope vendor in their digital transmitter compliance test product offering has added valuable measurement science that is easily accessible by their customers’ automation code. The .NET technology has enabled the creation of a common framework utilized for building all their supported data communication compliance applications designed to tackle testing of digital transmitters per a specific standard.
The .NET technology not only aided the oscilloscope vendor’s internal developers, but also provided a very high level of abstraction for their customers to leverage for remote execution and customer automation. Today’s digital device ecosystem measurements have become more complex as devices continue to go faster and become smaller.
Until recently the automation engineer was tasked with creating the required measurement algorithms to test in accordance to a stated standard such as PCI Express, SAS and other data communication standards. Currently, customers do not have the software engineering staff to keep up with the ever-changing data communication standards. Customers now expect oscilloscope vendors to provide the software required to qualify a device as compliant to a particular standard.
In the early versions of oscilloscopes, it was common for engineers to create their own algorithms for measuring rise time or fall time of an electrical signal. It was not until the later part of the 20th century when such measurements were incorporated into an oscilloscope’s firmware. By the 1990s, engineers expected their oscilloscopes to provide basic measurement functions such as a rise time measurement. In the 21st century, a customer should seek out an oscilloscope instrument vendor that grasps the test challenges for a particular data communication standard and provides the complete measurement solution as well as ease of access through their own automation code. An oscilloscope vendor’s product offerings should demonstrate an ongoing investment in measurement science designed to address current and future data communication standard’s requirements.
An oscilloscope vendor incorporating additional measurement science into their product offerings is usually an active member of standards bodies such as PCI Express, SATA, JEDEC and the USB-IF. The active participation in these standards enables the vendor to help define test specifications, which are intended to ensure interoperability of devices supporting a particular standard. Once the test requirements are defined, the oscilloscope vendor can implement the various measurements defined per the standard and add it to their oscilloscope’s software offerings.
A customer can now access a standard test suite of software enabled by .NET technology from the oscilloscope vendor for qualifying their device compliance to a particular data communication standard. In addition to providing an easy GUI for the customer to utilize the oscilloscope, the software platform should also enable full remote control access.
An oscilloscope vendor providing test suites for a variety of data communication standards greatly increases the productivity of the customer’s engineering staff. The oscilloscope vendor assumes responsibility for interpreting the test specifications of a standard, and is tasked to develop the measurement software suite and provide technical support. Additionally, having the oscilloscope vendor to provide the measurement software suite enables better correlation of test data between a customer’s own engineering teams and their customer’s teams knowing all parties are using the common tests and algorithms.
Figure 1 is an example of a software suite that exposes the available tests defined in the DDR4 computer memory standard. The customer selects the tests of interest, and the appropriate measurements and algorithms are implemented by the oscilloscope vendor’s automated software. It is important to look for an oscilloscope vendor that provides the same look and feel for all their standards-based measurement software. A DDR4 software test package should have the same look and feel as one for PCI Express, thus increasing the efficiency and productivity of the end user.
A complete software suite for testing to a data communication standard should produce data in a readable form such as the example below in Figure 2. An HTML report including screen shots where it is applicable for all tests executed with pass/fail/margin information creates great value to the customer for sharing with their own engineering teams as well as with their customers.
The 21st century oscilloscopes are now viewed as measurement systems that include state of the art probing for access to signals not accessible by a direct RF cable. FPGA-based algorithmic engines bolstered by access to external scripting languages along with math libraries are needed to analyze and produce many of the measurement values required by modern digital devices. It is not only important to access the desired tests through an interactive GUI as illustrated in Figure 1; but it is equally important to be able to execute the tests from the customer’s automation code.
The automation engineer may also need to control power supplies or environmental chambers before running a prescribed test as well as integrating measured data into a corporate data base. An oscilloscope vendor that can provide a seamless automation interface to the same features exposed in the interactive GUI provides not only great value to the automation engineer, but more importantly better utilization of the companies engineering resources.
A software framework that is built on .NET technology allows the automation engineer to access all the features in the oscilloscope vendor’s measurement software designed for a data communications standard. Moreover, it enables engineers to hook into asynchronous runtime events in order to integrate automation of supporting instruments, for example by programmatically responding to the message prompt, “Change the power supply output to 1V and click ‘OK’ to continue”. These events no longer need time-consuming manual intervention.
The following example in Python of how the use of a .NET assembly can provide a perfect level of abstraction to the automation engineer without burdening the engineer with the details of setting up test conditions, managing test flow and ultimately measured data management. Microsoft’s Common Language Runtime engine enables easy loading of a .NET assembly from a variety of programming languages such as Visual Basic, C#, C++ as well as graphical programming languages such Keysight’s VeePro, NI’s LabWindows and LabView.
In addition, .NET technology can be extended to cover a broad range of automation tasks including controlling environmental chambers, communication to the device under test, switch matrices and of course other instruments beyond an oscilloscope. import clr
from Keysight.Infiniium.AppFW.Remote import *
Required to connect to the oscilloscope via an Ethernet connection for access to the methods and proprieties exposed in the .NET assemblies.
remoteObj = RemoteAteUtilities.GetRemoteAte("192.168.1.107")
remoteApp = IRemoteAte(remoteObj) The object named remoteApp can now access all the features of the particular measurement software suite for the selected data communication standard as if it was being done interactively from the GUI of the test suite. The following illustrates the code needed by the automation engineer to create a new project analogous to performing File->New Project from the GUI of the measurement software suite. remoteApp.NewProject(True)
The following retrieves the identical information that was presented in Figure 1 when executing the measurement software suite interactively. Once the automation engineer knows the tests available, they can be selected programmatically similarly to placing a check box next to the test names in Figure 1. In fact, the GUI will reflect what the engineer programmed remotely, aiding greatly in code debug.
myAvailableTests = remoteApp.GetCurrentOptions("TestsInfo")
for info in myAvailableTests: // The following for loop extracts the available test names and test ids
myTestName = info.Name
myTestId = info.ID
testToSelect = myAvailableTests.ID // The first test in available tests is selected to execute
remoteApp.SelectedTests = [testToSelect]
The following executes the selected test and creates the HTML report as illustrated in Figure 2. The file MY_HTML is created in the C:\data folder.
descriptionHtmlString = 'MY_HTML'
saveResultHtmlOptions = ExportHtmlOptions()
saveResultHtmlOptions.ReportName = descriptionHtmlString
saveResultHtmlOptions.OverwriteExisting = True
saveResultHtmlOptions.BasePath = "C:\data"
A critical piece of documentation for efficient use of the .NET assembly is a complete and up-to-date help file from the oscilloscope vendor. An excerpt from a help file below defines what options are available when creating an HTML report. The options are implemented in the above Python example.
ExportHtmlOptions Properties Keysight DigitalTestApps Remote Interface for .NET
The ExportHtmlOptions type exposes the following members.
Better still are in-GUI tips, which answer questions such as, “Which automation command clicks this checkbox?”.
Companies can no longer afford to expend precious engineering resources to understand all the test requirements for a particular data communication standard, and subsequently funding the development of the software necessary for making the measurements dictated by a data communication standard. Once the oscilloscope vendor becomes the provider of the measurement software suite for a particular data communication standard, the customer’s engineers can quickly focus on gaining valuable insight about their products from the measured data generated by the measurement software suite. The ability to correlate data taken from different oscilloscopes hosting a common version of the measurement software suite improves the customer’s engineering staff’s productivity.
Customers will continue to look to oscilloscope vendors to provide an oscilloscope as a measurement system, which includes connectivity solutions to their device such as probes, measurement software suites that address the various data communication standards, and a high level abstraction of the measurement software suite—thus enabling automation engineers to easily control the execution of the measurement software suite from their internal automation software.
Questions or comments on this story? Contact firstname.lastname@example.org