How Do I Configure MDBRTUMASTER for Modbus RTU?

After the serial path, node address, register range, and local buffer are configured correctly, MDBRTUMASTER can read holding registers with function 16#03 and write multiple registers with function 16#10. Follow the request from the master PLC through the serial port to the slave, then verify the returned words in master memory before adding application logic.

Which communication path must work first?

The request starts in the master PLC application. MDBRTUMASTER passes the Modbus RTU frame to the opened serial port, the serial link carries it to the addressed slave, and the slave returns a response over the same path. A failure at any earlier hop prevents later protocol checks from proving anything.

Path element	Required configuration	Check before continuing
Master application	Call the communication function block and execute one defined command	The command enters its active state
Serial port	Open the port and define communication parameters	The open operation completes without a local port error
Physical link	Match interface wiring, reference conductors, termination, and biasing to the equipment manuals	Transmit activity reaches the intended cable and receive activity returns
Serial framing	Use matching baud rate, data format, parity, and stop-bit settings at both ends	The slave accepts complete frames rather than ignoring malformed traffic
Slave selection	Set the slave node address in the function block	Only the intended node responds

Layer one first. Inspect wiring and port activity before changing register numbers. A silent bus usually points to a closed port, wrong interface wiring, mismatched framing, or an incorrect node address. A received exception or a response carrying valid framing proves that the physical and serial portions of the path are already functioning.

Complete the serial-port action first and confirm that it has finished before enabling a read or write action.

How should the master sequence its commands?

A demonstrated implementation uses three actions: one opens the serial port and defines its parameters, one manages register reads, and one manages register writes. In an SFC program, each transition waits for completion of the command assigned to the communication function block. The same transaction discipline applies in Ladder or other IEC logic.

1. Execute the port-open action and wait for its completion indication.
2. Load the slave address, register address, register count, operation, and buffer reference for the read transaction.
3. Trigger one read request.
4. Keep the request definition stable while the transaction is active.
5. After completion, process the received words or record the reported error.
6. Load the write transaction parameters and trigger one write request.
7. Wait for completion before starting the next cycle.

Do not continuously retrigger a command while it is active. A Modbus RTU master owns the request sequence: it sends one frame, waits for the response or transaction failure, and only then sends another. Overlapping requests can overwrite parameters or make completion status belong to a different logical operation than the application expects.

The check at this stage is command serialization: a trace of the state logic must show port open, read start, read completion, write start, and write completion in that order.

What do Register and Buffer identify?

Register identifies the starting register in the remote slave transaction. Buffer identifies the local master memory used to receive read data or supply write data. They describe opposite ends of the same transfer and must not be assigned as though both were slave addresses.

Operation	Remote side	Local buffer behavior	Function
Read holding registers	Register is the first slave register to read	The function block stores returned 16-bit words starting at Buffer	16#03
Preset multiple registers	Register is the first slave register to write	The function block takes consecutive 16-bit words starting at Buffer	16#10

The register count determines how many consecutive words move. A count of two transfers two 16-bit words. Reserve enough contiguous local memory for that count, and keep the data types aligned with 16-bit Modbus registers. If the application combines registers into a wider value, apply the slave device's documented word order after the transfer; do not change transport addressing to compensate for byte or word order.

Check the buffer independently by placing recognizable values in the local write words and by monitoring all local destination words during a read.

How do the demonstrated SlimLine addresses map?

The demonstrated configuration transfers two registers in each direction. Its read starts at slave memory MX100.16, identified as Modbus address 40008, and stores the two returned 16-bit words in master memory starting at MX100.16. Its write takes two 16-bit words from master memory starting at MX100.32 and writes them to slave memory MX100.32, identified as Modbus address 40016.

Transaction	Quantity	Slave location	Stated Modbus address	Master buffer
Read	2 × 16-bit words	MX100.16	40008	Starts at MX100.16
Write	2 × 16-bit words	MX100.32	40016	Starts at MX100.32

Use these pairs as explicit mappings for this setup, not as a universal address-conversion formula. Modbus documentation may display a holding-register reference differently from the numeric offset placed in a function-block parameter. When configuring another slave, read its register table and determine whether the software expects the displayed reference or the protocol data address.

Prove the read mapping by changing one slave word at a time and observing which master buffer word changes. Prove the write mapping by loading two different test patterns into the master buffer and confirming their order at the two slave locations.

