Anybus-M-4014-ABS M Parallel DG 2 08 SCM-1200-015

Anybus-M-4014-ABS M Parallel DG 2 08 SCM-1200-015
Parallel Interface Design Guide
Anybus -S Slave & Master
®
Doc.Id. SCM-1200-015
Rev. 2.08
HMS Industrial Networks AB

Germany + 49 - 721 - 96472 - 0
Japan
+ 81 - 45 - 478 -5340
Sweden
+ 46 - 35 - 17 29 20
U.S.A.
+ 1 - 312 - 829 - 0601
France
+ 33 - 3 89 32 76 76
Italy
+ 39 - 347 - 00894 - 70
China
+ 86 - 10 - 8532 - 3183

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Table of Contents
Table of Contents
Preface
About This Manual
How To Use This Manual .................................................................................................................. P-1
Important User Information .............................................................................................................. P-1
Related Documentation ...................................................................................................................... P-2
Document History ............................................................................................................................... P-2
Conventions Used in This Manual .................................................................................................... P-3
Support .................................................................................................................................................. P-3
Chapter 1
Introduction
Key Features ..........................................................................................................................................1-1
Internals ..................................................................................................................................................1-2
External View ........................................................................................................................................1-3
Chapter 2
Application Connector
Connector Pinout..................................................................................................................................2-1
Control Signals.......................................................................................................................................2-2
Address Inputs (A0 ... A11) .......................................................................................................2-2
Data Input / Output (D0 ... D7)................................................................................................2-2
Busy Signal (BUSY) ....................................................................................................................2-2
Interrupt Request (IRQ) ...............................................................................................................2-2
Output Enable (OE)....................................................................................................................2-2
Read/Write (R/W).....................................................................................................................2-2
Chip Enable (CE) .......................................................................................................................2-2
Reset (RESET) ...........................................................................................................................2-3
Asynchronous Serial Interface ............................................................................................................2-3
Transmit Data (TxD) .................................................................................................................2-3
Receive Data (RxD).....................................................................................................................2-3
Chapter 3
Memory Map
Table of Contents II
Chapter 4
Control Register Area
Registers..................................................................................................................................................4-2
Module Bootloader Version (7C0h - 7C1h, RO) .........................................................................4-2
Application Interface Software Version (7C2h - 7C3h, RO) ........................................................4-2
Fieldbus Software Version (7C4h - 7C5h, RO)...........................................................................4-2
Module Serial Number (7C6h - 7C9h, RO)................................................................................4-2
Vendor ID (7CAh - 7CBh, RO) ................................................................................................4-2
Fieldbus Type (7CCh - 7CDh, RO) ............................................................................................4-3
Module Software Version (7CEh - 7CFh, RO)...........................................................................4-3
Watchdog Counter Input (7D2h - 7D3h, R/W) .........................................................................4-3
Watchdog Counter Output (7D4h - 7D5h, RO)..........................................................................4-4
LED Status (7DAh - 7DFh, RO).............................................................................................4-4
Module Type (7E0h - 7E1h, RO) ...............................................................................................4-4
Module Status (7E2h - 7E3h, RO).............................................................................................4-5
Changed Data Field (7E4h - 7EBh, R/W)................................................................................4-6
Event Notification Cause (7ECh - 7EDh, R/W).......................................................................4-6
Event Notification Source (7EEh - 7EFh, RO) ..........................................................................4-7
Input I/O Length (7F0h - 7F1h, RO)........................................................................................4-7
Input DPRAM Length (7F2h - 7F3h, RO)...............................................................................4-7
Input Total Length (7F4h - 7F5h, RO) ......................................................................................4-8
Output I/O Length (7F6h - 7F7h, RO) .....................................................................................4-8
Output DPRAM Length (7F8h - 7F9h, RO) ............................................................................4-8
Output Total Length (7FAh - 7FBh, RO)..................................................................................4-8
Chapter 5
Handshaking & Indication Registers
Application Indication Register (7FEh, R/W) .................................................................................5-2
Anybus Indication Register (7FFh, RO)............................................................................................5-3
Collisions ................................................................................................................................................5-4
Area Allocation/De-allocation............................................................................................................5-5
Unsynchronized Data Exchange...................................................................................................5-5
Synchronised Data Exchange........................................................................................................5-6
Requesting/Releasing Multiple Areas Simultaneously ...................................................................5-7
Application Example, Cyclic Access Method ................................................................................5-8
Chapter 6
Interrupts
Hardware Interrupt (IRQ) ...................................................................................................................6-1
Event Notification (Software Interrupt)............................................................................................6-2
Chapter 7
Fieldbus Data Exchange
Basics.......................................................................................................................................................7-1
Dual Port Memory vs. Internal Memory ...........................................................................................7-2
Data types...............................................................................................................................................7-2
Data Composition.................................................................................................................................7-3
Table of Contents III
Chapter 8
Mailbox Interface
General....................................................................................................................................................8-1
Message Types .......................................................................................................................................8-2
Mailbox Notification Bits.....................................................................................................................8-2
Sending a Mailbox Message..........................................................................................................8-3
Receiving a Mailbox Message........................................................................................................8-3
Mailbox Message Structure ..................................................................................................................8-4
Message Header.....................................................................................................................................8-4
Message ID ..................................................................................................................................8-5
Message Information .....................................................................................................................8-5
Command Number.......................................................................................................................8-5
Data Size.....................................................................................................................................8-5
Extended Words 1 ... 8................................................................................................................8-5
Chapter 9
Mailbox Messages
Application Messages ...........................................................................................................................9-1
Start Initialization (START_INIT)...........................................................................................9-2
Anybus Initialization (Anybus_INIT) ........................................................................................9-3
End Initialization (END_INIT)................................................................................................9-6
Save to FLASH (SAVE_TO_FLASH).................................................................................9-7
Load from FLASH (LOAD_FROM_FLASH).....................................................................9-8
Hardware Check (HW_CHK)....................................................................................................9-9
Fieldbus Messages ...............................................................................................................................9-10
Internal Memory Messages ................................................................................................................9-11
Read Internal Input Area (RD_INT_IN)................................................................................9-12
Write Internal Input Area (WR_INT_IN) ..............................................................................9-13
Clear Internal Input Area (CLR_INT_IN).............................................................................9-14
Read Internal Output Area (RD_INT_OUT) .........................................................................9-15
Reset Messages ....................................................................................................................................9-16
Software Reset (SW_RESET) ..................................................................................................9-16
Chapter 10
Start Up and Initialization
Introduction .........................................................................................................................................10-1
Hardware Initialization .......................................................................................................................10-2
Startup Sequence.........................................................................................................................10-2
Dual Port Memory Check (Optional) .........................................................................................10-2
Hardware Check (Optional) .......................................................................................................10-3
Software Initialization.........................................................................................................................10-3
Prepare Initialization Data.........................................................................................................10-3
Start Initialization......................................................................................................................10-3
Initialise Parameter Values.........................................................................................................10-4
Set Initial Fieldbus Data............................................................................................................10-4
End Initialization.......................................................................................................................10-4
Basic Initialization Sequence Example 1 ....................................................................................10-5
Basic Initialization Sequence Example 2 ....................................................................................10-5
Advanced Initialization Example ...............................................................................................10-6
Table of Contents IV
Chapter 11
Indication LEDs
Fieldbus Status Indicators..................................................................................................................11-1
Anybus-S Watchdog LED .................................................................................................................11-1
Chapter 12
Firmware Upgrade
Chapter 13
Driver Example
Interrupt Handler ................................................................................................................................13-2
Interface Handler ................................................................................................................................13-3
Mailbox Handler..................................................................................................................................13-4
Chapter 14
Mechanical Aspects
PCB Measurements.............................................................................................................................14-1
Height Restrictions..............................................................................................................................14-1
Mounting Holes...................................................................................................................................14-2
Application Connector .......................................................................................................................14-2
Fieldbus Connector(s) ........................................................................................................................14-2
Fieldbus Status Indication LED’s.....................................................................................................14-3
Appendix A Extended Memory Mode (4K DPRAM)
Appendix B Deviances
General................................................................................................................................................... B-1
Locked Release Behavior .................................................................................................................... B-1
Application Interface Hardware Deviances ..................................................................................... B-2
Appendix C Interrupt Line and Hardware Reset
Recommended Solution ...................................................................................................................... C-2
Appendix D Electrical Specification
Power Supply Requirements...............................................................................................................D-1
Signal Characteristics ...........................................................................................................................D-2
PE & Shielding Recommendations ...................................................................................................D-2
Appendix E Environmental Specification
Temperature.......................................................................................................................................... E-1
Relative Humidity................................................................................................................................. E-1
EMC compliance.................................................................................................................................. E-1
Table of Contents V
Appendix F Conformance with Predefined Standards
Fieldbus Certification........................................................................................................................... F-1
CE-Mark ................................................................................................................................................ F-1
UL/cUL-Certificate ............................................................................................................................. F-1
Appendix G Troubleshooting
Preface
About This Manual
How To Use This Manual
This design guide is intended to provide a good understanding of the functionality shared by the
Anybus-S and Anybus-M range of communication modules. It does however not cover any of the fieldbus specific features offered by the various Anybus types; this information is instead available as separate
fieldbus appendices.
All fieldbus systems are different. In order to cover these differences, deviances from what is described
in this document may occur. For more information, see B-1 “Deviances”.
For more information about development tools, sample code etc., please visit the HMS website,
‘www.anybus.com’.
Important User Information
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 application meets all performance and safety requirements including any applicable laws, regulations, codes, and standards.
Anybus® is a registered trademark of HMS Industrial Networks AB. All other trademarks are the property of their respective holders.
About This Manual P-2
Related Documentation
Document
Anybus-S API Reference Manual
Anybus-S Fieldbus Appendices (one for each fieldbus)
Data sheet for dual port memory (CY7C136)
Understanding Asynchronous Dual-Port RAMs (application note)
Author
HMS (www.hms-networks.com)
Cypress (www.cypress.com)
Document History
Summary of Recent Changes (2.07...2.08)
Change
Updated support information
Updated fieldbus type table
Page(s)
P-3
4-3
Revision List
Rev.
2.00
2.01
2.02
Date
2004-02-19
2004-06-17
2005-07-19
Author
PeP
ToT
PeP
2.03
2008-10-14 HeS
2.04
2009-09-10 KeL
2.05
2.06
2.07
2.08
2009-11-13
2010-01-12
2010-04-16
2010-12-17
KeL
KeL
KeL
KeL
Chapter
All
4
9
D
2
2
10
14
1,9
6, 8,D,12,4,
5, B
4, 5, A
6, 7, D
4
P, 4
Description
Second major release
Corrected online/offline indication for ‘Module Status Register’
Corrected Anybus_INIT response (Fault Information)
Corrected signal levels (Reset signal)
Corrected pull-up resistance & decoupling (Reset signal)
Renamed /CS, /RD, /WR to CE, OE, R/W
Updated exclusions during Dual Port Memory Check
Corrected DCP measures in drawing
Misc. minor updates
Misc. minor updates
Misc. minor updates
Misc. minor updates
Minor update
Minor update
About This Manual P-3
Conventions Used in This Manual
The following conventions are used throughout this manual:
•
Numbered lists provide sequential steps
•
Bulleted lists provide information, not procedural steps
•
The term ‘module’ is used when referring to the Anybus module
•
The term ‘application’ is used when referring to the hardware that is connected to the Anybus
Application Connector
•
Hexadecimal values are written in the format NNNNh, where NNNN is the hexadecimal value.
•
All measurements expressed in this document have a tolerance of ±0.25mm unless otherwise
stated.
•
16/32 bit values are generally stored in Motorola (big endian) format unless otherwise stated.
Support
HMS Sweden (Head Office)
E-mail:
Phone:
Fax:
Online:
[email protected]
+46 (0) 35 - 17 29 20
+46 (0) 35 - 17 29 09
www.anybus.com
HMS North America
E-mail:
Phone:
Toll Free:
Fax:
Online:
[email protected]
+1-312-829-0601
+1-888-8-Anybus
+1-312-738-5873
www.anybus.com
HMS Germany
E-mail:
Phone:
Fax:
Online:
[email protected]
+49-721-96472-0
+49-721-964-7210
www.anybus.com
HMS Japan
E-mail:
Phone:
Fax:
Online:
[email protected]
+81-45-478-5340
+81-45-476-0315
www.anybus.com
HMS China
E-mail:
Phone:
Online:
[email protected]
+86 10 8532 3023
www.anybus.com
About This Manual P-4
HMS Italy
E-mail:
Phone:
Fax:
Online:
[email protected]
+39 039 59662 27
+39 039 59662 31
www.anybus.com
HMS France
E-mail:
Phone:
Fax:
Online:
[email protected]
+33 (0) 3 89 32 76 41
+33 (0) 3 89 32 76 31
www.anybus.com
Chapter 1
Introduction
The Anybus-S/Anybus-M is a series of interchangeable fieldbus communication modules featuring on
board memory and processing power. All software and hardware functionality required to communicate
on the fieldbus is incorporated in the module itself, allowing the application to focus on other tasks.
The interface towards the application is based on a dual port memory architecture, where the host application and the Anybus module exchange data via a shared memory area. This allows for very efficient
data exchange, and generally produces very little overhead for the host application.
Standardisation of mechanical, electrical and software interfaces ensures that the different Anybus-S/
Anybus-M models are fully interchangeable. This also means that the same PCB layout can be used for
different fieldbus systems.
Typical applications are frequency inverters, HMI and visualization devices, instruments, scales, robotics, PLC’s and intelligent measuring devices.
Note: The application interface of the Anybus-M is identical to that of the Anybus-S. Therefore, all further references in this manual will be made to the Anybus-S; The information does however apply equally to the Anybus-M.
Key Features
•
Interchangeable (Uniform software interface regardless of fieldbus type)
•
Slave and Master versions available
•
All major fieldbus systems supported through a common application interface
•
On board CPU relieves host system from time consuming network related tasks
•
Pre-certified for all fieldbus networks (where applicable)1
•
Mailbox interface
•
2KB Dual Port Ram (DPRAM)2 architecture
•
Up to 2048 bytes of Input / Output data2
•
On board configuration switches (where applicable)
•
On board LED indications
•
Galvanically isolated fieldbus interface (where applicable)
•
CE, UL & cUL certified
1. See F-1 “Fieldbus Certification”.
2. Some Anybus-S versions offer more DPRAM and I/O data. For more information, see A-1 “Extended
Memory Mode (4K DPRAM)”
Introduction 1-2
Internals
Below is a schematic overview of a typical Anybus-S module; the application interface, the internal data
path, and the fieldbus interface.
LED's
Switches
Fieldbus Interface
Physical Network
Layer
Isolation
CPU
FLASH
Internal
Memory
RESET
IRQ
BUSY
Fieldbus Control
OE
R/W
CE
Dual Port Memory (DPRAM)
D0..D7
Fieldbus
A0..A11
Application Connector
Address/Databus
Application Interface
DC
DC
Application Interface
From an external point of view, the application interface is a common 8 bit parallel slave port interface
that can easily be incorporated into any microprocessor based system that has an address/data type bus.
Additionally, the application interface also features a reset pin, a busy signal, and an interrupt request
signal.
Fieldbus Interface
The fieldbus interface of an Anybus-S module is galvanically isolated, and is designed according to each
fieldbus standard. The fieldbus protocol is handled entirely by the Anybus-S and requires no interaction
by the application. However, to utilize the full potential of the fieldbus, additional fieldbus specific support is included in all Anybus-S modules. It is then up to the application to exploit these features.
The Anybus-S is tested standalone and found to comply with each fieldbus standard. For more information, see F-1 “Fieldbus Certification”.
Data Exchange
Internally, the application interface is based on a dual port memory (DPRAM) architecture. This enables
the application to exchange data with the Anybus-S module via a shared memory area. Basically, in order
to exchange data on the fieldbus, all the application has to do is to read/write data from/to this area.
The data is then forwarded from/to the fieldbus by the on board CPU, i.e. all fieldbus activity is handled
completely by the Anybus-S and generally requires no interaction by the host application.
Introduction 1-3
External View
The figure below shows a typical Anybus-S module. For more information about the mechanical aspects
of the Anybus-S, see 14-1 “Mechanical Aspects”.
1
2
5
3
4
1. Application Connector
The Anybus-S is accessed through a 34-pin connector (2mm strip header). This connector features various control signals, address/databus signals and power supply. For more information,
see 2-1 “Application Connector” and Appendix 14-2 “Application Connector”.
2. Fieldbus Connector(s)
The Anybus-S provides fieldbus connectors according to each fieldbus specification.1
3. Configuration Switches
Some Anybus-S modules features on board configuration switches for fieldbus settings such as
baud rate, node address, fieldbus termination etc.
4. Fieldbus Status Indication LED’s
All Anybus-S modules features LED indications according to the fieldbus standard. For more
information, see 11-1 “Fieldbus Status Indicators” and Appendix 14-3 “Fieldbus Status Indication LED’s”.
5. Anybus-S Watchdog Led
For more information, see 11-1 “Anybus-S Watchdog LED”.
1. See F-1 “Fieldbus Certification”
Application Connector
The Anybus-S application connector features a parallel slave port
type interface. Implementing this type of interface is comparable
to implementing an 8 bit wide SRAM. This makes it easy to incorporate the module directly on the host application address/
databus.
The application connector also features an asynchronous serial
interface. Generally, this interface is used for firmware upgrades
etc., but in some cases it may be used to enable external configuration / monitoring purposes.
For mechanical details, measurements etc. see 14-2 “Application
Connector”. For further information about signal levels, power
requirements etc. see D-1 “Electrical Specification”.
A10
CE
OE
BUSY
D6
D4
D2
D0
A8
A6
A4
A2
A0
TX
+5V
NC
+5V
33
31
29
27
25
23
21
19
17
15
13
11
9
7
5
3
1
34
32
30
28
26
24
22
20
18
16
14
12
10
8
6
4
2
A11
RESET
R/W
IRQ
D7
D5
D3
D1
A9
A7
A5
A3
A1
RX
GND
NC
GND
(Top view)
Chapter 2
Connector Pinout
Note: All signals are TTL level unless otherwise stated.
Pin
Name
Description
Direction
Note
1
2
+5V
VCC
Input
GND
Ground
-
Power Supply, bus interface. See D-1 “Power Supply
Requirements”.
3, 4
NC
Isolation distance
-
(Not connected)
5
+5V
VCC
Input
6
GND
Ground
-
Power Supply, module electronics. See D-1 “Power Supply
Requirements”.
7
TxD
Transmit Dataa
Output
Asynchronous serial interface transmita
8
RxD
Receive Dataa
Input
Asynchronous serial interface receivea
9 - 12
A0 - A3
Address Inputs
Input
Address lines 0 ... 3
13
A4
Address Inputsa
Input
Address line 4a
14 - 18 A5 - A9
Address Inputs
Input
Address lines 5 ... 9
19 - 26 D0 - D7
27
BUSY
Data Input / Output
Bidirectional Databus, bits 0 ... 7
Busy Signala
Output
Active low open collector outputa
28
IRQ
Interrupt Requesta
Output
Active low open collector outputa
29
OE
Output Enable
Input
Active low input
30
R/W
Read/Write
Input
Active low input
31
CE
Chip Enablea
Input
Active low inputa
32
RESET
Reset
Input
Active low input. Internally pulled up with 35 - 75k.
33
A10
Address Inputa
Input
Address line 10a
34
A11
Address Inputb
Input
Address line 11b
a. Internally pulled up with 10k.
b. This signal is used on some Anybus modules to accommodate a larger dual port memory. On those modules,
this pin is internally pulled up with 10k. For more information, see A-1 “Extended Memory Mode (4K
DPRAM)”. Note that the use of this pin is optional. If not used, it must be left unconnected or pulled to VCC.
Note: Since the first release of the Anybus-S, several minor changes have been made to the application
interface. The information in the table above applies only to the most recent Anybus-S versions. For
more information, see B-2 “Application Interface Hardware Deviances”.
Application Connector 2-2
Control Signals
Address Inputs (A0 ... A11)
Address input pins. Selects the target location in the dual port memory. A0 contains the least significant
bit, A11 contains the most significant bit. A4, A10 and A11 is internally pulled up with 10k.
The use of A11 is optional, however it is recommended to implement it on the application as it is used
on some Anybus modules for extended memory features. If not implemented, it must be left unconnected or pulled to VCC. For more information, see A-1 “Extended Memory Mode (4K DPRAM)”. See
also B-2 “Application Interface Hardware Deviances”.
Data Input / Output (D0 ... D7)
Data output pins during read operations, or data input pins during write operations. D0 is the least significant bit, D7 is the most significant.
The target memory location is specified on the Address Inputs (A0 ... A11).
Busy Signal (BUSY)
Active low open collector output, internally pulled up with 10k.When low, this pin indicates that the
desired address is currently in use by the Anybus module, and can be used to insert wait states to stall
the current operation until the module is ready.
Interrupt Request (IRQ)
Active low open collector output, internally pulled up with 10k. When low, this pin indicates that new
information is available in the Anybus Indication Register (7FFh). It is strongly recommended to implement this signal on the host application.
Output Enable (OE)
Enables data output on D0 ... D7 when low.
Read/Write (R/W)
Enables data input on D0 ... D7 when low. Internally pulled up with 10k.
Chip Enable (CE)
Active low input (though pulled up on most modules); enables communication with the application interface. CE must only be active during access of the DPRAM. Internally pulled up with 10k unless
otherwise stated in section ‘Application Interface Hardware Deviances’.
Application Connector 2-3
Reset (RESET)
If low, a system reset is initiated.
Internally pulled up with 10k - 75k and decoupled to ground with a 10 - 100nF capacitor.
Asynchronous Serial Interface
These pins are generally used for firmware upgrades etc., see 12-1 “Firmware Upgrade”.
For signal characteristics etc., see D-2 “Signal Characteristics”.
Transmit Data (TxD)
Asynchronous serial data transmit signal. Internally pulled up with 10k. Anybus modules with 3,3 to
5V conversion of the Tx signal does not have the 10k resistor. The signal is driven high or low by the
buffer circuit instead. See also B-2 “Application Interface Hardware Deviances”.
Receive Data (RxD)
Asynchronous serial data receive signal. Internally pulled up with 10k.
Chapter 3
Memory Map
The dual port memory is subdivided into several smaller areas based on their usage, see memory map
below.
Address:
Area:
Access:
Notes:
000h - 1FFh
Input Data Area
R/W
See 7-1 “Fieldbus Data Exchange”
200h - 3FFh
Output Data Area
RO
See 7-1 “Fieldbus Data Exchange”
400h - 51Fh
Mailbox Input Area
R/W
See 8-1 “Mailbox Interface”
520h - 63Fh
Mailbox Output Area
RO
See 8-1 “Mailbox Interface”
640h - 7BFh
Fieldbus Specific Area
-
7C0h - 7FDh
Control Register Area
R/W
See 4-1 “Control Register Area”
7FEh - 7FFh
Handshake Registers
R/W
See 5-1 “Handshaking & Indication Registers”
(Consult separate fieldbus appendix)
These areas must be allocated before access. See 5-1 “Handshaking & Indication Registers”.
These areas can be accessed directly.
Note: Implementing A11 in the application will affect the memory map. See A-1 “Extended Memory
Mode (4K DPRAM)” for further information.
Chapter 4
Control Register Area
This area contains information about the Anybus module; revision, initialization parameters, fieldbus
type and status etc. This area also contains registers for Watchdog handling and Event Notification handling.
Address:
7C0h - 7C1h
Register:
Bootloader Version
Access: Notes:
RO
7C2h - 7C3h
Application Interface Software Versiona
RO
7C4h - 7C5h
Fieldbus software versiona
RO
7C6h - 7C9h
Module Serial Number
RO
Unique serial number
7CAh - 7CBh
7CCh - 7CDh
7CEh - 7CFh
7D0h - 7D1h
7D2h - 7D3h
7D4h - 7D5h
7D6h - 7D9h
Vendor ID
Fieldbus Type
Module Software Version
(reserved)
Watchdog Counter Input
Watchdog Counter Output
(reserved)
RO
RO
RO
R/W
RO
-
Manufacturer ID number (HMS, other)
Fieldbus type identifier
Software revision
7DAh - 7DDh
LED Status
RO
Current status of each fieldbus status indicator
7DEh - 7DFh
7E0h - 7E1h
7E2h - 7E3h
(reserved)
Module Type
Module Status
RO
RO
Module type, master, slave, other.
Bit information; freeze, clear etc.
7E4h - 7EBh
Changed Data Field
RO
7ECh - 7EDh
7EEh - 7EFh
7F0h - 7F1h
7F2h - 7F3h
7F4h - 7F5h
7F6h - 7F7h
7F8h - 7F9h
7FAh - 7FBh
7FCh - 7FDh
Event Notification Cause
Event Notification Source
Input I/O Length
Input DPRAM Length
Input Total Length
Output I/O Length
Output DPRAM Length
Output Total Length
(reserved)
R/W
RO
RO
RO
RO
RO
RO
RO
-
Application controlled Watchdog counter
Counter, incremented each 1ms
Bit field, indicating changes in the Output Data
Area in the Dual Port Memory
Event cause register
Configuration register for Event Notification
Input I/O size
Number of input I/O bytes in dual port memory
Total Input Data size
Output I/O size
Number of output I/O bytes in dual port memory
Total Output Data size
a. On modules with application interface versions prior to 2.00, this register is reserved and should be zero.
Note: Generally, the Control Register Area must be allocated by the application before access. However, during module initialization, it is allowed to read static data such as software revision, fieldbus type,
module type etc. without handshaking.
Control Register Area 4-2
Registers
Module Bootloader Version (7C0h - 7C1h, RO)
This register specifies the revision of the boot loader firmware within the module.
7C0h
b15 b14 b13 b12 b11 b10 b9
Major revision (BCD coded)
b8
b7
b6
b5 b4 b3 b2 b1
Minor revision (BCD coded)
b0
7C1h
Application Interface Software Version (7C2h - 7C3h, RO)
This register specifies the revision of the application interface firmware in the module.
7C2h
b15 b14 b13 b12 b11 b10 b9
Major revision (BCD coded)
b8
b7
b6
b5 b4 b3 b2 b1
Minor revision (BCD coded)
b0
7C3h
Note: On modules with application interface versions prior to 2.00, this register is reserved and set to 0.
Fieldbus Software Version (7C4h - 7C5h, RO)
This register specifies the revision of the fieldbus control firmware in the module.
7C4h
b15 b14 b13 b12 b11 b10 b9
Major revision (BCD coded)
b8
b7
b6
b5 b4 b3 b2 b1
Minor revision (BCD coded)
b0
7C5h
Note: On modules with application interface versions prior to 2.00, this register is reserved and set to 0.
Module Serial Number (7C6h - 7C9h, RO)
This register contains a unique 32 bit serial number.
Vendor ID (7CAh - 7CBh, RO)
This register indicates the manufacturer of the module.
ID #
0000h
0001h
0002h - FFFFh
Vendor
(not used)
HMS
Reserved for OEM customers
Control Register Area 4-3
Fieldbus Type (7CCh - 7CDh, RO)
This register indicates the type fieldbus interface that is featured on the module.
Type #
0001h
0005h
0010h
0011h
0015h
0020h
0025h
0035h
0040h
0045h
0065h
0082h
0083h
0084h
0086h
0087h
0089h
0090h
0091h
0093h
0094h
009Dh
Fieldbus
PROFIBUS-DP
PROFIBUS-DPV1
Interbus-S
Interbus 2Mbps (Copper & Fibre Optic)
LonWorks
CANopen
DeviceNet
FIP IO
Modbus Plus
Modbus RTU
ControlNet
Ethernet (Modbus/TCP + IT)
Ethernet (EtherNet/IP + Modbus/TCP + IT)
PROFINET
FL-net
EtherCAT
PROFINET IRT
CC-Link
AS-Interface
Ethernet (Modbus/TCP + IT) 2-port
Ethernet (EtherNet/IP + Modbus/TCP + IT) 2-port
PROFINET IRT FO
Module Software Version (7CEh - 7CFh, RO)
This register specifies the revision of the system firmware within the module.
7CEh
b15 b14 b13 b12 b11 b10 b9
Major revision (BCD coded)
b8
b7
b6
b5 b4 b3 b2 b1
Minor revision (BCD coded)
b0
7CFh
Watchdog Counter Input (7D2h - 7D3h, R/W)
This register is used to indicate to the fieldbus that the application is working properly. To accomplish
this, the application should read the contents of the Watchdog Counter Output and write it to this register.
If the difference between these registers exceeds the value specified in the Anybus_Init command during
module initialization, the module will indicate that the application is not working properly to the fieldbus. This feature can be disabled during initialization by setting the difference value to zero.
7D2h
b15 b14 b13 b12 b11 b10
Counter (high byte)
b9
b8
b7
b6
b5 b4 b3 b2
Counter (low byte)
b1
b0
7D3h
Note: The implementation and behavior of this bit depends on the fieldbus type. Consult each separate
fieldbus appendix for more information. See also B-1 “Deviances”.
Control Register Area 4-4
Watchdog Counter Output (7D4h - 7D5h, RO)
The Anybus-S firmware features an internal counter that is incremented each millisecond. This internal
counter is continuously written to this register to indicate to the application that the Anybus module is
working properly.
The maximum refresh time of this register is 50ms, i.e. the value can be updated by as much as 50 each
refresh cycle.
7D4h
b15 b14 b13 b12 b11 b10
Counter (high byte)
b9
b8
b7
b6
b5 b4 b3 b2
Counter (low byte)
b1
b0
7D5h
LED Status (7DAh - 7DDh, RO)
These registers contains the current status of each fieldbus status indicator LED, 1 byte per led.
b7
b6
b5
7DAh
7DBh
7DCh
7DDh
Value
00h
Description
LED off or not used by the module
01h
LED greena
02h
LED reda
b4
b3
Led 1 (Top left)
Led 2 (Top right)
Led 4 (Bottom left)
Led 3 (Bottom right)
b2
b1
b0
a. Due to the requirements of certain fieldbus systems, some versions of the Anybus-S may use other colours.
Consult each fieldbus appendix for more information,
Module Type (7E0h - 7E1h, RO)
This register indicates the type of the currently used module.
Type #
0001h
0101h
0102h
0201h
Module Type
Anybus DT (Obsolete)
Anybus-S (a.k.a. Anybus-S Slave)
Anybus-S Drive Profile
Anybus-M (a.k.a Anybus-S Master)
Control Register Area 4-5
Module Status (7E2h - 7E3h, RO)
This register contains various status bits. Most bits in this register corresponds to settings made in the
‘Anybus Init’ mailbox command., see 9-3 “Anybus Initialization (Anybus_INIT)”.
b15 b14 b13 b12 b11 b10
7E2h
•
(reserved)
APRS
b9
b8
CD
APFC
b7
b6
(reserved)
b5
b4
b3
b2
b1
b0
RDR
FBSPU
FBS
FBFC
FBRS
7E3h
APRS1 (Application Run/Stop)
This bit indicates if the difference between the Watchdog Counter Output and Watchdog Counter Input has exceeded the Watchdog Timeout Value specified in Anybus_INIT.
0: Application has stopped (Watchdog Timeout Value exceeded)
1: Application is running
•
CD (Changed Data Field Status)
0: Changed Data Field disabled
1: Changed Data Field enabled
•
APFC1 (Application Stopped Freeze/Clear)
0: Input data is cleared if application has stopped
1: Input data is frozen if application has stopped
•
RDR1 (Fieldbus Reset Device Request Notification)
0: No fieldbus reset device request received (or the feature is not used)
1: Fieldbus reset device request received
•
FBS1, FBSPU1 & FBFC
Bit value
1
FBSPU
1
FBS
Fieldbus Offline Action
FBFC Output I/O Data
Parameter Data
0
Clear
Clear
1
Freeze
Freeze
0
Set
Set
1
(reserved)
(reserved)
0
Clear
Update
1
Freeze
Update
0
Set
Update
1
(reserved)
(reserved)
0
0
1
0
1
1
•
Notes
All data is cleared when the fieldbus
goes off line.
All data is frozen in it’s current state
when the fieldbus goes off line.
All data is set when the fieldbus goes
offline.
On some fieldbus systems, parameter
data may still be updated via the fieldbus although the I/O data exchange is
not running.
Consult each separate fieldbus appendix for further information.
FBRS (Fieldbus On / Off Line)
1: Fieldbus online
0: Fieldbus offline
1. The implementation and behavior of this bit depends on the fieldbus type. Consult each separate fieldbus
appendix for more information. See also B-1 “Deviances”.
Control Register Area 4-6
Changed Data Field (7E4h - 7EBh, R/W)
These registers form bit fields by which the application may determine what parts of the Output Data
Area contains changed data. Each bit in these registers represents 8 bytes in the Output Data Area.
Note 1: The use of these registers will reduce the overall performance of the module.
Note 2: This register is not implemented in some versions of the Anybus-M (a.k.a. Anybus-S Master).
7E4h
7E5h
7E6h
7E7h
7E8h
7E9h
7EAh
7EBh
b7
56-63
120-127
184-191
248-255
312-319
376-383
440-447
504-511
b6
48-55
112-119
176-183
240-247
304-311
368-375
432-439
496-503
b5
40-47
104-111
168-175
232-239
296-303
360-367
424-431
488-495
b4
32-39
96-103
160-167
224-231
288-295
352-359
416-423
480-487
b3
24-31
88-95
152-159
216-223
280-287
344-351
408-415
472-479
b2
16-23
80-87
144-151
208-215
272-279
336-343
400-407
464-471
b1
8-15
72-79
136-143
200-207
264-271
328-335
392-399
456-463
b0
0-7
64-71
128-135
192-199
256-263
320-327
384-391
448-455
Event Notification Cause (7ECh - 7EDh, R/W)
This register indicates the source of an Event Notification. The bits in this register are edge triggered,
i.e. the bits are set by the module when the event occurs. Default value is 0. The application should clear
the corresponding bit when the Event Notification has been handled.
For more information regarding interrupts and Event Notification, see 6-1 “Interrupts” and 6-2 “Event
Notification (Software Interrupt)”.
b15 b14 b13 b12 b11 b10
7ECh
b9
b8
b7
b6
(reserved)
b5
b4
b3
b2
b1
b0
RST
FBON
FBOF
DC
•
RST1
0: 1: A reset request from the fieldbus has been issued.
•
FBON
0: 1: Fieldbus has gone on line
•
FBOF
0: 1: Fieldbus has gone off line
•
DC
0: 1: Data has been updated, see 4-6 “Changed Data Field (7E4h - 7EBh, R/W)”.
7EDh
1. The implementation and behavior of this bit depends on the fieldbus type. Consult each separate fieldbus
appendix for more information. See also B-1 “Deviances”.
Control Register Area 4-7
Event Notification Source (7EEh - 7EFh, RO)
This register indicates which events that will trigger an Event Notification. The contents of this register
is determined during module initialization in the mailbox command ‘Anybus Init’.
For more information regarding interrupts and Event Notification, see 6-1 “Interrupts” and 6-2 “Event
Notification (Software Interrupt)”.
b15 b14 b13 b12 b11 b10
7EEh
b9
b8
b7
b6
b5
b4
(reserved)
b3
b2
b1
b0
RST
FBON
FBOF
DC
7EFh
•
RST1
0: 1: An Event Notification will be issued each time “reset request” has been issued from the fieldbus
•
FBON
0: 1: An Event Notification will be issued when the fieldbus goes on line
•
FBOF
0: 1: An Event Notification will be issued when the fieldbus goes off line
•
DC
0: 1: An Event Notification will be issued each time the data in the Output Area has changed.
Note that this requires that the Changed Data Field has been enabled during module initialization.
Input I/O Length (7F0h - 7F1h, RO)
This holds the Input I/O Length specified during module initialization.
7F0h
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7F1h
Input DPRAM Length (7F2h - 7F3h, RO)
This holds the Input DPRAM Length specified during module initialization.
7F2h
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7F3h
1. The implementation and behavior of this bit depends on the fieldbus type. Consult each separate fieldbus
appendix for more information. See also B-1 “Deviances”.
Control Register Area 4-8
Input Total Length (7F4h - 7F5h, RO)
This holds the Input Total Length specified during module initialization.
7F4h
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7F5h
Output I/O Length (7F6h - 7F7h, RO)
This holds the Output I/O Length specified during module initialization.
7F6h
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7F7h
Output DPRAM Length (7F8h - 7F9h, RO)
This holds the Output DPRAM Length specified during module initialization.
7F8h
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7F9h
Output Total Length (7FAh - 7FBh, RO)
This holds the Output Total Length specified during module initialization.
7FAh
b15 b14 b13 b12 b11 b10
High byte
b9
b8
b7
b6
b5
b4 b3
Low byte
b2
b1
b0
7FBh
Chapter 5
Handshaking & Indication Registers
Memory locations 7FEh and 7FFh holds two important registers; the Application Indication Register
and the Anybus Indication Register. These registers serves three main purposes:
•
Area allocation and de-allocation
This procedure is mandatory when accessing the Input-, Output-, Fieldbus Specific- and Control
Register Area. For more information, see 5-5 “Area Allocation/De-allocation”.
•
Event Notification
See 6-2 “Event Notification (Software Interrupt)”.
•
Sending & Receiving Mailbox Messages
See 8-1 “Mailbox Interface”.
Generally, the Application Indication Register is used to instruct (command) the module to perform a
specific low level action. The Anybus Indication Register contains responses to previously issued commands and indicates the overall status of the module.
Application
AnyBus-S
Application Indication
Register
AnyBus-S
Software
Application Software
AnyBus Indication
Register
Although these registers are often used in a command-response like fashion, the registers are independent from each other and should be treated
accordingly. However, the application must not issue a new command until the module has responded to the previous one., see figure on the right.
Each time a response or indication is sent by the
module, the UPDATED bit (bit 3 of the Anybus
Indication Register) is toggled and a hardware interrupt is triggered. The application can then examine the Anybus Indication Register to detect the
cause of the hardware interrupt.
If the hardware interrupt feature is not implemented, the application has to cyclically poll the Anybus
Indication Register in order to detect any changes.
It is however strongly recommended to utilize the
interrupt feature, as polling suffers from unnecessary overhead and is generally harder to implement.
Application
Indication Register
AnyBus
Indication Register
Command
Response or Indication
Command
Response or Indication
Response or Indication
Response or Indication
Command
Command
WRONG!
Response or Indication
Handshaking & Indication Registers 5-2
Application Indication Register (7FEh, R/W)
This register is used to perform the following tasks:
•
Area allocation and de-allocation (a.k.a. Request / Release)
•
Acknowledge Events (Event Notification)
•
Send / Receive mailbox messages
The register consists of a bit field with the following layout:
b7
AP_MIN
Bit
AP_MIN
b6
AP_MOUT
b5
AP_EVNT
Function
Mailbox Notification
b4
ACTION
b3
LOCK
b2
AP_IN
b1
AP_OUT
b0
AP_FBCTRL
Description
Used to send a mailbox message. See 8-2 “Mailbox Notification
Bits”.
Used to acknowledge a received mailbox message. See 8-2 “MailAP_MOUT
box Notification Bits”.
AP_EVNT
Event Acknowledge
This bit should be toggled to acknowledge that an Event Notification event has been handled. See 6-2 “Event Notification (Software Interrupt)”.
ACTION
This bit indicates if the current action is a request or release:
1: Request
0: Release
Area
Request/Release.
LOCK
This bit indicates if the action is locked or unlocked.
1: Locked
These bits are used to 0: Unlocked
request or release one This bit represents the Input Data Area
AP_IN
or several areas within 1: Action is affective for this area
the dual port memory.
0: Action is not affective for this area
AP_OUT
This bit represents the Output Data Area
For more information,
1: Action is affective for this area
see 5-5 “Area Allocation/
0: Action is not affective for this area
De-allocation”.
AP_FBCTRL
This bit represents the Fieldbus Specific Area and the Control
Registers
1: Action is affective for this area
0: Action is not affective for this area
Default
0
0
0
0
0
0
0
0
Note 1: It is recommended not to access this register cyclically. It should only be used to respond to
incoming events and to make requests.
Note 2: When accessing this register, it is important to modify all bits related to the desired operation
using a single memory access, otherwise the operation might be misinterpreted as several operations by
the module.
Handshaking & Indication Registers 5-3
Anybus Indication Register (7FFh, RO)
This register contains responses to previously issued commands and indicates the status of different
functions/areas in the module. The following information can be extracted from this register:
•
Ownership of the different areas within the dual port memory
•
Event Notification status
•
Mailbox Input & Output status
•
initialization status
Each change in this register will trigger a hardware interrupt. The application can then examine the contents of the register to detect the cause of the interrupt.
It is also possible to cyclically poll the contents of this register to detect any changes, however it is strongly recommended to utilize the interrupt feature, as polling suffers from unnecessary overhead and is generally harder to implement. (For more information about interrupts, see 6-1 “Hardware Interrupt
(IRQ)”).
b7
AB_MIN
Bit
AB_MIN
b6
AB_MOUT
b5
AB_EVNT
Function
Mailbox Notification
b4
INIT
b3
UPDATED
b2
AB_IN
b1
AB_OUT
b0
AB_FBCTRL
Description
The module toggles this bit to acknowledge that it has received a
mailbox message. See 8-2 “Mailbox Notification Bits”.
The module toggles this bit to indicate that a new message is
AB_MOUT
available in the Mailbox Output area. See 8-2 “Mailbox Notification Bits”.
AB_EVNT
Event Notification
The module toggles this bit when a new Event Notification has
occurred
INIT
Module initialised
This bit indicates if the module has been initialised.
0: Module not initialised
1: Module initialiseda
UPDATED
Register updated
This bit is toggled by the module each time the contents of this
register has been updated.
AB_IN
This bit represents the Input Data Area
1: Area owned by application
Area ownership.
0: Area owned by Anybus
These
bits
indicates
the
AB_OUT
This bit represents the Output Data Area
owner of each area within 1: Area owned by application
the dual port memory.
0: Area owned by Anybus
AB_FBCTRL
This bit represents the Fieldbus Specific Area and the Control
Registers
1: Area owned by application
0: Area owned by Anybus
Default
0
0
0
0
0
0
0
0
a. Please note that due to the nature of certain fieldbus systems, this does not necessarily mean that the fieldbus
is fully initialised and exchanging data. Consult each separate fieldbus appendix for further information.
Note: This register is read only. Do not attempt to write to this register as doing so may produce unpredictable results.
Handshaking & Indication Registers 5-4
Collisions
As mentioned earlier, the application interface is based on a dual port memory architecture, where both
sides are able to access the same memory location simultaneously.
An area allocation scheme (see 5-5 “Area Allocation/De-allocation”) is used in order to prevent collisions during runtime, however this does not cover the event of a collision occurring in the Anybus and
Application Indication Registers. If this is not handled correctly, the module might not get data written
to the Application Indication Register, and data read from the Application Indication Register may be
out of date and/or incorrect.
There are three ways of dealing with collisions: (Numbered in order of importance)
1. Multiple Write / Read (Mandatory)
While the IRQ and BUSY signals are used to prevent collisions (see below), this is a way of actually
dealing with them.
- When writing to the Application Indication Register...
... keep writing and verifying until the written data is known to be correct.
- When reading from the Anybus Indication Register...
... keep reading and comparing until two consecutive reads match.
Application Indication Register Access:
AnyBus Indication Register Access:
Start
Start
Write to register
Read register
Verify
Read register
Success?
No
Same value
read twice?
Yes
Yes
Done
Done
No
Note: At first sight, it may appear as if this violates what is stated earlier on page 5-1 and in Note
1 on page 5-2, however as the accesses are carried out in rapid sequence the module will interpret
them as a single access.
2. Implement the IRQ signal in the application (Optional, but recommended)
This pin is drawn low each time the Anybus Indication Register has been updated. The application can utilize this by accessing this register instantly upon receiving the interrupt, thus avoiding
a collision.
3. Implement the BUSY signal in the application (Optional, but recommended)
If this signal goes low, the application should stall the current memory access until the signal goes
high again e.g. by inserting wait states, thus avoiding a collision. (This may however not be possible with all architectures).
General Recommendation
Preferably, all three options should be implemented in the application. Either way, option 1 should be
considered mandatory, and it is strongly recommended to implement at least one of the other two.
Handshaking & Indication Registers 5-5
Area Allocation/De-allocation
As described earlier, the dual port memory is sub divided in several areas based on their function. In
order to avoid collisions and to ensure data consistency, the application has to allocate each area before
access. If the area is free to use, the module will indicate this to the application by setting the corresponding bit in the Anybus Indication Register. The area is then considered to be “owned” by the application,
and can be accessed freely. When finished, the area must be returned, i.e. released, to the Anybus module. The area is then considered to be “owned” by the Anybus module.
This allocation procedure is mandatory when accessing the following areas:
•
Input Data Area
•
Output Data Area
•
Fieldbus Specific Area
•
Control Register Area
The application can own an area for a maximum of 1000ms. If this time is
exceeded, i.e. the application does not release the area in time, the allocation
will be terminated automatically, i.e. the ownership of the area(s) will be
handed back to the Anybus module. It is important that the software routines within the application have the capability to recognize this and terminate the access in a safe manner.
Start
Request Area
Unsynchronized Data Exchange
Wait for response
In it’s simplest form, an access sequence towards the module consists of the
following steps: (See also figure on the right)
1. Request access to an area
To accomplish this, the application should set the corresponding bit
for that area as well as the ACTION bit in the Application Indication
Register.
2. Wait for response1
Application
owns the area?
Yes
Access the area
3. Check response to see if access is granted
To know if the request was successful, the application should check
the ownership of the area in the Anybus Indication Register.
Release Area
If the desired area is owned by the application, the application is free
to access that area.
4. Release the area
To do this, the application should set the corresponding bit for that
area as well as clearing the ACTION bit in the Application Indication
Register.
Wait for response
End
5. Wait for response1
1. This can either be waiting for an interrupt or polling the Anybus Indication Register, depending on how
the application is implemented. For more information, see 5-3 “Anybus Indication Register (7FFh, RO)”
and 6-1 “Interrupts”.
No
Handshaking & Indication Registers 5-6
Synchronised Data Exchange
The procedure described earlier will result in an unsynchronized data exchange. However, in some cases
it is desirable to synchronise the data exchange between the application and the Anybus-S module.
The LOCK bit in the Application Indication Register is used for this purpose, see table below.
Action LOCK Result
Request 0
If the requested area is currently in use, the application will have to repeat the request until
access is granted.
1
If the requested area is currently in use, the module will first send a response indicating that the
area is still in use by the Anybus module. However, as soon as the area is free, the ownership of
the area will be handed over to the application (i.e. Area owned by Application).
Release 0
The area is released.
1
The area is released, and is reserved for the Anybus module. The application will not be granted
access again before the module has accessed the area.
Locked Request
A locked request ensures that the application will gain access to an area as soon as it is free.
1. Request access to the area (LOCK = 1)
2. Wait for the initial response1
3. Check the ownership of the area
Area owned by Application - the area is free to use. Proceed with step 6.
Area owned by Anybus - the area is currently in use. Proceed with step 4.
4. Wait for an additional response1
5. Check the ownership of the area
The ownership of the area is handed over to the application.2
6. Done
1. This can either be waiting for an interrupt or polling the Anybus Indication Register, depending on how
the application is implemented. For more information, see 5-3 “Anybus Indication Register (7FFh, RO)”
and 6-1 “Interrupts”.
2. If multiple areas are requested simultaneously, the module may send up to 3 additional responses, one for
each area. In these cases, the sequence of events may be slightly different from what is described above.
For more information, see 5-7 “Requesting/Releasing Multiple Areas Simultaneously”.
Handshaking & Indication Registers 5-7
Locked Release
In some cases, it makes no sense to gain access to an area unless the Anybus has accessed it first. For
example, there is no gain in polling the Output Data Area cyclically unless the application can be sure
that the data has been updated by the Anybus module between each poll.
By using the LOCK bit when releasing an area, the application can reserve the area for the Anybus module, i.e. the application will not gain access to the area until the module has updated its contents.1
1. Release the area (LOCK = 1)
2. Wait for response2
3. Done
The area is now reserved for the Anybus module, i.e. the application will not gain access to the
area until the module has updated its contents.
Requesting/Releasing Multiple Areas Simultaneously
Multiple areas can be requested or released simultaneously. However, when doing this, it is important to
monitor the response in the Anybus Indication Register to see which areas that are actually free to use
(i.e. it is possible that one or more of the areas is in use at the time of the request). This is pretty straight
forward for unlocked requests, however special care has to be taken when performing locked requests
for multiple areas.
•
Requesting multiple areas (LOCK = 0)
The module sends a single response.
•
Requesting multiple areas (LOCK = 1)
The module may in theory send up to 4 responses depending on the situation:
- The initial response.
- Up to three additional responses will be sent as the ownership of the requested areas are
handed over to the application when an area is free to use.
•
Releasing multiple areas (LOCK = 0)
The specified areas are released instantly. The module sends a single response to acknowledge
the release.B-1 “Locked Release Behavior”
•
Releasing multiple areas (LOCK = 1)
The specified areas are released instantly. The module sends a single response to acknowledge
the release. The areas are then reserved for the Anybus module, i.e. the application cannot gain
ownership of them until the Anybus has updated their contents.
1. Please note that some modules update the Output Data Area only when there are changes to the output
data. This may cause the Output Data Area to stay locked, until an external event has caused changes in
the data. For further information see B-1 “Locked Release Behavior”
2. This can either be waiting for an interrupt or polling the Anybus Indication Register, depending on how
the application is implemented. For more information, see 5-3 “Anybus Indication Register (7FFh, RO)”
and 6-1 “Interrupts”.
Handshaking & Indication Registers 5-8
Application Example, Cyclic Access Method
This example describes one method for an application that requires cyclic access to the DPRAM input
and output data areas.
Background Information
To better understand the example, here follows a description of what happens inside the module.
When the application releases the DPRAM input data area (data to fieldbus), it triggers the module to
take control of that area. The area will be owned by the module until it has finished its tasks. How long
time this will take varies according to the configuration. Once finished, the module will not require the
area until the next time the area is released by the application. The application can thus, immediately after
it has released the area (with a locked release), perform a locked request of the area. It will then gain
access to the area at once when the module releases it the next time. While waiting, it can execute other
tasks, as long as the total time does not exceed 1000 ms.
An internal OUT I/O data buffer is continuously updated by the module. When data from all slaves has
been updated, the module requests access to the DPRAM output data area (data from fieldbus). It copies
the data from the buffer to the DPRAM and then releases the output data area. The process is then repeated. The module’s access to the DPRAM output data area is thus not related to the application’s access of the area. To make sure to read the latest data, the application must perform a request of the
DPRAM output data area only when it actually needs to read the data.
Suggested Access Method for a Cyclic Application
1. Locked request of OUT
2. Wait for access of IN (requested in previous cycle)
3. Write IN data
4. Wait for access of OUT1
5. Read OUT data
6. Locked release of IN + OUT
7. Wait for ACK (both areas will be released simultaneously)
8. Locked request of IN
9. Execute PLC-cycle
10. Repeat from 1
Note: This loop needs to be entered at step number 2 after an initial locked request of the DPRAM
input and output data areas, see flowchart next page.
1. Please note that some modules update the Output Data Area only when there are changes to the output
data. This may cause the Output Data Area to stay locked, until an external event has caused changes in
the data. For further information see B-1 “Locked Release Behavior”
Handshaking & Indication Registers 5-9
Start
Locked request of
IN + OUT
Locked request of
OUT
Wait for access of
IN
Write IN data
Wait for access of
OUT
Execute
PLC-cycle
Read OUT data
Locked release of
IN + OUT
Wait for ACK
(Both areas will be
released
simultaneously)
Locked request of
IN
IN :
DPRAM input data area (data to fieldbus)
OUT : DPRAM output data area (data from fieldbus)
Cyclic access method flowchart
Chapter 6
Interrupts
Hardware Interrupt (IRQ)
The module features an interrupt request pin (IRQ, pin #28). If implemented, it can be used to notify
the application of any changes in the Anybus Indication Register. Generally, it is recommended to use
this feature as it can significantly reduce overhead compared to polling the register cyclically.
The following events will generate a hardware interrupt:
•
Event Notification (Software interrupt, see below)
•
Mailbox notification (See 8-2 “Mailbox Notification Bits”)
•
Module initialised (See 5-3 “Anybus Indication Register (7FFh, RO)”)
•
Startup interrupt (See 10-2 “Startup Sequence”)
•
Area allocation responses (See 5-5 “Area Allocation/De-allocation”)
Once the application has read the contents of the Anybus Indication Register, the interrupt is automatically cleared.
Interrupts 6-2
Event Notification (Software Interrupt)
Event Notification is a mechanism for signalling important events to the application. The following
events can generate an Event Notification:
•
Fieldbus On/Off line
•
Fieldbus reset requests
•
Data changed1
Which of the above events that should cause an Event Notification is configured during module initialization in the Event Notification Config parameter in the ‘Anybus Init’ mailbox message.
To signal that a new Event has occurred, the module will toggle bit 5 (AB_EVNT) in the Anybus Indication Register. The cause of the event can then be read in the Event Notification Cause Register, see
4-6 “Event Notification Cause (7ECh - 7EDh, R/W)”. When the event has been handled, the application should clear the corresponding bits in this register and confirm the event by toggling bit 5
(AP_EVNT) in the Application indication Register.
While an event is unconfirmed by the application, all new events are queued within the module. This
eliminates the risk of an event being missed. The module will only toggle AB_EVNT, to indicate a new
event, if it is equal to AP_EVNT. Once the application returns a confirmation and toggles AP_EVNT
to be equal to AB_EVNT, the module can indicate the next event in the queue. It’s important that the
application does not toggle bit 5 (AP_EVNT) in the Application Indication Register, unless for confirming an event. If AB_EVNT and AP_EVNT are not equal, the module will be prohibited from indicating
a new event.
The following example describes how to check if a new event has occurred, and how to handle it.
1. AB_EVNT |= AP_EVNT?
FBOF
DC
4. Clear the FBOF bit in the Event Cause
(Event Cause Register)
FBON
3. Examine the Event Cause register to find out what caused the
event. In this case, the fieldbus has gone off line (FBOF).
RST
2. If yes, an event has occurred.(If no, skip the remaining steps)
0
0
1
0
0
0
0
0
Register2
5. Perform tasks associated with fieldbus off line events2
6. Toggle AP_EVNT in the Application Indication Register to confirm the event.
Note: Event Notification is a software interrupt and should not be confused with the hardware interrupt
described earlier. However, as it uses the Anybus Indication Register, it will trigger a hardware interrupt.
1. Data change event notification does not work for I/O data mapped to Internal Memory.
2. This requires that the Fieldbus Specific / Control Register Area is owned by the application.
Chapter 7
Fieldbus Data Exchange
Basics
AnyBus-S
•
Input Data Buffer
Data written to this buffer will be sent to the fieldbus.
•
Output Data Buffer
This buffer contains data received from the fieldbus.
Input Data Buffer
(up to 2048 bytes)
Output Data Buffer
(up to 2048 bytes)
Fieldbus
The module exchanges data on the fieldbus via two data buffers:
Basically, in order to exchange data on the fieldbus, all the application has to do is to read/write data from/to these two buffers.
Note: The size and composition of the data buffers is determined during module initialization. Therefore, the module will not be able to exchange data on the fieldbus unless it has been properly initialised
first. For more information, see 10-1 “Start Up and Initialization”.
Fieldbus Data Exchange 7-2
Dual Port Memory vs. Internal Memory
Each of the two data buffers can have a portion of
their data situated in dual port memory. The remainder is located in Internal Memory. The advantage of
having data situated in dual port memory is that it can
be accessed much faster than data situated in the Internal Memory.
Internal Memory can only be accessed indirectly via
mailbox commands, and is thus better suited for less
time critical data. Data buffer data that is situated in
dual port memory can not be accessed using mailbox
messages in parallel.
It is possible to configure how much data that should
be reside in dual port memory, and how much that
should be located in Internal Memory. The maximum
size of each data buffer is 2kbytes, out of which up to
5121 bytes can be configured to reside in dual port
memory.
Data Buffer
This part of each
data buffer can be
accessed directly
Dual Port Memory
This part of each
data buffer can only
be accessed indirectly using Mailbox Commands
Internal Memory
Note: Data change event notification (software interrupt) can not be used for I/O data mapped to the
Internal Memory.
Data types
Most fieldbus systems makes a distinction between fast cyclical data and slower parameter data. This is
reflected in the way data is treated by the Anybus-S module:
•
I/O Data
This type of data is usually associated with fast fieldbus data (a.k.a. cyclic data).
•
Parameter Data
This type of data is usually associated with slow fieldbus data (a.k.a. acyclic data).
How this data is treated for each fieldbus type is described in each separate fieldbus appendix.
1. Future Anybus versions may allow a larger amount of data to reside in dual port memory, see A-1
“Extended Memory Mode (4K DPRAM)”.
Fieldbus Data Exchange 7-3
Data Composition
As mentioned earlier, the maximum total size of each data buffer is 2048 bytes. Up to 5121 of these bytes
can reside in dual port memory, the remainder is located in Internal Memory and can only be accessed
indirectly using mailbox commands.
The composition of I/O and Parameter Data is determined during the module initialization phase in the
mailbox command ‘Anybus Init’, see 9-3 “Anybus Initialization (Anybus_INIT)”.
The following parameters must be set for each (Input and Output) data buffer:
•
Total Length2
This parameter defines the total amount of fieldbus data (I/O Data + Parameter Data) for the
data buffer. The maximum Total Length is 2048 bytes regardless of DPRAM and I/O Length
settings.
•
DPRAM Length2
This parameter defines how much of data that should be located in dual port memory. The
DPRAM Length cannot exceed 5121 bytes.
•
I/O Length2
This parameter defines how much of the data that should be treated as I/O Data. The remaining
data will be treated as Parameter Data.
The figure below illustrates the relationship between the parameters described above.
Dual Port Memory
I/O Length
Internal Memory
I/O Data
DPRAM
Length
(Not used)
Parameter Data
(Not used)
Total Length
Parameter Data
(Not used)
1. Future Anybus-S versions may allow a larger amount of data to reside in dual port memory, see A-1
“Extended Memory Mode (4K DPRAM)”.
2. The maximum range of these parameters may be limited by the fieldbus. Consult each separate fieldbus
appendix for more information.
Chapter 8
Mailbox Interface
General
The mailbox interface is a message interface used to instruct the module to perform a specific task, or
to request data. It is also used by the module to indicate certain events and to respond to requests sent
by the application.
Mailbox communication is handled through the Mailbox Input and Output Areas (See figure below) and
generally does not interfere with fieldbus data exchange unless the mailbox message itself is related to
fieldbus activity.
Application
AnyBus-S
Mailbox Input Area
AnyBus-S
Software
Application Software
Mailbox Output Area
The handshaking procedure for the Mailbox Input/Output Areas is slightly different than the one used
for the other areas. For more information, see 8-2 “Mailbox Notification Bits”.
The mailbox interface supports the following types of communication:
•
Command - Response
A message is sent by the message initiator, and the message recipient is required to respond. The
message initiator can be either the application or the Anybus-S.
•
Indication
A message is sent by the message initiator, and no response is required. The message initiator can
be either the application or the Anybus-S.
The mailbox interface is designed to allow multiple messages to be sent to the module before receiving
a response (if applicable). To be able to distinguish which mailbox response that belong to which command, a unique Message ID is used for each message/response, see figure below.
Application
AnyBus-S
ID: 1
Command
ID: 2
Command
Mailbox Input Area
Application Software
Response
ID: 1
Response
ID: 2
Mailbox Output Area
AnyBus-S
Software
Mailbox Interface 8-2
Message Types
The mailbox messages can be grouped into five categories based on their functionality, see below.
•
Application Messages
This category includes commands for accessing and controlling internal Anybus-S functions
•
Fieldbus Specific Messages
This category includes commands for accessing fieldbus specific data and functions. For more
information, consult each separate fieldbus appendix.
•
Internal Memory Messages
This category includes functions for accessing the Internal Memory.
•
Reset Messages
This category includes functions to effect the module operation.
Mailbox Notification Bits
The Mailbox Notification bits in the Anybus- and Application Indication Registers are used to control
the mailbox interface. Both registers contains bits that are used to send and receive mailbox messages,
and to monitor the current mailbox status.
Bit
AP_MIN
Function
Toggle this bit to post a message previously written to the Mailbox Input Area.
AP_MOUT
Toggle this bit to acknowledge that a mailbox message has been read
AB_MIN
This bit is toggled by the Anybus module when it has read a mailbox message
AB_MOUT
This bit is toggled each time a new message is waiting in the Mailbox Output Area.
Before entering a new mailbox message in the Mailbox Input Area, or attempting to read a message from
the Mailbox Output Area, it is necessary to know the current status of the mailbox interface. This is done
by comparing the corresponding Mailbox Notification bits in the Anybus- and Application Indication
Registers, see table below.
Expression
AP_MIN = AB_MIN
AP_MOUT = AB_MOUT
Result
True
False
True
False
Meaning
Mailbox Input Area is free
Mailbox Input Area is currently in use
No message available in the Mailbox Output Area
New message available in the Mailbox Output Area
Mailbox Interface 8-3
Sending a Mailbox Message
To send a mailbox message to the module, follow the procedure below.
 Start
1. Check if the Mailbox Input Area is free (If not, retry again later)
2. Write the message to the Mailbox Input Area
3. Toggle the AP_MIN bit in the Application Indication Register (7FEh)
 Done
Receiving a Mailbox Message
To receive a mailbox message, follow the procedure below.
 Start
1. Check if a message is waiting in the Mailbox Output Area (If not, retry again later)
2. Read the message from the Mailbox Output area
3. Toggle the AP_MOUT bit in the Application Indication Register (7FEh)
 Done
Mailbox Interface 8-4
Mailbox Message Structure
A mailbox message consists of a message header and message data, see below.
Offset:
000h - 01Fh
Contents:
Message Header
(32 bytes)
Description:
See 8-4 “Message Header”
020h - 11Fh
Message Data
(up to 256 bytes)
This section contains the data associated with the mailbox message.
Message Header
The header consists of a series of 16bit registers that specifies the type of message and the length of the
message data.
Offset:
000h
002h
004h
006h
008h
00Ah
00Ch
00Eh
010h
012h
014h
016h
018h
01Ah
01Ch
01Eh
Register:
Message ID
Message Information
Command Number
Data Size
(reserved, set to 0001h)
(reserved, set to 0001h)
(reserved, set to 0000h)
(reserved, set to 0000h)
Extended Word 1
Extended Word 2
Extended Word 3
Extended Word 4
Extended Word 5
Extended Word 6
Extended Word 7
Extended Word 8
Mailbox Interface 8-5
Message ID
The Message ID register contains a 16-bit integer identifier for the command. When a response is sent
back to the message initiator, the same message ID is used in that message. Message ID:s can be selected
arbitrary, but messages currently being processed must all have unique ID’s.
Message Information
This register contains bit and code information about the mailbox message. The register is divided into
five areas according to the figure below:
b15
ERR
b14
C/R
Bit / Field
ERR
C/R
Error Code
b13 b12
(reserved)
b11
b10 b9
Error Code
b8
Description
This bit indicates if the received command
contained any errors.
This bit specifies whether the message is
a command or a response.
If the ERR bit is set, this field contains
additional information about the error.
Message Type This field specifies the type of the message.
b7
b6
b5
b4
b3
b2
Message Type
b1
b0
Contents
0: Message OK
1: Error (See also ‘Error Code’ below)
0: Response Message
1: Command Message
0h: Invalid Message ID
1h: Invalid Message Type
2h: Invalid Command
3h: Invalid Data Size
4h: Message header malformed (offset 008h)
5h: Message header malformed (offset 00Ah)
6h: Message header malformed (offset 00Ch - 00Dh)
7h: Invalid address
8h: Invalid Response
9h: Flash Config Error
Fh: Invalid Other
(All other values are reserved)
1h: Application Message
2h: Fieldbus Specific Message
3h: Memory Message
5h: Reset Message
(All other values are reserved)
Command Number
This register contains a 16 bit command identifier.
Data Size
This register specifies the size of the Message Data in bytes. The maximum Message Data size is 256
bytes.
Extended Words 1 ... 8
These registers are specific for each command. Consult the specification for each command for further
information.
Chapter 9
Mailbox Messages
Application Messages
General
This category includes commands for accessing and controlling internal Anybus-S functions
Messages in This Category
Message
Start initialization
Anybus initialization
End initialization
Save to FLASH
Load from FLASH
Abbreviation
START_INIT
Anybus_INIT
END_INIT
SAVE_TO_FLASH
LOAD_FROM_FLASH
Hardware Check
HW_CHK
Description
Initiates the initialization process.
Used to set up basic operational parameters.
Ends the initialization process.
Records a mailbox initialization sequence to flash.
Replays a previously recorded mailbox initialization
sequence from flash.
Performs a diagnostic test on the Anybus-S hardware.
Page
9-2
9-3
9-6
9-7
9-8
9-9
Mailbox Messages 9-2
Start Initialization (START_INIT)
This command initiates the initialization process.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
START_INIT
1. (Application Message)
0001h
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command
(ID)
4001h
0001h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0001h
0001h
0000h
0001h
0001h
0000h
0000h
-
Application Message
START_INIT
No message data
Mailbox Messages 9-3
Anybus Initialization (Anybus_INIT)
This command is used to configure the data composition of the data exchange buffers, and the way the
module should operate on the network. Sending this mailbox is mandatory, either directly or indirectly
using the mailbox command ‘Load from FLASH’.
Note that the application must monitor the response from the module and verify that the command was
accepted.
The initialization parameters passed in the command are parsed by the module. If any parameter exceeds
its limits, the response message will contain recommended values. The application will then have to resend the message with the corrected values.
Note: This command can only be send during module initialization, i.e. between START_INIT and
END_INIT.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
Anybus_INIT
1. (Application Message)
0002h
The response header may contain fault information.
Initialization parameter data
Copy of command data, or suggested maximum values.
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command data word 1
Command data word 2
Command data word 3
Command data word 4
Command data word 5
Command data word 6
Command data word 7
Command data word 8
Command data word 9
Command
(ID)
4001h
0002h
0012h
0001h
0001h
0000h
0000h
Input I/O Length
Input DPRAM Length
Input Total Length
Output I/O Length
Output DPRAM Length
Output Total Length
Operation Mode
Event Notification Config.
Watchdog Timeout Value
Expected Response
(ID)
0001h
0002h
0012h
0001h
0001h
0000h
0000h
Fault Information
Input I/O Length
Input DPRAM Length
Input Total Length
Output I/O Length
Output DPRAM Length
Output Total Length
Operation Mode
Event Notification Config.
Watchdog Timeout Value
Application Message
Anybus_INIT
9 words of data (18 bytes)
Mailbox Messages 9-4
•
Fault Information
If the error code is ‘Invalid Other’ (Fh), extended error information is presented in this register
as follows:
Bit
0
1
2
3
4
5
6
7
8
9
10
11 - 15
•
Fault
Input I/O Length
Input DPRAM Length
Input Total Length
(reserved)
Output I/O Length
Output DPRAM Length
Output Total Length
(reserved)
Module Status
Event Notification
Incorrect Watchdog
(reserved)
Description
Incorrect length of input I/O
Incorrect length of DPRAM input
Incorrect length of total input
Incorrect length of output I/O
Incorrect length of DPRAM output
Incorrect length of total output
Incorrect configuration of bits in Module Status register
Incorrect configuration of bits in Event Notification register
Incorrect Watchdog Counter difference value
Input I/O Length, Input DPRAM Length & Input Total Length
These parameters determine the composition of the Input Data Buffer. For more information,
see 7-3 “Data Composition”
•
Output I/O Length, Output DPRAM Length & Output Total Length
These parameters determine the composition of the Output Data Buffer. For more information,
see 7-3 “Data Composition”
•
Operation Mode
This parameter is used to set various options in the module. The contents of this parameter is
reflected in the Module Status register in the Control Register Area.
b15
b14
Bit
FBFC
FBS1
FBSPU1
RDR1
APFC1
CD
•
b13
b12
b11
b10
b9
b8
CD
APFC
b7
b6
b5
Description
These bits defines the behaviour of the module when the
fieldbus goes off line. For more information, see 4-5 “Module Status (7E2h - 7E3h, RO)”
Fieldbus Reset Device Request notification
b4
b3
b2
b1
RDR
FBSPU
FBS
FBFC
b0
State
For more information, see 45 “Module Status (7E2h 7E3h, RO)”
0:
1:
This bit defines how the module should behave when the 0:
application has stopped (i.e. a Watchdog timeout)
1:
This bit enables/disables the Changed Data Field registers 0:
in the Control Register Area.
1:
Disable
Enable
Clear Input Data
Freeze Input Data
Disable
Enable
Event Notification Config.
This parameter is used to set which events that should trigger an Event Notification. For more
information about these bits, 4-7 “Event Notification Source (7EEh - 7EFh, RO)”.
Mailbox Messages 9-5
•
Watchdog Timeout Value1
This parameter is used to set the maximum allowed difference between the Watchdog Counter
Input/Output registers (See 4-3 “Watchdog Counter Input (7D2h - 7D3h, R/W)” and 4-4
“Watchdog Counter Output (7D4h - 7D5h, RO)”). When this value is exceeded, the module will
signal to the fieldbus that the application is not functioning properly. The range of this parameter
is 100 to 30000, which corresponds to a 0.1 - 30 second timeout period. A value of zero will disable this feature.
1. The implementation and behavior of this bit depends on the fieldbus type. Consult each separate fieldbus
appendix for more information. See also B-1 “Deviances”.
Mailbox Messages 9-6
End Initialization (END_INIT)
This command ends the initialization process.
Note: It is not possible to re-initialise the module without making a software or hardware reset.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
END_INIT
1. (Application Message)
0003h
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
•
Command
(ID)
4001h
0003h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0001h
Application Message
0003h
END_INIT
0000h
No message data
0001h
0001h
0000h
0000h
Secondary Fault Information
Primary Fault Information
Primary & Secondary Fault Information
Some modules can return fieldbus-specific error codes via these words during the modules internal initialization. Since these error codes are not generic, please refer to the applicable fieldbus
appendix for more information.
Mailbox Messages 9-7
Save to FLASH (SAVE_TO_FLASH)
This command is sent to save the Anybus-S initialization in the FLASH. This command can only be sent
directly after the START_INIT command. Please observe that issuing this command will erase any previously stored configuration.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
SAVE_TO_FLASH
1. (Application Message)
0004h
The response header may contain fault information.
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
•
Command
(ID)
4001h
0004h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0001h
0004h
0000h
0001h
0001h
0000h
0000h
Fault Information
Application Message
SAVE_TO_FLASH
No message data
Fault Information
If ‘Flash Config Error’ is returned in the Message Information word in the header of the response, information about the fault can be found here.
0001h: Flash is full - the mailbox that responded with this message will be unable to save.
0002h: Store operation error - will not be able to load the configuration.
Mailbox Messages 9-8
Load from FLASH (LOAD_FROM_FLASH)
This command is sent to load the Anybus-S initialization from the flash. This command can only be sent
directly after the START_INIT command, and a previously saved configuration must be present in the
FLASH.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
LOAD_FROM_FLASH
1. (Application Message)
0005h
The response header may contain fault information.
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
•
Command
(ID)
4001h
0005h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0001h
0005h
0000h
0001h
0001h
0000h
0000h
Fault Information
Application Message
LOAD_FROM_FLASH
No message data
Fault Information
If ‘Flash Config Error’ is returned in the Message Information word in the header of the response, information about the fault can be found here.
0003h: CRC mismatch or FLASH empty - responds directly and will not load the configuration.
0004h: LOAD failed - module cannot load the configuration, the module will be reset.
Mailbox Messages 9-9
Hardware Check (HW_CHK)
This command instructs the module to perform a diagnostic test on the hardware. This includes the
RAM, DPRAM, FLASH (CRC test) and possibly the ASIC depending on fieldbus type.
If any errors are detected, the module will not respond to any command until a hardware reset is performed. The Anybus-S Watchdog will indicate the type of error, for more information see 11-1
“Anybus-S Watchdog LED”.
Note: The command can only be sent before the START_INIT command.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
HW_CHK
1. (Application Message)
0006h
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command
(ID)
4001h
0006h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0001h
0006h
0000h
0001h
0001h
0000h
0000h
-
Application Message
HW_CHK
No message data
Mailbox Messages 9-10
Fieldbus Messages
This category includes commands for accessing fieldbus specific data and functions, and are described
in each separate fieldbus appendix.
Mailbox Messages 9-11
Internal Memory Messages
General
This category includes functions for accessing the Internal Memory.
Messages in This Category
Message
Read Internal Input Area
Write Internal Input Area
Clear Internal Input Area
Read Internal Output Area
Abbreviation
RD_INT_IN
WR_INT_IN
CLR_INT_IN
RD_INT_OUT
Description
Reads a block of data from the internal input area.
Writes a block of data to the internal input area.
Clears a block of data in the internal input area.
Reads a block of data from the internal output area.
Page
9-12
9-13
9-14
9-15
Mailbox Messages 9-12
Read Internal Input Area (RD_INT_IN)
This command is used to read a block of data from the Internal Input Area. It is possible to read up to
256 bytes of data with each command.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
RD_INT_IN
3. (Internal Memory Message)
0001h
Contains the source offset address and size of the data block
Contents of read data block.
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command
(ID)
4003h
0001h
0000h
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Expected Response
(ID)
0003h
0001h
(data size)
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Internal Memory Message
RD_INT_IN
(same as Block Size)
Response data word 1
Data Block
...
Response data word n
•
Block Offset
Address offset from the start of the Input Data Buffer.
•
Block Size
Size of the block that should be read (in bytes).
•
Data Block
The actual data block.
Mailbox Messages 9-13
Write Internal Input Area (WR_INT_IN)
This command is used to write a data block to the Internal Input Area. It is possible to write up to 256
bytes of data with each command.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
WR_INT_IN
3. (Internal Memory Message)
0002h
Contains destination offset address and size of the data block
Data that should be written.
Copy of the written data.
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command data word 1
...
Command
(ID)
4003h
0002h
(data size)
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Expected Response
(ID)
0003h
0002h
(data size)
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Response data word 1
Data Block
Data Block
Command data word n
•
Block Offset
Address offset from the start of the Input Data Buffer.
•
Block Size
Size of the block that should be written (in bytes).
•
Internal Memory Message
WR_INT_IN
(same as Block Size)
Data Block
The actual data block.
...
Response data word n
Mailbox Messages 9-14
Clear Internal Input Area (CLR_INT_IN)
This command is used to clear blocks of data in the Internal Input Area. It is possible to clear up to 256
bytes of data with each command. Several commands are required to clear the whole area.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
CLR_INT_IN
3. (Internal Memory Message)
0003h
Contains destination offset address and size of the data block that should be cleared
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
•
Command
(ID)
4003h
0003h
0000h
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Expected Response
(ID)
0003h
0003h
0000h
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Block Offset
Address offset from the start of the Input Data Buffer.
•
Block Size
Size of the block that should be cleared (in bytes).
Internal Memory Message
CLR_INT_IN
No message data
Mailbox Messages 9-15
Read Internal Output Area (RD_INT_OUT)
This command is used to read a block of data from the Internal Output Area. It is possible to read up
to 256 bytes of data with each command.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
RD_INT_OUT
3. (Internal Memory Message)
0004h
Contains the source offset address and size of the data block
Contents of read data block.
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command
(ID)
4003h
0004h
0000h
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Expected Response
(ID)
0003h
0004h
(data size)
0001h
0001h
0000h
0000h
Block Offset
Block Size
-
Internal Memory Message
RD_INT_OUT
(same as Block Size)
Response data word 1
Data Block
...
Response data word n
•
Block Offset
Address offset from the start of the Output Data Buffer.
•
Block Size
Size of the block that should be read (in bytes).
•
Data Block
The actual data block.
Mailbox Messages 9-16
Reset Messages
General
This category includes reset related functions.
Messages in This Category
Message
Software Reset
Abbreviation
SW_RESET
Description
Performs a software reset of the module.
Page
9-16
Software Reset (SW_RESET)
This command is used if a restart of the Anybus-S module for some reason is required, e.g. if some initialization data has to be changed. The application has 1 second to read the response before the reset
command is activated.
Note: This command only makes a software reset of the module, not a hardware reset.
Message Initiator
Message Name
Message Type
Command Number
Extended Header
Command Data
Response Data
Application
SW_RESET
5. (Reset Message)
0001h
-
Command and response layout:
Message ID
Message information
Command
Data size
Extended word 1
Extended word 2
Extended word 3
Extended word 4
Extended word 5
Extended word 6
Extended word 7
Extended word 8
Command
(ID)
4005h
0001h
0000h
0001h
0001h
0000h
0000h
-
Expected Response
(ID)
0005h
0001h
0000h
0001h
0001h
0000h
0000h
-
Reset Message
SW_RESET
No message data
Chapter 10
Start Up and Initialization
Introduction
At any given time, the Anybus-S module will be in one out of three possible states:
1. Hardware Initialization State
This is the initial state of the module after power on or reset. To get to the next state, various
diagnostic tests on the hardware should be performed, see 10-2 “Hardware Initialization”.
- No data exchange is possible in this state.
2. Software Initialization State
In this state, the basic operating parameters are set. In order to proceed to the next state, the
module must first successfully pass the software initialization sequence, see 10-3 “Software Initialization”.
- No data exchange is possible in this state.
3. Data Exchange State
In this state, the module is able to exchange data between the fieldbus and two I/O data buffers.
The only way to get to this state is to successfully go through the other states.
This chapter describes the steps involved in state 1 and 2. For more information about state 3 (Data
Exchange State), see 7-1 “Fieldbus Data Exchange”.
Start Up and Initialization 10-2
Hardware Initialization
This procedure is mandatory and ensures that the module is working properly before the software initialization sequence. The procedure consists of the following steps:
•
Startup Sequence
•
Dual Port Memory Check (Optional)
•
The Hardware Check mailbox message (Optional)
Startup Sequence
Depending on how the application has been implemented, the startup procedure differs slightly:
•
Hardware Interrupt feature not implemented
After power on/reset, the application should poll the Watchdog Counter Out register (7D4h 7D5h) approximately every 10ms to detect if it has been properly updated by the module. When
this register has been updated by the module at least 10 times, the module can be considered to
be up and running.
•
Hardware Interrupt feature implemented
After power on/reset, the Anybus module generates an interrupt to indicate that it is ready. Before this interrupt, the application is not allowed to write any data in the dual port memory.
The interrupt line is managed entirely by the internal logic of the DPRAM; this logic is affected
by a power on reset but not by a hardware reset. Therefore, certain precautions are needed to
ensure proper functionality. For more information, see C-1 “Interrupt Line and Hardware Reset”.
Dual Port Memory Check (Optional)
It is recommended to perform a read/write test of the dual port memory. This can be done in two ways,
depending on the nature of the application:
•
Hardware Reset not implemented (Or not controlled by the application software)
The test should be carried out directly after the Startup Sequence described above. The test must
be non-destructive, i.e. the data in the dual port memory must be restored after the test.
Also, it is important to exclude the following from these tests as this would interfere with the
operation of the module:
- Watchdog Counter In register (7D2h - 7D3h)
- Watchdog Counter Out register (7D4h - 7D5h)
- Handshake Registers (7FEh - 7FFh)
- LED indication status (7DAh-7DFh)
- Module Status (7E2h-7E3h)
- Fieldbus Specific Area (640h - 7BFh)
•
Hardware Reset implemented (And controlled by the application software)
The dual port memory test should be carried out while the reset line is held low by the application, prior to the Startup Sequence described above. All memory locations can be tested, and the
test can be either destructive or non-destructive.
Start Up and Initialization 10-3
Hardware Check (Optional)
Note: This step can only be performed after the Startup Sequence and the Dual Port Memory Check.
By sending the mailbox command ‘Hardware Check’, the module will be instructed to perform a hardware self-test. If the test is successful, the module will respond. If the module does not respond, the test
failed. For more information, see 9-9 “Hardware Check (HW_CHK)”) and 11-1 “Anybus-S Watchdog
LED”.
Software Initialization
Hardware
Initialisation
Before any fieldbus communication can take place, the
software in the Anybus-S module must be initialised.
This process is mandatory and decides how the module should operate on the network.
Prepare Init. Data
Start Initialisation
The software initialization process basically consists of
the following steps:
Initialise Parameter
Values
1. Prepare Initialization Data (Optional)
2. Start Initialization
Set Initial
FieldbusData
3. Initialise Parameter Values
4. Set Initial Fieldbus Data (Optional)
End Initialisation
5. End Initialization
Prepare Initialization Data
Fieldbus Data
Exchange
This step is optional, but will enable the application to take advantage of advanced fieldbus specific features without requiring multiple software versions. To accomplish this, the application needs to know
the type of Anybus module that is connected, and possibly other information such as software revisions
etc. During initialization, this information can be read directly from the Control Register Area without
handshaking.
The application can then modify the software initialization parameters to better exploit a specific
Anybus model.
Start Initialization
This step is mandatory, and instructs the module to
start the software initialization sequence.
Prepare Init.
Data
Send 'Start Init'
1. Send the mailbox message ‘Start Init’
This will instruct the module to start the software initialization process.
Check response
2. Check response
The module is now ready to accept further configuration mailbox messages.
Initialise Parameter
Values
Start Up and Initialization 10-4
Initialise Parameter Values
This step is mandatory, however the exact procedure may vary from case to case. The following steps
are involved.
•
Send mailbox command ‘Save to FLASH’ (Optional)
This mailbox command works very much like a tape recorder that records the following mailbox
commands. The recording stops when the module receives the ‘End Init’ mailbox command.
•
Send mailbox command ‘Load from FLASH’ (Optional)
This mailbox command replays a previously recorded mailbox sequence made using the ‘Save to
FLASH’ mailbox command.
•
Send mailbox command ‘Anybus Init’
This mailbox command is used to configure the data composition of the data exchange buffers,
and the way the module should operate. Sending this mailbox is mandatory, either directly or indirectly using the mailbox command ‘Load from FLASH’.
Note that the application must monitor the response from the module and verify that the command was accepted.
•
Send fieldbus specific initialization commands (Optional)
This procedure usually involves sending fieldbus specific mailbox commands to the module,
consult each separate fieldbus appendix for more information. Note that some fieldbus specific
initialization commands must be sent before Anybus Init. This has to be accounted for in the
application software.
Note: Please note that using fieldbus specific initialization commands may void the fieldbus precertification, see F-1 “Fieldbus Certification”.
Set Initial Fieldbus Data
This step is optional, but allows the application to have control over the contents of the Input Data Buffer before the first bus cycle. Depending on the location of the data that should be written, the application
must either write the data to the Input Data Area in the DPRAM or send it to the module using Internal
Memory commands, see 9-11 “Internal Memory Messages”.
End Initialization
This step signals to the module that the initialization is
done, and that the module should start exchanging
data on the fieldbus.
Initialise Parameter
Values
Send 'End Init'
1. Send the mailbox message ‘End Init’
2. Check response
If the response is ok, the module will start exchanging data on the fieldbus.
Check response
Fieldbus Data
Exchange
Start Up and Initialization 10-5
Basic Initialization Sequence Example 1
Start
(Note that procedure below assumes that the parameters sent with the ‘Anybus Init’ command are valid.)
Send 'Start Init'
If only basic fieldbus functionality is required, a very
basic initialization sequence like the one below can be
used.
Check response
 Power On (Reset)
