Runtime process hits 100 percent CPU a minute after startup

Why does a soft PLC runtime saturate the processor one minute after startup?

Treat it as a support question first. A board missing from the runtime's supported-hardware list can start cleanly and then push the runtime process to full CPU load about one minute in, and in the documented case the vendor's stated fix was support written into the runtime.

The delay is the part that carries the information. A fault that appears only after initialization points at code that runs late in startup, and that is exactly where board support lives. The internal path stays invisible from a process monitor. The decision needs two readable things: the vendor's compatibility list and a timestamped load trace. Everything else in this article serves those two reads.

What does each symptom point to before you change anything?

Three causes cover this pattern and each has a check that decides it: an unlisted board, an overloaded task set, or thermal throttling. The checks below separate them inside an hour.

• Startup OK, then saturation. The runtime process saturates the core about 1 minute after every start, and every release installed on the board behaves identically. This points to a board missing from the supported-hardware list. Check the list, then run the minimal-application test below.
• Load rises with the application. A full application runs hot while a minimal application sits near idle. This points to task overload on a small core. Read execution time against interval in the runtime's task monitor and use the arithmetic in the worked example.
• Load climbs as the board heats. This points to thermal throttling. Read the board temperature against its documented limit and watch the clock frequency; a fault that reproduces on a cool board is not thermal.
• An adapter swap changes nothing. A USB Ethernet adapter and a wireless dongle both gave a normal startup and the same one-minute saturation, so the communication path is ruled out by the swap test.

Does a clean startup prove the board is supported?

No. Startup exercises the board's boot loader, operating system and network stack. Support is a separate fact the runtime vendor publishes, and this fault starts only after those early steps succeed.

Support, in the sense that matters here, is a product: the vendor keeps a build for that exact board, tests it and answers questions about it. Software that merely installs and runs is a different thing. Control software regularly ends up on platforms its vendor has never taken on, and one documented case of control software running with no vendor support spells out what that costs when it misbehaves. A running process is also a weak signal: the quick checks for whether a CODESYS runtime is running or stopped are worth a minute before any deeper work.

Where do you find the supported-hardware list for your runtime?

Start from your runtime vendor's support portal. Several automation vendors publish a downloadable compatibility tool for their automation hardware and software, and every runtime has either such a tool or a supported-board page in its documentation.

Search the list by the board's exact revision. A list entry means the vendor built and maintains the port for that board, and a close relative of a listed board is still an unlisted board. Requirement pages sit next to the list and carry different information, minimum figures. One industrial runtime's published system requirements, for example, ask for a 1.8 GHz or faster processor. Read your own product's page for the numbers that govern your install, and use the list to name the board. Meeting the minimums does not put a board on the list.

How do you separate an unsupported board from an overloaded application?

Run the runtime with a minimal application, one empty cyclic task with a 100 ms interval, and read the process load at the one-minute mark. If the minimal application still saturates the core, your application is not the variable.

The full procedure:

1. Record the installed combination. Board revision, operating system release, runtime version, engineering software version, application, network adapter. Keep the runtime version and the engineering version as separate entries; they update on different schedules.
2. Read the list for the exact board revision. If the board is absent, ask the vendor which runtime package supports it, and record the answer against the version.
3. Back up before you test. Save the application and the runtime settings, and isolate machine outputs so a test start moves nothing.
4. Run the minimal baseline. One empty cyclic task at a 100 ms interval, one known-good network interface. Record process load, task timings and log lines from startup through the one-minute boundary and out to 10 minutes.
5. Apply the confirmed combination, then restore load in stages. Add tasks and communication step by step, recording process load after each stage, so the stage that pushes load up is named.
6. Read the trace with the worked example's arithmetic. The section below carries the numbers.

Read each task's execution time from the runtime's task monitor; sweeping the load to find a soft PLC runtime's cycle time limit is the same measurement done formally.

Worked example: which fault does the load trace show?

Say the board has one core and the task monitor reports 6 ms of execution time in a 10 ms cyclic task and 15 ms in a 100 ms task. That is 60 percent plus 15 percent, so the tasks account for 75 percent of the core.

The arithmetic, from these example readings:

• 6 ms / 10 ms = 0.60, a 60 percent share of one core
• 15 ms / 100 ms = 0.15, a 15 percent share
• 0.60 + 0.15 = 0.75, so the tasks hold 75 percent of the core, leaving about a quarter for communication and the operating system

Case A: the board is on the list. The minimal application sits at 12 percent process load. The full application pins the process at 95 to 100 percent. The gap is the task set: 75 points of measured task work on a core that also runs communication and the OS. The fix is sizing. Lengthen the fast task's interval from 10 ms to 20 ms, which drops its share to 30 percent (6 ms / 20 ms = 0.30) and the total to 45 percent, or move the application to a faster listed board. A working rule: keep measured task load under 80 percent of a core, which leaves about a fifth of the core for communication and scheduling.

Case B: the board is off the list. The minimal application, one empty 100 ms task doing 0.1 ms of work per interval, still climbs to full processor load about one minute after every cold start, on every release. That share is 0.1 percent (0.1 ms / 100 ms = 0.001), so the load comes from the runtime on that board, not from the application. The decision is made: run the runtime on a listed board and treat the unlisted board's behavior as expected until the vendor lists it.

Read the monitor's convention before you compare traces. On a one-core board, 100 percent is the whole processor. On a four-core board, a single-threaded process saturating one core can display as 25 percent (1 core / 4 cores) in tools that normalize across all cores. Check which convention your tool uses so the number means what you think it means.

What does a passing test look like after the fix?

Judge the fix over at least 10 minutes of running, past the one-minute boundary where the fault showed. Pass needs process load stable below the 80 percent line, task execution times inside their intervals, and the engineering connection usable throughout.

Run three consecutive cold starts and watch each one past the one-minute boundary; the fault in this pattern is repeatable, so the fix has to be. Read the task monitor once more inside the window and confirm each execution time against its interval. Keep the accepted trace with the runtime version and board revision noted, so the next change starts from a measured base.

Recommendation: Check the runtime's supported-hardware list for your exact board revision before you tune tasks, swap network adapters or add cooling. If the board is unlisted, treat the one-minute saturation as the expected behavior of an unsupported port and move the runtime to a listed board. If the board is listed, size the task set so measured execution times stay under 80 percent of a core, and confirm the fix with a 10-minute load trace after three cold starts.

Once the runtime is stable, showing line or machine status on a separate small screen is a different job; the guide to andon boards covers where a small screen fits and where it does not.

Questions