Visibility Control

Visibility modifiers also none as access modifiers can be applied to some elements of CODESYS project or library. CODESYS will provide two groups of these modifiers.

1. Attributes for decorating POU's

   Attributes will control the visibility of some elements in a way that a user of CODESYS will not able to see this element. The CODESYS compiler is still able to use these elements. An application which is using a element decorated with one of these attributes will not present an compile error.

2. Special Keywords like PUBLIC, PROTECTED, INTERNAL, PRIVATE for decorating Programs, Function Blocks, Properties and Methods

   With the help of these special keywords it is possible to define the access rights for a specific element. An application which is using a element decorated with one of these keywords will present an compile error if the access to this element is not allowed by the related keyword.

Attributes for Controlling the Visibility

 

In the CODESYS library template, concrete examples for the usage of some attributes regarding the visibility of symbols are provided:

•  

  {attribute 'qualified_only'} for enums types

  This attribute introduces a new name space. So one member of a enum type can be reused in an other enum type.

  For accessing a member of a enum type decorated with this attribute prefixing the name of this member

  with the name of the enum type is necessary.

  {attribute 'qualified_only'}
  TYPE ERROR : (NO_ERROR, TIME_OUT); END_TYPE

  eErrorID : ERROR;
  eErrorID := ERROR.NO_ERROR;

•  

  {attribute 'qualified_only'} for global variable lists

  This attribute introduces a new name space. So one member of the gvl can be reused in an other gvl.

  For accessing a member of a global variable list decorated with this attri­bute prefixing the name of this member

  with the name of the variable list is necessary.

  {attribute 'qualified_only'}
  VAR_GLOBAL CONSTANT
      gc_iDummy : INT := 42; /// This is a dummy global constant variable
  END_VAR

  iMyVar := GVL.gc_iDummy;

•  

  {attribute 'hide_all_locals'} for function blocks

  This attribute hide all local variables.

  {attribute 'hide_all_locals'}
  FUNCTION_BLOCK ETrigA_Temp EXTENDS CBML.ETrigA
  VAR_INPUT
     (* specific inputs *)
  END_VAR
  VAR_OUTPUT
     eErrorID : ERROR;
     (* specific outputs *)
  END_VAR
  VAR
     (* specific vars *)
  END_VAR

•  

  {attribute 'conditionalshow_all_locals' := 'SomeText'} or {attribute 'condi­tionalshow_all_locals'} for function blocks

  This attribute hide all local variables if the related library is installed as *.compiled-library.

  If the related library is available in the repository as a *.library the local variables are visible.

  {attribute 'conditionalshow_all_locals' := 'SomeText'}
  //{attribute 'conditionalshow_all_locals'}
  FUNCTION_BLOCK LCon_Temp EXTENDS CBML.LCon
  VAR_INPUT
     (* specific inputs *)
  END_VAR
  VAR_OUTPUT
     eErrorID : ERROR;
     (* specific outputs *)
  END_VAR
  VAR
     (* specific vars *)
  END_VAR

•  

  {attribute 'conditionalshow' := 'SomeText'} or {attribute 'conditionalshow'} for function blocks

  This attribute hide the whole function block if the related library is installed as *.compiled-library.

  If the related library is available in the repository as a *.library the func­tion block is visible.

  // This is a container to carry init data from the Create methode of the factory
  // to the prvInstInit methode of the new generated function block instance
  {attribute 'conditionalshow' := 'SomeText'}
  //{attribute 'conditionalshow'}
  {attribute 'enable_dynamic_creation'}
  FUNCTION_BLOCK CustomData EXTENDS FBF.InstanceData
  VAR_INPUT
      (* Todo: Add your application specific data as input variables *)
  END_VAR

Keywords for Controlling the Visibility

The main difference between controlling visibility with attributes to the method of using keywords is that these keywords will not simply hide symbols. The related symbols are really not accessible.

To encapsulate parts of your application has naturally some pros and cons.

Pros

• Because the implementation of a function block is not known to other classes, the implementation can be modified without affecting collaboration with other function blocks.

• Increased clarity as only the public interface of a class needs to be considered (Debugging, Documentation).

Cons

• Unit testing a maximum encapsulated function block is not so easy, because the access to specific internals is not possible.

  Note

  In the future, solving CDS-51581 may provide a better way to handle such situations.

PUBLIC:

PROTECTED:

INTERNAL:

PRIVATE: