Open Modbus/TCP is not a separate proprietary protocol. In this context, “open” describes the public, multi-vendor Modbus specification. For an ECOM100, the important distinction is between standard Modbus/TCP and a less common RTU-frame-over-TCP variant. Both use Ethernet transport, but their application payloads are not interchangeable.
Separate “Open” From the Wire Format
The word “open” describes protocol availability rather than a new packet format. Modbus/TCP can support equipment from multiple manufacturers when both endpoints implement the same protocol variant and agree on addressing.
Do not interpret “Open Modbus/TCP” as permission to send a complete serial Modbus frame through any TCP connection. Confirm whether the non-AutomationDirect device specifies standard Modbus/TCP or Modbus RTU encapsulated over TCP.
Compare the Supported Modbus Variants
| Variant | Transport | Error-check field in Modbus payload | Framing distinction |
|---|---|---|---|
| Modbus RTU | Serial | CRC | Binary messages are transmitted continuously and separated by silent periods. |
| Modbus ASCII | Serial | LRC | Messages use a leading colon and trailing CR/LF. |
| Modbus/TCP | TCP/IP | No Modbus CRC | An Ethernet/TCP-oriented header replaces serial framing requirements. |
| RTU frame over TCP | TCP/IP | CRC retained inside the payload | A serial-style RTU frame is carried through TCP. |
The evidence identifies Modbus/TCP as the protocol supported by ECOM modules. It also reports that some products carry the complete RTU transmission, including its CRC, inside a TCP payload. Treat that behavior as a separate variant rather than standard Modbus/TCP.
Decide Whether the ECOM100 and Peer Match
- Read the peer device documentation and identify the protocol by its complete name. “Ethernet Modbus” alone does not resolve whether it expects Modbus/TCP or an encapsulated RTU frame.
- Inspect the expected payload. Standard Modbus/TCP does not append the serial CRC; an RTU-over-TCP implementation retains it.
- Confirm the peer exposes the required inputs, outputs, counters, or register blocks through Modbus.
- Resolve the address representation separately from protocol compatibility. A successful TCP connection does not prove that the requested element address is correct.
If the peer requires standard Modbus/TCP, the evidence supports using an ECOM100 with non-AutomationDirect equipment. If it requires RTU-over-TCP, compatibility is not established by the evidence and must be checked against the applicable ECOM100 documentation.
Handle DirectLogic Address Translation Carefully
The reported implementation difficulty was mapping a Modbus address to the address entered by DirectLogic WX or RX ladder instructions. V-memory addresses may require decimal-to-octal conversion; other element types may also require an offset. Preserve the requested block length and starting element while performing the translation.
The source shows this ladder sequence:
LD K701
LD K4
LDA O40600
WX TA0The evidence does not define the meaning of each constant or prove that this sequence is correct for another device. Do not copy its values into a different project without validating the transaction type, starting address, element count, and destination.
A spreadsheet can make the address conversion repeatable: enter the Modbus address in one column and calculate the corresponding octal V-memory address with DEC2OCT(Modbus address) in the adjacent column. Generate only the required address range and apply any element-specific offset documented for the target memory type.
The DirectLogic 260 and 06 families introduced MRX and MWX instructions to accept a Modbus address offset without manual DirectLogic-to-Modbus element mapping. In the evidence, those instructions supported RTU serial communication only; an Ethernet-capable version was merely under development. Because no software or firmware version is supplied, verify present support before selecting these instructions for Modbus/TCP.
Verify the Transaction at Both Endpoints
- Use a Modbus read/write test utility to exercise one known input or register before testing a large block.
- Test each endpoint independently where possible: emulate the client to test the server, then emulate the server to test the client.
- Capture the Ethernet exchange and verify that the endpoints use the same Modbus variant. A CRC retained inside the application payload indicates an RTU-style encapsulation rather than the standard Modbus/TCP format described here.
- Confirm that a successful reply contains the intended data. If communication succeeds but values are displaced or invalid, investigate address base, decimal-to-octal conversion, element-type offset, and requested block length.
This process separates transport failures from address-mapping failures. No response points first to endpoint, network, or protocol-variant mismatch; a valid response containing the wrong elements points first to address translation.
FAQ
Does the ECOM100 use Open Modbus/TCP?
The evidence identifies the ECOM implementation as standard Modbus/TCP. “Open” describes the publicly available, multi-vendor protocol rather than a different ECOM100 operating mode.
Does Modbus/TCP include the Modbus RTU CRC?
Standard Modbus/TCP does not include the serial Modbus CRC in its application payload. A TCP payload containing the complete RTU frame and CRC represents the distinct RTU-over-TCP variant described in the evidence.
Why does an ECOM100 Modbus read return the wrong registers?
Check the Modbus starting address, block length, memory-type offset, and DirectLogic address representation. For V-memory mapping described in the evidence, convert the decimal Modbus address to octal with DEC2OCT(Modbus address), then verify the result with a single-element read.