Skip to main content

Configuring and Running Static Analysis

Using a basic sample project below, you will find the most important steps and options for configuring and running a static analysis.

Requirements: CODESYS Static Analysis is installed.

Sample project

If you want to reproduce the example project, create a standard project and insert the POUs below the application in the device tree. Then configure the communication settings for the connection to your local CODESYS Control Win.

FUNCTION_BLOCK fb1
VAR_INPUT
    iVar_fb1in1 : INT;
    ivar_fb1in2 : INT;
    rVar_fb1in3 : REAL;
END_VAR
VAR_OUTPUT
       iVar_fb1out:INT;
END_VAR
VAR
    P_fSampleProperty : INT;
    rVar : REAL;
    PRO : BOOL;
END_VAR
iVar_fb1out:=iVar_fb1in1 + 1;
FUNCTION_BLOCK fb2
VAR_INPUT
    iVar_fb2in:INT;
END_VAR
VAR_OUTPUT
    iVar_fb2out:INT;
END_VAR
VAR
END_VAR
iVar_fb2out:=iVar_fb2in - 1;
PROGRAM PLC_PRG
VAR
    fb1_inst: fb1;
    fb2_inst: fb2;
END_VAR
fb1_inst(iVar_fb1in1 := 99);
fb2_inst(iVar_fb2in := 22);
fb2_inst(iVar_fb2in := 1);

Checking for compliance to rules

  1. Click Build → Static Analysis → Settings. Switch to the Rules tab.

    A list is displayed containing all possible rule checks. They are organized in a tree structure by topical category. The "rule number" is added in brackets (example: Unused variables (33) in category Unused objects).

  2. Click the check box of the first line a few times (Rules node).

    Clicking toggles the activation status. The check boxes in the entire tree have a red or orange check mark, or no check mark at all.

  3. In this way, activate all entries with a red check mark. This means that CODESYS Static Analysis should report any detected rule violations as errors.

  4. Click Build → Static Analysis → Run Static Analysis.

    Errors are reported in the message view. The message texts are tagged with a sa_icon_message.png and begin with the error number "SA<rule number>".

  5. Double-click the message SA0033: Unused variables 'iVar_fb2out'.

    The focus moves to the declaration part of function block fb2 and the relevant variable is selected. The variable is declared, but not used. This is checked in Rule 33 (Unused variables). In the code, the relevant locations are underlined with a wavy line.

  6. To test the automatic execution of the analysis, click Build → Static Analysis → Settings. On the Settings tab, select the Perform static analysis automatically after compilation option. Click OK to exit the dialog.

  7. Click Online → Login.

    A dialog prompt indicates that compile errors exist. The errors reported by the code analysis are displayed again in the message view.

  8. Click Build → Static Analysis → Settings. Switch to the Rules tab. Now clear all of the rules in the dialog. In the Unused Objects category, explicitly activate Rule SA0035 (Unused input variables (35)) with an orange-colored check mark to report a "warning". See the tooltip for the rule text: This rule corresponds to the following PLCopen rules: CP24). Click OK to exit the dialog.

  9. Click Build → Generate Code.

    The analysis is performed automatically. In the message view, two errors are reported to the Static analysis messages category:

    § SA0035: Unused input 'iVar_fb1in2'

    § SA0035: Unused input 'iVar_fb1in3'

  10. Double-click the message and comment or remove the declaration. Perform the code analysis again.

    No error messages are displayed.

Checking for compliance to defined naming conventions

  1. Click Build → Static Analysis → Settings. Switch to the Naming Conventions tab.

    You see a table in a tree structure that is divided into expandable categories of variables and program blocks.

  2. Expand the Prefixes for VariablesPrefixes for Types category, and in the Prefix column, specify I for INT (14).

    Expand the Prefixes for POUsPrefixes for POU Type category. In the Prefixcolumn, specify the prog for PROGRAM (122) and fb for FUNCTIONBLOCK (103).

  3. Select the First character after prefix should be an upper case letter option. Clear all other options.

  4. Click Build → Static Analysis → Run Static Analysis.

    Error messages:

    • NC0102: Invalid name 'PLC_PRG': Expect prefix 'prog' because PLC_PRG does not have the required prefix

    • First character after prefix should be uppercase: 'ivar_fb1in2' because ivar_fb1in2 : INT; is in fb1.

    • NC0014: Invalid variable name P_fSampleProperty: Expect prefix 'i' because this integer variable does not have the required prefix.

Checking for forbidden symbols

  1. Click Build → Static Analysis → Settings. Switch to the Forbidden Symbols tab.

    A line editor allows for specifying strings that should not to be used in the code.

  2. As an example, double-click the blank line and type in the invalid string PRO directly. Double-click the next blank line and click the _cds_icon_three_dots.png button to open the Input Assistant. From Standard Types, select REAL. Click OK to exit the dialog.

  3. Click Build → Static Analysis → Run Static Analysis.

    The error messages Forbidden symbol 'REAL' and Forbidden symbol 'PRO' are displayed in the message view. Double-click the message text to jump to the relevant line of code.

Displaying of metrics

CODESYS Static Analysis performs selected tests on the code, and you can display the results in a view.

  1. Click Build → Static Analysis → Settings. Switch to the Metrics tab.

    The metrics that CODESYS Static Analysis applies to the code are listed in a table.

  2. For this example, activate the Number of inputs variables metric and specify the permitted value range: lower limit 1 and upper limit 2.

    Activate some more metrics, for example Code size and Number of calls.

  3. Click Build → Static Analysis → View Standard Metrics.

    The view includes a table with a line for each Program unit of the sample program. For each activated metric, there is a column showing the measured values. Values that are outside of the value range defined in the settings are highlighted in red. In the case of this specific example, this is at least the PLC_PRG/Inputs field because the number of input variables in this POU is greater than the defined upper limit of 2.