1. Send mailbox command ‘Start Init’
Send 'AnyBus Init'
2. Check response
3. Send mailbox command ‘Anybus Init’
Check response
4. Check response
5. Send mailbox command ‘End Init’
Send 'End Init'
6. Check response
 Ready
Check response
Ready
Basic Initialization Sequence Example 2
Start
In this example, the initialization mailbox sequence is
loaded from flash. Note that this requires that an initialization sequence has previously been stored in flash
using the ‘Save to FLASH’ mailbox command.
Send 'Start Init'
Check response
 Power On (Reset)
1. Send mailbox command ‘Start Init’
Send from
'AnyBus
Init'
'Load
FLASH'
2. Check response
3. Send mailbox command ‘Load from flash’
Check response
4. Check response
5. Send mailbox command ‘End Init’
Send 'End Init'
6. Check response
 Ready
Check response
Ready
Start Up and Initialization 10-6
Advanced Initialization Example
In this example, the initialization sequence is adapted
for the currently used Module/Fieldbus type, and the
Input Data Buffer is updated before the first bus cycle.
Start
Check:
Module Type
Fieldbus Type
 Power On (Reset)
1. Check Module/Fieldbus Type
Prepare
Initialisation data
This information can be read without handshaking from the Control Register Area.
2. Prepare Initialization Data
Send 'Start Init'
Based on the information from the Control
Register Area, the application can decide what
initialization parameters to use in the remainder
of the initialization process.
Check response
3. Send mailbox command ‘Start Init’
This step starts the initialization sequence.
Fieldbus Specific
Initialisation
4. Check response
5. Fieldbus Specific Initialization
The procedure for this step is different for each
fieldbus and is described in each separate fieldbus appendix.
6. Send mailbox command ‘Anybus Init’
Send 'AnyBus Init'
Modify 'AnyBus Init'
parameters
Check response
‘Anybus Init’ is used to set up I/O sizes and
various configuration bits.
7. Check response
No
8. Response OK?
Response OK?
Yes
If not, modify the parameters for the Anybus
Init mailbox message and go to step 4.
Update Input DataBuffer with
initial values
9. Update the Input Area with initial values
10. Send mailbox command ‘End Init’
Send 'End Init'
This step ends the initialization sequence.
11. Check response
Check response
 Ready
