PROFIBUS and PROFINET

Transcription

1 PROFIBUS and PROFINET Guideline Communication Function Blocks on PROFIBUS DP and PROFINET IO Version 2.0 November 2005 Order No: 2.182

2 Document Identification: TC a File name: Comm-Func-Block_2182_V20_Nov05 Prepared by the PROFIBUS Working Group 4 Communication Function Blocks in the Technical Committee 2 Communication Profiles. The attention of adopters is directed to the possibility that compliance with or adoption of PI (PROFIBUS International) specifications may require use of an invention covered by patent rights. PI shall not be responsible for identifying patents for which a license may be required by any PI specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. PI specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. NOTICE: The information contained in this document is subject to change without notice. The material in this document details a PI specification in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification in any company's products. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, PI MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE. In no event shall PI be liable for errors contained herein or for indirect, incidental, special, consequential, reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or any third party. Compliance with this specification does not absolve manufacturers of PROFIBUS or PROFINET equipment, from the requirements of safety and regulatory agencies (TÜV, BIA, UL, CSA, FCC, IEC, etc.). PROFIBUS and PROFINET logos are registered trade marks. The use is restricted for members of Profibus International. More detailed terms for the use can be found on the web page Please select button "Presentations & logos". In this specification the following key words (in bold text) will be used: may: indicates flexibility of choice with no implied preference. should: indicates flexibility of choice with a strongly preferred implementation. shall: indicates a mandatory requirement. Designers shall implement such mandatory requirements to ensure interoperability and to claimconformance with this specification. Publisher: PROFIBUS Nutzerorganisation e.v. Haid-und-Neu-Str. 7 D Karlsruhe Germany Phone: +49 (0) 721 / Fax: +49 (0) 721 / pi@profibus.com Web site: No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.

3 CONTENTS 1 General Scope References Definitions and Abbreviations Compliance Principles for modelling Communication Function Blocks Principles of Modelling IEC Function Blocks for Profibus Comm. and as Devices Proxies Library Concept and Program Porting Mapping to IEC Mapping to Functions and Function Blocks Parameters Error Concept Address Concept General DP Address Concept Address Conversion Communication Function Blocks for Host Controller General Information Cyclic Exchange of IO data object General Get IO data object (GETIO) Set IO data object (SETIO) Get a Part of IO data object (GETIO_PART) Set IO data object Related to a Part of a Slot (SETIO_PART) Exchange of Process Data Records General Read Process Data Record (RDREC) Write Data Record (WRREC) Alarms and Diagnosis General Receiving Alarms (RALRM) Read Diagnosis (RDIAG) Higher Communication Functions Interlocked Control (ICTRL) Communication Function Blocks for Supervisor General Reading IO data object Read Input Data (RDIN) Read Output Data (RDOUT) Exchange of Process Data Records Diagnosis Read Diagnosis (RDIAG) Copyright PNO All Rights Reserved Page 3 of 108

4 4.5 Connection Management (CNCT) Communication Function Blocks for Field Devices Model of a PLC as a Field Device IO Data Object Interface General Receive Cyclic Output Data (RCVCO) Subscribe Cyclic Input Data (SBCCI) Provide Cyclic Input Data (PRVCI) Process Data Record Interface General Receive Process Data Record (RCVREC) Provide Process Data Record (PRVREC) Alarm Handling and Diagnosis Send Alarm (SALRM) Generate Diagnosis Information (SDIAG) PLC in Multiple Communication Roles Guidelines for application of Communication Function Blocks Communication Function Blocks and Proxy Function Blocks Communication Function Blocks and PROFINET CBA Mapping Technological Functionality to Proxy FB Using Device IO Integrated and External Device IO Proxy FB for a Device with Local IO Proxy FB for a Field Device with IO via the Process Image Some Recommendations Scheduling of Function Blocks Annex A - Compliance Table Copyright PNO All Rights Reserved Page 4 of 108

5 List of tables Table 1 Communication FB Parameters...19 Table 2 Structure of the Output STATUS...20 Table 3 Error_Decode values...20 Table 4 Error_Code_1 values...20 Table 5 Structure of the Output of ADDR...24 Table 6 Structure of the ADDR data structure of PROFIBUS DP...25 Table 7 Structure of the ADDR data structure of PROFINET IO...25 Table 8 - Transitions and actions for GETIO state diagram...31 Table 9 - Transitions and actions for SETIO state diagram...34 Table 10 - Transitions and actions for GETIO_PART state diagram...37 Table 11 - Transitions of the SETIO_PART state diagram...40 Table 12 - Transitions and actions for RDREC state diagram...43 Table 13 - Transitions of the WRREC state diagram...46 Table 14 - Structure of the variable at AINFO parameter for PROFIBUS DP...48 Table 15 - Structure of the variable at AINFO parameter for PROFINET IO...48 Table 16 - Transitions and actions for RALRM state diagram...51 Table 17 - Transitions and actions for RDIAG state diagram...54 Table 18 States of interlocked control execution...56 Table 19 - Transitions and actions for ICTRL state diagram...58 Table 20 - Transitions and actions for RDIN state diagram...63 Table 21 - Transitions and actions for RDOUT state diagram...66 Table 22 - Transitions and actions for RDIAG state diagram...67 Table 23 - Structure of the variable at D_ADDR input for PROFIBUS DP...69 Table 24 - Structure of the variable at D_ADDR input for PROFINET IO...69 Table 25 - Transitions and actions for CNCT state diagram...71 Table 26 Transitions and actions for RCVCO state diagram...76 Table 27 - Transitions and actions for SBCCI state diagram...78 Table 28 - Transitions and actions for PRVCI state diagram...80 Table 29 - Transitions and actions for RCVREC state diagram...84 Table 30 - Transitions and actions for PRVREC state diagram...89 Table 31 - Transitions and actions for SALRM state diagram...93 Table 32 - Transitions and actions for SDIAG state diagram...95 Copyright PNO All Rights Reserved Page 5 of 108

