Required vs. recommended steps

If you create a logi.SAFE or a logi.WEB library, some steps of the instructions are required whereas other are recommended (see the icon within the following table). One step of the instructions is not possible for a logi.SAFE or a logi.WEB library (see the icon within the following table).

If required, it is also possible to install the library. But usually, this step is not required for a logi.SAFE or a logi.WEB library.

Notes on the syntax for the library configuration

Requirement: Insert the statement PTK_FOR_LIBRARY_BUILD within the library configuration. Complete the statement by the name of one platform for which the binary code should be generated.

Possibility: The keyword SiLCoverageReviewed can be added to the statement IEC, if a deviation from the full test coverage is justified.

Restrictions: Do not use the following statements or values within the library configuration:

• IMPLEMENTS_LOGICALS_LIB

• SUPPORTED_PTKS

• COMMON_SOURCE

• USES

• BINARIES

• INCLUDES

• SOURCES

• INTERFACE and OBJECT for DEPLOY in the statement IEC

If you are using these statements/values within the library configuration for a logi.SAFE or logi.WEB library anyway, either it is not possible to generate the library or these statements or the library elements specified by these values are ignored when the library is generated. This means that – if the library is generated – the library will be generated as if these statements or these library elements have not been included.

Requirements for library elements

When you specify library elements for the statement IEC within the library configuration, mind that these library elements match the following requirements:

• used-defined →function blocks

  • A user-defined function block must not use the following elements:

    • keyword IMPLEMENTS to implement →interfaces

    • →methods

    • →global variables (VAR_GLOBAL)

    • →external variables (VAR_EXTERNAL)

    • →retentive variables (= keyword RETAIN for a variable section)

    • input variables or output variables that are declared based on the data types CHAR or STRING

  • If you specify a user-defined function block with the value PUBLIC for VISIBILITY, the interface of this function block must also not use the following elements:
    

    • →in-out variables (VAR_IN_OUT)

    • REF_TO (see →reference) for →input variables or for →output variables

    • input variables or output variables that are declared based on →structured data types, →array data types, the data types DATE, DATE_AND_TIME, TIME_OF_DAY, CHAR or STRING

    • array input variables or array output variables

• user-defined →functions with the value PRIVATE for VISIBILITY

• →vendor function blocks – but they must not be extendable and they must not use any →generic data types
  If you specify a vendor function block with the value PUBLIC for VISIBILITY, the interface of this vendor function block must not use the above-listed elements as well.
  Moreover, the interface of the vendor function block must not include the specifications additionalLibraries and additionalObjects within the statement {ImplementationProperties ( )}. Instead, the interface must include the specification functionHasCFile within this statement.

• →data types with the value PRIVATE for VISIBILITY
  In case of some explicitly named data types, this is valid as well:

  • A derived data type with the name SAFEBOOL must have the base type BYTE.

  • A derived data type with the name SAFEINT must have the base type INT.

• elements that have been created within the current project
  This means: Do not specify elements with their origin being a library.

These elements must not be used at all for a logi.SAFE or logi.WEB library:

• interfaces

• vendor functions

If you are specifying invalid library elements within the library configuration for a logi.SAFE or logi.WEB library anyway, it is not possible to generate the library because the appropriate rule violations are reported during the validation.