Ready
Chapter 11
Indication LEDs
Fieldbus Status Indicators
The module features four front mounted status LED’s implemented in accordance with each fieldbus
standard. The function of these LED’s is fieldbus dependant and is described in each fieldbus appendix.
Anybus-S Watchdog LED
All Anybus-S modules features a surface mounted watchdog LED, indicating the status of the module.
Colour
Red
Green
Frequency
1Hz
2Hz
4Hz
2Hz
1Hz
Indication
Unspecified internal error, or running in bootloader mode
RAM failure
ASIC or FLASH failure
DPRAM failure
Module not initialised
Module initialised and running OK
Chapter 12
Firmware Upgrade
To be able to keep the continuous product development on the Anybus-S module and to be able to give
upgrades to our customers with more improved features, a FLASH memory is used in all Anybus-S
modules. This means that the firmware in the module can be updated in the field after production.
The module supports two firmware download methods:
•
Parallel Download via DPRAM
This method requires that special drivers are implemented in the application program. Please
contact HMS for further specification of these drivers.
•
Serial Download via Asynchronous Serial Interface
This method requires that the asynchronous serial interface pins on the Anybus application connector is connected to a standard PC via RS232 line drivers. The firmware can then be downloaded using a Microsoft Windows application supplied by HMS.
This method may require access to the circuit board, depending on module. Please contact HMS
for more information.
If the application is to support firmware download in the field, HMS recommends that the serial download option is used. A simple but fully functional implementation can be made by adding a four-pin connector that will connect the VCC, GND, TX and RX pins in the application connector to an external
RS232-to-TTL level converter. The TX/RX pins are used for the communication and the VCC/GND
supply the converter with power, eliminating the need for an external supply.
The application software also needs some preparations since the module will only accept download
commands immediately after a reset. Once the application has begun any initialization of the module it
must be reset or power-cycled in order for a download to be possible.
On newer modules it may also be required to close a jumper on the module circuit board in order to be
able to download new firmware, contact HMS for more information.
Chapter 13
Driver Example
The example driver is composed of three routines, called ‘Handlers’:
•
Interrupt Handler
This routine handles interrupts received from the Anybus-S. For more information, see 13-2 “Interrupt Handler”.
•
Interface Handler
This routine should be called cyclically from the main program. For more information, see 13-3
“Interface Handler”.
•
Mailbox Handler
This routine can be called cyclically from the main program, or when the need arises. For more
information, see 13-4 “Mailbox Handler”.
Implementation Notes
Also, it is assumed that the code in these examples is executed in a multitasking environment. If the application does not feature multitasking capability, the code should to be implemented as a state machine
or similar rather than linear code.
Important!
These example routines are far from optimal and is included for guidance only. Some essential functions
for Initialization, timeout, Event Notification and error handling etc. are left out and has to be implemented in order to be able to operate the module properly.
Global Variables
The following global variables are used in the example routines:
Variable
INIT
AB_IN
AB_OUT
AB_FBCTRL
AB_MOUT
Type
Description
Boolean These variables corresponds to individual bits in the Anybus Indication RegisBoolean ter, see 5-3 “Anybus Indication Register (7FFh, RO)”
Boolean
Boolean
Boolean
AB_MIN
Boolean
AB_EVNT
AP_MIN
AP_MOUT
Boolean
Boolean These variables corresponds to individual bits in the Application Indication RegBoolean ister, see 5-2 “Application Indication Register (7FEh, R/W)”
AP_EVNT
ABS_INITIALISED
IN_AREA_FREE
OUT_AREA_FREE
FBCTRL_AREA_FREE
MBX_OUT_NEW
MBX_IN_FREE
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
This variable indicates that the module has been initialised.
These variables indicates if an area in the DPRAM is free to use. (Set = free)
This variable indicates that the Mailbox Output Area contains a new message.
This variable indicates that the Mailbox Input Area is free to use.
Driver Example 13-2
Interrupt Handler
Start
The purpose of this routine is to interpret the contents of
the Anybus Indication Register upon receiving an interrupt, and to make this information available to the Interface/Mailbox Handlers and the main application program.
To provide fast interrupt handling, no further processing is
performed in this routine; i.e. all processing is performed in
the Interface Handler instead.
Read
AnyBus Indication Register
1
2
No
INIT == 1?
Yes
ABS_INITIALISED = 0
ABS_INITIALISED = 1
Note: Although this routine is called ‘Interrupt Handler’ it
can be used even if the interrupt pin is not implemented in
the application. In this case, the routine must be called periodically and/or when needed in order to refresh its status
variables. Exactly how this should be implemented is not
the scope of this chapter. Again, it is strongly recommended to use the interrupt feature whenever possible.
3
No
AB_IN == 1?
Yes
IN_AREA_FREE = 0
IN_AREA_FREE = 1
4
Step by Step
 Start
