Anybus CompactCom 40 User Manual
Anybus®CompactCom™40
SOFTWARE DESIGN GUIDE
HMSI-216-125 4.0 en-US ENGLISH
Important User Information
Disclaimer
The information in this document is for informational purposes only. Please inform HMS Industrial Networks of any
inaccuracies or omissions found in this document. HMS Industrial Networks disclaims any responsibility or liability
for any errors that may appear in this document.
HMS Industrial Networks reserves the right to modify its products in line with its policy of continuous product
development. The information in this document shall therefore not be construed as a commitment on the part of
HMS Industrial Networks and is subject to change without notice. HMS Industrial Networks makes no commitment
to update or keep current the information in this document.
The data, examples and illustrations found in this document are included for illustrative purposes and are only
intended to help improve understanding of the functionality and handling of the product. In view of the wide range
of possible applications of the product, and because of the many variables and requirements associated with any
particular implementation, HMS Industrial Networks cannot assume responsibility or liability for actual use based on
the data, examples or illustrations included in this document nor for any damages incurred during installation of the
product. Those responsible for the use of the product must acquire sufficient knowledge in order to ensure that the
product is used correctly in their specific application and that the application meets all performance and safety
requirements including any applicable laws, regulations, codes and standards. Further, HMS Industrial Networks will
under no circumstances assume liability or responsibility for any problems that may arise as a result from the use of
undocumented features or functional side effects found outside the documented scope of the 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.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Table of Contents
Page
1 Preface ................................................................................................................................. 5
1.1 About this Document....... .................................. ................. ................. ............................. 5
1.2 Related Documents ........... .............. ................. ................. .................................. ............. 5
1.3 Document History .. ................. ................. .................................. ................. ................. .... 5
1.4 Document Conventions .................... ................. ............................... .................... ............. 7
1.5 Document Specific Conventions................ ................. ................. .................................. ...... 7
1.6 Trademarks................................ .............. ................. ................................................... ... 8
2 About the Anybus CompactCom 40 ................................................................................... 9
2.1 General Information .............................. ................. .................... ............................... ....... 9
2.2 Features ............... ................. ................. .................................. ................. ................. .... 9
3 Software Introduction....................................................................................................... 10
3.1 Background.................... ..................................... ............................... ........................... 10
3.2 The Object Model ........ ................. .................... ............................... ................. ............. 12
3.3 Network Data Exchange ............................. ................. ................................................... . 15
3.4 Diagnostics ................ .................... ................. .............. ................. .................... ........... 16
3.5 File System ... ............................... .................... ................. ............................... ............. 17
3.6 Modular Device ............... ................. ..................................... .............. ................. ......... 19
3.7 SYNC...... .............. ................. ................. .................................. ................. ................. .. 19
3.8 Multilingual Support ......... ................. .............. .................... ................. ................. ......... 24
3.9 Firmware Download ......... ................. .................................. ................. ................. ......... 25
4 Host Communication Layer............................................................................................... 28
4.1 General Information .............................. ................. .................... ............................... ..... 28
4.2 Memory Map ........... ................. ................................................... ................. ................ 29
4.3 Communications Registers.............................. .............. ................. .................................. 30
5 Parallel Host Communication ........................................................................................... 35
5.1 Flow Control .............. .................... ................. .............. ................. .................... ........... 35
5.2 Anybus Event Driven Watchdog .................... ............................... ................. .................... 35
5.3 Application Event Driven Watchdog .......... ................. .............. ................. .................... .... 36
6 SPI Host Communication .................................................................................................. 37
6.1 General Information .............................. ................. .................... ............................... ..... 37
6.2 SPI Frame Format.............. ................. .............. ................. ............................................. 37
6.3 Interrupts ........ ................................................... ................. ......................................... 38
6.4 Message Fragmentation . ................. .............. ................. .................... ................. ............ 38
6.5 SPI Error Handling .................................. ............................... ................. .................... .... 39
6.6 Application Event Driven Watchdog .......... ................. .............. ................. .................... .... 40
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
7 Shift Register Host Communication ................................................................................. 41
7.1 General Information .............................. ................. .................... ............................... ..... 41
7.2 Reset ... ................................................... ................. ................................................... . 41
8 Serial Host Communication (UART).................................................................................. 42
8.1 General Information .............................. ................. .................... ............................... ..... 42
9 The Anybus State Machine ............................................................................................... 43
9.1 General Information .............................. ................. .................... ............................... ..... 43
9.2 State Dependent Actions ................................ ............................... .................................. 44
10 Object Messaging .............................................................................................................. 45
10.1 General Information .............................. ................. .................... ............................... ..... 45
10.2 Message Layout.............. .............. .................... ................. ................. .............. ............. 46
10.3 Message Segmentation ............. ................. ................. .................................. ................. . 46
10.4 Data Format........................ ................. ................. .................................. ................. ..... 49
10.5 Command Specification............ ................. ................................................... ................. .. 51
11 Initialization and Startup .................................................................................................. 57
11.1 General Information .............................. ................. .................... ............................... ..... 57
11.2 Startup Procedure.................................. ................. ............................... .................... .... 57
11.3 Anybus Setup (SETUP State).............. ................. ................. .............. .................... ........... 59
11.4 Network Initialization (NW_INIT State)...... ................. .................... .............. ................. ..... 60
12 Anybus Module Objects.................................................................................................... 61
12.1 General Information .............................. ................. .................... ............................... ..... 61
12.2 Object Revisions ......................... ................. ................................................... ............... 61
12.3 Anybus Object (01h) ............. ................. ................................................... ................. ..... 62
12.4 Diagnostic Object (02h) . ................. .................... ............................... ................. ............. 69
12.5 Network Object (03h) ........................ ..................................... .............. ................. ......... 74
12.6 Network Configuration Object (04h) . .................... ................. ................. .............. ............. 81
12.7 Anybus File System Interface Object (0Ah). ................. .................... .............. ................. ..... 83
12.8 Functional Safety Module Object (11h) ............. ............................... .................................. 98
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
13 Host Application Objects ................................................................................................ 105
13.1 General Information .............................. ................. .................... ............................... ... 105
13.2 Implementation Guidelines...................... ................. ................. .............. .................... .. 105
13.3 Functional Safety Object (E8h)................................ ................. ....................................... 107
13.4 Application Data Object (FEh).......... .................... ................. .............. ................. ........... 109
13.5 Application Object (FFh) .... ................. ..................................... .............. ................. ....... 118
13.6 Application File System Interface Object (EAh) ................. ................. ................................ 130
13.7 Assembly Mapping Object (EBh) .... ................. ................. .................... .............. ............. 133
13.8 Modular Device Object (ECh) ................................. .............. ................. ......................... 136
13.9 Sync Object (EEh) . .................... ................. ................. .............. .................... ................ 138
13.10 Host Application Specific Object (80h) ........... .............. ................. ................. .................. 140
A Categorization of Functionality ...................................................................................... 141
A.1 Basic........ ................. .................... ................. .............. ................. .................... ......... 141
A.2 Extended ............ .................................. ................. ................. .............. .................... .. 141
B Network Comparison ...................................................................................................... 142
B.1 Network Specific Comments . ................. .................................. ................. ................. .... 144
C Industrial Ethernet Network Comparison...................................................................... 145
D Object Overview.............................................................................................................. 147
D.1 Anybus Module Objects ....... ................. .................................. ................. ................. .... 147
D.2 Host Application Objects ... ................. .............. .................... ................. ................. ....... 148
E Conformance Test Information ...................................................................................... 149
E.1 EtherCAT .............. ................. ................. .................................. ................. ................. 149
E.2 CC-Link................ ................. .............. .................... ................. ................. .............. .... 150
E.3 Ethernet POWERLINK............... .............. ................. .................... ............................... ... 151
E.4 EtherNet/IP................................ ............................... ..................................... ............. 152
E.5 DeviceNet..... .............. ................. .................... ................. .............. ................. ........... 152
E.6 Modbus-TCP ............................. ..................................... ............................... .............. 152
F Runtime Remapping of Process Data............................................................................. 154
F.1 SPI Mode ............ .................... ................. ................. .............. .................... ................ 154
F.2 Parallel Mode, 8/16 Bits, Event Driven ................ .............. .................... ................. .......... 156
F.3 Backwards Compatible Modes................. ................................................... ................. ... 157
F.4 Example: Remap_ADI_Write_Area ........... ................. .................... .............. ................. ... 161
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
G CRC Calculation (16–bit) ................................................................................................. 162
G.1 General................................................ ................. ............................... .................... .. 162
G.2 Example .......... ..................................... ............................... ................. .................... .. 162
G.3 Code Example .. ................................................... ................. ................. ...................... 163
H CRC Calculation (32–bit) ................................................................................................. 165
H.1 Example .................................... .............. ................. ..................................... ............. 165
H.2 Code Example ......................... ................. ................. .................................. ................ 165
I Timing & Performance .................................................................................................... 166
I.1 General Information .............................. ................. .................... ............................... ... 166
I.2 Internal Timing ................. ................. ................. ................................................... ...... 166
J Backward Compatibility.................................................................................................. 168
J.1 Initial Considerations ........... ................. .................................. ................. ................. .... 168
J.2 Hardware Compatibility ........................................ ................. ................. ...................... 168
J.3 General Software ..................... ................. ................. .................................. ................ 173
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Preface 5 (176)
1 Preface
1.1 About this Document
This document is intended to provide a good understanding of the Anybus CompactCom
platform. It does not cover any of the network specific features offered by the Anybus
CompactCom 40 products; this information is available in the appropriate Network Guide.
The reader of this document is expected to be familiar with high level software design and
industrial network communication systems in general. For additional information,
documentation, support etc., please visit the support website at www.anybus.com/support.
1.2 Related Documents
Document
Anybus CompactCom M40 Hardware Design Guide
Anybus CompactCom B40 Design Guide
Anybus CompactCom Host Application Implementation Guide
Anybus CompactCom 40 Network Guides (separate document for
each supported fieldbus or network system)
Author
HMS HMSI-216-126
HMS HMSI-27-230
HMS HMSI-27-334
HMS
Document ID
1.3 Document History
Version
0.50 2013-07-02
0.60 2013-12-20
1.00 2014-03-28
1.10 2014-05-26
1.20 2014-08-15
1.21 2014-08-26
1.20 2014-11-10
1.31 2015-02-06
2.00 2015-09-24
3.0 2016-08-31
3.1 2017-04-03
3.2 2017-06-15
3.3 2017-07-10
3.4 2017-11-28
3.5 2018-03-09
3.6 2018-05-28
3.7 2018-09-19
3.8 2018-10-23 Minor corrections
Date
Description
New document
General update
Major update
Major update
Major update
Major update
Major update
Minor update
Major update
Moved from FM to DOX
Major update
CC-Link IE Field added
Misc. updates and corrections
BACnet/IP added
Misc. updates and corrections
Added attr #7 to Application Object (FFh)
Updated information on LED status register
Added appendix on backward compatibility
Added attr #8 - #11 to Application Object (FFh)
Minor updates
Misc. updates
Comparison tables updated for EPL and ECT
Misc. updates
Updates for MQTT support
®
Anybus
CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Preface 6 (176)
Version
Date
3.9 2019-03-01
4.0 2019-11-11
Description
Corrections to Module Device object description
Added info on CANopen module
Minor updates
Rebranded
Updated Anybus Ojbect (01h)
Minor updates
Changed disclaimer
®
Anybus
CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Preface 7 (176)
1.4 Document Conventions
Numbered lists indicate tasks that should be carried out in sequence:
1. First do this
2. Then do this
Bulleted lists are used for:
• Tasks that can be carried out in any order
• Itemized information
► An action
→ and a result
User interaction elements (buttons etc.) are indicated with bold text.
Program code and script examples
Cross-reference within this document: Document Conventions, p. 7
External link (URL): www.hms-networks.com
WARNING
Instruction that must be followed to avoid a risk of death or serious injury.
Caution
Instruction that must be followed to avoid a risk of personal injury.
Instruction that must be followed to avoid a risk of reduced functionality and/or damage
to the equipment, or to avoid a network security risk.
Additional information which may facilitate installation and/or operation.
1.5 Document Specific Conventions
• The terms “Anybus” or “module” refers to the Anybus CompactCom module.
• The terms “host” or “host application” refer to the device that hosts the Anybus.
• 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.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Preface 8 (176)
• A byte always consists of 8 bits.
• A word always consists of 16 bits.
1.6 Trademarks
• Anybus®is a registered trademark of HMS Industrial Networks.
• EtherNet/IP is a trademark of ODVA, Inc.
• DeviceNet is a trademark of ODVA, Inc.
•
EtherCAT®is a registered trademark and
patented technology, licensed by Beckhoff Automation GmbH, Germany.
All other trademarks are the property of their respective holders.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
About the Anybus CompactCom 40 9 (176)
2 About the Anybus CompactCom 40
2.1 General Information
The Anybus CompactCom 40 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.
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.
2.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
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 10 (176)
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Data from Fieldbus
Network Interface
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Data to Fieldbus
Network
3 Software Introduction
3.1 Background
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.
Fig. 1
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.
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.
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
HMSI-216-125 4.0 en-US
Software Introduction 11 (176)
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Data from Fieldbus
Network Interface
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Data to Fieldbus
Diagnostic Handling
Cyclic Data
Cyclic Data
Alarm
Diagnostics
Network
Acyclic Request
Acyclic Response
Acyclic Handling
Fig. 2
®
Anybus
CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 12 (176)
#1
Attributes:
#2
#3
#4
#5
Instance #1
Instance #2
Instance #3
#1
Attributes:
#2
#3
#4
#5
Object #1
(Instance #0)
3.2 The Object Model
3.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.
Fig. 3
®
Anybus
CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 13 (176)
3.2.2 Addressing Scheme
Objects, and 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.
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.
Example:
The module features an object called the “Anybus Object”, which groups common settings
relating the Anybus module itself.
In this object, instance #1 contains an attribute called ‘“Firmware version”’ (attribute #2). To
retrieve the firmware revision of the module, the host simply issues a Get Attribute request to
object #1 (Anybus Object), Instance #1, Attribute #2 (Firmware version).
3.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
Host Application Objects These objects are located in the host application firmware, and may be accessed by the
module and its actions on the network.
Anybus module. This means that the host application must implement proper handling
of incoming object requests.
3.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®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 14 (176)
Anybus Module Objects
The following objects are implemented in the standard Anybus CompactCom 40 firmware:
• Anybus Object
• Diagnostic Object
• Network Object
• Network Configuration Object
• File System Interface Object
• Functional Safety Module Object
• Network Specific Objects
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, p. 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)
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, p. 105
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 15 (176)
Translation
Application Parameter
Application Parameter
Process Data Handling
Translation
Host Application
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Process Data Buffer*
(Read)
Object Response
*) These buffers holds data from ADI's that are mapped to Process Data.
Network
Acyclic Request
Cyclic Data
Acyclic Response
0101101101010110010011
0000101010110100111011
1000010101100000100010
0100110010111000000001
0010001101000100001010
Process Data Buffer*
(Write)
Cyclic Data
(Dedicated Channel)
Application Data
Object
ADI 1
ADI 2
ADI 3
Application Parameter
Object Request
3.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.
Fig. 4
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 40, 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
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 16 (176)
Host Application
Network
Diagnostics
Application Diagnostic & Status Handling
Diagnostic
Object
Event
Event
Event
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:
• 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...
The Anybus State Machine, p. 43
Network Object (03h), p. 74
Functional Safety Object (E8h), p. 107
3.4 Diagnostics
The Anybus CompactCom 40 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.
Fig. 5
See also...
Diagnostic Object (02h), p. 69
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 17 (176)
3.5 File System
The modules in the Anybus CompactCom 40 series have a built-in 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). 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. The file system can not be deleted.
Three directories are predefined:
VFS
Application This directory provides access to the application file system through the Application File
Firmware
The virtual file system that e.g. holds the web pages of the module.
System Interface Object (EAh) (optional). The directory can not be accessed from the
application, only from the network.
Firmware updates are stored in this directory.
In the firmware folder, it is not possible to use append mode when writing a file. Use
write mode only.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 18 (176)
Anybus
CompactCom
File system
File 1
File 2
VFS
File 1
File 2
Application
Application
File system
File A1
File A2
Directory A1
File A1:1
File A1:2
The Anybus CompactCom accesses
the application file system through the
Application File System Interface Object.
Anybus CompactCom
Application
Firmware*
* The firmware folder is available to the application
for firmware download in all modules.
Fig. 6
See also...
Anybus File System Interface Object (0Ah), p. 83
Application File System Interface Object (EAh), p. 130
Firmware Download, p. 25
Anybus CompactCom 40 Network Guides, available at www.anybus.com
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 19 (176)
3.6 Modular Device
The modular device functionality makes it possible to model a structure of the process data on
to a number of modules of different types within an application, e.g. for handling digital input or
output, analog input or output, or drives. The ADIs are distributed among the modules and the
number of ADIs per module is configurable. The modules are physically connected to a
backplane, with a 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. When
mapping ADIs to process data, the application shall map the process data of each module in slot
order.
See also:
• Modular Device Object (ECh), p. 136
• Anybus CompactCom 40 Network Guides
3.7 SYNC
3.7.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:
• Sync Object (EEh), p. 138.
• Application Status Register, p. 30
• The Anybus State Machine, p. 43 for information of the different states of the Anybus
CompactCom module.
3.7.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 attributes #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, p. 30.
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.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 20 (176)
3.7.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, p. 30
3.7.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, p. 32.
3.7.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.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 21 (176)
Cycle time
MI0/SYNC Signal
Input Capture
Output Valid
Min: “Output
Processing”
Max: “Input
Processing”
WRPD (Write Process Data)
Written to Anybus
Input Capture
Point
Output Valid
Point
RDPDI
(Read Process
Data Interrupt
From Anybus)
3.7.6 Anybus CompactCom 40 SYNC Implementation
The Goal of SYNC
To set output data to
different devices
simultaneously.
To capture input data from
different devices
simultaneously.
Fig. 7
The PLC will tell all devices in the network to set the next set of available output data at
the application, when the SYNC signal is sent.
The time when the output data is set at the application is called the Output Valid Point.
The time when the input data is available is called the Input Capture Point.
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.
The device has to follow these steps:
1. Wait for indication of new output data (indicated by the Anybus CompactCom 40 through
the RDPDI (Read Process Data Interrupt).
2. Read the output data from the Anybus CompactCom 40 when receiving the RDPDI.
3. Process the new output data so that it can be used by the host application
– copy data
– process output variables
– do calculations
– etc
4. Wait for the SYNC signal.
5. When the SYNC signal arrives:
– If “Output Valid” = 0, activate the outputs to the host application.
– If “Output Valid” > 0, start a hardware or a software timer on the positive edge of the
SYNC signal. Activate the outputs to the host application when the timer has reached
“Output Valid”.
See Buffer Control Register, p. 31 and Interrupt Status Register, p. 32 for more information on
RDPD (Read Process Data) and RPDPI (Read Process Data Interrupt)
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 22 (176)
Handling of Input Data
Each device needs time to capture, prepare and send new input data. This time is not constant.
The device has to follow these steps:
1. Wait for the SYNC signal.
2. When the SYNC signal arrives (“Input Capture” point):
– If “Input Valid” = 0, capture the current input process variables of the host application.
– If “Input Valid” > 0, start a hardware or a software timer on the positive edge of the
SYNC signal. Capture the current input process data when the timer has reached “Input
Valid”.
3. Prepare the new input process data so that it can be written to theAnybus CompactCom 40.
4. Write the new process input data to theAnybus CompactCom 40.
Host Application Programming Guidelines
See Sync Object (EEh), p. 138 for more information.
1. Implement the SYNC Object (part 1)
7
Sync mode
8
Supported sync modes
Get/Set
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
40
Minimum cycle time supported by the
application (in nanoseconds)
The time elapsed between receiving an 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 Anybus CompactCom 40 asks for attribute #4
“Output processing”. The network master has to make sure that the minimum output
processing time is longer than the maximum time measured.
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 Anybus 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 write process data has been written
to the Anybus CompactCom 40). This value must be provided by the application when the
Anybus CompactCom 40 asks for attribute #6 “Min cycle time”.
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 23 (176)
3. Implement the SYNC Object (part 3)
1
Cycle time
2
Output valid
3 Input capture
Get/Set
Get/Set
Get/Set
UINT32
UINT32
UINT32
Application cycle time in nanoseconds
Output valid point relative to SYNC events, in
nanoseconds
Default value: 0
Input capture point relative to SYNC events, in
nanoseconds
Default value: 0
These three attributes can all be set by the Anybus CompactCom 40.
Using attribute #1, “Cycle time”, theAnybus 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 Anybus 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 capture 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, p. 30 for more information.
5. Act upon receiving an RDPDI and a SYNC signal
When receiving an RDPDI interrupt, read the output process data from the Anybus
CompactCom 40, 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:
a. Transfer the output process variables to the application immediately.
b. Capture all input process variables immediately.
c. Prepare and assign the input process variables to the input process data.
d. Write the input process data to the CompactCom.
Steps b, c and d must be done within the time specified by attribute #5 “Input processing”.
Steps a and b assumes Output Valid and Input Capture to be zero (0).
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 24 (176)
Cycle time
MI0/SYNC Signal
Max: “Input
Processing”
WRPD Written to
Anybus
Output Valid Point
and
Input Capture Point
The Easiest Realization of a Synchronous Application
Fig. 8
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 Anybus CompactCom 40.
– Read the output data from the Anybus CompactCom 40 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 depend on 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 in all applications where the process data handling
can be made fast and simple.
3.8 Multilingual Support
Where applicable, the Anybus CompactCom 40 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 CompactCom 40 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
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 25 (176)
• Italian
• French
See also...
Application Object (FFh), p. 118
3.9 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.
3.9.1 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 40 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 40.
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, p. 57
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Software Introduction 26 (176)
3.9.2 Using Firmware Manager II
This tool is available without cost from www.anybus.com. It can be used to download new
firmware for any Anybus CompactCom 40.
Fig. 9
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. Click
Yes to 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
HMSI-216-125 4.0 en-US
Software Introduction 27 (176)
3.9.3 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.
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), p. 130
3.9.4 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), p. 130
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Host Communication Layer
4 Host Communication Layer
4.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.
4.1.1 Communication Basics
The communication between the host and the Anybus CompactCom 40 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.
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.
28 (176)
Anybus®CompactCom™40 Software Design Guide
HMSI-216-125 4.0 en-US
Loading...