Delta AS228T Modbus TCP: Troubleshooting MCONF Setup

An AS228T program is attempting to read five items from an ABB PLC over Modbus TCP with MCONF, but no connection is established. The same project reports an EIP parameter upload timeout. Treat the Modbus transaction and the EIP upload timeout as separate diagnostic paths until evidence proves they share a cause.

Preserve the Known Configuration

Correct the Structured Text Execution Order

The shown program calls MCONF before assigning D100, D101, and okuma_adresi. That ordering is a concrete initialization risk: the call can observe earlier or uninitialized values, depending on when and how it is enabled. Assign every input and configuration word before invoking the block.

D100 := 16#0A14;
D101 := 16#0375;
okuma_adresi := 16#0000;

MCONF(0, D100, 1, 03, okuma_adresi, 5, seviye, 10, 0, 0, seviye_yazma);

This reorder does not prove that the encoded values are correct. It only ensures that the displayed values exist before the instruction executes.

Configure the Data Exchange Path

The available guidance identifies two relevant application topics: Data Exchange Communication (Modbus TCP) and Editing the Data Exchange Table with the MCONF Instruction (Modbus TCP). This indicates that the connection depends on both the Modbus TCP Data Exchange configuration and the MCONF-defined table entry; locating the block in the library alone is insufficient evidence that the exchange table is valid.

1. Initialize D100, D101, and okuma_adresi before the MCONF call.
2. Use the Delta Data Exchange and MCONF application material to verify every argument against the intended ABB endpoint and table entry.
3. Confirm on the ABB side that the requested data area begins at the intended address and is exposed through Modbus TCP. Resolve the ambiguity between protocol addressing and the ABB table notation rather than assuming that 16#0000 maps to the desired value.
4. Run the exchange and verify both the MCONF result/status variables and whether seviye changes. Preserve the exact status returned if the read still fails.

Separate the EIP Timeout

EIP parameter upload timeout names an EIP operation, while the requested exchange uses Modbus TCP. Do not treat that message alone as proof that the Modbus TCP peer rejected the request. First establish whether the timeout occurs during an engineering upload operation, during MCONF execution, or independently; then record the operation that triggers it and the associated status.

If reordered initialization and a verified Data Exchange table still produce no read, the missing evidence is decisive: the ABB model, its Modbus TCP configuration, the intended table/address convention, the meaning of the two configuration words, and the MCONF output status. Obtain those values before changing additional parameters.

FAQ