Using Breakpoints

Breakpoints are commonly used for debugging programs. You can set breakpoints at specific positions in the program to force an execution stop and to monitor variable values. You can also set data breakpoints to halt program execution when the value of a specific variable changes. CODESYS supports breakpoints in all IEC editors.

The halt at a breakpoint or data breakpoint can be linked to additional conditions. You can also redefine breakpoints and data breakpoints as execution points where specific code is executed instead of stopping the program.

Note

The Breakpoints view provides an overview of all defined breakpoints. It also includes additional commands for processing batch changes to multiple breakpoints.

In the editor, the following symbols identify the status of a breakpoint or execution point:

• Breakpoint enabled
• Breakpoint disabled
• Breakpoint is set in another instance of the POU open in the editor.
• Halted at breakpoint
• Conditional breakpoint enabled
• Conditional breakpoint disabled
• Execution point enabled
• Execution point disabled
• Conditional execution point enabled
• Conditional execution point disabled
• Data breakpoint enabled
• Data breakpoint disabled
• Halted at data breakpoint
• Data execution point enabled
• Data execution point disabled
• Halted at data execution point
• Conditional data execution point enabled
• Conditional data breakpoint enabled

See also

• Command ‘Breakpoints’

Data breakpoints

With data breakpoints, program execution can be halted when the value of a variable changes.

Note

Data breakpoints are supported for specific target systems only and are enabled in the device description file.

The number of data breakpoints is limited depending on the target system because only a specific number of registers are available. An error message is displayed when attempting to set an additional data breakpoint.

The same options for “normal” breakpoints also exist for data breakpoints:

• Linking the halt at the data breakpoint to an additional condition
• Redefining a data breakpoint to a data execution point where the program does not halt, but processes specific code

Breakpoints in applications with several tasks

Basically, debugging is not possible for multiple tasks at the same time. While you are working on a task with breakpoints or stepping, breakpoints are ignored in other tasks.

If a block containing a breakpoint is used by multiple tasks, then only the debug task is halted because it arrives at the breakpoint first. All other tasks continue. The Call Stack dialog shows which task is currently halted.

If you need a breakpoint to affect only one specific task, then you can define this in the breakpoint properties.

Breakpoints operate separately for each application so that a “HALT ON BP” does not affect any other applications. This applies also to parent/child applications, even if the breakpoint is set in a block that is used by several applications and whose code is located only once on the PLC.

Attention

The I/Os that are called by the debug task are not updated at a halt in the breakpoint, even if you select the Update I/Os in Stop check box in the PLC settings.

Note

If the application stops at a breakpoint on the PLC, then an online change or download causes all tasks to halt which means the PLC will stop. In this case, CODESYS prompts you whether or not to continue with the login.

See also

• Command ‘Call Stack’

Setting a simple breakpoint (example in ST editor)

Requirement: The application is in online mode and running. The operating mode is Debug.

1. In the editor, open a POU programmed in structured text (ST).

2. Place the cursor in the line where a breakpoint will be set.

3. Click Debug ‣ Toggle Breakpoint or press F9.

   ⇒

   The line is marked in red and identified by the “breakpoint enabled” symbol ( ). If the program is halted at the breakpoint, then the line is marked by the “stop at breakpoint” symbol ( ). Program processing is stopped and identified in the status line by the red-highlighted HALT ON BP status.

4. Click Debug ‣ Start or press F5.

   ⇒

   The program continues.

5. Set more breakpoints and check the variable values at the breakpoint position.

6. Place the cursor in the line where a breakpoint should be removed.

7. Click Debug ‣ Toggle Breakpoint or press F9.

   ⇒

   The breakpoint and the marking are deleted.

See also

• Command ‘Toggle Breakpoint’

Defining a breakpoint condition (example in ST editor)

1. In the editor, open a POU programmed in structured text (ST).

2. Place the cursor in the line where a breakpoint will be set.

3. Click Debug ‣ New Breakpoint.

   ⇒

   The New Breakpoint dialog opens.

4. Click the Condition tab.

5. Click Break when the hit count is a multiple of in the Hit Count drop-down box.

   Type the value “5” in the field to the right.

6. In addition, you can define a Boolean condition for when the breakpoint should be active. Select the Break, if true check box. Type a Boolean variable in the text field to the right.

7. Select the Enable breakpoint immediately check box.

8. Close the dialog.

   ⇒

   The line is marked red and identified by the “conditional breakpoint enabled” symbol ( )

Monitor the running program. As long as the Boolean variable for the condition is FALSE, the breakpoint condition is not fulfilled and the program continues to run. If you set the variable to TRUE, then the condition is fulfilled and the program halts at the breakpoint every 5th pass.

See also

• Dialog ‘Breakpoint Properties’

Defining an execution point (example in ST editor)

1. In the editor, open a POU programmed in structured text (ST).

2. Place the cursor at the position for an execution point.

3. Click Debug ‣ New Breakpoint.

   ⇒

   The New Breakpoint dialog opens.

4. Click the Execution point settings tab.

5. Select the Execution point check box.

   In the Execute the following code field, type the following statement: iCounter := iCounter + 1;

   In the Print a message in the device log field, type the following text: Execution point reached {iCounter}

6. Close the dialog.

If the program reaches the execution point, then is does not halt, but executes the code defined above. In addition. a message is issued to the device log.

See also

• Dialog ‘Breakpoint Properties’

Setting a data breakpoint

Requirement: The application is in online mode and running.

1. Click View ‣ Breakpoints.

2. Click Debug ‣ New data breakpoint.

3. Click the button in the New breakpoint dialog (Data tab.

4. In the Input assistant dialog (Watch variables tab), select the variables for which the program should halt when changed.

   As an alternative, specify the qualified variable name of the variables in the Data tab directly in the input line.

5. In the Breakpoints view, select the line with the data breakpoint and click the button.

   ⇒

   The line is marked and identified by the “Data breakpoint enabled” symbol ( ). When the program reaches the data breakpoint (meaning when the value of the selected variables changes), the program processing halts. In the implementation part of the POU, the next line is identified by an arrow . This is identified in the status line by the red-highlighted HALT ON BP status.

6. Click Debug ‣ Start or press F5.

   ⇒

   The program continues running and halts again when the value of the variables changes again.

See also

• Dialog ‘Breakpoint Properties’