3.1 - Command/Response [U6 Datasheet] | LabJack
« Close

Datasheets and User Guides

App Notes

Software & Driver


3.1 - Command/Response [U6 Datasheet]

Everything besides streaming is accomplished in command/response mode (CR), meaning that all communication is initiated by a command from the host which is followed by a response from the U6.  The low-level Feedback function is the primary UD function used in CR activities and is limited to 64-bytes per data packet (command and response).  CR commands requiring more than 64 bytes will result in multiple CR packets between the host and the U6.  Table 3.1.1 lists typical measured execution times for various tasks (no analog IO), using CR mode, assuming a single CR data exchange (< 64 bytes).


Table 3.1.1. Typical communication overhead for typical U6/host connections.


Testing Procedure and Definitions:

The times in table 3.1.1 were measured using the example program “allio.c” (VC6_LJUD) or similar (Firmware 1.43, LJUD 3.45). The program executes a loop 1000 times and divides the total time by 1000.  The resulting round-trip communication time includes Windows latency, UD driver overhead, communication time, and U6 processing time.

A "USB high-high" configuration applies to setups where the U6 is connected to a high-speed USB2 hub which is then connected to a high-speed USB2 host.  The U6 is not a high-speed USB device.  However, placing a high-speed USB2 hub between the U6 and host will improve communication performance.

A "USB other" configuration applies to setups where the U6 is connected directly to the USB host (your PC) or if the U6 is connected to an old full-speed hub (hard to find).  Connecting the U6 directly to a high-speed USB2 port on your PC does not constitute a "USB high-high" connection.  Performance times shown in the "USB Other" column apply to all direct connections between the U6 and host.


Preemptive Operating Systems and Thread Priority:

It is important to understand that Linux, Mac, and Windows are generally "best-effort" operating systems and not "real-time", meaning that the listed CR speeds can vary based on each individual computer, the hardware inside of it, its currently enabled peripherals, current network traffic, design of the application software, other running software, and many more variables [1].


ADC Conversions:

Analog to digital conversions (ADC) will increase the command response time depending on the number of channels, input gain, and resolution index being used.  Table 3.1.2 lists the conversion times for the U6 at various gains and resolution index settings, reading a single analog input channel.  The total command response time (CRT) when reading analog inputs is equal to the overhead time from tables 3.1.1 added to the conversion times from Table 3.1.2 (per channel being read) .  Please review table 3.1.1 and 3.1.2 carefully, as the listed times will determine the maximum sampling rate achievable when reading analog inputs in command response mode.

