3.0 Communication [T-Series Datasheet]

Overview

T-Series devices are Modbus-TCP servers. Modbus-TCP is the protocol that describes how to interpret the data stream. A server will wait for commands to be sent to it from a client. A computer acts as the client when making requests of the server.

Modbus can be accessed by various clients. In most cases the high-level LJM library and acompanying software should be used to control T-series devices.

Subsections

Communication Options

There are two methods for data transfer to occur:

• Command-response - offers the lowest latency.

• Stream Mode - offers the highest data throughput.

Command-Response

This is the default mode for communication with LabJack devices. It is the simplest communication mode. Communication is initiated by a command from the client which is followed by a response from the device.

• Overall data transfer is paced by the client software.

• Command-response is generally used at 1000 scans/second or slower.

• Command-response mode is generally best for minimum-latency^[1] applications such as feedback control.

• See Appendix A-1 for details on command-response data rates.

[1] Latency, in this context, means the time from when a reading is acquired to when it is available in the client software.

Stream Mode

Stream mode is generally best for maximum-throughput applications. Data can be acquired very fast, but to sustain the fast rates it must be buffered and moved from the device to the client in large chunks. The buffers introduce some latency to the data delivery. Because of that latency, streaming is usually not recommended for feedback control operations.

• Data transfer is paced by hardware on the LabJack device.

• Runs at a set interval designated by a configurable scan rate.

• A scan consists of a sample from each channel in the stream scan list.

• Stream samples are placed in a buffer on the LabJack.

• When sufficient samples have been collected on the device, a data packet will be sent to the client.

• Primarily used when command-response is not capable of the desired sampling rate.

• See Appendix-A-1 for details on stream mode data rates.

For the T7-Pro, stream mode is not supported on the hi-res converter (resolution indices 9-12 are not supported in stream).

Combining Command-response and Stream mode acquisition

Command-response operations can be performed while a stream is active.

If any of the items in the stream scan list is an analog channel, stream will take exclusive control of the analog input system and analog inputs cannot be read via command-response.

If the scan list does not contain any analog inputs, it is what we refer to as a digital only stream. Some T-series devices (T4,T7) will allow analog readings through command-response while performing digital only stream.

The T8 does not support digital only stream.

Hardware/Software Interface

T-series devices communicate via Modbus TCP and act as Modbus TCP servers. A device must act as the client, using Modbus TCP to interface with the device hardware. This hardware/software interface can be achieved using Modbus TCP client software or by using the high level LJM library. These interface options are described in greater detail below. Further software information can be found in the Software Options appendix.

Modbus Protocol

Modbus TCP is a register based protocol. Registers store values which can be read from or written to. Each register represents a configuration, measurement, or variable. Most T-series device registers are both readable and writable.

All of the Modbus registers that are supported by T-series devices are contained in a list called the Modbus Map. The map allows users to quickly look up any available operations.

The word “register” is often used with two different meanings. The Modbus protocol defines a register as a single 16-bit value which resides at a single address within the Modbus map. A register can also be defined as a logical value. The logical value may require larger data-types such as a 32-bit floating point number. If the data-type associated with a logical value is larger than 16-bits, then multiple Modbus TCP registers will need to be read sequentially. For more information, see the Modbus Map section.

High-level LJM library

LJM is a cross-platform library. It allows users to access device registers by name. For example, "AIN4" for analog input 4. Example code is available for over a dozen different programming languages.

The LJM library makes it easy to integrate T-series devices into a variety of existing software frameworks. The LJM library is the recommended programming interface for T-series devices.

Client Software Options

Prebuilt Programs from LabJack

Prebuilt programs are useful for simple applications such as testing, configuring, and logging data to files. LabJack provides a few prebuilt applications:

• Kipling provides a simple interface for testing and configuring most t-series features.

• LJLogM uses software timing to periodically sample data and save results to a file.

• LJStreamM uses hardware timing to sample data and save results to a file at higher rates. Generally, sampling at more than 500 Hz to 1k Hz requires streaming.

Custom LJM Programs

Custom programs allow all of the functionally of T-series devices to be controlled from many different programming languages. Custom programs are used when an application requires output control, response to stimuli, feedback systems, etc.

Example workflow:

1. Open a connection to the T-series device.

2. Read from and write to Modbus registers.

3. Close the connection.

Prebuilt Programs from third Parties

Programs known as COTS or “Commercial Off The Shelf” can often communicate via Modbus TCP with T-series devices. Some T-series features, such as stream and multiple operations per packet, will not be available when using a COTS program.

Custom Modbus TCP Programs

A custom program could be designed to interface with T-series devices via Modbus TCP, however the high level LJM library should be used in most cases. LJM abstracts away most Modbus TCP details to simplify software development.

Onboard Lua Scripts

Onboard Lua scripts are small programs that run on the t-series device's processor. Scripts have access all the features of the device and do not have to wait for communication delays.

Onboard scripts allow T-Series devices to perform tasks without commands from a client program and are one of the most useful features of T-Series devices. Scripts have several advantages such as lower response times, autonomous operation, simplifying some tasks such as reading from sensors, PID loops, etc.

Script application examples:

• Sensor Reading: A common use for scripts is to read a digital or analog sensor, apply a calibration curve and save the resulting value so that the client application can read that value at its convenience. This remove the complexity of communication protocols, or device specific analog settings from the host application.

• PID: A pid controller can be implemented in a script that will constantly update an output in response to an input. The client application can read the most recent output and input values for P, I, and D as well as start and stop commands.

A device running an onboard script needs to process the Lua byte code. That requires some processing power, which results in lower maximum data collection rates when running a script.