6 Table of figures Figure 1 Application of the Communication Function Blocks...10 Figure 2 Proxy FB and Communication Function Blocks...17 Figure 3 Usage of function block libraries with Communication Function Blocks and Proxy FB...18 Figure 4 Function ID...23 Figure 5 Function ADDR...23 Figure 6 SLOT...24 Figure 7 Function Block ADDR_TO_ID...25 Figure 8 Function Block ID_TO_ADDR...26 Figure 9 System with a PLC as Host Controller...27 Figure 10 Communication Function Blocks for cyclic exchange of data...27 Figure 11 Communication path for cyclic IO data object...28 Figure 12 GETIO function block...30 Figure 13 State diagram of GETIO function block...31 Figure 14 SETIO function block...33 Figure 15 State diagram of SETIO function block...34 Figure 16 GETIO_PART function block...36 Figure 17 State diagram of GETIO_PART function block...37 Figure 18 SETIO_PART function block...39 Figure 19 State diagram of SETIO_PART function block...40 Figure 20 Communication Function Blocks for acyclic exchange of data records...41 Figure 21 RDREC function block...42 Figure 22 State diagram of RDREC function block...43 Figure 23 WRREC function block...45 Figure 24 State diagram of WRREC function block...46 Figure 25 RALRM function block...50 Figure 26 State diagram of RALRM function block...51 Figure 27 RDIAG function block...53 Figure 28 State diagram of RDIAG function block...54 Figure 29 Interlocked Control Timeline...55 Figure 30 ICTRL function block...57 Figure 31 State diagram of ICTRL function block...58 Figure 32 Profibus system with a PLC as Supervisor...61 Figure 33 RDIN function block...62 Figure 34 State diagram of RDIN function block...63 Figure 35 RDOUT function block...65 Figure 36 State diagram of RDOUT function block...66 Figure 37 CNCT function block...70 Figure 38 State diagram of CNCT function block...71 Figure 39 Profibus system with a PLC as Field Device...73 Figure 40 PLC as a Field Device Using IO data object...74 Figure 41 RCVCO function block...75 Figure 42 State diagram of RCVCO function block...76 Figure 43 SBCCI function block...77 Figure 44 State diagram of SBCCI function block...78 Figure 45 PRVCI function block...79 Figure 46 State diagram of PRVCI function block...80 Figure 47 RCVREC function block...83 Figure 48 State diagram of RCVREC function block...84 Figure 49 PRVREC function block...88 Figure 50 State diagram of PRVREC function block...89 Figure 51 SALRM function block...92 Figure 52 State diagram of SALRM function block...93 Figure 53 SDIAG function block...95 Figure 54 State diagram of SDIAG function block...95 Figure 55 PLC in multiple communication roles...97 Figure 56 Usage of Communication FB and Proxy FB in the PLC program (Host Controller)...98 Figure 57 Concepts of FB application...99 Figure 58 Field Device with local IO Figure 59 Field Device with external IO Copyright PNO All Rights Reserved Page 6 of 108

7 Figure 60 Proxy FB MINI_PID with local IO Figure 61 Proxy FB MINI_PID_2 with IO via the process image Figure 62 Scheduling of a function block Figure 63 Multiple scheduling of a FB instance by invokations in different programs Figure 64 Multiple scheduling of a FB instance by different invokations in the same programs Copyright PNO All Rights Reserved Page 7 of 108

8 Foreword For PROFIBUS DP and PROFINET IO sets of communication services are defined in IEC The representation of these services in the application program is dependent of the various controllers and devices provided by different manufactures. State of the art for the programming model and programming languages in the area of the programmable controllers (PLC) is the international standard IEC This standard defines a set of language elements and mechanisms (e.g. data types, function blocks) which are commonly applied in a well defined set of programming languages (e.g. Ladder Diagram, Structured Text). This specification defines a common set of Communication Function Blocks applicable in application programs using the IEC languages. The application of this specification can provide benefits for the following three groups: End users want to implement applications (including application software and devices) using predefined solutions and having a wide choice and independent mixture of various PLC and Field Devices on PROFIBUS DP and PROFINET IO respectively. PLC manufacturers want to offer the PLC series with a wide choice of Field Devices from various manufactures. Field Device manufacturers wants to have applied his Field Devices easily with a wide choice of minimise the effort to use these Field Devices with different PLC. The first published version V 1.20 July 2001 of this specification defined a set of Communication Function Blocks for PROFIBUS DP. This 2 nd version V 2.0 specifies a set of function blocks which is applicable for PROFIBUS DP and PROFINET IO and which are compatible to the first version to a large extent. Following relevant changes are made in the version 2.0. Clause Feature Reason all scope extended for PROFINET IO relevance of PROFINET IO all naming conventions made more general to conform to the extended scope of PROFIBUS DP and PROFINET IO 1.3 definitions for PROFINET IO added extended scope of PROFINET IO 2.6 EN input and ENO output are optional and may be omitted from the textual Function Block declarations EN and ENO are used according to IEC , chapter FC NSLOT deleted because of irrelevance unified address concept for PROFIBUS DP and PROFINET IO UML compatible presentation of the state diagrams extended scope of PROFINET IO IEC compatibility 3 FB SYCFR deleted because of irrelevance 3.2 FB GETIO_PART and SETIO_PART added Structure of the variable at AINFO parameter for PROFINET IO requirement to access parts of the IO data of a module FB RALRM extended for PROFINET IO Copyright PNO All Rights Reserved Page 8 of 108

