2.0 T-Series Support Home [T-Series Datasheet]

T-Series devices operate using a register-based system. Every feature of the device is accessed by interacting with the registers. Using this system, you can interact with the device in two primary ways:

• Writing: Used to configure a setting, trigger a specific internal action, or store a value on the device. For example, writing to AIN4_RANGE configures the voltage range for that input.

• Reading: Used to retrieve a current setting, access a stored value, or trigger an action that returns a result. For example, reading from the AIN4 register triggers a measurement and returns the current voltage.

Each section of this datasheet identifies the specific register names used to operate the feature being described. For a comprehensive list of all available registers, refer to the Modbus Map.

Each register has both a Name (e.g., DAC1) and a numerical Address (e.g., 1002). Our API is designed to accept register names, making code easier to read, write, and maintain. This is the recommended method for most users. Advanced users or those using third-party Modbus software can use the numerical address directly.

There are two distinct ways to communicate with T-Series devices. The choice depends on whether you need individual, immediate readings or a continuous flow of high-speed data.

Command-Response (C-R)

Command-Response is the standard mode for most applications. In this mode, the computer sends a request to the LabJack (the command), and the LabJack sends a response back.

• Best for: Changing settings, toggling digital I/O, or reading sensors at lower speeds (typically up to ~800 samples/second).

• Software-Timed: The timing is managed by the application's code. The interval between samples may vary due to how the operating system schedules tasks. Typically, that variance is around 1 ms. (Note: Jitter may be higher over network connections, especially WiFi). If better precision is needed, stream mode (below) should be considered.

• Latency: Each command is subject to the "round-trip" time of your connection (USB, Ethernet, or WiFi).

Stream Mode (Stream)

Stream is a hardware-timed mode where the LabJack captures data at a precise, fixed rate. Instead of waiting for a command for every sample, the LabJack uses its internal crystal oscillator to trigger measurements and sends the data to the computer in large packets.

• Best for: Capturing high-speed waveforms or any application where the time between samples must be perfectly uniform.

• Hardware-Timed: The interval between samples is more precise. The sample timing is controlled by the LabJack’s crystal based clock. The result is much less variation “jitter” in the time between measurements.

• Throughput: By grouping many samples into each communication packet, Stream achieves much higher data rates than Command-Response.

• Concurrent C-R: While stream is running, the device will still accept C-R instructions. Some systems like the analog inputs may be unavailable because Stream is using them.

Quick, easy, and reliable for short distances. Note that USB can be sensitive to ESD (Electrostatic Discharge) events. This app-note will help you track down any issues:

• Troubleshooting: USB Communication Failure (App Note)

Great for reliable, long-distance communication. Connecting to managed networks, such as those at an office or other IT managed locations, might require additional setup steps. Here are a few guides to get you going:

• Basic Setup Guide: Setup WiFi and Ethernet for T-Series Devices (App Note)

  • Direct Connection: Direct Connection via Ethernet (App Note)

  • Troubleshooting: Ethernet Troubleshooting (App Note)

Offers maximum convenience but comes with some speed and reliability tradeoffs. Be sure to read the below guide before starting a WiFi project.

• Important: Is WiFi Right for my Use Case?

Before writing your application, you must decide how the device will be configured. There are three primary methods:

• Boot-up Configuration (Power-up Defaults): You can save a specific configuration directly to the device’s non-volatile memory using Kipling or your own application. The device will then automatically load these settings every time it powers on.

  • Best for: Simplifying your code and ensuring consistent behavior when using LJLogM or LJStreamM.

  • Resources: See Device Configuration and Kipling’s Power-up Defaults.

• In-Application Configuration: Kipling uses the same Modbus registers that are accessible to any application. Any configuration that can be set in Kipling can be also be set in your program.

  • Best for: Ensuring the device is in a known state regardless of previous usage or changes made by other software.

• On-Device Lua Scripts: A Lua script running on the T-Series device can manage complex configurations autonomously. This can be much more convenient than using Kipling, especially when dealing with high-channel counts or complex features like AIN_EF.

  • Best for: Applying configuration to many channels, applying the same configuration to multiple devices, making small changes to many channels.

• Kipling: Primarily used to test, configure, and update the device. It is a convenient tool for verifying hardware operation, exploring features, and setting the Power-up Defaults.

• LJLogM and LJStreamM: Free, ready-to-run logging programs provided by LabJack. These are great for projects that require straightforward data collection to a file. While they include simple, manually triggered output capabilities, they are not suitable for applications that require the computer to set outputs automatically based on logic or timing.

• Custom Programs: For full control, you can write your own software. We provide a simple API (LJM) and extensive code examples (Python, C++, C#, etc.) to help you integrate LabJack control directly into your application. You can find examples for many languages here: LJM Examples

• Lua: Lua scripts run locally on the T-Series hardware, providing several unique advantages:

  • Task Offloading: Move complexity away from the host PC by handling digital sensor interfaces or serial communication locally.

  • Simplified Configuration: Programmatically configure many features at once—useful for duplicating setups across multiple devices.

  • Stand-alone Operation: Perfect for autonomous tasks like PID control loops that must run even if the host computer is disconnected.

• 3rd-Party Software (COTS): Commercial Off-The-Shelf programs (like DAQFactory or LabVIEW) offer a middle ground for users who need more logic than our free loggers provide but prefer not to write code from scratch.

• Modbus Clients and SCADA: Because T-Series devices speak native Modbus TCP, they can be controlled by many industrial SCADA systems. See our Direct Modbus TCP app-note for more information.

  Note: Direct Modbus TCP connections generally do not support high-speed features like Stream or Feedback.

For more information about these choices, see the Software Options page.