RUT206 custom Modbus requests must be defined from sender to destination before selecting extra hardware. Start with the requester, trace the serial path, identify the exact function code and payload, and decide where the response must go. Whether the built-in serial client can originate the transaction depends on those concrete requirements.
Which path must the request cross?
Follow the packet. The proposed path starts with the RUT206 acting as the Modbus client. It constructs a request, transmits it through either RS232 or RS485, and waits for the addressed Modbus server to reply. If the application also requires parsed data at another server, the path continues through a separate forwarding or publishing stage.
| Path element | Question to resolve | Failure symptom |
|---|---|---|
| Request origin | Will the RUT206 itself act as the client? |
No transaction is generated when another device was expected to originate it. |
| Serial interface | Does the installation use RS232 or RS485? |
No electrical communication despite valid protocol data. |
| Destination | Which server address receives the request? | The intended device remains silent or another device responds. |
| Operation | What exact Modbus function code and request fields are required? | The client cannot construct the operation, or the server rejects it. |
| Response handling | Must the RUT206 parse the reply or send its data to another server? |
A serial response arrives but never reaches the application. |
Separate transaction generation from response processing. Sending a custom request, decoding its returned bytes, and exporting values are three different capabilities. A device may support one without supporting all three.
Which implementation approach fits the request?
Compare the built-in client path with an external request generator only after defining the transaction. An additional module is justified by a missing capability, not by the word “custom.”
| Approach | Use it when | What must be confirmed | Main limitation |
|---|---|---|---|
| Built-in serial client | The client accepts the required function code and request structure. | Supported function codes, configurable request fields, response decoding, and data forwarding. | A fixed client interface may expose only predefined operations. |
| External request generator or module | The required transaction cannot be represented by the built-in client. | Serial ownership, request scheduling, response parsing, and the interface to the RUT206 or final server. |
Adds another device, configuration boundary, and failure point. |
| Pass-through architecture | Another system originates the request and the RUT206 only transports data. |
Whether transparent transport is available for the required serial path and how sessions are managed. | The RUT206 is not the Modbus client and does not inherently interpret the payload. |
Use the built-in client first if its configuration accepts the exact function code and all required fields. Move to an external generator only when a documented or tested limitation prevents construction of that transaction. This decision avoids adding hardware before locating the actual boundary.
What defines a custom Modbus request?
“Custom function” can describe two materially different cases: a standard Modbus function used with application-specific register data, or a function code and payload format defined by the target-device manufacturer. The first may fit an ordinary client operation. The second requires a client that can construct arbitrary protocol data and interpret the corresponding response.
| Field | Value to obtain | Where to obtain it |
|---|---|---|
| Function code | The exact numeric code required by the server | Target-device protocol documentation |
| Server address | The intended serial device address | Device configuration and network schedule |
| Request data | Byte order, field lengths, addresses, quantities, and vendor-defined bytes | Protocol request format |
| Expected response | Normal response structure and exception behavior | Protocol response format |
| Data destination | Local parsing, storage, or forwarding to another server | Application design |
Do not test with only a description such as “custom read.” Write the complete request definition first. A configuration screen can then be checked field by field: if any required byte cannot be represented, the built-in client is not sufficient for that operation.
How should the physical and serial layers be checked?
Layer one first. A function-code investigation is inconclusive while the serial link is electrically wrong. Confirm which interface the target actually uses; RS232 and RS485 are not interchangeable wiring modes.
| Check |
RS232 path |
RS485 path |
|---|---|---|
| Electrical interface | Confirm transmit, receive, and signal-reference conductors. | Confirm differential conductor identity and bus reference requirements. |
| Topology | Check the point-to-point connection. | Check the multidrop bus, terminations, and biasing arrangement. |
| Serial format | Match baud rate, data bits, parity, and stop bits at both ends. | |
| Addressing | Confirm the request targets the configured server address. | |
| Timing | Read timeout and polling settings from the client configuration; compare them with the target-device response requirements. | |
Capture the serial traffic when possible. No transmitted bytes point to client configuration or scheduling. Transmitted bytes with no response point first to wiring, serial format, addressing, or server readiness. A returned exception shifts the investigation to the function code and request contents.
How should the recommended path be configured?
- Confirm that the
RUT206must originate the Modbus request rather than transport a request generated elsewhere. - Select the installed interface,
RS232orRS485, and verify its wiring before changing protocol settings. - Copy the serial format and server address from the target-device configuration.
- Record the exact function code, request fields, byte order, and expected response structure from the target protocol documentation.
- Open the serial-client configuration and map every required request field to an available setting. Treat an absent field as a capability gap.
- Configure response handling separately: define whether returned bytes are parsed locally or sent to another server.
- If the client cannot represent the transaction, select an external request generator or a pass-through design and assign only one active client to control request timing on the serial link.
Do not infer custom-function support from basic Modbus connectivity. A successful standard transaction proves the physical link and common serial settings, but it does not prove that the client can emit an arbitrary function code or variable payload.
How is the result verified?
- Send one known transaction with polling reduced to a controlled test sequence.
- Observe the serial line and confirm that the intended client transmits to the intended server address.
- Compare the transmitted function code and every request byte with the target-device protocol definition.
- Confirm that the response arrives within the configured timeout and matches the documented normal-response or exception structure.
- Verify the final application behavior: parsed values must map to the intended fields, or the complete response must arrive at the designated server without unintended transformation.
FAQ
How do I know whether RUT206 can send my custom Modbus function?
Define the exact function code and payload, then map every field against the RUT206 serial-client configuration. If the interface cannot represent a required field, use an external request generator or evaluate a pass-through path.
How do I choose RS232 or RS485 for the RUT206 request?
Use the electrical interface specified and wired on the target device. Confirm conductors and topology first, then match baud rate, data bits, parity, stop bits, and server address.
How do I verify a custom Modbus request is correct?
Capture one transaction and compare the server address, function code, request bytes, returned bytes, and exception behavior with the target protocol definition. Finish by confirming that the parsed value or unmodified response reaches the designated application server.