9 . Communication Function Blocks on PROFIBUS DP and PROFINET IO Version 2.0 Clause Feature Reason 3.5 representation of state diagrams in UML conforming to PNO regulations 3.5 mapping to PROFINET IO services added 4.5 Structure of the variable at D_ADDR input for PROFINET IO 5.3 FB RCVREC and PRVREC: F_ID parameter extended to DWORD to hold slot and subslot 5.3 FB RCVREC and PRVREC: New output parameter SUBSLOT extended scope of PROFINET IO FB CNCT extended for PROFINET IO different address concept of PROFINET IO different address concept of PROFINET IO 6 PLC in multiple communication roles using all Communication Function Blocks in one application program 7.2 Communication Function Blocks and PROFINET CBA A.1 Compliance table extended for PROFINET IO explanation extended scope of PROFINET IO B Application example DPV1 Parameter Channel deleted The following figure gives an overview of the PNO profiles and the placement of this guideline in the context of the other PNO specifications. Application Profiles II PA Devices RIO for PA SEMI PROFIdrive V2.0 and V3.0 Ident Weighing & Dosage Encoder Integration Technologies System Profiles 1 x Application Profiles I Communication Technologies RS 485 RS 485 -IS CommFB, IEC 61158/61784 Common Application Profiles (optional): PROFIsafePROFIsafe, Time Stamp, Redundancy, etc. PROFIBUS DP PROFIBUS DP / PROFINET NRZ Intrinsic Safety Fiber Optics: Glass Multi Mode Glass Single Mode PCF / Plastic Fiber MBP *): MBP -LP: MBP -IS: DP- V0...V2 Manchester Bus Powered Low Power Intrinsic Safety Descriptions (GSD, EDD) Tools (DTM, Configurators ) Master Conformance Classes Interfaces (Comm - FB, FDT,etc.) Constraints Copyright PNO All Rights Reserved Page 9 of 108

10 1 General 1.1 Scope This specification defines a set of Communication Function Blocks for communication among programmable controllers and Field Devices over PROFIBUS DP and PROFINET IO respectively. These Communication Function Blocks are defined according the international standard for programming languages of PLC IEC The Communication Function Blocks shall have universal interfaces for as well as PROFIBUS DP and PROFINET IO. Therefore if the Communication Function Blocks are used in technology function blocks. The technology function blocks can be defined with similar interfaces for different IO systems. Application program in IEC language Technology function block Communication Block Function Communication Block Function PROFIBUS DP PROFINET IO Figure 1 Application of the Communication Function Blocks This specification gives also some "Guidelines for the application of the Communication Function Blocks", i.e. for implementing Field Device specific Proxy Function Blocks usable in the PLC. Also the relationship to PROFINET CBA is shown in the guideline. 1.2 References The following normative documents contain provisions which constitute provisions of this specifications. IEC :2004, Digital data communications for measurement and control - Fieldbus for use in industrial control systems Part 5: Application layer service definition. IEC :2004, Digital data communications for measurement and control - Fieldbus for use in industrial control systems Part 6: Application layer protocol specification. Copyright PNO All Rights Reserved Page 10 of 108

11 PROFINET IO, Application Layer Service Definition, Application Layer Protocol, Version 2.0, April NOTE PROFIBUS DP is already part of IEC 61158, PROFINET IO will be part of IEC as Type 10. PROFINET IO is already published IEC PAS 62411, IEC : 2 nd Edition , Programmable Controllers, Part 3: Programming languages. 1.3 Definitions and Abbreviations For the purpose of this specification the following definitions apply. For definitions adopted from other standards the source reference is given application program self-contained sequence of computer instructions to solve a task NOTE In this specification is a application program a set of function blocks and functions written in a IEC language array aggregate that consists of data objects, with identical attributes, each of which may be uniquely referenced by subscripting [IEC ] cyclic (exchange of data) term used to describe events which repeat in a regular and repetitive manner [IEC ] Communication Function Block basic function block defined in this specification and supplied by the PLC manufacturer for the access to Field Devices data type set of values together with a set of permitted operation [IEC ] declaration mechanism for establishing the definition of a language element. NOTE A declaration normally involves attaching an identifier to the language element, and allocating attributes such as data types and algorithms to it. [IEC ] DP-master (Class 1) controlling device which controls several DP-slaves (Field Devices); usually a programmable controller or distributed control system [IEC ] Copyright PNO All Rights Reserved Page 11 of 108

