Modbus RTU

Overview

Modbus RTU Reader and Modbus RTU Writer are two prefabs, each unified across every Modbus RTU function code you’d otherwise need a separate node for. Both talk to a slave device over a Serial (UART) port, framing and checksumming the request for you — you fill in the constants (which function, which slave, which address), not the raw bytes.

Modbus RTU Reader — sends a read request (Coils, Discrete Inputs, Holding Registers, or Input Registers) and emits the slave’s response as a BYTES packet.
Modbus RTU Writer — sends a write request (a single coil, a single register, or multiple coils/ registers at once) and reports whether it was sent.

Both prefabs only pick a channel (serial_channel) — the bus’s own parameters (baud rate, parity, and so on) are not node constants. They’re set once per channel in the Global Peripheral Configuration panel, same as the Serial Reader. See Peripherals below for what a Modbus RTU bus specifically needs there.

How it Works

Both nodes are gated by their trigger input: nothing is sent over the wire until a message arrives on trigger, and each trigger message sends exactly one Modbus RTU request. Framing (address, function code, CRC-16) is assembled and verified internally — a Reader’s output:BYTES is the response the slave sent back, and a Writer’s debug:STRING / sent:BOOL report the outcome, not a byte array you have to decode yourself.

If no response arrives within timeout(ms), the request is abandoned.

On both prefabs, the address field (start_addr on the Reader, adress on the Writer) is the 0-based protocol address that goes on the wire — the same number your device’s Modbus map lists in hex or plain decimal. If your datasheet instead shows the traditional 5-digit register number (40001, 30001, …), subtract the leading digit and 1 first (40001 → 0).

A Reader’s output:BYTES is already-decoded data, not the raw RTU frame — the slave address, function code, byte count, and CRC are stripped before it reaches the port. What’s left depends on mode, which is why it pairs well with Bytes to Value:

Read Holding Registers (03) / Read Input Registers (04) — each register is emitted as a little-endian 16-bit word, back-to-back. Use word_size_bytes: 2, endian: le, and address each field by its position in the response, counting from 0 — word_address: 0 is the first register you requested (i.e. start_addr), word_address: 1 is the next one, and so on. It is not the absolute register address on the device.
Read Coils (01) / Read Discrete Inputs (02) — each coil/input is emitted as its own whole byte (0x00 or 0x01), not packed into bits. Use word_size_bytes: 1 and type: BOOL (or U8), again addressed by position starting at 0 for the first coil requested.

Modbus RTU Reader

Sends one of the four Modbus RTU read functions and emits the response.

Constants

Constant	Type	Description
`mode`	Option	Required. Which read function to send: `Read Coils (01)`, `Read Discrete Inputs (02)`, `Read Holding Registers (03)`, or `Read Input Registers (04)`. Defaults to `Read Coils (01)`.
`slave_id`	`NUMBER`	Required. The target slave’s address. Valid unicast addresses are `1`–`247` per the Modbus spec; `0` is reserved for broadcast (write-only, not applicable to a read).
`start_addr`	`NUMBER`	Required. The first coil/register’s 0-based protocol address to read.
`quantity`	`NUMBER`	Required. How many coils/registers to read starting at `start_addr`.
`timeout(ms)`	`NUMBER`	Maximum time to wait for the slave’s response before giving up. Defaults to `10` ms if left blank — raise this if your slave is slow to respond.

Ports

Inputs: trigger:ANY — sends one read request per message received. The message content is ignored; any data type works.
Outputs: output:BYTES — the decoded response data (see the callout above for its exact layout per mode).

Picks its UART channel via the serial peripheral (serial_channel: 0 or 1) — see Peripherals below.

Example

Modbus RTU Writer

Sends one of four Modbus RTU write functions. Which constants are visible depends on mode — the node only shows the field(s) that function actually needs.

Constants

Constant	Type	Description
`mode`	Option	Required. Which write function to send: `Write Single Coil (05)`, `Write Single Register (06)`, `Write Multiple Coils (15)`, or `Write Multiple Registers (16)`.
`slave_id`	`NUMBER`	Required. The target slave’s address. Valid unicast addresses are `1`–`247` per the Modbus spec; `0` broadcasts the write to every slave on the bus.
`adress`	`NUMBER`	Required. The 0-based protocol address of the coil/register to write to (note: this is the field’s literal name in the UI).
`coil`	Option	Shown only when `mode` is `Write Single Coil (05)`. `ON` or `OFF`.
`value`	`NUMBER`	Shown only when `mode` is `Write Single Register (06)`. A single 16-bit register value, decimal or hex (`0x0064`).
`coils`	text	Shown only when `mode` is `Write Multiple Coils (15)`. Comma-separated coil states, e.g. `0,1,1,0` or `0x00,0x01`.
`values`	text	Shown only when `mode` is `Write Multiple Registers (16)`. Comma-separated 16-bit register values, decimal or hex, e.g. `100,0x0064,42`.
`timeout(ms)`	`NUMBER`	Maximum time to wait for the slave’s acknowledgement before giving up.

The address field is spelled adress (missing the second d) in the node’s configuration panel — this is the literal constant key, not a typo in this page.

Ports

Inputs: trigger:ANY — sends one write request per message received. The message content is ignored; any data type works.
Outputs: sent(optional):BOOL — whether the write was acknowledged. debug:STRING — details useful for troubleshooting a failed or rejected write.

Picks its UART channel via the serial peripheral (serial_channel: 0 or 1) — see Peripherals below.

Example

Peripherals

Both prefabs only pick a serial channel as a node constant — everything about the bus itself is configured once per channel in the Blueprint Editor’s Global Peripheral Configuration panel, and once per channel in the device’s Hardware settings.

Modbus RTU is a serial protocol, not a specific bus standard — it commonly runs over two-wire RS-485, which is a half-duplex bus. If that’s your wiring, set that channel’s Mode to Half Duplex in the UART / Serial card, and assign that channel’s DE pin in Hardware settings — half-duplex mode drives the bus through that single pin, and the UART bus fails to start without it. Point-to-point RS-232 wiring, if that’s what your slave uses instead, can stay Full Duplex.

The Modbus over Serial Line specification commonly used by slave devices defaults to 8 data bits, and either even parity with 1 stop bit or no parity with 2 stop bits — check your specific device’s datasheet, since not every Modbus RTU slave follows the default.

What you need to set

Answering “what do I need to set for Modbus RTU” means filling in three separate places — the same split every peripheral-aware prefab uses:

Where	What
Node constants (on the Reader/Writer node itself)	`mode` (function code), `slave_id`, `start_addr`/`quantity` (Reader) or `adress`/`coil`/`value`/`coils`/`values` (Writer), `timeout(ms)`, and which `serial_channel` (`0` or `1`) to use.
Global Peripheral Configuration (the sliders icon, one card per channel)	Baudrate, Data Bits, Parity, Stop Bits, and Mode for that `serial_channel` — see UART / Serial. Set Mode to `Half Duplex` for RS-485 wiring.
Hardware settings (on the device)	TX/RX pins for that UART channel, plus its DE pin if you’re running `Half Duplex` — see Peripheral Pinout Mapping.

All three have to agree — a channel picked on the node with no pins assigned in Hardware settings, or a baud rate that doesn’t match the slave device, will leave the request timing out with no response.