No
Yes
OUT_AREA_FREE = 0
1. Read the Anybus Indication Register
OUT_AREA_FREE = 1
2. Check if the module is initialised
5
(Store status in ABS_INITIALISED)
3. Check if the Input Area is free
(Store status in IN_AREA_FREE)
AB_OUT == 1?
No
AB_FBCTRL == 1?
Yes
FBCTRL_AREA_FREE = 0
FBCTRL_AREA_FREE = 1
4. Check if the Output Area is free
6
(Store status in OUT_AREA_FREE)
5. Check if the Fieldbus Specific Area & Control
Register Area is free
No
Yes
MBX_OUT_NEW = 0
(Store status in FBCTRL_AREA_FREE)
MBX_OUT_NEW = 1
6. Check if the Mailbox Output Area contains a
new message
7
No
(Store status in MBX_OUT_NEW)
7. Check if the Mailbox Input Area is free
AB_MOUT != AP_MOUT?
AB_MIN == AP_MIN?
Yes
MBX_IN_FREE = 0
MBX_IN_FREE= 1
(Store status in MBX_IN_FREE)
8. Check if an Event Notification has occurred
8
(Store status in NEW_EVENT)
No
 Done
AB_EVNT != AP_EVNT?
Yes
NEW_EVENT = 0
NEW_EVENT = 1
Done
Driver Example 13-3
Interface Handler
Start
The Interface Handler should be called cyclically from the main program.
The purpose of this routine is to transfer
data and to perform all necessary handshaking for the Input/Output Data Areas
and the Fieldbus Specific/Control Register
Areas.
1
New data for Input Area?
Yes
No
2
IN_AREA_FREE == 1?
No
Yes
Request Area
Write data
If an area within the dual port memory is
currently in use, a request will be made so
that the area can be accessed the next time
the routine is called.
Wait for response
Release Area
Yes
IN_AREA_FREE == 1?
Wait for response
No
Step by Step
 Start