12 1.3.8 DP-master (Class 2) controlling device which manages configuration data (parameter sets) and diagnosis data of a DP-master (Class 1); additionally the DP-master (Class 2) can perform all communication capabilities of a DP-master (Class 1) [IEC ] DP-slave Field Device that is assigned to one DP-master (Class 1) as a provider for cyclic IO data object exchange, in addition acyclic functions and alarms could be provided [IEC ] Field Device device acting as a PROFIBUS DP-slave or PROFINET IO Device respectively function block (FB) programmable controller programming language element consisting of: (i) the definition of a data structure partitioned into input, output, and internal variables; and (ii) a set of operations to be performed upon the elements of the data structure when an instance of the function block type is invoked [IEC ] function program organisation unit which, when executed, yields exactly one data element and possibly additional output variables (which may be multi-valued, e.g., an array or structure), and whose invocation can be used in textual languages as an operand in an expression [IEC ] Host Controller controller acting as a PROFIBUS DP-master (Class 1) or PROFINET IO Controller respectively Human Machine Interface (HMI) reading and writing interface for the machine or control equipment operator or shop floor personell to the process data identifier combination of letters, numbers, and underline characters which begins with a letter or underline and which names a language element [IEC ] instance (of a function block) individual, named copy of the data structure associated with a function block type or program type, which persists from one invocation of the associated operations to the next [IEC ] Copyright PNO All Rights Reserved Page 12 of 108

13 index address of an object within an application process [IEC ] IO Controller controlling device, which acts as client for several IO Devices (Field Devices) NOTE This is usually a programmable controller or a distributed control system. [PROFINET IO] IO data object object designated to be transferred cyclically for the purpose of processing and referenced by device/slot/subslot [PROFINET IO] IO Device Field Device which acts as server for IO operation [PROFINET IO] IO Supervisor engineering device which manages commissioning and diagnosis of an IO system [PROFINET IO] IO subsystem subsystem composed of one Host Controller and all its associated Field Devices [PROFINET IO] IO system system consisting of a Host Controller and Field Devices which act as server for IO operation to the Host Controller [derived from PROFINET IO] invocation process of initiating the execution of the operations specified in a program organization unit like function block and function [IEC ] language element item identified by a symbol on the left-hand side of a production rule in the formal specification [IEC ] library (of function blocks) organised set of function blocks for the use in application programs Copyright PNO All Rights Reserved Page 13 of 108

14 module addressable unit inside the Field Device [IEC , IEC ] parameter (input and output parameter) variable assuming a constant used as an argument to pass in or out a function block or function [IEC ] process data data which are already pre-processed and transferred acyclically for the purpose of information or further processing [IEC ] Proxy function block (Proxy FB) function block used in the IEC application program representing a Field Device or a functional part of a Field Device slot address of a module within a Field Device [IEC , IEC ] Structured Text (ST) textual PLC programming language using (i) the same common elements as all IEC languages like data types, function blocks and (ii) the specific operators like +, - and (iii) language statements like IF, CASE, WHILE, which are adopted from the well know general purpose languages BASIC or PASCAL [IEC ] subslot address of a structural unit within a slot Supervisor device or tool acting as a PROFIBUS DP-master (Class2) or PROFINET IO Supervisor respectively task execution control element providing for periodic or triggered execution of a group of associated program organisation units like function block or funktions [IEC ] Copyright PNO All Rights Reserved Page 14 of 108

15 type (of a function block) PLC languages element consisting of: (i) the definition of a data structure partitioned into input, output, and internal variables; and (ii) a set of operations to be performed upon the elements of the data structure when in instance of the function block type is invoked [IEC ] 1.4 Compliance This subclause defines the requirements which shall be met by programmable controller systems and Field Devices which claim compliance with this PNO specification. The definition of the function blocks in this specification is based on the elements and rules of the "common elements" of IEC (2 nd edition). Therefore it is required that a programming system which uses the here defined function blocks is compliant to the IEC standard. This specifications defines a set of Communication Function Blocks which have defined names, interfaces and functionality. The function block interface comprises the names, the data type and the order of the input and output parameters. The functionality is defined by the state diagram and the associated transition and action table. A system which claims compliance with this PNO specification shall provide a subset of the here defined of Communication Function Blocks. All provided function blocks shall have the full set of parameters and functionality. The compliant function blocks shall be listed in the "Compliance Table" according Annex A. In a second table also shown in Annex A the permitted "Implementation dependant features" shall be listed. Copyright PNO All Rights Reserved Page 15 of 108

16 2 Principles for modelling Communication Function Blocks 2.1 Principles of Modelling The following principles of modelling for the Communication Function Blocks have to be met: to fit into the existing PLC systems, e.g. using the existent addressing concept to be efficient and without overhead; that means the model shall be performance oriented to enable a easy application program porting between different PLC systems universal interface for the use with different types of IO communication subsystems especially to support the use of PROFIBUS DP and PROFINET IO to use directly the existing PROFIBUS DP or PROFINET IO functions, i.e. if possible one Communication Function Block shall cover one service. to apply good programming style is to avoid dependencies of the hardware configuration data such as addressing in the application program. 2.2 IEC Function Blocks for Profibus Communication and as Devices Proxies There are various possibilities in a program of a PLC acting as a Host Controller (DP Master Class 1 and IO Controller respectively) to access to the data in remote modules and Field Devices (DP-slave and IO Device respectively): A typical solution in the PLC is the "cyclic access" via the so-called process image to the remote inputs and outputs. In the application program these remote variables are used like local I/O variables. The data exchange over the fieldbus happens cyclically. The variables are transferred independently of the execution of the application program and mapped in the process image. In this specification a set of Communication Function Blocks is defined like read and write record to achieve a data transfer which is triggered by the application program in the PLC. The Figure 2 shows an instance of the so called Proxy Function Block representing the Field Device in the IEC application program in the PLC. This device specific Proxy function block exhibits the input and output parameters of the represented Field Device. Inside the Proxy FB standardised Communication Function Blocks provide the reading and writing access to the Field Device data using the standard Profibus protocols. Copyright PNO All Rights Reserved Page 16 of 108

