Modbus Remote I/O Integration | Obeita
Delivered project. The completed hardware and software met the customer’s agreed requirements in testing. Specifications for a new project must be agreed separately.
Obeita completed and delivered a Modbus remote I/O project built around dry-contact inputs, relay outputs and RS485 communication. The customer’s requirements were translated into a contracted hardware and software scope, then taken through design and physical testing. The central integration issue was defining who controls each output when remote commands and local input linking are both part of the architecture.
Defining control ownership before implementation
The documented I/O architecture separates remote independent control from local input-to-output linking. In remote mode, input reading and output commands are independent. In local mode, IN0–IN4 control OUT0–OUT4, and remote commands do not own those channels. Maintained-contact mode follows the contact state; momentary-contact mode toggles the state on a closure.
This distinction shaped the project’s engineering focus: contact signals, relay behaviour and the supervisory system must share the same control interpretation. The agreed requirements and contract bounded the behaviour to be implemented in the delivered hardware and software.
Connecting field I/O to the Modbus map
Obeita completed the hardware and software design for the agreed remote I/O task. The documented register map assigns 0x0000–0x0007 to inputs and 0x1000–0x1004 to outputs. Configuration registers 0x2000–0x2003 hold device address, baud selection, control mode and input mode, respectively. Model information starts at 0x6000 and software version is at 0x6008.
For a similar integration, the map must be read alongside the selected function codes, read/write permissions and explicit zero-based addressing convention. Control mode also matters when diagnosing an output that does not respond to a remote write. The standard Modbus unicast range is 1–247; address 0 is reserved for broadcast where applicable. Addresses 248–255 should not be used as ordinary slaves unless a separately documented proprietary mode is intended.
Matching relay and enclosure choices to the application
The public architecture includes DIN-rail mounting and a 7–36 V supply design. Relay suitability depends on the actual load type and inrush, not only the marking on the relay. A new installation therefore needs contact types, load details and cabinet wiring conditions to be reviewed together with the control mode.
Documented architecture and configuration
The table records the documented architecture, configuration directions and selection boundaries for this case. Optional items, firmware-dependent choices and expansion directions are not independent guarantees that every listed option was delivered. The agreed project hardware, software and functional scope define the actual delivery.
| Item | Configuration |
|---|---|
| Inputs | 8 dry-contact channels; IN0–IN7 |
| Outputs | 5 relay channels; OUT0–OUT4 |
| Bus | RS485 / Modbus RTU |
| Baud selections | 9600 / 19200 / 38400 / 57600 / 115200; lower rates require firmware check |
| Control modes | Remote independent control / local linking |
| Mechanical design | 95 × 90 × 40 mm; 35 mm DIN rail |
Delivery outcome and test scope
The contracted remote I/O hardware and software were completed and delivered. Physical functional testing confirmed that the project met the customer’s requirements.
The functional result applies to the agreed control and I/O scope. It is not a published relay load rating or a claim that every baud option and proprietary addressing mode has been validated. Lower baud rates remain subject to the firmware qualification shown in the table.
Discuss a similar project
Send Obeita the contact types, relay loads, intended local and remote control behaviour, and PLC register conventions. A similar project can then define control ownership and register access before hardware and firmware are committed.