Fix a red Edge gateway link in the automation server

Why is the Edge gateway red in the automation server?

The recorded failure pairs runtime 4.13.0.0 with Edge gateway 4.13.0.0 on a single-board computer. The Edge showed red and could not connect right after every component was updated to its latest release. The recorded fix is upgrading both components together to 4.14.0.0.

Red means the server shows the Edge as not connected, and everything routed through that Edge fails with it, the scan included. The site had run earlier gateway versions before the update, and that matters: hardware, network path and credentials were already established by earlier green operation. The variable that changed was the version set. The recorded correction moved both components at once, so which one carried the fault is not identified; treat the matched pair as the unit you are correcting.

Which symptom are you looking at?

A link that goes red straight after an update points at the version pair. A link that drops after hours of green, or a failure that names a device or download error, points at a different fault with its own fix.

Sort your case against these signatures before changing any version:

• Red from the first connection attempt, scan fails, the day after an update. The recorded signature. Move the runtime and gateway versions as a pair, with the steps below.
• Red the moment a newly created Edge is added to the server. Same signature in a fresh setup: check which runtime and gateway versions are installed before touching network settings, because a version mismatch fails a first connection just as it fails a reconnection.
• Green for 8 hours or a full shift, then dropped. A connection-lifetime fault, not a version-pair fault. The article on a SysLibSockets TCP client that stops after hours covers that pattern and its checks.
• Red alongside errors naming a device mismatch. That is a PLC runtime device mismatch, a separate procedure from a version upgrade.

Which versions fail and which pair works?

The recorded failing state runs 4.13.0.0 on both the runtime and the Edge gateway with CODESYS 3.5.2.40 on the engineering machine. The recorded working state runs 4.14.0.0 on both, with the CODESYS version not reported.

Each gateway line also documents its own minimums and releases, worth checking against what you run. The Edge Gateway for Windows lists CODESYS Control V3.5 SP10 or higher as the runtime requirement. It documents releases under 3.5.20.0. Configuring the Edge Gateway for Linux lists CODESYS Development System 3.5.16.0 or higher, required for the configuration step, and the Linux release line is documented well past 4.23.0.0. The 4.14.0.0 pair is therefore a real released state you can land on, and the released lines have moved well beyond it since.

How do you upgrade the runtime and Edge gateway together?

Move both components to the same released version in one maintenance window; a 60-minute window covers the runtime upgrade, the gateway upgrade and one scan on a single edge device. The recorded correction took the runtime and the Edge gateway from 4.13.0.0 to 4.14.0.0 as a pair, after the matched 4.13.0.0 state had failed.

Recommendation: when an update leaves the Edge red and the scan failing, upgrade the runtime and the Edge gateway to one matched released version in the same window, with 4.14.0.0 as the recorded pair that recovered. Hold network, port or certificate changes until matched versions still show red after 15 minutes of retries.

1. Record the installed versions. Write down the runtime version, the Edge gateway version and the CODESYS version before anything moves. The recorded case could name 4.13.0.0, 4.13.0.0 and 3.5.2.40; your notes should name yours.
2. Take the machine out of automatic control first. The runtime upgrade restarts the runtime, and a machine must not sit in automatic across that restart. Pick a maintenance window and let the line stop under its normal procedures.
3. Upgrade the runtime to 4.14.0.0, or to the release you have chosen for both components.
4. Upgrade the Edge gateway on its host machine to the same version, 4.14.0.0.
5. Re-add the Edge to the automation server, or retry the existing connection. Where the gateway itself is configured against the server, a separate page walks through configuring the CODESYS Edge Gateway for the automation server.
6. Run the scan and record the versions that produced a green link.

If the job is a gateway hardware swap instead of an upgrade, the automation server documentation describes replacing a still active Edge Gateway with a new Edge Gateway, so the server-side configuration survives the swap.

How do you verify the link after the upgrade?

Two checks match the recorded recovery: the Edge no longer shows red in the automation server and the scan completes. Both results get recorded with the version pair that produced them.

Before the scan, confirm the CODESYS runtime is running and not stopped. A stopped runtime fails a scan with no gateway fault involved, and the running-or-stopped check takes about 1 minute. Then re-run the scan and watch it finish; on the recorded site the link was judged green or red within 10 minutes of the retry. Write the working pair into the site notes as the baseline: in the recorded case that line reads runtime 4.14.0.0 and Edge gateway 4.14.0.0. If either check fails, go to the next section with the versions and the failure wording written down.

Worked example: what moves from 4.13.0.0 to 4.14.0.0?

Three components carry versions in this plant: the edge device's runtime at 4.13.0.0, the gateway host's Edge gateway at 4.13.0.0 and the engineering laptop's CODESYS at 3.5.2.40. The fix fits in one 60-minute window. The recorded correction moves two of the three components; the third must clear a documented minimum of 3.5.16.0.

Count the components off the working pair: the runtime and the gateway, so 2. Upgrading one leaves 2 - 1 = 1 component below the working version, a split state the recorded evidence never exercised. Upgrading both leaves 2 - 2 = 0, the matched 4.14.0.0 pair that recovered.

Check the laptop against the documented minimum: CODESYS 3.5.2.40 reads as V3.5 service pack 2, patch 40, and the configuration minimum for the Linux Edge gateway is 3.5.16.0, service pack 16. That is 16 - 2 = 14 service packs short, so the laptop takes an update before it touches gateway configuration. Budget about 30 minutes for that laptop update ahead of the window. If the laptop never configures the gateway, that minimum does not apply to this fix.

Result: both edge components on 4.14.0.0 after the 60-minute window, the laptop updated where it configures the gateway, the connection retried, the Edge green and the scan completed. The baseline recorded for the next failure is runtime 4.14.0.0, Edge gateway 4.14.0.0.

What if the link is still red after both upgrades?

If the Edge still shows red with the runtime and gateway matched, the version-pair cause is cleared and the recorded case has nothing further to offer. Collect the details it never produced: the exact error code, the gateway log lines around each connection attempt, and the installed version of all three components in writing.

Compare those versions against the documented minimums and releases from the earlier table: CODESYS Control V3.5 SP10 or higher and releases up to 3.5.20.0 on the Windows gateway line, Development System 3.5.16.0 or higher and Linux releases past 4.23.0.0 on the Linux line. A device mismatch produces its own named errors, distinct from a plain red link, and follows its own fix. Network paths, ports and certificates are the remaining causes, and the collected logs are what decide among them, since no error code, port requirement or certificate condition appears in the recorded case.

The decision at the end of both paths: a matched 4.14.0.0 pair with a green Edge and a completed scan closes the case, and a still-red link with a matched pair moves it to the logs.

Questions