17 Host controller (PLC): IEC program Technology FB Proxy FB FB_Field_Device _Control WRREC Comm. FB RDREC IO Subsystem: PROFIBUS DP or PROFINET IO Field Device: IEC program Comm. FB RCVREC Figure 2 Proxy FB and Communication Function Blocks 2.3 Library Concept and Program Porting Figure 3 illustrates the usage of libraries of two PLC systems with standardised Communication Function Blocks. The manufacturers of the PLC systems A and B provide their programming systems according IEC and offer both their own library with the Communication Function Blocks as defined in this PNO specification. These Communication Function Blocks have the identical interface and functionality but are specifically implemented for the different PLC systems and IO subsystems. The Communication Function Blocks can be used by the application programmers and also by the Field Device manufacturers to build the specific Proxy FB. PLC manufacturers may provide libraries of standardised Proxy FB based on fieldbus profiles and the Communication Function Blocks to support application development integrating Field Device functionality and support access to Field Device maintenance and diagnose features. As shown in figure 2 two different Field Device manufacturers C and D can provide their own libraries with specific Proxy function block C and D for the application support of their Field Devices connected via Profibus to the PLC systems A and B. The device manufacturers use the standardised Communication Function Blocks for the implementation of their Proxy FB executa- Copyright PNO All Rights Reserved Page 17 of 108

18 ble in different PLC systems. They can apply the same Proxy FB implementation using the standard Communication Function Blocks of the required PLC library. The application programmers of the PLC systems A and B can use the specific Proxy FB C and D as well as the basic Communication Function Blocks. The application programs using same the IEC programming language and the standardised Communication Function Blocks and Proxy FB can easily ported from PLC system A to B. PLC System A Proxy FB Library: Field device manufacturer C uses Comm FB and provides Proxy FB Proxy FB PLC System B Library: C CommFB A Field device manufacturer D uses Comm FB and provides Proxy FB C Comm FB B D C A Proxy FB Comm FB Application program: Portation D C B Proxy FB Comm FB Application program: Figure 3 Usage of function block libraries with Communication Function Blocks and Proxy FB The guidelines in clause 4 offer additional information to implement and apply of the Communication Function Blocks and Proxy FB. 2.4 Mapping to IEC The Communication Function Blocks map onto objects and services defined in IEC Type 3 (Profibus DP) and IEC Type 10 (PROFINET IO) respectively. 2.5 Mapping to Functions and Function Blocks The communication between the application program written in an IEC language and the Field Devices connected via an IO subsystem to the PLC is modelled by Communication Function Blocks. This specification defines the Communication Function Blocks for the cyclic and acyclic data access. The representation of the interface of the function and function block types is given in graphical and textual form according IEC The EN input and ENO output are given in the graphical representation of the declarations of the cyclic function blocks. These parameters are optional and may be omitted when calling the function block instance according to IEC , chapter The behaviour of the function blocks is presented as a graphical state diagram with a table for the transitions and the actions. Copyright PNO All Rights Reserved Page 18 of 108

19 2.6 Parameters Parameters of different Communication Function Blocks with the same or a similar meaning shall have the same name and data type according Table 1: Table 1 Communication FB Parameters Parameter Data Type Meaning EN BOOL Enable ENO BOOL Enable output REQ BOOL Request function ID DWORD Identification of a Field Device or a slot / subslot of it INDEX INT Identifier of a process data object OFFSET INT Count of the first byte within IO Data object LEN INT Actual data length of a process data record DONE BOOL Flag that the function has finished successfully VALID BOOL Flag that the function has finished successfully and the received output data are valid BUSY BOOL Flag that the function is still performing its task, its not ready to perform a new task ERROR BOOL Flag that the function has finished with an error STATUS DWORD Completion or error code The Functions and Function Blocks may use the EN input and ENO output according to IEC , chapter The IO data object, the process data records or the alarm and diagnosis information is passed by input-output parameters to the Communication Function Blocks. Typically these data can be described as an array of byte. The length of the byte arrays may vary from instance to instance of one Communication Function Block. It shall also be possible to use a structured data type if the used data is structured. The INDEX input addresses a process data record, the LEN parameter contains the length of a process data record. NOTE The data type INT is used for both the INDEX and LEN parameter though the value range of the parameters in the IO subsystems may cover The data type INT is supported by all PLC implementations, the better fitting UINT is not always supported. The value range of is sufficient for nearly all applications. The data type INT was already used by version 1.20 of this PNO guideline, and it is kept for compatibility reason. Nevertheless an INDEX > may be given on the interface using a negative number or a hexadecimal constant. The ANY data type is used to allow the use of byte arrays of different lengths, the use of structured data types as buffers for IO data object, the process data records or the alarm and diagnosis information, or different address data structures. The user shall use variables of appropriate size which can contain the information wished. The implementer may cause an error if he can detect that a given variable does not fit to the requested service. The DONE and the ERROR outputs pulses only from one invocation of the instance of the Communication Function Block. The FB parameters use those data types of IEC which are supported in a wide range of PLC and is contained in the portability level of PLCopen. Copyright PNO All Rights Reserved Page 19 of 108

