ABB AC 800M Library Object Style Manual
  1. Manuals
  2. Brands
  3. ABB Manuals
  4. Controller
  5. AC 800M
  6. Library object style manual

ABB AC 800M Library Object Style Manual

Hide thumbs Also See for AC 800M:
Table of Contents

Advertisement

Quick Links

See also: User Manual , Installation Manual
AC 800M
Library Object Style Guide
System Version 6.0
Power and productivity
for a better world
TM

Advertisement

Table of Contents
loading

Related Manuals for ABB AC 800M

Summary of Contents for ABB AC 800M

  • Page 1 AC 800M Library Object Style Guide System Version 6.0 Power and productivity for a better world...
  • Page 3 AC 800M Library Object Style Guide System Version 6.0...
  • Page 4 In no event shall ABB be liable for direct, indirect, special, incidental or consequential damages of any nature or kind arising from the use of this document, nor shall ABB be liable for incidental or consequential damages arising from use of any software or hard- ware described in this document.

  • Page 5: Table Of Contents

    TABLE OF CONTENTS About This User Manual General ..........................9 Document Conventions ....................10 Warning, Caution, Information, and Tip Icons..............10 Terminology........................11 Related Documentation ....................11 Section 1 - Libraries Introduction ........................13 Purpose ......................13 Library Categories ......................14 Standard Libraries ....................14 User Defined Libraries ..................15 Object Libraries....................15 Library Dependencies......................15 Connected Libraries .....................15...
  • Page 6 Table of Contents Section 3 - Parameter Interface Naming Convention ......................25 Compound Words and Abbreviations ..............25 Parameter Properties ....................... 26 Data Type ......................27 Attributes ......................27 Parameter for Control Modules and Diagrams ............ 28 Parameter for Function Blocks ................30 FD Port ......................
  • Page 7 Table of Contents Data Flow Order....................58 Execution order ....................60 Reverse and Display value attribute on data types in diagrams ......61 Reverse attribute on data types in Diagram types ..........61 Variable and Parameter..................62 Interaction Windows in Online Mode ................63 Introduction ......................63 Interaction Windows ....................65 Information Windows...................65 When to use Interaction Windows ...............65...
  • Page 8 Table of Contents Protection and Scope ................... 88 Re-use of Code..................... 89 Control Module Types ..................91 Function Block Types ..................93 Diagram Types ..................... 93 Data Types ......................93 Templates ......................94 Task Considerations ..................... 94 Parameter Dependency on Tasks and Controllers..........95 Calls to Asynchronous Functions ................

  • Page 9: About This User Manual

    About This User Manual General This manual is primarily a style guide for building object types and data types in application libraries. It describes a concept for enhancing consistency and readability in a library. The manual is organized in this manner: •...

  • Page 10: Document Conventions

    Document Conventions About This User Manual Document Conventions Microsoft Windows conventions are normally used for the standard presentation of material when entering text, key sequences, prompts, messages, menu items, screen elements, etc. Warning, Caution, Information, and Tip Icons This publication includes Warning, Caution, and Information where appropriate to point out safety related or other important information.

  • Page 11: Terminology

    About This User Manual Terminology Terminology A complete and comprehensive list of Terms is included in the Industrial Extended Automation System 800xA, Engineering Concepts instruction (3BDS100972*). The listing included in Engineering Concepts includes terms and definitions as they apply to the 800xA system where the usage is different from commonly accepted industry standard definitions and definitions given in standard dictionaries such as Webster’s Dictionary of Computer Terms.
  • Page 12 Related Documentation About This User Manual 3BSE042835-600...

  • Page 13: Section 1 Libraries

    Section 1 Libraries Introduction The libraries used in the control project must have a consistent appearance. The names of libraries, object types, data types, parameters, and variables must be used consistently. In addition to this, there must be well-defined color schemes, and a standard methodology for user interaction on the interface.

  • Page 14: Library Categories

    BUXSupportLib). Standard Libraries The Standard libraries are included as AC 800M system extensions for 800xA. They contain extended functionality designed by ABB. Almost all object types in the standard libraries are protected. This means that these types cannot be modified and cannot be copied to another library.

  • Page 15: User Defined Libraries

    Section 1 Libraries User Defined Libraries User Defined Libraries User defined libraries should be used for customer or solution specific objects. For these libraries, it is recommended to include a prefix, which designates the origin of the library. For example, the name for the Business Unit X's library can be BUXVesselLib. Object Libraries Object libraries contain templates or ready to use objects such as data types, function block types, control module types, and diagram types that can be used in...

  • Page 16: Split Libraries

    Split Libraries Section 1 Libraries Split Libraries In many cases, dividing a library into several libraries has advantages.  Split libraries can be defined as: • A specific set of libraries where some libraries are common to all applications, and they are complemented by more specialized libraries. •...

  • Page 17: Naming Convention

    Section 1 Libraries Naming Convention Naming Convention The name of a library shall describe its purpose. The name of a library shall consist of a mix of uppercase and lowercase letters forming the structure "LibNameLib". That is, the different parts of the name shall be separated with uppercase letters and the name string shall always end with "Lib".
  • Page 18 Naming Convention Section 1 Libraries 3BSE042835-600...

  • Page 19: Section 2 Types

    Section 2 Types The choice of object type depends on the functionality that surrounds the object (that is, the overall plant design). For more information, refer to the Basic Control Software, Introduction and Configuration manual and also the Application Programming, Introduction and Design manual. Naming Object Types Object types and parameters shall comply with relevant standards and form a...
  • Page 20 Object Types Section 2 Types The length of object type names shall not exceed twelve characters, when this is not possible up to 20 characters are allowed. However, the use of short names is not as critical for control module types as for Function Blocks types. The following reasons are: •...

  • Page 21: Compound Words And Abbreviations

    Section 2 Types Compound Words and Abbreviations Compound Words and Abbreviations The following usage order is recommended: Use the full name Use the short name If it is a compound word, try to use the following rules in the following order: A.

  • Page 22: Suffixes

    Suffixes Section 2 Types There are no strict rules on how to build a short name, but the following methods should be considered: Rule Example Use only a part of a whole word. Acceleration Limiter -> AccelerationLimCC Remove all vowels (and some consonants). Square root ->...
  • Page 23 Section 2 Types Suffixes The following suffixes shall be recognized: Table 3. Object Name Suffixes Short Name Remark Real, Bool, Dint, CC Used as suffix on function blocks that have same or similar function, but the data type of the main signal parameter differs.

  • Page 24: Name Space

    Name Space Section 2 Types Name Space The object type name should be unique, not only within a library, but among all libraries. Object types with the same name but belonging to different libraries can be accessed via dot notation, for example MyLib1.MyFunctionBlock and MyLib2.MyFunctionBlock.

  • Page 25: Section 3 Parameter Interface

    Section 3 Parameter Interface The parameters of Control Modules and Function Blocks should follow the naming and usage convention described in this section. It will be easier for the application programmer to understand the purpose of the different parameters found in each object’s connection list.

  • Page 26: Parameter Properties

    Parameter Properties Section 3 Parameter Interface If it is a compound word, try to use the following rules which was described in Compound Words and Abbreviations on page 21. Names can consist of only one name, for example Enable, but also be composed by several words, InteractionPar.

  • Page 27: Data Type

    Section 3 Parameter Interface Data Type Recommendations for the following properties will be presented: • Name on page 33 • Data Type on page 27 • Attributes on page 27 • Parameter for Control Modules and Diagrams on page 28 •...

  • Page 28: Parameter For Control Modules And Diagrams

    Parameter for Control Modules and Diagrams Section 3 Parameter Interface • hidden • by_ref • constant • Reverse attribute on data types in diagrams • Display value attribute on data types in diagrams Retain shall be used for In and Out parameters in Function Block Types. Whereas ColdRetain is the normal attribute for operator-settings parameters, such as operating time measurements, and parameters for operator interaction.
  • Page 29 Section 3 Parameter Interface Parameter for Control Modules and Diagrams The differences between the four types include the different access rules from the code inside the control module and the limitations for connecting the parameters: • In parameters can only be read, where as Out, In_Out and Unspecified parameters can be both read and written.

  • Page 30: Parameter For Function Blocks

    Parameter for Function Blocks Section 3 Parameter Interface Parameter for Function Blocks In function block types, a parameter can have the direction In, Out or In_Out. Use the direction In or Out whenever possible. Parameters of direction In_Out must be connected for function blocks.

  • Page 31: Initial Value

    Section 3 Parameter Interface Initial value • No Right - Not visible as a port. The parameter will be placed on the right side of the object if the user decides to show it later on. • Yes - Visible as a port on the left side of the object. •...
  • Page 32 Description Section 3 Parameter Interface Type Description Keyword The description field can hold a keyword before the actual description. This keyword holds information about its usage for the application engineer. All parameters in Control Module types, Diagram types, and IN_OUT parameters should have at least one of the first four comments in Table Table 4.

  • Page 33: Parameters With Special Purposes

    Section 3 Parameter Interface Parameters with Special Purposes Parameter description starts with “IN” --> IN port Parameter description starts with “OUT” --> OUT port Parameter description starts with any other string --> INOUT port Changing the first characters containing keywords of the parameter description should be considered an incompatible change.

  • Page 34: Description

    Description Section 3 Parameter Interface • If the object is an alarm owner, its Name should be used as source name when alarms are generated, and must therefore be unique. The Name parameter will then appear in the alarm list as the Source Name of an alarm. In such cases the Name parameter of the type should not have any initial value to force the application engineer to enter a name.
  • Page 35 Section 3 Parameter Interface Description The example object in Figure 3, is part of a standard PID controller with the Name parameter displayed in the Windows title bar and the Description parameter displayed in the control builder faceplate. Figure 3. Example of usage and location of the Name and the Description parameter.

  • Page 36: Interactionpar

    InteractionPar Section 3 Parameter Interface InteractionPar The InteractionPar parameter is a structured data type where the components are all the parameters that can be changed via interaction objects. Note that it is only values that are written to/from the interaction objects that should be placed in this parameter.

  • Page 37: Parerror

    Section 3 Parameter Interface ParError ParError The ParError parameter is set true if any input parameter is out of range. This type of check is mandatory for SIL classified object. For non-SIL objects or SIL marked objects running in a non-SIL environment, the EnableParError parameter may be used.
  • Page 38 Connections Section 3 Parameter Interface Point-to-Point Connection using ControlConnection Data Type A natural way to represent the main signal flow of Control Modules is by structured connections. In this way a single connection, which preferably is done graphically, handles the main signal flow between two adjacent objects. Bidirectional connections should have components for each direction.

  • Page 39: Parameters For Alarm Handling

    Section 3 Parameter Interface Parameters for Alarm Handling The reverse attribute can be used for components in the data types used in communication variables for point-to-point communication. If there is any reverse component in a communication variable, it is communicated from out backwards to in (opposite direction to the normal data flow).
  • Page 40 Monitoring Continuous Execution Section 3 Parameter Interface Table 7. Parameters for continuous functionality in FB and CM Parameter Name Type Direction Comment Enable bool Activates/deactivates continuous functionality. Valid bool Indicates that there is no error status and that the function is active. Warning status does not affect Valid.

  • Page 41: Section 4 Engineering Interface

    Section 4 Engineering Interface The engineering interface is the front-end towards the application engineer. In a library there are Control Module (CM), Function Block (FB) and Diagram (D) types that are ready to use, but also types which are intended to be modified before usage, so called templates.

  • Page 42: General

    General Section 4 Engineering Interface Language name Description Sequential Flow Chart. In steps and transitions is ST used. FD code block This is used in the single graphical code block that only exist in the first tab of a diagram. Other code blocks in the diagram may be of any language.

  • Page 43: Template Design

    Section 4 Engineering Interface Template Design Template Design Templates can be divided into two categories; types that can be edited and types that must be edited. To enable code editing in a template the application engineer must first make a copy of the type. Templates enable the application engineer to customize a common solution.
  • Page 44 Graphical Layers Section 4 Engineering Interface Icons shall be put in layer 1, and the instance name of the icon type should be Icon. When the “surrounding” control module type lacks graphical connections, the icon should not be zoomable. This means the icon inherits the zooming properties of layer 1, that is, it disappears at a zoom level of 0.95 (which means that the type covers more than 95% of the whole screen).
  • Page 45 Section 4 Engineering Interface Graphical Layers Figure 5. Recommended visibility of layers and icon at different zoom levels. 3BSE042835-600...

  • Page 46: Grid And Coordinate System

    Grid and Coordinate System Section 4 Engineering Interface Grid and Coordinate System A basic control module type should typically have four connection nodes and an internal coordinate system extending from (-1,-1) to (1,1). When working with the graphics inside control module type, it is advisable to check Show Grid. The default grid size of 0.02 should normally be used, but other sizes may be used as well.

  • Page 47: Layers And Interaction Windows

    Section 4 Engineering Interface Layers and Interaction Windows Layers and Interaction Windows Control modules in layer 2 When a control module contains other modules, so called sub modules, it is recommended that they are placed in layer 2. Zooming in on the module will reveal the sub-modules, which gives a good overview and also fast access to the modules.

  • Page 48: Icons

    Icons Section 4 Engineering Interface A control module type that represents the interaction window should contain a rectangle with the following properties: • Line color: -3 (Foreground color) • Area color: -1 (Transparent) This means that the area in the window will have window background color. It also means that the window border is visible in layer 2 of the control module.
  • Page 49 Icons Icons in Control Software for AC 800M Control Software for AC 800M recognizes two kinds of icons: the basic icons of IconLib and the control module type icons. The basic icons are typically used for building up the latter, which may contain dynamics. For example, if the control module type is inhibited, a cross should cover the icon, or if the control module type malfunctions, an ErrorIcon should be visible in the control module type icon.
  • Page 50 Icons Section 4 Engineering Interface If the icon is in a template type, the icon must be a public control module type. The name of the type should be NameIcon. For all icons, the control module instance name should be Icon. Size of the ErrorIcon If the symbol in the module icon is not large the ErrorIcon should be in the background of the module, and cover almost the whole icon.

  • Page 51: Function Block Design

    Section 4 Engineering Interface Function Block Design Function Block Design When programming using function block diagrams the layout of a function block is important. The layout of a function block is determined by the order of the parameters, the length of their name, and their direction. The parameters of a function block type can be divided into groups reflecting their usage, for example alarm handling, or group start handling.

  • Page 52: Function Block Example

    Function Block Example Section 4 Engineering Interface ManMode is better than MANMODE. The POU editors allow use of upper and lower case letters for declaration of parameter names, and that the user refers to the name in any form, as long as the letters are the same (for example entering ManMode is the same as entering MANMODE).
  • Page 53 Section 4 Engineering Interface Function Block Example An IN_OUT parameter has connections on both side of the function block, see Figure 7. A graphical consequence of this is that parameters of the direction IN and OUT will be grouped, between IN_OUT parameters, see Table 3BSE042835-600...
  • Page 54 Function Block Example Section 4 Engineering Interface IN and OUT Parameters declared in sequence of 1 to 16. IN_OUT Parameters declared as number 17. Separates parameters into a new group with start from 18. IN and OUT Parameters declared in sequence of 18 to 42.
  • Page 55 Section 4 Engineering Interface Function Block Example Table 8. Parameter list Name Data Type Direction Name Data Type Direction Enable bool PriorityMode bool Name string[30] PriorityStart bool Description string[40] PriorityStop1 bool Interlock bool PriorityStop2 bool SetAuto bool PriorityStop2Txt string AutoMode bool PriorityStop3 bool...
  • Page 56 Function Block Example Section 4 Engineering Interface Table 8. Parameter list (Continued) Name Data Type Direction Name Data Type Direction ActTorque DintIO in_out TrippedStat bool Command DintIO in_out ALStateFault dint SpdRef DintIO in_out AEConfigFault dint TrqRef DintIO in_out AESeverityFault dint TrqSelectorOut DintIO in_out...

  • Page 57: Diagram Design

    Section 4 Engineering Interface Diagram Design Diagram Design Using the Diagram editor allows mixing of functions, function blocks, diagram instances and control modules in the same diagram. The diagram is based on manual layout. This means the user can freely position blocks on the page. The graphical connections are drawn using auto-routing.

  • Page 58: Data Flow Order

    Data Flow Order Section 4 Engineering Interface Figure 8. Diagram Example Containing Different Invocations Data Flow Order In the diagram all invocations are sorted in to a data flow order. The data flow order of the invocations are decided by the connections which depends on the data flow order they are connected to each other.
  • Page 59 Section 4 Engineering Interface Data Flow Order Figure 9. Flow Order Determined by Graphical Placement 3BSE042835-600...

  • Page 60: Execution Order

    Execution order Section 4 Engineering Interface Execution order For control modules the execution order is determined by the normal code sorting. The numeric execution order indication (after the instance name) indicates the execution order of the forward code blocks. Figure 10. Flow Order and Control Module Code Sorting In the Figure 10 the code sorting is done in two ways.

  • Page 61: Reverse And Display Value Attribute On Data Types In Diagrams

    Section 4 Engineering Interface Reverse and Display value attribute on data types in diagrams Reverse and Display value attribute on data types in diagrams As an result of the execution order described in Execution order on page 60, the reverse attribute will work for control modules in diagrams. Split and Join functions shall not to be used with structured data types containing components with the reverse attribute.

  • Page 62: Variable And Parameter

    Variable and Parameter Section 4 Engineering Interface code block, but the backward signal flow must be implemented in a separate code block. Figure 12. Diagram Type with Control Diagram (Forward) and Structured Text (Backward and Set_Output) code blocks Figure 12, the control diagram code represents the forward data flow and the ST code represents the backward data flow.

  • Page 63: Interaction Windows In Online Mode

    Section 4 Engineering Interface Interaction Windows in Online Mode invoked object, or it is possible to insert a variable or parameter object in the diagram as in the lower example in the figure. Figure 13. Connecting Parameters and Variables in Diagrams If the parameters and variables are inserted in the diagram as objects, instead of just textual connections, then the load increases in the editor, but the controller load is not affected.
  • Page 64 Introduction Section 4 Engineering Interface Figure 14. (left) Example of an Interaction window and (right) an Information window. The instance name on the Interaction window (left image on Figure 14) is called Faceplate. The instance name on the Information window (right image on Figure 14), where interaction parameters are assigned, is called InfoPar.

  • Page 65: Interaction Windows

    Section 4 Engineering Interface Interaction Windows Interaction Windows The interaction window contains the most important and frequent (mode changes, etc.) user interactions. There is also a sub window or a part of the interaction window which is called an Information window. When the object type is selected, an interaction window shall be displayed.

  • Page 66: Window Appearance

    Window Appearance Section 4 Engineering Interface Typically, Control Module types are more complex than Function Block Types. Therefore, interaction windows are more often necessary for Control Module types (normally to facilitate configuring). Otherwise, the same rules as for function blocks apply.

  • Page 67: Design

    Section 4 Engineering Interface Design In exceptional cases there may be parameters to determine where the window should appear. There may also be a parameter, which determines if the position is relative to the module or to the screen. Window positioning should be as follows: parameters to the right, trim curve to the left, and bar graph beneath the interaction window.
  • Page 68 Design Section 4 Engineering Interface possible to have separate buttons (for example, pairs Apply/Undo) for the different logical groups. Figure 15. Grouping of option buttons. The following rules should be used in the control module for the interaction window: • Grid size = 0.02 •...

  • Page 69: Interaction Principles

    Section 4 Engineering Interface Interaction principles Figure 16. Interaction window design. Interaction principles Synchronization of data write Sometimes several values should be applied simultaneously, for example the tuning parameters for a PID-controller. There is a built in solution for this in the Control Builder graphics.
  • Page 70 Interaction principles Section 4 Engineering Interface Dimming of objects Texts are dimmed by changing the color of the text. Normally the text has foreground color (-3). The alternative color, that is the dimmed color should be 4. The condition for using the alternative color should be NOT EnableName. The project constant cColors.Disable function can be used for dimming the objects.

  • Page 71: Section 5 Operator Interface

    Section 5 Operator Interface Operator refers to a user that is interacting with the system via a graphical interface in online mode. This includes actions during testing, commissioning, tuning, maintenance and daily operation via an operator‘s Workplace. Introduction Graphic interfaces fetch data via parameters and variables in the object type. In the sub-section InteractionPar on page 36, the concept of InteractionPar, a parameter of...

  • Page 72: Operator Workplace Interaction

    Operator Workplace Interaction Section 5 Operator Interface Operator Workplace Interaction It has to be decided for each object type if it should have operator graphics in the Workplace (Process Portal). Examples of object types that should have Operator Workplace graphics are high level objects such as Motors, Valves, PID-controllers etc.
  • Page 73 Section 5 Operator Interface Faceplates Figure 18. Example of (left) Reduced faceplate and Normal faceplate. The Extended view is optional and should be used for additional information that does not fit in a Normal view and is not so often used during normal operation. Figure 19.

  • Page 74: Display Elements

    Display Elements Section 5 Operator Interface Display Elements The Display Elements are used for graphic displays. The following Display Elements aspects are mandatory for objects with Operator Workplace graphics: • Reduced Icon • Icon • Reduced Icon Icon Figure 20. The mandatory display elements; (left) Reduced Icon, (middle) Icon and (right) Tag.

  • Page 75: National Language Support (Nls)

    Section 5 Operator Interface National Language Support (NLS) National Language Support (NLS) All texts in the faceplates shall be NLS-strings. The NLS-translator is common for all standard libraries so that the total number of NLS-strings is limited. The NLS- translator should further be placed outside the libraries since there is no easy way to have version handled NLS-strings.

  • Page 76: Interaction Principles

    Interaction principles Section 5 Operator Interface Permissions for Variables that are not Hidden All parameters and variables that are not hidden are assumed to be read by everyone. Therefore, no read permissions are assigned. Table 10 describes the write permissions that can be used. These are restricted. Table 10.

  • Page 77: Sil Considerations

    Section 5 Operator Interface SIL considerations SIL considerations Access Level The Access Level defines the rules for changing online values of a running SIL application. Access Level shall be configured on parameters used for interaction in faceplates of SIL1-2 and SIL 3 marked types. For variables and parameters of simple data type the Access Level shall be configured on the variable/parameter (configured in the object type).

  • Page 78: Support For Confirm Operation Dialog

    Support for Confirm Operation Dialog Section 5 Operator Interface Support for Confirm Operation Dialog The faceplate shall be designed so that it is possible to recognize Operation, Object, Property, and Value in the Confirm Operation dialog. Figure 23. Confirm Operation dialog For properties that can be changed through the faceplate (SIL marked types), a separate NLS string shall be defined for confirm write support in the NLS Manager for Access Management.
  • Page 79 Section 5 Operator Interface Support for Confirm Operation Dialog Example: Table 11. Property: SignalErrorMode (dint) Value Description Through Freeze Pre-determined For other data types, for example: real and time, no Value text is necessary. It is the value itself that is displayed in the Confirm Write dialog. The mapping between the value and the Confirm Value NLS string is made in the Confirm Write Support aspect on the type.
  • Page 80 Support for Confirm Operation Dialog Section 5 Operator Interface Figure 24. Relation between Faceplate information and Confirm Operation dialog The Faceplate button in Figure 24 is configured in the Main Faceplate aspect with a Property name and Property Value to which it is set, see Figure 3BSE042835-600...
  • Page 81 Section 5 Operator Interface Support for Confirm Operation Dialog Figure 25. Faceplate button configuration showing associated Property Name and Property Value In the Confirmed Write Support aspect on the type, the property is associated with a Confirm Name, Confirm Value(s), and Operation, which is displayed in the  Confirm Operation dialog.
  • Page 82 Support for Confirm Operation Dialog Section 5 Operator Interface Figure 26. Configuration of the aspect Confirmed Write Support for the Confirm Operation dialog shown in Figure 24 3BSE042835-600...

  • Page 83: Graphical Indication Of Parerror

    Section 5 Operator Interface Graphical Indication of ParError Graphical Indication of ParError The ParError parameter, introduced in the sub-section ParError on page 37, indicates when an input parameter of an object is out of range. In that case the erroneous value is not used in the code. Instead a documented 'safe' value is used. The graphics, Operator Workplace and Control Builder, shall always show how the object works.
  • Page 84 The Operator Workplace Graphics Section 5 Operator Interface Figure 27. ParError indication on a Graphic Element Reduced Icon (left) and in Workplace faceplates (right). The CB Graphics Control Builder graphics have the corresponding red triangle displayed in the upper left corner of the interaction window Figure Figure 28.

  • Page 85: Section 6 Program Code Issues

    Section 6 Program Code Issues Program Code Structured Text shall be used for all program code in the library types. The only exception is the use of SFC in template types, see Templates on page 94. The most important general requirement on the code is that it should be efficient. This means that it should use few local variables, execute fast and generate little communication.

  • Page 86: Descriptions

    Descriptions Section 6 Program Code Issues Figure 29. A code block using a sequence token variable called PrgStep. Descriptions A description should be provided wherever possible. This means that all object types, and data types shall have a brief (three to four short rows) and clear description to be shown under the Description tab in the lower pane of Project Explorer when the object is selected.

  • Page 87: Variables And Project Constants

    Section 6 Program Code Issues Variables and Project Constants A structured data type component shall have a line of text briefly describing its purpose/function. Parameters in object types should be described similarly. Do not write any reference to the online help in a parameter description in an object type.

  • Page 88: Object Sub-Structures

    Object Sub-Structures Section 6 Program Code Issues Project Constants Project constants can be read in libraries and be changed project wide with a single operation. They are suitable for library items that the user may want to change. Examples are date and time formats, logical colors and names, alarm condition texts, and alarm and event texts.

  • Page 89: Re-Use Of Code

    Section 6 Program Code Issues Re-use of Code Re-use of Code Code re-use requires more variables and execution time, but facilitates maintenance. Internal (hidden) function block types should be used to improve the structuring of object types. It is also possible to implement functions by means of placing sub control module types within both Control Module- and Function Block types.
  • Page 90 Re-use of Code Section 6 Program Code Issues It is possible to address sub function block parameters using dot notation. This can be used in order to save memory and execution time. One way to use the dot notation is for access of Out parameters. See the example in Figure 30, where the variable x can be omitted by using dot notation.

  • Page 91: Control Module Types

    Section 6 Program Code Issues Control Module Types Control Module Types Code Sorting and Algebraic Loops The code block sorting is a powerful tool that can be used to minimize delay between input and output signals. This is achieved by dividing the code into different code blocks in Control Builder.
  • Page 92 Control Module Types Section 6 Program Code Issues The code in the control module type should not be divided in code blocks for any other reasons than taking advantage of the code sorting. Unnecessary code blocks will cost extra execution time, especially in SIL-applications, and might danger the code sorting.

  • Page 93: Function Block Types

    Section 6 Program Code Issues Function Block Types Function Block Types Even though there are no code sorting of code blocks within a function block type, the code might be split into more than one code block. This make the code more readable, especially for objects that implements different, non dependant functions.

  • Page 94: Templates

    Templates Section 6 Program Code Issues components in them. The data type should have attribute Protected and have a complete description of all components as well as the type itself. All other data types are presumed to be Public data types. All the Public data types are important for the user.

  • Page 95: Parameter Dependency On Tasks And Controllers

    Section 6 Program Code Issues Parameter Dependency on Tasks and Controllers feature of sub function blocks executing in another task than its parent is that it will not be executed at function block calls in structured text code. Parameter Dependency on Tasks and Controllers The tasks within a controller are recommended to have interval times that are multiples of each other, for scheduling purposes.

  • Page 96: Special Functions

    Special functions Section 6 Program Code Issues Special functions Handling of Input and Output Values The code shall handle its input and output values in the following way: The code shall have a predictable and reasonable behavior for all input values. Input values, which are considered invalid, shall be mapped to valid input values.

  • Page 97: Error Handling

    Section 6 Program Code Issues Error Handling Error Handling If there is any risk that the type may end up in an error state or have a malfunction, it should have error handling. If case of error, an ErrorIcon should appear in layer 1 of the module. An ErrorIcon should also appear in all operator windows.
  • Page 98 Alarm and Event Handling Section 6 Program Code Issues Table 13 summarizes the Alarm and Event parameters for the Standard Library Objects and Figure 32 illustrates the alarm and event logic. Table 13. Summary of Alarm and Event parameters Parameter Direction Data type Function AEClass...
  • Page 99 Section 6 Program Code Issues Alarm and Event Handling Table 13. Summary of Alarm and Event parameters (Continued) Parameter Direction Data type Function InteractionPar.InhXAct In Bool Same as InhXAct but controlled from faceplate. Only introduced for a selection of objects. When declaring the data type for InteractionPar, the InhXAct component must be declared with...
  • Page 100 Alarm and Event Handling Section 6 Program Code Issues Table 13. Summary of Alarm and Event parameters (Continued) Parameter Direction Data type Function AlStateX Dint The alarm state for condition X. Valid if AEConfigX = 1 EnableSupOut Bool Default true. When false, out parameter X is false when XEnabled is false.

  • Page 101: Program Stop Complication

    Section 6 Program Code Issues Program Stop Complication Source name The source name parameter of the AlarmCondBasic instance shall not be connected to a parameter. By doing so, the Name parameter of the closest alarm owner will be used as source name. It is therefore important that all objects with alarms have a Name parameter.

  • Page 102: Power Failure Behavior

    Power Failure Behavior Section 6 Program Code Issues into consideration, when constructing the code of a control module or Function Block. Three alternatives exist: Accept the error code and return failure back to the caller. Ignore the -15 error code and return success back to the caller. Retry the asynchronous procedure when error code is -15 until success or another error emerges.

  • Page 103: Range Check

    Section 6 Program Code Issues Range Check Range Check A real, integer, data type, or time input parameter may have a range. This means that it may be required to have a relation (for example > or <) to one or several constants or other parameters.
  • Page 104 Range Check Section 6 Program Code Issues Example of range test on AEConfig: (* Parameter range test *) ParError := false; IF AEConfig < 0 or AEConfig > 4 THEN AEConfigInt := 1; ParError := true; ELSE AEConfigInt := AEConfig; END_IF;...

  • Page 105: Conditional Range Check

    Section 6 Program Code Issues Conditional Range Check Conditional Range Check If a conditional range check is applied, the execution time can be reduced in  Non-SIL applications. Table 16. Parameter interface for an example type with conditional range check and last good value Data Initial Name...
  • Page 106 Conditional Range Check Section 6 Program Code Issues if MyPar > MyLimit then (* No assignment, use last good value *) ParErrorInt := true; else MyParInt := MyPar; end; (* More range checked assignments ... *) else (* Assignment without range checks *) MyParInt := MyPar;...

  • Page 107: Overflow Handling

    Section 6 Program Code Issues Overflow handling Overflow handling The object must have a predictable behavior when calculating output parameter values. Situations like divide by zero and sqrt() of negative numbers shall be prevented or handled in the code. Example: Create a function Y := (1/T)*G, where T and G are parameters to a function block.
  • Page 108 SIL Mark Restrictions Section 6 Program Code Issues 3BSE042835-600...

  • Page 109: Appendix A Names And Abbreviations

    Appendix A Names and Abbreviations Suggested Names The recommendations consist of the following: • Recommended Names and Abbreviations on page 109 lists recommended names and abbreviations for a number of common types and parameters. • Standard Library Parameters on page 113 lists common parameters used in standard libraries.
  • Page 110 Recommended Names and Abbreviations Appendix A Names and Abbreviations Table 17. Names and recommended abbreviations of type and parameter names. Full name Short name Remarks Automatic Auto Boolean Bool Busy Busy Cascade Casc Channel Chan Command Communication Comm Condition Cond Connect Conn Connected...
  • Page 111 Appendix A Names and Abbreviations Recommended Names and Abbreviations Table 17. Names and recommended abbreviations of type and parameter names. Full name Short name Remarks Enable Error External Feed back Feed forward Fieldbus Foundation Filter Filt Force Force Do not abbreviate Function block Gain Scheduling Hysteresis...
  • Page 112 Recommended Names and Abbreviations Appendix A Names and Abbreviations Table 17. Names and recommended abbreviations of type and parameter names. Full name Short name Remarks Memory Message Mode Mode Do not abbreviate Negative Number Of NoOf Object Occurrence Do not abbreviate Panel Parameter Periodic...

  • Page 113: Standard Library Parameters

    Appendix A Names and Abbreviations Standard Library Parameters Table 17. Names and recommended abbreviations of type and parameter names. Full name Short name Remarks Select Setpoint Signal Simple Simulate Slave Source Start Start Do not abbreviate Status Stat Stop Stop Do not abbreviate String Supervision...

  • Page 114: Bse042835

    Standard Library Parameters Appendix A Names and Abbreviations Table 18. Certain parameters and their descriptions used in standard libraries. Parameter name Description Name The name of the object. This name should appear in the window title of all the operator windows. It should also appear when the module is zoomed to layer 2.
  • Page 115 Appendix A Names and Abbreviations Standard Library Parameters Table 18. Certain parameters and their descriptions used in standard libraries. InteractionPar A parameter of type ObjectNamePar. The components are all the parameters that the operator can interact with via interaction objects. Via this parameter, all operator parameters are available in the surrounding program.
  • Page 116 Standard Library Parameters Appendix A Names and Abbreviations 3BSE042835-600...

  • Page 117: Index

    INDEX direction 38 Display Elements Access Level Icon 74 Confirm 77 Reduced Icon 74 Read-Only 77 Tag 74 AEConfig 97 Area color 48 Aspect Object 72 error display 97 ErrorIcon 50 basic icons 49 Bool 23 by_ref 28 Function Block Diagram 20 CC 23 graphical nodes 46 class 39...

  • Page 118: Index

    Index Index Maneuver icons 50 Administrate 76 ManoeuvreIcon 65 Operate 76 MaxSize 44 Tune 76 Mode icons 50 Name Upload 33 to 34 NLS-strings 75 nosort 27 Project Constants 88 Protection 42 range 37 Real 23 Reset Shape 46 retain 27 Scope Private 88 Public 88...
  • Page 120 Contact us www.abb.com/800xA Copyright© 2003-2014 ABB. www.abb.com/controlsystems All rights reserved. Power and productivity for a better world...

Table of Contents