How is the debugging process done in CoDeSys?

How is debugging performed in CODESYS?

Find where the fault begins, not just where it appears

Hello everyone. Debugging in CODESYS uses variable monitoring, breakpoints, stepping and time-based recording to identify where a program departs from its expected behaviour. First define the symptom: does the program fail to run, produce the wrong result, or fail only under a particular condition? This guide covers CODESYS V3; feature availability depends on the controller, runtime and user permissions.

1. Start with the correct project and controller

Back up the saved project version, resolve build errors and check the target hardware. Select the correct controller in the device’s Communication Settings, then connect using Online > Login. If CODESYS requests a Download or Online Change, investigate the difference between the project and the running application. Do not accept a download automatically just to view values.

Separate a network connection problem from a program logic error. For initial tests without hardware, enable Online > Simulation while offline, log in and select Debug > Start. Simulation does not fully validate physical I/O connections or field device behaviour. Successfully compiling IEC 61131-3 code does not by itself prove correct machine operation.

2. Observe first: Watch lists and task status

Use View > Watch > Watch 1 to collect relevant variables in one list. Use the full variable path, such as PLC_PRG.StartRequest. If a function block has several instances, make sure you are monitoring the intended instance. Data types and display formats matter: a BOOL state, a numeric value and a timer’s elapsed time need different interpretations.

Check task statistics under Task Configuration > Monitor. Is the program called, is the application in RUN, and is the task cycle appropriate? The Watch display may miss fast changes. Never seeing TRUE on screen does not prove that a variable never becomes TRUE during execution.

3. Check a motor’s starting conditions one by one

If StartRequest is TRUE in the PLC program but MotorCommand remains FALSE, monitor the operating permissive, fault state, sequence step and output command together instead of repeatedly writing the start signal. If Ready is FALSE, investigate the permissive before the output assignment. If MotorCommand is TRUE but the physical output is absent, check I/O mapping, the module and the field circuit.

Use cross-references to find other assignments to the same output variable. This applies whether you use LD, FBD or ST. A value that looks correct at one statement may be changed by another statement later in the cycle.

4. Use breakpoints and stepping to inspect execution

Under suitable test conditions, select an executable statement in the online ST editor and use Debug > Toggle Breakpoint or F9. Execution reaching that point produces HALT ON BP. Manage breakpoints through View > Breakpoints; continue with Debug > Start or F5.

In Structured Text, Step Over executes a called unit in one step, Step Into enters the call, and Step Out executes the remainder of the current unit and returns to its caller. The next statement shown at the halt position has not yet executed. Stepping does not reproduce normal cycle timing; do not rely on it alone to investigate timing faults.

Editor’s note: A breakpoint is not a safe machine stop. In a multitask application, other tasks can continue while the debug task is halted. I/O updates belonging to the halted task stop. Do not assume outputs become safe; assess the effect on the machine before using breakpoints on operating equipment.

5. Use the call stack to identify the correct instance

View > Call Stack shows the halted POU, its callers, the task and the instance path. If two pumps use separate instances of the same function block, inspecting the wrong instance gives misleading results. A previous halt location displayed in grey offline or during normal online operation is not a live call stack of the code currently executing.

6. Distinguish writing a value from forcing it

Prepare a test value in Prepared Value. Debug > Write Values writes it once; the program can overwrite it. Debug > Force Values reapplies it at the beginning and end of the task cycle. Assignments within the cycle can temporarily give a forced variable another value.

When testing timers or logic conditions, begin with controlled simulation tests. Forcing physical outputs or protective conditions can cause actual movement. Making a system run by forcing a signal does not fix the fault. Record which condition the test value changes, then explicitly release the force.

7. Capture fast or intermittent faults with Trace

If supported by the target, add a Trace object below Application. Select the relevant task, variables, sampling settings and trigger condition, then start recording. Compare StartRequest, Ready and MotorCommand on the same time axis. Trace can miss a short event if the sampling interval is unsuitable, and recording can increase task cycle time.

For a data exchange problem, examine communication status and the last valid update as well as the received value. Assess task statistics alongside the device’s Log entries and communication diagnostics. Trace recording can continue after logout, so stop the recording separately when finished.

8. Finish the test and verify the correction

Check Watch All Forces and release the relevant forces. Debug > Unforce All Values can release ordinary variable forces. If you used special CFC function block input forcing, release it separately through its own command. Clear breakpoints and verify the intended application state. Stop stops the application; Logout closes the connection session. They are different operations.

After correcting the code, repeat both the fault-triggering condition and normal operation. Restore production access permissions, remove temporary test code and record the revision. Clear variable names and small program units make future investigations easier. Apply the same discipline when using training examples: the symptom, cause, correction and verification result should each be clear.