Why can the slave work without an application block?

In the demonstrated SlimLine-to-SlimLine arrangement, the master project contains the communication logic, while the slave requires no user program for Modbus slave handling because its operating system manages that service automatically. The master still needs the correct slave node address and an address range exposed by that service.

This arrangement does not remove the need to validate memory ownership. The application must avoid using the same locations for unrelated logic while a transaction is reading or writing them. For writes, load the complete local source buffer before triggering 16#10. For reads, consume the destination buffer only after successful completion so the application does not mix previous and newly received values.

The check is asymmetric by design: monitor the master transaction state and the slave memory locations. No slave application action is expected to start the protocol exchange in this specific arrangement.

Why does Ethernet Modbus communication stop before the request?

The older LogicLab SlimLine configuration described here can act as a TCP server but cannot initiate a TCP connection as a client. The ModbusMaster function block operates on an I/O stream supplied through a FILEP parameter returned by Sysfopen. A Modbus TCP master needs an established outbound TCP connection to the slave. Without TCP-client capability, the path stops before a Modbus request is sent.

Configuration	Who initiates the connection?	Result
Serial MDBRTUMASTER or serial ModbusMaster	The master controls the serial request sequence	Supported by the demonstrated master applications
Direct Ethernet from the described LogicLab SlimLine	The SlimLine would need to open a TCP client connection	The connection cannot be initiated in the described system version
Ethernet/serial converter	The converter acts as TCP client	Provides the missing TCP connection while the PLC uses its serial port
UDP transfer between SlimLine systems	Application-defined UDP exchange	Use UDPDataTxfer when Modbus TCP compatibility is not required
Codesys SlimLine version	The controller supports TCP server and client roles	Requires a suitable master implementation because the LogicLab library range is not carried over unchanged

Do not troubleshoot Modbus register addresses until the TCP connection exists. Check the socket role first: the device at the master end must be capable of initiating the connection, and the slave must be listening.

How can a converter bridge the missing TCP-client hop?

An Ethernet/serial converter such as the ATC-1000 can provide the connection initiator. Connect its serial side to the SlimLine serial port, configure the converter as a TCP client, and set the Modbus slave's IP address and listening port as the destination. The stated default port is 502.

1. Wire and configure the PLC serial port and the converter serial interface with matching parameters.
2. Configure the converter for TCP-client operation.
3. Enter the slave's IP address and port; use 502 only when the slave is configured for that stated default.
4. Connect ModbusMaster to the PLC serial port stream.
5. Set Type to 2 so the function block handles Modbus TCP framing across that stream.
6. Issue a known read before enabling writes.

Here, the serial cable carries a Modbus TCP-formatted data stream to the converter; the converter supplies the outbound Ethernet connection. This is different from using MDBRTUMASTER for native Modbus RTU framing. Keep the selected function block, framing type, and converter operating mode consistent.

Verify each hop separately: confirm serial transmit data from the PLC, an established converter-to-slave TCP session, a request received by the slave, and a response returned to the function block.

How do I verify the complete transaction?

Follow the packet from the application to the final word rather than changing several settings at once.

1. Confirm that the serial port opens and that both endpoints use matching serial parameters.
2. Trigger one 16#03 request for two words at the known read mapping.
3. Confirm that the command completes and that two destination words starting at the master Buffer change to the slave values.
4. Change each slave word separately to verify register order and rule out an off-by-one address.
5. Load two distinct values into the master write buffer.
6. Trigger one 16#10 request and wait for completion.
7. Read the slave locations back and compare both words with the original master buffer.
8. Repeat the cycle while watching that no new command starts before the preceding command finishes.

Symptom	First decision point	Check
No request activity	Application or port-open stage	Command trigger, open completion, and selected stream
Transmit activity but no response	Physical link, serial framing, or node selection	Wiring, interface settings, and slave address
Valid response but wrong words	Register interpretation or buffer placement	Displayed reference versus protocol address, count, and destination order
Read works but write does not	Write range or source data	16#10, writable slave locations, count, and populated local buffer
No direct Ethernet session	TCP-client capability	Connection initiator, destination IP, and port

The end-to-end pass condition is exact: the read copies both selected slave words into the intended master words, the write copies both prepared master words into the intended slave words, and a subsequent read returns the same two written values.

FAQ