1. New data for Input Area?
2. Is the area free to use?
3
Time to read Output Area?
Yes
No
4
OUT_AREA_FREE == 1?
If yes, access the data, release the
area and wait for response.
No
Yes
If no, request and if possible access
the area. If the area is still in use, a
new attempt will be made the next
time the routine is called.
Request Area
Read Data
Wait for response
Release Area
Yes
3. Time to read Output Area?
OUT_AREA_FREE == 1?
Wait for response
4. Is the area free to use?
If yes, access the data, release the
area and wait for response.
If no, request and if possible access
the area. If the area is still in use, a
new attempt will be made the next
time the routine is called.
No
Access to the
Fieldbus/Control Area
Required?
5
Yes
No
6
FBCTRL_AREA_FREE == 1?
No
Yes
5. Access to the Fieldbus Specific
Area & Control Register Area required?
Read/Write Data
Wait for response
Release Area
6. Is the area free to use?
Yes
If yes, access the data, release the
area and wait for response.
If no, request and if possible access
the area. If the area is still in use, a
new attempt will be made the next
time the routine is called.
 Done
Request Area
FBCTRL_AREA_FREE == 1?
Wait for response
No
Done
Driver Example 13-4
Mailbox Handler
The Mailbox Handler should be called cyclically from the main
program.
Start
The purpose of this routine is to exchange mailbox messages
with the module. The routine handles both incoming and outgoing mailbox traffic:
New mailbox
command for
AnyBus-S?
•
1
Yes
2
No
MBX_IN_FREE == 1?
Application to Anybus module
If the application wishes to send a mailbox message to
the module, the routine will first check if the Mailbox
Input Area is free (i.e. MBX_IN_FREE == 1), and if
possible, transfer the message. The routine will then
toggle the AP_MIN bit to signal to the module that a
message has been entered in the Mailbox Input Area.
If the Mailbox Input Area is currently in use (i.e.
MBX_IN_FREE == 0), the routine will attempt to
send the message the next time the routine is called.
•
No
Yes
Write mailbox message
to Mailbox Input Area
Toggle AP_MIN
3
Application
ready to receive
mailbox msg?
Module to Application
Yes
4
No
MBX_OUT_NEW == 1?
If the application is able to receive a new mailbox message and a new message is detected (i.e.
MBX_OUT_NEW == 1), the routine will transfer the
message and acknowledge this to the module by toggling the AP_MOUT bit in the Application Indication
Register.
No
Yes
Read mailbox message from
Mailbox Output Area
Toggle AP_MOUT
Step by Step
Done
 Start
