USBTMC Data Acquisition Device Firmware

[msol]

Hello,

I am trying to develop a simple data acquisition device that can interface with Labview using the USBTMC protocol.  Following the USBTMC and USBTMC-USB488 specs, I have implemented the code to process Bulk-Out endpoints with all required message IDs. However, I am a little confused about how NI-VISA actually interracts with a device.  When a viWrite or viRead command is issued, what specific messages are sent to the device on what endpoints, and what is the expected response from the device? What would be the typical process for aquiring large quantites of data from a USBTMC device? If you can clear any of this up for me, it would be greatly appreciated!

Thanks,

Mike 

[PeterGC]

msol,

The viRead/viWrite commands are device specific.  They send specific commands based on what you have specified your end device to be.   Sometimes you need to edit the protocols to match what the device is able to understand.

Here is a guide to VISA programming

http://www.ni.com/pdf/manuals/370132c.pdf

Hope this helps,

Pete

[Makoto · Accepted solution]

When the host issues viWrite call, the 12byte USBTMC_BULKOUT header followed by your SCPI string shall be sent to the BULKOUT endpoint of your firmware. In this case, USBTMC_BULKOUT header contains MsgID=1.

When the host issues viRead call, the 12byte USBTMC_BULKOUT header shall be sent to request for reading to the BULKOUT endpoint. In this case the MsgID=2 and the length is only 12 bytes all. Then your firmware , if a response string is ready, shall set the USBTMC_BULKIN header followed by the SCPI response to the BULKIN endpoint for sending out.

viWrite generates a BULKOUT transaction, and viRead generates a BULKOUT transaction plus BULKIN transaction.

example:

viWrite( "*IDN?\n") -- generates a bulkout transaction as [12 + 6 + 2] bytes. (last 2 bytes are padding for 4-byte align)

Correcponding viRead() -- generates a bulkout as [12] bytes, then the firmware shall set bulkin data as [12 + response + padding].

Makoto

[msol]

Thanks for both of the replies. Makoto, that was exactly what I was looking for.

[Makoto]

You are welcome, I forgot to answer about how to handle large amount of data to send out to host.

When the host issued viRead() call, your firmware receives a USBTMC_BULKOUT packet having MsgID=2. In this case your firmware must check the length info which describes how many bytes shall be returned back to host in maximum. For example, when viRead() only requests 3 bytes to read for "*IDN?\n" query, the first 3 bytes shall only be responded (in this case the first 3 letters of your vendor name). Then remaining data that was not responded shall be kept in the sending-buffer of your firmware. If the host continuously issued viRead() without issuing a new viWrite() call, your firmware must answer the remaing part. Otherwise if the host issued a new viWrite() without reading remaining part, your firmware shall flush the sending-buffer. (IEEE4882 rule)

As for large amount of data, for example such like 16KB block data, the host may or may not request whole size in viRead() call.  In most cases, your firmware will have to answer over 64-byte data following to USBTMC_BULKIN header must be sent out in a transaction. Normally BULK endpoints have 64byte payload limitation, so your firmware may have to split the large data into multiple packets (multiple 64byte packets and a short or 0-length packet). But you may or may not have to write split-sending code for each BULK-IN packet, because it is up to your USB device peripheral and its device driver functions.

Example (Firmware will answer 181 byte SCPI response):

(1)Host issues viRead(100)

(2)Firmware receives USBTMC_BULKOUT with MsgID=2, MaxLength=100

(4)Firmware sends  [12 + 100 + 0padding] to BULKIN

  (In this case assumes the driver can handle split 64byte packets automatically)

(5)Host issues viRead(100) again

(3)Firmware receives USBTMC_BULKOUT with MsgID=2, MaxLength=100

(4)Firmware sends [12 + 81 + 3] to  to BULKIN

  (In this case assumes the driver can handle split 64byte packets automatically)

Makoto

[msol]

Great, thanks! Now I am running into another issue... The device is recognized as a USBTMC device and shows up under "USB Test and Measurement Devices" in device manager, but VISA Interactive Control and MAX do not list it.  Any idea what may be causing this issue?

When I run the driver wizard, I get the following message:

"This device is a member of the USB Test and Measurement Class (USBTMC). NI-VISA can already detect and control it. Do not use this wizard to create an INF file"

[Makoto]

First you better to check what version of NI-VISA is running and what USB device driver is hosting your device.

When using NI-VISA 5.x, any USBTMC devices must be hosted by "ausbtmc.sys" (check it at Device Manager), which is common for all recent VISA versions including NI-VISA, Agilent IO, KI-VISA, etc. The driver is provided by IVI Foundation as a part of VISA Shared Components, which is also bundled with recent VISA setup program. (The VISA Shared component can also be installed separately, found at http://www.ivifoundation.org download page.)

I dont know what is being checked by NI-VISA / NI-MAX program to recognize the device as USBTMC, but I think at least the following conditions must be met:

(1) the device is hosted by ausbtmc.sys (assuming NI-VISA is 5.x)

(2) the device must have at least 1 bulkout, 1 bulkin endpoints, and optionally one intr-in endpoint.

(3) the device must correctly set DEVICE DESCRIPTER and CONFIG DESCRIPTOR with USBTMC-USB488 class values.

(4) the device must respond to GET_CAPABILITIES class request.

(5) the device must respond to *IDN? query through bulkout/bulkin.

The USB driver wizard provided by NI is for non-USBTMC devices, so you dont have to (or shall not) use it for your USBTMC device.

Makoto

[msol]

Thanks again.  My problem ended up being that I was using a serial number of 0 in the device descriptors.  While re-reading through the USBTMC spec, I noticed that it mentioned that the serial number must be non-zero and when I changed it the device showed up. 

[ViSoft]

Hello msol,

I am trying to implement the USB-TMC into the V-USB device (http://www.obdev.at/vusb/).

Since I am new to USB, it is a challenge to me.

May You please send me the source code for studying purposes?

BR,

ViSoft