Software Design Guide Anybus -CompactCom 30 ® Doc.Id. HMSI-168-97 Rev. 2.08 Connecting DevicesTM HALMSTAD • CHICAGO • KARLSRUHE • TOKYO • BEIJING • MILANO • MULHOUSE • COVENTRY • PUNE • COPENHAGEN HMS Industrial Networks Mailing address: Box 4126, 300 04 Halmstad, Sweden Visiting address: Stationsgatan 37, Halmstad, Sweden E-mail: [email protected] www.hms-networks.com Important User Information This document is intended to provide a good understanding of the software interface used on Active Anybus CompactCom communication modules. Passive modules are not covered, nor does this document cover any network specific features; this information is instead available as separate documents (Network Interface Appendices). The reader of this document is expected to be familiar with high- and low-level software design, and communication systems in general. Liability Every care has been taken in the preparation of this manual. Please inform HMS Industrial Networks AB of any inaccuracies or omissions. The data and illustrations found in this document are not binding. We, HMS Industrial Networks AB, reserve the right to modify our products in line with our policy of continuous product development. The information in this document is subject to change without notice and should not be considered as a commitment by HMS Industrial Networks AB. HMS Industrial Networks AB assumes no responsibility for any errors that may appear in this document. There are many applications of this product. Those responsible for the use of this device must ensure that all the necessary steps have been taken to verify that the applications meet all performance and safety requirements including any applicable laws, regulations, codes, and standards. HMS Industrial Networks AB will under no circumstances assume liability or responsibility for any problems that may arise as a result from the use of undocumented features, timing, or functional side effects found outside the documented scope of this product. The effects caused by any direct or indirect use of such aspects of the product are undefined, and may include e.g. compatibility issues and stability issues. The examples and illustrations in this document are included solely for illustrative purposes. Because of the many variables and requirements associated with any particular implementation, HMS Industrial Networks AB cannot assume responsibility for actual use based on these examples and illustrations. Intellectual Property Rights HMS Industrial Networks AB has intellectual property rights relating to technology embodied in the product described in this document. These intellectual property rights may include patents and pending patent applications in the US and other countries. Trademark Acknowledgements Anybus ® is a registered trademark of HMS Industrial Networks AB. All other trademarks are the property of their respective holders. Warning: This is a class A product. in a domestic environment this product may cause radio interference in which case the user may be required to take adequate measures. ESD Note: This product contains ESD (Electrostatic Discharge) sensitive parts that may be damaged if ESD control procedures are not followed. Static control precautions are required when handling the product. Failure to observe this may cause damage to the product. Anybus CompactCom 30 Software Design Guide Rev 2.08 Copyright© HMS Industrial Networks AB Mar 2014 Doc Id HMSI-168-97 Table of Contents Table of Contents Preface About This Document Related Documents.................................................................................................................................. 1 Document History ................................................................................................................................... 1 Conventions & Terminology .................................................................................................................. 2 Support....................................................................................................................................................... 2 Chapter 1 About the Anybus CompactCom General Information ................................................................................................................................ 3 Features ...................................................................................................................................................... 3 Chapter 2 Software Introduction Background................................................................................................................................................ 4 The Object Model .................................................................................................................................... 5 Basics............................................................................................................................................... 5 Addressing Scheme........................................................................................................................... 5 Object Categories.............................................................................................................................. 5 Standard Object Implementation....................................................................................................... 6 Network Data Exchange......................................................................................................................... 7 Diagnostics ................................................................................................................................................ 9 Multilingual Support................................................................................................................................. 9 Chapter 3 Host Communication Layer General Information .............................................................................................................................. 10 Basic Principles .............................................................................................................................. 10 Telegram Contents.......................................................................................................................... 10 Handshake Registers .............................................................................................................................. 11 Control Register (Read/Write)....................................................................................................... 11 Status Register (Read Only) ........................................................................................................... 11 Supervised Bit (SUP)..................................................................................................................... 12 Auxiliary Bit (STAT_AUX, CTRL_AUX)............................................................................ 12 Process Data Subfield ............................................................................................................................ 13 General Information....................................................................................................................... 13 Process Data Mapping ................................................................................................................... 13 Changed Data Indication ............................................................................................................... 14 Anybus Watchdog .................................................................................................................................. 15 Application Watchdog ........................................................................................................................... 15 Serial Host Communication.................................................................................................................. 16 General Information....................................................................................................................... 16 Serial Telegram Frame................................................................................................................... 16 Message Fragmentation .................................................................................................................. 17 Transmission Errors ...................................................................................................................... 18 Parallel Host Communication .............................................................................................................. 20 General Information....................................................................................................................... 20 II Memory Map................................................................................................................................. 20 Parallel Telegram Handling ........................................................................................................... 21 Chapter 4 The Anybus State Machine General Information.............................................................................................................................. 22 State-Dependent Actions ...................................................................................................................... 23 Chapter 5 Object Messaging General Information.............................................................................................................................. 24 Basic Principles .............................................................................................................................. 24 Source ID ...................................................................................................................................... 24 Error Handling ............................................................................................................................. 24 Message Layout ...................................................................................................................................... 25 Data Format ............................................................................................................................................ 26 Available Data Types.................................................................................................................... 26 Handling of Array of Char (Strings).............................................................................................. 26 Flow Control........................................................................................................................................... 27 Command Specification ........................................................................................................................ 28 General Information....................................................................................................................... 28 Command Codes............................................................................................................................ 29 Error Codes................................................................................................................................... 29 Get_Attribute ............................................................................................................................... 30 Set_Attribute ................................................................................................................................ 30 Create............................................................................................................................................ 31 Delete ............................................................................................................................................ 31 Reset.............................................................................................................................................. 32 Get_Enum_String ........................................................................................................................ 32 Get_Indexed_Attribute ................................................................................................................. 33 Set_Indexed_Attribute.................................................................................................................. 33 Chapter 6 Initialization and Startup General Information.............................................................................................................................. 34 Initial Handshake.................................................................................................................................... 35 Anybus Setup (‘SETUP’-State) ............................................................................................................ 36 Network Initialization (‘NW_INIT’-State) ........................................................................................ 37 Chapter 7 Anybus Module Objects General Information.............................................................................................................................. 38 Object Revisions..................................................................................................................................... 38 Anybus Object (01h).............................................................................................................................. 39 Diagnostic Object (02h) ........................................................................................................................ 44 Network Object (03h) ........................................................................................................................... 47 Network Configuration Object (04h) ................................................................................................. 51 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 III Chapter 8 Host Application Objects General Information.............................................................................................................................. 53 Implementation Guidelines .................................................................................................................. 54 Application Data Object (FEh) ........................................................................................................... 55 Command Details: Get_Instance_Number_By_Order .................................................................. 58 Command Details: Get_Profile_Instance_Numbers....................................................................... 59 Command Details: Get_ADI_Info ............................................................................................... 60 Command Details: Remap_ADI_Write_Area............................................................................. 61 Command Details: Remap_ADI_Read_Area.............................................................................. 63 Application Object (FFh)...................................................................................................................... 64 Appendix A Categorization of Functionality Basic ......................................................................................................................................................... 69 Extended.................................................................................................................................................. 69 Advanced ................................................................................................................................................. 69 Appendix B Network Comparison Chart Appendix C Timing & Performance General Information.............................................................................................................................. 72 Internal Timing....................................................................................................................................... 73 Startup Delay ................................................................................................................................ 73 NW_INIT Delay......................................................................................................................... 73 Anybus Response Time......................................................................................................................... 74 Overview ........................................................................................................................................ 74 Telegram Delay.............................................................................................................................. 74 Command Delay............................................................................................................................ 75 Process Data ........................................................................................................................................... 76 Overview ........................................................................................................................................ 76 Anybus Read Process Data Delay (Anybus Delay)........................................................................ 76 Anybus Write Process Data Delay (Anybus Delay) ...................................................................... 77 Network System Read Process Data Delay (Network System Delay)............................................. 77 Network System Write Process Data Delay (Network System Delay)............................................ 77 Appendix D Runtime Remapping of Process Data Parallel mode........................................................................................................................................... 78 Read Process Data......................................................................................................................... 78 Write Process Data........................................................................................................................ 79 Serial Mode.............................................................................................................................................. 80 Read Process Data......................................................................................................................... 80 Write Process Data........................................................................................................................ 81 Example: Remap_ADI_Write_Area ................................................................................................... 82 Appendix E CRC Calculation General..................................................................................................................................................... 83 Example ................................................................................................................................................... 84 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Preface P. About This Document For more information, documentation etc., please visit the HMS website, ‘www.anybus.com’. P.1 Related Documents Document ABCC Hardware Design Guide ABCC Driver User Guides ABCC Network Interface Appendices (separate document for each networking system) ABCC Drive Profile Design Appendices (separate document for each networking system) Author HMS HMS HMS HMS P.2 Document History Summary of Recent Changes (2.07 ... 2.08) Change Updated Initial Handshake section (interrupts allowed during initialization) Updated support info Page(s) 35 2 Revision List Revision 1.00 1.01 1.10 1.11 1.12 1.13 1.20 1.21 1.23 1.24 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 Date 2005-09-05 2005-09-21 2007-01-28 2007-07-09 2008-01-10 2008-10-23 2008-12-17 2009-04-30 2009-06-29 2009-11-20 2010-04-13 2010-08-20 2010-09-17 2011-01-14 2011-08-12 2012-04-13 2012-12-14 2013-04-26 2014-03-07 Anybus CompactCom 30 Doc.Rev. 2.08 Author PeP PeP PeP PeP PeP HeS HeS PeP PeP KeL KeL KeL KeL KeL KeL KeL KeL KeL KeL Chapter(s) All 5, 7, 8 All 3, 7 3, 5, 8, C 3, 5, 7, A 3, 7, 8 3, 4, 5, 7, 8, A, C 3, 7, 8 7 B P, 7, B B 5, 7, B 8, B P, 6 Description First official version Minor adjustments Major updates Minor updates Minor updates Minor updates Major updates Minor updates Minor updates Minor updates Minor updates, categorizing of objects Minor update Minor corrections Minor corrections and updates Minor updates Minor update Minor corrections Minor corrections and updates Minor update Doc.Id. HMSI-168-97 About This Document P-2 P.3 Conventions & Terminology The following conventions are used throughout this document: • Numbered lists provide sequential steps • Bulleted lists provide information, not procedural steps • The terms ‘Anybus’ or ‘module’ refers to the Anybus CompactCom module. • The terms ‘host’ or ‘host application’ refers to the device that hosts the Anybus CompactCom. • Hexadecimal values are written in the format NNNNh or 0xNNNN, where NNNN is the hexadecimal value. • Intel byte order is assumed unless otherwise stated • Object Instance equals Instance #0 • Object Attributes resides in the Object Instance • The terms ‘Anybus implementation’ and ‘Anybus version’ generally refers to the implementation in the Anybus module, i.e. network type and internal firmware revision. • Unless something is clearly stated to be optional, it shall be considered mandatory. • When writing, fields declared as ‘reserved’ shall be set to zero. • When reading, fields bits declared as ‘reserved’ shall be ignored. • Fields which are declared as ‘reserved’ must not be used for undocumented purposes. • A byte always consists of 8 bits. P.4 Support For general contact information and where to find support, please refer to the contact and support pages at www.hms-networks.com. Anybus CompactCom 30 Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 1 1. About the Anybus CompactCom 1.1 General Information The Anybus CompactCom network communication module is a high performance, low cost communication solution for industrial field devices. Typical applications are Frequency Inverters, PLCs, HMIs, Visualization Devices, Instruments, Scales, Robotics and Intelligent measuring devices. The Anybus CompactCom software interface is designed to be network protocol independent, allowing the host application to support all major networking systems using the same software driver, without loss of functionality. To provide flexibility and room for expansion, an object oriented addressing scheme is used between the host application and the Anybus module. This allows for a very high level of integration, since the host communication protocol enables the Anybus module to retrieve information directly from the host application using explicit object requests rather than memory mapped data. HMS supplies a free source level (C language) software driver that can be used freely to speed up the development process. The driver act as “glue” between the Anybus module and the host application, i.e. it separates the low level host interface communication from the host application software and provides easy to use function calls for common Anybus related tasks. The driver is fully OS independent, and can even be used without an operating system if required. For more information, consult the ABCC Driver User Guide. Note: This document does not cover Passive Anybus CompactCom modules. For further information, consult the separate network interface appendices for these products. 1.2 Features • Object oriented technology • Network protocol independent • Multilingual support • High level of integration • Cyclic and Acyclic data • Optional support for advanced network specific features • Serial or Parallel operation • Interrupt operation (optional) • Free source level (C-language) software driver available Chapter 2 2. Software Introduction 2.1 Background 0101101101010110010011 0000101010110100111011 Data from Fieldbus 1000010101100000100010 0100110010111000000001 0010001101000100001010 Network The primary function of an industrial network interface is to exchange information with other devices on the network. Traditionally, this has mostly been a matter of exchanging cyclic I/O and making it available to the host device via two memory buffers. Network Interface 0101101101010110010011 0000101010110100111011 Data to Fieldbus 1000010101100000100010 0100110010111000000001 0010001101000100001010 As demand for higher level network functionality increases, the typical role of a network interface has evolved towards including acyclical data management, alarm handling, diagnostics etc. By utilizing modern object oriented technology, the Anybus CompactCom provides a simple and effective way of supporting most networking systems, as well as taking advantage of advanced network functionality, without having to write separate software drivers for each network; Acyclic requests are translated in a uniform manner, and dedicated objects provide diagnostic and alarm handling according to each network standard. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Network Generally, the way this is implemented differs fundamentally between different networking systems. This means that supporting and actually taking advantage of this new functionality is becoming increasingly complex, if not impossible, without implementing dedicated software support for each network. Network Interface Cyclic Data 0101101101010110010011 0000101010110100111011 Data from Fieldbus 1000010101100000100010 0100110010111000000001 0010001101000100001010 Cyclic Data 0101101101010110010011 0000101010110100111011 Data to Fieldbus 1000010101100000100010 0100110010111000000001 0010001101000100001010 Acyclic Request Acyclic Handling Acyclic Response Alarm Diagnostic Handling Diagnostics Doc.Id. HMSI-168-97 Software Introduction 5 2.2 The Object Model 2.2.1 Basics To provide a flexible and logical addressing scheme for both the host application and the Anybus module, the software interface is structured in an object oriented manner. While this approach may appear confusing at first, it is nothing more than a way of categorizing and addressing information. Related information and services are grouped into entities called ‘Objects’. Each object can hold sub-entities called ‘Instances’, which in turn may contain a number of fields called ‘Attributes’. Attributes typically represents information or settings associated with the Object. Depending on the object in question, Instances may either be static or created dynamically during runtime. Object #1 (Instance #0) Attributes: #1 #2 #3 #4 #5 Instance #3 Instance #2 Instance #1 Attributes: #1 #2 #3 #4 #5 2.2.2 Addressing Scheme Objects, and the their contents, are accessed using Object Messaging. Each object message is tagged with an object number, instance, and attribute, specifying the location of the data or setting associated with the message. Example: The module features an object called the ‘Anybus Object’, which groups common settings relating the Anybus module itself. In this object, instance no. 1 contains an attribute called ‘Firmware version’ (attribute no. 2). To retrieve the firmware revision of the module, the host simply issues a ‘get’-request to object no. 1 (Anybus Object), Instance 1, Attribute 2 (Firmware version). IMPORTANT: This addressing scheme applies to both directions; i.e. just like the Anybus module, the host application must be capable of interpreting incoming object requests and route them to the appropriate software routines. 2.2.3 Object Categories Based on their physical location, objects are grouped into two distinct categories: • Anybus Module Objects These objects are part of the Anybus firmware, and typically controls the behaviour of the module and its actions on the network. • Host Application Objects These objects are located in the host application firmware, and may be accessed by the Anybus module. This means that the host application must implement proper handling of incoming object requests. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Software Introduction 6 2.2.4 Standard Object Implementation The standard object implementation has been designed to cover the needs of all major networking systems, which means that it is generally enough to implements support for these objects in order to get sufficient functionality regardless of network type. Optionally, support for network specific objects can be implemented to gain access to advanced network specific functionality. Such objects are described separately in each Network Interface Appendix. Anybus Module Objects The following objects are implemented in the standard Anybus CompactCom firmware: • Network Object Anybus Object • Diagnostic Object • Network Object • Network Configuration Object • Network Specific Objects Network Configuration Object Anybus Object Diagnostic Object Note: Exactly how much support that needs to be implemented for these objects depends on the requirements of the host application. Router Network Specific Objects Driver See also... • “Anybus Module Objects” on page 38 Host Interface Host Application Driver Host Application Objects The following objects shall be implemented in the host application. • Application Data Object (Mandatory) • Application Object (Optional) • Network Specific Objects (Optional) Note: It is mandatory to implement the Application Data Object. The exact implementation however depends heavily on the requirements of the host application. Implementation of the Application Object is optional, albeit highly recommended. Router Application Data Object Network Specific Objects ADI Application Object See also... • “Host Application Objects” on page 53 Note: The ‘router’-part in the figure above symbolizes a software component which interprets the header information in an object message and routes it’s data to the appropriate software function. The ‘driver’-part is responsible for maintaining the host communication. This functionality is implemented within the standard Anybus firmware, and will need to be implemented in the host application as well. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Software Introduction 7 2.3 Network Data Exchange Data that is to be exchanged on the network is grouped in the Application Data Object. This object shall be implemented in the host application firmware, and each instance within it (from now on referred to as ‘ADI’, i.e. Application Data Instance) represents a block of network data. ADIs are normally associated with acyclic parameters on the network side; for example, on DeviceNet, ADIs are represented through a dedicated CIP-object, while on PROFIBUS, ADIs are accessed through acyclic DP-V1 read/write services. ADIs can also be mapped as Process Data, either by the host application or from the network (where applicable). Process Data is exchanged through a dedicated data channel in the Anybus CompactCom host protocol, and is normally associated with fast cyclical network I/O. The exact representation of Process Data is highly network specific; for example on PROFIBUS, Process Data correlates to IO data. Cyclic Data 0101101101010110010011 0000101010110100111011 Process Data Buffer* 1000010101100000100010 (Read) 0100110010111000000001 0010001101000100001010 Cyclic Data 0101101101010110010011 0000101010110100111011 Process Data Buffer* 1000010101100000100010 (Write) 0100110010111000000001 0010001101000100001010 Host Application Process Data Handling (Dedicated Channel) Application Data Object Acyclic Request Translation Application Parameter Object Request ADI 1 Network ADI 2 Application Parameter ADI 3 Acyclic Response Translation Object Response Application Parameter *) These buffers holds data from ADI's that are mapped to Process Data. Each ADI may be tagged with a name, data type, range and default value, all of which may be accessed from the network (if supported by the network in question). This allows higher level network devices (e.g. network masters, configuration tools etc.) to recognize acyclic parameters by their actual name and type (when applicable), simplifying the network configuration process. Some networking systems allows both cyclic and acyclic access to the same parameter. In the case of the Anybus CompactCom, this means that an ADI may be accessed via explicit object requests and Process Data simultaneously. The Anybus module makes no attempt to synchronize this data in any way; if necessary, the host application must implement the necessary mechanisms to handle this scenario. The Anybus interface uses little-endian memory addressing. This means that the byte order is from the least significant byte (LSB) to the most significant byte (MSB). The Anybus will however handle ADI values transparently according to the actual network representation (indicated to the application during initialization). The application driver is responsible for byte swap if required. Use of this approach is decided because of the following reasons: Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Software Introduction 8 • The Anybus can not hold information about the data type of all ADIs due to memory limitations and start-up time demands. • The alternative to read the data type prior to every parameter write or read request would be too time consuming. See also... • “Process Data Subfield” on page 13 • “The Anybus State Machine” on page 22 • “Network Object (03h)” on page 47 • “Application Data Object (FEh)” on page 55 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Software Introduction 9 2.4 Diagnostics The Anybus CompactCom features a dedicated object for host-related diagnostics. To report a diagnostic event, the host application shall create an instance within this object. When the event has been resolved, the host simply removes the diagnostic instance again. Each event is tagged with an Event Code, which specifies the nature of the event, and a Severity Code, which specifies the severity of the event. The actual representation of this information is highly network specific. Host Application Diagnostic Object Network Event Event Diagnostics Event Application Diagnostic & Status Handling See also... • “Diagnostic Object (02h)” on page 44 2.5 Multilingual Support Where applicable, the Anybus CompactCom supports multiple languages. This mainly affects instance names and enumeration strings, and is based on the current language setting in the Anybus Object. Note that this also applies to Host Application Objects, which means that the host application should be capable of changing the language of enumeration strings etc. accordingly. When applicable, the Anybus module forwards change-of-language-requests from the network to the Application Object. It is then up to the host application to grant or reject the request, either causing the module to change its language settings or to reject the original network request. Supported languages: • English (default) • German • Spanish • Italian • French See also... • “Application Object (FFh)” on page 64 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 3 3. Host Communication Layer 3.1 General Information 3.1.1 Basic Principles On it’s lowest level, the host interface communication is based on a half-duplex protocol. Telegrams are exchanged in a ping-pong fashion, with the only exceptions being the very first telegram issued by the host application during startup, and possible re-transmissions due to transmission errors (only applicable when using the serial host interface). The host application and Anybus module share an equal responsibility of maintaining a telegram exchange rate that provides an acceptable throughput, yet does not exceed the performance capabilities of the local CPU. Host Application Anybus Module Telegram Telegram Telegram Telegram Protocol violation! The Anybus module will respond as quickly as possible based on present conditions, while the application should respond as fast as required to fulfil its own timing demands, or to fulfil the demands of the actual network, whichever is highest. The parallel- and serial interfaces share the same basic protocol, with some slight differences to cover the needs for each interface (i.e. CRC for serial transmission etc.). 3.1.2 Telegram Contents Each telegram consists of three subfields: • Handshake Registers This field controls the communication between the host and the Anybus module. See also... - “Handshake Registers” on page 11 • Message Subfield This field is used for Object Messaging, an embedded sub-protocol which carries messages between the host application and the module. This field is present in all telegrams, however its contents may or may not be relevant depending on certain bits in the handshake registers. See also... - “Object Messaging” on page 24 • Process Data Subfield This field provides a dedicated channel for fast cyclical network I/O, known as Process Data. See also... - “Process Data Subfield” on page 13 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 11 3.2 Handshake Registers 3.2.1 Control Register (Read/Write) This register controls the communication towards the Anybus module. b7 (MSB) CTRL_T b6 CTRL_M b5 CTRL_R b4 CTRL_AUX b3 - b2 - b1 - b0 (LSB) - Bit CTRL_T Description The host application shall toggle this bit when sending a new telegram. CTRL_T must be set to “1” in the initial telegram sent by the application to the module. CTRL_M If set, the message subfield in the current telegram is valid (see also “Message Fragmentation” on page 17). CTRL_R If set, the host application is ready to receive a new command (see also “Flow Control” on page 27). CTRL_AUX See “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 12 (reserved, set to zero) 3.2.2 Status Register (Read Only) This register holds the current status of the Anybus module. b7 (MSB) STAT_T b6 STAT_M b5 STAT_R b4 STAT_AUX b3 SUP b2 S2 b1 S1 b0 (LSB) S0 Bit STAT_T Description When the module issues new telegrams, this bit will be set to the same value as CTRL_T in the last telegram received from the host application. STAT_M If set, the message subfield in the current telegram is valid (see also “Message Fragmentation” on page 17). STAT_R If set, the Anybus module is ready to process incoming commands (see also “Flow Control” on page 27). STAT_AUX See “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 12 SUP Value:Meaning: 0: Module is not supervised. 1: Module is supervised by another network device These bits indicates the current state of the module (see also “The Anybus State Machine” on page 22). S[0... 2] S2 S1 S0 Anybus State 0 0 0 SETUP 0 0 1 NW_INIT 0 1 0 WAIT_PROCESS 0 1 1 IDLE 1 0 0 PROCESS_ACTIVE 1 0 1 ERROR 1 1 0 (reserved) 1 1 1 EXCEPTION Note: The Status Register shall be regarded as cleared at start-up. The first telegram issued by the host application must therefore not contain a valid message subfield since STAT_R is effectively cleared (0). Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 12 3.2.3 Supervised Bit (SUP) While the Anybus State Machine reflects the state of the cyclic data exchange, the SUP-bit indicates the overall status of the network communication, including acyclic communication. For example, on CIP, this bit indicates that the master has a connection towards the module. This connection may be an I/O connection, or an acyclic (explicit) connection. In case of the latter, the communication will be “silent” for extended periods of time, and the state machine will indicate that the network is Idle. The SUP-bit will however indicate that there still is a connection towards the module. Exactly how this functionality should be handled, the offered level of security, and how to correctly activate it is network specific and often depends on external circumstances, e.g. configuration of the network as well as other network devices. Whether use of the SUP-bit is appropriate must therefore be decided for each specific application and network. See also... • “Status Register (Read Only)” on page 11 (bit 3, ‘SUP’) IMPORTANT: It is important to recognize that this bit reflects the network state at the time of transmission of each telegram. In case a message from the network, such as a parameter data request or other command, for some reason is delayed (for example if the application has cleared the CTRL_R-bit for some time), the application may have to take alternative actions depending on the situation. 3.2.4 Auxiliary Bit (STAT_AUX, CTRL_AUX) By default, this bit is not used and shall be zero. Optionally, it is possible to specify additional functionality for this bit in the Anybus Object (Instance Attribute #15, ‘Auxiliary Bit’). At the time of writing, the following functionality has been defined: • Default Not used; STAT_AUX and CTRL_AUX shall be zero. • Changed Data Indication In this mode, the CTRL_AUX- and STAT_AUX bits indicate if the process data in the current telegram has changed compared to the previous one. See also... • “Control Register (Read/Write)” on page 11 (bit 4, ‘CTRL_AUX’) • “Status Register (Read Only)” on page 11 (bit 4, ‘STAT_AUX’) • “Process Data Subfield” on page 13 (“Changed Data Indication”, p. 14) • “Anybus Object (01h)” on page 39 (Instance Attribute #15) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 13 3.3 Process Data Subfield 3.3.1 General Information Process Data comes in two flavours; Read Process Data, and Write Process Data. • Read Process Data Read Process Data represents data received from the network, and is present (if used) in telegrams received from the Anybus module. • Write Process Data Write Process Data represents data that shall be sent to the network, and is present (if used) in telegrams sent to the Anybus module. Exactly how the Process Data is represented on the network varies, for example on PROFIBUS, it is exchanged as IO data, while on CANopen, it is exchanged through PDOs. See also... • “The Anybus State Machine” on page 22 IMPORTANT: • The Process Data subfield doesn’t exist until the module is fully initialized. This is generally not an issue when using the parallel host interface, however it is important to note that it affects the telegram length when using the serial host interface. • The Anybus module does not perform any byte swapping on this data; the host application is thus solely responsible for byte swapping if needed by the implementation. 3.3.2 Process Data Mapping The actual size and structure of the Process Data subfield is based on the Process Data map, which can be specified by the host application during startup, and in the case of certain Anybus implementations also from the network. Process Data mapping is basically a structured way of defining the cyclic I/O size on a higher level, and enables the host application to define data structures etc. by their actual data types instead of specifying anonymous blocks of binary data. See also... • “Network Data Exchange” on page 7 • “Network Object (03h)” on page 47 • “Command Details: Map_ADI_Write_Area” on page 49 • “Command Details: Map_ADI_Read_Area” on page 50 • “Application Data Object (FEh)” on page 55 • “Command Details: Remap_ADI_Write_Area” on page 61 • “Command Details: Remap_ADI_Read_Area” on page 63 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 14 3.3.3 Changed Data Indication Note: This functionality is optional and is not enabled by default. Optionally, it is possible to have a changed data indication with each telegram through the use of the Auxiliary bits (STAT_AUX and CTRL_AUX). When this functionality is enabled, these bits are independently used as changed data signals for Read- and Write Process Data respectively, as described below. • Changed Data Indication of Read Process Data The Anybus module indicates if the Read Process Data has changed as follows. - STAT_AUX is set (1) in telegrams containing Read Process Data which differs from that of the last telegram which contained Read Process Data. - STAT_AUX is cleared (0) in telegrams containing Read Process Data which equals that of the last telegram which contained Read Process Data. - The first telegram containing Read Process Data will be compared to an ‘imaginary’ previous process data buffer containing all zeroes. - STAT_AUX is always set in the first telegram containing a Read Process Data map that has been modified by Remap_ADI_Read_Area. - The host application may choose to discard the Read Process Data in telegrams where STAT_AUX is cleared (0). • Changed Data Indication of Write Process Data The host application indicates if the Write Process Data has changed as follows. - CTRL_AUX is set (1) in telegrams containing Write Process Data which differs from that of the last telegram which contained Write Process Data. - CTRL_AUX is cleared (0) in telegrams containing Write Process Data which equals that of the last telegram which contained Write Process Data. - The first telegram containing Write Process Data shall be compared to an ‘imaginary’ previous process data buffer containing all zeroes. - CTRL_AUX shall always be set in the first telegram containing a Write Process Data map that has been modified by Remap_ADI_Write_Area. - Setting CTRL_AUX (1) in telegrams where the Write Process Data is unchanged is acceptable although it may add extra load on the Anybus module. See also... • “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 12 • “Anybus Object (01h)” on page 39 (Instance Attribute #15) • “Command Details: Remap_ADI_Write_Area” on page 61 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 15 3.4 Anybus Watchdog The host application can establish whether or not the module is working properly by measuring the telegram response time. If this time exceeds a certain value, the module can be assumed to be malfunctioning. The host application can then enter a safe state, reset the module, or take similar actions. Suggested minimum timeout values: Interface Parallel Serial, 19.2kbps Serial, 57.6kbps Serial, 115.2kbps Serial, 625kbps Host Application Start timer Anybus Module Telegram Telegram Stop timer Start timer Telegram Minimum timeout value 10 ms 1050 ms 360 ms 180 ms 60 ms Note: These are only suggested minimum values that are guaranteed to be met by the Anybus module in all cases. An appropriate value for a particular application depends highly on safety demands, quality of serial communications (if applicable) etc. Anybus failure Timeout. 3.5 Application Watchdog If enabled, this feature allows the Anybus module to establish whether or not the host application is working properly by measuring its telegram response time. If this time exceeds a specified value, the Anybus module considers the host application as not working and takes action accordingly. The actions performed when a timeout occurs are network specific, however common to all Anybus CompactCom implementations is that the module shifts to the ‘EXCEPTION’-state. Host Application Anybus Module Telegram Start timer Telegram Stop timer Telegram Start timer Host application failure Note: When using the serial host interface, the watchdog timer is started when the module initiates a new transmission and stopped when the module receives a valid telegram that is not a re-transmission. Timeout. See also... • “Anybus Object (01h)” on page 39 (Instance Attribute #4, ‘Application watchdog timeout’) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 16 3.6 Serial Host Communication 3.6.1 General Information On the serial host interface, telegrams are transmitted through a common asynchronous serial interface. The baudrate is determined by certain signals on the host interface connector of the module; consult the Anybus CompactCom Hardware Design Guide for further information. Other communication settings are fixed to the following values: Data bits:8 Parity: None Stop bits:1 IMPORTANT: As is the case with most asynchronous communication devices, the actual baudrate used on the Anybus CompactCom may differ slightly from the ideal baudrate. The baudrate deviation of the Anybus module is less than ±1.5%. To ensure proper operation, the baudrate deviation in the host application must not exceed ±1.5%. 3.6.2 Serial Telegram Frame 1 byte Handshake Register Field (1st byte) • 16 bytes Message Subfield Up to 256 bytes Process Data Subfield 2 bytes CRC16 (last byte) Handshake Register Field This field contains the Control Register in telegrams sent to the Anybus module, and the Status Register in telegrams received from the Anybus module. See also... - “Handshake Registers” on page 11 • Message Subfield To maintain throughput for the Process Data, the message subfield is limited to 16 bytes when using the serial interface. Longer messages are exchanged as several smaller fragments (see “Message Fragmentation” on page 17). See also... - “Object Messaging” on page 24. • Process Data Subfield1 This field contains the Write Process Data in telegrams sent to the Anybus module, and the Read Process Data in telegrams received from the Anybus module. See also... - “Process Data Subfield” on page 13 • CRC16 This field holds a 16 bit Cyclic Redundancy Check (Motorola format, i.e. MSB first). The CRC covers the entire telegram except for the CRC itself. See also... - “CRC Calculation” on page 83. 1. Note that this field does not exist when the Anybus module is operating in the ‘SETUP’-state. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 17 3.6.3 Message Fragmentation To ensure Process Data throughput at all times, messages longer than 16 bytes are transmitted as multiple small (≤16 bytes) fragments. These fragments are then assembled by the receiving part and processed as a complete message, i.e. the receiver must wait until a complete message has been received before processing it. Note that this includes any fundamental errors that may have been detected in the first fragment (e.g. data field too large, command with error bit set (E=1) etc.). Each message must be followed by an additional “empty” fragment (i.e. a telegram with CTRL_M or STAT_M=0) to indicate to the receiver that the message has been completed. Example Fragmentation Sequence: Message Frame: Fragment #1 Header + MsgData[0...7] CTRL_M=1 Fragment #2 MsgData[8...23] CTRL_M=1 Fragment #3 MsgData[24...39] CTRL_M=1 Fragment #4 MsgData[40...55] CTRL_M=1 Fragment #5 MsgData[56...71] CTRL_M=1 Fragment #6 MsgData[72...79] CTRL_M=1 Fragment #7 (no message) CTRL_M=0 MsgData[0...79] Header (8 bytes) A message with 80 bytes of message data is sent to the module as 6 smaller fragments. An additional “empty” fragment ends the message. A fragmented message may be aborted at any time by issuing an “empty” fragment (i.e. a telegram with CTRL_M or STAT_M=0), causing a fragmentation error at the receiving end. Example Fragmentation Sequence: Message Frame: Fragment #1 Header + MsgData[0...7] STAT_M=1 Fragment #2 MsgData[8...23] STAT_M=1 Fragment #3 MsgData[24...39] STAT_M=1 Fragment #4 MsgData[40...55] STAT_M=1 Fragment #5 (no message) STAT_M=0 MsgData[0...71] Header (8 bytes) A message with 72 bytes of message data is sent by the module as several smaller fragments. The message is aborted prematurely using an “empty” fragment. Smaller messages (i.e. ≤16 bytes) are sent without fragmentation, however an additional “empty” fragment must still be sent to signal to the receiver that a full message has been completed. Example Message Frame: Fragmentation Sequence: Fragment #1 Header + MsgData[0...7] STAT_M=1 Fragment #2 (no message) STAT_M=0 MsgData[0...7] Header (8 bytes) A small message (16 bytes) is sent to the host application. An additional “empty” fragment ends the message. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 18 3.6.4 Transmission Errors Transmission errors are handled as follows: • A telegram is ignored in the event of a reception error (i.e. a CRC mismatch). • Any transmission error shall, after a timeout, result in a re-transmission of the last telegram by the host application (suggested re-transmission timeout values for different baud rates are specified in the table below). • The module detects re-transmissions by monitoring CTRL_T. To make this concept successful, the host application must fulfil the following requirements: • The telegram transmission time must be less than TSEND (See table) • The re-transmission timeout must not be less than TTIMEOUT (See table) Baudrate TSEND TTIMEOUT 19.2 kbps 57.6 kbps 115.2 kbps 625 kbps 175 ms 60 ms 30 ms 6 ms 350 ms 120 ms 60 ms 20 ms Scenario 1: Anybus Detects a CRC Error In this example, the Anybus module encounters a CRC-mismatch. The erroneous telegram is simply ignored, causing a timeout in the host application, eventually forcing it to re-transmit the original telegram. Host Application Start timer Anybus Module Telegram (CTR L_T=0) TSEND _T=0) Telegram (STAT Expected CTRL_T=0 (OK, send next) _T=1) Expected CTRL_T=1 (OK, send next) Stop timer Start timer Telegram (CTR L_T=1) Telegram (STAT Stop timer Start timer Telegram (CTR L_T=0) Error CRC error detected (Telegram ignored) TTIMEOUT Timeout (Retransmit) Start timer Telegram (CTR L_T=0, retransm ission) _T=0) Telegram (STAT Expected CTRL_T=0 (OK, send next) Stop timer Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 19 Scenario 2: Error detected by Host In this example, the host encounters a CRC-mismatch. Just like the Anybus module, it must ignore the erroneous telegram, eventually causing a timeout, which shall in turn generate a re-transmission. Host Application Start timer Anybus Module Telegram (CTR L_T=1) TTIMEOUT _T=1) Expected CTRL_T=1 (OK, send next) ission) Expected CTRL_T=0 (Not OK, retransmit) Telegram (STAT Error CRC error detected (Telegram ignored) Timeout (Retransmit) Start timer Telegram (CTR L_T=1, retransm ission) _T=1, retransm Telegram (STAT Stop timer IMPORTANT: Note that it is the timeout itself that shall trigger the re-transmission rather than the actual CRCerror; it is not allowed to make a re-transmission directly after detecting a CRC-error. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 20 3.7 Parallel Host Communication 3.7.1 General Information When using the parallel host interface, telegrams are exchanged via a shared memory area; the telegram subfields are simply accessed via pre-defined memory locations (see memory map below). Telegram transmission is triggered via the Control Register, and the reception of a new telegram is indicated in the Status Register. This means that the Process Data and Message sub-fields must be written prior to accessing the Control Register. While waiting for reception of a telegram, any access to the parallel interface other than polling of the Status Register must be avoided. See also... • “Handshake Registers” on page 11 IMPORTANT: Internally, an interrupt is triggered in the module each time the Control Register is modified. It is therefore important not to use bit handling or other read-modify-write instructions directly on this register, since the module may interpret this as multiple accesses. All bit handling etc. must instead be performed in a temporary register, and written back. 3.7.2 Memory Map The address offset specified below is relative to the base address of the module., i.e. from the beginning of the area in host application memory space where the parallel interface has been implemented. Address Offset: 0000h... 37FFh Area: (reserved) Access: Notes: - (reserved for future use) 3800h... 38FFh Process Data Write Area Write Only See “Process Data Subfield” on page 13 3900h... 39FFh Process Data Read Area Read Only See “Process Data Subfield” on page 13 3A00h... 3AFFh (reserved) 3B00h... 3C06h Message Write Area 3C07h... 3CFFh (reserved) 3D00h... 3E06h Message Read Area Write Only See “Object Messaging” on page 24 Read Only See “Object Messaging” on page 24 3E07h... 3FFDh (reserved) - 3FFEh Control Register Read/Write 3FFFh Status Register Read Only See “Control Register (Read/Write)” on page 11 See “Status Register (Read Only)” on page 11 IMPORTANT: C-programmers are reminded to declare the entire shared memory area as volatile. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Communication Layer 21 3.7.3 Parallel Telegram Handling On the parallel interface, transmission and reception is managed through the Handshake Registers. See also... • “Handshake Registers” on page 11 Telegram Transmission To transmit a telegram, perform the following steps: 1. If applicable, write the Write Process Data to the Process Data Write Area (3800h...38FFh) 2. If applicable, write the message to the Message Write Area (3B00h...3C06h) 3. Update the Control Register to trigger the transmission. See also... • “Control Register (Read/Write)” on page 11 Telegram Reception Telegram reception is signalled by the STAT_T-bit in the Status Register. The host application can either poll the Status Register cyclically to detect new telegrams, or rely on interrupt operation. • Interrupt Operation (Highly Recommended) If implemented, an interrupt is generated each time the module issues a new telegram. Generally, it is strongly recommended to use this feature as it can significantly reduce overhead compared to polling the Status Register cyclically. • Polled Operation The host application must poll the Status Register cyclically and study the STAT_T-bit; when the value of this bit equals the value of the CTRL_T-bit, the module has issued a new telegram. IMPORTANT: To ensure valid results when polling the Status Register, it is required to use a read-until-twoconsecutive-readings-agree procedure. See also... • “Status Register (Read Only)” on page 11 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 4 4. The Anybus State Machine 4.1 General Information A fundamental part of the Anybus CompactCom is the Anybus State Machine. At any given time, the state machine reflects the status of the module and the network. The state machine shall be regarded as a Moore machine; i.e. the host application is not required to keep track of all state transitions, however it is expected to perform certain tasks in each state. (Power up) SETUP (00h) EXCEPTION (07h) NW_INIT (01h) (From all states) WAIT_PROCESS (02h) PROCESS_ACTIVE (04h) ERROR (05h) IDLE (03h) See also... • “State-Dependent Actions” on page 23 “Status Register (Read Only)” on page 11 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 The Anybus State Machine 23 4.2 State-Dependent Actions The expected actions for each state are listed below. State SETUP NW_INIT Description Anybus Setup in progress. The Anybus module is currently performing network-related initialisation tasks. Telegrams now contains Process Data (if such data is mapped), however the network Process Data channel is not yet active. WAIT_PROCESS The network Process Data channel is temporarily inactive. IDLE The network interface is idle. The exact interpretation of this state is network specific. Depending on the network type, the Read Process Data may be either updated or static (unchanged). PROCESS_ACTIVE The network Process Data channel is active and error free. ERROR There is at least one serious network error. EXCEPTION Expected Actions See “Anybus Setup (‘SETUP’-State)” on page 36. See “Network Initialization (‘NW_INIT’-State)” on page 37. The host application shall regard the Read Process Data as not valid. The host application may act upon the Read Process Data, or go to an idle state. Perform normal data handling. The Read Process Data shall be regarded as not valid. Optionally, the host application may perform network specific actions. Write Process Data could still be forwarded to the master, so the application must keep this data updated. The module has ceased all network participa- Correct the error if possible (details about the error tion due to a host application-related error. can be read from the Anybus Object, see “Anybus Object (01h)” on page 39). This state is unrecoverable, i.e. the module must be restarted in order to be able to When done, reset the Anybus module. exchange network data. See also... • “General Information” on page 22 • “Status Register (Read Only)” on page 11 IMPORTANT: The host application must keep the Write Process Data updated in ‘NW_INIT’ (initial data), ‘WAIT_PROCESS’, ‘IDLE’, ‘ERROR’ and ‘PROCESS_ACTIVE’ since this data is buffered by the Anybus module, and may be sent to the network after a state shift. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 5 5. Object Messaging 5.1 General Information 5.1.1 Basic Principles Object Messaging involves two types of messages; Commands and Responses. On the message level, there is no master-slave relationship between the host application and the Anybus module; both parts may issue Commands, and are required to respond. Commands and Responses are always associated with an Instance within the Anybus Object Model. This can either be the Object itself (addressed through Instance #0), or an Instance within it. Commands can be issued at any time (provided Host Application that the receiving end is ready to accept new comCommand 1 mands), while responses must only be sent as a reaction to a previously received command. Unexpected or malformed responses must always be discarded. Commands and responses are treated asynchronously, i.e. new commands may be issued before a response has been returned on the previous one. This also means that commands are not guaranteed to be executed in order of arrival, and that responses may return in arbitrary order (see figure). When necessary, the host application must wait for the response of any command to which the action or result may affect successive commands. Anybus Module Response 1 Command 2 Command 3 Response 3 Response 2 5.1.2 Source ID To keep track of which response that belongs to which command, each message is tagged with a Source ID. When issuing commands, the host application may choose Source IDs arbitrarily, however when responding to commands issued by the Anybus module, the Source ID in the response must be copied from the original command. See also... • “Message Layout” on page 25 5.1.3 Error Handling When a command for some reason cannot be processed, the receiver is still obliged to provide a response. In such case, an error shall be flagged in the header of the response message, together with an appropriate error code in the message data field. The command initiator must then examine the response to see whether it is a successful response to the command or an error message. See also... • “Message Layout” on page 25 • “Error Codes” on page 29 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 25 5.2 Message Layout An object message consists of an 8 byte header followed by message related data. Offset 0 1 2 3 4 5 6 7 8...n Contents Description b7 b6 b5 b4 b3 b2 b1 b0 Source ID See “Source ID” on page 24 Object Specifies a source/destination within the Anybus Object model. Instance (lsb) Instance (msb) Value:Meaning: E 0: Message is either a Command, or a successful Response 1: Message is an Error Response C Value:Meaning: 0: Message is a Response 1: Message is a Command Command Code See “Command Specification” on page 28 Message Data Size CmdExt[0] CmdExt[1] MsgData[0...n] Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Size of the MsgData[] field in bytes (up to 255 bytes). Command-specific extension. See “Command Specification” on page 28. Message data field. Doc.Id. HMSI-168-97 Object Messaging 26 5.3 Data Format 5.3.1 Available Data Types The Anybus CompactCom uses the following data types as standard. Additional network specific data types are described in each separate network interface appendix (when applicable). Available on All Networksa Yes Yes Yes Yes Valid for Process Datab Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes -2 No Yes 0... +(264-1) No Yes Floating point (IEC 60559) ±1.17549435E-38... ±3.40282347E+38 No Yes # Type Bits Description Range 0 1 2 3 BOOL SINT8 SINT16 SINT32 8 8 16 32 Boolean Signed 8 bit integer Signed 16 bit integer Signed 32 bit integer 0 = False, !0 = True -128... +127 -32768...+32767 4 5 6 UINT8 UINT16 UINT32 8 16 32 Unsigned 8 bit integer Unsigned 16 bit integer Unsigned 32 bit integer 7 CHAR 8 8 ENUM 8 0... +(232-1) Character (ISO 8859-1)cde 0... +255 0... +255 Enumerationf 16 SINT64 64 Signed 64 bit integer 17 UINT64 64 Unsigned 64 bit integer 18 FLOAT 32 -231... +(231-1) 0... +255 0... +65535 63... +(263-1) a. This column specifies if the data type can be represented on all networks. b. This column specifies if the data type can be used for Process Data. c. Arrays of type CHAR will be translated to the native string type of the network. d. ‘Set_Indexed_Attribute’ and ‘Get_Indexed_Attribute’ cannot be used for this data type. e. This data type cannot be used for Process Data. f. Data of type ENUM are enumerations, limited to a consecutive range of values starting at zero. 5.3.2 Handling of Array of Char (Strings) Note: This section is mainly applicable when using arrays of CHAR in ADIs. Arrays of type CHAR will be translated to the native string type (when applicable). The maximum string length, and the buffer space required to store it, is defined by the data type and the number of elements. All elements of an array of CHAR are significant; the Anybus module does not expect any termination characters when reading, nor does it generate any when writing. The actual length of the string is defined in the payload size given in the ‘Get_Attribute’- and ‘Set_Attribute’-commands. Generally, it is recommended to keep the ‘number of elements’, ‘data type’, and the message payload length, as consistent as possible. There is no guarantee that the Anybus module will check consistency between the payload length and the actual buffer space. See also... • “Application Data Object (FEh)” on page 55 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 27 5.4 Flow Control In some cases, the host application or the Anybus module may be busy or for some other reason temporarily unable to process new commands. To deal with such situations, CTRL_R and STAT_R are used to give the receiving part the possibility to signal whether it is ready to handle new commands or not. These following rules apply: • Responses are not blocked by these bits, i.e. when issuing a command, the host application must always have enough free resources to process a response to that command. • CTRL_R and STAT_R are only checked between messages; i.e. when using the serial host interface, it is not possible to pause or cancel an ongoing message fragmentation using these bits. • If the host application issues a command while STAT_R is cleared (0), that command will be discarded by the module, in turn causing the DC error counter to be incremented. Host Application Anybus Module CTRL_R = 1 STAT_R = 1 CTRL_R = 1 STAT_R = 1 Send Command #1 Process Command #1 Pending Command #2 CTRL_R = 0 STAT_R = 1 CTRL_R = 0 Done! STAT_R = 1 Respond to CTRL_R = 1 Command #1 STAT_R = 1 Send Command #2 Respond to CTRL_R = 1 Command #2 See also... • “Control Register (Read/Write)” on page 11 • “Status Register (Read Only)” on page 11 • “Anybus Object (01h)” on page 39 (Instance Attribute #8, ‘Error counters’) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 28 5.5 Command Specification 5.5.1 General Information This chapter covers global commands, i.e. commands which have the same command code regardless of which object that is being accessed. Some objects have special requirements, which are handled through object-specific commands. In such cases, unlike global commands, the same command code may have different meaning depending on context (i.e. which object that is being accessed). Object-specific commands are described separately for each object (when applicable). See also... • “Anybus Module Objects” on page 38 • “Host Application Objects” on page 53 Regarding generic command descriptions it should be noted that while a command has a defined generic description and structure, the actual effect of it may differ greatly depending on the context. For example: • Application issues Reset → Network Configuration Object = resets network settings • Network Reset → Anybus issues Reset → Application Object = Anybus shifts to EXCEPTION and awaits a hardware reset IMPORTANT: Fields marked as ‘reserved’ must be treated with caution. Reserved fields in messages sent to the Anybus module must be set to 0 (zero), since they may have a defined use in future Anybus revisions. In messages received from the Anybus module, reserved fields shall simply be ignored. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 29 5.5.2 Command Codes The following commands are global, i.e. the same command code is used regardless of which object that is being accessed. Command Code 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h... 0Fh 10h... 30h 31h... 3Eh 3Fh Command Name (reserved) Get_Attribute Set_Attribute Create Delete Reset Get_Enum_String Get_Indexed_Attribute Set_Indexed_Attribute (reserved) (reserved for object specific-commands) (reserved) (reserved for object specific-commands) Page 30 30 31 31 32 32 33 33 - 5.5.3 Error Codes If a command for some reason cannot be executed, the first byte in message data field (MsgData[ ]) of the response is used to supply details about problem to the command initiator. Additional object specific error information may also be added in the message data section. Value 00h 01h 02h 03h 04h 05h 06h Error (reserved) Meaning - Invalid message format Unsupported object Unsupported instance Unsupported command Invalid CmdExt[0] 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h 11h... FEh FFh Invalid CmdExt[1] Attribute not Set-able Attribute not Get-able Too Much Data Not Enough Data Out of range Invalid state Out of resources Segmentation failure Segmentation buffer overflow (reserved) Object Specific Error Command and error bit set Object not registered The target instance does not exist The target object does not support the specified command Invalid value of CmdExt[0] or invalid combination of CmdExt[0] and CmdExt[1} Invalid setting in CmdExt[1] The requested attribute is not Set-able The requested attribute is not Get-able Too much data in message data field Not enough data in message data field A specified value is out of range The command is not supported in the current state The target object cannot execute the command due to limited resources Invalid handling of the segmentation protocol Too much data received The object returned extended error information. Additional details may or may not be included in the message data field (MsgData[0...n]) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 30 5.5.4 Get_Attribute Details Command Code: 01h Valid for: (depends on context) Description This command retrieves the value of an attribute. • Command Details CmdExt[0] CmdExt[1] • Attribute number (reserved) Response Details MsgData[0...n] Attribute Value 5.5.5 Set_Attribute Details Command Code: 02h Valid for: (depends on context) Description This command assigns a value to an attribute. • Command Details CmdExt[0] CmdExt[1] MsgData[0...n] • Attribute number (reserved) Attribute Value Response Details (No data) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 31 5.5.6 Create Details Command Code: 03h Valid for: Object Instance (Instance #0) Description This command creates a new instance within the object. If successful, the data portion of the response contains the number of the newly created instance. • Command Details (Object specific) • Response Details MsgData[0] MsgData[1] The number of the created Instance (low byte) The number of the created Instance (high byte) 5.5.7 Delete Details Command Code: 04h Valid for: Object Instance (Instance #0) Description This command deletes a previously created instance (see above). If successful, all resources occupied by the specified instance will be released. • Command Details CmdExt[0] CmdExt[1] • Instance number to delete (low byte) Instance number to delete (high byte) Response Details (Success) (No data) • Response Details (Error) Invalid CmdExt[0] The specified instance does not exist. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 32 5.5.8 Reset Details Command Code: 05h Valid for: (depends on context) Description This command performs a reset command on an object. • Command Details CmdExt[0] CmdExt[1] • (reserved) 00h = Power-on reset (actual power-on or simulated) 01h = Factory default reset 02h = Power-on + Factory default reset Response Details (No data) 5.5.9 Get_Enum_String Details Command Code: 06h Valid for: (depends on context) Description This command retrieves attributes which are of enumeration type (ENUM). The returned value is the literal string associated with the specified enumeration value. • Command Details CmdExt[0] CmdExt[1] • Response Details (Success) MsgData[0...n] • The number of the attribute The enumeration value The enumeration string Response Details (Error) Invalid CmdExt[1] The enumeration value is out of range Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Object Messaging 33 5.5.10 Get_Indexed_Attribute Details Command Code: 07h Valid for: (depends on context) Description This command retrieves the value of a single element of an attribute which consists of multiple elements (i.e. an array). Note that this command cannot be used to access attributes of type CHAR. • Command Details CmdExt[0] CmdExt[1] • The number of the attribute Index (first element has index 0) Response Details (Success) MsgData[0...n] • Value Response Details (Error) Invalid CmdExt[1] Index is out of range 5.5.11 Set_Indexed_Attribute Details Command Code: 08h Valid for: (depends on context) Description This command assigns a value to a single element of an attribute which consists of multiple elements (i.e. an array). Note that this command cannot be used to access attributes of type CHAR. • Command Details CmdExt[0] CmdExt[1] MsgData[0...n] • The number of the attribute Index (first element has index 0) Value to set Response Details (Success) (No data) • Response Details (Error) Invalid CmdExt[1] Index is out of range Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 6 6. Initialization and Startup 6.1 General Information Before network participation, the following steps must be completed: 1. Initial Handshake The purpose of the initial handshake is to make sure that both parts (the host application and the Anybus module) are ready to communicate. When done, the module will enter the ‘SETUP’state. For more information, see “Initial Handshake” on page 35. 2. Anybus Setup This step determines how the module shall operate. When done, the module will enter the ‘NW_INIT’-state. For more information, see “Anybus Setup (‘SETUP’-State)” on page 36. 3. Network Initialisation At this stage, the module will attempt to read and evaluate information from the host application. When done, the module will enter the ‘WAIT_PROCESS’-state. For more information, see “Network Initialization (‘NW_INIT’-State)” on page 37. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Initialization and Startup 35 6.2 Initial Handshake The procedure is slightly different depending on which type of host interface that is used. • Parallel Host Interface The parallel host interface has two alternatives to handle the initial handshake: 1. The host application shall wait 1.5 s after reset, followed by reading the Status Register. 2. (Fast startup) When an interrupt arrives the host application immediately reads the Status Register and then enters the ‘SETUP’-state. Release Reset 1.5 s or time to interrupt detected Read Status Register Wait • (Anybus enters ‘SETUP’-state) Serial Host Interface The host application must wait at least 1.5s after reset before it sends its first telegram. Release Reset Min. 1.5s Wait... Send 1st Telegram (Anybus enters ‘SETUP’-state) Note: The Status Register shall be regarded as cleared at startup; this means that the first telegram must not contain any message data since the STAT_T-bit is considered to be set to 0 (zero). Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Initialization and Startup 36 6.3 Anybus Setup (‘SETUP’-State) This stage involves four distinctive steps: 1. Gather information about the Anybus Module (Optional) The host application may retrieve the network type, as well as other properties that may be relevant when configuring the module, from the Anybus Object (01h). This information may also be used to select different implementations based on e.g. the module type value. 2. Network Configuration (Optional) At this stage, the host application should update all instances in the Network Configuration Object of which the value originates from physical switches (i.e. node address, baud rate etc.). Settings which originate from “soft” input devices such as a keypad and display should not be updated at this point. 3. Process Data Mapping (Optional1,2) The host application may optionally map ADIs to Process Data. 4. Finalize the Setup The setup procedure is finalized by setting the ‘Setup Complete’-attribute in the Anybus Object (01h) to TRUE. If successful, the module now shifts to the ‘NW_INIT’-state (below), or in case of failure, to the ‘EXCEPTION’-state. In case of the latter, further information can then be read from the ‘Exception’-attribute in the Anybus Object (01h). See also... • “Network Data Exchange” on page 7 • “The Anybus State Machine” on page 22 • “Anybus Object (01h)” on page 39 • “Network Configuration Object (04h)” on page 51 1. This step is optional, but may be required by some networking systems and/or Anybus implementations. 2. Certain Anybus implementations (such as the Anybus CompactCom Drive Profile range of products) may attempt to alter the Process Data map during runtime. For more information, see “Application Data Object (FEh)” on page 55. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Initialization and Startup 37 6.4 Network Initialization (‘NW_INIT’-State) At this stage, the Anybus module will attempt to read and evaluate information from the host application. The host application is required to respond to incoming requests to Host Application Objects. If the requested object or attribute is not implemented in the host application, simply respond with an error message. The module will in that case use it’s own default value for the requested attribute. The host application is free to update any instances in the Network Configuration Object, including those that do not originate from physical switches. If a serious error is encountered (i.e. any error which prevents the module from proceeding) in this state, the module will shift to state ‘EXCEPTION’. Further information can then be read from the ‘Exception’-attribute in the Anybus Object (01h). When done, the module enters the ‘WAIT_PROCESS’-state. IMPORTANT: The transition to this state is critical, especially if using the serial host interface, since telegrams from this point may (depending on the setup) contain Process Data. It is important to keep Write Process Data updated in this state since this data is buffered by the module and may be sent to the network on the next state transition. See also... • “The Anybus State Machine” on page 22 • “Network Configuration Object (04h)” on page 51 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 7 7. Anybus Module Objects 7.1 General Information The objects in this chapter are implemented as standard in all Anybus CompactCom implementations. Their functionality is categorized to indicate when and how to use the objects. See also... • “Data Format” on page 26 • “Error Codes” on page 29 • “Categorization of Functionality” on page 69 7.2 Object Revisions The purpose of the Object Revision attribute is to make it possible for the host application to determine if the revision of the object in the Anybus module is compatible with the software implementation in the host application, and/or to make it possible to choose different implementations based on the object revision. As a general rule, the object revision is updated when the object is changed in such a way that the change may cause compatibility issues in the host application software implementation. Minor changes, such as when an attribute or command has been added, are normally not cause for a revision change. IMPORTANT: The definition of the Object Revision attribute has changed during early development. This means that Object Revisions in early Anybus CompactCom implementations has been incremented also even for minor changes. When applicable, a note will be added to each network interface appendix stating from which firmware revision the present definition is used. In case of questions, contact the HMS technical support services. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 39 7.3 Anybus Object (01h) Category Basic Object Description This object assembles data about the Anybus module itself. The data in question does not as such represent the industrial network the module is adapted to, but describes data inherent to the module. This data is available for use in the application. The values may differ, depending on industrial network, and are in that case described in the respective appendices. Most attributes in this object have access type “get” where data can be fetched using the command Get_Attribute. The only attribute that is mandatory to set is “Setup complete” (instance #1, attribute #5), which is used by the application to notify the module that it has finished the setup. If the configuration is not accepted, the module will shift to the EXCEPTION state, and information can be read from instance #1, attribute #6 (“Exception Code”). Supported Commands Object: Get_Attribute (01h) Instance: Get_Attribute (01h) Set_Attribute (02h) Get_Enum_String (06h) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 40 Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision Number of instances Highest instance no. Access Get Get Get Get Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Anybus’ 04h 0001h 0001h Instance Attributes (Instance #1) # Name 1 Module type Access Get Category Type UINT16 Appl. spec. 2 Firmware version Get - 3 Serial number 4 Application watchdog timeout Get Get/Set Extended a struct of: UINT8 Major UINT8 Minor UINT8 Build UINT32 UINT16 Description Value:Meaning: 0401h: Standard Anybus CompactCom 0402h: Anybus CompactCom Drive Profile (other): (reserved for future products) Firmware version. Note that this value shall generally not be used to determine if a particular functionality is available or not. Please use the ‘Revision’attribute of each individual object for this purpose. Unique serial number Application watchdog configuration: Value:Meaning: 0: Disabled (default) (other): Timeout value (ms) If enabled, the watchdog timeout time is active immediately, regardless of the state of the application. The internal timer is reloaded every time it is restarted, so the value of this attribute can be changed durign runtime. 5 Setup complete Get/Set Basic 6 Exception Code 7 FATAL event Get Get/Set Extended Dev. 8 Error counters Get Dev.c b Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 BOOL ENUM struct of: (HMS Specific) struct of: UINT16 DC UINT16 DR UINT16 SE UINT16 FE See also... - “Application Watchdog”, p. 15 This attribute shall be set to TRUE when the Anybus Setup stage has been completed. If the configuration is accepted, the Anybus module shifts to the ‘NW_INIT’-state. If not, i.e. if a serious error is detected in the configuration, the module will shift to the ‘EXCEPTION’-state. In such case further information can be read from the ‘Exception Code’-attribute (below) See also... - “Anybus Setup (‘SETUP’-State)” on page 36 See “Exception Codes”, p. 42 The latest FATAL event (if any) is logged to this instance. Used for evaluation by HMS support. Error counters (stops counting at FFFFh): DC:Discarded commands (received with R = 0) DR:Discarded (unexpected) responses SE:Serial reception errors FE:Fragmentation errors Doc.Id. HMSI-168-97 Anybus Module Objects 41 # Name 9 Language 10 Provider ID Access Get/Set Get Category Extended Type ENUM - UINT16 11 Provider specific info Get/Set - UINT16 12 LED colors Get Appl. spec.a struct of: UINT8 LED1A UINT8 LED1B UINT8 LED2A UINT8 LED2B 13 LED status Get Appl. spec.a UINT8 14 (reserved) 15 Auxiliary Bit Get/Set - 16 GPIO configuration Get/Setd Appl. spec.a UINT16 Appl. spec. UINT8 a Description Current language: Value:Enumeration String: 00h: ‘English’ (default) 01h: ‘Deutsch’ 02h: ‘Español’ 03h: ‘Italiano’ 04h: ‘Français’ See also... - “Application Object (FFh)” on page 64 - “Command Details: Change_Language_Request” on page 68 Pre-programmed and stored permanently in FLASH by HMS during production (contact HMS for further information). Value:Meaning: 0001h: HMS Networks FFFFh: (reserved) other: Provider specific. The information stored in this attribute is providerspecific, i.e. it has no predefined meaning and is not evaluated nor used by the Anybus module. Any value written to this attribute will be stored in non-volatile memory. Default value is 0000h. This attributes specifies the colors of the network status LEDs. Value:Meaning: 00h: None (not used) 01h: Green 02h: Red 03h: Yellow 04h: Orange 05h: Blue 06h: White Bit field holding the current state of the network status LEDs as follows: Bit:Contents: b0: LED1A status (0=OFF, 1=ON) b1: LED1B status (0=OFF, 1=ON) b2: LED2A status (0=OFF, 1=ON) b3: LED2B status (0=OFF, 1=ON) b4... 7: (reserved) See also... - “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 12 - “Auxiliary Bit” on page 42 This attribute makes it possible to use the host interface GPIO pins for special purposes. See “GPIO Configuration” on page 43 Default: 0000h a. The category of this attribute depends on how it is used in the application. b. The contents of this attribute is only used as input to HMS support during application development. c. The contents of this attribute is only used during application development d. Set access is only valid during setup. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 42 Exception Codes When in the EXCEPTION state, this attribute provides additional information about the condition. # 00h 01h Enumeration String ‘No exception’ ‘Application timeout’ Description The host application has not responded within the specified watchdog timeout period 02h ‘Invalid device address’ The selected device address is not valid for the actual network 03h ‘Invalid communication settings’ The selected communication settings are not valid for the actual network 04h ‘Major unrecoverable The host application has reported a major unrecoverable event to the app event’ Diagnostic object 05h ‘Wait for reset’ The module is waiting for the host application to execute a reset 06h ‘Invalid process data config’ The Process Data configuration is invalid 07h ‘Invalid application response’ The host application has provided an invalid response to a command 08h ‘Non-volatile memory checksum error’ At least one of the parameters stored in non-volatile memory has been restored to its default value due to a checksum error (other) (reserved) - See also... • “The Anybus State Machine” on page 22 Auxiliary Bit This attribute defines the function for the CTRL_AUX and STAT_AUX bits. # 00h 01h Function None (default) Changed Data indication (other) (reserved) CTRL_AUX No function, set to 0 (zero). 0: Write Process Data unchanged 1: Write Process Data updated - STAT_AUX No function, always 0 (zero). 0: Read Process Data unchanged 1: Read Process Data updated - See also... • “Handshake Registers”, p. 11 • “Auxiliary Bit (STAT_AUX, CTRL_AUX)”, p. 12 Object Specific Error Codes The following object-specific error codes may be returned by the module as a response to setting the ‘Setup complete’-attribute. # 01h 02h 03h Error Invalid process data configuration Invalid device address Invalid communication settings Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Description The Process Data configuration is invalid The selected device address is not valid for the actual network The selected communication settings are not valid for the actual network Doc.Id. HMSI-168-97 Anybus Module Objects 43 GPIO Configuration This attribute makes it possible to use the GPIO (General Purpose IO) pins for other purposes than general IO. The attribute will have to be set during setup for any changes to take effect. The functionality is not introduced in all modules in the Anybus CompactCom 30product family, please consult the network appendices for more information. # 0000h Function Standard 0001h Extended LED functionality (other) (reserved) Description GIP[0..1] are used as general input pins. GOP[0..1] are used as general output pins.a GIP[0..1] are used as network specific, active low LED outputs associated with the left, or single port. GOP[0..1] are used as network specific, active low LED outputs associated with the right port on dual port modules. a. Please note that the general output pins are defined as active low. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 44 7.4 Diagnostic Object (02h) Category Specific to each industrial network, see appendices. Object Description This object provides a standardized way of reporting diagnostic events to the network. Exactly how this is represented on the network differs, however common to all implementations is that the module enters the ‘EXCEPTION’-state on case of a Major Unrecoverable event. When the module has been started and initialized, no instances exist in this module. When a diagnostic event, e.g. a blown fuse, occurs in the application, the application creates an instance with information on severity and kind of event. The information in this instance remains available for the application, until the application deletes the instance. The event code in the instance is processed by the module, to transfer correct network-specific information about the event to the network used. Supported Commands Object: Get Attribute (01h) Create (03h) (See “Command Details: Create” on page 46) Delete (04) (See “Command Details: Delete” on page 46) Instance: Get Attribute (01h) Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision Number of instances Highest instance no. 11 Max no. of instances Access Get Get Get Get Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Diagnostic’ 01h (depends on number of created diagnostic events) (network specific) Get UINT16 Max. no. of instances that can be created (network specific)a a. Of the maximum number of instances there is always one instance reserved for one of severity level ‘Major, unrecoverable’ to force the module into the ‘EXCEPTION’-state. For information regarding allowed no. of instances for a specific network, see ’Network Comparison Chart’ page 70. Instance Attribute (Instance #1) # 1 2 3 Name Severity Event Code NW specific extension Access Get Get Get Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Type UINT8 UINT8 Array of UINT8 Description See “Severity Levels” on page 45 See “Event Codes” on page 45 Network specific event information (optional) Doc.Id. HMSI-168-97 Anybus Module Objects 45 Severity Levels # 00h 10h 20h 30h (other) Severity Minor, recoverable Minor, unrecoverable Major, recoverable Major, unrecoverable - Comment Unrecoverable events cannot be deleted. Causes a state-shift to EXCEPTION. (reserved for future use) Event Codes # 10h 20h 21h 22h 23h 30h 31h 32h 33h 40h 41h 42h 50h 60h 61h 62h 63h 70h 80h 81h 82h 90h F0h FFh Meaning Generic Error Current Current, device input side Current, inside the device Current, device output side Voltage Mains Voltage Voltage inside the device Output Voltage Temperature Ambient Temperature Device Temperature Device Hardware Device Software Internal Software User Software Data Set Additional Modules Monitoring Communication Protocol Error External Error Additional Functions NW specific Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Comment Definition is network-specific; consult separate network interface appendix for further information. Doc.Id. HMSI-168-97 Anybus Module Objects 46 Command Details: Create Details Command Code: 03h Valid for: Object Instance Description Creates a new instance, in this case representing a new diagnostic event in the host application. • Command Details Field CmdExt[0] CmdExt[1] MsgData[0-n] • Contents Severity Event Code, see previous page Network specific extension (optional, definition is network specific) Response Details (Success) Field MsgData [0...1] Contents The number of the created instance Command Details: Delete Details Command Code: 04h Valid for: Object Instance Description Deletes an existing instance, i.e. a previously created diagnostic event. Note: Instances representing unrecoverable events cannot be deleted. • Command Details Field CmdExt[0] CmdExt[1] • Contents The number of the instance to delete (low byte) The number of the instance to delete (high byte) Response Details (Error) Error Object Specific Error Contents MsgData[0] = FFh MsgData[1] = 01h Comment Error code (Not removed). The event could not be removed, either because the event itself is unrecoverable, or due to a network specific reason. See also: • “Error Codes” on page 29 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 47 7.5 Network Object (03h) Category Basic Object Description This object holds general information about the network (i.e. network type, data format etc.). It is also used when mapping ADIs as Process Data from the host application side. See also... • “Application Data Object (FEh)” on page 55 • “Application Object (FFh)” on page 64 Supported Commands Object: Get_Attribute (01h) Instance: Get_Attribute (01h) Set_Attribute (02h) Get_Enum_String (06h) Map_ADI_Write_Area (10h) Map_ADI_Read_Area (11h) Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision Number of instances Highest instance no. Access Get Get Get Get Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Network’ 02h (Module type dependent) (Module type dependent) Doc.Id. HMSI-168-97 Anybus Module Objects 48 Instance Attributes (Instance #1) # 1 2 3 Name Network type Network type string Data format Access Get Get Get 4 Parameter data sup- Get port 5 Write Process Data Get size 6 Read Process Data Get size 7 Exception Information Get Category Extended Basic Type Description UINT16 (See separate network interface appendix) Array of CHAR ENUM Network data format: Value:Enumeration String: 00h: ‘LSB First’ 01h: ‘MSB First’ This attribute indicates if the network supports acyclic Extendeda BOOL data services. Value:Meaning: True: Network supports acyclic data access False: No support for acyclic data UINT16 The current write Process Data size (in bytes) Updated on every successful Map_ADI_Write_Area or Remap_ADI_Write_Area UINT16 The current read Process Data size (in bytes) Updated on every successful Map_ADI_Read_Area or Remap_ADI_Read_Area UINT8 Additional network specific information may be presented here if the module has entered the EXCEPTION state (see separate network interface appendix) a. Can be used for deciding what ADIs to map to Process Data Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 49 Command Details: Map_ADI_Write_Area Details Command Code: 10h Valid for: Instance Description This command maps an ADI as Write Process Data. If successful, the response data contains the offset of the mapped ADI from the start of the Write Process Data image. Note 1: It is strongly recommended not to map an ADI more than once (i.e. map it multiple times to the Read- or Write Process Data, or map it to both the Read- and Write Process Data) since this is not accepted by some networks. Note 2: It is not possible to map only part of an ADI, i.e. all elements of an ADI must always be mapped. Note 3: Certain Anybus implementations allow the network to remap the Process Data during runtime. For more information, see “Application Data Object (FEh)” on page 55. See also... • “Command Details: Map_ADI_Read_Area” on page 50 • “Application Object (FFh)” on page 64 IMPORTANT: Error control is only performed on the command parameters. The Anybus module does not verify the correctness of these parameters by a read of the actual ADI attributes. • Command Details Field CmdExt[0] CmdExt[1] MsgData[0] MsgData[1] MsgData[2] MsgData[3] Contents Instance number of the ADI (low byte) Instance number of the ADI (high byte) Data Type of the ADI (see “Data Format” on page 26) Number of elements in the ADI Order Number of the ADI (low byte) Order Number of the ADI (high byte) Note: The Order Number in the mapping command equals that of the ‘Get_Instance_Number_By_Order’-command in the Application Data Object. See also... • “Application Data Object (FEh)” on page 55 (Order Number) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 50 • Response Details (Success) Field MsgData[0] • Contents Offset of the mapped ADI from the start of the Write Process Data. Response Details (Error) Error Invalid CmdExt[0] Invalid state Object Specific Error Contents The ADI number is not valid. Mapping of ADIs is only allowed in ‘SETUP’-state. Object specific error, see MsgData[1] for details: 01h: Invalid data type The data type is not valid for Process Data 02h: Invalid number of elements The number of elements is not valid (zero) 03h: Invalid total size The requested mapping is denied because the resulting total data size would exceed the maximum permissible (depending on network type) 04h: Multiple mapping The requested mapping was denied because the specific network does not accept multiple mapping of ADIs. 05h: Invalid Order Number The order number is not valid (zero). 06h: Invalid map command sequence The network specific requirements regarding command sequence have been violated. IMPORTANT: Error control is only performed on the command parameters. The Anybus module does not verify the correctness of these parameters by a read of the actual ADI attributes. Command Details: Map_ADI_Read_Area Details Command Code: 11h Valid for: Instance Description This command is identical to Map_ADI_Write_Area except that it maps ADIs to Read Process Data. See also... • “Command Details: Map_ADI_Write_Area” on page 49 • “Application Object (FFh)” on page 64 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Anybus Module Objects 51 7.6 Network Configuration Object (04h) Category Network specific Object Description This object contains network specific configuration parameters that may be set by the end user, typically settings such as baud rate or node address etc. Although the actual definition of the instances in this object are network specific, instance 1 and 2 are fixed in that they are always of an 8-bit data type. When possible, the following convention is used for these instances: Instance no. 1 2 Data type Any 8-bit data type Any 8-bit data type Parameter Currently selected network device address (or similar). Currently selected network communication bitrate (or similar). The instance values in this object must be updated whenever their originating value changes. Mechanical switches or similar need therefore be continuously monitored by the host application. Note: Instances tagged with ‘shared’ access (indicated by the descriptor) must be regarded as volatile; a ‘set’-access towards such an instance may or may not alter its value. The Anybus module will not respond with an error in case the value remains unaffected. Differentiation of Input Devices The Anybus module makes a distinction between parameters originating from “hardwired” input devices (i.e. physical mechanical switches) and parameters specified using a “soft” input device such a keypad and display. This permits the Anybus module to fulfil network specific needs related to the actual origin of a parameters (e.g. some networks require that a change of value on physical switches is visually acknowledged on the on-board LEDs). This distinction is based on the following actions from the host application (see table). State SETUP (other states) Actions (Host Application) Poll and update parameters originating from physical switches (make sure to issue at least one ‘set’-command for each one of the affected parameters). Do not update parameters originating from “soft” input devices (do not issue any ‘set’-commands for these parameters yet). Poll and update all parameters (i.e. physical switches and “soft” input methods) as necessary. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Anybus Behavior The Anybus module identifies the affected parameters as originating from physical switches. The remainder are assumed to originate from “soft” input devices. The Anybus module keeps track of the parameters which were updated during the SETUP-state, and is thus able to treat them differently if required by the network. Doc.Id. HMSI-168-97 Anybus Module Objects 52 Supported Commands Object: Get_Attribute (01h) Reset (05h) (The actual behavior is network specific) Instance: Get_Attribute (01h) Set_Attribute (02h) Get_Enum_String (06h) Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision No. of instances Highest instance no. Access Get Get Get Get Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Network Configuration’ 01h (Network dependent) Instance Attributes (Instances #1... N) Each instance represents a network configuration parameter. The attributes within it provides a comprehensive description of the parameter (name, data type etc.). Instance names and enumeration strings are multilingual (see “Multilingual Support” on page 9). The actual strings are of course network specific, but the maximum number of characters is limited to thirteen (13). # 1 Name Name Access Get 2 Data type Get 3 4 Number of Get elements Descriptor Get 5 Value Category Type Description Array of CHAR Parameter name (e.g. ‘Node address’) Appl. Spec. Data type (See “Data Format” on page 26) Appl. Spec.a UINT8 a Appl. Spec.a UINT8 Number of elements of the specified data type Appl. Spec.a UINT8 Bit field specifying the access rights for the parameter Bit:Access b0: 1: Get access b1: 1: Set access b2: 1: Shared accessb Determined by Appl. Spec.a Determined by Actual parameter value. Stored in non-volatile memory. “Descriptor” “Data type” a. The category of this attribute depends on how it is used in the application. b. Instances tagged with ‘shared’ access must be regarded as volatile; a ‘set’-access towards such an instance may or may not alter its value. The Anybus module will not respond with an error in case the value remains unaffected. Note: Instance #1 and instance #2 are categorized as Basic, if they exist in an application. All other instances of this object are categorized in the respective network appendices. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Chapter 8 8. Host Application Objects 8.1 General Information The objects in this group are meant to be implemented within the host application software. The Anybus module will issue commands towards these objects to access the settings and data within them. Their functionality is categorized to indicate when and how to use the objects. See also... • “Data Format” on page 26 • “Anybus Module Objects” on page 38 • “Categorization of Functionality” on page 69 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 54 8.2 Implementation Guidelines Implementation of an object is generally a matter of parsing incoming commands and forming suitable responses. While the exact details as of how this is done is beyond the scope of this document, it is important to follow the following basic rules: • An implemented object must feature all object attributes (instance #0) as specified in this document and/or the network interface appendix. • In case a command for some reason cannot be executed (i.e. if a particular object, attribute or command hasn’t been implemented), respond with a suitable error code to indicate the source of the problem. • Support for the Application Data Object is mandatory. • Support for the Application Object is optional, albeit highly recommended. • Support for Network Specific Objects is optional. It shall however be noted that the standard functionality provided by the Anybus module limits network functionality to the use of certain predefined device information and services. These limitations may be more or less significant and are described in each separate network interface appendix. In case this standard functionality is inadequate, i.e. vendor specific information or enhanced network functionality is required, Network Specific Objects may be implemented in the host application. • During startup the module will attempt to retrieve values of attributes in the Network Specific Objects. If an attribute is not implemented in the host application, respond with an error message (06h, “Invalid CmdExt[0]”). The module will then use its default value. Also, if the module tries to retrieve a value of an attribute that is not listed in the network appendix, respond with an error message (06h, “Invalid CmdExt[0]”. • Support for Process Data remapping (by means of commands ‘Remap_ADI_Write_Area’ and ‘Remap_ADI_Read_Area’) is mandatory for the Anybus CompactCom Drive Profile range of products. While implementation of these commands are optional for the standard CompactCom range, it may provide better network integration for certain networks in the future. See also... • “Error Codes” on page 29 IMPORTANT: The purpose of the Object Revision attribute is to make it possible for the Anybus module to establish whether or not the object implementation in the host application is compatible with that of the Anybus module, and to use different implementations if necessary. It is therefore imperative that the Object Revision attribute reflects the actual implementation, and that it is incremented based on changes in this document and/or the network interface appendix only. In case of questions, contact the HMS technical support services. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 55 8.3 Application Data Object (FEh) Category Basic. Please note that this object is mandatory. Object Description Each instance within this object (a.k.a. Application Data Instance or ADI) correlates to a block of data to be represented on the network. Each time such data is accessed from the network, the module translates such requests into object requests towards this object (or instances within it). The module may also access this object spontaneously if necessary. The exact representation on the network is highly network specific; e.g. on DeviceNet, ADIs are represented as dedicated CIP object, while on PROFIBUS, ADIs are accessed by means of acyclic DP-V1 read and write services. To allow the network and the Anybus module to efficiently scan the host application for ADIs, regardless of their instance number, this object implements the additional ‘Get_Instance_Number_By_Order’-command. This command retrieves the ADI instance number as if the ADIs were sorted in a numbered list, allowing the Anybus module to query only for the instances that are actually implemented in the host application. The Order Number is also used when mapping ADIs to Process Data, see “Command Details: Map_ADI_Write_Area” on page 49. Example: In this example, the host application has four ADIs with instance numbers 1, 3 and 100: Instance # 1 2 3 4... 99 100 Implemented Yes No Yes No Yes Order Number 1 2 3 In this particular case, the host application shall respond with instance number 100 to a ‘Get_Instance_Number_By_Order’-request for Order Number 3. IMPORTANT: • The Anybus module does not take over the host application responsibility for error control of parameter requests, even if a request is ‘obviously’ erroneous (e.g. a write request to an ADI with zero byte data, or an attempt to access an attribute that doesn’t exist will not be ‘filtered out’ by the module). • The response time in the host application (i.e. the time spent processing an incoming request towards this object prior to responding to it) must be taken into consideration, since some networks may impose certain timing demands. Where applicable, special timing requirements etc. are specified in each separate network appendix. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 56 Commands Object: Get_Attribute (01h) Get_Instance_Number_By_Order (10h) Get_Profile_Instance_Numbers (11h)1 Remap_ADI_Write_Area (13h)1,2 Remap_ADI_Read_Area (14h)1,2 Instance: Get_Attribute (01h) Set_Attribute (02h) Get_Enum_String (06h) Get_Indexed_Attribute (07h) Set_Indexed_Attribute (08h) Get_ADI_Info (12h)2,3 Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision Number of instances Highest instance no. Access Get Get Get Get Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Application Data’ 02h (depends on application) 1. Implementation is mandatory when using products with profile support. 2. Implementation is mandatory if remapping of Process Data is to be supported (object rev. 2 and higher). 3. Implementation is mandatory since object rev. 2. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 57 Instance Attributes (Instance #1... N) # 1 2 3 4 5 6 7 8 Name Name Access Get Category Type Description Network spe- Array of CHAR ADI name (can be multilingual) cific Data type Get Basic UINT8 Data type of ADI value (See “Data Format” on page 26) Number of Get Basic UINT8 Number of elements of the specified data type. It is elements strongly recommended not to use ADIs with Number of elements set to zero since this is not accepted by some networks. Descriptor Get Basic UINT8 Bit field specifying the access rights for the ADI value Bit:Access b0: 1: Get access b1: 1: Set access b2: -: (reserved, set to zero) b3a: 1: Can be mapped as Write Process Data b4a: 1: Can be mapped as Read Process Data Determined by Basic Determined by ADI value(s) Value(s)b “Descriptor” “Data type” d The maximum permitted ADI value. Implementation Get Max. valAppl. Spec. of this attribute is optional. If not implemented, the ueb,c module will use the maximum value of the specified data type for this attribute. b,c Get d The minimum permitted ADI value. Implementation Appl. Spec. Min. value of this attribute is optional. If not implemented, the module will use the minimum value of the specified data type for this attribute. d The default ADI value. Implementation of this attriDefault val- Get Appl. Spec. bute is optional. A zero value (float: +Min. value) will ueb,c be used if not implemented. a. Mandatory if remapping of Process Data is to be supported (object revision 2 and higher). b. The byte order of these attributes is network dependent; the Anybus does not perform any byte swapping etc. c. The Max/Min/Default attributes is common for all elements in the ADI. That is, there is no separate Max/Min/ Default value for each element in the array. d. The category of this attribute depends on how it is used in the application. IMPORTANT: • Once defined, the number of elements is fixed and must, together with the data type, represent the buffer space needed to handle the array. It is not permitted change to the number of elements during runtime. • The instance value(s) must fit entirely into the message data field. The number of elements, multiplied by the size of each element in bytes, must therefore never exceed 255 bytes. • The only attributes that may be changed during runtime are attribute #1 (‘Name’) and #5 (‘Value’). Once defined, all other attributes must be considered fixed; changing them during runtime is not permitted. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 58 8.3.1 Command Details: Get_Instance_Number_By_Order Details Command Code: 10h Valid for: Object Description This command requests the actual instance number of an ADI as if sorted in an ordered list. • Command Details: Field CmdExt[0] CmdExt[1] • Response Details (Success): Field MsgData [0...1] • Meaning Requested Order Number (low byte) Requested Order Number (high byte) Meaning The instance number of profile ADI Response Details (Error): Error Code Invalid CmdExt[0] Meaning The requested Order Number is not associated with an ADI. See also... • “Object Description” on page 55 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 59 8.3.2 Command Details: Get_Profile_Instance_Numbers Details Command Code: 11h Valid for: Object Description Note: This command is only applicable for products with built-in support for network profiles, such as the Anybus CompactCom Drive Profile range of products; it is not used by the standard version of the Anybus CompactCom. This command retrieves a list of the ADI instance numbers associated with a certain profile. The number of ADIs used for this, their purpose, data type etc., are dictated by the actual profile; the application may however assign instance numbers as needed to suit the implementation. IMPORTANT: When using the Anybus CompactCom Drive Profile range of products, implementation of this command is mandatory. For further information, consult the Anybus CompactCom Drive Profile Design Appendix. When using the standard version of the Anybus CompactCom, implementation of this command is not necessary. • Command Details: Field CmdExt[0] CmdExt[1] • Meaning (reserved, ignore) Value:Profile 00h: (reserved) 01h: Drive Profile (other) (reserved for future use) Response Details: Field MsgData [0...1] MsgData [2...3] ... MsgData [(2n-2)...(2n-1)] Type UINT16 UINT16 ... UINT16 Meaning The instance number of profile ADI 1 The instance number of profile ADI 2 ... The instance number of profile ADI n Note 1: The contents of this list is entirely profile dependent and is specified in the separate profile appendix (i.e. the Anybus CompactCom Drive Profile Design Appendix). Note 2: Optional or conditional profile ADIs that are not supported by the host application shall be indicated with an instance number of zero. Note 3: The Anybus module enters the ‘EXCEPTION’-state if any of the following occurs: - the size of the response did not match the requested profile - a required parameter was marked as not supported (see note 2) - the application indicated an error in the response See also... • “Object Description” on page 55 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 60 8.3.3 Command Details: Get_ADI_Info Details Command Code: 12h Valid for: Instance Description This command is used to gather the object attributes Data type, Number of elements and Descriptor of an ADI in a single response message. Note: Implementation is mandatory since object rev. 2. • Command Details: Field CmdExt[0] CmdExt[1] • Response Details (Success): Field MsgData [0] MsgData [1] MsgData [2] • Meaning (reserved, ignore) Meaning Data type Number of elements Descriptor Response Details (Error): Error Code 04h Meaning Unsupported instance. See also... • “Application Data Object (FEh)” on page 55 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 61 8.3.4 Command Details: Remap_ADI_Write_Area Details Command Code: 13h Valid for: Object Description The Anybus module issues this command when the network requests changes in the Process Data map. The ADIs are mapped at the insertion point in the same order as stated by the command. The command can remove and/or insert multiple mapping items, starting at the point indicated by the mapping item number in CmdExt[0], where a mapping item is an ADI previously mapped by a Map_ADI_Write_Area command, or an ADI (or elements of a multi-element ADI) previously mapped by a Remap_ADI_Write_Area command. The following set of data is included in the command data for each inserted mapping item: • The ADI number • The index to the first element to map • The number of consecutive elements to map The command may be issued in all states except SETUP and EXCEPTION. Note 1: All actions specified in the command shall either be carried out or rejected, i.e. the Process Data map must remain unchanged if the command was not accepted. Note 2: The Anybus module is limited to one outstanding remap command at a time. See also... • “Network Object (03h)” on page 47 • “Runtime Remapping of Process Data” on page 78 • “Example: Remap_ADI_Write_Area” on page 82 IMPORTANT: To support this procedure, the host application must be capable of re-arranging the Process Data map during runtime. This is a mandatory requirement from object rev. 2. Support for this object revision is required when using the Anybus CompactCom Drive Profile range of products, but may also provide better network integration for certain networks in the standard product range. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 62 • Command Details: Field CmdExt[0] CmdExt[1] Data[0-1] Data[2-3] Data[4-5] Data[6] Data[7] Data[8-9] Data[10] Data[11] ... • Response Details (Success): Field MsgData [0] MsgData [1] • Meaning Start of remap (mapping item number, 0 = first) (reserved, ignore) The number of current mapping items to remove (0... 256) The number of mapping items to insert (0... 62) New mapping item 1: ADI number New mapping item 1: Index to the first element to map New mapping item 1: Number of consecutive elements to map New mapping item 2: ADI number New mapping item 2: Index to the first element to map New mapping item 2: Number of consecutive elements to map (etc.) Meaning The resulting total size of the write process data area in bytes (low byte) The resulting total size of the write process data area in bytes (high byte) Response Details (Error): Error Code 01h Error Mapping item error 02h Invalid total size Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Meaning The requested mapping is denied because of a NAK to at least one mapping item The requested mapping is denied because the resulting total data size would exceed the maximum permissible for the application Doc.Id. HMSI-168-97 Host Application Objects 63 8.3.5 Command Details: Remap_ADI_Read_Area Details Command Code: 14h Valid for: Object Description This command is used to (re-)map ADIs to the read process data area. It is otherwise equivalent to Remap_ADI_Write_Area. Note 1: A successful transfer of an ACK to a remap command indicates the point where the process data map will be changed. For serial application, this means that a changed process data map shall be expected or used in telegrams following the empty telegram (or telegrams in case of retransmissions) after the ACK (see “Runtime Remapping of Process Data” on page 78). Note 2: Handling of changed data indication (Auxiliary Bit) during a remap is described in “Changed Data Indication” on page 14. See also... • “Network Object (03h)” on page 47 • “Runtime Remapping of Process Data” on page 78 • “Example: Remap_ADI_Write_Area” on page 82 IMPORTANT: To support this procedure, the host application must be capable of re-arranging the Process Data map during runtime. This is a mandatory requirement in the case of the Anybus CompactCom Drive Profile range of products, but may also provide better network integration for certain networks in the standard product range (for these products, support for this command is optional, albeit highly recommended). Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 64 8.4 Application Object (FFh) Category Extended Object Description This object groups general settings for the host application. Albeit not mandatory, it is highly recommended to implement this object and its commands to be able to support multiple languages and network reset requests. Supported Commands Object: Get_Attribute (01h) Reset (05h) Reset_Request (10h) Change_Language_Request(11h) Instance: Get_Attribute (01h) Set_Attribute (02h) Get_Enum_String (06h) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 65 Object Attributes (Instance #0) # 1 2 3 4 Name Name Revision Number of instances Highest instance no. Access Get Get Get Get Data Type Array of CHAR UINT8 UINT16 UINT16 Value ‘Application’ 01h 0001h 0001h Instance Attributes (Instance #1) # 1 2 Name Configured Supported languages Access Get Get Category Extended Extended Type BOOL Array of ENUM Description Indicates if the application parameters have been changed from their out-of-box value. Value:Meaning: False: Out-of-box state True: Configured, settings have been altered See also... - “Command Details: Reset” on page 66 - “Command Details: Reset_Request” on page 67 List specifying which languages that are supported by the host application. Value:Enumeration String: 00h: ‘English’ 01h: ‘Deutsch’ 02h: ‘Español’ 03h: ‘Italiano’ 04h: ‘Français’ See also... - “Multilingual Support” on page 9 - “Anybus Object (01h)” on page 39 (Instance attribute #9) - “Command Details: Change_Language_Request” on page 68 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 66 Command Details: Reset Details Command Code: 05h Valid for: Object Description This command is issued by the module when a reset is required. Depending on the network type, it may, or may not, be preceded by a ‘Reset_Request’-command. • Command Details Field Contents CmdExt[0] (reserved, ignore) CmdExt[1] 00h: Power-on reset 01h: Factory default reset Comment This shall be regarded as a device reset, i.e. the host application shall reset the module via the /RESET signal. Note: The Anybus module enters the ‘EXCEPTION’-state prior to issuing this type of request. This shall cause the host application to return to an out-of-box state. Any network-specific procedures necessary to set the module to this state are performed automatically. 02h: Power-on + Factory default A combination of the two above. Note: The Anybus module enters the ‘EXCEPTION’-state prior to issuing this type of request. • Response Details (No data) See also... • “Instance Attributes (Instance #1)” on page 65 (Attribute #1, ‘Configured’) • “Command Details: Reset_Request” on page 67 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 67 Command Details: Reset_Request Details Command Code: 10h Valid for: Object Description On certain networks, this command may be issued prior to the Reset command (see below). This is, as the name implies, a request and not an actual reset command. The requested reset can be either a Power-on reset, a Factory Default reset, or both. A Power-on reset shall be regarded as a device reset. Host Application Reset request (power-on) Reset_Request (power-on) (request granted) Reset acknowledge If the request is granted, the host application must also be prepared to receive a corresponding Reset command (see figure). State = EXCEPTION Reset (power-on) The host application is also free to respond with an error in case a reset for some reason cannot be executed. In such case, no Reset command will be issued by the module. • Network Anybus Module Command Details Host Application Field Contents CmdExt[0] (reserved, ignore) CmdExt[1] 00h = Power-on reset 01h = Factory default reset 02h = Power-on + Factory default Anybus Module Network Reset request (power-on) Reset_Request (power-on) (reset not granted) Reset refused acknowledge • Response Details (No data) See also... • “Instance Attributes (Instance #1)” on page 65 (Attribute #1, ‘Configured’) • “Command Details: Reset” on page 66 Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Host Application Objects 68 Command Details: Change_Language_Request Details Command Code: 11h Valid for: Object Instance Description This command will be issued by the module when a change of the current language is requested from the network. If accepted, it will result in a corresponding change of the Language Attribute (#9) in the Anybus Object (01h). The host application must also adjust its’ internal language settings accordingly. • Command Details Field Contents CmdExt[0] (reserved, ignore) CmdExt[1] The requested language as follows: Value:Language: 00h: English 01h: German 02h: Spanish 03h: Italian 04h: French • Response Details (No data) See also... • “Multilingual Support” on page 9 • “Anybus Object (01h)” on page 39 (Instance attribute #9, ‘Language’) • “Instance Attributes (Instance #1)” on page 65 (Attribute #2, ‘Supported languages’) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Appendix A A. Categorization of Functionality The objects, including attributes and services, of the Anybus CompactCom and the application are divided into three categories: basic, advanced and extended. A.1 Basic This category includes objects, attributes and services that are mandatory to implement or to use. They will be enough for starting up the Anybus CompactCom and sending/receiving data with the chosen network protocol. The basic functions of the industrial network are used. These objects are presented in this document (and the appropriate industrial network appendix). Additional objects etc, that will make it possible to certify the product also belong to this category. A.2 Extended Use of the objects in this category extends the functionality of the application. Access is given to the more specific characteristics of the industrial network, not only the basic moving of data to and from. Extra value is given to the application. A.3 Advanced The objects, attributes and services that belong to this group offer specialized and/or seldom used functionality. Most of the available network functionality is enabled and accessible. Access to the specification of the industrial network is normally required. Anybus CompactCom 30 Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Appendix B B. Network Comparison Chart The Anybus CompactCom software interface is designed to be as generic as possible without sacrificing network functionality or integration with the host system. When designing the host application, it is important to be aware of the limitations and possibilities of each networking system. In most cases, no additional software support is needed to support a particular network. However, in order to fully exploit certain aspects of the network functionality, a degree of dedicated software support may be necessary. A summary of the features offered by the different network implementations is presented in the table on the next page. How to interpret the table: • The figures specify the values that are to be expected in a typical generic implementation. • The figures in parenthesis specify the values that are possible with dedicated software support. • Of the maximum number of diagnostic instances there is always one instance reserved for one of severity level ‘Major, unrecoverable’ to force the module into the ‘EXCEPTION’-state. • If a data type is not supported, this means that the network has no direct counterpart for that particular type. The data may however still be represented on the network, albeit in some other format (e.g. a UINT64 may be represented as four UINT16s etc.) Note: The information in this chapter gives a rough idea of the possibilities on the different network implementations. For in-depth information about a particular network, consult the corresponding network appendix. Anybus CompactCom 30 Doc.Rev. 2.08 Doc.Id. HMSI-168-97 PROFIBUS DP-V1 PROFIBUS DP-V0 DeviceNet CANopen Modbus RTU Modbus/TCP ControlNet EtherCAT CompoNet SERCOS III BACnet IP BACnet MSTP LSB first LSB first MSB first MSB first MSB first LSB first LSB first LSB first LSB first LSB first LSB first LSB first LSB first MSB first MSB first Acyclic Data Support Yes No Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Max. no. of Elements Per ADI 255 255 64 (240) N/A 255 255 254 32 (255) 32 (255) 255 255 255 255 1 1 Max. ADI Size (in bytes) 255 255 64 (240) N/A 255a 255 254 32 (255) 32 (255) 255 255 255 255 4 4 1 N/A 1b N/A 1 1 1 1 1 1 1 1 1 1 1 4062 4062 (65023) (65023) 65535 16383 255c 32767d 65535 65535 Lowest Addressable ADI no. Highest Addressable ADI no. 65535 Max. Write Process Data (in bytes) 256 Min. Write Process Data (in bytes) 0 Max. Read Process Data (in bytes) 256 Min. Read Process Data (in bytes) 0 Max. Process Data (Read + Write, in bytes) 512 N/A 65025 14-44 (256)e 152 (244)f 0 0 14-46 (256)e 152 (244)f 0 0 28-90 (512)e 152 (368)f and 2-Port PROFINET, 1-Port CC-Link Network Data Format and 2-Port EtherNet/IP, 1-Port Anybus CompactCom 30 Doc.Rev. 2.08 Item N/A 32767 65535 16383 80 (244)f 256f 256 256 256 256 256 256 32 256 256 256 0 0 0 0 0 0 0 0 0 0 0 0 80 (244)f 256 256 256 256 256 256 256 32 256 0 0 0 0 0 0 0 0 0 0 0 0 0 0 80 (380)f 512f 512 512 512 512 512 512 64 512 256 256 Min. Process Data (Read + Write, in bytes) 0 0 1 1 1 0 0 0 0 0 0 1 0 0 0 Requires ‘Get/Set_Indexed_Attribute’ No No No No No No Yes No No (Yes) No Yes No No No No Yesg,h No No No Yesh Yesg No No Yesh Yesg Yesi Yesg Yesh Yesh,j Yesj 6 6 6 (1) 10 (10) 6 (1) 6 6 6 6 6 6 6 6 1 1 Supports Network Reset Type 0: ‘Power-onreset’ Yes No No No No Yes Yes No No Yes No Yes No Yes Yes Supports Network Reset Type 1: ‘Factory default reset’ Yes No No No Yes Yes Yes No No Yes Yes Yes Yes No No Supports SINT64 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Supports UINT64 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Supports FLOAT Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Extended LED functionality No No No No No No No No No Yes Yes No No No No Requires ‘Get_Instance_Number_By_Order’ Max. no. of Diagnostic Instances Network Comparison Chart 71 Doc.Id. HMSI-168-97 a. If API 0 is not used, or if transparent mode is used, the ADI data size will at the most be 244 bytes as the header (11 bytes) must be inserted in the Get/Set_Record message. For more information see PROFINET network appendices. b. Due to technical reasons, it is generally not recommended to use ADI numbers 1 ... 256, since this may cause problems when using certain PROFIBUS configuration tools. c. More ADIs can be created, but only 255 can be addressed from CompoNet. d. Of these, around 16000 ADIs can be reached from SERCOS III. e. The amount of process data depends on the data types of the mapped ADIs. For more information see CC-Link network interface appendix. f. Check PROFIBUS and PROFINET network interface appendices for addressing limitations. g. This command is used when accessing attributes in the Parameter Object from a CIP network. h. For modules, that support internal web pages, this command is used when the parameter web page is opened. i. For EtherCAT products, this command is used during initialization to find number of ADIs. j. When a BACnet product isn’t in advanced mode, this command is used to perform initial mapping. Appendix C C. Timing & Performance C.1 General Information This chapter specifies timing and performance parameter that are verified and documented for each member of the Anybus CompactCom family. The following timing aspects are measured: Category Startup Delay NW_INIT Delay Telegram Delay Command Delay Anybus Read Process Data Delay (Anybus Delay) Anybus Write Process Data Delay (Anybus Delay) Network System Read Process Data Delay (Network System Delay) Network System Write Process Data Delay (Network System Delay) Parameters T1, T2 T3 T4 T5 T6, T7, T8 T12, T13, T14 T9, T10, T11 T15, T16, T17 Page 73 73 74 75 76 77 77 77 IMPORTANT: At the time of writing, network specific timing specifications for all networks has not yet been publicly released. This information will be added continuously to all network interface appendices when available. In case of questions, contact HMS. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Timing & Performance 73 C.2 Internal Timing C.2.1 Startup Delay The following parameters are defined as the time measured from the point where /RESET is released to the point where the specified event occurs. Parameter T1 T2 Description Anybus generates the first application interrupt (parallel mode) The Anybus is able to receive and handle the first application telegram (serial mode) Max. 1.0 1.0 Unit. s s C.2.2 NW_INIT Delay The time required by the Anybus module to perform the necessary actions in the NW_INIT-state is highly network specific. Furthermore, the number of commands issued towards the host application in this state may vary, not only between different networks, but also between different implementations (e.g. depending on the actual Process Data implementation etc.). This, in turn, means that the response time of the host application has a major impact on this parameter as well. It is therefore only possible to specify a maximum value that any Anybus version, together with a typical host application implementation, can fulfil. Specifying this parameter does not, in any way, imply that the host application is required, or even expected, to supervise that it is met - the fact that the protocol is running and the correct state is indicated should be a sufficient indication of the healthiness of the Anybus module. If, however, the Anybus concept is not trusted in this respect, the host application may wait for a timeout before a no-go situation is indicated to the end user. It should then be satisfactory to use a rather long timeout value since this is, after all, during the start-up phase. Parameter No. of network specific commands No. of ADIs (single UINT8) mapped to Process Data in each direction Application response time No. of simultaneously outstanding Anybus commands that the application can handle Conditions Max. 32a < 10 ms 1 a. Or maximum amount in case the network specific maximum is less Parameter T3 Description NW_INIT delay Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Communication Serial 19.2kbps (all other modes) Max. 30 10 Unit. s s Doc.Id. HMSI-168-97 Timing & Performance 74 C.3 Anybus Response Time C.3.1 Overview Host Application Anybus Anybus Internal Object Command Command T4 Host application response time T5 Response Response C.3.2 Telegram Delay The Telegram Delay is defined as the time required by the Anybus module to respond to a telegram. It is assumed that commands are issued one by one, i.e. that no new commands are issued towards the Anybus module prior to receiving a response to the previous one. Parameter Communication Host application response time Anybus state No. of ADIs (single UINT8) mapped to Process Data in each direction Conditions All modes 0.2ms All states 32a Normal 1 Bus load, no. of nodes, baud rate etc. No. of simultaneously outstanding application commands. a. Or maximum amount in case the network specific maximum is less Parameter T4 Description Anybus telegram delay Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Avg. < 0.4 Max. 1.5 Unit. ms Doc.Id. HMSI-168-97 Timing & Performance 75 C.3.3 Command Delay The Command Delay is defined as the time required by the Anybus module to respond to commands which are handled internally, i.e. commands where no network information is exchanged. The measurement is ended when the Anybus module has finished processing and is ready to send a response. It is assumed that commands are issued one by one, i.e. that no new commands are issued towards the Anybus module prior to receiving a response to the previous one. Conditions Communication Application response time Anybus state No. of ADIs (single UINT8) mapped to Process Data in each direction Conditions All modes 0.2 ms All states 32a Normal 1 Bus load, number of nodes, baud rate etc. Number of simultaneously outstanding application commands. a. Or maximum amount in case the network specific maximum is less Certain commands may require a considerable amount of time to execute due to various technical reasons (e.g. storage of parameters to non-volatile memory or formatting of a file system etc.). The commands are therefore categorized by their expected command delay. Parameter Description T5 Anybus Command Delay Categorya A B Cb Avg. Max. Unit. <1 - 10 5000 ms ms ms a. A command is of category A unless otherwise stated. b. These commands are used for blocking services; a response is not returned until an external event occurs of which the Anybus module has no control. It must, however, be taken into consideration that such services will lock message resources for an unpredictable amount of time in both the Anybus module and the host application. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Timing & Performance 76 C.4 Process Data C.4.1 Overview Host Application Application software Anybus Host interface software HMS Driver Network Master Network specific software Network specific hardware Network Media Event Anybus Delay Network System Delay C.4.2 Anybus Read Process Data Delay (Anybus Delay) The Read Process Data Delay (labelled ‘Anybus delay’ in the figure above) is defined as the time measured from just before new data is buffered and available to the Anybus host interface software, to when the data is available to the host application (just after the new data has been read from the driver). Note: The transmission delay for the serial communication is not considered in these measurements. Parameter Application CPU Timer system call interval Driver call interval No.of ADIs (single UINT8) mapped to Process Data in each direction. Communication Telegram types during measurement period Bus load, no. of nodes, baud rate etc. Parameter T6 T7 T8 Description Anybus Read Process Data delay, 8 ADIs (single UINT8) Anybus Read Process Data delay, 16 ADIs (single UINT8) Anybus Read Process Data delay, 32 ADIs (single UINT8) Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Conditions 1 ms 0.2... 0.3 ms 8, 16 and 32 Parallel Process Data only Normal Avg. < 0.5 < 0.7 <1 Max. 1 1.2 1.5 Unit. ms ms ms Doc.Id. HMSI-168-97 Timing & Performance 77 C.4.3 Anybus Write Process Data Delay (Anybus Delay) The Write Process Data Delay (labelled ‘Anybus delay’ in the figure) is defined as the time measured from the point the data is available from the host application (just before the data is written from the host application to the driver), to the point where the new data has been forwarded to the network buffer by the Anybus host interface software. Conditions: as in “Anybus Read Process Data Delay (Anybus Delay)”, p. 76. Note: The transmission delay for the serial communication is not considered in these measurements. Parameter T12 T13 T14 Description Anybus Write Process Data delay, 8 ADIs (single UINT8) Anybus Write Process Data delay, 16 ADIs (single UINT8) Anybus Write Process Data delay, 32 ADIs (single UINT8) Avg. < 0.5 < 0.7 <1 Max. 1 1.2 1.5 Unit. ms ms ms C.4.4 Network System Read Process Data Delay (Network System Delay) The Network System Read Process Data Delay (labelled ‘Network System Delay in the figure), is defined as the time measured from the point where an event is generated at the network master to when the corresponding data is available to the host application (just after the corresponding data has been read from the driver). Parameter T9 T10 T11 Description Avg. Max. Unit. (network type dependent;see Network System Read Process Data delay, 8 ADIs (single UINT8) separate network interface Network System Read Process Data delay, 16 ADIs (single UINT8) appendix) Network System Read Process Data delay, 32 ADIs (single UINT8) Conditions: as in “Anybus Read Process Data Delay (Anybus Delay)”, p. 76. IMPORTANT: At the time of writing, network specific timing specifications for all networks has not yet been publicly released. This information will be added continuously to all network interface appendices when available. C.4.5 Network System Write Process Data Delay (Network System Delay) The Network System Write Process Data Delay (labelled ‘Network System Delay in the figure), is defined as the time measured from the time after the new data is available from the host application (just before the data is written to the driver) to when this data generates a corresponding event at the network master. Parameter T15 T16 T17 Description Avg. Max. Unit. (network type dependents sepaNetwork System Write Process Data delay, 8 ADIs (single UINT8) Network System Write Process Data delay, 16 ADIs (single UINT8) rate network interface appendix) Network System Write Process Data delay, 32 ADIs (single UINT8) Conditions: as in “Anybus Read Process Data Delay (Anybus Delay)” on page 76. IMPORTANT: At the time of writing, network specific timing specifications for all networks has not yet been publicly released. This information will be added continuously to all network interface appendices when available. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Appendix D D. Runtime Remapping of Process Data This appendix describes how to handle a request from the application to remap read or write process data in parallel mode and in serial mode. Please note that the telegrams are exchanged in a ping-pong fashion. D.1 Parallel mode Runtime remapping of process data in parallel mode is rather straightforward, see figures below. D.1.1 Read Process Data A p p lica tio n ABCC W PD H a n d le R e m a p re a d M M E xp e ct n e w re a d p ro ce ss d a ta m a p ( RPD2 ) RPD1 W PD R e m a p re a d R emap A C K RPD2 H a n d le R e m a p A C K U se n e w re a d p ro ce ss d a ta m a p (RPD2) RPD = Read Process Data WPD = Write Process Data M e ssa g e ( M = 1 ) P o ssib le m e ssa g e (M = X ) P ro ce ss d a ta Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Runtime Remapping of Process Data 79 D.1.2 Write Process Data A p p lica tio n ABCC W PD1 H a n d le R e m a p w rite M M R PD R e m a p w rite W PD1 R emap A C K H a n d le R e m a p A C K R PD U se n e w w rite p ro ce ss d a ta m a p (WPD2) W PD2 RPD = Read Process Data WPD = Write Process Data M e ssa g e ( M = 1 ) P o ssib le m e ssa g e (M = X ) P ro ce ss d a ta Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Runtime Remapping of Process Data 80 D.2 Serial Mode Please note that the telegrams are exchanged in a ping-pong fashion, and that a telegram without a message ends each command. A number of telegrams will thus have to be exchanged before the re-mapping takes effect D.2.1 Read Process Data A p p lica tio n ABCC W PD M RPD1 R e m a p re a d W PD RPD1 H a n d le R e m a p re a d M W PD R emap A C K RPD1 W PD E xp e ct n e w re a d p ro ce ss d a ta m a p ( RPD2 ) R PD2 H a n d le R e m a p A C K U se n e w re a d p ro ce ss d a ta m a p (RPD2) RPD = Read Process Data WPD = Write Process Data N o m e ssa g e (M = 0 ) M e ssa g e ( M = 1 ) P o ssib le m e ssa g e (M = X ) P ro ce ss d a ta Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Runtime Remapping of Process Data 81 D.2.2 Write Process Data A p p lica tio n ABCC W PD1 M R PD R e m a p w rite W PD1 R PD H a n d le R e m a p w rite M W PD1 R emap A C K R PD W PD1 H a n d le R e m a p A C K R PD U se n e w w rite p ro ce ss d a ta m a p (WPD2) W PD2 RPD = Read Process Data WPD = Write Process Data No Me ssa g e ( M = 0 ) M e ssa g e ( M = 1 ) P o ssib le m e ssa g e (M = X ) P ro ce ss d a ta Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 Runtime Remapping of Process Data 82 D.3 Example: Remap_ADI_Write_Area ADI 2 a (1 * UINT8) 3 b 4 c (1 * UINT16) d (3 * UINT16) e 5 f g h i (4 * UINT8) 8 j k l m (4 * UINT8) 12 n (1 * UINT8) Initial Mapping: Mapping Item ADI Element 0 a 1 b 2 d c 3 e f g h i Command Remap_ADI_Write_Area: 1 0 2 2 8 1 3 12 0 1 CmdExt[0] CmdExt[1] Data[0...1] Data[2...3] Data[4...5] Data[6] Data[7] Data[8...9] Data[10] Data[11] Start remap from mapping item 1 (reserved) Remove 2 mapping items (i.e. 1 and 2) Insert 2 mapping items New mapping item 1: Instance no. #8 New mapping item 1: Map from element 1 (k) New mapping item 1: Map 3 elements (k... m) New mapping item 2: Instance no. #12 New mapping item 2: Map from element 0 (n) New mapping item 2: Map 1 element (n) Result: Mapping Item ADI Element 0 a k 1 l Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 m 2 n 3 f g h i Doc.Id. HMSI-168-97 Appendix E E. CRC Calculation E.1 General Note: The following information applies only when using the serial interface. To allow the receiving part to detect transmission errors, each serial telegram frame contains a 16-bit Cyclic Redundancy Check. The CRC is calculated as follows: 1. Load a 16-bit register with FFFFh. (Let’s call it the CRC-register for simplicity) 2. XOR the first byte of the message with the low order byte of the CRC-register, putting the result in the CRC-register 3. Shift the CRC-register one bit to the right (towards the LSB), zero-filling the MSB. 4. Examine the LSB that was just shifted out from the register. If set, Exclusive-OR the CRC-register with the polynomial value A001h (1010 0000 0000 0001). 5. Repeat steps 3 and 4 until 8 shifts have been performed. 6. XOR the next byte from the message with the low order byte of the CRC-register, putting the result in the CRC-register 7. Repeat steps 3...6 until the complete message has been processed. 8. The CRC-register now contains the final CRC16-value. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 CRC Calculation 84 E.2 Example This example uses a fast approach to calculate the CRC; all possible CRC-values are pre-loaded into two arrays, which are simply indexed as the function increments through the message buffer. Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97 CRC Calculation 85 const UINT8 abCrc16Hi[] = { 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40 }; 0x80, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC0, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC0, 0x80, 0x41, 0x01, 0xC1, 0x81, 0x40, 0x01, 0xC1, 0x80, const UINT8 abCrc16Lo[] = { 0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0xC5, 0xC4, 0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0xCB, 0x0B, 0xC9, 0x09, 0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC, 0x14, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3, 0x11, 0xD1, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0xE7, 0xE6, 0x26, 0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F, 0x6E, 0xAE, 0xAA, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x9C, 0x5C, 0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C, 0x44, 0x84, 0x85, 0x45, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80, 0x40 }; 0x07, 0x0E, 0x1B, 0xD4, 0xD0, 0x37, 0xFA, 0x2B, 0x25, 0xE0, 0xA5, 0x6A, 0x7A, 0xB5, 0x50, 0x95, 0x9B, 0x4A, 0x87, 0xC7, 0x0A, 0xDB, 0xD5, 0x10, 0xF5, 0x3A, 0x2A, 0xE5, 0xA0, 0x65, 0x6B, 0xBA, 0x77, 0x90, 0x94, 0x5B, 0x4E, 0x47, 0x05, 0xCA, 0xDA, 0x15, 0xF0, 0x35, 0x3B, 0xEA, 0x27, 0x60, 0x64, 0xAB, 0xBE, 0xB7, 0x91, 0x54, 0x99, 0x8E, 0x46, UINT16 CRC_Crc16( UINT8* pbBufferStart, UINT16 iLength ) { UINT8 bIndex; UINT8 bCrcLo; UINT8 bCrcHi; bCrcLo = 0xFF; bCrcHi = 0xFF; while( iLength > 0 ) { bIndex = bCrcLo ^ *pbBufferStart++; bCrcLo = bCrcHi ^ abCrc16Hi[ bIndex ]; bCrcHi = abCrc16Lo[ bIndex ]; iLength--; } return( bCrcHi << 8 | bCrcLo ); } Anybus CompactCom 30 Software Design Guide Doc.Rev. 2.08 Doc.Id. HMSI-168-97
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021