Do-more EIPMSG Error: A Network-State Fault, Not Valve Logic

Reject the usual quick fixes

Changing the Ethernet cable, re-entering the IP address, and replacing a new module are common first moves. They do not match this symptom when the Nitra valve block answers a ping after a power cycle but stops answering immediately after the first control attempt.

Quick fix	Why it falls short	When it is useful
Replace the cable again	A cable fault normally affects traffic before the valve command as well as after it. A repeatable transition from reachable to unreachable points toward connection handling, an address conflict, or an endpoint that stops processing traffic.	Use another cable when link indications drop, movement changes the symptom, or switch counters show physical-layer errors.
Re-enter the same addresses	Matching the intended address on a drawing does not detect a duplicate address, wrong subnet mask, or another device responding in place of the valve block.	Record the PLC, valve-block, laptop, subnet, and gateway settings, then test for duplication.
Power-cycle everything	A restart clears connection state and temporarily restores communication, but it also removes the failed state needed for diagnosis.	Use a controlled restart to restore production only after recording which device stopped responding.
Replace the valve module	New hardware can still have an address conflict, incompatible message setup, or repeated requests that overload its connection handling.	Replace hardware only after the same configuration and network path work with a known-good target, or official support identifies a hardware fault.

Get it running, then fix it properly: use the restart as a recovery action, not proof that the fault is gone.

Read the state change before naming the cause

The reported message is Couldn't open TCP connection with specified device in EIPMSG @0000005D (EIPMSG at $Main@1). The address @0000005D and reference $Main@1 locate the failing instruction; they do not identify the defective component.

A TCP connection can open only while the target address is reachable and the target can accept the requested session. Ping tests basic IP reachability. It does not prove that the target can process an EIPMSG request, that its connection resources are available, or that the message path and payload are valid.

The key diagnostic fact is the transition:

1. The block responds after a power cycle.
2. The PLC or laptop can ping it.
3. An attempt to control a valve runs EIPMSG.
4. Ping then fails until the PLC and device are rebooted.

This places the fault in network or endpoint state rather than ordinary valve-output logic. Separate three cases: the valve block stops responding, the PLC network interface stops communicating, or another station disrupts traffic when the message begins.

Isolate the device that loses communication

Run the test with the machine in a safe state and the automatic message trigger inhibited. Do not let the instruction retry every scan while troubleshooting.

Check	Result	Decision
Ping the valve block continuously from a laptop while issuing one controlled message	Laptop ping fails at the same instant	Focus on the valve block, address duplication, switch port, power, or traffic caused by the request.
Ping another device from the PLC after the failure	Other devices also fail	Focus on the PLC interface, its network state, cabling, or the common switch path.
Ping another device from the laptop after the failure	Other devices remain reachable	The general network remains active; narrow the fault to the valve-block path or address.
Disconnect or power down the valve block, then ping its configured address	A reply remains	Another station owns the same address. Correct the duplicate before reconnecting the block.
Move the laptop onto the same local segment using verified settings	Local communication works but routed communication fails	Check subnet masks, gateway entries, VLAN assignment, and routing rather than the valve command.

Watch link indicators during the transition. On a managed switch, capture port events, address-table changes, packet errors, and traffic rate. A packet capture should show whether the PLC repeatedly attempts to open TCP, whether the target resets the exchange, or whether the target becomes silent. Stop here if the command causes widespread network loss; isolate the machine network before another test.

Control the EIPMSG execution sequence

An explicit-message instruction must run as a transaction, not as an uncontrolled continuous output. A common recurring fault is retriggering a message while the previous request remains active or immediately retrying a failed connection. That behavior can create overlapping attempts and prevent the endpoint from recovering.

Inspect the logic at $Main@1 around EIPMSG:

• Trigger one request from a one-shot or state transition.
• Do not launch another request while the current transaction is active.
• Handle completion and error states separately.
• Require a deliberate retry transition after an error.
• Do not use a continuously true rung as an unlimited reconnect loop.

Then verify the message configuration against the valve-block documentation: target address, message service, object path, instance, attribute, payload length, and access direction. Read these values from the project and product documentation; do not infer them from the fact that ping works.

Recover in a controlled order

1. Place the process in a safe condition. Account for stored pneumatic energy and the commanded state of every valve.
2. Disable the logic that triggers EIPMSG. Record the full error text, instruction location, network settings, and which pings still work.
3. Power-cycle only the valve block. After its normal startup sequence completes, test ping from the laptop and PLC without issuing a valve command.
4. Power down or disconnect the valve block and ping its address. If anything replies, find and correct the duplicate address.
5. Reconnect the block. Issue one manually controlled EIPMSG transaction while watching ping and the instruction state.
6. If the target remains reachable, correct the sequencing so the message cannot overlap or retry continuously.
7. If the PLC cannot reach other devices after the failed request, recover the PLC communication path according to the machine shutdown procedure and inspect its network diagnostics before restarting production.

Do not restore automatic retries until one request can complete or fail without removing IP reachability. If the first controlled request still makes the target disappear, preserve a packet capture and the exact message configuration for official support.

Verify communication separately from valve motion

Prove the network repair before troubleshooting pneumatics or output mapping:

1. Start with both endpoints reachable and record the baseline ping behavior.
2. Execute one message and confirm that EIPMSG reaches a normal completion state without the TCP-open error.
3. Repeat controlled transactions while confirming that the valve block and at least one other network device remain reachable.
4. Test a normal power-up sequence. Confirm that message logic waits for the target to become ready instead of starting an immediate reconnect loop.
5. Restore automatic operation and watch for connection errors, unexpected traffic growth, switch-port events, and loss of ping.

A successful message with no valve movement is a different fault. Check command data, output mapping, interlocks, valve power, air supply, and the block's local diagnostics. A moving valve does not by itself prove healthy communications; confirm that subsequent messages still complete and the endpoint remains reachable.

FAQ