20 2.7 Error Concept Communication Function Blocks indicate if the requested function (block) was performed successfully or not. The error indication is typically used for two purposes: 1. To change the reaction to the process i.e. to implement a substitute reaction e.g. to repeat the request at another time or another place or to abort the process task. 2. To issue an alarm message to an HMI system by the application program or by the PLC system automatically. NOTE In case 1 only very few different reactions dependent on the indicated error are typical. Detailed error information is hardly used. If the Communication Function Block maps directly to one service primitive of IEC the error indications of the used service primitive is used as error indication of the function block too. The Function_Num byte, Error_Decode byte, Error_Code_1 byte, and Error_Code_2 byte of the DP service primitives are combined to the STATUS output. The STATUS output has the data type DWORD which is interpreted as a packed array of four bytes as described in the following table. Table 2 Structure of the Output STATUS Byte Name Definition Date type 0 Function_Num contains Function_Code / Error_Code, byte PDU_Identifier, and Frame_Selector 1 Error_Decode defines the meaning of Error_Code_1 and Error_Code_2, byte see Table 3 2 Error_Code_1 see Table 4 byte 3 Error_Code_2 implementer specific byte NOTE The error code 2 should be used only for the purpose to detail an error defined with error decode byte and error code 1 byte e.g. for the use of an protocol analyser or an other diagnosis device. The Function_Num byte is used as defined in IEC and IEC respectively. The value 16#40 shall be used, if no protocol element is used. The Error_Decode byte defines the meaning of Error_Code_1 and Error_Code_2. Table 3 Error_Decode values Error_Decode Source Meaning 16# #7F PLC No error or warning 16#80 DP V1, PNIO Error reported according to IEC #81 PNIO Error reported according to IEC # #8F PLC 18#8x reports an error according the x-th parameter of the call of the Communication Function Blocks 16#FE.. 16#FF DP Profile profile-specific error The Error_Code_1 defines the reason of the reported error, see Table 5. Table 4 Error_Code_1 values Error_Decode Error_Code_1 Source Meaning 16#00 16# No error and no warning 16# #7F 16# #FF PLC Warning 16#80 16# #9F PLC Implementer specific 16#80 16#A0 PLC Read error 16#80 16#A1 PLC Write error 16#80 16#A2 PLC Module failure 16#80 16#A3.. 16#A6 PLC Implementer specific 16#80 16#A7 PLC Busy Copyright PNO All Rights Reserved Page 20 of 108

21 Error_Decode Error_Code_1 Source Meaning 16#80 16#A8 PLC Version conflict 16#80 16#A9 PLC Feature not supported 16#80 16#AA.. 16#AF PLC DP-master specific 16#80 16#B0 Access Invalid index 16#80 16#B1 Access Write length error 16#80 16#B2 Access Invalid slot 16#80 16#B3 Access Type conflict 16#80 16#B4 Access Invalid area 16#80 16#B5 Access State conflict 16#80 16#B6 Access Access denied 16#80 16#B7 Access Invalid range 16#80 16#B8 Access Invalid parameter 16#80 16#B9 Access Invalid type 16#80 16#BA.. 16#BF Access User specific 16#80 16#C0 Resource Read constrain conflict 16#80 16#C1 Resource Write constrain conflict 16#80 16#C2 Resource Resource busy 16#80 16#C3 Resource Resource unavailable 16#80 16#C4.. 16#C7 Resource Implementer specific 16#80 16#C8.. 16#CF Resource User specific 16#80 16#D0.. 16#FF User specific User specific 16#81 16# #FF PNIO PNIO specific error, see PROFINET IO, Table #82 16# #FF PLC Error concerning the value the 2 nd parameter : : : : 16#8F 16# #FF PLC Error concerning the value the 15 th parameter 16#90 IOxS PLC Transfer of IOxs (only PROFINET IO) 16#FE.. 16#FF 16# #FF Profile Profile-specific errors General errors coming from the IO subsystems shall use the value 16#80 or 16#81 as the value of the Error_Decode byte. Errors which can explicitly mapped to one parameter of the function block code the parameter number in the least significant nibble of the Error_Decode byte, e.g. 16#82xx means that an error was detected for parameter number 2. The parameters are counted beginning with the input parameters starting with 1 and continuing with the output and input/output parameters as defined in the function block declaration. NOTE The first parameter of all Communication Function Blocks is of type BOOL and cannot issue an error. Quality information provided by the used IO system shall be evaluated and returned as an error code in the STATUS output if the STATUS output is not set to a value not equal to zero, e.g. a negative IOPS of PROFINET IO shall result in Error_Decode =16#90 and the value of the IOxS state in Error_Code_1. The outputs at function blocks for the cyclic I/O services e.g. GETIO is set or reset at every invocation of the function block instance. In this case an error will appear for a longer time in the STATUS output if it is not only temporary. Temporary errors may be treated as irrelevant by the application program. The outputs at function blocks for a acyclic services e.g. RDREC shows the state of the last requested service. They will stay at the same values until the service is requested with the same function block instance again. 2.8 Address Concept General The address concepts of the different IO Systems may be different. This will result in different functions or function parameters to identify a Field Device, a slot or subslot inside a Field Device. Copyright PNO All Rights Reserved Page 21 of 108

