Configuring OPC UA Modbus Drivers for Serial Transport

The OPC UA Modbus driver example exchanges data over TCP/IP, but the target device exposes a non-TCP transport. Follow the request from the OPC UA client through the driver: the path stops where AbstractNioDriver expects a network channel. A serial device needs a separate transport layer that opens the port, frames requests, controls timing, receives bytes, and reports failures to the Modbus driver.

Where does the request path stop?

The OPC UA client does not communicate with the Modbus device directly. It issues a read or write to the OPC UA server. The driver converts that operation into a Modbus request, sends the request through a transport, receives the response, validates it, and returns the result through OPC UA.

AbstractNioDriver supplies the networking portion of that path. Its send and receive behavior is therefore tied to a network channel; it is not a general serial implementation. For a non-TCP device, place a custom serial abstraction—commonly described as AbstractSerialDriver—between AbstractModbusDriver and AbstractDriver. The first proof point is architectural: no request for the serial device may enter an AbstractNioDriver socket path.

Which transport settings replace the TCP endpoint?

Replace the IP endpoint with the actual serial endpoint and its line settings. Ignition does not provide the serial communications support required by this driver path, so the module must use a serial library, such as RXTX, or another library selected for the target operating system and runtime.

Read the required serial values from the device manual or its local configuration. A port can open successfully while using the wrong baud rate or parity, producing unreadable bytes or silence. The check before continuing is a stable open port with the configured line settings reported by the serial library and no ownership conflict from another process.

How should the serial connection be opened?

Layer one first. Confirm the interface type, conductor assignment, reference connection, termination, biasing, and transmit-direction control required by the installed hardware. Software cannot correct reversed conductors, mismatched electrical interfaces, or a converter that never switches between transmit and receive.

1. Load the serial library during driver startup and confirm that its native dependencies match the runtime platform.
2. Resolve the configured serial device to one operating-system port. Reject a missing or ambiguous device rather than selecting another port automatically.
3. Acquire exclusive ownership, then apply the device's baud rate, data bits, parity, and stop bits.
4. Configure read cancellation so driver shutdown can interrupt a blocked receive operation.
5. Flush or classify stale input before the first transaction; bytes left by an earlier session must not become the next Modbus response.
6. Close the port and release library resources during driver stop, restart, or configuration change.

Keep one owner for a half-duplex request/response channel. Concurrent writes can interleave frames, while multiple readers can divide one response between unrelated requests. The proof point is a repeatable port lifecycle: start, open, stop, and reopen without a leaked handle or blocked reader.

How must Modbus framing change?

Changing only the byte carrier is insufficient. Select the serial Modbus framing specified by the slave. Modbus TCP uses a network application-data-unit header for transaction and length information. Modbus RTU instead carries the slave address, function, data, and a CRC, with timing used to delimit frames. Modbus ASCII uses text encoding and a different frame check. Do not send a complete Modbus TCP frame unchanged over a serial port.

The serial transport should deliver exactly one validated response frame to the Modbus decoder. It should not pass arbitrary read-buffer fragments upward as complete messages. Prove the framing with a captured request and response: address, function, data length, and error check must all agree with the selected serial mode.

How should sendMessage and receiveMessage work?

Implement the transport contract directly under AbstractDriver through the custom serial abstraction. The Modbus layer should remain responsible for Modbus meaning; the serial layer should remain responsible for byte transfer, timing, buffering, and port state.

1. sendMessage accepts the encoded serial frame, acquires the single-channel transaction lock, applies transmit-direction control when the adapter requires it, writes all bytes, and waits for the library to report completion before changing direction.
2. receiveMessage accumulates bytes until the selected framing rule identifies one complete response. It rejects an invalid frame, reports a response timeout as a transport failure, and returns only the response belonging to the active request.
3. The request coordinator permits only one outstanding serial transaction unless the underlying protocol and hardware explicitly provide a correlation mechanism. Serial Modbus normally correlates by sequence and slave/function content rather than by the Modbus TCP transaction identifier.
4. Driver shutdown cancels pending I/O, releases the transaction lock, closes the port, and completes the outstanding request with a defined failure rather than leaving it blocked.

Do not let receiveMessage wait forever. Obtain the response timeout and any frame timing from the device documentation and expose them as driver settings instead of embedding guessed constants. The check is deterministic fault behavior: disconnecting the device produces one bounded timeout, not a deadlocked driver thread.

How is the complete OPC UA path verified?

1. Start with one documented Modbus read whose slave address, function, and data range are known.
2. Confirm that the OPC UA request reaches the driver and creates one outbound serial frame.
3. Capture the transmitted bytes and verify their framing and error check.
4. Confirm that one response arrives before the configured timeout and is decoded without leftover bytes.
5. Compare the decoded value with the device's local indication or another trusted measurement.
6. Repeat the read, then test a controlled timeout, driver restart, and port reopen.

Advance to writes only after reads are repeatable. For a write test, use a permitted noncritical value, read it back through a separate transaction, and confirm the device accepted the change. The end-to-end pass condition is one OPC UA operation producing one correctly framed serial request, one matching response, and the expected OPC UA value or defined fault.

FAQ