USB Test and Measurement Class (USBTMC) instrument emulator
USB Test and Measurement Class or USBTMC instruments are defined initially to allow General Purpose Interface Bus-style (GPIB-style) communication over USB using USBTMC compliant Virtual Instrument Software Architecture (VISA) layers. The standard defines protocols that are used to send instrument command messages to an instrument and read back response messages. Most USB-based instruments available today adhere to the USBTMC standard. These instruments are mostly programmed via Standard Commands for Programmable Instruments (SCPI) or similar text messages, comparable to what you would expect from a GPIB instrument.
Keysight IO Libraries will be able to enumerate and discover the USBTMC instruments by making use of the standard USBTMC class device driver in windows. These USBTMC instruments will be detected as “USB Test and Measurement Devices” in the windows device manager and appear in the Keysight IO Libraries with a VISA address assigned, as shown in Figure 1. With that, users can start to communicate with these USBTMC instruments using the VISA address. This article will demonstrate how a mechanism can emulate a USBTMC instrument on a Microsoft Windows computer and work exactly like a USBTMC instrument without having any USB devices plugged in to the Microsoft Windows computer.
Microsoft has introduced the new USB Device Emulation (UDE) architecture in the Windows 10 operating system, which allows any hardware devices such as a PCIe device to be emulated as a USB device. The UDE architecture is described in Figure 2. UDE is designed by Microsoft to work by creating another set of USB host side software, refer to Figure 2. This special set of host side software will have its own emulated USB host controller and emulated USB client driver. It will allow any other hardware in the computer to be emulated as a USB device. For example, a PCIe device will be able to emulate as a USB device. The main advantage the test and measurement industry can make use of UDE is to have a USBTMC emulator. From my point of view, there are 3 ways USBTMC emulator can be beneficial:
- Work as a virtual USBTMC instrument.
- Collecting valuable big data.
- Allow PXIe or AXIe modular instruments to also support USBTMC interface.
How to emulate a USBTMC instrument
We can simulate a USBTMC device by implementing UDE in a normal PCIe kernel device driver. The steps to implement a simulated USBTMC instrument are:
- Refer to Figure 3, the idea is to implement a PCIe device driver that has UDE. This PCIe device driver is able to read information like the USB descriptor and endpoint the instruments it would like to simulate from registry and text files. It also communicates with a user mode application that can act as a “virtual instrument”.
- Since we are simulating a virtual USBTMC instrument in this case, the PCIe hardware can be any PCIe device in the computer that is not used. In this case, I selected the “Intel® Active Management Technology – SOL” which is available in most computers as shown in Figure 4. It is not required to write to the hardware registers of the PCIe device, it doesn’t matter which device is utilized. Just use the Vendor Identification (VID) and Product Identification (PID) of the PCIe hardware to install the PCIe device driver as shown in Figure 4.
- The PCIe device driver will implement all the normal entry point functions such as DriverEntry, DeviceAdd, DeviceCleanup, DevicePrepareHardware, DeviceReleaseHardware, IoDeviceControl and so on. Steps 4 to 9 further describe the implementation of this PCIe device driver.
Figure 3: Virtual USBTMC instrument architecture.
- In the DeviceAdd function, initialize the emulated USB host controller for UDE. This will allow the driver to receive and handle IOCTL commands for the emulated USB host controller.
- The last step in the DeviceAdd function is to create a virtual USB device. A virtual USB device behaves similar to a real USB device. It supports a configuration with multiple interfaces and each interface supports alternate settings. All descriptors (device, configuration, interface, endpoint) are set by the UDE client driver so that the device can report information much like a real USB device.
- The virtual USB device is created and handled by the UDE Client Driver described in Figure 2. It creates and reports descriptors and endpoints just like the firmware of a USBTMC instrument.
- All these descriptors and endpoint information is read from external registry or text files.
- Next is to create control, interrupt, bulk in and bulk out endpoints with a callback to handle the responses to commands like “*IDN?”.
- If these descriptors and endpoints are similar to descriptors and points reported by the respective USBTMC instrument, the device driver will be able to simulate a USBTMC instrument. It will show up as “USB Test and Measurement Device” in the windows device manager as shown in Figure 5.
Figure 4: Driver for Intel® Active Management Technology – SOL. Figure 5: Discovery in windows device manager and KCE. - Keysight IO Libraries will also be able to recognize the simulated virtual USBTMC Instrument based on the response on the descriptor reported as shown in Figure 5. The screenshot is simulating 34461A USBTMC instrument.
- The user mode application “virtual instrument” is created to communicate with the PCIe device driver through a few IOCTL commands such as READ_SCPI_CMD and REPLY_DATA to the PCIe device driver.
- “Virtual instrument” will be able to reply to the SCPI commands it received and reply back with whatever data it tries to simulate.
The architecture described above has already taken into consideration its capability to simulate different USBTMC instruments required by users. By having the 2 extra components of “reading from registry, USB descriptor files and USB endpoint files” and “virtual instrument”, this will significantly enhance the user friendliness of the USBTMC instrument emulator. It allows users to easily simulate the USBTMC instruments they wanted without making changes to the PCIe device driver. What users need to do is to change the registry, USB descriptor files and USB endpoint files to simulate the USBTMC instrument they want. Also, users will need to add in code in the “virtual instrument” user mode software application to simulate how their “virtual instrument” software wants to behave and react to the SCPI commands received.
All these USB descriptor files, USB endpoint files and registries will have to follow a certain predefined standard format that the kernel driver can comprehend. Also, the “virtual instrument” will have some predefined APIs to communicate with the PCIe device driver in kernel mode by also using predefined IOCTL commands. This is to allow special information such as data and certain SCPI handling mechanisms to be parsed into the kernel driver in order to properly simulate a virtual USBTMC instrument. For example, the SCPI parser can be integrated into this “virtual instrument” to process SCPI commands if required. This “virtual instrument” should be able to behave exactly like real USBTMC firmware, except that there is no real hardware for it to read and write from.
Benefits and use models of Virtual USBTMC instrument
With the virtual USBTMC instrument enumerated and discovered by Keysight IO, what are the potential uses of the virtual USBTMC instrument? There are 3 main areas that could make use of virtual a USBTMC instrument:
- Work as a virtual USBTMC instrument: Cost savings when engineers develop software applications – engineers can develop test and manufacturing software applications by making use of virtual USBTMC instrument without having to purchase a lot of instruments during development phase.
- Collecting valuable big data: The “Virtual instrument” will receive SCPI commands and respond to these SCPI commands from test software applications. This allows it to have a choice in deciding what to do with these SCPI commands. The fact that this “virtual instrument” is a user mode application allows it a lot of flexibility on what to do with the data such as SCPI commands passing through it.
- Allow PXIe or AXIe modular instruments to also support the USBTMC interface: Modular PXIe and AXIe instruments are PCIe based instruments. Each of the PXIe and AXIe instruments will come with a PCIe endpoint and have a kernel PCIe device driver to control it. A modular instrument is different from a USBTMC instrument in the sense that it does not support SCPI commands. Control of modular instruments is done through an IVI driver, which performs hardware control through reading or writing PCIe hardware registers.
Figure 6 shows that data will flow from test software that is sending a SCPI command to the VISA address of the emulated USBTMC instrument through Keysight IO Libraries. This SCPI command will flow through the PCIe device driver, which emulates a USBTMC instrument, to then reach the “virtual instrument”. The “Virtual instrument” can choose to record the SCPI command it received and have a timestamp to show the time it received this command in a file. Since the “virtual instrument” is a user mode software application just like the test software, it can also send this SCPI command to a real USBTMC instrument VISA address through Keysight IO Libraries by using the VISA Application Programming Interface (API). This SCPI command is then processed by a SCPI parser in the firmware of the real USBTMC instrument. The response data will be returned from the real USBTMC instrument to the “virtual instrument” through the VISA API. It can also record down the real instrument response data to the same file and have a timestamp to show the time it received this response data.
After that, the “virtual instrument” will then return this data to the PCIe device driver. The PCIe device driver will then return the response data to the test or manufacturing software through the VISA API by Keysight IO Libraries. The whole process is similar to communicating directly with the real USBTMC instrument from the test or manufacturing software point of view. It will not realize that there is a “virtual instrument” in between that captures data it sends and receives.
If we install this “virtual instrument” in one of the computers of a manufacturing facility for one day, it will be able to record all the SCPI commands and response data that goes through to the real USBTMC instrument. This record will be able to show the utilization rate of this particular USBTMC instrument for this entire day. Based on this, if we install this “virtual instrument” to all the computers with real USBTMC instruments in the manufacturing facility, then the utilization rate of all USBTMC instruments for the entire manufacturing facility will be recorded. With this information, the efficiency of the manufacturing facility can be improved by improving the utilization of these instruments.
Besides this, the “virtual instrument” can also playback the data it recorded. As described previously, the role of “virtual instrument” is to receive SCPI commands and respond back. It can respond back to SCPI commands from the same manufacturing software by reading from the data it recorded in previous day. With that, it can simulate the manufacturing facility activities of the entire day. This will help to simulate a virtual factory for users to analyze the activities in a factory and find ways to improve efficiencies.
Adding the UDE components to the existing PCIe device driver of modular PXIe and AXIe instruments allows these instruments to also support a USBTMC interface that accepts SCPI commands and works like USBTMC instruments. This is different than the virtual USBTMC in the sense that it is not just simulated instruments. It is modular PXIe or AXIe instruments that support the USBTMC interface and discovered by Keysight IO Libraries as both modular PXIe and AXIe and USBTMC instruments.
The steps for PXIe and AXIe instruments to support a new USBTMC interface is similar to the steps mentioned in virtual USBTMC. Instead of a PCIe driver just for installation, use the existing PCIe driver for the modular PXIe and AXIe instruments. Just add the UDE to emulate a USBTMC instrument interface to a current existing PCIe driver for the modular PXIe and AXIe instruments as mentioned in steps 3 to 9. Then, add a SCPI parser so that it can process SCPI commands by reading and writing PCIe hardware registers to simulate a USBTMC instrument. The overall architecture is described in Figure 7.
With all these steps implemented, device managers will have the Keysight Technologies’ Modular Device class PCIe driver appear and also the USB Test and Measurement Device appear. Keysight IO Libraries will also have both the PCIe device and the USBTMC device discovered as shown in Figure 8. Both of the interfaces will have different VISA addresses for users to interact with. Again, Figure 8 is shows the modular M9545A instrument emulated as a 34461A USBTMC instrument.
The main benefit for modular PXIe or AXIe instruments to have a USBTMC interface is to allow SCPI commands to be used by customers instead of an IVI driver. There are two reasons for this:
- The PXIe/AXIe instrument is developed from an existing USBTMC instrument. There are existing customer applications that have been developed and they would want it to continue to work without investing resources to port it over to an Interchangeable Virtual Instrument (IVI) driver.
- Customers wanting to use USB programming interface or SCPI commands to be compliant with their existing software system.
Conclusion
USBTMC was introduced in 2002 for programmable control of USB-based test instruments. The standard has been widely adopted by many test and measurement industry instruments. Many customer’s factories and test systems are making use of this standard to operate production daily. The USBTMC instrument emulator will be able to help in terms of cost savings by emulating virtual USBTMC instruments during the factory software system development phase. Furthermore, it can help in collecting valuable big data on instrument utilization in factory. Another important contribution is to allow modular PXIe and AXIe instruments to support a USBTMC interface and at the same time support the SCPI commands to be backward compatible with traditional boxed instruments.
References
[i] USB Device Emulation (UDE) – https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-emulated-device–ude–architecture
[ii] Write a UDE Client Driver – https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/writing-a-ude-client-driver
[iii] Using USBTMC to communicate with you USB instrument – https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NsmSAE&l=en-US
[iv] Programming USB instruments – https://literature.cdn.keysight.com/litweb/pdf/5989-6582EN.pdf
About the Author
Kok Kuan is an R&D software architect at Keysight’s Design and Engineering Division. His main expertise includes Windows device drivers and firmware. He has worked on modular instrument drivers and firmware for the past 10 years since joining Keysight in 2010.
Prior to his current responsibilities, Kok Kuan has been working on Solid State Drive firmware as a senior firmware engineer at STEC Technology (2007-2010), USB/PCIe to GPIB converter device drivers at Agilent Technologies (2005 – 2007), graphics drivers at Intel Corporation (2000 – 2005) and as a product engineer at Integrated Device Technology (1999 – 2000).
Kok Kuan graduated from the University Science of Malaysia with a bachelor’s degree in electrical and electronics engineering.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