22 All Communication Function Blocks hide the address concept of the different IO Systems, i.e. the address of one identified functionality can be used with all Communication Function Blocks. The application program shall be able to use the Communication Function Blocks without knowledge of the explicit hardware configuration e.g. the MAC address of a Field Device or the position of a slot or subslot in a modular Field Device. It shall be able to use symbolic addressing DP Address Concept Addresses shall allow to identify technological functions which communicate with the PLC and its application program via Profibus DP. Typically these technological functions are represented by one slot of a DP-slave, a continuous series of slots or a whole DP-slave. Additionally the configured allocation of technological functions to slots of a DP-slave e.g. in the PA profile shall be supported. The address concept considers existing DP addressing and existing address concepts of PLC. A PLC may communicate to DP-slaves which are connected to different DP systems, i.e. the PLC is DP-master (Class 1) to different DP systems. A DP-slave is addressed using a station number unique within the DP system. To address a slot of a DP-slave an additional slot number is used. All numbers have ranges that do not exceed , i.e. one DWORD can hold this information. If a PLC is acting as a DP-master (Class 2) it can address different DP systems using a segment number. As a DP-master (Class 1) the segment number is not relevant and set to zero. The input parameter ID of the Communication Function Blocks addresses one slot of a DP-slave or a DP-slave. The ID contains a handle of data type DWORD, the value of it is implementerspecific. The handle may be generated by local means of the PLC or its configuration system or may be generated by using one of the following functions: ID: Conversion of a physical address of a DP-slave to the handle ADDR: Conversion of a handle to the physical address of a DP-slave SLOT: Addressing a slot of a DP-slave Note IEC distinguishes between function block and function. The function does not have the instance construct like the function block but it can be used as a simple means to provide a value Function ID The function ID converts the physical identification of a slot to a handle which can be used with the Communication Function Blocks. The slot has a unique slot number within a DP-slave, the DP-slave has a unique station number in a DP system, and a DP system is identified by an identification of its master interface. The identification of its master interface may be PLC-specific or unique in the automated system. A DP-master (Class 2) can use a DP segment number additionally. Copyright PNO All Rights Reserved Page 22 of 108

23 BOOL --- EN BYTE --- MASTER BYTE --- SEGMENT BYTE --- STATION BYTE --- SLOT ID ENO --- BOOL --- DWORD Note: According IEC nd Edition the main function output does not have a formal name in the graphical representation. FUNCTION ID : DWORD (* Generate DP slot handle *) VAR_INPUT EN : BOOL; MASTER : BYTE; (* ID of the DP system *) SEGMENT : BYTE; (* Number of the DP segment *) STATION : BYTE; (* Number of the DP-slave (station address) *) SLOT : BYTE; (* Number of the slot *) VAR_OUT ENO ; : BOOL; Figure 4 Function ID NOTE The EN and ENO parameters are optional and may be omitted when calling the function in textual languages. The slot number 0 is used to address the DP-slave interface. If no slot exists at the given physical address 16#FFFF_FFFF is returned as an error indication. The output ENO shall be false Function ADDR The function ADDR converts a handle which addresses a slot or a DP-slave into its physical address. BOOL --- EN DWORD --- ID ADDR ENO --- BOOL --- DWORD FUNCTION ADDR : DWORD (* Convert DP slot handle to physical address *) VAR_INPUT EN : BOOL; ID : DWORD; (* Slot or device handle *) VAR_OUT ENO ; : BOOL; Figure 5 Function ADDR NOTE The EN and ENO parameters are optional and may be omitted when calling the function in textual languages. The result of the function ADDR is a DWORD which is interpreted as a packed array of four bytes as described in the following table. NOTE: An output of data type DWORD is used because it is not allowed to use a structured variable as a function result with IEC Copyright PNO All Rights Reserved Page 23 of 108

24 Table 5 Structure of the Output of ADDR Byte Name Definition Date type 0 master DP master interface identification byte 1 segment segment number byte 2 station station number byte 3 slot slot number byte If the handle of a DP-slave interface is given, the returned slot number shall be Function SLOT The function SLOT provides the handle of a slot identified by its number to a given DP-slave. BOOL --- EN DWORD --- ID BYTE --- SLOT SLOT ENO --- BOOL --- DWORD FUNCTION SLOT : DWORD (* Provides the slot to a given DP-slave handle *) VAR_INPUT EN : BOOL; ID : DWORD; (* Handle to a DP-slave or a slot *) SLOT : BYTE; (* Slot number *) VAR_OUT ENO ; : BOOL; Figure 6 SLOT NOTE The EN and ENO parameters are optional and may be omitted when calling the function in textual languages. If the handle of a DP-slave is given, the returned handle addresses the slot identified by the number in the SLOT input of this DP-slave. If the handle at input ID addresses a slot of a DPslave the same handle is returned as if the DP-slave is addressed at the input ID. If a slot with this number does not exist 16#FFFF_FFFF is returned as an error indication. The output ENO shall be false. NOTE If an implementer uses the physical address in its handle, these functions may easily be implemented using logic and arithmetic expressions Address Conversion Addresses shall allow to identify technological functions which communicate with the PLC and its application program. Typically these technological functions are represented by one slot or subslot of a Field Device. The address conversion considers existing PROFIBUS DP and PROFINET IO addressing and existing address concepts of PLC. A PLC may communicate to Field Devices which are connected to different IO subsystems. The input parameter ID of the Communication Function Blocks addresses one slot of a PROFIBUS DP-slave or a subslot of a PROFINET IO Device. The ID contains a handle of data type DWORD, the value of it is implementer-specific. The handle may be generated by local means of the PLC or its configuration system or may be generated by using one of the following functions: ADDR_TO_ID: Conversion of a address of a PROFINET IO Device to the handle Copyright PNO All Rights Reserved Page 24 of 108

