Why create boot application is grayed out in CODESYS

What the grayed-out command means

A grayed out command never executes. It writes nothing to the controller and raises no error, which is why the PLC logger usually looks clean while the problem is still there.

Match your symptom to the check it points to:

• The command is disabled and no application is selected in the project tree. The command has nothing to attach to. Select the application that should run at startup.
• The command is disabled with an application selected and a clean build. The connection state or the stored controller state is the suspect. Work through the checks below.
• The command is enabled but fails when you run it. That is a different fault, in the write itself. Read the error message and the logger entries from that timestamp.
• The command came back only after a factory reset. The disabled state lived in stored configuration that a restart keeps.

The checks in order

1. Open the project that belongs to that controller and select the application that should start at power-up. A command checked in the wrong project tells you nothing about the controller.
2. Build the application and clear every error. The boot files are written from a compiled application.
3. Connect through the project's communication settings and verify the controller identity from the connected device's information, not from the saved connection name.
4. Follow the boot-application workflow the controller documentation describes. Some targets write the boot files as part of the download, others expect the command run after it. The installed CODESYS help shows where Create boot application sits in your version.
5. Check the command. If it is enabled, run it, power-cycle the controller and watch the application start.
6. If it is still disabled, note the time, open the PLC logger and read the entries from that 1-minute window. Record what you find, including nothing.
7. Count the restart-type attempts already made. Make three the limit: after a controller restart, a runtime reinstall and an IDE restart have changed nothing, another restart of any of them costs time and diagnoses nothing.

Why restarts and reinstalls change nothing

Read two descriptions in the controller manual before you spend another hour on the symptom: the installation procedure and the reset procedure. Each one prints the data it changes. On most controllers an installation leaves the stored configuration and application data in place, so a fresh runtime lands in the same blocked state. The reset removes the stored data and returns the controller to its delivery state. That difference is the recovery: a restart loads, a reinstall replaces the runtime, and only a reset removes the state the command is checking.

One branch to rule out early: if someone edited the runtime configuration on that controller before the command went gray, start from the fix for a CODESYSControl.cfg edit that locked you out and put the file back before anything else.

The recovery: a documented factory reset

A factory reset returns the controller to its delivery state and removes the applications, communication settings and retained data on it. Put the machine in a safe state first, and run only the reset procedure the controller manual documents.

1. Back up the project and the machine settings. The FAQ below lists the four items.
2. Record how you will get back in: the connection values from that backup list, plus the physical route to the controller if the network settings change with the reset.
3. Run the reset exactly as documented. On some controllers that is a front-panel button held 5 to 6 seconds until a status LED starts flashing; on others it is a service tool command. Your controller's manual gives the button, the hold time and the signal.
4. Restore the connection settings, install the runtime again if the reset scope requires it, and check the runtime is running. If the controller boots but the runtime does not, use whether a CODESYS runtime is running or stopped.
5. Open the project, select the application and check Create boot application now, before any optional setting goes back. Retesting at this point attaches a returning symptom to the change that precedes it.
6. Run the command, power-cycle the controller and watch the application start with nobody logged in.

Example: 47 minutes from a grayed-out command to a starting application

Scenario: a packing-line controller during afternoon changeover, with the line already stopped, so there is room to do the job properly.

You open the line's project, select the one application and build it: 0 errors, 10 minutes including the connection check against the device information. The command is still disabled. You note 10:42 and read the PLC logger entries from the 1-minute window around it: no entries at all, which fits a command that never reached the controller. Three restart-type attempts went nowhere before lunch (a controller power-cycle, a runtime reinstall, an IDE restart), an hour spent for no change, so the stored state is the suspect.

The recovery: the machine is in a safe state during changeover. You back up the project and the controller's machine settings, 15 minutes, and write the connection values on the panel drawing: IP address 192.168.1.20, subnet mask 255.255.255.0, device name from the cabinet label. The controller's documented reset is a front-panel button held 5 to 6 seconds until the status LED flashes; you hold it 6 seconds, 2 minutes all in. Restoring the IP settings and reinstalling the runtime per the manual takes 15 minutes, and the download, Create boot application and power-cycle check take 5.

The arithmetic: 10 + 15 + 2 + 15 + 5 = 47 minutes from the first check to the application running unattended. The command came back right after the reset, before any optional setting was restored, so if it ever grays out again, the change made next is the first suspect.

After the command returns

Run Create boot application after every program change that has to survive a restart. To drop the manual step from the routine, use the implicit boot application setting documented under Application > Properties > Boot Application; your CODESYS version's help prints the exact option.

Recommendation: Run the four checks (application selection, clean build, verified connection, PLC logger from the minute of the attempt) before changing anything on the controller, and stop at three no-effect restart attempts. If the command is still disabled, put the machine in a safe state, back up the project and machine settings, record the connection values, and run the reset exactly as the controller manual documents it. Retest Create boot application immediately after the reset, before optional settings go back, then create the boot application and power-cycle to confirm the startup works.

Questions