The lockout comes from the file, not the network: the runtime parses CODESYSControl.cfg at startup and a bad append breaks the parse, while Command = AllowAll belongs in CODESYSControl_User.cfg. Check ping, SSH and TCP port 11740 to find the failing hop, then delete the block or reinstall the runtime and move the setting to the User file.
You are locked out because of the file you edited, in one of two ways: the runtime parses CODESYSControl.cfg as an INI file when it starts, and a badly appended block breaks that parse, and the setting you added belongs in CODESYSControl_User.cfg, which a runtime reinstall never touches while the base file is rebuilt. Remove the block or reinstall the runtime from the update tool, then work the checks below in order so you repair the hop that is actually broken. The setting here is [SysProcess] with Command=AllowAll, the pair that lets application code run shell commands on the controller. The context is a single-board Linux controller running the CODESYS Control runtime, the runtime system that turns a device into an IEC 61131-3 controller; IEC 61131-3 is the standard that defines the PLC programming languages.
Why did the controller stop answering after the cfg edit?
Because the runtime reads CODESYSControl.cfg as an INI file at startup, an appended 2-line block with no newline ahead of it glues [SysProcess] onto the last existing entry and breaks both, and the fault then appears at the next restart, days after the edit. In practice that gap runs 2 to 10 days: the controller only restarts on a power event or a firmware update, and the connection fails then.
The runtime reads two configuration files. CODESYSControl.cfg is the base file, and a runtime reinstall regenerates it in its original state. CODESYSControl_User.cfg is the file for your own settings, and the update tool never touches it. The [SysProcess] section is meant for the User file; written into the base file it is lost at the next update.
That mismatch is why the failure looks random. The edit sits quiet until the runtime restarts, then the connection fails from the controller side. The sibling fault, where the runtime reads a valid setting and still gives it no effect, is a different problem covered in why a control application config setting is ignored.
Which hop is failing: network, operating system, or runtime?
Four checks, one command each, cover all six hops between your engineering PC and the runtime, and the first check that fails names the layer you fix, because a cfg edit can only break the last two hops. A full pass of the four checks takes under 5 minutes when the network is healthy.
A download leaves your PC's network interface, crosses the switch and cable, arrives at the controller's network interface, passes the Linux network stack, reaches the runtime process, and ends at the communication component that opens TCP 11740. Prove the first four hops before you touch any file. On a local switch a healthy ping answers in under 1 ms per reply; anything over 10 ms points at a congested link or the wrong subnet.
| Check | Reading | What it tells you | Next |
|---|---|---|---|
ping the controller IP |
replies | hops 1 to 3 are good | SSH check |
ping the controller IP |
no reply | cable, switch, a changed DHCP lease, or an OS fault | fix addressing, repeat |
| SSH to the controller | login works | hop 4, the operating system, is alive | process and port check |
| SSH to the controller | refused or times out | an OS or SSH service fault, outside the runtime | repair the OS first |
How do I check the runtime process and TCP port 11740?
Log in over SSH, list the codesyscontrol processes and the listening sockets, and compare them: the default communication port is TCP 11740, so a running process with 11740 listening means the runtime started and the fault sits above it. Give the process 60 seconds after a reboot before you judge it, because the communication component starts after the runtime core.
Run ps aux | grep -i codesyscontrol for the process and ss -tln for the listening ports. The runtime's own status views give the same answer with more depth in how to check if a CODESYS runtime is running or stopped.
| Reading over SSH | What it points to | Next |
|---|---|---|
| process listed, 11740 listening | runtime up; the fault is in the gateway path or the project | project check below |
| process listed, 11740 missing | the communication component failed to start; a malformed cfg section is the prime suspect | cfg file check |
| no process, or one that keeps restarting | the runtime aborts while reading its configuration | cfg file check |
What should I look for in the cfg file itself?
Three faults cover nearly every bad append: a missing newline ahead of your block, a second [SysProcess] header where one already exists, and the plain fact that Command=AllowAll belongs in a different file.
Look at the tail of CODESYSControl.cfg:
- Missing newline. If the original last line had no line break, your
[SysProcess]header glues onto it and the parser reads both as one broken entry. - Duplicate section.
[SysProcess]can already exist in the file; a second header conflicts with the first. - Wrong file. Even a clean block in the base file is erased by the next runtime reinstall.
Command=AllowAll grants application code the right to run shell commands on the controller under the runtime's account, so enable it only on a network no untrusted client reaches. Other persistent settings live in the User file too, among them OPC UA server parameters configured in CODESYSControl_User.cfg.
How do I restore the runtime and keep Command = AllowAll?
Delete the appended block, confirm the base file still ends in one newline, then write the same two lines into CODESYSControl_User.cfg, and when the base file looks damaged reinstall the runtime from the CODESYS update tool first. Budget 15 minutes for the whole job, most of it the runtime reinstall.
- Back up both files, for example
cp CODESYSControl.cfg CODESYSControl.cfg.bak. - Open CODESYSControl.cfg, delete the appended
[SysProcess]block, and confirm the file ends with exactly one newline. - Restart the runtime, or reboot the controller, wait 60 seconds, and rerun the process and port check. If the process runs with 11740 listening, jump to step 5.
- If the process still fails, reinstall the runtime from the update tool in the development system. The reinstall returns the base file to its original state and leaves the User file untouched.
- Open CODESYSControl_User.cfg, add
[SysProcess]and, on the next line,Command=AllowAll, and end the file with a newline. - Restart the runtime again, and confirm the IDE and the runtime carry the same version, for example 3.5.13.20 on both ends; a version mismatch produces connection faults of its own.
Recommendation: treat CODESYSControl.cfg as rebuildable and CODESYSControl_User.cfg as yours. Delete the appended block, reinstall the runtime whenever the base file is in doubt, keep every custom setting in the User file, and restart the runtime after each edit so a fault shows up at once instead of days later.
Why did a new project reach the same controller?
A fresh project builds a new device object and scans the gateway for the live runtime, while the old project kept its stored device address and device description version, so repair the configuration first and correct the project second.
The old project holds the address and the description version it was built with, and it still fails against a healthy controller until you update those. Open the device editor, rescan the network, update the address, and match the description version to the installed runtime. The version-pairing work behind that step is covered in fix a PLC runtime device mismatch safely. After that, one project connects again and you stop maintaining two.
Example: one recovery from start to finish
One controller on runtime 3.5.13.20 that took downloads for days fails after the edit; the checks place the fault at the last hop, the fix is one deletion and one reinstall in about 15 minutes, and the arithmetic runs below.
A single-board Linux controller at 192.168.1.50 runs runtime 3.5.13.20, paired with an IDE at the same version. It accepted downloads for 9 days. Then [SysProcess] and Command=AllowAll were appended to CODESYSControl.cfg with no newline ahead of them, the controller restarted, and every download failed.
The checks: ping 192.168.1.50 replies in under 1 ms, so hops 1 through 3 of 6 pass. SSH logs in, so hop 4 passes: 3 + 1 = 4 hops good. The process list shows the runtime running, so hop 5 passes: 4 + 1 = 5. But ss -tln shows nothing on 11740, so hop 6, the communication component, is the failing one.
The fix: delete the appended 2 lines, restore the 1 newline the original last line lost, reinstall the runtime once from the update tool because the tail of the file is suspect, write the 2 lines into CODESYSControl_User.cfg, restart, and wait 60 seconds. Port 11740 comes back, hop 6 passes, and 5 + 1 = 6 of 6. A completed download proves the path end to end, and the shell function block returning its result proves the User file is being read.
Questions
What does Command = AllowAll actually allow?
It permits code in the application to execute shell commands on the controller through the SysProcess library, under the runtime's own account. That is what lets a function block run a script and read the result, and it is why the setting belongs only on a controller attached to a network no untrusted client reaches.
Will my settings in CODESYSControl.cfg survive a runtime update?
No. The update tool regenerates the base file and returns it to its original state, so anything added there is gone. CODESYSControl_User.cfg is untouched by the same update, which is why every custom setting belongs in that file.
Is deleting the appended block enough, or do I need the reinstall?
Deleting the block and restarting is enough when the rest of the base file is intact and the process then starts with TCP 11740 listening. Reinstall from the update tool when you cannot vouch for the file, or when the process still fails to start after the deletion.
Is TCP 11740 the port on every installation?
It is the default communication port for the runtime. If your configuration or a firewall rule changed it, list the listening sockets over SSH and match the gateway settings to the port you actually see.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.