CRT (milliseconds) = overhead + (#AINs * AIN Sample Time)


Table 3.1.2.  Effective resolution and sampling times for various gains and resolution index settings. Resolution index settings 9-12 apply to the U6-Pro only.

Figure 3.1.3.  Analog input effective resolution over various gains and resolution index settings.

Figure 3.1.4.  Analog input LSB voltage over various gains and resolution index settings.

Figure 3.1.6.  AIN sample times for analog inputs over various gains resolution index settings.


Estimating Command/Response Times

The following examples demonstrate how to estimate the CRT for single and multiple command/response data sets.

Example 1 - Read four analog inputs at G=x100 and Res=1 with a "USB Other" connection:

The expected overhead for a "USB Other" configuration is 4.0 ms (Table 3.1.1) and the sampling time at the specified gain and resolution is 1.04ms (Table 3.1.2).  The CRT is then:

     CRT = 4.0ms + (4 x 1.04ms) = 8.16ms


Example 2 - Read four analog inputs at G=x100 and Res=1 and set both DACs with a "USB Other" connection:

The given configuration is the same as Example 1 with the additional writes to the two DACs.  Table 3.1.1 lists the DAC read as 4.12 ms which includes all overhead.  The CRT is:

     CRT = 4.12ms + (4 x 1.04ms) = 8.28ms


Example 3 - Read 16 analog inputs at G=x100 and Res=1 with a "USB high-high" connection:

The overhead and analog sample time for the given configuration is 0.60ms and 1.04 ms, respectively. Unlike the previous examples, reading 16 analog channels requires multiple CR data exchanges.  The Feedback function can transmit/receive up to 64 bytes for a command and response packet.  Handshaking data accounts for a small portion of the data packet and thus command packets are limited to 57 bytes and response packets to 55 bytes for data (see Section 5.2.5).  Analog reads use the AIN24 low-level IO type which requires 4 command bytes and 3 response bytes (see section Section  With this in mind, the maximum number of analog reads that will fit into a single CR command packet is 14, limited by command bytes (14 x 4 < 57).  The resulting CR transmissions will therefore consist of two separate transmissions: one 14 channel read followed by a two channel read.  The CRT is calculated as:

     CRT = {0.60ms + (14 x 1.04ms)} + {0.60 + (2 x 1.04ms)} = 17.3ms


1.  Various software issues need consideration when implementing a feedback loop that executes at the desired time interval.  Some considerations are: thread priority, logging to file, updating the screen, and other programs running on the machine.



LJlogUD shows 000.000 on channel 193 fro the digital inputs.

When writing to file I miss the a file header

Those special channels from Section 3.2.1 were originally just supported in stream mode, but we are in the process of adding them to command/response mode.

Are you saying you want the LJLogUD data file to have a header like the LJStreamUD data file?  We will see if we can add that at the same time.


thank you very much for your answer. I am a very new user of Labjack.

I just tried a few tests to see how it works. I am very happy with the U6 and with the LJlogUD and the LJstreamUD. As far as I have seen, I can do what I intend to do.

The electric brake on a 45 year old railway motorcoach does not work properly. Is regulation is done by using "transductors" . I would like to find and fix the fault. So I need to measure up to 14 analog currents and voltages and up to 16 DI. The sampling rate I want to use is 200 ... 1000 Hz per channel (even 3333 Hz were working yesterday). With the labjack U6 and LJstramUD I can do it. Thank you very much for these features. There are just a few questions about it, which I posted yesterday. 

-I would prefer, when the file created by the LJlogUD and LJstreamUD look the same. Its easier for further calculation with other programs.

-The LJstreamUD does give the right value for the internal temperatrure but not the right value for the DI when not streaming. When streaming, the internal temperature is wrong but the DI are correct.

-The header of the file created by the LJstreamUD is wrong (U9 instead of U6)

- I found the reason, why all the alues are saved twice in the file. (once original measured values, once scaled values)


thank you very much and have a nice weekend.

Kind regards

Does performance really improve by adding an extra device between the U6 and the computer? When you refer to High-High USB using a highspeed hub, should the hub be a powered hub or would a non powered hub give the performance improvement also?



Yes, we really see this improvement.  We suspect it is because the hub talks full-speed to the U6, but talks high-speed to the host, and thus the host is more efficient.

Speed should be the same whether the hub is self-powered or bus-powered.  For other reasons, though, we always recommend self-powered hubs over bus-powered whenever you have a choice.

If I have multiple U6's connected to one PC, is it sufficient to connect them all to one hub to see the performance improvements, or do I need to connect each of them to a separate hub?

I can't say we have tested that scenario, but my guess is that the performance would be similar using 1 hub or 2 hubs.  The benefit seems to be due to the fact that the hub translates the full-speed USB from the U6 to high-speed USB between the hub and host.

Note that USB is a serial bus, so at the lowest level it will only send a packet to one of the U6s at a time.  So in theory we might expect that overall data rates would decrease, but a single U6 only uses a small portion of the available USB bandwidth so that is not necessarily true.

Finally got my U6. I tested it with LJ Control Panel and everything seems ok. But then I tried U6_AllIO.vb in VS 2010, Win7 using USB High-High and in "Milliseconds per Iteration" I get numbers like 76418.34 or 87234.63. The longer the U6 stays connected the larger the number gets when I run U6_AllIO.vb. What does this number mean? I was expecting something like 1.12 or 4.05.



This is a bug in that example.

You see around line 265 it is storing the Environment.TickCount into the variable 'time' before doing all the iterations, then after it is done (100 iterations is the default) it again stores that value into time.  What it should be doing, is storing it first into one variable, then again into a second variable, then when it is displayed, it should subtract the first from the second and then divided by numIterations. If you make this change you will see the value drop to around 65 ms or so.  This is still higher than 1.12 or 4.05 since it is doing all the different IO operations, multiple analog inputs, reading the timers & digital ports, etc.  If you change the code to just read a single analog input or two you should see the values you are expecting.

We will make sure this bug gets fixed in the next release of the examples.

Yes that was the problem, working OK now, thank you!

I need the LabWindows CVI U6 USB command, anyone can help!

LabWindows CVI is a C environment.  You will make calls to the UD driver as documented in Section 4 of the U6 User's Guide.  Start with the LabWindows/CVI archive for the UD driver, and also refer to the C archive for many other examples easily adapted to LabWindows CVI.