Anybus-CompactCom M40 Module-8791-Anybus CompactCom 40 Software Design Guide

Anybus-CompactCom M40 Module-8791-Anybus CompactCom 40 Software Design Guide
Software Design Guide
Anybus® CompactCom 40
Doc.Id. HMSI-216-125
Doc. Rev. 2.00
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 40 communication modules. This document does not cover any network specific features; this information is instead available as separate documents (Network Guides).
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 40 Software Design Guide
Rev 2.00
Copyright© HMS Industrial Networks AB
Sep 2015 Doc Id HMSI-216-125
Table of Contents
Table of Contents
Preface
About This Document
Related Documents.................................................................................................................................. 7
Document History ................................................................................................................................... 7
Conventions & Terminology .................................................................................................................. 8
Support....................................................................................................................................................... 8
Chapter 1
About the Anybus CompactCom
General Information ................................................................................................................................ 9
Features ...................................................................................................................................................... 9
Chapter 2
Software Introduction
Background.............................................................................................................................................. 10
The Object Model .................................................................................................................................. 11
Basics............................................................................................................................................. 11
Addressing Scheme......................................................................................................................... 11
Object Categories............................................................................................................................ 11
Standard Object Implementation..................................................................................................... 12
Network Data Exchange....................................................................................................................... 13
Diagnostics .............................................................................................................................................. 15
File System............................................................................................................................................... 16
SYNC ....................................................................................................................................................... 17
General Information....................................................................................................................... 17
Functionality .................................................................................................................................. 17
Synchronization Lock .................................................................................................................... 17
SYNC Pulse ................................................................................................................................. 18
Network Translation ..................................................................................................................... 18
Anybus CompactCom 40 SYNC Implementation ......................................................................... 18
Multilingual Support............................................................................................................................... 23
Firmware Download .............................................................................................................................. 24
Chapter 3
Host Communication Layer
General Information .............................................................................................................................. 26
Memory Map........................................................................................................................................... 27
Communication Registers ..................................................................................................................... 28
Module Capability Register ............................................................................................................ 28
LED Status Register..................................................................................................................... 28
Application Status Register ............................................................................................................ 29
Anybus CompactCom Module Status Register................................................................................ 29
Buffer Control Register ................................................................................................................... 30
Interrupt Mask Register................................................................................................................. 31
Interrupt Status Register................................................................................................................. 31
Control Register (Read/Write)....................................................................................................... 32
Status Register (Read Only) ........................................................................................................... 32
Supervised Bit (SUP) .................................................................................................................... 33
Auxiliary Bit (STAT_AUX, CTRL_AUX) ........................................................................... 33
Chapter 4
Parallel Host Communication
Flow Control........................................................................................................................................... 34
Communication Basics ................................................................................................................... 34
Anybus Event Driven Watchdog ........................................................................................................ 35
Application Event Driven Watchdog ................................................................................................. 35
Chapter 5
SPI Host Communication
General Information.............................................................................................................................. 36
SPI Frame Format.................................................................................................................................. 36
Data Definitions for the MOSI (Master Output, Slave Input) Frame............................................ 36
Data Definitions for the MISO (Master Input, Slave Output) Frame............................................ 37
Message Fragmentation......................................................................................................................... 38
SPI Error handling ................................................................................................................................. 38
Application Event Driven Watchdog ................................................................................................. 39
Chapter 6
Shift Register Host Communication
General Information.............................................................................................................................. 40
Reset ......................................................................................................................................................... 40
Chapter 7
Serial Host Communication (UART)
General Information.............................................................................................................................. 41
Chapter 8
The Anybus State Machine
General Information.............................................................................................................................. 42
State Dependent Actions ...................................................................................................................... 43
Chapter 9
Object Messaging
General Information.............................................................................................................................. 44
Basic Principles .............................................................................................................................. 44
Source ID ...................................................................................................................................... 44
Error Handling ............................................................................................................................. 44
Message Layout ...................................................................................................................................... 45
Message Segmentation........................................................................................................................... 46
Command Segmentation Procedure ................................................................................................. 46
Response Segmentation Procedure ................................................................................................... 47
Data Format ............................................................................................................................................ 48
Available Data Types.................................................................................................................... 48
Bit Fields....................................................................................................................................... 48
Handling of Array of Char (Strings).............................................................................................. 49
OCTET ....................................................................................................................................... 49
PADx .......................................................................................................................................... 49
Command Specification ........................................................................................................................ 50
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
General Information....................................................................................................................... 50
Command Codes............................................................................................................................ 51
Error Codes................................................................................................................................... 51
Get_Attribute ............................................................................................................................... 52
Set_Attribute ................................................................................................................................ 52
Create............................................................................................................................................ 53
Delete ............................................................................................................................................ 53
Reset.............................................................................................................................................. 54
Get_Enum_String ........................................................................................................................ 54
Get_Indexed_Attribute ................................................................................................................. 55
Set_Indexed_Attribute.................................................................................................................. 55
Chapter 10
Initialization and Startup
General Information.............................................................................................................................. 56
Startup Procedure................................................................................................................................... 57
Anybus Setup (‘SETUP’-State) ............................................................................................................ 59
Network Initialization (‘NW_INIT’-State) ........................................................................................ 60
Chapter 11
Anybus Module Objects
General Information.............................................................................................................................. 61
Object Revisions..................................................................................................................................... 61
Anybus Object (01h).............................................................................................................................. 62
Diagnostic Object (02h) ........................................................................................................................ 68
Network Object (03h) ........................................................................................................................... 74
Network Configuration Object (04h) ................................................................................................. 81
Anybus File System Interface Object (0Ah) ...................................................................................... 83
Functional Safety Module Object (11h).............................................................................................. 84
Chapter 12
Host Application Objects
General Information.............................................................................................................................. 87
Implementation Guidelines .................................................................................................................. 88
Energy Reporting Object (E7h)........................................................................................................... 89
Functional Safety Object (E8h) ........................................................................................................... 90
Application Data Object (FEh) ........................................................................................................... 91
Application Object (FFh).................................................................................................................... 101
Application File System Interface Object (EAh) ............................................................................ 108
Examples .................................................................................................................................... 118
Assembly Mapping Object (EBh)...................................................................................................... 122
Modular Device Object (ECh)........................................................................................................... 125
Sync Object (EEh) ............................................................................................................................... 128
Energy Control Object (F0h) ............................................................................................................. 130
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Appendix A Categorization of Functionality
Basic ....................................................................................................................................................... 135
Extended................................................................................................................................................ 135
Advanced ............................................................................................................................................... 135
Appendix B Network Comparison Chart
Appendix C Industrial Ethernet Network Comparison
Appendix D Object Overview
Appendix E Runtime Remapping of Process Data
SPI Mode............................................................................................................................................... 142
Read Process Data....................................................................................................................... 142
Write Process Data...................................................................................................................... 143
Parallel Mode, 8/16 Bits, Event Driven ........................................................................................... 144
Read Process Data....................................................................................................................... 144
Write Process Data...................................................................................................................... 145
Backwards Compatible Modes........................................................................................................... 146
Parallel mode ............................................................................................................................... 146
Serial Mode ................................................................................................................................. 148
Example: Remap_ADI_Write_Area ................................................................................................. 150
Appendix F CRC Calculation (16-bit)
General................................................................................................................................................... 151
Example ................................................................................................................................................. 151
Code Example ...................................................................................................................................... 151
Appendix G CRC Calculation (32-bit)
Example ................................................................................................................................................. 153
Code Example ...................................................................................................................................... 154
Appendix H Timing & Performance
General Information............................................................................................................................ 155
Internal Timing..................................................................................................................................... 156
Startup Delay .............................................................................................................................. 156
NW_INIT Handling ................................................................................................................. 156
Event Based WrMsg Busy Time.................................................................................................. 156
Event Based Process Data Delay ................................................................................................. 157
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
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 40 Hardware Design Guides
Anybus CompactCom 40 Network Guides (separate document for each networking system)
Author
HMS
HMS
P.2 Document History
Summary of Recent Changes (1.31... 2.00)
Change
Updated Application Object (FFh) to revision 2
Corrected footnote references in table
Changed wording in object attribute #13 in Energy Control Object (F0h)
Added appendix for Industrial Ethernet Features
Anybus object updated with new attributes
Section on virtual attributes updated
Exchanged links in footnote 2 in section Anybus Setup
Clarified description for handling of structured ADIs in the Application Data Object (FEh)
Removed command Get_ADI_Info from Application Data Object (FEh)
Added section “Notes on Parameter Access to Application Data Object (FEh)
Updated description in Application File System Interface Object (EAh)
Added important note on backwards compatibility, removed redundant text
Added runtime remapping as item in fieldbus comparison chart
Removed command Get_Profile_Instance_Numbers from Application Data Object (FEh)
Note added to description of general command Create
Application event driven watchdog information added to SPI
Added section on reset handling in stand-alone mode
Updated bit 5 of Interrupt Status Register
Added appendix with object overview
Reordered module capability register
Clarified RDPDI
Clarified application status register table, added reference to state machine description
Clarified event driven modes and data reception
Changed recommendations for support for Network Specific objects
Added instructions on what to do at download/upgrade failure
Added information on 8-bit header
Restructured descriptions of startup procedure
Corrected links
Anybus CompactCom
Doc.Rev. 2.00
Page(s)
101
48
131
138
62
66
59
91
91
94
108
9
137
91
53
39
40
31
140
28
18
29
34
88
24, 58
45
57
102, 106
Doc.Id. HMSI-216-125
About This Document P-8
Revision List
Revision
0.50
0.60
1.00
1.10
1.20
1.21
1.30
1.31
2.00
Date
2013-07-02
2013-12-20
2014-03-28
2014-05-26
2014-08-15
2014-08-26
2014-11-10
2015-02-06
2015-09-24
Author
KaD
KaD, KeL
KaD
KaD
KeL, KaD
KaD
KeL
KaD
KeL
Chapter(s)
All
All
All
8, 10, 11, C, D
1, 2, 6, 12, C, F
2
2, 3, 6, 10, 11, 12, B
2, 3, 11
1, 2, 3, 4, 5, 9, 10,
11, 12, B, C
Description
New document
General update
Major update
Major update
Major update
Major update
Major update
Minor update
Major update
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.
•
A word always consists of 16 bits.
P.4 Support
For general contact information and support, please refer to the contact and support pages at
www.anybus.com.
Anybus CompactCom
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 1
1. About the Anybus CompactCom
1.1 General Information
The Anybus CompactCom network communication module is a powerful communication solution for
demanding industrial applications. It is ideal for high performance, synchronized applications such as
servo drive systems. Typical applications are PLCs, HMIs, robotics, AC/DC and servo drives.
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.
IMPORTANT: The Anybus CompactCom 40 series is backward compatible with the Anybus CompactCom 30 series though the 40 series has significantly better performance and include more functionality than the 30 series. The 40 series is backward compatible with the 30
series in the sense that an application developed for the 30 series should be possible to use with
the 40 series products, even though minor application code changes may be necessary.
The 40 series products can thus not replace 30 series products as is.
1.2 Features
•
Hardware support for triple buffered process data
•
Black channel interface, offering a transparent channel for safety communication
•
Host interface is network protocol independent
•
Multilingual support
•
High level of integration
•
Synchronization support
•
8-bit and 16-bit parallel modes
•
SPI mode
•
Stand-alone shift register mode
•
Serial interface mode (UART)
•
Optional support for advanced network specific features
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 40 Software Design Guide
Doc.Rev. 2.00
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-216-125
Software Introduction 11
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 structured 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 subentities 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 behavior 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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 12
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 implement 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 guide.
Anybus Module Objects
The following objects are implemented in the standard Anybus CompactCom firmware:
•
Anybus Object
•
Diagnostic Object
•
Network Object
•
Network Configuration Object
•
File System Interface Object
•
Functional Safety Object
•
Network Specific Objects
Note: Exactly how much support that needs to be implemented for these objects depends on the requirements of the host application.
See also...
•
“Anybus Module Objects” on page 61
Host Application Objects
The following objects can be implemented in the host application.
•
Application Data Object (Mandatory)
•
Application Object (Mandatory)
•
Sync Object (Optional)
•
Modular Device Object (Optional)
•
Assembly Mapping Object (Optional)
•
File System Interface Object (Optional)
•
Energy Control Object (Optional)
•
Functional Safety Object (Optional)
•
Network Specific Objects (Optional)
Note: It is mandatory to implement the Application Data Object and the Application Object. The exact
implementation however depends heavily on the requirements of the host application.
See also...
•
“Host Application Objects” on page 87
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 13
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
and EtherNet/IP, ADIs are represented through a dedicated vendor specific CIP object, while on PROFIBUS, ADIs are accessed through acyclic DP-V1 read/write services. On EtherCAT and other protocols that are based on the CANopen Object Dictionary, ADIs are mapped to PDOs, defined in the
object dictionary.
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 14
•
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 29
•
“The Anybus State Machine” on page 42
•
“Network Object (03h)” on page 74
•
“Functional Safety Object (E8h)” on page 90
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 15
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 68
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 16
2.5 File System
The modules in the Anybus CompactCom 40 series have an in-built file system.
For modules not supporting FTP, this makes it possible to store firmware files in the firmware directory
using the File System Interface Object (0Ah), see firmware upgrade. No other access to or use of the file
system is possible for these modules.
For modules supporting FTP, the in-built file system can be accessed from the application and from the
network. Three directories are predefined:
•
VFS - The virtual file system that e.g. holds the web pages of the module.
•
Application - This directory provides access to the application file system through the Application File System Interface Object (EAh) (optional).
•
Firmware - Firmware updates are stored in this directory.
Important: In the firmware folder, it is not possible to use append mode when writing a file. Be
sure to use write mode only.
Anybus CompactCom
Application
Anybus
CompactCom
File system
File 1
File 2
VFS
File 1
File 2
Application
The Anybus CompactCom accesses
the application file system through the
Application File System Interface Object.
Application
File system
File A1
File A2
Directory A1
File A1:1
Firmware*
File A1:2
* The firmware folder is available to the application
for firmware download in all modules.
See also...
•
“Anybus File System Interface Object (0Ah)” on page 83
•
“Application File System Interface Object (EAh)” on page 108
•
“Firmware Download” on page 24
•
Anybus CompactCom 40 Network Guides, available at www.anybus.com
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 17
2.6 SYNC
2.6.1 General Information
Automation systems involving many devices often require a way to synchronize events. To achieve this,
the devices in the system can share a common timing signal. The Anybus CompactCom 40 supports a
SYNC mechanism via the SYNC object, that is optional to implement in the application.
The following Anybus CompactCom 40 modules support the SYNC functionality:
•
Ethernet POWERLINK
•
PROFINET-IRT
•
EtherCAT
See also:
•
See “Sync Object (EEh)” on page 128.
•
See“Application Status Register” on page 29
•
See “The Anybus State Machine” on page 42 for information of the different states of the
CompactCom module.
2.6.2 Functionality
For a successful SYNC implementation, there are a number of things to implement and consider.
The network master will configure attributes 1-3 and 7 of the SYNC object through the Anybus CompactCom module before entering state IDLE or PROCESS_ACTIVE. If the module attempts to set
attribute 1-3 in state IDLE or PROCESS_ACTIVE, the application must respond with error code 0Dh
(Invalid state). For unsupported values for the attributes, the application must respond with a suitable
error code (11h (Value too high), 12h (Value too low) or 0Ch (Value out of range)).
If there is a problem with the configuration as a whole, the application must indicate this in the application status register. See “Application Status Register” on page 29.
The application must indicate its minimum supported cycle time and the required input/output processing times in attributes 4-6 of the SYNC object at all times. The value of these attributes can be constant
or vary, reflecting the timing required for the current process data mapping.
2.6.3 Synchronization Lock
If the application needs time to lock on the SYNC signal, it must write 0001h (“Application not yet synchronized”) to the application status register. When synchronization lock has been achieved, and there
are no configuration errors, the application must write 0000h to the application status register and then
accept a transition to PROCESS_ACTIVE.
Whenever the application is not locked on the SYNC signal, and attribute 7 “Sync mode” in the SYNC
object is set to “1”, the application must write the most accurate nonzero status code to the application
status register.
See also
•
“Application Status Register” on page 29
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 18
2.6.4 SYNC Pulse
The SYNC signal, available from the module’s application connector, indicates the synchronization
event to the application by a positive pulse once every cycle. The positive edge of the SYNC pulse indicates the synchronization event.
The width of the SYNC pulse is at least 5 µs, with a maximum width of 50% of the cycle time.
The SYNC event is also available to the application as a maskable interrupt. See “Interrupt Status Register” on page 31.
2.6.5 Network Translation
Ethernet POWERLINK does not in itself support synchronization functionality. The SYNC signal
from the module is sent once for each cycle, and can as such be used by the application.
In Anybus CompactCom 40 EtherCAT, parameters and settings are stored in CoE objects 1C32h and
1C33h.
The Anybus CompactCom 40 PROFINET IRT supports both isochronous and non-isochronous
modes.
For more information, please consult the respective network guides.
2.6.6 Anybus CompactCom 40 SYNC Implementation
The Goal of SYNC
•
To set output data to different devices simultaneously. In other words, the PLC will tell all devices in the network “here is the next set of output data. Set it at your application when the SYNC
signal is sent”.
The time when the output data is set at the application is called the Output Valid Point.
•
To capture input data from different devices, simultaneously.
This time is called the Input Capture Point.
Cycle time
MI0/SYNC Signal
Input Valid
Output Valid
RDPDI
(Read Process
Data Interrupt
From Anybus)
Min: “Output
Processing”
Output Valid
Point
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Max: “Input
Processing”
Input Capture
Point
WRPD (Write Process Data)
Written to Anybus
Doc.Id. HMSI-216-125
Software Introduction 19
Handling of Output Data
Each device needs time to handle the new output data before it can be set in the application. This time
is not constant, but jitters.
The following steps have to be made by the device:
1. Wait for indication of new output data (indicated by the CompactCom module through the RDPDI (Read Process Data Interrupt1).
2. When receiving the RDPDI, read the output data from the CompactCom module.
3. Handle the new output data (prepare it so it can be used by the host application (copy the data,
process output variables, do calculations etc.)
4. Wait for the SYNC signal.
5. In case of an “Output Valid” time of 0, activate the outputs to the host application when
receiving the SYNC signal.
6. Alternatively (if the “Output Valid” time value is higher than 0) start a hardware or software timer with the positive edge of the SYNC signal to create an “output valid event”. Activate the outputs
to the host application when the timer elapses the “Output Valid” point.
Handling of Input Data
Each device needs time to capture, prepare and send new input data. This time is not constant, but jitters.
The following steps have to be made by the device:
1. Wait for the SYNC signal.
2. In case of an “Input Valid” time of 0, capture the current input process variables of the host application (as fast as possible) when receiving the SYNC signal (“Input Capture” point).
3. Alternatively (if the “Input Valid” time is higher than 0), start a hardware or software timer with
the positive edge of the SYNC signal to create an “input capture event”. Capture the current input
process data when the timer elapses the “Input Valid” point.
4. Handle the new input process data (prepare it so it can be written to the CompactCom module).
5. Write the new process input data to the CompactCom module.
1. See “Buffer Control Register” on page 30 and “Interrupt Status Register” on page 31 for more information
on RDPD (Read Process Data) and RPDPI (Read Process Data Interrupt)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 20
Host Application Programming Guidelines
To support SYNC using the Anybus CompactCom 40, there are things to consider and implement.
See “Sync Object (EEh)” on page 128 for more information.
1. Implement the SYNC Object (part 1)
7
8
Sync mode
Get/Set
Supported sync modes Get
UINT16
UINT16
This attribute is used to select synchronization mode. It enumerates the bits in attribute 8
0: Non synchronous operation. (Default value if non synchronous operation is supported)
1: Synchronous operation
2 - 65535: Reserved. Any attempt to set sync mode to an
unsupported value shall generate an error response
A list of the synchronization modes the application supports.
Each bit corresponds to a mode in attribute 7
Bit 0: 1 = Non synchronous mode supported
Bit 1: 1 = Synchronous mode supported
Bit 2 - 15: Reserved (0)
2. Implement the SYNC Object (part 2)
4
Output processing
Get
UINT32
5
Input processing
Get
UINT32
6
Min cycle time
Get
UINT32
Minimum required time, in nanoseconds, between RDPDI
interrupt and “Output valid”
Maximum required time, in nanoseconds, from “Input capture” until write process data has been completely written to
the Anybus CompactCom module
Minimum cycle time supported by the application
The time elapsed between receiving a RDPDI interrupt and when the process output variables
have been taken over by the application has to be measured. The maximum time must be provided by the application when the CompactCom 40 asks for attribute 4 “Output processing”.
The time elapsed between capturing the input process variables and when the input process data
is written to the CompactCom 40 must be measured. The maximum time must be provided by
the application when the CompactCom 40 asks for attribute 5 “Input processing”.
The host application must measure the maximum time needed to handle all process data (the
time from receiving the RDPDI interrupt until the input process data has been written to the
CompactCom 40). This value must be provided by the application when the CompactCom 40
asks for attribute 6 “Min cycle time”.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 21
3. Implement the SYNC Object (part 3)
1
2
3
Cycle time
Output valid
Input capture
Get/Set
Get/Set
Get/Set
UINT32
UINT32
Application cycle time in nanoseconds
Output valid point relative to SYNC events, in nanoseconds
UINT32
Default value: 0
Input capture point relative to SYNC events, in nanoseconds
Default value: 0
These three attributes can all be set by the CompactCom 40.
Using attribute 1, “Cycle time”, the CompactCom 40 informs the host application about the real
used cycle time (by the Set_Attribute command). This value must be evaluated by the host application and refused if not acceptable (not suitable, e.g. in conflict with other cyclic tasks of the
host application or not within the defined range). If refused, the CompactCom 40 will report this
to the PLC.
Attributes 2 and 3 reflect functionality present on some networks (e.g. EtherCAT, SERCOS and
PROFINET), where the input and output valid points can be fine-tuned. This can be used to
offset one device relative to another by a small amount of time. To support values other than
zero (0), timers will have to be implemented in the application.
4. Implement the Application Status Register
See “Application Status Register” on page 29 for more information.
5. Do the right thing when receiving an RDPDI and a SYNC signal
When receiving an RDPDI interrupt, read the output process data from the CompactCom, prepare it (handle and assign it to process output variables) so that it can be activated when receiving
a SYNC signal.
When receiving a SYNC signal, do the following:
1. Take over the output process variables to the application immediately.
2. Capture all input process variables immediately.
3. Prepare and assign the input process variables to the input process data.
4. Write the input process data to the CompactCom.
Steps 2, 3 and 4 must be done within the time specified by attribute 5 “Input processing” (in relation to the Input Capture time).
Steps 1 and 2 assumes Output Valid and Input Capture to be zero (0).
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 22
The Easiest Realization of a Synchronous Application
Cycle time
MI0/SYNC Signal
Max: “Input
Processing”
Output Valid Point
and
Input Capture Point
WRPD Written to
Anybus
The following steps show how to create a very simple synchronous application.
1. Set up an interrupt routine triggered by the positive SYNC edge. Disable the RDPDI interrupt.
2. In the SYNC interrupt routine:
- Sample the input data and write it to the CompactCom.
- Read the output data from the CompactCom and start using it immediately.
3. For this application, attribute 4 “Output processing” in the SYNC object should be set to zero
(0). No measurement needed.
4. Attribute 5 “Input processing” must be determined. It can probably be hard coded to a fixed value, but this is application specific and dependent of the complexity of the SYNC interrupt routine
and the application processor performance.
5. For attributes 2 “Output valid” and 3 “Input capture”, only the value zero (0) will be accepted
by the application.
This simple step-by-step method will work fine in all applications where the process data handling can
be made fast and simple.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 23
2.7 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 101
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 24
2.8 Firmware Download
Download and upgrade of network communication firmware for a specific fieldbus or industrial network can be performed in different ways, depending on which Anybus CompactCom 40 that is to be
upgraded.
Using Firmware Manager II
This tool is available without cost from the HMS website, www.anybus.com. It can be used to download
new firmware for any Anybus CompactCom 40.
Using the tool, perform the following steps to download new firmware to the module.
1. Connect a computer with the Firmware Manager II software installed to the network containing
the module.
2. Start the Firmware Manager II tool.
3. Scan the network and find the module.
4. Click the Firmware Repository icon in the menu, to open the Firmware Repository window.
Drag the firmware folder into the window to add the new firmware to the repository. Close the
Firmware Repository window.
5. In the scan window, under the “Available Networks” tab, select the appropriate firmware for the
module. Click the “Change Network” button. A confirmation window will appear. Clicking
“Yes” will start the download of the new firmware. Please make sure that download is completely
finished before continuing.
6. After download, a restart of the module is needed to install the new firmware. If the application
allows it, it is possible to restart the module via the “Restart Module” button in the Firmware
Manager II tool. If the application does not allow restart from the network, a manual restart of
the module is needed.
For more information, see the help file in the Firmware Manager II software.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Software Introduction 25
Using the internal file system
The internal file system can be accessed via the File System Interface Object. Interfacing this object from
the host application, makes it possible to store the new firmware in the /firmware directory in the internal file system. The next time the module is started the firmware will be upgraded. After the firmware is
installed, the firmware file is deleted from the /firmware directory.
Important: In the firmware folder, it is not possible to use append mode when writing a file. Be sure to
use write mode only.
See also ...
•
“Application File System Interface Object (EAh)” on page 108
Using FTP
If the module supports FTP, this can be used to access the file system and upload the new firmware
directly to the /firmware directory. The next time the module is started the firmware will be upgraded.
After the firmware is installed, the firmware file is deleted from the /firmware directory.
See also ...
•
“Application File System Interface Object (EAh)” on page 108
IMPORTANT: When the Anybus CompactCom 40 is restarted after a firmware download,
the application must wait for the installation to finish before initialization is started. The Anybus CompactCom is protected against power failure during download and/or installation and
will recover upon restart.
• If download through e.g. Firmware Manager or FTP, is interrupted, please restart
the firmware download process from the beginning.
• To install the new firmware after download is completed, reset the Anybus CompactCom. If the installation of the new firmware is interrupted, e.g. due to power loss,
please restart the Anybus CompactCom 40. The installation process will automatically
start from the beginning and the new firmware will be installed without any further action.
For more information see, “Startup Procedure” on page 57.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 3
3. Host Communication Layer
3.1 General Information
The main communication layer is used by the 8-bit/16-bit parallel modes and the SPI mode. It is divided
into process data read/write areas, message data read/write areas and a number of control registers.
Below is a detailed description of the memory map and the different control registers.
Communication Basics
The communication between the host and the Anybus CompactCom module is simple, fast and flexible.
The host can read or write process data at any time. It can check for incoming data via the buffer control
register or by enabling appropriate interrupts via the interrupt mask register.
ATTENTION: Attempts to access reserved registers will produce unpredictable results. Attempts to write to a read-only register will produce unpredictable results. Reserved bits shall
be written with zeros (0). Reading reserved bits returns undefined values.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 27
3.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 interface has been implemented.
Note: The memory area is not available during reset.
Byte Address
Word Address
Area
0000h - 0FFFh
0000h - 07FFh
Process data, write areab
1000h - 1FFFh
0800h - 0FFFh
2000h - 25FFh
2600h - 2FFFh
3000h - 35FFh
3600h - 37FFh
3800h - 38FFh
1000h - 12FFh
1300h - 17FFh
1800h - 1AFFh
1B00h - 1BFFh
1C00h - 1C7Fh
Process data, read areab
Message data, write area
Reserved
Message data, read area
Reserved
3900h - 39FFh
1C80h - 1CFFh
3A00h - 3AFFh
3B00h - 3C06h
1D00h - 1D7Fh
1D80h - 1E03h
3C07h - 3CFFh
3D00h - 3E06h
1E04h - 1E7Fh
1E80h - 1F03h
3E07h - 3FE7h
3FE8h - 3FEFh
1F04h - 1FF3h
1FF4h - 1FF7h
3FF0h - 3FF1h
3FF2h - 3FF3h
3FF4h - 3FF5h
3FF6h - 3FF7h
3FF8h - 3FF9h
3FFAh - 3FFBh
3FFCh - 3FFDh
3FFEh
1FF8h
1FF9h
1FFAh
1FFBh
1FFCh
1FFDh
1FFEh
1FFFh
3FFFh
Bytes Accessa Notes
4096 R/W
Applicable for all
protocols
4096 R
1536
2560
1536
512
256
R/W
R
R/W
256
R
256
263
R/W
249
263
R
479
8
R
Control registerc
2
2
2
2
2
2
2
1
R
R
R/W
R
R/W
R/W
R/W
R/W
Status registerc
1
R
Process data, write areac
Process data, read areac
Reserved
Message data, write areac
Reserved
Message data, read areac
Reserved
d
Current network time
Module capability register
LED status register
Application status register
Anybus CompactCom module status register
Buffer control register
Interrupt mask register
Interrupt status register
Applicable for
the event driven
protocol
Applicable for
the half duplex
protocol
a. Seen from the host.
b. This is the total size of the area. The actual size depends on the network. For network specific process area sizes,
see “Network Comparison Chart” on page 136.
c. These areas and registers are used for backward compatibility with the Anybus CompactCom 30 series.
d. If an application is to use “current network time”, the network time must first be sampled. This is performed by writing to this register. The register will be updated with the actual value from the network, which then can be read by
the application.
IMPORTANT: C-programmers are reminded to declare the entire shared memory area as volatile.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 28
3.3 Communication Registers
3.3.1 Module Capability Register
The module capability register contains one of the values below, indicating module type. The application
should determine the module type by examining the low byte only. The high byte is reserved for future
use.
Value
0000h
000Bh
0101h
0202h
0303h
0404h
0505h
0606h - 0909h
0A0Ah
0C0Ch - 0F0Fh
Module Type
Active Anybus CompactCom 30 series module, supporting the half duplex protocol only
8 bit parallel and serial modes
Active Anybus CompactCom 40 series module, supporting the event driven as well as the half
duplex protocol
8 bit/16 bit parallel, shift register, SPI and serial modes
Passive RS232
Passive RS422
Passive USB
(reserved)
Passive Bluetooth
(reserved)
Passive RS485
(reserved)
Note: All passive modules belong to the Anybus CompactCom 30-series. There are no passive modules
in the Anybus CompactCom 40-series.
3.3.2 LED Status Register
This register reflects the LED status, as represented by the value of the instance attribute LED status
(#13) in the Anybus Object. See “Anybus Object (01h)” on page 62 for more information.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 29
3.3.3 Application Status Register
The application status register is primarily used in SYNC applications. It is used in applications where
the network in question supports the ability to indicate critical process data errors to the master. If this
is supported, the Anybus CompactCom module will accept and handle the below listed status codes
written by the application.
This register is optional to use. For networks which do not support indications of critical process data
errors, the module will ignore this register.
Status Code Error
0000h
No error
0001h
0002h
Not yet synchronized
Sync configuration error
0003h
0005h
Read process data
configuration error
Write process data
configuration error
Synchronization loss
0006h
Excessive data loss
0007h
Output error
0004h
Descriptiona
Ready for transition to state PROCESS_ACTIVE
(Default)
Not ready for transition to state PROCESS_ACTIVE
A problem with the current attribute values in the Sync object prevents
the transition to state PROCESS_ACTIVE
A problem with the current read process data mapping prevents the transition to state PROCESS_ACTIVE
A problem with the current write process data mapping prevents the transition to state PROCESS_ACTIVE
The application has lost synchronization lock
If the Anybus CompactCom is in the state PROCESS_ACTIVE, it will
change to a lower state
The application has detected a significant loss of process data from the
network
If the Anybus CompactCom is in the state PROCESS_ACTIVE, it will
change to a lower state
Application malfunction
If the Anybus CompactCom is in the state PROCESS_ACTIVE, it will
change to a lower state
a. The Anybus state machine is described in “The Anybus State Machine” on page 42.
3.3.4 Anybus CompactCom Module Status Register
This register contains the current Anybus CompactCom module state, and a supervised bit indicated by
the Anybus CompactCom module. The Anybus state machine is described in “The Anybus State Machine” on page 42
Bit
0-2
3
Name
S[0..2]
Supervised bit
4 - 15
-
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
The current Anybus CompactCom module state
1 = Supervised by another network device
0 = Not supervised by another network device
See “Supervised Bit (SUP)” on page 33.
Reserved (0)
Doc.Id. HMSI-216-125
Host Communication Layer 30
3.3.5 Buffer Control Register
This register is used by the application to control the event driven communication with the Anybus
CompactCom module.
By writing to this register, it is possible to trigger appropriate events. Write “1” to trigger bits, and “0”
to leave bits unaffected.
Reading this register gives the current status of the different memory areas.
Bit
0
Name
1
When the module has updated the read process data, this bit will be read as ‘1’.
RDPDa
(Read Process Data) The application shall write ‘1’ to this bit to request the latest read process data. By
doing this the bit is cleared.
a
This bit is read as ‘1’ when the write message area is occupied.
WRMSG
(Write Message Data) This bit is cleared by the module when the write message area is available for a
new message.
When the application sends a write message to the module, it shall write ‘1’ to this
bit.
The application is only allowed to write to the write message area while this bit is ‘0’.
2
3
4
a
WRPD
(Write Process Data)
Note: it is only allowed to write command messages when the ANBR bit is also set.
This bit will be read as ‘1’ when the module has posted a new read message.
RDMSG
(Read Message Data) The application writes ‘1’ to this bit to acknowledge the message. By doing this the
bit is cleared.
The application is only allowed to read the read message area while this bit is ‘1’.
ANBR
This bit is set to ‘1’ when the module is ready to receive a new command message.
(Anybus Ready)
The application is only allowed to send command messages while this bit is ‘1’.
a
5
APPR
(Application Ready)
6
APPRCLR
(Application Ready
Clear)
-
7 - 15
Description
The application shall write ‘1’ to this bit when new data has been written.
This bit can only change from ‘1’ to ‘0’ while WRMSG is ‘1’.
It can change from ‘0’ to ‘1’ at any time.
The application writes ‘1’ to this bit when it is ready to receive a new command message.
The module will only send command messages while this bit is ‘1’.
Use APPRCLR to set this bit to ‘0’.
The application can write ‘1’ to this bit to clear the APPR bit. This is only allowed
when RDMSG is ‘1’.
Reserved
a. For more information about how to implement and use this bit, see“Communication Basics” on page 34.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 31
3.3.6 Interrupt Mask Register
This register makes it possible for the application to enable or disable individual interrupts, according to
the table below.
Bit
0
Name
RDPDIEN
1
RDMSGIEN
2
WRMSGIEN
3
ANBRIEN
4
STATUSIEN
5
6
7 - 15
SYNCIEN
-
Description
Set this bit to ‘1’ to enable interrupt for when the RDPD bit in the buffer control register
transitions from ‘0’ to ‘1’.
Set this bit to ‘1’ to enable interrupt for when the RDMSG bit in the buffer control register transitions from ‘0’ to ‘1’.
Set this bit to ‘1’ to enable interrupt for when the WRMSG bit in the buffer control register transitions from ‘1’ to ‘0’.
Set this bit to ‘1’ to enable interrupt for when the ANBR bit in the buffer control register
transitions from ‘0’ to ‘1’.
Set this bit to ‘1’ to enable interrupt for an Anybus CompactCom module status register
change.
Reserved
Set this bit to ‘1’ to enable interrupt for a SYNC event.
Reserved
3.3.7 Interrupt Status Register
The module indicates the pending interrupts in this register, according to the table below.
Bit
0
Name
RDPDI
1
RDMSGI
2
WRMSGI
3
ANBRI
4
STATUSI
5
PWRI
6
SYNCI
7 - 15
-
Description
This bit is set to ‘1’ when RDPD in the buffer control register transitions from ‘0’ to ‘1’.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ when RDMSG in the buffer control register transitions from ‘0’ to ‘1’.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ when WRMSG in the buffer control register transitions from ‘1’ to ‘0’.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ when ANBR in the buffer control register transitions from ‘0’ to ‘1’.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ on an Anybus CompactCom module status register change.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ when the module is ready to start communication after a power-up
or a hardware reset.
The application shall write ‘1’ to this bit to set it to ‘0’.
This bit is set to ‘1’ on each SYNC event.
The application shall write ‘1’ to this bit to set it to ‘0’.
Reserved
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 32
3.3.8 Control Register (Read/Write)
Only used for the half duplex (ping/pong) protocol.
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.
CTRL_R
If set, the host application is ready to receive a new command.
CTRL_AUX (ignored)
(reserved, set to zero)
3.3.9 Status Register (Read Only)
Only used for the half duplex (ping/pong) protocol.
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.
STAT_R
If set, the Anybus module is ready to process incoming commands.
STAT_AUX See “Auxiliary Bit (STAT_AUX, CTRL_AUX)” on page 33.
SUP
Value:Meaning:
0: Module is not supervised.
1: Module is supervised by another network device.
S[0... 2]
See “Supervised Bit (SUP)” on page 33.
These bits indicates the current state of the module (see also “The Anybus State Machine” on page 42).
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Communication Layer 33
3.3.10 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 32 (bit 3, ‘SUP’)
•
“Anybus CompactCom Module Status Register” on page 29 (bit 3, ‘Supervised bit’)
3.3.11 Auxiliary Bit (STAT_AUX, CTRL_AUX)
The Anybus CompactCom module ignores the CTRL_AUX bit.
The module will set the STAT_AUX bit if new process data has been received from the network since
the last telegram.
See also...
•
“Control Register (Read/Write)” on page 32 (bit 4, ‘CTRL_AUX’)
•
“Status Register (Read Only)” on page 32 (bit 4, ‘STAT_AUX’)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 4
4. Parallel Host Communication
4.1 Flow Control
The following only applies to the event driven modes (full duplex modes). For information about the
half duplex mode, see “Serial Host Communication (UART)” on page 41.
Data can be read or written from either the host or the Anybus CompactCom module, at any point and
in any order. Communication can be fully controlled by writing to and reading from the buffer control
register, or it can be achieved by enabling interrupts for appropriate events using the interrupt mask register. If enabled, an interrupt is generated each time the module has made new data available.
See “Buffer Control Register” on page 30 and “Interrupt Mask Register” on page 31.
4.1.1 Communication Basics
When using the parallel host interface, data is exchanged via the shared memory area. For more information, see “Memory Map” on page 27.
Data Transmission
To write process data:
1. Write data to the write process data memory area. The area currently mapped by ADIs for process data must be refilled with new data.
2. Finalize the write process by writing “1” to bit 0 (WRPD) in the buffer control register.
To write message data:
1. Read bit 2 (WRMSG) in the buffer control register.
- If it is “0”, the area is available for new message data.
- If it is “1”, the area is occupied and is not yet available to receive new message data.
2. Write data to the write message data memory area.
3. Finalize the write process by writing “1” to bit 2 (WRMSG) in the buffer control register.
Data Reception
For the latest read process data:
1. Write “1” to bit 1 (RDPD) in the buffer control register, to gain access to the process data.
2. Read the latest read process data from the read process data area.
For the latest message data:
1. Read bit 3 (RDMSG) in the buffer control register.
- If it is “0”, no new message data has been posted.
- If it is “1”, there is a new message in the read message data area.
2. Read the latest message data from the read message data area.
3. Write “1” to bit 3 (RDMSG) in the buffer control register.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Parallel Host Communication 35
4.2 Anybus Event Driven Watchdog
It is possible for the host to establish whether or not the Anybus CompactCom module is working properly by periodically measuring the message response time. If this time exceeds a specified value, the module can be assumed to be malfunctioning. The host can then enter an application specific safe state, reset
the module, or take similar actions.
It is strongly recommended to have at least a rudimentary watchdog mechanism, to be able to restart the
module if needed.
4.3 Application Event Driven Watchdog
If desired by the application, an application watchdog timeout can be enabled within the Anybus CompactCom module. When this is enabled, the module will assume that the application is not working
properly if the time between two write process data buffer updates exceeds the watchdog timeout selected by the application.
The application watchdog timeout is specified in the Anybus Object, instance attribute #4 (Application
watchdog timeout). See “Anybus Object (01h)” on page 62.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 5
5. SPI Host Communication
5.1 General Information
The SPI (Serial Peripheral Interface) is a serial, full duplex protocol. It is a master/slave mode, where
the host acts as the master and the Anybus CompactCom module as the slave.
Each byte in the SPI frame is transmitted with the most significant bit first, but the byte order is little
endian. The least significant byte is transmitted first. Errors are detected by a 32-bit CRC.
5.2 SPI Frame Format
4 Words
MOSI
SPI
CTRL
Reserv
ed
MSGLEN
MISO
Reserv
ed
Reserv
ed
LEDSTAT
APP
STAT
PDLEN
ANB
STAT
MSG LEN Words
PD LEN Words
2 Words
1 Word
WrMsgField
WrPdField
CRC
PADDING
INT
MASK
SPI
STAT
NETTIME
5 Words
RdMsgField
MSG LEN Words
RdPdField
CRC
PD LEN Words
2 Words
5.2.1 Data Definitions for the MOSI (Master Output, Slave Input) Frame
SPI MOSI Frame Format
Byte
Name
0
SPI CONTROL
1
(reserved)
2-3
MSGLEN
4-5
PDLEN
6
APPSTATUS
7
INTMASK
MSGLEN words
MSGFIELD
PDLEN words
WRPDFIELD
2 words
CRC
1 word
PADDING
Description
SPI control byte, see SPI Control Byte table below.
The size of the message field, in words.
The size of the write process data field, in words.
Application status, see “Application Status Register” on page 29.
Interrupt mask, see “Interrupt Mask Register” on page 31.
Message field.
Write process data field.
Dummy data.
SPI Control Byte
Bit
Name
Description
0
WRPD VALID If this bit is set, the Anybus CompactCom module will act on the content of the write
process data field.
If this bit is not set, the module will ignore the content of the write process data field.
1-2
CMDCNT
These two bits indicate the number of commands the application is prepared to
receive.
3
4
5-6
M
LAST FRAG
-
00 = The application is not prepared to receive any commands.
01 = The application is prepared to receive at least one command.
10 = The application is prepared to receive at least two commands.
11 = The application is prepared to receive at least three commands.
If set, the message field contains a message.
If set, the message field contains the last fragment of a message.
Reserved, set to 0
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
SPI Host Communication 37
SPI Control Byte
Bit
Name
7
TOGGLE
Description
For the initial transmission, this bit shall be set to “1”.
This bit shall toggle for every SPI transfer.
Note: When a CRC error has been detected, this bit shall NOT be toggled to indicate
a retransmission.
5.2.2 Data Definitions for the MISO (Master Input, Slave Output) Frame
SPI MISO Frame Format
Byte
Name
0-1
(reserved)
2-3
LEDSTATUS
4
ANBSTATUS
5
6-9
MSGLEN words
PDLEN words
2 words
Description
LED state, see “LED Status Register” on page 28.
Anybus CompactCom module state, see “Anybus CompactCom
Module Status Register” on page 29.
SPI status, see SPI status byte table below.
These 4 bytes hold the lower 32 bits of the network time.
Message field.
Read process data field.
-
SPISTATUS
NETTIME
MSGFIELD
RDPDFIELD
CRC
SPI Status Byte
Bit
Name
Description
0
WRMSG FULL If set, the write message buffer is full. If there was a message in the MOSI frame, it
has been ignored by the Anybus CompactCom module and must be sent again.
1-2
CMDCNT
Important: The toggle bit must still be toggled, in this case.
These two bits indicate the number of commands the module is prepared to receive.
00 = The module is not prepared to receive any commands.
01 = The module is prepared to receive at least one command.
10 = The module is prepared to receive at least two commands.
11 = The module is prepared to receive at least three commands.
3
4
5
M
LAST FRAG
NEW PD
6
7
Reserved
Reserved
When WRMSG FULL is set, the module has not yet parsed the latest “write message”. As a consequence, the CMDCNT may not reflect the last command. Applications that wish to send several consecutive commands without waiting in between
must take this into consideration when evaluating the CMDCNT.
If set, the message field contains a message.
If set, the message field contains the last fragment of a message.
If set, the RDPDFIELD contains data that has been updated from the network since
the last SPI transfer. Note that “updated” data does not necessarily mean “changed
data”.
If not set, the RDPDFIELD contains the same data as in the last SPI transfer.
Note that even SPI transfers with corrupt CRCs may clear this bit.
-
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
SPI Host Communication 38
5.3 Message Fragmentation
The SPI protocol supports message fragmentation.
To disable fragmentation, just set the MSGLEN field to a value large enough to fit the maximum size
of the messages that the host will send. The M and the LAST FRAG bits shall be set for every message.
To enable fragmentation, set the MSGLEN field to a value smaller than the maximum message size. The
M bit shall be set for all SPI frames containing a message or message fragment. The LAST FRAG bit
indicates that the current fragment is the last fragment of a message.
5.4 SPI Error handling
Errors are detected using a 32-bit CRC. The position of the CRC in the MISO and the MOSI frames is
shifted. If the Anybus CompactCom module detects an error in the MOSI frame, it will send an invalid
CRC to the host.
When the host detects a CRC error in the MISO frame, it shall ignore the contents and retransmit the
original frame. The retransmitted frame must keep the TOGGLE bit, the M bit, the LAST FRAG bit,
as well as the MSGLEN and the MSGFIELD, set to the same values as the original frame. All other
fields may contain new values.
The image below depicts a normal scenario. The host sends the SPI frame cyclically, toggling the toggle
bit in the SPI control byte each time.
In case of a reception error on the MISO line, the host will detect this using the MISO CRC and perform
a retransmission. Retransmissions are indicated by NOT toggling the toggle bit in the SPI control byte
of the MOSI header.
This scenario is depicted in the image below.
In case of a reception error on the MOSI line, the Anybus CompactCom will detect this using the MOSI
CRC. The Anybus will respond with destroying the MISO CRC, which will result in a retransmission of
the SPI frame from the host.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
SPI Host Communication 39
5.5 Application Event Driven Watchdog
If desired by the application, an application watchdog timeout can be enabled within the Anybus CompactCom module. When this is enabled, the module will assume that the application is not working
properly if the time between two write process data buffer updates exceeds the watchdog timeout selected by the application.
The application watchdog timeout is specified in the Anybus Object, instance attribute #4 (Application
watchdog timeout). See “Anybus Object (01h)” on page 62.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 6
6. Shift Register Host Communication
6.1 General Information
The Anybus CompactCom 40 can be used stand-alone, with no host processor. Process data is communicated to shift registers on the host. The Anybus CompactCom supports up to 32 registers in each direction, for a total of 256 bits of data.
Input Byte 0
Input Byte 1
Input Byte 2
Input Byte n-1
Input Byte 31
INPUT SHIFT
REGISTER 1
INPUT SHIFT
REGISTER 2
INPUT SHIFT
REGISTER 3
INPUT SHIFT
REGISTER n
INPUT SHIFT
REGISTER 32
OUTPUT SHIFT
REGISTER 1
OUTPUT SHIFT
REGISTER 2
OUTPUT SHIFT
REGISTER 3
OUTPUT SHIFT
REGISTER n
OUTPUT SHIFT
REGISTER 32
Output Byte 0
Output Byte 1
Output Byte 2
Output Byte n-1
Output Byte 31
The Anybus CompactCom 40 will automatically detect the number of connected input and output shift
registers. Every shift register will be represented by one UINT8 ADI. The input ADIs will be named
“Input 0”, “Input 1”, etc. The output ADIs will be named “Output 0”, “Output 1”, etc.
The Anybus CompactCom 40 will always try to retrieve network specific attributes from a host application. As this is not possible in stand-alone mode, a virtual attribute list, stored in nonvolatile memory,
will be used instead, see “Virtual Attributes” on page 66.
6.2 Reset
In stand-alone mode there is no application available to handle a reset request from the network. The
reset will be handled by the Anybus CompactCom and the module will reset automatically.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 7
7. Serial Host Communication (UART)
7.1 General Information
This mode is supported for backward compatibility with the Anybus CompactCom 30, and
should not be used for pure Anybus CompactCom 40 applications.
On the serial host interface, telegrams are transmitted through a common asynchronous serial interface.
The baud rate is determined by certain signals on the host interface connector of the module; consult
the Anybus CompactCom 40 Hardware Design Guide for further information.
For more information on the serial host communication mode, please consult the Anybus CompactCom
30 Software Design Guide.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 8
8. The Anybus State Machine
8.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 43
“Status Register (Read Only)” on page 32
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
The Anybus State Machine 43
8.2 State Dependent Actions
The expected actions for each state are listed below.
State
SETUP
Description
Anybus CompactCom Setup in progress.
The module may not send commands to the
application in this state.
NW_INIT
The Anybus CompactCom module is currently
performing network-related initialization 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 59.
See “Network Initialization (‘NW_INIT’-State)” on
page 60.
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
This state is unrecoverable, i.e. the module
Object (01h)” on page 62).
must be restarted in order to be able to
exchange network data.
When done, reset the Anybus module.
See also...
•
“General Information” on page 42
•
“Status Register (Read Only)” on page 27
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 9
9. Object Messaging
9.1 General Information
9.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 CompactCom 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
9.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 45
9.1.3 Error Handling
When a command for some reason cannot be processed, the receiver is still obliged to provide a response. In such case, an error shall be flagged in the header of the response message, together with an
appropriate error code in the message data field.
The command initiator must then examine the response to see whether it is a successful response to the
command or an error message.
See also...
•
“Message Layout” on page 45
•
“Error Codes” on page 51
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 45
9.2 Message Layout
An object message consists of an 12 byte header followed by message related data.
Offset
0-1
2-3
4
5
6
7
8
9
10
11
12...n
Contents
Description
b7 b6 b5 b4 b3 b2 b1 b0
Message Data Size
Size of the MsgData[] field in bytes (up to 1524 bytes)
(reserved)
Source ID
See “Source ID” on page 44
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 Codes” on page 51
(reserved)
CmdExt[0]
CmdExt[1]
MsgData[0-n]
Command-specific extension. See “Command Specification” on page 50
Message data field
If the Anybus CompactCom 40 is used in a Anybus CompactCom 30 application, an 8 byte header will
have to be used. Please consult the Anybus CompactCom 30 Software Design Guide for information.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 46
9.3 Message Segmentation
The maximum message size supported by an object message is 1524 bytes. Some object services, however, must support larger messages. In order to support this, the Anybus CompactCom module supports
a fragmentation protocol. To avoid confusion with the fragmentation protocol used for serial telegrams,
this protocol is called a segmentation protocol.
9.3.1 Command Segmentation Procedure
When a message is segmented, the initiator of the message sends the same command header multiple
times. For each message, the data field is exchanged for the next segment of data.
Command Details
CmdExt[1]
Command Segment Bits
Bit 0: FS (first segment)
Bit 1: LS (last segment)
Bit 2: AB (abort)
Bit 3-7: Reserved (0)
Response Details
CmdExt[1]
Response Segment Bits
Bit 0-7: Reserved (0)
When sending segmented commands, follow the procedure below:
•
For the first element, the FS bit shall be set.
•
For the subsequent elements, the FS and LS bits shall be cleared (0).
•
For the last element, the LS bit shall be set. (For single frame commands (< 1524 bytes) both the
FS and the LS bits shall be set).
The command receiver shall send a response (ACK/NACK) for each segment, indicating if the segment
was accepted or not. In case of a NACK, the segment will be discarded. The segmentation will not be
terminated, however, so earlier accepted segments remain in the segmentation buffer.
The response (ACK/NACK) to the last segment contains the actual result of the operation.
The command initiator may at any time abort the operation by sending a message with the AB bit set.
This shall result in that the segmentation buffer is flushed.
To determine if a command is the same as a previous one, the following shall be checked:
•
Destination object
•
Instance number
•
Command number
•
Command extension 0 (CmdExt[0])
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 47
9.3.2 Response Segmentation Procedure
When a response message is segmented, the initiator of the message requests the next segment by sending the same command multiple times. For each message, the data field is exchanged for the next segment of data.
Command Details
CmdExt[1]
Command Segment Bits
Bit 0: Reserved (0)
Bit 1: Reserved (0)
Bit 2: AB (abort)
Bit 3-7: Reserved (0)
Response Details
CmdExt[1]
Response Segment Bits
Bit 0: FS (first segment)
Bit 1: LS (last segment)
Bit 2-7: Reserved (0)
When sending segmented responses, follow the procedure below:
•
For the first element, the FS bit shall be set.
•
For the subsequent elements, the FS and LS bits shall be cleared (0).
•
For the last element, the LS bit shall be set. (For single frame commands (< 1524 bytes) both the
FS and the LS bits shall be set).
If the LS bit is not set in a response, the command initiator requests the next segment by sending the
same command again.
The command initiator may at any time abort the operation by sending a request/response with the AB
bit set. This shall result in that the segmentation buffer is flushed.
To determine if a command is the same as a previous one, the following shall be checked:
•
Destination object
•
Instance number
•
Command number
•
Command extension 0 (CmdExt[0])
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 48
9.4 Data Format
9.4.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
00000000... 11111111
Yes
Yes
0000000000000000...
1111111111111111
00000000 00000000 00000000
00000000... 11111111 11111111
11111111 11111111
0... +255
Yes
Yes
Yes
Yes
Yes
No
-263... +(263-1)
No
Yes
No
0... +(264-1)
32 Floating point (IEC 60559) ±1.17549435E-38... ±3.40282347E+38 No
0-16 Bit fields of size 0 - 16
N/A
Yes
used for padding
1-7 Bit fields of size 1-7
[0...1]... [0000000...1111111]
Yes
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)cd 0... +255
0... +255
Enumeratione
9
f
BITS8
8
8 bit bit field
10
BITS16f
16
16 bit bit field
11
BITS32f
32
32 bit bit field
Undefined 8 bit data
OCTETf 8
13-15
(reserved)
16
SINT64 64 Signed 64 bit integer
12
17
UINT64
18
FLOAT
32-48 PADxf
65-71 BITxf
64
-231... +(231-1)
0... +255
0... +65535
Unsigned 64 bit integer
Yes
Yes
Yes
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. Data of type ENUM are enumerations, limited to a consecutive range of values starting at zero.
f. This data type is only supported by Anybus CompactCom 40 modules.
9.4.2 Bit Fields
The bit field types should be used for parameters where each bit, or group of bits, contains individual
meaning. Typical examples include control/status words or digital I/O.
Bit field parameters will be translated to network specific data types suitable for digital I/O or control/
status words.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 49
BITSx
The BITSx data types (BITS8, BITS16, and BITS32) consist of even data byte sizes and must be byte
aligned. They are handled in the same way as other multibyte data types with regard to byte order.
BITx
The BITx data types (BIT1-BIT7) are packed with bits aligned, and may be placed over byte boundaries.
The type code (65-71) of BITS1-BITS7 may be divided into the 5 most significant bits as specifier (always 01000) and the 3 least significant bits as bit counter, with valid values from 1 to 7 for the bit counter
field.
9.4.3 Handling of Array of Char (Strings)
Note: Readable strings can be represented in ADIs in two different ways. Either as an array of CHAR
or as a string variable. The recommended way is to represent readable strings in ADIs as a variable using
the attribute “Number of subelements” in the Application Data Object (FEh), i.e. a string variable that
consists of one element with several subelements. This section is mainly applicable when using arrays of
CHAR in ADIs. Both these types of strings are hereafter named string.
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 91
9.4.4 OCTET
The OCTET type is used for undefined data of byte size. In ADIs, elements of type OCTET may have
subelements.
9.4.5 PADx
The PADx types consist of 17 types, from PAD0 to PAD16. PADx variables are packed with bit alignment and might pass any byte boundaries. The value of a PADx variable is irrelevant and might be
skipped completely in a network specific way.
The type code (32-48) might be divided into the 3 most significant bits as specifier (always 001) and the
5 least significant bits as bit counter, with valid values from 0 to 16 for the bit counter field.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 50
9.5 Command Specification
9.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 61
•
“Host Application Objects” on page 87
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 51
9.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
52
52
53
53
54
54
55
55
-
9.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
Invalid CmdExt[1]
Attribute not settable
Attribute not gettable
Too much data
Not enough data
Out of range
0Dh
0Eh
0Fh
10h
11h
12h
13h... FEh
FFh
Invalid state
Out of resources
Segmentation failure
Segmentation buffer overflow
Value too high
Value too low
(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 settable
The requested attribute is not gettable
Too much data in message data field
Not enough data in message data field
A specified value is out of range
Use this error code only when 11h or 12h cannot be used
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 written data is too high
The written data is too low
The object returned an object specific error code. Additional details may or
may not be included in the message data field (MsgData[0...n])
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 52
9.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
9.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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 53
9.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)1
•
Response Details
MsgData[0]
MsgData[1]
The number of the created Instance (low byte)
The number of the created Instance (high byte)
9.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.
1. Not all objects have any specific details for this command. If there are any object specific details, they are
found in the description of the object in question.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 54
9.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)
9.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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Messaging 55
9.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
9.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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 10
10. Initialization and Startup
10.1 General Information
Before network participation, the following steps must be completed:
1. Startup Procedure
The purpose of the startup procedure is to make sure that both parts (the host application and
the Anybus CompactCom module) are ready to communicate. Normally an Anybus CompactCom module is ready to communicate in less than 1.5s.1 The module will then enter the ‘SETUP’-state. For more information, see “Startup Procedure” on page 57.
2. Anybus CompactCom 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 59.
3. Network Initialization
At this stage, the module will attempt to read and evaluate information from the host application.
When finished, the module will enter the ‘WAIT_PROCESS’-state.
For more information, see “Network Initialization (‘NW_INIT’-State)” on page 60.
1. IMPORTANT: When the module is restarted after a firmware download, the application must wait for
the upgrade to finish, before anything else is done, see “Startup Procedure” on page 57.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Initialization and Startup 57
10.2 Startup Procedure
The startup procedure is slightly different depending on which type of host interface that is used, but
will normally be finished within 1.5 s.
1. Enable power.
2. Release reset to the module.
3. Wait for the Anybus CompactCom 40 to respond. Depending on interface, the expected response is different:
Interface
Parallel Host (8/16 bit)
SPI
Shift Register
Serial Host
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Expected Response
The host application shall wait for the Anybus CompactCom interrupt signal
to go active, before starting to communicate.
After releasing the reset signal to the Anybus CompactCom module, the
host application may optionally wait for the Anybus CompactCom interrupt
signal to go active, thus indicating that the module is ready, before starting
SPI communication.
The other option for the host application is to start SPI communication
immediately after releasing the Anybus CompactCom reset signal. The
host application may see SPI telegrams with CRC errors at first. These telegrams shall be retransmitted according to normal error handling rules for
the SPI protocol, see “SPI Error handling” on page 38.
The Anybus CompactCom 40 module initializes autonomously after reset
is released.
This interface is backwards compatible to the Anybus CompactCom 30series serial host interface. Please refer to the Anybus CompactCom 30
Software Design Guide for information.
Doc.Id. HMSI-216-125
Initialization and Startup 58
Suggested Startup Procedure when Upgrading from Network
If firmware upgrade from network is allowed1, the following startup procedure is suggested:
IMPORTANT: Do not reset the Anybus CompactCom module during the startup procedure.
1. Enable power.
2. Release reset to the module.
3. Wait for the Anybus CompactCom 40 to respond. Depending on interface the expected response is different:
Interface
Parallel Host (8/16 bit)
SPI
Shift Register
Serial Host
Expected Response
Interrupt
First SPI telegram without CRC error, or an active interrupt signal
N/A
First serial telegram without CRC error
4. If a new firmware candidate is available, the module will start to reprogram the firmware. This
can need up to 1 min. If no candidate firmware is available the boot time will always be less than 1.5
seconds. In case of a firmware update, do not reset the module. If possible, display a message to the
end user: “Waiting for Anybus module...”.
5. When a response is detected: Start the initialization of the Anybus CompactCom 40 module. Remove any previously displayed message.
If the module does not respond as described, it has not started up correctly. Please contact HMS at
www.anybus.com for support.
IMPORTANT: When the Anybus CompactCom 40 is reset after a firmware download, the
application must wait for the installation to finish, before initialization is started. The Anybus
CompactCom is protected against problems occurring during download and/or installation
and will recover upon restart.
• To install the new firmware after download, reset the Anybus CompactCom. If the
installation of the new firmware is interrupted, e.g. due to power loss, please restart the
Anybus CompactCom 40. The installation process will automatically start from the beginning and the new firmware will be installed without any further action.
1. To allow firmware upgrade from network, implement attribute #5 of the Application Object (FFh),
instance #1. The module will inform the host application when a new firmware candidate is available in the
candidate area. The host application must store the information in non-volatile memory. See “Application
Object (FFh)” on page 101.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Initialization and Startup 59
10.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 13
•
“The Anybus State Machine” on page 42
•
“Anybus Object (01h)” on page 62
•
“Network Configuration Object (04h)” on page 81
1. This step is optional, but may be required by some networking systems and/or Anybus implementations.
2. Certain Anybus implementations may attempt to alter the Process Data map during runtime. For more
information, see “Application Data Object (FEh)” on page 91.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Initialization and Startup 60
10.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 those cases use its own default values for the requested attributes, or configured virtual attributes.
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 42
•
“Network Configuration Object (04h)” on page 81
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 11
11. Anybus Module Objects
11.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...
•
“Message Segmentation” on page 46
•
“Error Codes” on page 51
•
“Categorization of Functionality” on page 135
For detailed information about each object, see...
•
“Anybus Object (01h)” on page 62
•
“Diagnostic Object (02h)” on page 68
•
“Network Object (03h)” on page 74
•
“Network Configuration Object (04h)” on page 81
•
“Anybus File System Interface Object (0Ah)” on page 83
•
“Functional Safety Module Object (11h)” on page 84
11.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.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 62
11.3 Anybus Object (01h)
Category
Basic
Object Description
This object assembles data about the Anybus CompactCom 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)
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
Appl. spec.a UINT16
2 Firmware version
Get
-
struct of:
UINT8 Major
UINT8 Minor
UINT8 Build
3 Serial number
Get
-
UINT32
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
Value:
Meaning:
0401h:
Standard Anybus CompactCom 30
0402h:
Anybus CompactCom Drive Profile 30
0403h:
Standard Anybus CompactCom 40
(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
Doc.Id. HMSI-216-125
Anybus Module Objects 63
# Name
4 Application watchdog timeout
Access
Get/Set
Category
Extended
Type
UINT16
5 Setup complete
Get/Set
Basic
BOOL
6 Exception code
7 FATAL event
Get
Get/Set
Extended
8 Error counters
Get
Dev.c
9 Language
Get/Set
Extended
10 Provider ID
Get
11 Provider specific info Get/Set
b
Dev.
ENUM
struct of:
(HMS Specific)
struct of:
UINT16 DC
UINT16 DR
UINT16 SE
UINT16 FE
ENUM
-
UINT16
-
UINT16
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
Application watchdog configuration:
Meaning:
Value:
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 during runtime.
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 59
See “Exception Codes” on page 67
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
Current language:
Enumeration String:
Value:
00h:
‘English’ (default)
01h:
‘Deutsch’
02h:
‘Español’
03h:
‘Italiano’
04h:
‘Français’
See also...
- “Application Object (FFh)” on page 101
“Command Details: Change_Language_Request”
on page 106
Preprogrammed and stored permanently in
FLASH by HMS during production (contact HMS
for further information).
Meaning:
Value:
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
nonvolatile memory. Default value is 0000h.
Doc.Id. HMSI-216-125
Anybus Module Objects 64
# Name
12 LED colors
Access
Get
Type
struct
of:
Appl. spec.
UINT8 LED1A
UINT8 LED1B
UINT8 LED2A
UINT8 LED2B
13 LED status
Get
Appl. spec.a UINT8
14 Switch Statusd
Get
Category
a
Appl. spec. struct of
UINT8 SW1
UINT8 SW2
15 (not used for Anybus CompactCom 40)
16 GPIO configuration Get/Sete Appl. spec. UINT16
Description
This attributes specifies the colors of the network
status LEDs.
Value:
Meaning:
00h:
None (not used)
01h:
Green
02h:
Green
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:
LED3A status (0=OFF, 1=ON)
b5:
LED3B status (0=OFF, 1=ON)
b6:
LED4A status (0=OFF, 1=ON)
b7:
LED4B status (0=OFF, 1=ON)
Values of DIP switches representing node address
and baud rate.
Supported in serial, SPI and shift register mode. in
other modes the attribute contains random data.
Configuration of the host interface GPIO pins.
Value:
0000h,
0001h:
17 Virtual attributesd
Get/Sete Extended
Array of UINT8
Description
Extended LED functionality: GIP[0..1]
are used as network specific, active
low LED outputs associated with the
left, or single, port. (Default 0001h)
0002h:
RMII: GIP[0..1], /GOP[0..1], LED1A,
LED1B, LED2A, and LED2B are used
to create RMII interface against the
application.
This attribute is used to implement virtual host
application attributes in the module, e.g. when
using the module stand alone.
Multiple virtual attributes can be created, using the
format below:
Object (8 bit)
Instance (16 bit)
Attribute (8 bit)
Length (16 bit)
Data (Length * 8 bit)
Maximum size: 1524 bytes. Stored in nonvolatile
memory.
See “Virtual Attributes” on page 66.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 65
# Name
Access
18 Black list/White listd Get/Set
19 Network timed
20 Firmware custom
version
Get
Get
Category
Extended
Extended
Extended
Type
struct of:
UINT8 InfoBits
UINT8 ListLen
UINT16 Prot#1
UINT16 Prot#2
...
UINT16 Prot#n
UINT64
UINT8
Description
This attribute is used to implement the black list/
white list.
Format:
InfoBits:
bit 0: 0 = black list
1 = white list
bit 1 - 7: reserved
ListLen:
Length of the list, equal to #n entries (Prot#n)
0 = List disabled
Prot#:
The network type identifier
See “Black List / White List” on page 66.
The current network time.
The format of the network time is in a network
specific format.
0 = the network does not support network time.
This attribute holds a firmware version prefix, indicating a special branch of the firmware.
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. This attribute is only supported on Anybus CompactCom 40.
e. Set access is only valid during setup.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 66
Virtual Attributes
The virtual attributes list is a 1524 bytes array, stored in nonvolatile memory.
The virtual attributes are accessed via attribute #17 in the Anybus object. See “Anybus Object (01h)”
on page 62.
When the Anybus CompactCom 40 tries to retrieve network specific attributes from the host application
and the application cannot supply these attributes, an error code is returned. The module will then check
for the missing attributes in the virtual attributes list.
Using the virtual attributes list, it is possible to provide network specific objects and/or attributes to the
module without implementing them in the host application. This may e.g. be useful when an application
is to be adapted to new networks, and need to support network specific attributes, that are not available
in the original application.
Note 1: If the array data in the virtual attributes list does not fit into a single message, a Get_Attribute
request will return the error code “Messaging channel too small” (14h)
If the Anybus CompactCom 40 is used in stand alone mode, no host application is available and the Anybus CompactCom 40 will check for attributes in the virtual attributes list. The virtual attributes can only
be set before the “Setup complete” attribute is set.
ATTENTION: If you change the module’s identity when implementing a stand alone shift
register solution, it is necessary to implement the virtual attributes.
Black List / White List
Using the black list/white list, it is possible for the host to block or accept certain protocol versions.
Bit 0 in the header of the list decides if it is a black list or a white list. If configured as a white list, only
the protocols in the list will be accepted. If configured as a black list, all protocols in the list will be rejected.
A white list makes it possible to accept only a predefined choice of protocols.
A black list makes it possible to block already defined protocols.
The black list/white list is accessed via attribute #18 in the Anybus object. See “Anybus Object (01h)”
on page 62.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 67
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
‘Nonvolatile memory checksum error’ At least one of the parameters stored in nonvolatile memory has been
restored to its default value due to a checksum error.
09h
‘ASM communication error’
Communication is lost between the Anybus CompactCom module and
the attached Anybus safety module.
0Ah
‘Insufficient application implementa- The application does not implement the functionality required for the Anytion’
bus module to continue its operation.
(other) (reserved)
-
See also...
•
“The Anybus State Machine” on page 42
Object Specific Error Codes
The following object-specific error codes may be returned by the module as a response to setting the
‘Setup complete’-attribute.
#
01h
02h
03h
Error
Invalid process data configuration
Invalid device address
Invalid communication settings
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
The Process Data configuration is invalid
The selected device address is not valid for the actual network
The selected communication settings are not valid for the actual network
Doc.Id. HMSI-216-125
Anybus Module Objects 68
11.4 Diagnostic Object (02h)
Category
Specific to each industrial network, see network guides.
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 the 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 72)
Delete (04) (See “Command Details: Delete” on page 73)
Instance:
Get Attribute (01h)
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
‘Diagnostic’
01h
(depends on number of created diagnostic events)
(network specific)
Get
UINT16
12 Supported Functionalityb Get
BITS32
Max. no. of instances that can be created (network specific)a
Bit 0:
‘1’ if latching events are supported
‘0’ if latching events are not supported
Bit 1 - 31: reserved (shall be ‘0’)
11 Max no. of instances
a. Of the maximum number of instances there should always be one instance reserved for an event of severity level
‘Major, unrecoverable’, to force the module into the ‘EXCEPTION’-state.
b. Not supported in Anybus CompactCom 30.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 69
Instance Attribute (Instance #1)
#
1
Name
Severity
Access
Get
Type
UINT8
Description
This attribute should be viewed as a bit field
Bit 0 (the least significant bit) indicates whether extended
diagnostics are used by the instance
Bit 0 = 1: extended diagnostics are used
Bit 0 = 0: extended diagnostics are not used
2
3
4
Event Code
NW specific extension
Slot
Get
Get
Get
Bits 4 - 6 are used for severity level information. See “Severity” on page 70
UINT8
See “Event Codes” on page 71
Array of UINT8 Network specific event information (optional)
UINT16
Indicates which slot in a modular device the diagnostic event
is associated with
Default value: 0
5
6
ADI
Element
Get
Get
UINT16
UINT8
For more information, see “Modular Device Object (ECh)” on
page 125
Indicates which ADI the diagnostic event is associated with
Default value: 0 (if the diagnostic instance is not associated
with any particular ADI)
Indicates which element in the ADI the diagnostic event is
associated with
The value ‘255’ is used if the diagnostic event is associated
with the entire ADI
7
Bit
Get
UINT8
Default value: 255
Indicates the bit in the element that the diagnostic event is
associated with
The value ‘255’ is used to indicate that the diagnostic event is
associated with the entire element
Default value: 255
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 70
Severity
This parameter indicates the severity level of the event. Only bits 4 - 6 are used for severity level information.
Severity Levels
Bit Combination
000
001
010
011
101
110
(other)
Severity
Minor, recoverable
Minor, unrecoverable
Major, recoverable
Major, unrecoverable
Minor, latching
Major, latching
-
Comment
Unrecoverable events cannot be deleted
Causes a state-shift to EXCEPTION
(reserved for future use)
Recoverable events shall be deleted by the application when the cause of the error is gone.
Unrecoverable events cannot be deleted. They remain active until the Anybus CompactCom is reset or
power is turned off.
Latching events remain active until explicitly acknowledged by the network master. If the network does
not support acknowledgment of latching diagnostic events, the module shall refuse the creation of latching diagnostic events.
When the network master acknowledges one or more latching events, the module shall send a “Reset
Diagnostic” request to the application object. The request contains a list of diagnostic instances which
the master wishes to acknowledge. The application object shall respond with a list of diagnostic instances
which it allows the module to delete. The module will then delete the allowed instances, and report the
appropriate information to the network master.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 71
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 40 Software Design Guide
Doc.Rev. 2.00
Comment
Definition is network-specific; consult separate network guide for further information.
Doc.Id. HMSI-216-125
Anybus Module Objects 72
Command Details: Create
Details
Command Code:
03h
Valid for:
Object
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-1]
MsgData[2-3]
MsgData[4]
MsgData[5]
MsgData[6-7]
MsgData[0/8-n]
Contents
Bit 0:
Extended Diagnostic
Bit 4 - 6: Severity
Other bits: Reserved. Set to zero
Event Code, see previous page
Slot number associated with the event
Set to ‘0’ if unknown or unsupported
ADI associated with the event
Set to ‘0’ if unknown or unsupported
Element associated with the event
Set to ‘255’ if unknown or unsupported
Bit in element associated with the event
Set to ‘255’ if unknown or unsupported
Reserved. Set to zero
Network specific extension (optional, definition is
network specific)
Note
These fields only exist if ‘bit 0:
Extended Diagnostic’ is set
MsgData[8-n] if bit 0 in CmdExt[0]
is set
MsgData[0-n] if bit 0 in CmdExt[0]
is not set
•
Response Details (Success)
Field
MsgData[0-1]
•
Contents
The number of the created instance
Response Details (Error)
Error
Object Specific Error
Contents
MsgData[1] = 0x02
MsgData[1] = 0xFF
Comment
Error code (Latching event not supported)
The event could not be created since the
module does not support latching events
Error code (Network specific error)
The event could not be created due to a network specific reason
Information about the event is found in
response MsgData[2-n]
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 73
Command Details: Delete
Details
Command Code:
04h
Valid for:
Object
Description
Deletes an existing instance, i.e. a previously created diagnostic event.
Note: Instances representing unrecoverable events and latching 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[1] = 01h
MsgData[1] = FFh
Comment
Error code (Not removed).
The event could not be removed, either
because the event itself is unrecoverable,
latching, or due to a network specific reason.
Error code (Network specific error)
The event could not be deleted due to a network specific reason
Information about the event is found in
response MsgData[2-n]
See also:
•
“Error Codes” on page 51
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 74
11.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...
•
“Functional Safety Object (E8h)” on page 90
•
“Application Object (FFh)” on page 101
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)
Map_ADI_Write_Ext_Area (12h)
Map_ADI_Read_Ext_Area (13h)
Object Attributes (Instance #0)
#
1
2
3
4
Name
Name
Revision
Number of instances
Highest instance no.
Access
Get
Get
Get
Get
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Data Type
Array of CHAR
UINT8
UINT16
UINT16
Value
‘Network’
02h
(Module type dependent)
(Module type dependent)
Doc.Id. HMSI-216-125
Anybus Module Objects 75
Instance Attributes (Instance #1)
#
1
2
3
Name
Network type
Network type string
Data format
Access
Get
Get
Get
4
Parameter data
support
Get
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 guide)
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,
Map_ADI_Write_Ext_Area, Remap_ADI_Write_Area
or any network specific mapping command
UINT16
The current read Process Data size (in bytes)
Updated on every successful Map_ADI_Read_Area,
Map_ADI_Read_Ext_Area, Remap_ADI_Read_Area
or any network specific mapping command
UINT8
Additional network specific information may be presented here if the module has entered the EXCEPTION state (see separate network guide)
a. Can be used for deciding what ADIs to map to Process Data
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 76
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: It is not allowed to mix mapping commands Map_ADI_Read/Write_Area and
Map_ADI_Read/Write_Ext_Area within one area.
Note 4: It is not allowed to map BITSx types of fractional byte size (BIT1 - BIT7) or PADx types using
this command.
Note 5: It is only allowed to map variables and arrays with this command. It is not allowed to map structures.
Note 6: Certain Anybus implementations allow the network to remap the Process Data during runtime.
For more information, see “Application Data Object (FEh)” on page 91.
See also...
•
“Command Details: Map_ADI_Write_Ext_Area” on page 78
•
“Command Details: Map_ADI_Read_Area” on page 77
•
“Application Object (FFh)” on page 101
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 48)
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.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 77
•
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 order in which the commands were
received is invalid
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 76
•
“Application Object (FFh)” on page 101
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 78
Command Details: Map_ADI_Write_Ext_Area
Details
Command Code:
12h
Valid for:
Instance
Description
Only supported by Anybus CompactCom 40 modules.
This command is equivalent to Map_ADI_Write_Area, but can map more than 256 bytes of data. It supports mapping fractional byte size types, and it can be used to map only specific parts of an ADI.
It maps an ADI as Write Process Data. If successful, the response data contains the offset, in bits, for
the mapped ADI from the start of the Write Process Data area.
Note 1: Mapping 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) is not accepted by all networks.
Note 2: It is not allowed to mix mapping commands Map_ADI_Read/Write_Area and
Map_ADI_Read/Write_Ext_Area within one area (Read/Write).
Note 3: It is recommended to only map one item for each mapping command during initial development, since data area offset is only given for the first mapping item, and all mapping items may be rejected using one single error code.
Note 4: All mapped elements, except those of types BIT1-BIT7 and PADx, must be byte aligned.
Note 5: The only implicit padding done is from the very last mapped item up to byte alignment, since
the process data needs to be of byte size when the setup is complete.
Note 6: Explicit padding is done either through available ADI elements of PADx type, or through the
imaginary ADI 0, which is assumed to be an array with 255 elements of type PAD1. Explicit padding of
process data is the only correct use of ADI 0. Padding bits might not be visible on the network.
Note 7: This command may permanently alter the state of the Anybus CompactCom even though the
command is returned with an error. Network specific restrictions may lead to n mapping items to be
accepted, but with an error on mapping item n+1. If so, the mappings up to and including n will be accepted, but all other mapping items, starting with n+1, are rejected. The number of accepted mappings
is declared inCmdExt[ 0 ] of the answer.
Note 8: Certain Anybus implementations allow the network to remap the Process Data during runtime.
For more information, see “Application Data Object (FEh)” on page 91.
See also...
•
“Command Details: Map_ADI_Read_Ext_Area” on page 80
•
“Application Object (FFh)” on page 101
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.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 79
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-1]
MsgData[2]
MsgData[3]
MsgData[4]
MsgData[5]
MsgData[6..n]
...
•
Response Details (Success)
Field
CmdExt[0]
MsgData[0]
MsgData[1]
MsgData[2]
MsgData[3]
•
Contents
The number of ADIs to add (0-217)
Reserved. Set to 0
New mapping item 1: ADI number
New mapping item 1: Number of elements in the ADI
New mapping item 1: Index to the first element to map (0-254)
New mapping item 1: Number of consecutive elements to map (1-255)
New mapping item 1: Number of type descriptors (1-255)
New mapping item 1: Array of type specifiers for each mapped element
Repeat MsgData[0-n] (as above) for mapping item 2 and onwards.
Contents
The number of accepted mapping items (0-217).
Bit offset of the mapped ADI from the start of the Write Process Data (Least significant
byte)
Bit offset of the mapped ADI from the start of the Write Process Data
Bit offset of the mapped ADI from the start of the Write Process Data
Bit offset of the mapped ADI from the start of the Write Process Data (Most significant
byte)
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, or
too many elements)
03h: Invalid total size
The requested mapping is denied because the
resulting total data size would exceed the maximum permissible (depending on network type)
06h: Invalid map command sequence The order in which the commands were
received is invalid
07h: Invalid mapping command
Inconsistencies in the command makes it
impossible to parse
08h: Bad alignment
The alignment rules for process data are not
followed
09h: Invalid use of ADI 0
ADI 0 is an array (255 elements) of type PAD1
FFh: Network specific restriction
The mapping is denied because of a network
specific reason, stated in response Data[2-n].
Consult the relevant network guide
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.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 80
Command Details: Map_ADI_Read_Ext_Area
Details
Command Code:
13h
Valid for:
Instance
Description
Only supported by Anybus CompactCom 40 modules.
This command is equivalent to Map_ADI_Read_Area, but can map more than 256 bytes of data.
It is identical to Map_ADI_Write_Ext_Area except that it maps ADIs to Read Process Data.
See also...
•
“Command Details: Map_ADI_Write_Ext_Area” on page 78
•
“Application Object (FFh)” on page 101
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 81
11.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, node address etc. Although the actual definition of the instances in this object
are network specific, instance 1 and 2 are fixed (when possible).
When possible, the following convention is used for these instances:
Instance no.
1
2
Data type
Any 8 bit or 16 bit data type
Any 8 bit or 16 bit data type
Parameter
Currently selected network device address (or similar).
Currently selected network communication bit rate (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 1: 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.
Note 2: When a set request with 8 bits of data is directed to a 16 bit instance, the set request is accepted
and the upper 8 bits are set to zero.
Note 3: When a set request with 16 bits of data is directed to a 8 bit instance, the set request is accepted
and the upper 8 bits are discarded.
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 fulfill network specific needs related to the actual origin
of a parameter (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 40 Software Design Guide
Doc.Rev. 2.00
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-216-125
Anybus Module Objects 82
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 “SYNC” on page 17). 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
Number of Get
elements
Descriptor Get
4
5
6
Category
Type
Description
Array
of
CHAR
Parameter
name (e.g. ‘Node address’)
Appl. Spec.
Data type (See “Data Format” on page 48)
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
Value
Determined by Appl. Spec.a Determined by Actual parameter value. Stored in nonvolatile memory
“Descriptor”
“Data type”
Get access: the actually used value will be returned
Set access: the configured (and possibly the actual)
value will be written
Configured Get
Appl. Spec.a Determined by The configured parameter value
“Data type”
value
Returns the configured value of an attribute. It is useful
when ‘Value’ is not being used directly when set, e.g.
when a power cycle is needed
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 guides.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 83
11.7 Anybus File System Interface Object (0Ah)
Category
Extended
Object Description
This object can be used to create and delete file system interface instances dynamically during runtime.
Each instance is a handle to a file and/or a directory stream and supports services for file system operations.
It is structurally identical to the Application File System Interface Object (EAh). For object documentation and more information, see “Application File System Interface Object (EAh)” on page 108.
Note: Ethernet modules have a file system that is accessible to the application for different purposes,
e.g. for firmware download/upgrade and internal web pages. See the respective network guides for more
information. For all other modules, only one folder is present. This folder is only used for downloading
and upgrading firmware.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 84
11.8 Functional Safety Module Object (11h)
Category
Extended
Object Description
This object holds information provided by the Safety Module connected to the Anybus CompactCom.
See also...
•
Functional Safety Object
Supported Commands
Object:
Get_Attribute (01h)
Error_Confirmation
Instance:
Get_Attribute (01h)
Object Attributes (Instance #0)
#
1
2
3
4
Name
Name
Revision
Number of instances
Highest instance no.
Access
Get
Get
Get
Get
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Data Type
Array of CHAR
UINT8
UINT16
UINT16
Value
‘Functional Safety Module’
01h
0001h
0001h
Doc.Id. HMSI-216-125
Anybus Module Objects 85
Instance Attributes (Instance #1)
Extended
#
Name
1
State
Acce
Type
ss
Get UINT8
2
Vendor ID
Get
UINT16
3
IO Channel ID
Get
UINT16
4
Firmware version
Get
Struct of
5
Serial number
Get
UINT8 (Major)
UINT8 (Minor)
UINT8 (Build)
UINT32
6
Output data
Get
Array of UINT8
7
Input data
Get
Array of UINT8
8
Error counters
Get
Struct of
UINT16 (ABCC DR)
UINT16 (ABCC SE)
UINT16 (SM DR)
UINT16 (SM SE)
9
Event log
Get
Array of UINT8
10 Exception information Get
UINT8
11 Bootloader version
Struct of
UINT8 Major
UINT8 Minor
Get
Description
Current state of the Safety Modulea
Identifies vendor of the Safety Module.a
E.g. 0001h (HMS Industrial Networks)
Describes the IO Channels that the Safety Module is
equipped with.a
Safety Module firmware version.
Version 2.18.3 would be represented as:
first byte: 02h
second byte: 12h
third byte: 03h
32 bit number, assigned to the Safety Module at production.a
Current value of the Safety Module output data, i.e. data
FROM the network
Note: This data is unsafe, since it is provided by the Anybus
CompactCom module.
Current value of the Safety Module input data, i.e. data sent
TO the network.
Note: This data is unsafe, since it is provided by the Anybus
CompactCom module.
Error counters (each counter stops counting at FFFFh)
ABCC DR: Responses (unexpected) from the Safety Module, discarded by the Anybus CompactCom
module.
ABCC SE: Serial reception errors detected by the Anybus
CompactCom module.
SM DR:
Responses (unexpected) from the Anybus
CompactCom module, discarded by the Safety
Module.
SM SE:
Serial reception errors detected by the Safety
Module.
Latest Safety Module event information (if any) is logged to
this attribute. Any older event information is erased when a
new event is logged.
For evaluation by HMS support.
If the Exception code in the Anybus object is set to “Safety
communication error” (09h), additional exception information
is presented here, see “Exception Information” on page 86.
Safety module bootloader version.
Version “2.12” would be represented as:
first byte: 02h
second byte: 0Ch
a. Values depend on which Safety Module is used.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Anybus Module Objects 86
Exception Information
If Exception Code 09h is set in the Anybus object, there is an error regarding the functional safety module in the application. Exception information is presented in instance attribute #10 according to this table:
Value
00h
01h
02h
03h
04h
05h
06h
07h
08h
09h
0Ah
0Bh
0Ch
0Dh
0Eh
0Fh
Exception Information
No information
Baud rate not supported
No start message
Unexpected message length
Unexpected command in response
Unexpected error code
Safety application not found
Invalid safety application CRC
No flash access
Answer from wrong safety processor during boot loader communication
Boot loader timeout
Network specific parameter error
Invalid IO configuration string
Response differed between the safety microprocessors (e.g. different module types)
Incompatible module (e.g. supported network)
Max number of retransmissions performed (e.g. due to CRC errors)
Command Details: Error_Confirmation
Category
Extended
Details
Command Code:
Valid for:
Object Instance
Description
When the Safety Module has entered the Safe State, for any reason, it must receive an error confirmation
from the application, before it can leave the safe state. The application sends this command to the Anybus CompactCom module, that forwards it to the Safety Module.
•
Command Details
(No data)
•
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Chapter 12
12. Host Application Objects
12.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...
•
“Message Segmentation” on page 46
•
“Anybus Module Objects” on page 61
•
“Categorization of Functionality” on page 135
For detailed information about each object, see...
•
“Application Object (FFh)” on page 101
•
“Application Data Object (FEh)” on page 91
•
“Energy Control Object (F0h)” on page 130
•
“Sync Object (EEh)” on page 128
•
“Modular Device Object (ECh)” on page 125
•
“Assembly Mapping Object (EBh)” on page 122
•
“Application File System Interface Object (EAh)” on page 108
•
“Functional Safety Object (E8h)” on page 90
•
“Energy Reporting Object (E7h)” on page 89
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 88
12.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 Object and the Application Data Object are mandatory.
•
Support for Network Specific Objects is optional, but recommended. 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 the module tries to access an object that is not implemented, respond with an error
message (03h, Unsupported Object). 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 optional for the CompactCom 40 range and may provide better
network integration for certain networks.
See also...
•
“Error Codes” on page 51
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 guide only.
In case of questions, contact the HMS technical support services.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 89
12.3 Energy Reporting Object (E7h)
Category
Extended
Object Description
Using this object, the host application has a standardized way of reporting its energy consumed or produced. The reporting capabilities of this object are limited. On networks providing more elaborate reporting functionality, the reporting functionality will have to be implemented in a transparent manner
by the application.
Supported Commands
Object:
Get_Attribute
Instance:
Get_Attribute
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
‘Energy Reporting’
01h
0001h
0001h
Instance Attributes (Instance #1)
Extended
#
1
Name
Energy Reading
Access Type
Get
Struct of:
UINT32
UINT32
2
Direction
Get
BOOL
3
Accuracy
Get
UINT16
4
Current Power
Consumption
Nominal Current
Consumption
Get
UINT16
Get
UINT32
5
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
Amount of energy consumed or produced in Wh. Stored in
nonvolatile memory.
The first UINT32 represents the lower part of the Energy
Reading, the second UINT32 represents the higher part of the
Energy Reading
Indicates if the host is consuming or producing energy.
Value: Meaning
0: Producing
1: Consuming
Accuracy: 0.01% of reading
0: Unknown
The current power consumption in 0.01% of the Nominal
Power consumption
The nominal power consumption in mW
Doc.Id. HMSI-216-125
Host Application Objects 90
12.4 Functional Safety Object (E8h)
Category
Extended
Object Description
This object specifies the safety settings of the application. Mandatory if Functional Safety is to be supported and a Safety Module is connected to the Anybus CompactCom module.
Supported Commands
Object:
Get_Attribute
Instance:
Get_Attribute
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
‘Functional Safety Module’
01h
0001h
0001h
Instance Attributes (Instance #1)
Extended
#
1
Name
Safety enabled
Access Type
Get
BOOL
2
Baud Rate
Get
UINT32
3
IO Configuration
Get
Array of UINT8
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
When TRUE, enables communication with the Safety Module.
Note: If functional safety is not supported, this attribute must
be set to FALSE.
Optional attribute. Sets the baud rate for the communication
between the Anybus CompactCom module and the Safety
Module. If not implemented, the default value 1020 kbit/s will
be used.
If the generated baud rate differs more than 5% from the value
of this attribute, the Anybus CompactCom module will go into
EXCEPTION.
Optional attribute. Manufacturer specific settings of the digital
I/O of the Safety Module.
For information, see the specification of Safety Module used.
Doc.Id. HMSI-216-125
Host Application Objects 91
12.5 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 objects, 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 76 and “Command Details:
Map_ADI_Write_Ext_Area” on page 78.
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.
•
If remapping of Process Data is to be supported, implementation is mandatory of object commands Remap_ADI_Write_Area, Remap_ADI_Read_Area and Get_Instance_numbers.
•
If remapping of Process Data is supported, object attributes #11 and #12 are mandatory.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 92
Commands
Object:
Get_Attribute (01h)
Get_Instance_Number_By_Order (10h)
Remap_ADI_Write_Area (13h)1
Remap_ADI_Read_Area (14h)1
Get_Instance_Numbers (15h)1
Instance:
Get_Attribute (01h)
Set_Attribute (02h)
Get_Enum_String (06h)
Get_Indexed_Attribute (07h)
Set_Indexed_Attribute (08h)
Object Attributes (Instance #0)
#
1
2
3
4
11
Name
Name
Revision
Number of instances
Highest instance no.
No. of read process
data mappable
instancesa
12 No. of write process
data mappable
instancesa
Access
Get
Get
Get
Get
Get
Data Type
Array of CHAR
UINT8
UINT16
UINT16
UINT16
Get
UINT16
Value
‘Application Data’
03h
(depends on application)
a. Attribute mandatory for applications supporting remapping of process data.
1. Implementation is mandatory if remapping of Process Data is to be supported.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 93
Instance Attributes (Instance #1... n)
#
1
2
3
4
5
6
7
8
9
Name
Name
Access
Get
Category
Type
Description
Network spe- Array of CHAR ADI name (can be multilingual)
cific
Data type
Get
Basic
Array of UINT8 Each UINT8 defines the data type of the corresponding element of the instance value for structures and variables. (See “Classes of Data” on page
94). For arrays, one UINT8 defines the data type for
all subelements of the corresponding array element.
Number of Get
Basic
UINT8
Number of elements in attribute #5, “Value(s)”. 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
Array of UINT8 Each UINT8 is a bit field specifying the access
rights etc. for the corresponding element of the
instance value for structures and variables. (See
“Classes of Data” on page 94).For arrays, one
UINT8 defines the descriptor for all subelements of
the corresponding array element.
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”
Indexed elements can be of different types and
sizes as specified in attribute #2.
This attribute consists of all elements packed
together with bit alignment. No implicit padding
should be used. See table below for specific alignment restrictions and explicit padding.
d
Get
The maximum permitted ADI value.
Max. valAppl. Spec.
Implementation of this attribute is optional. If not
ueb,c
implemented, the 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.
d
Each UINT16 defines the number of subelements of
Number of Get
Appl. Spec. Array of
UINT16
the corresponding element of the instance value for
subelestructures and variables.
ments
Implementation of this attribute is optionale, and
must not be implemented for arrays. (See “Classes
of Data” on page 94).
The number of subelements may only differ from 1 if
the corresponding element is of type CHAR or
OCTET.
a. Mandatory if remapping of Process Data is to be supported.
b. The byte order of these attributes is network dependent; the Anybus does not perform any byte swapping etc.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 94
c. Unless the data class is a structure 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. For structured ADIs, the format is the
same as for attribute #5.
d. The category of this attribute depends on how it is used in the application.
e. If this attribute is not implemented, one (1) subelement for each element is assumed.
IMPORTANT:
•
The instance value(s) must fit entirely into the message data field. The total byte size of all elements must therefore never exceed 1524 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.
Classes of Data
An Application Data object instance may be used to model different classes of data: variables, arrays or
structures. Every class can be distinguished by the instance attributes, as described in the table below.
Class
Variable
Array
Structure
Distinguished by
Number of elements is 1.
Remarks
Starting with revision 3 of the Application Data object, the
attribute Number of subelements used in conjunction with
a variable of CHAR type is the recommended way to create a string variable. I.e. a string variable here consists of
one element with several subelements.
Number of elements is > 1, and num- The attribute Number of subelements is not valid for
ber of data types in Data type is 1.
arrays.
Arrays of CHAR will be translated to string variables on
networks supporting strings. See the remark for Variable
above, for the recommended way to represent string variables.
Number of elements is > 1, and
A structure consists of elements that may have different
equals the number of Data types.
data types. Possible from object revision 3.
Notes on Parameter Access
The following list gives rules and notes on accessing parameters in the Anybus CompactCom 40.
•
Subelements not equal to 1 are only allowed for CHAR and OCTET
•
Structures many not contain elements of type ENUM
•
If there is a “hole” in a structured ADI, its data type is defined as PAD0. The Descriptor (attribute #49 should define it as neither settable nor gettable, and “Invalid CmdExt[1]” (07h) will be
returned for the commands Get_Indexed_Attribute/Set_Indexed_Attribute.
•
Names of elements are generated by the Anybus CompactCom, if needed, e.g. “ADIName.0”.
•
All elements, except those of data type BIT1 - BIT7 and PAD0 - PAD16, must be byte aligned.
•
The only implicit padding done for parameter access is from the very last accessed element up
to byte alignment, since messages are always complete bytes.
•
Explicit padding is done using elements of PADx data type.
•
Elements, which are not byte aligned, shall be shifted down to be byte aligned when accessed
through Get_Indexed_attribute, and vice versa for Set_Indexed_Attribute.
•
Descriptors may differ between elements of the same ADI
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 95
- For a Get_Attribute of an ADI of class Structure with inconsistent settings of the Descriptor
bit “Get access” for different elements, the application should fill the unreadable elements
with zero in the response. If the “Get access” descriptor bits are consistently set to 0, the
Get_Attribute should be returned with error code “Attribute not gettable” (09h).
- For a Set_Attribute of an ADI of class Structure with inconsistent settings of the Descriptor
bit “Set access” for different elements, the application should ignore the non-settable elements and apply the values of the settable ones. If the “Set access” descriptor bits are consistently set to 0, the Set_Attribute should be returned with error code “Attribute not
settable” (08h).
•
Elements with bit alignment are always shifted down to bit 0 when accessed through Get_Indexed_Attribute/Set_Indexed_Attribute.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 96
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 the ADI corresponding to the submitted Order Number.
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 91
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 97
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 the following Anybus CompactCom states: NW_INIT, WAIT_PROCESS, IDLE and ERROR.
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 74
•
“Runtime Remapping of Process Data” on page 139
IMPORTANT: To support this procedure, the host application must be capable of remapping the Process Data during
runtime. This is a mandatory requirement for object rev. 2, and optional for object rev. 3. Support for this command is
highly recommended.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 98
•
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 (low byte) (mapping item number, 0 = first)
Start of remap (high byte) (mapping item number, 0 = first)
The number of current mapping items to remove
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 40 Software Design Guide
Doc.Rev. 2.00
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-216-125
Host Application Objects 99
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 applications, 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 139).
See also...
•
“Network Object (03h)” on page 74
•
“Runtime Remapping of Process Data” on page 139
IMPORTANT: To support this procedure, the host application must be capable of remapping the Process Data during
runtime. Support for this command is optional, albeit highly recommended).
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 100
Command Details: Get_Instance_Numbers
Details
Command Code:
15h
Valid for:
Object
Description
This command is used to produce lists of ADIs with certain properties. List types 01h - 03h are mandatory for all applications supporting dynamic process data mapping. For a complete list of list types, see
“Table of List Types” on page 100.
The application shall respond with a number of instances equal to or less than the requested number
(less if a fewer number than requested exists in the application). If the requested starting order number
is higher than the highest instance, an empty response shall be returned. If an unsupported list type is
requested, an error response with “Invalid CmdExt[1]” shall be generated.
The Anybus CompactCom module may issue several commands with increasing order number to retrieve a complete list.
Note: The module shall enter state EXCEPTION if a response with out of order instance numbers is
received, or at the reception of any incorrect response.
•
Command Details:
Field
CmdExt[0]
CmdExt[1]
Data[0-1]
Data[2-3]
•
Meaning
Reserved = 00h
List type (See “Table of List Types” on page 100)
Starting order number
Requested number of instances
Response Details:
Field
MsgData[0-1]
Type
UINT16
MsgData[2-3]
UINT16
MsgData[4-5]
UINT16
...
...
Meaning
The instance number of the ADI (with the instance number corresponding to
the order number), matching the selected list type
The instance number of the ADI (with the instance number corresponding to
the order number + 1), matching the selected list type
The instance number of the ADI (with the instance number corresponding to
the order number + 2), matching the selected list type
...
Table of List Types
List Number
00h
01h
02h
03h
List Type
Reserved
All ADIs
All read process data mappable ADIs (All ADIs where bit 4 in the descriptor attribute is set to “1”.
See “Instance Attributes (Instance #1... n)” on page 93 for more information.)
All write process data mappable ADIs (All ADIs where bit 3 in the descriptor attribute is set to “1”.
See “Instance Attributes (Instance #1... n)” on page 93 for more information.)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 101
12.6 Application Object (FFh)
Category
Basic, Extended
Object Description
This object is mandatory, and groups general settings for the host application. The object and its commands makes it possible to support multiple languages, network reset requests and latching diagnostic
events.
A control sum, available from the application, that specifies the current parameter settings, can be used
to enhance startup time.
Information on if there is a candidate firmware available, and if it is possible to configure the address of
the module via hardware switches, can also be read from this object.
Supported Commands
Object:
Get_Attribute (01h)
Reset (05h)
Reset_Request (10h)
Change_Language_Request (11h)
Reset Diagnostic (12h)
Instance:
Get_Attribute (01h)
Set_Attribute (02h)
Get_Enum_String (06h)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 102
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’
02h
0001h
0001h
Instance Attributes (Instance #1)
#
1
2
3
Name
Configured
Supported
languages
Serial
number
Access
Get
Get
Get
Category
Extended
Extended
Extended
Type
BOOL
Array of ENUM
UINT32
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 104
- “Command Details: Reset_Request” on page 105
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 23
- “Anybus Object (01h)” on page 62 (Instance attribute
#9)
- “Command Details: Change_Language_Request” on
page 106
The vendor’s serial number for the device
If a serial number in the corresponding network specific
host object is not available, the module will use this
number instead, converted according to network
requirements.
If this attribute is missing, the module will use its own
serial number.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 103
#
4
Name
Parameter
control sum
Access
Get
5
Candidate
firmware
available
Get/Set
6
Hardware
Get
configurable
address
Category
Extended
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Type
Array of UINT8
(128 bits)
BOOL
BOOL
Description
This attribute will hold a control sum from the application
that specifies the current parameter settings in the application. How the application calculates the control sum is
not specified, the only requirement is that as soon as a
parameter in the application changes the control sum also
changes.
The control sum is used to improve the startup time for
the Anybus CompactCom for POWERLINK and PROFINET. Common to these networks are that the master
sets a parameter (configuration date and configuration
time for POWERLINK and UUID for PROFINET) that
specifies the parameter setting the master will transfer to
the slave. In order for the slave to determine whether the
application already has these parameter settings it must
compare the parameter received from the master with the
parameter received from the application. If the saved (in
non-volatile memory) master parameter and application
parameter match the ones newly received from the application and master there is no need for re-parameterization of the application.
It’s not required by the application to implement this attribute, but it is recommended if quickconnect/fast startup
for the above mentioned networks are used.
Indicates if there is an firmware file available in the candidate area, for firmware upgrade at the next restart. The
application can use this to determine if the next restart will
be extended due to a firmware upgrade.
The attribute is cleared at startup.
Value: Meaning:
False: Firmware file not available in the candidate area.
True: Firmware file available in the candidate area.
See also “Firmware Download” on page 24 and “Startup
Procedure” on page 57
Indicates if the address of the module can be configured
via hardware switches.
An address may be hardware configurable, but not necessarily hardware configured. Some networks, e.g. EtherNet/IP need to be able to make this distinction.
Value: Meaning:
False: The address is not hardware configurable.
True: The address is hardware configurable.
Doc.Id. HMSI-216-125
Host Application Objects 104
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 application
specific out-of-box state. Any network-specific procedures necessary to set the module to this state are performed automatically.
Note: The state of the Anybus module, prior to this request, is
network specific.
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 102 (Attribute #1, ‘Configured’)
•
“Command Details: Reset_Request” on page 105
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 105
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 102 (Attribute #1, ‘Configured’)
•
“Command Details: Reset” on page 104
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 106
Command Details: Change_Language_Request
Details
Command Code:
11h
Valid for:
Object
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 23
•
“Anybus Object (01h)” on page 62 (Instance attribute #9, ‘Language’)
•
“Instance Attributes (Instance #1)” on page 102 (Attribute #2, ‘Supported languages’)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 107
Command Details: Reset_Diagnostic
Details
Command Code:
12h
Valid for:
Object
Description
The Reset_Diagnostic request will be sent to the application object when the network master wishes to
acknowledge/reset one or several “latching diagnostic events”.
This service is only mandatory if the application supports “latching diagnostic events”.
It is for the application to decide if diagnostic events can be deleted or not. In the Reset_Diagnostic response, the application is expected to provide a list of diagnostic instances that can be deleted (where
the error is no longer present). This list may be identical to the list in the Reset_Diagnostic request, or
it may be a subset of that list. The application may also respond with a zero sized list, if no instances can
be deleted, or with an error in the case that the Reset_Diagnostic request is refused.
See “Diagnostic Object (02h)” on page 68 for more information.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-n]
•
Contents
Reserved. Value = 00h
Reserved. Value = 00h
UINT16 list of diagnostic instances which the Anybus CompactCom module requests
permission to delete
Response Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-n]
Contents
Reserved. Value = 00h
Reserved. Value = 00h
UINT16 list of diagnostic instances which the Anybus CompactCom module is permitted to
delete
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 108
12.7 Application File System Interface Object (EAh)
Category
Extended
Object Description
This object can be used to create and delete file system interface instances dynamically during runtime.
Each instance is a handle to a file stream and contains services for file system operations.
The application must allocate a dedicated area in its internal memory for this functionality. It must also
be able to handle all available commands.
Supported Commands
Object:
Get_Attribute (01h)
Set_Attribute (02h)
Create (03h)
Delete (04h)
FormatDisc (30h)
Instance:
Get_Attribute (01h)
File Open (10h)
File Close (11h)
File Delete (12h)
File Copy (13h)
File Rename (14h)
File Read (15h)
File Write (16h)
Directory Open (20h)
Directory Close (21h)
Directory Delete (22h)
Directory Read (23h)
Directory Create (24h)
Directory Change (25h)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 109
Object Attributes (Instance #0)
#
1
2
3
4
11
12
Name
Name
Revision
Number of instances
Highest instance no.
Max no. of instances
Disable virtual file system
13 Total disc size
14 Free disc size
15 Disc CRC
Access
Get
Get
Get
Get
Get
Set
Get
Get
Get
Data Type
Array of CHAR
UINT8
UINT16
UINT16
UINT16
BOOL
Value
‘Application File System Interface’
01h
4
Default value: 0
Array of UINT32
Array of UINT32
Array of UINT32
0 = the virtual file system is enabled
1 = the virtual file system is disabled
N/A
N/A
N/A
Instance Attributes (Instance #1... 4)
#
1
Name
Access
Instance type Get
Category
Extended
Type
UINT8
2
3
File size
Path
Extended
Extended
UINT32
Array of CHAR
Get
Get
Description
0 = Reserved
1 = File instance
2 = Directory instance
File size (0 for a directory)
The file path to where the instance operates
File System Errors
In case of errors for services calling the file system interface object, the module will return FFh (object
specific error). A descriptive file system error will be returned in the error response data field.
#
1
2
3
4
5
6
7
8
9
10
11
12
Name
FILE_OPEN_FAILED
FILE_CLOSE_FAILED
FILE_DELETE_FAILED
DIRECTORY_OPEN_FAILED
DIRECTORY_CLOSE_FAILED
DIRECTORY_CREATE_FAILED
DIRECTORY_DELETE_FAILED
DIRECTORY_CHANGE_FAILED
FILE_COPY_OPEN_READ_FAILED
FILE_COPY_OPEN_WRITE_FAILED
FILE_COPY_WRITE_FAILED
FILE_RENAME_FAILED
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Description
Could not open file
Could not close file
Could not delete file
Could not open directory
Could not close directory
Could not create directory
Could not delete directory
Could not change directory
Could not open file for copy
Could not open file for destination
Could not write file when copying
Could not rename file
Doc.Id. HMSI-216-125
Host Application Objects 110
Command Details: File Open
Details
Command Code:
10h
Valid for:
Instance
Description
Opens a file for reading, writing or appending.
•
Command Details
Field
CmdExt[0]
Contents
Mode:
00h - Read mode
Comment
Opens a file for read only access.
01h - Write mode
CmdExt[1]
MsgData[0...n]
•
Opens a file for write only access. If the specified file does
not exist, it will be created. If the specified file already
exists, it will be overwritten.
02h - Append mode
Opens a file for writing at end-of-file. If the specified file
does not exist, it will be created. If the specified file exists,
any data written to the file will be appended at end-of-file.
Reserved (0)
Path + filename of the file to open relative to current path
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 111
Command Details: File Close
Details
Command Code:
11h
Valid for:
Instance
Description
Closes an open file.
•
Command Details
(No data)
•
Response Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]
MsgData[1]
MsgData[2]
MsgData[3]
Contents
Reserved (0)
Reserved (0)
File size (low byte)
File size
File size
File size (high byte)
Comment
The size of the closed file
Command Details: File Delete
Details
Command Code:
12h
Valid for:
Instance
Description
Deletes the specified file.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0...n]
•
Contents
Reserved (0)
Reserved (0)
Path + filename of the file to delete relative to the current path
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 112
Command Details: File Copy
Details
Command Code:
13h
Valid for:
Instance
Description
Makes a copy of a file.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
MsgData[x]
MsgData[y]...
•
Contents
Reserved (0)
Reserved (0)
Path + filename of the source file, relative to the current path
NULL (00h)
Path + filename of the destination file, relative to the current path
Response Details
(No data)
Command Details: File Rename
Details
Command Code:
14h
Valid for:
Instance
Description
Renames or moves a file.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
MsgData[x]
MsgData[y]...
•
Contents
Reserved (0)
Reserved (0)
Old path + filename, relative to the current path
NULL (00h)
New path + filename, relative to the current path
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 113
Command Details: File Read
Details
Command Code:
15h
Valid for:
Instance
Description
Reads data from a file open for reading.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
•
Contents
The number of bytes to read
Reserved (0)
Response Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
Contents
Reserved (0)
Reserved (0)
Data read from the file
Command Details: File Write
Details
Command Code:
16h
Valid for:
Instance
Description
Writes data to a file open for writing or appending.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
•
Contents
Reserved (0)
Reserved (0)
Data to write to the file
Response Details
Field
CmdExt[0]
CmdExt[1]
Contents
Bytes written
Reserved (0)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 114
Command Details: Directory Open
Details
Command Code:
20h
Valid for:
Instance
Description
Opens a directory.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
•
Contents
Reserved (0)
Reserved (0)
Path + name to the directory to open relative to the current path
Response Details
(No data)
Command Details: Directory Close
Details
Command Code:
21h
Valid for:
Instance
Description
Closes a directory.
•
Command Details
(No data)
•
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 115
Command Details: Directory Delete
Details
Command Code:
22h
Valid for:
Instance
Description
Deletes a directory in the file system. The directory must be empty to be deleted. An attempt to delete
a directory that is not empty will result in an error.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
•
Contents
Reserved (0)
Reserved (0)
Path + name to the directory to delete, relative to the current path
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 116
Command Details: Directory Read
Details
Command Code:
23h
Valid for:
Instance
Description
This command reads data from a directory previously opened for reading by the Directory Open command.
For each command sent the next directory entry (file or directory) is returned. When all entries in the
directory have been read, the response data size will be set to zero (0) and no message data will be returned, to indicate that no more entries exist in the directory.
•
Command Details
(No data)
•
Response Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]
MsgData[1]
MsgData[2]
MsgData[3]
MsgData[4]
MsgData[5]...
Contents
Reserved (0)
Reserved (0)
Size of object (low byte)
Size of object
Size of object
Size of object (high byte)
Object flags
Object name (file or directory)
Object Flags
Field
01h
02h
04h
08h
Contents
The object is a directory
The object is read only
The object is hidden
The object is a system object
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 117
Command Details: Directory Create
Details
Command Code:
24h
Valid for:
Instance
Description
Creates a directory in the file system.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
•
Contents
Reserved (0)
Reserved (0)
Path + name to the directory to create, relative to the current path
Response Details
(No data)
Command Details: Directory Change
Details
Command Code:
25h
Valid for:
Instance
Description
Change directory/path of the instance.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]...
•
Contents
Reserved (0)
Reserved (0)
Path + name to the directory to change to, relative to the current path
Response Details
(No data)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 118
Command Details: Format Disc
Details
Command Code:
30h
Valid for:
Object
Description
Formats a disc in the file system (will erase all data on the disc).
•
Command Details
Field
CmdExt[0]
CmdExt[1]
•
Contents
Disc to format. Set to zero (0)
Reserved (0)
Response Details
(No data)
12.7.1 Examples
In this section are presented examples for a couple of common cases where the end user would use the
File System Interface Object.
An imaginary folder structure will be used in the example, with the following files in the root folder:
Root
[reports]
weld_current (txt)
weld_formation (txt)
weld_info (txt)
configuration (html)
down (jpg)
index (html)
left (jpg)
navigation (js)
right (jpg)
status (html)
test (txt)
up (jpg)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 119
Read a File
The following example opens weld_info.txt in the reports folder and reads data from the file.
Start
Create a new instance. The instance number
returned will be used by subsequent commands.
InstX = Obj.Create( )
InstX.File Open( R, \reports\
weld_info.txt )
Open file for reading (CmdExt[0] = 0) and point
to the file to open. The instance can now be used
for file operations. Any directory operations will
be rejected.
data = InstX.File Read( Size )
Read Size number of bytes from the file.
No
EOF
(Zero bytes returned)
Keep reading until the Read command returns
zero (0) or the desired content has been read.
Yes
InstX.File Close( )
Obj.Delete ( InstX )
Close the file.
Delete the instance.
End
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 120
Write a File
The following example opens up the test.txt file for writing.
Start
Create a new instance. The instance number
returned will be used by subsequent commands.
InstX = Obj.Create( )
Open file for reading (CmdExt[0] = 1) and point
to the file to open. The instance can now be used
for file operations. Any directory operations will
be rejected.
InstX.File Open( W, \test.txt )
Write the desired data to the file.
InstX.File Write( data )
No
Done
Keep writing until the desired content has been
written.
Yes
InstX.File Close( )
Obj.Delete ( InstX )
Close the file.
Delete the instance.
End
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 121
List Directory Contents
The following example lists the contents of the reports directory
Start
Create a new instance. The instance number
returned will be used by subsequent commands.
InstX = Obj.Create( )
Open the report directory. The instance can now
be used for directory operations. Any file
operations will be rejected.
InstX.Directory Open( \reports\ )
Read the directory entry by entry.
data = InstX.Directory Read( )
No
Done
Keep reading until all entries have been read.
When there are no more entries, this is indicated
by a zero data size in the response.
Yes
InstX.Directory Close( )
Obj.Delete ( InstX )
Close the file.
Delete the instance.
End
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 122
12.8 Assembly Mapping Object (EBh)
Category
Extended
Object Description
This object provides support for the possibility to establish I/O connections to different sets of data
(assemblies). Assemblies represent, for example, PDOs on EtherCAT or assembly instances on
EtherNet/IP.
The sum of the sizes of all write assemblies must not exceed the maximum supported write process data
size.
If the application supports the modular device object, all ADIs within one assembly mapping must be
in slot order.
If this object is not implemented, the module will provide only one read and one write assembly on the
network.
Supported Commands
Object:
Get_Attribute (01h)
Instance:
Get_Attribute (01h)
Set_Attribute (02h)
Write_Assembly_Data (10h)
Read_Assembly_Data (11h)
Object Attributes (Instance #0)
#
1
2
3
4
11
Name
Name
Revision
Number of instances
Highest instance no.
Write PD instance list
12 Read PD instance list
Access
Get
Get
Get
Get
Get
Data Type
Array of CHAR
UINT8
UINT16
UINT16
Array of UINT16
Get
Array of UINT16
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Value
‘Assembly mapping’
01h
Number of assembly mappings
Highest assembly mapping number
List of currently present instances that can be mapped to
write process data
List of currently present instances that can be mapped to
read process data
Doc.Id. HMSI-216-125
Host Application Objects 123
Instance Attributes (Instance #1)
#
Name
Access
1
Assembly
descriptor
Get
2
ADI Map 0 Get/Seta
ADI Map 1 Get/Seta
3
... ...
...
12 ADI Map 10 Get/Seta
Type (if using 263 bytes Type (if using 1536 bytes
Description
message size)
message size)
UINT32
UINT32
Bit 0:
0 = Write assembly
1 = Read assembly
Bit 1:
0 = ADI Map is static
1 = ADI Map is dynamic
Bits 2 - 31: 0 = Reserved
Array of BITS32[0-61]
Array of BITS32[0-379]
Array of ADI items populating this
Array of BITS32[62-123] Array of BITS32[380-759] assembly. See “ADI Map” on page
123
...
...
Array of BITS32[620-681] Array of BITS[3800-4095]
a. Set shall only be supported if dynamic remapping is allowed from the network, i. e. if bit 1 in the assembly descriptor is set to “1”.
ADI Map
The ADI mapping can be split into multiple attributes, each with a maximum size of 380 ADI items.
Each ADI map attribute must be fully populated with 380 ADI items before using the next attribute.
For applications using the 255 bytes messaging interface, this means that a maximum of 62 ADI map
items can be used.
The ADI item format:
Bits
0-15
16-23
24-31
Description
ADI number
Index of first element to map
Number of consecutive elements to map
Upon a network connection to a read assembly, the Anybus CompactCom module will read all ADI map
attributes and generate matching Remap_ADI_Read_Area commands.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 124
Command Details: Write_Assembly_Data
Details
Command Code:
10h
Valid for:
Instance
Description
This command is used to write data to all ADIs within a read assembly mapping.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-n]
•
Contents
Reserved (0)
Reserved (0)
Assembly data
Response Details
The application can accept the write request, or send an error response.
- If the written assembly contains an ADI currently mapped to the process data channel, and
the Anybus CompactCom module state is PROCESS_ACTIVE, then it is recommended to
NAK the request and send error response: “Attribute controlled from another channel”.
- Requests where the assembly data size is incorrect shall generate an error response with error
“Not enough data”, “Too much data” or “Segmentation data overflow”.
Command Details: Read_Assembly_Data
Details
Command Code:
11h
Valid for:
Instance
Description
This command is used to read data from all ADIs within a read assembly mapping.
•
Response Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-n]
Contents
Reserved (0)
Reserved (0)
Assembly data
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 125
12.9 Modular Device Object (ECh)
Category
Extended
Object Description
This object is used to describe a modular device. Modular devices consist of a backplane with a certain
number of “slots”. The first slot is occupied by the “coupler” which contains the Anybus CompactCom
module. All other slots may be empty or occupied by modules.
Each instance of this object describes a slot in the modular device. Instance 1 corresponds to the coupler. There are no instance attributes, but the command Get_List returns a list of the modules in the
application.
When mapping ADIs to process data, the application shall map the process data of each module in slot
order. If the application maps the process data in any other order, the Anybus CompactCom module
will enter EXCEPTION state.
IMPORTANT: The implementation of modular device functionality differs between networks. Please consult the respective Network Guides for more information.
Supported Commands
Object:
Get_Attribute (01h)
Get_List (15h)
Object Attributes (Instance #0)
#
1
2
3
4
11
Name
Name
Revision
Number of instances
Highest instance no.
Number of slots
Access
Get
Get
Get
Get
Get
Data Type
Array of CHAR
UINT8
UINT16
UINT16
UINT16
Value
‘Modular device’
01h
Number of connected modules, including the coupler
Highest connected module
Number of available slots in the backplane, including the
coupler
On most networks this attribute must not be set to a value
higher than 256
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 126
# Name
Access
12 Number of ADIs per slot Get
Data Type
UINT16
Value
Used to determine which ADI belongs to which slot,
according to the following formula:
ADI = slot * x + index + 1
slot = (ADI - 1) / x
index = (ADI - 1) MOD x
(x equals the value of THIS attribute)
For compatibility with EtherCAT, the value of this attribute
multiplied with the number of slots (attribute 11 above)
must not exceed 4096
Command Details: Get_List
Details
Command Code:
15h
Valid for:
Object
Description
This command produces a list of modules in the application. For supported list types, see “Table of List
Types” on page 127. List type 01h is mandatory.
The application shall respond with a number of module IDs equal to or less than the requested number
(less if a fewer number than requested exists in the application). If the requested starting order number
is higher than the highest instance, an empty response shall be returned. If an unsupported list type is
requested, an error response with “Invalid CmdExt[1]” shall be generated. For unoccupied slots, the value 00000000h will be returned.
The Anybus CompactCom may issue several commands with increasing item number to retrieve a complete list.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0-1]
MsgData[2]
•
Contents
Reserved (0)
List type (See “Table of List Types” on page 127)
Starting item number
Requested number of items
Response Details
Field
MsgData[0-3]
MsgData[4-7]
...
Type
UINT32
UINT32
...
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Contents
Module ID of instance ‘item number’
Module ID of instance ‘instance number + 1’
...
Doc.Id. HMSI-216-125
Host Application Objects 127
Table of List Types
List Number
00h
01h
List Type
Reserved
List of all module IDs
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 128
12.10 Sync Object (EEh)
Category
Extended
Object Description
This object contains the host application SYNC settings. For more information about how to use SYNC
in applications, see
•
“Application Status Register” on page 29
•
“SYNC” on page 17
Supported Commands
Object:
Get_Attribute (01h)
Instance:
Get_Attribute (01h)
Set_Attribute (02h)
Object Attributes (Instance #0)
#
1
2
3
4
Name
Name
Revision
Number of instances
Highest instance no.
Access
Get
Get
Get
Get
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Data Type
Array of CHAR
UINT8
UINT16
UINT16
Value
‘Sync’
01h
0001h
0001h
Doc.Id. HMSI-216-125
Host Application Objects 129
Instance Attributes (Instance #1)
#
1
2
Name
Cycle time
Output valid
Access
Get/Set
Get/Set
Type
UINT32
UINT32
Description
Application cycle time in nanoseconds
Output valid point relative to SYNC events, in nanoseconds
3
Input capture
Get/Set
UINT32
Default value: 0
Input capture point relative to SYNC events, in nanoseconds
4
Output processing
Get
UINT32
5
Input processing
Get
UINT32
6
7
Min cycle time
Sync mode
Get
Get/Set
UINT32
UINT16
8
Supported sync modes Get
UINT16
Default value: 0
Minimum required time, in nanoseconds, between RDPDI
interrupt and “Output valid”
Maximum required time, in nanoseconds, from “Input capture” until write process data has been completely written to
the Anybus CompactCom module
Minimum cycle time supported by the application
This attribute is used to select synchronization mode. It enumerates the bits in attribute 8
0: Non synchronous operation. (Default value if non synchronous operation is supported)
1: Synchronous operation
2 - 65535: Reserved. Any attempt to set sync mode to an
unsupported value shall generate an error response
A list of the synchronization modes the application supports.
Each bit corresponds to a mode in attribute 7
Bit 0: 1 = Non synchronous mode supported
Bit 1: 1 = Synchronous mode supported
Bit 2 - 15: Reserved (0)
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 130
12.11 Energy Control Object (F0h)
Category
Extended
Object Description
This object implements energy control functionality, i.e. energy specific settings, in the host application.
The implementation of this object is optional; the host application can support none, some, or all of the
attributes specified below.
Each enabled instance in the object corresponds to an Energy saving mode. The number of available
modes is device specific, and must be defined by the application. The higher the instance number, the
more energy is saved. The instance with the highest number always corresponds to the “Power off”
mode, i.e. the state where the device is essentially shut down. Instance 1 of the object represents “Ready
to operate”, i.e. the mode where the device is fully functional and does not save energy at all. Consequently a meaningful implementation always contains at least two instances, one for energy saving and
one for operating. It is recommended not to use a higher instance number than 9.
Please note that these states are always present, they are not dynamically created or deleted.
Ready to operate
Energy saving mode 1
Energy saving mode 2
Energy saving mode n-1
Energy saving mode n
Power off
Mandatory transition
Optional transition
Supported Commands
Object:
Get Attribute
StartPause
EndPause
Instance: Get Attribute
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 131
Object Attributes (Instance #0)
#
1
Name
Name
2
3
Revision
Access
Get
Get
Get
Data Type
Value
Array of CHAR ‘Energy
Control’
UINT8
01h
UINT16
-
First Revision of object
Number of instances in object
Highest instance no.a
11 Current Energy Saving
mode
Get
UINT16
-
Highest created instance number (max. 65534)
Get
UINT16
-
12 RemaingTimeToDestinationb
Get
UINT32
FFFFFFFFh
(Default)
13 EnergyConsumptionToDestination
Get
FLOAT
0.0 (Default,
also used if
the value is
undefined.)
Instance number of the currently used Energy
Saving mode. “Ready to operate” will equal 1
and “Power off” will equal Highest instance
number.
When changing mode this parameter will reflect
the actual time (in milliseconds) remaining until
the mode transition is completed. c
When changing mode this parameter will reflect
the energy (in kWh) that will be consumed until
the mode transition is completed.c
a
Number of instances
4
Description
Object Name
a. Attribute 3 and 4 will hold the same value, as the highest created instance number always equals the number of
instances.
b. If the value of this attribute is infinite or unknown, the maximum value of FFFFFFFFh shall be used. If the value is
zero, 00000000h shall be used.
c. If a dynamic value can not be generated, the static value for the transition from the source to destination mode
shall be used.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 132
Instance Attributes (Instance #n)
Extended
#
Name
Access
Type
1
ModeAttributes
Get
UINT16
Default Valuea
0
2
TimeMinPauseb
Get
UINT32
0
Minimum pause time, tpause (ms)c
3
TimeToPauseb
Get
UINT32
0
Expected time to go to this energy saving
state, toff (ms)c
4
TimeToOperateb
Get
UINT32
0
Time needed to go the “Ready to operate”
state, ton (ms)c
5
TimeMinLengthOfStayb Get
UINT32
0
The minimum time that the device must
stay in this state, toff_min (ms)c
6
TimeMaxLengthOfStayb Get
UINT32
FFFFFFFFh
7
ModePowerConsump- Get
tion
EnergyConsumptionTo- Get
Pause
EnergyConsumptionTo- Get
Operate
FLOAT
0.0d
FLOAT
0.0d
FLOAT
0.0d
The maximum time that it is allowed to
stay in this state (ms)
Amount of energy consumed in this state
(kW)
Amount of energy required to go to this
state (kWh)
Amount of energy required to go to the
“Ready to operate” state from this state
(kWh)
8
9
Comment
Bit field defining whether static or dynamic
values are available.
Bit 0: Meaning
0: Only static time and energy values
1: Dynamic time and energy values
Bit 1-15: reserved
a. If an attribute is not implemented, this value will be used instead.
b. If the value of this attribute is infinite or unknown, the maximum value of FFFFFFFFh shall be used. If the value is
zero, 00000000h shall be used.
c. toff + toffmin + ton = tpause, see picture below.
d. The value 0.0 is also used if the value of the attribute is undefined.
Ready to
operate
Energy saving
mode x
Toff
Toff_min
Ton
Time
Tpause = Toff + Toff_min + Ton
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 133
Command Details: StartPause
Details
Command Code:
10h
Valid for:
Instance
Description
The module issues this command to the host application when the system wants to initialize a pause of
the system. The length of the pause is specified in milliseconds. The response contains the destination
mode, i.e. the instance number of the selected energy saving state. The command is always issued towards the object itself.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
MsgData[0]
MsgData[1]
MsgData[2]
MsgData[3]
•
Contents
Comments
(not used)
Pause time (low word, low byte) Pause time (ms)
Pause time (low word, high byte)
Pause time (high word, low byte)
Pause time (high word, high byte)
Response Details
Field
CmdExt[0... 1]
MsgData[0]
MsgData[1]
Contents
(reserved)
Instance number (low byte)
Instance number (high byte)
Comments
(set to zero)
Instance number of the selected Energy mode
If the application does not change modes, the error code “ABP_ERR_OUT_OF_RANGE” (0Ch) is
returned.
See also...
•
“Command Details: EndPause” on page 134
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Host Application Objects 134
Command Details: EndPause
Details
Command Code:
11h
Valid for:
Instance
Description
The module issues this command to the host application when the system wants to return the system
from a pause mode back to “Ready to operate” mode. The response contains the number of milliseconds needed to return to “Ready to operate” mode. The command is always issued towards the object
itself.
•
Command Details
Field
CmdExt[0]
CmdExt[1]
•
Contents
-
Comments
(not used)
Response Details
Field
CmdExt[0... 1]
MsgData[0]
MsgData[1]
MsgData[2]
MsgData[3]
Contents
(reserved)
Time to operate (low word, low byte)
Time to operate (low word, high byte)
Time to operate (high word, low byte)
Time to operate (high word, high byte)
Comments
(set to zero)
Time needed to switch to “Ready to operate” mode
(ms)
If the application is unable to end the pause, the error code “ABP_ERR_INV_STAT” (0Dh) shall be
returned.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
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
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Appendix B
B. Network Comparison Chart
The Anybus CompactCom 40 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 guide.
Anybus CompactCom
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
CC-Link
PROFIBUS DP-V1
PROFINET
DeviceNet
Modbus-TCP
EtherCAT
LSB first
LSB first
MSB first
MSB first
LSB first
LSB first
LSB first
Acyclic Data Support
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Max. no. of Elements Per ADI
255
112/256a
240
255
255
32 (255)
255
254
Max. ADI Size (in bytes)
N/Ab
Ethernet
Anybus CompactCom
Doc.Rev. 2.00
POWERLINK
EtherNet/IP
Network Data Format
Item
LSB first
1524
112/256a
240
1308
512
32 (1524)
1524
Lowest Addressable ADI no.
1
1
1c
1
1
1
1
1
Highest Addressable ADI no.
65535
65535
65025
32767
65535
3839d (61424)e
57343f (16383)g
57343
Max. Write Process Data (in bytes)
1448
368
244
1308
512
1536
1486
1490
Min. Write Process Data (in bytes)
0
0
0
0
0
0
0
0
Max. Read Process Data (in bytes)
1448
368
244
1308
512
1536
1486
1490
Min. Read Process Data (in bytes)
Max. Process Data (Read + Write, in bytes)
0
0
0
0
0
0
0
0
2896
736
488
2616
1024
3072
2972
2980
Min. Process Data (Read + Write, in bytes)
0
0
1
0
0
0
0
0
Requires ‘Get/Set_Indexed_Attribute’
No
No
No
No
No
No
Yes
Yes
Requires ‘Get_Instance_Number_By_Order’
Runtime Remapping
Yesh,i
No
No
Yes
Yesh
No
Yesj
No
Yes
No
Yes
Yes
No
No
Yes
Yes
6k
Max. no. of Diagnostic Instances
6k
6k
6k
6k
6k
6k
Supports Network Reset Type 0: ‘Power-onreset’
Yes
No
No
Yes
Yes
No
Yes
Supports Network Reset Type 1: ‘Factory
default reset’
Yes
No
No
Yes
Yes
No
Yes
No
Supports SINT64
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
1
l
Yes
Supports UINT64
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Supports FLOAT
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Cycle time
1 ms
~1msm
-
250 µs
10 ms
-
100 µs
200 µs - 2147483 µs
Network Comparison Chart 137
Doc.Id. HMSI-216-125
a. Depends on ADI mapping, please consult the Anybus CompactCom 40 CC-Link Network Guide
b. The network puts no limit. The present implementation allows 30 kB / ADI.
c. 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.
d. Default.
e. If changing “Number of ADI indexing bits” and limiting ADI size.
f. Generic mode.
g. Modular device profile enabled.
h. This command is used when accessing attributes in the Parameter Object from a CIP network.
i. For modules, that support internal web pages, this command is used when the parameter web page is opened.
j. For EtherCAT products, this command (or alternatively, Get_Instance_Numbers) is used during initialization to find number of ADIs.
k. 5 minor, recoverable instances +1 major, unrecoverable instance.
l. This reset type is supported for firmware upgrade purposes.
m. At transmission speed 10 Mbps and only one Remote device occupying one station on the network. Depends on network configuration.
Appendix C
C. Industrial Ethernet Network Comparison
The Anybus CompactCom 40 series product family support a number of Industrial Ethernet networks.
In the product family there is also a Common EtherNet module, offering an Ethernet platform which
can be used as is or to which you can download the Ethernet firmware of your choice.
The tables below show what Ethernet features are available for the different networks. In the first table,
features common to the available Industrial Ethernet networks are listed. The following tables show features specific to the different networks.
Note: For in-depth information about a particular network, consult the corresponding network guide.
Anybus CompactCom
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Item
Application interfaces
Anybus CompactCom
Doc.Rev. 2.00
Network cycle time
Latency
Jitter
Max. process data (in/out, byte)
Max. parameter data (in/out, byte)
IT protocol support
Web server included
Optional HTTP forwarding
Network accessible FLASH disk
Socket communication support
EtherNet/IP
PROFINET
Modbus-TCP
EtherCAT
Ethernet POWERLINK
8/16-bit DPRAM (30 ns)
SPI (max. 20 Mbit/s)
Shift register (12.5 MHz)
8/16-bit DPRAM (30 ns)
SPI (max. 20 Mbit/s)
Shift register (12.5 MHz)
8/16-bit DPRAM (30 ns)
SPI (max. 20 Mbit/s)
Shift register (12.5 MHz)
8/16-bit DPRAM (30 ns)
SPI (max. 20 Mbit/s)
Shift register (12.5 MHz)
8/16-bit DPRAM (30 ns)
SPI (max. 20 Mbit/s)
Shift register (12.5 MHz)
≥ 1 ms
≥ 250 μs
N/A
≥ 100 μs
≥ 200 μs
160 μs with 32 bytes of process
data
tbd
N/A
< 250 ns
< 15 μs
40 μs with 32 bytes of process data
tbd
N/A
< 200 ns
200 ns
1448 / 1448
1440 / 1440 including status byte
1536 / 1536
1486 / 1486
1490 / 1490
1448
1512 / 1294
248 / 248
1524 /1524
1490 / 1490
TCP, UDP, FTP, HTTP, SMTP
TCP, UDP, FTP, HTTP, SMTP
TCP, UDP, FTP, HTTP, SMTP
No
No
Yes
Yes
Yes
No
No
Yes
Yes
Yes
No
No
Yes, 28 Mbyte
Yes, 28 Mbyte
Yes, 28 Mbyte
No
No
Max 20 connections at the same
time
Max 20 connections at the same
time
Max 20 connections at the same
time
No
No
Yes
No
N/A
No
N/A
LED outputs, ABCC Diagnostic
Object, EtherNet/IP diagnostic
counter support, web site
LED outputs, ABCC Diagnostic
Object, web site, SNMP MIB2
LED, ABCC Diagnostic Object, web
site
LED outputs, ABCC Diagnostic
Object, diagnostics in ESC
LED outputs, ABCC Diagnostic
Object
Node address setting
Configuration object, DIP switch, via
network, IPconfig, HTTP
Configuration object, via network,
IPconfig, HTTP
Configuration object, DIP switch,
IPconfig, HTTP
Configuration object, DIP switch
Configuration object, DIP switch
Approvals
Network conformance
UL, cUL
UL, cUL
UL, cUL
UL, cUL
UL, cUL
Port disabling supported
Diagnostic capabilities
IT security
Safety support
PROFINET 2.31
HTTP authentication (basic +
digest), FTP password
CIP Safety, T100 IO & black channel. planned
DS301 V1.1.0
HTTP authentication (basic +
digest), FTP password
N/A (no IT support)
N/A (no IT support)
PROFIsafe, T100 IO & black channel, Q1/2015
No
FSoE, T100 IO & black channel,
planned
TBD
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Doc.Id. HMSI-216-125
Industrial Ethernet Network Comparison 139
Secure Host IP Configuration Protocol (HICP)
HMS Firmware Manager supported
CT11, EIP PlugFest
HTTP authentication (basic +
digest), FTP password
EtherCAT conformance test passed
Modbus TCP Conformance Test 3.0
2014-06-06
Appendix D
D. Object Overview
Each device in the Anybus CompactCom 40 series supports a subset of the objects, that are possible to
implement. The following tables give an overview.
For in-depth information about a particular network, consult the corresponding network guide.
Note: If the firmware of a module have been upgraded recently, these tables may be subject to update
in the next revision of this document.
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
No
No
No
Noa
Yes
Yes
Yes
Yes
No
No
No
Yes
No
No
No
No
Noa
Common
Ethernet
Yes
Yes
Yes
Yes
No
No
No
Yes
No
No
No
No
No
Ethernet
POWERLINK
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
No
EtherCAT
Yes
Yes
Yes
Yes
No
No
No
Yes
No
No
No
Yes
No
Modbus-TCP
Noa
Yes
Yes
Yes
Yes
No
Yes
No
Yes
No
No
No
No
No
DeviceNet
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
No
PROFINET
Anybus Object
Diagnostic Object
Network Object
Network Configuration Object
Socket Interface Object
Network CC-Link Object
SMTP Client Object
Anybus File System Interface Object
Network Ethernet Object
CIP Port Configuration Object
Network PROFINET IO Object
PROFIBUS DP-V0 Diagnostic Object
Functional Safety Module Object
PROFIBUS DP-V1
01h
02h
03h
04h
07h
08h
09h
0Ah
0Ch
0Dh
0Eh
10h
11h
CC-Link
EtherNet/IP
Anybus Module Objects
Yes
Yes
Yes
Yes
No
No
No
Yes
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
No
No
No
a. Under development.
Anybus CompactCom
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Object Overview 141
No
No
Yes
No
No
No
No
No
No
No
Yes
No
No
No
No
No
Yes
Yes
No
Yes
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
No
No
Yes
No
No
No
Yes
Yes
a
Yes
No
No
No
No
Yes
No
Yes
No
No
Yes
No
Yes
Yes
No
Yes
No
No
No
No
No
No
Yes
No
Yes
Yes
No
No
No
No
No
No
No
No
No
Yes
Yes
No
No
Yes
Yes
Yes
Yes
No
Yes
No
Yes
No
No
No
No
No
No
No
Yes
Yes
EtherCAT
No
Yes
PROFINET
No
No
No
No
a
Common
Ethernet
Yes
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
No
No
No
Yes
Yes
No
No
Ethernet
POWERLINK
No
No
Yes
No
No
Modbus-TCP
a
DeviceNet
E9h POWERLINK Object
EAh Application File System Interface
Object
EBh Assembly Mapping Object
ECh Modular Device Object
EDh CIP Identity Host Object
EEh Sync Object
F0h Energy Control Object
F5h EtherCAT Object
F6h PROFINET IO Object
F7h CC-Link Host Object
F8h EtherNet/IP Host Object
F9h Ethernet Host Object
FAh Modbus Host Object
FCh DeviceNet Host Object
FDh PROFIBUS DP-V1 Object
FEh Application Data Object
FFh Application Object
Yes
PROFIBUS DP-V1
E7h Energy Reporting Object
E8h Functional Safety Object
CC-Link
EtherNet/IP
Host Application Objects
No
No
No
No
Yes
No
No
Yes
No
No
No
Yes
No
No
No
No
No
Yes
No
No
No
Yes
Yes
No
No
No
No
No
No
No
No
No
Yes
No
No
No
Yes
Yes
a. Under development.
Anybus CompactCom
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Appendix E
E. Runtime Remapping of Process Data
This appendix describes how to handle a request from the network to remap read or write process data.
The functionality is available on EtherNet/IP, EtherCAT, PROFINET, PROFIBUS, and Ethernet
POWERLINK.
E.1 SPI Mode
In SPI mode, telegrams are sent in full duplex. In the pictures this is illustrated by showing MISO and
MOSI telegrams adjacent to each other. For more information on the SPI mode see “SPI Host Communication” on page 36.
E.1.1 Read Process Data
When the application has received a Remap_ADI_Read_Area request from the Anybus CompactCom
40 and has acknowledged the request, the Anybus CompactCom 40 will start sending read process data
to the application according to the new mapping, the next time it receives new process data from the
network. Not updated read process data will be sent according to the old mapping.
The Anybus CompactCom 40 sends Remap_ADI_Read_Area requests to the application in states
where the read process data is inactive/invalid. Valid process data according to the new mapping will
typically not be detected until the next time the Anybus CompactCom 40 enters the PROCESS_ACTIVE state.
A p p lica tio n
MISO
MSG:
MOSI
MSG:
MISO
MSG:
Remap read
MOSI
MSG:
MISO
MSG:
MOSI
MSG:
Anybus
CompactCom
RPD1
WPD
RPD1
WPD
H a n d le R e m a p re a d
Remap ACK
MISO
MSG:
MOSI
MSG:
RPD1
WPD
H a n d le R e m a p A C K
RPD2
Use new read process
data map on updated
process data
(RPD2)
WPD
RPD1 = Read Process Data according to previous mapping
RPD2 = Read Process Data according to new mapping
WPD = Write Process Data
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 143
E.1.2 Write Process Data
When the application has received a Remap_ADI_Write_Area request, it sends process data according
to the new mapping starting with the SPI telegram that acknowledges the Remap_ADI_Write_Area request..
A p p lica tio n
MISO
MSG:
MOSI
MSG:
MISO
MSG:
Remap write
MOSI
MSG:
MISO
MSG:
MOSI
MSG:
Anybus
CompactCom
RPD
WPD1
RPD
WPD1
H a n d le R e m a p re a d
U se n e w write
p ro ce ss d a ta m a p
(WPD2)
Remap ACK
MISO
MSG:
MOSI
MSG:
RPD
WPD2
H a n d le R e m a p A C K
RPD
WPD2
WPD1 = Write Process Data according to previous mapping
WPD2 = Write Process Data according to new mapping
RPD = Read Process Data
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 144
E.2 Parallel Mode, 8/16 Bits, Event Driven
E.2.1 Read Process Data
When the application has received a Remap_ADI_Read_Area request from the Anybus CompactCom
40 and has acknowledged the request, the Anybus CompactCom 40 will start sending read process data
to the application according to the new mapping the next time it receives such data from the network.
The Anybus CompactCom 40 sends Remap_ADI_Read_Area requests to the application in states
where the read process data is inactive/invalid. Valid process data according to the new mapping will
typically not be detected until the next time the Anybus CompactCom 40 enters the PROCESS_ACTIVE state.
A p p lica tio n
Anybus
CompactCom
W PD
M
R e m a p re a d
RPD1
H a n d le R e m a p re a d
W PD
M
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)
RPD1 = Read Process Data according to previous mapping
RPD2 = Read Process Data according to new mapping
WPD = Write Process Data
M e ssa g e
P ro ce ss d a ta
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 145
E.2.2 Write Process Data
When the application has received a Remap_ADI_Write_Area requests, it starts sending process data
according to the new mapping to the Anybus CompactCom 40 before acknowledging the
Remap_ADI_Write_Area request.
The Anybus CompactCom 40 regards the write process data as invalid between the time it sends a
Remap_ADI_Write_Area request to the application until the remap request is acknowledged or not acknowledged.
A p p lica tio n
Anybus
CompactCom
W PD1
M
R e m a p write
RPD
H a n d le R e m a p write
W PD2
M
Use n e w write
p ro ce ss d a ta m a p
( WPD2 )
R emap A C K
H a n d le R e m a p A C K
RPD
W PD2
WPD1 = Write Process Data, according to previous mapping
WPD2 = Write Process Data, according to new mapping
RPD = ReadProcess Data
M e ssa g e
P ro ce ss d a ta
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 146
E.3 Backwards Compatible Modes
In this section is described runtime remapping of process data in parallel and serial modes, backwards
compatible to the Anybus CompactCom 30 series.
Please note that the telegrams are exchanged in a ping-pong fashion.
E.3.1 Parallel mode
Runtime remapping of process data in parallel mode is rather straightforward, see figures below.
Read Process Data
A p p lica tio n
Anybus
CompactCom
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 147
Write Process Data
A p p lica tio n
Anybus
CompactCom
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 148
E.3.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
This mode is backwards compatible to Anybus CompactCom 30.
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 149
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Runtime Remapping of Process Data 150
E.4 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 40 Software Design Guide
Doc.Rev. 2.00
m
2
n
3
f
g
h
i
Doc.Id. HMSI-216-125
Appendix F
F. CRC Calculation (16-bit)
F.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.
F.2 Example
When implementing the CRC calculation algorithm, use these example strings (below) to ensure that the
algorithm yields the same results as the Anybus CompactCom module.
The array { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 } should yield the following
CRC16: { 0xb0, 0xcf }.
The array { 0x00, 0x55, 0xAA, 0xFF, 0x0F, 0x5A, 0xA5, 0xF0 } should yield the following
CRC16: { 0x11 , 0x03 }.
The array { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 } should yield the following
CRC16: { 0x77 , 0x28 }.
F.3 Code Example
This example uses a fast approach to calculate the CRC; all possible CRC-values are preloaded into two
arrays, which are simply indexed as the function increments through the message buffer.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
CRC Calculation (16-bit) 152
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 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Appendix G
G. CRC Calculation (32-bit)
G.1 Example
When implementing the CRC calculation algorithm, use these example strings (below) to ensure that the
algorithm yields the same results as the Anybus CompactCom module.
The array { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 } should yield the following
CRC32: { 0xeb 0xf4 0x72 0x27 }.
The array { 0x00, 0x55, 0xAA, 0xFF, 0x0F, 0x5A, 0xA5, 0xF0 } should yield the following
CRC32: { 0xbe 0xa7 0x3a 0x2d }.
The array { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 } should yield the following
CRC32: { 0x9a 0xf6 0x4b 0x49 }.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
CRC Calculation (32-bit) 154
G.2 Code Example
This example uses a fast approach to calculate the CRC.
const UINT8 abBitReverseTable16[] = { 0x0, 0x8, 0x4, 0xC, 0x2, 0xA, 0x6, 0xE,
0x1, 0x9, 0x5, 0xD, 0x3, 0xB, 0x7, 0xF };
const UINT32 crc_table32[] = {
0x4DBDF21CUL, 0x500AE278UL, 0x76D3D2D4UL, 0x6B64C2B0UL,
0x3B61B38CUL, 0x26D6A3E8UL, 0x000F9344UL, 0x1DB88320UL,
0xA005713CUL, 0xBDB26158UL, 0x9B6B51F4UL, 0x86DC4190UL,
0xD6D930ACUL, 0xCB6E20C8UL, 0xEDB71064UL, 0xF0000000UL
};
UINT32 CRC_Crc32( UINT8* pbBufferStart, UINT16 iLength )
{
UINT8 bCrcReverseByte;
UINT16 i;
UINT32 lCrc = 0x0;
for(i = 0; i < iLength; i++)
{
bCrcReverseByte = lCrc ^ abBitReverseTable16[ (*pbBufferStart >> 4 ) &
0xf ];
lCrc = (lCrc >> 4) ^ crc_table32[ bCrcReverseByte & 0xf ];
bCrcReverseByte = lCrc ^ abBitReverseTable16[ *pbBufferStart
& 0xf ];
lCrc = (lCrc >> 4) ^ crc_table32[ bCrcReverseByte & 0xf ];
pbBufferStart++;
}
lCrc = ((UINT32)abBitReverseTable16 [ (lCrc & 0x000000F0UL) >> 4 ] )|
((UINT32)abBitReverseTable16 [ (lCrc & 0x0000000FUL) ] ) << 4 |
((UINT32)abBitReverseTable16 [ (lCrc & 0x0000F000UL ) >> 12 ] << 8)|
((UINT32)abBitReverseTable16 [ (lCrc & 0x00000F00UL ) >> 8 ] << 12)|
((UINT32)abBitReverseTable16 [ (lCrc & 0x00F00000UL ) >> 20 ]<< 16)|
((UINT32)abBitReverseTable16 [ (lCrc & 0x000F0000UL ) >> 16 ]<< 20)|
((UINT32)abBitReverseTable16 [ (lCrc & 0xF0000000UL ) >> 28 ]<< 24) |
((UINT32)abBitReverseTable16 [ (lCrc & 0x0F000000UL ) >> 24 ]<< 28);
return lCrc;
}
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Appendix H
H. Timing & Performance
H.1 General Information
This chapter specifies timing and performance parameters that are verified and documented for each
member of the Anybus CompactCom 40 family.
The following timing aspects are measured:
Category
Startup Delay
NW_INIT Handling
Event Based WrMsg Busy Time
Event Based Process Data Delay
Parameters
T1, T2
T100
T103
T101, T102
Page
156
156
156
157
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 guides when available.
In case of questions, contact HMS.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
Timing & Performance 156
H.2 Internal Timing
H.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.5
1.5
Unit.
s
s
H.2.2 NW_INIT Handling
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 fulfill.
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
Conditions
Max.
32a
> 1 ms
> 10 ms
1
Event based application message response time
Ping-pong application response time
No. of simultaneously outstanding Anybus commands that the application can handle
a. Or maximum amount in case the network specific maximum is less.
Parameter
T100
Description
NW_INIT handling
Communication
All event based modes
Required for “quick connect” modules
Recommended for all other modules
Serial 19.2kbps
(all other modes)
Max.
100
Unit.
ms
30
10
s
s
H.2.3 Event Based WrMsg Busy Time
The Event based WrMsg busy time is defined as the time it takes for the module to return the
H_WRMSG area to the application after the application has posted a message.
Parameter
T103
Description
H_WRMSG area busy time
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Max.
500
Unit.
μs
Doc.Id. HMSI-216-125
Timing & Performance 157
H.2.4 Event Based Process Data Delay
“Read process data delay” is defined as the time from when the last bit of the network frame enters the
module, to when the RDPDI interrupt is asserted to the application.
“Write process data delay” is defined in two different ways, depending on network type.
- For software stack based cyclic/polled networks, it is defined as the time from when the
module exchanges write process data buffers, to when the first bit of the new process data
frame is sent out on the network.
- For COS (Change Of State) networks, it is defined as the time from when the application
exchanges write process data buffers, to when the first bit of the new process data frame is
sent out on the network.
A maximum delay of 500 µs for 32 byte process data is defined for compatibility with old ping-pong
performance requirements, but high performance synchronous event based modules will never have a
delay of more than 15 µs for 32 byte process data.
Parameter
Description
T101
T102
Read process data delay
Write process data delay
Recommended max for 32
byte process data
15
15
Absolute max for 32 byte
process data
500
500
Unit
μs
μs
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 guides when available.
Anybus CompactCom 40 Software Design Guide
Doc.Rev. 2.00
Doc.Id. HMSI-216-125
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