Ignition 'Read timed out' on Writes Means M580 CPU Overload

Symptom Profile and What the Timeout Measures

Before anything else, confirm the installation matches this pattern. The chain is PLC → Kepware (KEPServerEX) → OPC UA → Ignition gateway → Ignition client. The fault appeared after a Schneider Premium TSX PLC was replaced by a Modicon M580, with logic, tags, and parameters carried over nearly unchanged.

• Reads are healthy. A value change in the PLC shows up in Ignition within about a second.
• Writes from the Ignition client take a long time to be accepted. Most attempts fail with Error writing 95 to tag [Tags]"Tag path" com.inductiveautomation.ignition.client.gateway_interface.GatewayException Read timed out.
• Kepware diagnostics toward the PLC show no read or write failures, and the link is stable.
• Writing the same register to the PLC from a standalone Modbus tool is fast.
• The PLC logic runs with normal cycle times.
• Restarting Kepware changes nothing.

The "Read timed out" in that message is a socket read timeout on the client-to-gateway interface. It is not an OPC or Modbus read. The Ignition client sent a write request to its gateway and did not get an answer in time. A write travels the whole chain and back: client → gateway → OPC UA Write service → Kepware → Modbus write to the PLC → PLC response → Kepware → OPC UA Write response → gateway → client. The client only reports the timeout. The delay can sit on any leg, so the job is to find which leg holds the time.

Why Reads Stay Fast While Writes Stall

Reads and writes stress the chain differently.

• Writes wait in the device queue. A Kepware Modbus channel serializes transactions to a device. A write joins the same pipeline as the pending read requests. When the PLC's Modbus server answers slowly, the write waits for the transaction in flight and then pays its own slow round trip. If the response is late enough to trigger a driver retry, the delay multiplies. The Ignition client, waiting synchronously, gives up first.
• A standalone Modbus tool bypasses the queue. It sends one request on its own connection with nothing ahead of it, so it slips in between the PLC's other work and looks fast. This result proves the PLC can accept writes. It does not prove the PLC can keep up with sustained multi-request traffic.
• Slow is not failed. A response that arrives inside the driver timeout counts as a success, so Kepware's error counters stay clean while latency climbs.

On the PLC side, the M580 CPU services incoming Modbus TCP server requests from Kepware and its own Modbus traffic to the drives and STB islands. When that communication load exceeds what the CPU can process, server response time grows. The cyclic logic task keeps its priority, so a normal cycle time is not evidence of communication headroom. A like-for-like logic migration from Premium to M580 carries over the program. It does not carry over the communication capacity of the old platform. In this case the entry-level CPU BMEP582020 could not handle the internal Modbus traffic between the drives and the STB islands on top of the SCADA requests.

Symptoms Versus Causes

Candidate Fixes Compared

Recommended Path

Isolate first, then give the CPU headroom. Do not buy hardware until the capture shows the PLC's Modbus response time is the delay. Once it does, the CPU upgrade is the proven fix. Reducing load is the alternative when an upgrade is not possible, provided the drive and STB scan requirements allow it. Moving to the BMENUA0100 is an architectural decision about vendor support and server location. It is not a fix for CPU saturation, so treat it separately.

Isolation Procedure

1. Reproduce with a second OPC UA client. Connect UaExpert to the same Kepware endpoint and write to the same slow tag. If the write is slow there too, Ignition is cleared. Go to step 3. If UaExpert writes promptly, the problem sits between Ignition and Kepware. Go to step 2.
2. Capture the OPC UA leg. Temporarily set the Ignition-to-Kepware OPC UA connection to no security so the payload can be decoded. Run Wireshark on the gateway or Kepware host, start a write from Ignition, and measure the time from the OPC UA Write request to the Write response. Restore security when you finish.
3. Capture the Modbus leg. On the Kepware host, filter on Modbus TCP (port 502) toward the M580. Start a write from Ignition. Identify the write transaction (function code 6 or 16) and record when Kepware sends it and how long the PLC takes to answer. Also record response times for the surrounding read transactions.
4. Classify the delay.
   • Long request-to-response times on reads and writes mean the PLC server is slow. Go to step 5.
   • Fast PLC responses but a late write request mean Kepware scheduling. Adjust the channel write-optimization and read/write interleave settings, then repeat step 3.
5. Load test the PLC. Temporarily disable or slow the Kepware tag groups polling the M580 and write again from Ignition. If writes become prompt as polling drops, the PLC cannot serve the combined load. Do not move on until this test gives a clear answer.
6. Read the CPU communication load. In the M580 programming software's CPU and Ethernet diagnostics, check the communication and messaging load with the drive and STB-island scanning active. Compare it with the capacity figures for the CPU reference in Schneider's M580 hardware documentation.

Restoring CPU Headroom

Option A — CPU upgrade (confirmed fix).

1. Confirm the target CPU fits the existing rack, power supply, and network topology. Here the target is BMEP584040, replacing BMEP582020.
2. Change the CPU reference in the application, rebuild, and fix any configuration items the new reference flags. Confirm the IP addressing and the drive/STB I/O scanning configuration are unchanged after the rebuild.
3. Download to the new CPU. Before reconnecting SCADA, confirm the drives and STB islands are communicating and the logic cycle time is normal.
4. Re-enable the Kepware channel and confirm that reads update in Ignition as before.

Option B — reduce communication load on the existing CPU.

1. List every Modbus consumer of the CPU: the drive scans, the STB-island scans, Kepware polling, and any other HMI or engineering connections.
2. Slow the repetition rate of non-critical drive and STB status data. Remove registers nobody uses. Confirm process response is still acceptable before the next change.
3. In Kepware, raise scan rates on tag groups that do not need fast updates, and consolidate tags into contiguous register blocks so fewer, larger requests replace many small ones.
4. In Ignition, avoid subscribing large tag sets at fast rates when they are not displayed or historized.
5. Repeat the Modbus capture from the isolation procedure after each change and track PLC response time. Stop when writes complete promptly with margin to spare. If the needed cuts compromise the process, fall back to Option A.

Verification

1. From the Ignition client, write a test value (for example 95) to the tag that previously failed. Confirm it is accepted without a GatewayException Read timed out and the new value reads back promptly.
2. Repeat the write from UaExpert against the same Kepware endpoint and confirm equivalent timing.
3. Re-run the Modbus TCP capture on the Kepware host. Confirm the PLC's response times on reads and writes are short and stable with full polling active.
4. Check the M580 diagnostics with drive and STB scanning and all SCADA polling active. Confirm communication load has margin and logic cycle time is unchanged.
5. Check Kepware's device diagnostics for timeouts or retries toward the M580. Do not close the job until several consecutive Ignition writes during normal production traffic complete promptly with zero timeouts.

FAQ