1. Should a new mailbox message be sent to the Anybus module?
(If not, the routine jumps to step 3)
2. Is the Mailbox Input Area free?
If yes, write the message to the Mailbox Input Area. When done, toggle the AP_MIN bit to signal
to the module that a new message has been entered.
If no, do nothing; a new attempt will be made the next time the routine is called.
3. Is the application ready to receive a new mailbox message?
(If not, the routine exits)
4. Does the Mailbox Output Area contain a new message?
If yes, read the message from the Mailbox Output Area. When done, toggle the AP_MOUT bit
to acknowledge that the message has been read.
If no, do nothing; a new attempt will be made the next time the routine is called.
 Done
Chapter 14
Mechanical Aspects
PCB Measurements
2
39.8
37.2
2
Ø 0.8
5.8
0.75
0
3x Ø 3.2
A
A
Ø 0.9
6.2
2
Ø 0.8
Ø 0.8
2.54
2.54
2
12.8
71.8
40
0
2
1
14.2
1.6
82
55.5
7
0
4
A-A
Height Restrictions
In order to provide sufficient space between the Anybus-S circuit board/components and the surrounding parts of the application, certain mechanical restrictions must be accounted for.
The following drawing specifies the height restrictions of the components mounted on an Anybus-S
module. Generally, no components etc. are situated outside the boundaries specified below.
7
1.4 - 7.2
17
5
15
1.6
4
54
86
Note: Due to current component restrictions, the Anybus-S ControlNet does not follow the above expressed standard. For this module, the height restriction is 15 mm on the entire top side of the board.
Mechanical Aspects 14-2
Mounting Holes
All Anybus-S modules features three metal plated mounting holes for mechanical fastening. Two of
these holes are used for improved electrical connection between the application and the module, see table below.
(For measurements, see 14-1 “PCB Measurements”.)
#
A
B
Description
Position
Conductive hole, used to connect PE (Protective Earth) with
C
fieldbus electronics (Shield). (This hole is connected to the
fieldbus cable shield via a filter according to the fieldbus
specification).
Electrically isolated hole for use with conductive or non conductive screws.
A
B
C Conductive hole, used for improved GND connection.
6.00 mm
3.20 mm
Both on the conductive and non-conductive holes there is an area around
the hole where no PCB wires are placed on the Anybus module. This area
has a diameter of 8mm.
Conductive Area
Application Connector
The application connector is a 2mm low profile strip header that can be mounted on either side of the
module. If required, alternative solutions are available for an additional charge, e.g. the module can be
equipped with other standard or non-standard headers with other post heights.
Standard Post Heights
6.4 mm
8.1 mm
10.1 mm
12.2 mm
Post Height
(For measurements, see 14-1 “PCB Measurements”.)
Fieldbus Connector(s)
To be able to fulfil the connector specification for all major fieldbus systems, most Anybus-S modules
can be equipped with several different connector types. A 2mm strip header is also available for applications where the fieldbus connector should be relocated to the application board.
The positions of the first fieldbus connector and the 2mm strip headers are fixed. Some fieldbus systems
require a second fieldbus connector, however the position of this connector is not fixed.
(For measurements, see 14-1 “PCB Measurements”.)
Mechanical Aspects 14-3
Fieldbus Status Indication LED’s
All Anybus-S modules features four fieldbus status indication LED’s, available in both straight (180º)
and right-angled (90º) configurations. The position of these LED’s is standardised on all modules to facilitate the design of LED description panels etc.
The module can also be supplied with a 2.54 2x4 header if the LED’s are to be relocated to the application board (for measurements, see 14-1 “PCB Measurements”).
Angled LED’s
9,2
2,9
13,7 15,8
2,3
7,4
9,7
73,3
77,9
Straight LED’s
9,2
4,6
8,1 10,2
2,9
8,7
5
75,6
9,7
Appendix A
Extended Memory Mode (4K DPRAM)
The Anybus-S platform has been extended to allow faster access to fieldbus data. This is accomplished
by using pin 34 of the application connector as address line 11 (A11), giving an effective address range
of 4kbyte instead of the standard 2kbyte.
At the time of writing, this feature is only used by the Anybus-M Profibus DPV1 Master and the
Anybus-M Devicenet Master/Scanner, but it may be used in future versions of the Anybus-S. Regardless
of DPRAM size, all future Anybus-S versions are backwards compatible with applications where A11 is
not implemented.
Implementing this feature will affect the memory map,. see below.
A11 not implemented:
Area:
A11 Implemented:
000h - 1FFh
Input Data Area
800h - 9FFh (Standard Mode)
000h - 5FFh (Extended Mode)
200h - 3FFh
Output Data Area
A00h - BFFh (Standard Mode)
600h - BFFh (Extended Mode)
400h - 51Fh
Mailbox Input Area
C00h - D1Fh
520h - 63Fh
Mailbox Output Area
D20h - E3Fh
640h - 7BFh
Fieldbus Specific Area
E40h - FBFh
7C0h - 7FDh
Control Register Area
FC0h - FFDh
7FEh - 7FFh
Handshake Registers
FFEh - FFFh
In order to be able to support future this feature, address line 11 must be implemented in the application,
and the address offset used in the software must be recalculated relative to the memory map above.
Appendix B
Deviances
General
The Anybus-S is designed to support virtually any type of network, and to present network events and
functions in a uniformed manner to the application in the widest extent possible.
To accomplish this, the Anybus-S specification includes a vast amount of bit coded status information.
Which of these bits that are actually used, and their exact interpretation, are fieldbus dependant.
For this reason, an implementation that relies heavily on a specific status bit or function may require
some slight modifications when changing fieldbus system, i.e. a completely transparent Anybus-S implementation cannot be done unless these slight differences are accounted for.
Also, in order to support fieldbus specific features, such as the socket interface of an Anybus-S Ethernet
module, special support has to be included in the application software.
Information about these deviances are presented in each separate fieldbus appendix.
Locked Release Behavior
When a locked release of the Output Data Area is requested, the area cannot be accessed again until the
Anybus module has updated it. Most modules update this area each cycle, whether there are changes to
the data or not, but there are exceptions. There are some modules that update the Output Data Area
only when there are changes to the output data, implying that the area can stay locked for several cycles.
This has to be taken into account when configuring an application, as you may have to rely on external
events for the area to be released.
The following modules update the Output Data Area only when the data has changed:
Module
ABS PROFIBUS DP-V0
ABS PROFIBUS DP-V1
ABS PROFIBUS DP-V1 I&M
ABS EtherNet/IP
ABS CANopen
ABS DeviceNet
a. COS = Change of state
Comment
When only COSa-data is used
When only COS-data is used
Deviances B-2
Application Interface Hardware Deviances
During the product’s life cycle, certain minor changes has been made to the application interface hardware in order to improve signal characteristics etc. The table below lists these changes. Generally, all new
products are implemented according to what is stated in 2-1 “Application Connector”.
At the time of writing, products not listed below or products with a higher revision numbers than the
ones listed below can be assumed to be implemented in accordance with what is stated earlier in 2-1
“Application Connector”. (Products with lower revision numbers are considered obsolete and may have
slight variations in resistor values etc. If this is the case with your product, contact HMS for further information.)
Anybus Module
ID #
Anybus-M DeviceNet
2102
Anybus-M DPV
2101
Anybus-S Interbus (500k)
3265
Anybus-S Interbus Fibre Optic (500k) 3273
Anybus-S Modbus Plus
4028
-
no pull up resistor
10k
10k pull up resistor
x
Signal not implemented
PCB
Revision
2.3.1
1.1.1
1.20 - 1.30
1.01 - 1.10
1.11
A4/DE
CE
IRQ
BUSY
A10
A11
-
10k
-
10k
10k
10k
100k
10k
10k
10k
10k
100k
10k
10k
10k
100k
10k
10k
10k
x
x
x
Appendix C
Interrupt Line and Hardware Reset
As described earlier, the Anybus-S generates an interrupt to indicate that it is ready after a power on reset. It is furthermore mentioned that the application is not allowed to write any data in the DPRAM before this interrupt is generated.
The interrupt line is however managed entirely by the internal logic of the dual port ram; this logic is
affected by a power on reset but not by a hardware reset. If the application utilizes hardware reset, for
example via a manual reset button, there is a risk of the interrupt line being held at a low level from the
start. Therefore, certain precautions are needed to ensure proper functionality.
The following diagrams describe the different situations1.
Normal Power On-Reset
The interrupt line (/INT) is initialized to a high level after a power-on reset.
Power
/RESET
/INT
AnyBus Ready
Read 7FFh
Hardware Reset – Case 1
A hardware reset occurs while the interrupt line is high, resulting in a normal start-up.
Power
/RESET
/INT
AnyBus Ready
Read 7FFh
Hardware Reset – Case 2
A hardware reset occurs after the Anybus-S has responded to a request but before the application has
read the handshake register. In this case there is a potential risk that the application starts the handshake
procedures before the Anybus-S is ready.
Power
/RESET
/INT
Response aborted by reset
"False" Interrupt
Read 7FFh
AnyBus Ready
Read 7FFh
1. These diagrams do not show exact timing, but rather the relationship and sequence of events.
Interrupt Line and Hardware Reset C-2
Recommended Solution
For a safe initialization in any of the situations described previously, it is recommended that the application perform an extra “dummy” read of the Anybus Indication Register (7FFh), while the reset line is
held low or within t < 120 ms after the reset line is released.
Hardware Reset – Case 2 Handled Correctly
Power
/RESET
t
/INT
Response aborted by reset
"Dummy read" (7FFh)
AnyBus Ready
Read 7FFh
Appendix D
Electrical Specification
Power Supply Requirements
The module features dual power supply pins. These can either be tied together or powered separately,
depending on the power supply in the host application. Either way, both must be powered in order for
the module to operate properly. Generally, it is recommended to tie both power supplies together.
Symbol Item
Current Consumption
IIN
VCC
tA
Bus Interface (Pin 1)
Module Electronics (Pin 5)
Both (Pins 1 and 5)
Min.
-
Typ.
-
Bus Interface (Pin 1)
Module Electronics (Pin 5)
Maximum Ripple (AC) Bus Interface (Pin 1)
Module Electronics (Pin 5)
Power supply rise time (0.1 VCC to 0.9 VCC)
4.75
4.75
-
5.00
5.00
-
Supply Voltage (DC)
Max.
300
300
450a
5.25
5.25
± 100 pp
± 100 pp
50
Unit
mA
mA
mA
V
V
mV
mV
ms
a. The maximum input current on both the bus interface and the module electronics summed together.
Note:The values in the table above are valid for most modules. At the time of writing there is one exception, the Anybus-S Profinet IRT FO. Please contact HMS for further information.
As an extra precaution, a bulk capacitor can be added close to the module power supply:
Capacitor Type
Cheramic
Electrolythe
Value
22uF / 6.3V
100uF / 16V
Electrical Specification D-2
Signal Characteristics
Symbol Item
Output High Voltage
VOH
D0-D7
Min.
2.4
Typ.
-
Max.
-
Unit Test Conditions
V
IOH = -4.0 mA
Tx
3.5
-
-
V
IOH = -1.0 mA
D0-D7
-
-
0.4
V
IOL = 4.0 mA
BUSY, IRQ
-
-
0.5
V
IOL = 16.0 mA
Tx
-
-
0.4
V
IOL = 1.60 mA
A0-A11, D0-D7, CE,
OE, R/W
Rx
RES
A0-A11, D0-D7, CE,
OE, R/W
Rx
RES
2.2
-
-
V
-
2.0
3.5
-
-
0.8
V
V
V
-
-
-
0.8
0.8
V
V
-
-5
-
+5
µA
GND VI VCC
IOZ
A0-A11, D0-D7, CE,
OE, R/W
Output Leakage Current D0-D7
-5
-
+5
µA
-
Pulse Width
1.0
-
-
µs
GND VO VCC
(Output Disabled)
-
VOL
Output Low Voltage
Input High Voltage
VIH
VIL
Input Low Voltage
IIX
Input Load Current
RES
Note: Pull up resistors are not considered in these characteristics.
PE & Shielding Recommendations
In order to achieve proper EMC behaviour, the module must be properly connected to protective earth
in accordance with the fieldbus requirements.
The Anybus-S features three metal plated mounting holes, out of which two are used for extended electrical connection between the application and the module. One of these two holes are used for connection to protective earth (PE). This hole will from now on be referred to as ‘the PE-hole’
If the housing of the application is of non conductive type, it is recommended to use PE-hole. However,
if the housing of the application is conductive, there are a two options:
•
Protective Earth connection via PE-hole
In this case, the fieldbus connector must be completely isolated from the application housing in
order to avoid ground loops etc.
•
Protective Earth connection via fieldbus connector / application housing
In this case, the PE-hole must be isolated from the application in order to avoid ground loops
etc.
The application must provide support for these different options in order to ensure compatibility with
all fieldbus systems. This issue becomes a bit more complex when using a fieldbus system that uses more
than one fieldbus connector as these connectors may need to be treated differently. In these cases, it is
recommended to isolate the fieldbus connectors from the application housing and use the PE-hole.
Contact HMS and/or consult each fieldbus specification for further information regarding PE/shielding
requirements.
Appendix E
Environmental Specification
Temperature
Operating
+0 to +70 degrees Celsius
(Test performed according to IEC-68-2-1 and IEC 68-2-2.)
Non Operating
-15 to +85 degrees Celsius
(Test performed according to IEC-68-2-1 and IEC 68-2-2.)
Relative Humidity
The product is designed for a relative humidity of 5 to 95% non-condensing.
Test performed according to IEC 68-2-30.
EMC compliance
EMC pre-compliance testing has been conducted according to the Electromagnetic Compatibility Directive
2004/108/EC.
Details about what standards that have been used, can be found in the separate EMC pre-compliance
documents, available for download for each product at www.anybus.com.
Appendix F
Conformance with Predefined Standards
Fieldbus Certification
All Anybus-S modules are pre-certified and found to comply with each fieldbus standard. Please note
that although the module itself has been pre-certified, the final product may still require re-certification
depending on the fieldbus standard.
This pre-certification is valid under the following conditions:
•
Standard fieldbus connectors
•
No fieldbus specific initialization parameters
•
Non-modified device description file (i.e. ‘.GSD’ or ‘.EDS’)
If any of these conditions change, the module is not considered to be pre-certified and requires re-certification.
For more information, consult the fieldbus standard and/or contact HMS.
CE-Mark
Generally, most Anybus-S modules are certified according to the European CE standard unless otherwise stated. It is however important to note that although the Anybus-S itself is certified, the final product may still require re-certification depending on the application.
UL/cUL-Certificate
The Anybus-S modules are UL/cUL recognized for the US (NRAQ2) and Canada (NRAQ8) according
to UL508, “Programmable Controller”.
Appendix G
Troubleshooting
The module does not exchange data
•
Check the Anybus-S Watchdog LED. If the module does not flash green at 1hz, this means that
the module is not initialised and therefore cannot exchange data.
Initialization troubles
•
Verify that the responses to the initialization mailbox messages does not contain any error indications.
•
The maximum I/O/Parameter data sizes may differ between different fieldbus systems. Verify
that the initialization parameters suit the currently used Anybus-S version.
•
If using the HW_CHK mailbox message - does the module respond? If not, the module has detected a hardware problem. The reason for the problem is indicated on the Anybus-S Watchdog
LED.
•
If using the ‘Load from FLASH’ mailbox command - ensure that the flash actually contains a
valid mailbox sequence.
The driver example in this document does not work
•
In most cases, the example can’t work without modifications as it would require very specific
conditions to be met. Instead, we have chosen to illustrate how the code should work generally
rather than going into details on how to implement the code in a particular application.
•
The example is provided for educational purposes and is far from complete. Several essential
functions for initialization, error handling etc. has intentionally been left out and must be implemented by the user.
Common Handshaking Troubles, solutions
•
Never write new commands to the Application Indication Register unless the module has responded to a previous command in the Anybus Indication Register first.
•
Write to the Application Indication Register only when required. Unnecessary accesses to this
register will only result in loss of processing power. Use locked requests if an area should be accessed as soon as possible.
Reset Related Problems
•
If the application utilizes hardware reset, for example via a manual reset button, there is a risk of
the interrupt line being held at a low level from the start. Therefore, certain precautions are needed to ensure proper functionality. See C-1 “Interrupt Line and Hardware Reset”x
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