Statement to suppress warnings
(* syntax for a POU *)
{suppressWarning modelRuleNamespace.modelRuleId('reason for suppression'), scope:=element|file}
PROGRAM name1 | FUNCTION_BLOCK name2 | FUNCTION name3
...
END_PROGRAM | END_FUNCTION_BLOCK | END_FUNCTION
(* syntax for a data type *)
TYPE
{suppressWarning modelRuleNamespace.modelRuleId('reason for suppression'), scope:=element|file}
name4 : ...;
END_TYPE
Meaning |
suppress a warning for the following element, if a rule violation for this element is detected when validating the application and this rule violation would be reported as warning The statement {suppressWarning} can be inserted in front of these ST-elements: Syntax:
Restriction: If a rule refers to a file, the value element will not have any effect. Just define scope:=file for such rules. See "Rules for the validation of an application", whether you are able to suppress warnings for a rule and/or if you need information on the scope of individual rules. |
It is not possible to
suppress warnings for →methods or →interfaces.
suppress errors reported for rule violations. But it is possible to ignore the entire contents of ST-objects.
{suppressWarning com.logicals.mrc.rules.ModelRuleStObjWithResNameOnly('The function block must have a different name than the ST-object.'), scope:=file}
FUNCTION_BLOCK Control
...
END_FUNCTION_BLOCK
Consequences of the statement {suppressWarning} for the concerned POU or data type:
The rule violation will not be listed as warning in the ST-editor or the Problems view anymore but as information.
When the application is validated, the suppressed warning will be listed in the generated report.