Anybus-CompactCom-5415-Anybus CompactCom Software Design Guide

Anybus-CompactCom-5415-Anybus CompactCom Software Design Guide
Software Design Guide
Anybus -CompactCom 30
®
Doc.Id. HMSI-168-97
Rev. 2.09
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.anybus.com
Important User Information
This document is intended to provide a good understanding of the software interface used on Active Anybus CompactCom 30 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.09
Copyright© HMS Industrial Networks AB
June 2015 Doc Id HMSI-168-97
Table of Contents
Table of Contents
Preface
About This Document
Related Documents.................................................................................................................................. 6
Document History ................................................................................................................................... 6
Conventions & Terminology .................................................................................................................. 7
Support....................................................................................................................................................... 7
Chapter 1
About the Anybus CompactCom
General Information ................................................................................................................................ 8
Features ...................................................................................................................................................... 8
Chapter 2
Software Introduction
Background................................................................................................................................................ 9
The Object Model .................................................................................................................................. 10
Basics............................................................................................................................................. 10
Addressing Scheme......................................................................................................................... 10
Object Categories............................................................................................................................ 10
Standard Object Implementation..................................................................................................... 11
Network Data Exchange....................................................................................................................... 12
Diagnostics .............................................................................................................................................. 14
Multilingual Support............................................................................................................................... 14
Chapter 3
Host Communication Layer
General Information .............................................................................................................................. 15
Basic Principles .............................................................................................................................. 15
Telegram Contents.......................................................................................................................... 15
Handshake Registers .............................................................................................................................. 16
Control Register (Read/Write)....................................................................................................... 16
Status Register (Read Only) ........................................................................................................... 16
Supervised Bit (SUP)..................................................................................................................... 17
Auxiliary Bit (STAT_AUX, CTRL_AUX)............................................................................ 17
Process Data Subfield ............................................................................................................................ 18
General Information....................................................................................................................... 18
Process Data Mapping ................................................................................................................... 18
Changed Data Indication ............................................................................................................... 19
Anybus Watchdog .................................................................................................................................. 20
Application Watchdog ........................................................................................................................... 20
Serial Host Communication.................................................................................................................. 21
General Information....................................................................................................................... 21
Serial Telegram Frame................................................................................................................... 21
Message Fragmentation .................................................................................................................. 22
Transmission Errors ...................................................................................................................... 23
Parallel Host Communication .............................................................................................................. 25
General Information....................................................................................................................... 25
II
Memory Map................................................................................................................................. 25
Parallel Telegram Handling ........................................................................................................... 26
Chapter 4
The Anybus State Machine
General Information.............................................................................................................................. 27
State-Dependent Actions ...................................................................................................................... 28
Chapter 5
Object Messaging
General Information.............................................................................................................................. 29
Basic Principles .............................................................................................................................. 29
Source ID ...................................................................................................................................... 29
Error Handling ............................................................................................................................. 30
Error Counters .............................................................................................................................. 30
Message Layout ...................................................................................................................................... 31
Data Format ............................................................................................................................................ 32
Available Data Types.................................................................................................................... 32
Handling of Array of Char (Strings).............................................................................................. 32
Flow Control........................................................................................................................................... 33
Command Specification ........................................................................................................................ 34
General Information....................................................................................................................... 34
Command Codes............................................................................................................................ 35
Error Codes................................................................................................................................... 35
Get_Attribute ............................................................................................................................... 36
Set_Attribute ................................................................................................................................ 36
Create............................................................................................................................................ 37
Delete ............................................................................................................................................ 37
Reset.............................................................................................................................................. 38
Get_Enum_String ........................................................................................................................ 38
Get_Indexed_Attribute ................................................................................................................. 39
Set_Indexed_Attribute.................................................................................................................. 39
Chapter 6
Initialization and Startup
General Information.............................................................................................................................. 40
Initial Handshake.................................................................................................................................... 41
Anybus Setup (‘SETUP’-State) ............................................................................................................ 42
Network Initialization (‘NW_INIT’-State) ........................................................................................ 43
Chapter 7
Anybus Module Objects
General Information.............................................................................................................................. 44
Object Revisions..................................................................................................................................... 44
Anybus Object (01h).............................................................................................................................. 45
Diagnostic Object (02h) ........................................................................................................................ 51
Network Object (03h) ........................................................................................................................... 54
Network Configuration Object (04h) ................................................................................................. 58
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
III
Chapter 8
Host Application Objects
General Information.............................................................................................................................. 60
Implementation Guidelines .................................................................................................................. 61
Application Data Object (FEh) ........................................................................................................... 62
Command Details: Get_Instance_Number_By_Order .................................................................. 65
Command Details: Get_Profile_Instance_Numbers....................................................................... 66
Command Details: Get_ADI_Info ............................................................................................... 67
Command Details: Remap_ADI_Write_Area............................................................................. 68
Command Details: Remap_ADI_Read_Area.............................................................................. 70
Application Object (FFh)...................................................................................................................... 71
Appendix A Categorization of Functionality
Basic ......................................................................................................................................................... 76
Extended.................................................................................................................................................. 76
Advanced ................................................................................................................................................. 76
Appendix B Network Comparison Chart
Appendix C Timing & Performance
General Information.............................................................................................................................. 79
Internal Timing....................................................................................................................................... 80
Startup Delay ................................................................................................................................ 80
NW_INIT Delay......................................................................................................................... 80
Anybus Response Time......................................................................................................................... 81
Overview ........................................................................................................................................ 81
Telegram Delay.............................................................................................................................. 81
Command Delay............................................................................................................................ 82
Process Data ........................................................................................................................................... 83
Overview ........................................................................................................................................ 83
Anybus Read Process Data Delay (Anybus Delay)........................................................................ 83
Anybus Write Process Data Delay (Anybus Delay) ...................................................................... 84
Network System Read Process Data Delay (Network System Delay)............................................. 84
Network System Write Process Data Delay (Network System Delay)............................................ 84
Appendix D Runtime Remapping of Process Data
Parallel mode........................................................................................................................................... 85
Read Process Data......................................................................................................................... 85
Write Process Data........................................................................................................................ 86
Serial Mode.............................................................................................................................................. 87
Read Process Data......................................................................................................................... 87
Write Process Data........................................................................................................................ 88
Example: Remap_ADI_Write_Area ................................................................................................... 89
Appendix E CRC Calculation
General..................................................................................................................................................... 90
Example ................................................................................................................................................... 91
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
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
Anybus CompactCom 30 Hardware Design Guide
Anybus CompactCom Driver User Guides
Anybus CompactCom 30 Network Interface Appendices (separate document for each networking system)
Anybus CompactCom 30 Drive Profile Design Appendices (separate document for each networking system)
Author
HMS
HMS
HMS
HMS
P.2 Document History
Summary of Recent Changes (2.08 ... 2.09)
Change
Updated exception codes for the Anybus Object
Updated section on Error Handling
Added information about error counters
Page(s)
48
30
30
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
2.09
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
2015-06-08
Anybus CompactCom 30
Doc.Rev. 2.09
Author
PeP
PeP
PeP
PeP
PeP
HeS
HeS
PeP
PeP
KeL
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
5, 7
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
Misc updates
Doc.Id. HMSI-168-97
About This Document P-7
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.anybus.com.
Anybus CompactCom 30
Doc.Rev. 2.09
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.09
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 10
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.09
Doc.Id. HMSI-168-97
Software Introduction 11
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
44
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 60
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.09
Doc.Id. HMSI-168-97
Software Introduction 12
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.09
Doc.Id. HMSI-168-97
Software Introduction 13
•
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 18
•
“The Anybus State Machine” on page 27
•
“Network Object (03h)” on page 54
•
“Application Data Object (FEh)” on page 62
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Software Introduction 14
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 51
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 71
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
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 16
•
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 29
•
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 18
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 16
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 22).
CTRL_R
If set, the host application is ready to receive a new command (see also “Flow Control” on page 33).
CTRL_AUX See “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 17
(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 22).
STAT_R
If set, the Anybus module is ready to process incoming commands (see also “Flow Control” on page 33).
STAT_AUX See “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 17
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 27).
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.09
Doc.Id. HMSI-168-97
Host Communication Layer 17
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 16 (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 16 (bit 4, ‘CTRL_AUX’)
•
“Status Register (Read Only)” on page 16 (bit 4, ‘STAT_AUX’)
•
“Process Data Subfield” on page 18 (“Changed Data Indication”, p. 19)
•
“Anybus Object (01h)” on page 45 (Instance Attribute #15)
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 18
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 27
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 12
•
“Network Object (03h)” on page 54
•
“Command Details: Map_ADI_Write_Area” on page 56
•
“Command Details: Map_ADI_Read_Area” on page 57
•
“Application Data Object (FEh)” on page 62
•
“Command Details: Remap_ADI_Write_Area” on page 68
•
“Command Details: Remap_ADI_Read_Area” on page 70
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 19
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 17
•
“Anybus Object (01h)” on page 45 (Instance Attribute #15)
•
“Command Details: Remap_ADI_Write_Area” on page 68
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 20
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 45 (Instance Attribute #4, ‘Application watchdog timeout’)
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 21
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 16
•
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 22).
See also...
- “Object Messaging” on page 29.
•
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 18
•
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 90.
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.09
Doc.Id. HMSI-168-97
Host Communication Layer 22
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.09
Doc.Id. HMSI-168-97
Host Communication Layer 23
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.09
Doc.Id. HMSI-168-97
Host Communication Layer 24
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.09
Doc.Id. HMSI-168-97
Host Communication Layer 25
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 16
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 18
3900h... 39FFh
Process Data Read Area
Read Only
See “Process Data Subfield” on page 18
3A00h... 3AFFh
(reserved)
3B00h... 3C06h
Message Write Area
3C07h... 3CFFh
(reserved)
3D00h... 3E06h
Message Read Area
Write Only
See “Object Messaging” on page 29
Read Only
See “Object Messaging” on page 29
3E07h... 3FFDh
(reserved)
-
3FFEh
Control Register
Read/Write
3FFFh
Status Register
Read Only
See “Control Register (Read/Write)” on
page 16
See “Status Register (Read Only)” on
page 16
IMPORTANT: C-programmers are reminded to declare the entire shared memory area as volatile.
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Communication Layer 26
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 16
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 16
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 16
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
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 28
“Status Register (Read Only)” on page 16
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
The Anybus State Machine 28
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 42.
See “Network Initialization (‘NW_INIT’-State)” on
page 43.
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 45).
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 27
•
“Status Register (Read Only)” on page 16
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.09
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 31
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Object Messaging 30
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. Error counters are available in the Anybus Module Object (01h).
If the network communication because of the error cannot continue, the module should enter the EXCEPTION state.
See also...
•
“Message Layout” on page 31
•
“Error Codes” on page 35
•
“State-Dependent Actions” on page 28
•
“Error Counters” on page 30
•
“Anybus Object (01h)” on page 45
5.1.4 Error Counters
The following error counters are available::
Error Counter
Abbr. Description
Discarded commands DC
Incremented if a command has been received with the R bit cleared
Discarded responses DR
Incremented if the E bit in the response is cleared, but
- the size or other data in the response (or similar) differs form what is expected, making
the response unusable
- the Source ID is not from the client sending the request..
- contains a command that was not sent by the client.
Serial reception errors SE
Incremented for
- a CRC error
- a serial error, e.g framing, overrun etc.
Fragmentation errors FE
Incremented if a fragmentation error has occurred on the serial channel.
All error counters stop counting at FFFFh.
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Object Messaging 31
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 29
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 34
Message Data Size
CmdExt[0]
CmdExt[1]
MsgData[0...n]
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Size of the MsgData[] field in bytes (up to 255 bytes).
Command-specific extension. See “Command Specification” on page 34.
Message data field.
Doc.Id. HMSI-168-97
Object Messaging 32
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 62
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Object Messaging 33
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 16
•
“Status Register (Read Only)” on page 16
•
“Anybus Object (01h)” on page 45 (Instance Attribute #8, ‘Error counters’)
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Object Messaging 34
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 44
•
“Host Application Objects” on page 60
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.09
Doc.Id. HMSI-168-97
Object Messaging 35
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
36
36
37
37
38
38
39
39
-
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.09
Doc.Id. HMSI-168-97
Object Messaging 36
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.09
Doc.Id. HMSI-168-97
Object Messaging 37
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.09
Doc.Id. HMSI-168-97
Object Messaging 38
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.09
Doc.Id. HMSI-168-97
Object Messaging 39
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.09
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 41.
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 42.
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 43.
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Initialization and Startup 41
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.09
Doc.Id. HMSI-168-97
Initialization and Startup 42
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 12
•
“The Anybus State Machine” on page 27
•
“Anybus Object (01h)” on page 45
•
“Network Configuration Object (04h)” on page 58
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 62.
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Initialization and Startup 43
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 27
•
“Network Configuration Object (04h)” on page 58
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
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 32
•
“Error Codes” on page 35
•
“Categorization of Functionality” on page 76
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.09
Doc.Id. HMSI-168-97
Anybus Module Objects 45
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.09
Doc.Id. HMSI-168-97
Anybus Module Objects 46
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.09
BOOL
ENUM
struct of:
(HMS Specific)
struct of:
UINT16 DC
UINT16 DR
UINT16 SE
UINT16 FE
See also...
- “Application Watchdog”, p. 20
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 42
See “Exception Codes”, p. 48
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 47
# 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 71
- “Command Details: Change_Language_Request” on page 75
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 17
- “Auxiliary Bit” on page 48
This attribute makes it possible to use the host
interface GPIO pins for special purposes.
See “GPIO Configuration” on page 50
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.09
Doc.Id. HMSI-168-97
Anybus Module Objects 48
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
09h
‘Safety module error’
Something is wrong with the safety module. More information can be
found in the Exception Information attribute in the Functional Safety
Object.a
0Ah
‘Insufficient application implementa- The application does not implement the functionality required for the Anytion’
bus CompactCom module to continue its operation, e.g. unsupported
object version, unimplemented attribute or service, or missing instances.
(other) (reserved)
a. The only Anybus CompactCom 30 series module to implement functional safety is Anybus CompactCom 30
PROFINET 2-Port, the Functional Safety Objects are described in the network interface appendix for that module.
See also...
•
“The Anybus State Machine” on page 27
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. 16
•
“Auxiliary Bit (STAT_AUX, CTRL_AUX)”, p. 17
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
Error
Invalid process data configuration
Invalid device address
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Description
The Process Data configuration is invalid
The selected device address is not valid for the actual network
Doc.Id. HMSI-168-97
Anybus Module Objects 49
#
03h
Error
Invalid communication settings
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Description
The selected communication settings are not valid for the actual network
Doc.Id. HMSI-168-97
Anybus Module Objects 50
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.09
Doc.Id. HMSI-168-97
Anybus Module Objects 51
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 53)
Delete (04) (See “Command Details: Delete” on page 53)
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 77.
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.09
Type
UINT8
UINT8
Array of UINT8
Description
See “Severity Levels” on page 52
See “Event Codes” on page 52
Network specific event information (optional)
Doc.Id. HMSI-168-97
Anybus Module Objects 52
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.09
Comment
Definition is network-specific; consult separate network interface appendix for further information.
Doc.Id. HMSI-168-97
Anybus Module Objects 53
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 35
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Anybus Module Objects 54
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 62
•
“Application Object (FFh)” on page 71
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.09
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 55
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.09
Doc.Id. HMSI-168-97
Anybus Module Objects 56
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 62.
See also...
•
“Command Details: Map_ADI_Read_Area” on page 57
•
“Application Object (FFh)” on page 71
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 32)
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 62 (Order Number)
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Anybus Module Objects 57
•
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 56
•
“Application Object (FFh)” on page 71
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Anybus Module Objects 58
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.09
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 59
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 14). 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 32)
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.09
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 32
•
“Anybus Module Objects” on page 44
•
“Categorization of Functionality” on page 76
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 61
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 35
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.09
Doc.Id. HMSI-168-97
Host Application Objects 62
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 56.
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.09
Doc.Id. HMSI-168-97
Host Application Objects 63
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.09
Doc.Id. HMSI-168-97
Host Application Objects 64
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
32)
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.09
Doc.Id. HMSI-168-97
Host Application Objects 65
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 62
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 66
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 62
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 67
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 62
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 68
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 54
•
“Runtime Remapping of Process Data” on page 85
•
“Example: Remap_ADI_Write_Area” on page 89
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.09
Doc.Id. HMSI-168-97
Host Application Objects 69
•
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.09
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 70
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 85).
Note 2: Handling of changed data indication (Auxiliary Bit) during a remap is described in “Changed
Data Indication” on page 19.
See also...
•
“Network Object (03h)” on page 54
•
“Runtime Remapping of Process Data” on page 85
•
“Example: Remap_ADI_Write_Area” on page 89
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.09
Doc.Id. HMSI-168-97
Host Application Objects 71
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.09
Doc.Id. HMSI-168-97
Host Application Objects 72
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 73
- “Command Details: Reset_Request” on page 74
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 14
- “Anybus Object (01h)” on page 45 (Instance attribute
#9)
- “Command Details: Change_Language_Request” on
page 75
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 73
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 72 (Attribute #1, ‘Configured’)
•
“Command Details: Reset_Request” on page 74
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 74
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 72 (Attribute #1, ‘Configured’)
•
“Command Details: Reset” on page 73
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
Doc.Id. HMSI-168-97
Host Application Objects 75
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 14
•
“Anybus Object (01h)” on page 45 (Instance attribute #9, ‘Language’)
•
“Instance Attributes (Instance #1)” on page 72 (Attribute #2, ‘Supported languages’)
Anybus CompactCom 30 Software Design Guide
Doc.Rev. 2.09
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.09
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.09
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.09
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 78
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
80
80
81
82
83
84
84
84
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.09
Doc.Id. HMSI-168-97
Timing & Performance 80
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.09
Communication
Serial 19.2kbps
(all other modes)
Max.
30
10
Unit.
s
s
Doc.Id. HMSI-168-97
Timing & Performance 81
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.09
Avg.
< 0.4
Max.
1.5
Unit.
ms
Doc.Id. HMSI-168-97
Timing & Performance 82
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.09
Doc.Id. HMSI-168-97
Timing & Performance 83
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.09
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 84
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. 83.
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. 83.
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 83.
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.09
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.09
Doc.Id. HMSI-168-97
Runtime Remapping of Process Data 86
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.09
Doc.Id. HMSI-168-97
Runtime Remapping of Process Data 87
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.09
Doc.Id. HMSI-168-97
Runtime Remapping of Process Data 88
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.09
Doc.Id. HMSI-168-97
Runtime Remapping of Process Data 89
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.09
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.09
Doc.Id. HMSI-168-97
CRC Calculation 91
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.09
Doc.Id. HMSI-168-97
CRC Calculation 92
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.09
Doc.Id. HMSI-168-97
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement