7 CODESYS Commissioning Issues to Catch Before Factory Deployment

A CODESYS application compiles successfully. The I/O responds, the control logic works, and the machine sequence looks correct.

Is the machine ready for production?

Not necessarily.

A basic bench test confirms that the application can run under the conditions tested. It does not automatically verify how the complete control system will behave after a restart, under a higher workload, or when a field device loses communication.

For machine builders using BLIIOT EdgePLC + CODESYS, these seven checks can help identify configuration issues before the machine leaves the workshop.

1. Is the CODESYS Runtime and Licensing Setup Correct?

A successful development session does not, by itself, confirm that the target device has every required runtime component and license.

Depending on the selected CODESYS product and the device manufacturer's licensing arrangement, Runtime licensing may be included in the solution or require separate activation. Additional software components may also have their own licensing requirements.

Before commissioning, verify:

• The CODESYS Runtime and required components are available on the target.
• The development environment, device description and Runtime versions are compatible.
• The applicable Runtime and feature licenses are correctly configured, where required.
• Any additional functions used by the application are supported by the selected configuration.

What to check: Confirm the licensing arrangement and software configuration for the actual EdgePLC model before deployment. Do not assume that a license for the development environment also covers the target Runtime.

2. Does the Project Match the Actual Target Device?

A project that compiles successfully is not necessarily ready to run on every CODESYS-compatible controller.

The target device description, libraries, Runtime version and supported functions can affect whether a project can be deployed and operated as intended. Some combinations are compatible, while others may cause login problems, missing functions or incompatibilities.

Before downloading the application, check:

• The selected target device matches the intended hardware platform.
• The required device descriptions and libraries are available.
• The project and Runtime versions are compatible.
• The configured interfaces and functions are supported by the actual device.

This is particularly relevant when transferring a project from a development setup to the final machine controller.

What to check: Validate the project against the actual target configuration, rather than relying on a successful compile alone.

3. Have the Physical I/O Channels Been Verified?

Correct I/O mapping is essential, but a variable appearing in the application does not prove that the corresponding physical signal is correct.

A channel may be mapped incorrectly, a signal may be interpreted with the wrong polarity, or an analog value may use an incorrect scaling factor.

Verify the relevant inputs and outputs:

• Does each application variable correspond to the intended physical channel?
• Are signal types, polarity and electrical ranges correct?
• Are analog values scaled and interpreted as expected?
• Do the connected sensors and actuators respond correctly?

For example, an analog input returning a numerical value does not necessarily mean that the engineering value is accurate. Similarly, an output variable changing state does not prove that the connected actuator responds as intended.

What to check: Test the complete signal path, from the physical terminal through the I/O configuration and CODESYS application to the connected device. Perform output tests under controlled conditions.

4. Are Fieldbus Connections and Device Parameters Correct?

Communication problems can originate from several places, including network settings, device parameters, addressing, topology and project configuration.

For Modbus, EtherCAT and other interfaces supported by the selected configuration, verify the relevant settings:

• IP addresses, device addresses or serial communication parameters.
• Master/slave relationships and network topology.
• Device descriptions and communication parameters.
• Communication status, diagnostic messages and timeout behavior.

EtherCAT deserves particular attention. The CODESYS EtherCAT Master documentation calls for a dedicated network interface and warns that real-time capability cannot be guaranteed if unrelated fieldbus or additional network traffic shares that interface. The implementation should be checked against the documentation for the specific Runtime and hardware platform.

What to check: Test normal communication and, where relevant, verify how the application responds when a device becomes unavailable or communication is interrupted.

5. Are Task Cycle Times and Watchdogs Configured Appropriately?

A configured task interval does not, on its own, prove that the application consistently meets its timing requirements.

Actual execution time and timing variation depend on the application workload, task configuration, operating system, Runtime and target hardware.

During commissioning, review:

• Task intervals and execution priorities.
• Measured execution times and cycle-time variation.
• Watchdog configuration and expected behavior when a task exceeds its limit.
• The timing relationship between control tasks and relevant fieldbus cycles.

A small test program may behave differently from the completed application with all its control logic, communication and background services running.

Avoid choosing a cycle time or watchdog value simply because it is available in the configuration. The settings should reflect the machine's requirements and be verified on the intended target.

What to check: Monitor task timing and watchdog behavior during representative operating conditions, including periods of higher workload. Compare the results with the application's actual timing requirements.

6. Has the Complete Application Workload Been Tested?

Depending on the selected EdgePLC configuration, the system may run CODESYS control alongside Linux-based services for data processing, protocol conversion or other edge applications.

When these functions share computing or communication resources, their combined workload may affect system performance. The extent of this effect depends on the hardware, operating system, scheduling configuration and applications involved.

Before release, evaluate the planned workload:

• Run the CODESYS application together with the other services intended for deployment.
• Monitor available CPU, memory and system-load indicators.
• Observe CODESYS task timing while communication and data processing are active.
• Test sustained operation under representative and peak workloads.
• Investigate unexpected task delays, resource contention or application failures.

Not every project requires additional Linux applications. If the controller is dedicated to PLC control, the validation plan should reflect that simpler configuration.

What to check: Evaluate the intended system configuration as a whole. Testing each component separately may not reveal issues that arise when they operate together.

7. Has Startup and Fault Recovery Been Verified?

A successful initial startup does not establish how the machine will behave after every restart or communication failure.

Commissioning should include checks of the startup sequence, application persistence and recovery behavior relevant to the machine.

Verify the following:

• Is the intended boot application present and configured to start as required?
• Does the application start correctly after a normal power cycle?
• What does the machine do when communication with a field device is interrupted?
• Is recovery handled correctly when communication returns?
• Are alarms, restart conditions and error states handled as intended?
• Do retained variables and persistent data behave correctly under the expected restart, download and reset conditions?

CODESYS provides boot application and data-retention mechanisms, but the actual behavior depends on the target configuration and the retention mechanism used. For example, RETAIN and PERSISTENT variables do not have identical retention behavior under all reset and download conditions.

Output behavior during a fault also depends on the application, the target system, the output hardware and the connected equipment. Do not assume that outputs automatically enter a safe state whenever communication is lost.

What to check: Test the expected startup and recovery scenarios on the actual target. Document the required machine response and verify it against the project's functional and safety requirements.

Before the Machine Leaves the Workshop

Commissioning is more than downloading a program and confirming that it runs. It is an opportunity to verify that the complete control solution meets the requirements defined for the machine.

Use these seven checks as a starting point:

1. Runtime compatibility and licensing.
2. Target device and project compatibility.
3. Physical I/O mapping and signal behavior.
4. Fieldbus configuration and communication.
5. Task timing and watchdog behavior.
6. Combined application workload.
7. Startup, fault recovery and data retention.

For a BLIIOT EdgePLC + CODESYS solution, the most useful approach is to evaluate the controller, software configuration and application workload together. The exact checks will vary with the selected model, enabled functions and machine requirements.

A successful commissioning process does not eliminate every possible fault, but it helps identify configuration problems before they become more difficult to investigate on the factory floor.

Planning your next machine with EdgePLC + CODESYS?

Start by defining your control tasks, communication interfaces and application requirements. These details provide a practical basis for evaluating the appropriate platform and planning the commissioning process.

Explore the BLIIOT EdgePLC Controller Series to learn more about the available platforms and configurations.