25 ID_TO_ADDR: Conversion of a handle to the address of a PROFINET IO Device Function Block ADDR_TO_ID The function block ADDR_TO_ID converts the physical identification of a slot of a PROFIBUS DP-slave or subslot of a PROFINET IO Device to a handle which can be used with the Communication Function Blocks. ADDR_TO_ID BOOL --- EN ENO --- BOOL STATUS --- DWORD ID --- DWORD ANY --- ADDR ADDR FUNCTION_BLOCK ADDR_TO_ID (* Generate a handle *) VAR_INPUT EN : BOOL; (* Enable *) VAR_OUTPUT ENO : BOOL; (* Flag *) STATUS : DWORD; (* Last detected status *) ID : DWORD; (* Handle *) VAR_IN_OUT ADDR : ANY; (* Data structure to define the address of *) (* a slot of a PROFIBUS DP-slave or *) (* a subslot of a PROFINET IO Device *) Figure 7 Function Block ADDR_TO_ID NOTE The EN and ENO parameters are optional and may be omitted when calling the function in textual languages. The physical address is given in a data structure which contains the address components as shown in the following tables: Table 6 Structure of the ADDR data structure of PROFIBUS DP Name Date type Definition SYSTEM BYTE Type of the IO Subsystem (1= PROFIBUS DP) VERSION BYTE Version of the data structure (1= Version 1) D STRUCT Identification of the Field Device MASTER BYTE DP master interface identification SEGMENT BYTE segment number STATION BYTE station number END_STRUCT SLOT BYTE slot number Table 7 Structure of the ADDR data structure of PROFINET IO Name Date Type Definition SYSTEM BYTE Type of the IO Subsystem (2= PROFINET IO) VERSION BYTE Version of the data structure (1= Version 1) D STRUCT Identification of the Field Device STATIONNAME STRING Station name INSTANCE WORD Instance ID DEVICE WORD Device ID VENDOR WORD Vendor ID END_STRUCT API DWORD application process identifier SLOT WORD Slot Number (identification of a slot) SUBSLOT WORD Subslot Number (identification of a subslot) Copyright PNO All Rights Reserved Page 25 of 108

26 NOTE The string containing the station name shall be of appropiate size. NOTE The structures of Table 6 and Table 7 are equivalent to the address information in Table 23 and Table 24 For PROFIBUS DP the slot number 0 is used to address the DP-slave interface. For PROFINET IO the subslot number 0 is used to address a slot of a PROFINET IO Device. If the IO Device, the slot or subslot does not exist at the given physical address an error is given at the STATUS output. The output ENO shall be false Function Block ID_TO_ADDR The function block ID_TO_ADDR converts a handle which addresses a slot of a PROFIBUS DPslave or a subslot of a PROFINET IO Device into its physical address. ID_TO_ADDR BOOL --- EN ENO --- BOOL DWORD --- ID STATUS --- DWORD ANY --- ADDR ADDR FUNCTION ID_TO_ADDR (* Convert a handle to physical address *) VAR_INPUT EN : BOOL; (* Enable *) ID : DWORD; (* Slot or subslot handle *) VAR_OUTPUT ENO : BOOL; (* Flag *) STATUS : DWORD; (* Last detected status *) VAR_IN_OUT ADDR : ANY; (* Physical address information *) Figure 8 Function Block ID_TO_ADDR NOTE The EN and ENO parameters are optional and may be omitted when calling the function in textual languages. The result of the function block ID_TO_ADDR is a data structure which contains the physical address as shown in Table 6 Structure of the ADDR data structure of PROFIBUS DP and Table 7 Structure of the ADDR data structure of PROFINET IO. If the given handle at the ID input is not valid, an error is given at the STATUS output. The output ENO shall be false. Copyright PNO All Rights Reserved Page 26 of 108

27 3 Communication Function Blocks for Host Controller 3.1 General Information This clause defines the Communication Function Blocks for a PLC acting as a Host Controller (DP Master (Class 1) or PROFINET IO Controller) programmed in IEC PLC as Host Controller programmed in IEC PLC as Supervisor (programmed in IEC ) IO Subsystem Remote I/O as Field Device Field Device PLC as Field Device programmed in IEC Figure 9 System with a PLC as Host Controller The following function blocks define the application program interface to the basic services for a PLC acting as a Host Controller: GETIO: Get input data of a Field Device SETIO: Set output data of a Field Device GETIO_PART: Get a part of input data of a Field Device SETIO_PART: Set a part of output data of a Field Device RDREC: Read a process data record from a Field Device WRREC: Write a process data record to a Field Device RALRM: Receive an alarm from a Field Device RDIAG: Read diagnosis information from a Field Device The following function blocks define a application program interface with higher communication functions using the basic services for a PLC acting as a Host Controller: ICRTL: Request a interlocked control function from a Field Device 3.2 Cyclic Exchange of IO data object General The figure below shows the two FBs for cyclic exchange of IO data object. GETIO SETIO BOOL --- EN ENO --- BOOL BOOL --- EN ENO --- BOOL DWORD --- ID STATUS --- DWORD DWORD --- ID STATUS --- DWORD LEN --- INT INT --- LEN ANY --- INPUTS-- --INPUTS ANY --- OUTPUTS-- --OUTPUTS Figure 10 Communication Function Blocks for cyclic exchange of data Copyright PNO All Rights Reserved Page 27 of 108