3.0 Communication [T-Series Datasheet] | LabJack
« Close

Datasheets and User Guides

App Notes

Software & Driver


3.0 Communication [T-Series Datasheet]


T-series devices communicate through a protocol named Modbus TCP, which is used via USB, Ethernet, and WiFi (T7-Pro only). "Modbus TCP" is commonly shortened to "Modbus" in this document.

Modbus TCP is a protocol where values are written to and/or read from Modbus registers. Any given Modbus register is readable, writable, or both.

A T-series device is a Modbus server—all configurations and data are read from or written to Modbus registers. Thus, the process for reading the serial number, an analog input, or a waveform is functionally the same, you simply access a different address.

T-series devices provide a flexible interface. Modbus registers can be accessed by various clients.

Communication Options

The software used to communicate with a T-series device depends on what tasks need to be performed.


Applications are appropriate for common and simple tasks.

LabJack Kipling provides a graphical interface for many types of device configuration. It also provides a Register Matrix which can read or write arbitrary register values.

LabJack LJLogM periodically samples and logs data.

LabJack LJStreamM streams data at much higher sampling rates.

High-level LJM library

Programming with the LJM library is appropriate for custom, complex, and automated tasks.

LJM is a cross-platform library which allows users to access registers by name, such as "AIN4" for analog input 4. With example code in over a dozen different programming languages, it is possible to integrate the T4 and T7 into a variety of existing software frameworks.

Example workflow:

    1. Open a connection to the T4/T7.
    2. Read from and write to Modbus registers.
    3. Close the connection.

Direct Modbus TCP, Clients

T-series devices are Modbus TCP servers.  Any software capable of acting as a Modbus TCP client can read from and write to a Modbus TCP server.  For example, all software we know of that describes itself as "SCADA" is capable of being a Modbus TCP client and can talk to T-series devices.

It is straightforward to integrate a T-series device, over Ethernet or WiFi (not USB), into standard commercial off-the-shelf (COTS) Modbus client platforms. People who already use Modbus software will find this option convenient. Some COTS Modbus clients are very powerful, and will save users the time and money required to develop their own software.

A Modbus TCP client can read/write any single-value numeric register without any driver software or libraries from us.  More complex registers such as strings and arrays will be difficult if not impossible to use from a standard Modbus client, which notably prohibits stream mode and serial protocols.  Custom Modbus clients, however, can realize all functionality.

Typical workflow:

    1. Configure the power-up-default registers on the T4 or T7 using the Kipling software program. Change Ethernet/WiFi IP settings, any relevant analog input settings, etc. Note that '..._DEFAULT' registers indicate that they are power-up-defaults.
    2. Open COTS Modbus client program.
    3. Specify the Modbus registers by address, such as 6, for AIN3. Find applicable registers with the register look-up tool (Modbus map), or by referencing the datasheet etc.
    4. See data directly from the T4 or T7 in COTS software.

For more details, see the Software Options page.

Communication Speed Considerations

There are two alternate methods for data transfer to occur.

  • Command-response offers the lowest latency.
  • Streaming offers the highest data throughput.

The LJM library simplifies both command-response and stream mode.

COTS Direct Modbus software uses command-response and is unlikely to be capable of stream mode.


This is the default mode for communication with a device. It is the simplest communication mode.

Communication is initiated by a command from the host which is followed by a response from the device. In other words, data transfer is paced by the host software. Command-response is generally used at 1000 scans/second or slower, which is often a sufficient data throughput.

Command-response mode is generally best for minimum-latency applications such as feedback control. Latency, in this context, means the time from when a reading is acquired to when it is available in the host software. A reading or group of readings can be acquired in times on the order of a millisecond. See Appendix A-1 for details on command-response data rates.

Stream Mode

Stream mode is generally best for maximum-throughput applications. However, streaming is usually not recommended for feedback control operations, due to the latency in data recovery. Data is acquired very fast, but to sustain the fast rates it must be buffered and moved from the device to the host in large chunks.

Stream mode is a continuous hardware-paced input mode where a list of addresses is scanned at a specified scan rate. The scan rate specifies the interval between the beginning of each scan. The samples within each scan are acquired as fast as possible. Since samples are collected automatically by the device, they are placed in a buffer on the device, until retrieved by the host. Stream mode is generally used when command-response is not fast enough. For the T7-Pro, stream mode is not supported on the hi-res converter (resolutions 9-12 not supported in stream).

For example, a typical stream application might set up the device to acquire a single analog input at 100,000 samples/second. The device moves this data to the host in chunks of samples. The LJM library moves data from the USB host memory to the software memory in chunks of 2000 samples. The user application might read data from memory once a second in a chunk of 100,000 samples. The computer has no problem retrieving, processing, and storing, 100k samples once per second, but it could not do that with a single sample 100k times per second. See Appendix-A-1 for details on stream mode data rates.

Command-response can be done while a stream is active, but streaming needs exclusive control of the analog input system, so analog inputs (including the internal temperature sensor) cannot be read via command-response while a stream is active.