« Close

Datasheets and User Guides

App Notes

Software & Driver


3.0 Communication

Communication Overview

Modbus TCP is the protocol used by all connections on the T7(USB, Ethernet, WiFi).   All important values and data from the device can be read and/or written by using the associated Modbus register(s). Thus, the process for reading the serial number, an analog input, or a waveform is all functionally the same, you simply provide a different address. There are two main ways to communicate with a T7 using Modbus TCP.

Communication Options

High-level LJM library

Among other useful features, this cross-platform library 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 T7 into a variety of existing software frameworks.

Conceptual workflow:

  1. Find example code/wrappers for your desired programming language.
  2. Use the LJM_Open() function to open a connection to the T7.
  3. Perform reads and writes to Modbus registers using LJM_eReadName() or LJM_eWriteName().
  4. Use the Close() function to close the connection.

Direct Modbus TCP, Clients

For users who don't want to write their own software, it is easy to integrate a T7 over Ethernet or WiFi into standard COTS Modbus software platforms, since the T7 is directly compatible. People who already use Modbus software will find this option convenient.  Some COTS Modbus software is very powerful, and will save users the time and money required to develop their own software.

Conceptual workflow:

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

Communication Speed Considerations

There are two alternate methods for data transfer to occur, command response is the lowest latency, and streaming offers the highest data throughput, the following sections provide more detail.


This is the default behavior for communication with a device, and most people find the data throughput satisfactory. Direct Modbus interactions will always use command-response. The high-level LJM library also uses command-response.

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

Command-response mode is generally best for minimum-latency applications such as feedback control.  By latency here we mean 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 c-r 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.  As 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.  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 25 samples each.  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 streaming, 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 running.

Doing Other Things While Streaming

The T7 supports 1 active stream at 1 scan rate.  Command-response calls can be used while a stream is active to read/write almost everything except analog inputs (which includes the internal temperature sensor), as stream mode takes over the analog input system.