Ethernet POWERLINK
Communication Profile Specification
EPSG DS 301 V1.5.1

EPSG Draft Standard 301

Ethernet POWERLINK
Communication Profile Specification

Version 1.5.1©

B&R(B&R Industrial Automation GmbH)
2023

EPSG DS 301 V1.5.1-2-

B&R Industrial Automation GmbH

POWERLINK-Office
B&R Straße 15142 Eggelsberg
Austria

powerlink.office@br-automation.com
www.br-automation.com/en/technologies/powerlink/

The EPSG Draft Standard 301 “Ethernet Powerlink Communication Profile Specification” has been
provided by Ethernet POWERLINK Standardisation Group (hereinafter referred to as “EPSG”). As aconsequence of the EPSG being dissolved from March 31st, 2023, B&R Industrial Automation GmbHwill – as the formal successor of EPSG regarding the rights and content – make the Ethernet
Powerlink Communication Profile Specification available as open source on it’s own website subject tothe conditions mentioned in the disclaimer under clause Pre. 1 of this document. B&R Industrial
Automation GmbH especially disclaims liability for any personal injury, property or other damage, of
any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly
resulting from the publication, use of, or reliance upon this, or any other EPSG Standard document.

EPSG DS 301 V1.5.1

Pre. 1-3-Disclaimer

Use of this EPSG Standard is wholly voluntary. The EPSG disclaims liability for any personal injury,
property or other damage, of any nature whatsoever, whether special, indirect, consequential, orcompensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any
other EPSG Standard document.
The EPSG does not warrant or represent the accuracy or content of the material contained herein,and expressly disclaims any express or implied warranty, including any implied warranty ofmerchantability or fitness for a specific purpose, or that the use of the material contained herein is freefrom patent infringement. EPSG Standards documents are supplied “AS IS”.
The existence of an EPSG Standard does not imply that there are no other ways to produce, test,
measure, purchase, market, or provide other goods and services related to the scope of the EPSG
Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued issubject to change brought about through developments in the state of the art and comments received
from users of the standard. Users are cautioned to check to determine that they have the latest editionof any EPSG Standard.
In publishing and making this document available, the EPSG is not suggesting or rendering
professional or other services for, or on behalf of, any person or entity. Nor is the EPSG undertaking toperform any duty owed by any other person or entity to another. Any person utilizing this, and anyother EPSG Standards document, should rely upon the advice of a competent professional indetermining the exercise of reasonable care in any given circumstances.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as
they relate to specific applications. When the need for interpretations is brought to the attention of the
EPSG, the group will initiate action to prepare appropriate responses. Since EPSG Standards
represent a consensus of concerned interests, it is important to ensure that any interpretation has also
received the concurrence of a balance of interests. For this reason, the EPSG and it’s members are
not able to provide an instant response to interpretation requests except in those cases where thematter has previously received formal consideration.
Comments for revision of EPSG Standards are welcome from any interested party, regardless ofmembership affiliation with the EPSG. Suggestions for changes in documents should be in the form ofa proposed change of text, together with appropriate supporting comments. Comments on standards
and requests for interpretations should be sent to the address given on the page before.

Pre 1.1

Patent noticeAttention is called to the possibility that implementation of this standard may require use of subject
matter covered by patent rights. By publication of this standard, no position is taken with respect to theexistence or validity of any patent rights in connection therewith. B&R shall not be responsible for
identifying patents for which a license may be required by an EPSG standard or for conducting
inquiries into the legal validity or scope of those patents that are brought to its attention.

EPSG DS 301 V1.5.1

Pre. 2-4-

History

Vers.
1.0.0
1.0.1

State
DS
WDP

Date
2006-04-18
2008-01-30

Author / Company
Knopke et al.
Kirchmayer

Lenze et al.
B&R et al.

1.0.2
1.0.3
1.0.4

WDP
WDP
WDP

2008-06-13
2008-07-23
2008-09-05

Kirchmayer
Kirchmayer
Kirchmayer

B&R et al.
B&R et al.
B&R et al.

1.0.4
1.0.5
1.1.0

DSP
DSP
DS

2008-09-08
2008-10-17
2008-10-22

Kirchmayer
Kirchmayer
Kirchmayer

B&R et al.
B&R et al.
B&R et al.

1.1.1

WDP

2010-01-13

Kirchmayer

B&R et al.

1.1.2
1.1.3

WDP
WDP

2010-08-04
2011-08-12

Kirchmayer
Kirchmayer

B&R et al.
B&R et al.

1.1.4
1.1.5

WDP
WDP

2012-08-30
2013-02-27

Kirchmayer
Kirchmayer

B&R et al.
B&R et al.

1.1.6

WDP

2013-04-30

Kirchmayer

B&R et al.

1.1.7

WDP

2013-06-11

Kirchmayer

B&R et al.

1.1.7
1.2.0

DSP
DS

2013-06-11
2013-12-18

Kirchmayer
Kirchmayer

B&R
B&R

1.2.0
1.2.1
1.2.2
1.2.3

DS
WDP
WDP
DSP

2014-05-28
2014-09-25
2015-09-25
2015-12-16

Kirchmayer
Kirchmayer
Kirchmayer
Kirchmayer

B&R
B&R
B&R
B&R

1.3.0
1.3.0a
1.3.1
1.3.2

DS
DS
WDP
WDP

2016-03-23
2016-11-23
2016-12-19
2017-05-22

Kirchmayer
Kirchmayer
Kirchmayer
Kirchmayer

B&R
B&R
B&R
B&R

1.3.3
1.3.4

WDP
DSP

2017-08-18
2018-08-18

Kirchmayer
Kirchmayer

B&R
B&R

1.4.0

DS

2018-11-13

Kirchmayer

B&R

1.4.1

WDP

2021-08-21

Kirchmayer

B&R

1.5.0
1.5.1

DS
DS

2021-09-22
2023-04-06

Kirchmayer
Kirchmayer

B&R
B&R

Description
DS version created from working documents
WDP version created from DS 1.0.0
Changes from TWG meetings in 6/07 and10/07.
Changes from TWG meetings in 2/07 and 2/08.
Changes from TWG meeting in 6/08.
Objects used in EPSG DS 302-A are marked
as reserved.
Feedback from certification meeting
Status changes to Draft Standard Proposal
Feedback from TWG conference call in 10/08
DS version created from DSP 1.0.5
Minor layout changes
WDP version created from DS 1.1.0
Changes from TWG meeting in 6/09
Feedback from ITEI (China)
Changes from TWG meeting in 3/10
Changes from TWG meeting in 9/10
Refer ot IEC instead of IAONA standards
Changes from TWG meeting in 10/11
Changes from TWG meeting in 9/12
Contribution list removed
PDO mapping attribute of 1F8Ch is Opt
Changes from TWG meeting in 3/13
Reference to polling order corrected in 4.2.4.4
Maximum SDO payload size corrected
No PReq to CN in NMT_CS_STOPPED
corrected
Changes from TWG telco in 5/13,
Clarify Tab. 53, Replace Sender/Receiver by
Client/Server in Fig. 45 to Fig. 54
Status change to DSP
Changes from TWG meeting in 12/13
Update of references to other standards
Status change to DS
Typos corrected
Changes from TWG meeting 06/14
Changes from TWG meeting 06/15
Changes from TWG meeting 12/15
Status change to DSPStatus change to DS
Typos and other corrections
Changes from TWG meeting 9/16
Changes from TWG meeting 5/17,
Typos and NMT_EPLNodeID_TYPE corrected
Changes from TWG meeting 7/17
Changes from TWG meeting 3/18
Status change to DSP
Changes from TWG meeting 10/18
Status change to DS
Remove default values from 1F93h si1(NodeID_U8) and si3 (SWNodeID_U8)
Missing text in Fig. 62 completed
Typos and update of referenced versions
Remove dates/versions from references
Status change to DS© B&R due to dissolution of the EPSGEPSG DS 301 V1.5.1

Pre. 3-5-

Change Record

The changes based on the last valid Communication Profile Specification (EPSG DS 301 V1.5.0a) aretracked in a separate change record. Hereby the change record provides a detailed history from thelast draft standard to the current one.

EPSG DS 301 V1.5.1

Pre. 4Pre. 1
Pre 1.1
Pre. 2Pre. 3Pre. 4Pre. 5Pre. 6Pre. 7
Pre 7.1
Pre 7.2
Pre. 8
1
1.1
1.2
1.3
1.4
2
2.1
2.1.1
2.1.1.1
2.1.1.2
2.2
2.2.1
2.2.2
2.2.2.1
2.3
2.3.1
2.3.2
2.3.3
2.3.4
3
3.1
3.1.1
3.1.2
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.3.3.1
3.3.3.2
3.3.3.3
3.4
4
4.1
4.2
4.2.1
4.2.2
4.2.2.1
4.2.2.2
4.2.2.2.1
4.2.2.2.2
4.2.3
4.2.4
4.2.4.1
4.2.4.1.1
4.2.4.1.1.1
4.2.4.1.2
4.2.4.1.2.1
4.2.4.1.2.2
4.2.4.1.2.3
4.2.4.1.3
4.2.4.2
4.2.4.3
4.2.4.3.1
4.2.4.4
4.2.4.5-6-

Content
Disclaimer
Patent noticeHistory
Change Record
Content
TablesFiguresDefinitions and Abbreviations
Definitions
Abbreviations
References
Introduction
Slot Communication Network Management
POWERLINK key features
Integration
Modular Machines
Modelling
Reference Model
Application Layer
Service Primitives
Application Layer Service Types
Device Model
GeneralThe Object Dictionary
Index and Sub-Index Usage
Communication Model
Master/Slave relationship
Client/Server relationship
Producer/Consumer relationship - Push/Pull modelSuperimposing of Communication Relationships
Physical Layer
Topology
Hubs
Switches
Network Guidelines
JitterPorts and Connectors
RJ-45
M12
Crossover Pin Assignment
RJ45 to RJ45
M12 to M12M12 to RJ45
Cables (recommendation)
Data Link Layer
Modes of Operation
POWERLINK Mode
Introduction
POWERLINK Nodes
POWERLINK Managing Node
POWERLINK Controlled Node
Isochronous CN
Async-only CN
Services
POWERLINK Cycle
Isochronous POWERLINK Cycle
Isochronous phase
Multiplexed Timeslots
Asynchronous phase
Asynchronous SchedulingDistribution of the Asynchronous phase
Asynchronous Transmit Priorities
Idle Phase
Reduced POWERLINK Cycle
POWERLINK Cycle Timing
POWERLINK Cycle Timing Error HandlingMultiplexed Slot Timing
CN Cycle State Machine

3
3
4
5
6
15
18
20
20
22
24
25
25
25
26
27
28
28
28
28
29
29
29
30
32
32
32
33
33
34
35
35
35
35
35
36
36
36
36
37
37
37
38
38
39
39
39
39
39
39
40
40
40
40
40
41
41
42
43
44
44
44
47
47
47
55
58
58

EPSG DS 301 V1.5.1
4.2.4.5.1
4.2.4.5.2
4.2.4.5.3
4.2.4.5.4
4.2.4.5.4.1
4.2.4.5.4.1.1
4.2.4.5.4.2
4.2.4.5.4.2.1
4.2.4.6
4.2.4.6.1
4.2.4.6.2
4.2.4.6.3
4.2.4.6.4
4.2.4.6.4.1
4.2.4.6.4.2
4.2.4.6.4.3
4.2.4.6.4.3.1
4.2.4.6.4.4
4.2.4.6.4.4.1
4.2.5
4.3
4.4
4.4.1
4.4.2
4.4.3
4.5
4.6
4.6.1
4.6.1.1
4.6.1.1.1
4.6.1.1.2
4.6.1.1.3
4.6.1.1.4
4.6.1.1.5
4.6.1.1.5.1
4.6.1.1.6
4.6.1.1.6.1
4.6.1.2
4.6.1.3
4.7
4.7.1
4.7.2
4.7.3
4.7.4
4.7.4.1
4.7.4.2
4.7.5
4.7.5.1
4.7.5.2
4.7.5.3
4.7.5.4
4.7.6
4.7.6.1
4.7.6.1.1
4.7.6.1.1.1
4.7.6.1.1.2
4.7.6.1.1.3
4.7.6.2
4.7.6.3
4.7.6.4
4.7.6.5
4.7.6.6
4.7.6.7
4.7.6.8
4.7.6.9
4.7.7
4.7.7.1
4.7.7.2
4.7.7.3
4.7.7.3.1
4.7.7.3.2
4.7.7.3.3-7-

Overview
StatesEventsDependance of the NMT_CS on the DLL_CS
State NMT_GS_INITIALISATION, NMT_CS_NOT_ACTIVE, NMT_CS_BASIC_ETHERNET,
NMT_CS_PRE_OPERATIONAL_1
Transitions in other NMT states
State NMT_CS_PRE_OPERATIONAL_2, NMT_CS_READY_TO_OPERATE,
NMT_CS_OPERATIONAL, NMT_CS_STOPPEDTransitions
MN Cycle State Machine
Overview
StatesEventsUsage of the NMT_MS state by the DLL_MS
State NMT_GS_INITIALISATION, NMT_MS_NOT_ACTIVE
NMT_MS_BASIC_ETHERNETState NMT_MS_PRE_OPERATIONAL_1
Transitions
State NMT_MS_OPERATIONAL, NMT_MS_READY_TO_OPERATE and
NMT_MS_PRE_OPERATIONAL_2
Transitions
Recognizing Active Nodes
Basic Ethernet Mode
MAC Addressing
MAC Unicast
MAC Multicast
MAC Broadcast
POWERLINK Addressing
Frame Structures
Integration with Ethernet
POWERLINK Frame
POWERLINK Basic Frame
Start of Cycle (SoC)
PollRequest (PReq)
PollResponse (PRes)
Start of Asynchronous (SoA)
RequestedServiceID s
Asynchronous Send (ASnd)
ServiceID values
Non-POWERLINK Frames
Transfer Protection
Error Handling Data Link Layer (DLL)
Possible Error Sources and Error Symptoms
Error Handling Table for CN
Error Handling Table for MN
Error Handling Registration
Threshold counters
Cumulative Counter
Physical Layer Error Sources
Loss of Link
Incorrect physical Ethernet operating mode
Rx MAC buffer overflow / Tx MAC buffer underrun
Transmission / CRC Errors
Communication Error Symptoms detected by the MN
Timing Violation
Slot Time Exceeded
Case 1-2 Frame received in time
Case 3 Loss of PRes: Frame not received
Case 4-6 Late PRes: Frame received in foreign slot (also collisions)
Loss of PRes
Late PRes
Cycle Time Exceeded
Collisions
Invalid Formats
POWERLINK Address Conflicts
Multiple MNs on a single POWERLINK Network
Loss of StatusResponse
Communication Error Symptoms detected by the CN
Collisions
Invalid Formats
Loss of Frames
Loss of SoC
Loss of SoA
Loss of PReq

58
59
59
59
60
60
61
61
63
63
63
63
64
64
64
64
65
66
66
68
68
69
69
69
69
69
70
70
70
70
72
73
74
75
75
76
76
77
77
77
77
78
79
80
81
81
81
81
82
82
83
83
83
83
84
84
84
85
86
87
88
89
89
90
90
91
91
92
92
93
93
94

EPSG DS 301 V1.5.1
4.7.7.3.4
4.7.8
4.7.8.1
4.7.8.2
4.7.8.3
4.7.8.4
4.7.8.5
4.7.8.6
4.7.8.7
4.7.8.8
4.7.8.9
4.7.8.10
4.7.8.11
4.7.8.12
4.7.8.13
4.7.8.14
4.7.8.15
4.7.8.16
4.7.8.17
4.7.8.18
4.7.8.19
4.7.8.20
4.7.8.21
4.7.8.22
4.7.8.23
4.7.8.24
5
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.1.2.1
5.1.1.2.2
5.1.1.3
5.1.1.3.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.5.1
5.1.5.2
5.1.5.3
5.1.5.4
5.2
5.3
6
6.1
6.1.1
6.1.2
6.1.3
6.1.3.1
6.1.3.2
6.1.4
6.1.4.1
6.1.4.2
6.1.4.3
6.1.4.4
6.1.4.5
6.1.4.6
6.1.4.7
6.1.4.8
6.1.4.9
6.1.5
6.1.6
6.1.6.1
6.1.6.2
6.1.6.3
6.1.6.4
6.1.6.5
6.1.6.6
6.1.6.7
6.2
6.2.1
6.2.1.1
6.2.2-8-

SoC Jitter out of Range
DLL Error Handling Objects
Object 1C00h: DLL_MNCRCError_REC
Object 1C01h: DLL_MNCollision_REC
Object 1C02h: DLL_MNCycTimeExceed_REC
Object 1C03h: DLL_MNLossOfLinkCum_U32
Object 1C04h: DLL_MNCNLatePResCumCnt_AU32
Object 1C05h: DLL_MNCNLatePResThrCnt_AU32
Object 1C06h: DLL_MNCNLatePResThreshold_AU32
Object 1C07h: DLL_MNCNLossPResCumCnt_AU32
Object 1C08h: DLL_MNCNLossPResThrCnt_AU32
Object 1C09h: DLL_MNCNLossPResThreshold_AU32
Object 1C0Ah: DLL_CNCollision_REC
Object 1C0Bh: DLL_CNLossSoC_REC
Object 1C0Ch: DLL_CNLossSoA_REC
Object 1C0Dh: DLL_CNLossPReq_REC
Object 1C0Eh: DLL_CNSoCJitter_REC
Object 1C0Fh: DLL_CNCRCError_REC
Object 1C10h: DLL_CNLossOfLinkCum_U32
Object 1C12h: DLL_MNCycleSuspendNumber_U32
Object 1C13h: DLL_CNSoCJitterRange_U32
Object 1C14h : DLL_CNLossOfSocTolerance_U32
Object 1C15h: DLL_MNLossStatusResCumCnt_AU32
Object 1C16h: DLL_MNLossStatusResThrCnt_AU32
Object 1C17h: DLL_MNLossStatusResThreshold_AU32
Object 0424h: DLL_ErrorCntRec_TYPE
Network / Transport Layer
Internet Protocol (IP)
IP Host Requirements
Nodes without IP Communication
Minimum Requirements for SDO Communication
IP Stack Requirements
UDP Requirements
Minimum Requirements for Standard IP Communication
IP Stack Requirements
IP Addressing
Address Resolution
Hostname
Object description
Object 1E4Ah: NWL_IpGroup_REC
Object 1E40h .. 1E49h: NWL_IpAddrTable_Xh_REC
Object 0425h: NWL_IpGroup_TYPE
Object 0426h: NWL_IpAddrTable_TYPE
POWERLINK compliant UDP/IP format
POWERLINK Sequence Layer
Application Layer
Data Types and Encoding Rules
General Description of Data Types and Encoding Rules
Data Type Definitions
Bit Sequences
Definition of Bit Sequences
Transfer Syntax for Bit Sequences
Basic Data Types
NIL
BooleanVoid
Bit
Unsigned Integer
Signed Integer
Floating-Point Numbers
MAC Address
IP address
Compound Data Types
Extended Data Types
Octet String
Visible String
Unicode String
Time of Day
Time Difference
DomainNet Time
Object Dictionary
Object Dictionary Entry Definition
Sub-Index Definition
Data Type Entry Specification

94
95
95
96
97
98
98
99
99
100
100
101
102
103
104
105
106
107
108
108
108
108
109
109
110
110
111
111
111
111
111
111
111
111
112
112
112
113
114
114
115
116
116
117
117
118
118
118
118
119
119
120
120
120
120
120
120
121
121
122
122
123
123
124
124
124
124
124
124
124
125
125
125
128
129

EPSG DS 301 V1.5.1
6.2.2.1
6.2.2.2
6.2.2.3
6.3
6.3.1
6.3.1.1
6.3.2
6.3.2.1
6.3.2.1.1
6.3.2.2
6.3.2.3
6.3.2.3.1
6.3.2.3.1.1
6.3.2.3.1.2
6.3.2.3.1.3
6.3.2.3.1.4
6.3.2.3.1.5
6.3.2.3.2
6.3.2.3.2.1
6.3.2.3.2.2
6.3.2.3.2.3
6.3.2.3.2.4
6.3.2.3.2.5
6.3.2.3.2.6
6.3.2.4
6.3.2.4.1
6.3.2.4.1.1
6.3.2.4.1.2
6.3.2.4.1.3
6.3.2.4.2
6.3.2.4.2.1
6.3.2.4.2.1.1
6.3.2.4.2.1.2
6.3.2.4.2.1.3
6.3.2.4.2.1.4
6.3.2.4.2.1.5
6.3.2.4.2.1.6
6.3.2.4.2.2
6.3.2.4.2.2.1
6.3.2.4.2.2.2
6.3.2.4.2.3
6.3.2.4.2.3.1
6.3.2.4.2.3.2
6.3.2.4.2.3.3
6.3.2.4.2.3.4
6.3.2.4.2.3.5
6.3.2.4.2.3.6
6.3.2.4.2.4
6.3.2.4.2.4.1
6.3.3
6.3.3.1
6.3.3.1.1
6.3.3.1.1.1
6.3.3.1.1.2
6.3.3.1.1.3
6.3.3.1.2
6.3.3.1.2.1
6.3.3.1.2.2
6.3.3.1.3
6.3.3.1.3.1
6.3.3.1.3.2
6.3.3.2
6.3.3.2.1
6.3.3.2.2
6.3.3.3
6.3.3.3.1
6.3.3.3.2
6.3.3.3.3
6.3.4
6.3.4.1
6.3.4.2
6.3.4.3
6.4
6.4.1
6.4.1.1
6.4.1.2-9-

Static Data Types
Complex Data Types
Extension for Multiple Device Modules
Service Data (SDO)
SDO Layer Model
SDO Hosting in Frames
SDO in Asynchronous Phase
SDO via UDP/IP
UDP Layer
SDO via POWERLINK ASnd
Asynchronous SDO Sequence Layer
Connection
Initialisation of Connection
Closing a connection
Data Transfer
Data Transfer with Delay
Sender History Full
ErrorsError: Loss of Frame with Data
Error: Loss of Acknowledge Frame
Error: Duplication of Frame
Error: Overtaking of Frames
Broken Connection
Error: Flooding with commands
Asynchronous SDO Command Layer
POWERLINK Command Layer Protocol
Download Protocol
Upload Protocol
Abort Transfer
Commands
SDO Protocol
Command: Write by Index
Command: Read by Index
Command: Write All by Index
Command: Read All by Index
Command: Write by Name
Command: Read by Name
File Transfer
Command: File Write
Command: File Read
Variable groups
Command: Write Multiple Parameter by Index
Write Multiple Parameter by Index Request
Write Multiple Parameter by Index Response
Command: Read Multiple Parameter by Index
Read Multiple Parameter by Index Request
Read Multiple Parameter by Index Response
Parameter Services
Command: Maximum Segment Size
SDO Embedded in PDO
Embedded Sequence Layer for SDO in PDO
Connection
Initialisation of Connection
Closing a connection
Data Transfer
ErrorsError: Request Lost
Error: Response Lost
Handling of Segmented Transfers
Segmented Download from Client to Server
Segmented Upload from Server to Client
Embedded Command Layer for SDO in Cyclic Data
Command Write by Index via PDO
Command Read by Index via PDO
Object Description
Object 1200h .. 127Fh: SDO_ServerContainerParam_XXh_REC
Object 1280h .. 12FFh: SDO_ClientContainerParam_XXh_REC
Object 0422h: SDO_ParameterRecord_TYPE
SDO Timeouts
Object 1300h: SDO_SequLayerTimeout_U32
Object 1301h: SDO_CmdLayerTimeout_U32
Object 1302h: SDO_SequLayerNoAck_U32
Process Data Object (PDO)
PDO Mapping Limitations
TPDO Mapping Limitations
RPDO Mapping Limitations

130
130
130
130
131
131
131
131
132
134
134
135
135
135
136
136
137
137
138
138
139
139
139
140
140
141
143
144
145
146
146
146
147
147
148
148
149
149
149
150
150
150
151
151
152
152
153
153
153
154
155
156
156
157
158
159
159
160
160
160
161
161
161
162
162
162
163
164
164
164
164
165
165
166
166
166

EPSG DS 301 V1.5.1
6.4.1.3
6.4.2
6.4.3
6.4.4
6.4.5
6.4.6
6.4.7
6.4.8
6.4.8.1
6.4.8.1.1
6.4.8.1.2
6.4.8.2
6.4.9
6.4.9.1
6.4.9.2
6.4.9.3
6.4.9.4
6.4.9.5
6.4.9.6
6.4.9.7
6.5
6.5.1
6.5.2
6.5.3
6.5.4
6.5.5
6.5.5.1
6.5.6
6.5.7
6.5.8
6.5.8.1
6.5.8.2
6.5.9
6.5.9.1
6.5.9.2
6.5.9.3
6.5.9.4
6.5.106.5.10.1
6.5.10.2
6.6
6.6.1
6.6.1.1
6.6.1.2
6.6.1.3
6.6.1.4
6.6.2
6.6.2.1
6.6.2.2
6.7
6.7.1
6.7.1.1
6.7.1.2
6.7.2
6.7.2.1
6.7.2.2
6.7.2.3
6.7.2.4
6.7.3
6.7.3.1
6.7.3.2
6.7.3.3
6.7.3.4
6.7.3.5
6.7.3.6
6.7.3.7
6.7.3.8
6.7.3.9
6.7.3.10
6.7.3.11
6.7.3.12
6.7.3.13
6.8
6.8.1
6.8.2

-10-

Further Limitations
PDO Mapping Version
SDO via PDO Container
Transmit PDOs
Receive PDOs
PDO via PReq
PDO via PResPDO Error Handling
Dynamic Errors
Incompatible Mapping
Unexpected End of PDO
Configuration Errors
Object Description
Object 1400h .. 14FFh: PDO_RxCommParam_XXh_REC
Object 1600h .. 16FFh PDO_RxMappParam_XXh_AU64
Object 1800h .. 18FFh PDO_TxCommParam_XXh_REC
Object 1A00h .. 1AFFh PDO_TxMappParam_XXh_AU64
Object 1C80h: PDO_ErrMapVers_OSTR
Object 1C81h: PDO_ErrShort_RX_OSTR
Object 0420h: PDO_CommParamRecord_TYPE
Error Signaling
Error Entry
Interface to Error Signaling
Processing of CN Error Information on the MN
Error Signaling Bits
Initialisation
Startup value and behaviour of the EC flag
Error Signaling with Preq and Pres frames
Error Signaling with Async-only CNs
Format of StatusResponse Data
Static Error Bit Field
Status and History Entries
ExamplesCase 1 – Only Bit Field, No Status/History Entries
Case 2 – Status Entries
Case 3 – History Entries
Case 4 – Status and History Entries
Object descriptions
Object 1001h : ERR_ErrorRegister_U8
Object 1003h: ERR_History_ADOM
Program Download
Object Dictionary Entries on the CN
Object 1F50h: PDL_DownloadProgData_ADOM
Object 1F51h: PDL_ProgCtrl_AU8
Object 1F52h: PDL_LocVerApplSw_REC
Object 0427h: PDL_LocVerApplSw_TYPE
Object Dictionary Entries on the MN
Object 1F53h: PDL_MnExpAppSwDateList_AU32
Object 1F54h: PDL_MnExpAppSwTimeList_AU32
Configuration Management
Device Description
Local Storage on the Device
Central Storage on the MN
Device Configuration Storage
Device Configuration File Storage
Concise Configuration Storage
Check Configuration Process
Request Configuration
Object Dictionary Entries
Object 1020h: CFM_VerifyConfiguration_REC
Object 1021h: CFM_StoreDevDescrFile_DOM
Object 1022h: CFM_StoreDevDescrFormat_U16
Object 1F20h: CFM_StoreDcfList_ADOM
Object 1F21h: CFM_DcfStorageFormatList_AU8
Object 1F22h: CFM_ConciseDcfList_ADOM
Object 1F23h: CFM_StoreDevDescrFileList_ADOM
Object 1F24h: CFM_DevDescrFileFormatList_AU8
Object 1F25h: CFM_ConfCNRequest_AU32
Object 1F26h: CFM_ExpConfDateList_AU32
Object 1F27h: CFM_ExpConfTimeList_AU32
Object 1F28h: CFM_ExpConfIdList_AU32
Object 0435h: CFM_VerifyConfiguration_TYPE
Input from a Programmable Device
BasicsDynamic index assignment

167
167
168
168
168
168
169
169
169
169
169
170
170
170
171
172
173
174
175
175
175
177
178
178
178
179
179
180
181
181
181
181
182
182
183
184
184
184
184
185
185
186
186
186
187
188
188
189
189
190
190
190
190
190
191
191
191
191
192
192
193
193
194
194
195
196
197
197
198
199
199
200
200
200
201

EPSG DS 301 V1.5.1
6.8.3
6.8.3.1
6.8.3.2
7
7.1
7.1.1
7.1.2
7.1.2.1
7.1.2.1.1
7.1.2.1.1.1
7.1.2.1.1.1.1
7.1.2.1.1.2
7.1.2.2
7.1.3
7.1.3.1
7.1.3.2
7.1.3.2.1
7.1.3.2.2
7.1.3.2.2.1
7.1.3.2.2.2
7.1.3.2.2.3
7.1.3.2.2.4
7.1.3.2.3
7.1.3.3
7.1.4
7.1.4.1
7.1.4.1.1
7.1.4.1.2
7.1.4.1.2.1
7.1.4.1.2.2
7.1.4.1.2.3
7.1.4.1.2.4
7.1.4.1.2.5
7.1.4.1.3
7.1.4.2
7.1.4.3
7.1.4.4
7.2
7.2.1
7.2.1.1
7.2.1.1.1
7.2.1.1.2
7.2.1.1.3
7.2.1.1.4
7.2.1.1.5
7.2.1.1.6
7.2.1.1.7
7.2.1.2
7.2.1.2.1
7.2.1.2.2
7.2.1.3
7.2.1.3.1
7.2.1.3.2
7.2.1.3.3
7.2.1.4
7.2.1.4.1
7.2.1.5
7.2.1.5.1
7.2.1.5.2
7.2.1.5.3
7.2.1.5.4
7.2.1.5.5
7.2.1.6
7.2.1.6.1
7.2.1.7
7.2.1.7.1
7.2.2
7.2.2.1
7.2.2.1.1
7.2.2.1.2
7.2.2.2
7.2.2.2.1
7.2.2.2.2
7.2.2.2.3
7.2.2.2.4-11-

Object dictionary entries
Object 1F70h: INP_ProcessImage_REC
Object 0428h: INP_ProcessImage_TYPE
Network Management (NMT)NMT State Machine
Overview
Common Initialisation NMT State MachineStatesNMT_GS_POWEREDNMT_GS_INITIALISATION
Sub-states
NMT_GS_COMMUNICATING
Transitions
MN NMT State Machine
Overview
States
NMT_MS_NOT_ACTIVE
NMT_MS_EPL_MODE
NMT_MS_PRE_OPERATIONAL_1
NMT_MS_PRE_OPERATIONAL_2
NMT_MS_READY_TO_OPERATENMT_MS_OPERATIONAL
NMT_MS_BASIC_ETHERNETTransitions
CN NMT State MachineStatesNMT_CS_NOT_ACTIVE
NMT_CS_EPL_MODE
NMT_CS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATENMT_CS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNETTransitions
States and Communication Object Relation
Relationship to other state machines
NMT Object Dictionary Entries
NMT General Objects
Identification
Object 1000h: NMT_DeviceType_U32
Object 1008h: NMT_ManufactDevName_VS
Object 1009h: NMT_ManufactHwVers_VS
Object 100Ah: NMT_ManufactSwVers_VS
Object 1018h: NMT_IdentityObject_REC
Object 1F82h: NMT_FeatureFlags_U32
Object 1F83h: NMT_EPLVersion_U8
Parameter Storage
Object 1010h: NMT_StoreParam_REC
Object 1011h: NMT_RestoreDefParam_REC
Communication Interface Description
Object 1F93h: NMT_EPLNodeID_REC
Object 1030h .. 1039h : NMT_InterfaceGroup_Xh_REC
Object 1F9Ah: NMT_HostName_VSTR
Node List
Object 1F81h: NMT_NodeAssignment_AU32
TimingObject 1006h: NMT_CycleLen_U32
Object 1F98h: NMT_CycleTiming_REC
Object 1F9Bh: NMT_MultiplCycleAssign_AU8
Object 1016h: NMT_ConsumerHeartbeatTime_AU32
Object 1F8Dh: NMT_PresPayloadLimitList_AU16
NMT Service Interface
Object 1F9Eh: NMT_ResetCmd_U8
NMT Diagnostics
Object 1F8Ch: NMT_CurrNMTState_U8
NMT MN Objects
MN Start Up Behavior
Object 1F80h: NMT_StartUp_U32
Object 1F89h: NMT_BootTime_REC
NMT Master Network Node Lists
Object 1F84h: NMT_MNDeviceTypeIdList_AU32
Object 1F85h: NMT_MNVendorIdList_AU32
Object 1F86h: NMT_MNProductCodeList_AU32
Object 1F87h: NMT_MNRevisionNoList_AU32

201
202
202
203
203
203
203
203
203
203
204
205
205
207
207
207
207
208
208
208
208
209
209
210
211
211
211
212
212
212
212
213
213
213
214
214
215
216
216
216
216
216
217
217
217
218
220
220
220
222
224
224
225
228
229
229
231
231
231
234
235
236
237
237
237
237
237
237
237
239
241
241
242
243
243

EPSG DS 301 V1.5.1
7.2.2.2.5
7.2.2.3
7.2.2.3.1
7.2.2.3.2
7.2.2.3.3
7.2.2.3.4
7.2.2.4
7.2.2.4.1
7.2.2.4.2
7.2.2.5
7.2.2.5.1
7.2.3
7.2.3.1
7.2.3.1.1
7.2.4
7.2.4.1
7.2.4.2
7.2.4.3
7.2.4.4
7.2.4.5
7.2.4.6
7.2.4.7
7.2.4.8
7.3
7.3.1
7.3.1.1
7.3.1.1.1
7.3.1.2
7.3.1.2.1
7.3.1.2.1.1
7.3.1.2.2
7.3.1.2.3
7.3.2
7.3.2.1
7.3.2.1.1
7.3.2.1.2
7.3.3
7.3.3.1
7.3.3.2
7.3.3.2.1
7.3.3.3
7.3.3.3.1
7.3.4
7.3.4.1
7.3.4.1.1
7.3.4.1.2
7.3.4.1.3
7.3.4.1.4
7.3.4.1.5
7.3.4.1.6
7.3.4.1.7
7.3.4.1.8
7.3.4.1.9
7.3.4.1.10
7.3.5
7.3.5.1
7.3.5.1.1
7.3.5.2
7.3.6
7.3.6.1
7.3.6.1.1
7.3.7
7.3.7.1
7.3.7.2
7.3.8
7.4
7.4.1
7.4.1.1
7.4.1.2
7.4.1.3
7.4.1.4
7.4.1.5
7.4.1.6
7.4.2
7.4.2.1
7.4.2.2-12-

Object 1F88h: NMT_MNSerialNoList_AU32
TimingObject 1F8Ah: NMT_MNCycleTiming_REC
Object 1F8Bh: NMT_MNPReqPayloadLimitList_AU16
Object 1F92h: NMT_MNCNPResTimeout_AU32
Object 1F9Ch: NMT_IsochrSlotAssign_AU8
CN NMT State Surveillance
Object 1F8Eh: NMT_MNNodeCurrState_AU8
Object 1F8Fh: NMT_MNNodeExpState_AU8
NMT Service Interface
Object 1F9Fh: NMT_RequestCmd_REC
NMT CN Objects
CN StartUp Behaviour
Object 1F99h: NMT_CNBasicEthernetTimeout_U32
NMT Object Types
Object 0023h: IDENTITY
Object 0429h: NMT_ParameterStorage_TYPE
Object 042Bh: NMT_InterfaceGroup_TYPE
Object 042Ch: NMT_CycleTiming_TYPE
Object 042Eh: NMT_BootTime_TYPE
Object 042Fh: NMT_MNCycleTiming_TYPE
Object 0439h: NMT_EPLNodeID_TYPE
Object 043Ah: NMT_RequestCmd_TYPE
Network Management Services
NMT State Command Services
Implicit NMT State Command Services
Implicit NMT State Command Transmission
Explicit NMT State Command Services
Plain NMT State Command
NMT Reset Commands to the MN
Extended NMT State Command
POWERLINK Node List Format
NMT Managing Command Services
Service Descriptions
NMTNetHostNameSet
NMTFlushArpEntry
NMT Response Services
NMT State Response
IdentResponse Service
IdentResponse Frame
StatusResponse Service
StatusResponse FrameNMT Info Services
Service Descriptions
NMTPublishConfiguredNodes
NMTPublishActiveNodes
NMTPublishPreOperational1
NMTPublishPreOperational2
NMTPublishReadyToOperate
NMTPublishOperational
NMTPublishStopped
NMTPublishNodeStates
NMTPublishEmergencyNew
NMTPublishTime
NMT Guard Services
Guarding CNs
Guarding Async-Only CNs
Guarding the MN
Request NMT Services by a CN
NMTRequest Frame
Invalid NMTRequests
NMT Services via Object Dictionary
NMT Reset Commands
NMT Requests to the MN
NMT Services via UDP/IP
Boot-up Managing Node
NMT_MS dependant Network Boot-up
Overview
NMT_MS_NOT_ACTIVE
NMT_MS_PRE_OPERATIONAL_1
NMT_MS_PRE_OPERATIONAL_2
NMT_MS_READY_TO_OPERATENMT_MS_OPERATIONAL
MN Boot-up Procedure on CN Level
Overview
Boot-up of optional and mandatory CNs

244
245
245
246
247
247
249
249
249
250
250
251
251
251
252
252
252
252
252
253
253
253
253
254
254
254
255
255
256
258
258
258
259
260
260
261
261
261
262
263
265
265
266
267
267
267
267
268
268
268
268
268
269
269
269
269
269
270
270
270
270
271
271
271
271
272
272
272
272
273
274
276
277
279
279
279

EPSG DS 301 V1.5.1
7.4.2.2.1
7.4.2.2.1.1
7.4.2.2.1.2
7.4.2.2.1.3
7.4.2.2.1.3.1
7.4.2.2.2
7.4.2.2.3
7.4.2.2.4
7.4.2.2.5
7.4.2.2.6
7.4.2.2.7
7.4.2.2.8
7.4.2.2.9
7.4.3
7.4.3.1
7.4.3.2
7.4.3.3
7.4.3.4
7.4.3.5
7.4.3.6
7.4.3.7
7.4.3.8
7.4.3.9
7.4.3.10
7.4.3.11
7.4.3.12
7.4.3.13
7.4.3.14
7.4.3.15
7.4.3.16
7.4.4
7.4.5
7.4.6
8
8.1
8.1.1
8.1.2
8.1.3
8.1.3.1
8.1.3.2
9
9.1
9.1.1
9.1.2
9.1.3
9.1.3.1
9.1.3.2
9.1.4
9.1.4.1
9.1.4.2
9.1.4.2.1
9.1.4.2.1.1
9.1.4.2.1.1.1
9.1.4.2.1.1.2
9.1.4.2.2
9.1.4.2.2.1
9.1.4.2.2.1.1
9.1.4.2.2.1.2
9.1.5
9.1.5.1
9.1.5.1.1
9.1.5.1.2
9.1.5.1.3
9.1.5.1.3.1
9.1.5.1.3.2
9.1.6
9.1.7
9.1.7.1
9.1.7.2
9.1.7.3
9.1.7.4
9.1.7.5
9.1.7.6
9.1.7.7
9.1.7.8-13-

BOOT_STEP1CHECK_IDENTIFICATIONCHECK_SOFTWARECHECK_CONFIGURATIONGET_IDENT
BOOT_STEP2CHECK_COMMUNICATIONSTART_CN
START_ALL
CHECK_STATECHANGE_NMT_STATEOPERATIONALERROR_TREATMENT
Boot-up Errors
Bus activity
BOOT_STEP1 failed
BOOT_STEP2 failed
Boot-up in NMT_MS_READY_TO_OPERATE failed
Get Ident failed
Device Type Invalid
Vendor ID invalid
Configuration failed
Product Code invalid
Revision number invalid
Serial number invalid
NMT state invalid
Invalid Software
Invalid NMT state for SW update
SW update not allowed
SW update failed
Minimal Boot-up MN
Example Boot-up Sequence
Application Notes
Diagnostics
Diagnostic Object Dictionary Entries
Object 1101h: DIA_NMTTelegrCount_REC
Object 1102h: DIA_ERRStatistics_REC
Diagnostics Object Types
Object 0437h: DIA_NMTTelegrCount_TYPE
Object 0438h: DIA_ERRStatistics_TYPE
RoutingRouting Type 1
Core Tasks of a POWERLINK Router
Reference Model
Data Link Layer
DLL POWERLINK Interface
DLL interface to the external network
Network Layer
Communication between POWERLINK and the external network
IP Coupling
IP Routing
Configuration
SNMP
SDO
Network Address Translation (NAT)
Configuration
SNMP
SDO
Security
Packet Filter – Firewall
ACL – Filter Entries
Filter strategy
Configuration
SNMP
SDO
Additional Services of a POWERLINK Router
Object description
Object 1E80h: RT1_EplRouter_REC
Object 1E90h .. 1ECFh: RT1_IpRoutingTable_XXh_REC
Object 1D00h .. 1DFFh: RT1_NatTable_XXh_REC
Object 1E81h: RT1_SecurityGroup_REC
Object 1B00h .. 1BFFh: RT1_AclFwdTable_XXh_REC
Object 1ED0h .. 1EDFh: RT1_AclInTable_Xh_REC
Object 1EE0h .. 1EEFh: RT1_AclOutTable_Xh_REC
Router Type I Object Types

280
281
282
284
285
286
287
288
289
290
291
291
291
292
292
293
293
293
293
294
294
294
294
295
295
295
295
296
296
296
297
298
298
300
300
300
302
303
303
304
305
305
305
306
306
307
307
307
307
307
307
308
308
308
308
310
310
310
310
311
312
312
312
312
312
312
313
313
313
315
317
317
320
322
325

EPSG DS 301 V1.5.1
9.1.7.8.1
9.1.7.8.2
9.1.7.8.3
9.1.7.8.4
9.1.7.8.5
9.1.8
9.2
10
10.1
10.2
10.3
App. 1
App. 1.1
App. 1.2
App. 2
App. 3
App. 3.1
App. 3.2
App. 3.3
App. 3.4
App. 3.5
App. 3.6
App. 3.7
App. 3.8
App. 3.9
App. 3.10
App. 4-14-

Object 0430h: RT1_EplRouter_TYPE
Object 0431h: RT1_IpRoutingTable_TYPE
Object 0432h: RT1_NatTable_TYPE
Object 0433h: RT1_SecurityGroup_TYPE
Object 0434h: RT1_AclTable_TYPE
POWERLINK Router MIB
Routing Type 2
Indicators
Indicator states and flash rates
Indicator Signaling
Recommended labelling
Summary Object Library (normative)
Object Dictionary Entries, sorted by index
Object Dictionary Entries, sorted by name
Device Description Entries (normative)
Constant Value Assignments (normative)
POWERLINK Message Type Ids
AsyncSend Request Priorities
ASnd ServiceIDs
SoA RequestedServiceIDs
Object Dictionary Object Types
NMT States
NMT Commands
General Purpose Constants
Error Code Constants
SDO Abort Codes
Data Sheet Requirements (normative)

325
325
325
325
325
326
326
327
327
328
329
330
330
336
341
345
345
345
345
346
346
346
347
348
349
351
352

EPSG DS 301 V1.5.1

Pre. 5-15-

TablesObject dictionary structure
31
Pin assignment RJ45 port
36
Pin assignment IP67 port
37
POWERLINK cycle timing parameters
54
POWERLINK cycle timing verification: Error codes and handling
57
Transitions for CN cycle state machine, states NMT_GS_INITIALISATION, NMT_CS_NOT_ACTIVE,
NMT_CS_PRE_OPERATIONAL_1, NMT_CS_BASIC_ETHERNET
60
Transitions for CN cycle state machine, states NMT_CS_OPERATIONAL, NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE
62
Transitions for MN cycle state machine, state NMT_MS_PRE_OPERATIONAL_1
65
Transitions for MN cycle state machine, states NMT_MS_OPERATIONAL, NMT_MS_READY_TO_OPERATE
and NMT_MS_PRE_OPERATIONAL_2
67
Assigned multicast addresses
69
POWERLINK Node ID assignment
70
Ethernet POWERLINK frame structure
71
Ethernet POWERLINK frame fields
71
POWERLINK message types
71
SoC frame structure
72
SoC frame data fields
72
PReq frame structure73
PReq frame data fields
73
PRes frame structure74
PRes frame data fields
74
SoA frame structure
75
SoA frame data fields
75
Definition of the RequestedServiceID in the SoA frame
76
ASnd frame structure
76
ASnd frame data fields
76
ServiceID values in the ASnd frame77
CN error handling table78
MN error handling table
79
IP parameters of a POWERLINK node
112
POWERLINK compliant UDP/IP frame structure
117
Transfer syntax for bit sequences
120
Transfer syntax for data type UNSIGNEDn
121
Transfer syntax for data type INTEGERn
122
Transfer syntax of data type REAL32
122
MAC address encoding, example 00-0A-86-xx-xx-xx shows a Lenze device
123
IP address encoding, example shows the IP address of a POWERLINK MN 192.168.100.240
123
Object type definitions
126
Access attributes for data objects
127
PDO mapping attributes for data objects
127
Static data type object definition example
127
Complex data type object definition example
128
NumberOfEntries sub-index description example
128
Record type object sub-index description example
128
Array type object sub-index description example
129
Structure of sub-index FFh
129
Complex data type description example
130
SDO via UDP/IP
132
SDO via UDP/IP field interpretation
132
UDP header
133
SDO via POWERLINK ASnd
134
SDO via ASnd field interpretation
134
POWERLINK sequence layer in asynchronous data frame
134
Fields of POWERLINK sequence layer in asynchronous data frame
135
POWERLINK command layer
141
POWERLINK command layer field interpretation
142
Abort transfer frame
145
Abort transfer frame field interpretation
145
Command services and command ID
146
Command: Write by Index request
147
Write by Index request field interpretation
147
Command: Read by Index Request
147
Read by Index request field interpretation
147
Command: Write All by Index request
147
Write All by Index request field interpretation
148
Command: Read All by Index Request
148
Read All by Index request field interpretation
148
Command: Write by Name request
148
Write by Name request field interpretation
148
Command: Read by Name request
149

EPSG DS 301 V1.5.1-16-

Read by Name request field interpretation
149
Command: File Write request
150
File Write request field interpretation
150
Command: File Read request
150
File Read request field interpretation
150
Command: Write Multiple Parameter by Index Request
151
Write Multiple Parameter by Index request field interpretation
151
Command: Write Multiple Parameter by Index Response
151
Write Multiple Parameter by Index response field interpretation
152
Command: Read Multiple Parameter by Index request
152
Read Multiple Parameter by Index request field interpretation
152
Command: Read Multiple Parameter by Index response
153
Read Multiple Parameter by Index response field interpretation
153
Command: Maximum Segment Size
154
Maximum Segment Size field interpretation
154
SDO embedded in PDO
154
SDO embedded in PDO field interpretation
155
POWERLINK sequence layer for embedding of SDO in cyclic data
155
Fields of POWERLINK sequence layer for embedding of SDO in cyclic data
156
Command: Write by Index Request via PDO
161
Command: Read by Index Request via PDO
162
Structure of PDO Mapping version
167
Structure of PDO Mapping Entry
172
Internal bit mapping of PDO mapping entry
172
Format of one entry
177
Description of one entry
177
Format of the field entry type
177
Error signaling bits
178
Static error bit field
181
Abbreviations for the following examples
182
PDL_ProgCtrl_AU8 sub-index value interpretation
187
Device description file and device configuration storage formats
194
Concise DCF stream format
196
CNConfigurationRequest write access signature
198
Structure of SelectedRange_U32
202
Common initialisation NMT state transitions
206
MN specific state transitions
210
CN specific state transitions
214
States and communication objects
215
NMT_DeviceType_U32 value interpretation
216
Structure of Revision number
218
NMT_FeatureFlags_U32 interpretation
220
NMT_EPLVersion_U8 encoding
220
NMT_StoreParam_REC storage write access signature
221
NMT_StoreParam_REC storage read access structure222
NMT_StoreParam_REC structure of read access222
NMT_RestoreDefParam_REC restoring write access signature223
NMT_RestoreDefParam_REC restoring default values read access structure224
NMT_RestoreDefParam_REC structure of restore read access224
NMT_NodeAssignment_AU32 interpretation
231
HeartbeatDescription value interpretation
236
NMT_StartUp_U32 interpretation
238
Implicit NMT state commands
255
NMT state command service, NMT managing command service and NMT info service structure of the NMT
Service Slot field
256
NMT Service Slot fields of explicit NMT state command services
256
Plain NMT state commands
257
Extended NMT state commands
258
POWERLINK node list: Node ID to bit assignment
259
NMT Service Slot fields of NMT managing command services
260
NMT managing command services
260
NMTCommandData structure of NMTNetHostNameSet
260
NMTCommandData data fields of NMTNetHostNameSet
260
NMTFlushArpEntry ASnd service slot structure
261
NMTCommandData data fields of NMTFlushArpEntry
261
NMT Service Slot structure of IdentResponse
263
NMT Service Slot data fields of IdentResponse
265
NMT Service Slot structure of StatusResponse
265
NMT Service Slot data fields of StatusResponse
266
NMT Service Slot data fields of NMT managing info services
266
NMT info services
267
NMTCommandData structure of NMTPublishNodeStates
268
NMTCommandData data fields of NMTPublishNodeStates
268
NMTCommandData structure of NMTPublishTime
269
NMTCommandData data fields of NMTPublishTime
269
NMT Service Slot structure of NMTRequest270

EPSG DS 301 V1.5.1-17-

NMT Service Slot data fields of an NMTRequest frame

270

EPSG DS 301 V1.5.1

Pre. 6
Fig. 1.
Fig. 2.
Fig. 3.
Fig. 4.
Fig. 5.
Fig. 6.
Fig. 7.
Fig. 8.
Fig. 9.
Fig. 10.
Fig. 11.
Fig. 12.
Fig. 13.
Fig. 14.
Fig. 15.
Fig. 16.
Fig. 17.
Fig. 18.
Fig. 19.
Fig. 20.
Fig. 21.
Fig. 22.
Fig. 23.
Fig. 24.
Fig. 25.
Fig. 26.
Fig. 27.
Fig. 28.
Fig. 29.
Fig. 30.
Fig. 31.
Fig. 32.
Fig. 33.
Fig. 34.
Fig. 35.
Fig. 36.
Fig. 37.
Fig. 38.
Fig. 39.
Fig. 40.
Fig. 41.
Fig. 42.
Fig. 43.
Fig. 44.
Fig. 45.
Fig. 46.
Fig. 47.
Fig. 48.
Fig. 49.
Fig. 50.
Fig. 51.
Fig. 52.
Fig. 53.
Fig. 54.
Fig. 55.
Fig. 56.
Fig. 57.
Fig. 58.
Fig. 59.
Fig. 60.
Fig. 61.
Fig. 62.
Fig. 63.
Fig. 64.
Fig. 65.
Fig. 66.
Fig. 67.
Fig. 68.

-18-

Figures
Slot Communication Network Management (SCNM)
Integration POWERLINK based machines into the IT infrastructure of end customer
Typical centralized and decentralized controller structures
Reference modelService types
Device model
Unconfirmed master slave communication
Confirmed master slave communication
Client/Server communication
Push model
Pull modelStar topology and line topology
RJ45 pin assignment (left: connector, right: port)
IP67 port pin assignment.
recommended RJ45 to RJ45 pin assignment
not recommended RJ45 to RJ45 pin assignment
M12 to M12 pin assignment
M12 to RJ45 pin assignment
POWERLINK Cycle
POWERLINK - an isochronous process
Multiplexed POWERLINK cycle
Asynchronous scheduling
Asynchronous transmit priority handling (Priority level PR: 7 = PRIO_NMT_REQUEST, 3 =PRIO_GENERIC_REQUEST)
Reduced POWERLINK cycle
POWERLINK cycle timing, start phase and isochronous phase
POWERLINK cycle timing, asynchronous phase, AsyncSend transmission by CN
POWERLINK cycle timing, asynchronous phase, AsyncSend transmission by MN
Multiple slot assignment
CN cycle state machine, states NMT_GS_INITIALISATION, NMT_CS_NOT_ACTIVE,
NMT_CS_PRE_OPERATIONAL_1, NMT_CS_BASIC_ETHERNET
CN cycle state machine (DLL_CS), valid for NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, NMT_CS states NMT_CS_OPERATIONAL
MN cycle state machine, state NMT_MS_PRE_OPERATIONAL_1
MN cycle state machine, States NMT_MS_OPERATIONAL, NMT_MS_READY_TO_OPERATE and
NMT_MS_PRE_OPERATIONAL_2
Error registration
Threshold counter
Timeouts
Timing violation
Cycle time exceeded
Construction of the IPv4 address
POWERLINK frame structure
POWERLINK compliant UDP/IP frame structure
Legacy Ethernet frame structure
SDO layer model
POWERLINK SDO embedded in UDP/IP frame
UDP socket
Initialisation of a asynchronous connection
Closing of asynchronous connection
Normal asynchronous communication
Delayed asynchronous communication
Asynchronous communication when history buffer gets fullError loss of asynchronous frame
Error loss of asynchronous acknowledge
Error duplication of asynchronous frame
Error asynchronous communication broken
Error flooding with asynchronous commands
Information structure of POWERLINK command layer
Definition of segment size
POWERLINK command layer: Typical download transfer
POWERLINK command layer: Typical upload transfer
Abort transfer
Initialisation of embedded connection
Closing of connection
Normal embedded communication
Error embedded request lostError embedded response lost
Embedded segmented download
Embedded segmented upload
Error signaling – Reference model
Error signaling – Overview

25
27
27
28
29
30
32
33
33
33
34
35
36
37
37
37
37
38
41
41
42
44
46
47
48
49
49
58
60
61
65
66
80
81
84
85
87
112
118
118
118
131
132
133
135
135
136
137
137
138
138
139
140
140
141
142
143
144
145
156
157
158
159
160
160
161
176
176

EPSG DS 301 V1.5.1
Fig. 69.
Fig. 70.
Fig. 71.
Fig. 72.
Fig. 73.
Fig. 74.
Fig. 75.
Fig. 76.
Fig. 77.
Fig. 78.
Fig. 79.
Fig. 80.
Fig. 81.
Fig. 82.
Fig. 83.
Fig. 84.
Fig. 85.
Fig. 86.
Fig. 87.
Fig. 88.
Fig. 89.
Fig. 90.
Fig. 91.
Fig. 92.
Fig. 93.
Fig. 94.
Fig. 95.
Fig. 96.
Fig. 97.
Fig. 98.
Fig. 99.
Fig. 100.
Fig. 101.
Fig. 102.
Fig. 103.
Fig. 104.
Fig. 105.
Fig. 106.
Fig. 107.
Fig. 108.
Fig. 109.
Fig. 110.
Fig. 111.
Fig. 112.
Fig. 113.
Fig. 114.

-19-

Error signaling initialisation
Error signaling with Preq and Pres
Error signaling for Async-only CNs and CNs in state NMT_CS_PRE_OPERATIONAL_1
Common initialisation NMT state machine
NMT state diagram of an MNState diagram of a CN
NMT_RestoreDefParam_REC restore procedure
POWERLINK communication slots
Implicit NMT state command service protocol
Explicit NMT state command service protocol
NMT managing command service protocol
NMT state response service protocol (isochronous CN)
NMT state response service protocol (async-only CN)
IdentResponse service protocol
StatusResponse service protocol
NMT info service protocol
State NMT_MS_NOT_ACTIVE
Detail state NMT_MS_PRE_OPERATIONAL_1
Detail state NMT_MS_PRE_OPERATIONAL_2
Detail state NMT_MS_READY_TO_OPERATE
Detail state NMT_MS_OPERATIONAL
Overview of the boot process in NMT super-state NMT_MS
Network boot process dependencies to the NMT_MS for optional and mandatory CNs
Sub-state BOOT_STEP1
Sub-state CHECK_IDENTIFICATION[Node ID]
Sub-state CHECK_SOFTWARE[Node ID]
Sub-state CHECK_CONFIGURATION[Node ID]
Sub-state GET_IDENT[Node ID]
Sub-state BOOT_STEP2[Node ID]
Sub-state CHECK_COMMUNICATION[Node ID]
Sub-state START_CN[Node ID]
Sub-state START_ALL
Sub-state CHECK_STATE
Sub-state CHANGE_NMT_STATE
Sub-state ERROR_TREATMENT
Minimal NMT boot-up process
Boot procedure example for a single CN
POWERLINK router, black box model
Possible communication relations via a POWERLINK router
POWERLINK router reference model
Symmetrical n-to-n NAT
NAT architecture
Integration of NAT in the POWERLINK router
Filter tables of the packet filter
POWERLINK router type 2
ERROR LED state machine

179
180
181
204
207
211
224
247
255
256
260
261
262
262
265
266
272
274
275
276
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
297
298
305
306
306
309
309
310
311
326
328

EPSG DS 301 V1.5.1-20-Pre. 7

Definitions and Abbreviations

Pre 7.1

Definitions

AgeingApplication Process
Async-only CN

Asynchronous Data

Asynchronous Period
Asynchronous Scheduling
Basic Ethernet Mode
CANopenContinuous
Controlled Node (CN)Cycle State Machine

Cycle Time

Deterministic Communication

Device Configuration File
Device Description File
Destination NAT (D-NAT)
DomainEthernet POWERLINK (EPL)

Ageing is a common mechanism to maintain (cache) tables. Entries
which are not used or refreshed are removed after a specified time.
The Application Process is the task on the Application Layer
An Async-only CN is operated in a way, that it isn’t accessed cyclicallyin the isochronous slot by the MN. It is polled during the asynchronous
period by a StatusRequest message.
Data in a POWERLINK network which is not time critical. Within the
POWERLINK cycle there is a specific period reserved for
Asynchronous Data which is shared by all nodes. Each node connectedto the network can send asynchronous data by requesting it to theManaging Node. The Managing Node keeps a list of all asynchronous
data requests and will subsequently grant the network access to one
node after the other.
The Asynchronous Period is the second part of the POWERLINK cycle,
starting with a Start of Asynchronous (SoA) frame.
The MN’s asynchronous scheduler decides when a requested
asynchronous data transfer will happen.
Basic Ethernet Mode provides the Legacy Ethernet communication.
CANopen is a network technology optimized for the usage in industrial
control environments, in machine internal networks and in embedded
systems (any control unit deeply "embedded" in a device withelectronics). The lower-layer implementation of CANopen is based
upon CAN (Controller Area Network).
Continuous is a POWERLINK communication class where isochronous
communication takes place every cycle (the opposite to multiplexed).
Node in a POWERLINK network without the abilty to manage the
SCNM mechanism.
The Cycle State Machine controls the POWERLINK cycle on the Data
Link Layer and is itself controlled by the NMT state machine defining
the current operating mode.
The time between two consecutive Start of Cycle (SoC) frames – i.e.
repeating – process. The Cycle Time includes the time for datatransmission and some idle time before the beginning of the next cycle.
Describes a communication process whose timing behaviour can bepredicted exactly. I.e. the time when a message reaches the recipient ispredictable.
The configuration parameters of a specific device are stored in the
Device Configuration File (XDC).
All device dependent information is stored in the Device Description File
(XDD) of each device.
D-NAT (Destination- Network Address Translation) changes thedestination address of the IP / ICMP packet.
In the context of CANopen: A Domain is a data object of arbitrary typeand length which can be transferred over a POWERLINK network.
In the context of internet protocols: A Domain is a part of the internet
name space which is supported by the Domain Name System (DNS).
An extension to Legacy Ethernet on layer 2, to exchange data under
hard real-time constraints. It was developed for deterministic dataexchange, short cycle time and isochronous operation in industrial
automation.

EPSG DS 301 V1.5.1
IdentRequest
IdentResponse
Idle Period
IEEE 1588
Isochronous

Isochronous Data
Isochronous Period

Legacy Ethernet
Managing Node (MN)Media Access Control (MAC)

Multiplexed

Multiplexed CN
Multiplexed Timeslot
NetTime
Network Management (NMT)NMT State Machine
Object Directory
PollRequest

PollResponse

POWERLINK Command
Layer

POWERLINK Cycle

POWERLINK Mode
POWERLINK Node ID-21-

IdentRequests are POWERLINK frames sent by the MN in order to
identify active CNs waiting to be included into the network.
The IdentResponse is a special form of an ASnd frame in response to
an IdentRequest.
The Idle Period is time interval remaining between the completed
asynchronous period and the beginning of the next cycle.
This standard defines a protocol enabling synchronisation of clocks in
distributed networked devices (e.g. connected via Ethernet).
Pertains to processes that require timing coordination to be successful.
Isochronous data transfer ensures that data flows continously and at a
steady rate in close timing with the ability of connected devices.
Data in a POWERLINK network which is to be transmitted every cycle(or every nth cycle in case of multiplexed isochronous data).
The Isochronous Period of a POWERLINK cycle offers deterministic
operation, i.e. it is reserved for the exchange of (continuous or
multiplexed) isochronous data.
Ethernet as standardised in IEEE 802.3 (non-deterministic operation in
non-time-critical environments).
A node capable to manage the SCNM mechanism in a POWERLINK
network.
One of the sub-layers of the Data Link Layer in the POWERLINK
reference model that controls who gets access to the medium to send amessage.
Multiplexed is a POWERLINK communication class where cyclic
communication takes place in such a way that m nodes are served in s
cycles (the opposite to continuous).
A node which is allowed to send isochronous data every nth cycle.
A slot destined to carry multiplexed isochronous data, i.e. the timeslot isshared among multiple nodes.
The MN’s clock time is distributed to all CNs within the SoC frame.
Network Management functions and services in the POWERLINK
model. It performs initialisation, configuration and error handling in a
POWERLINK network.
The state machine controlling the overall operating mode and status ofa POWERLINK node.
The repository of all data objects accessible over POWERLINK
communications.
A PollRequest is a frame, which is used in the isochronous part of thecyclic communication. The MN request with this frame the CN to send
its data.
A PollResponse is a frame, which is used in the isochronous part of thecyclic communication. The CN responses with this frame to a
PollRequest frame from an MN.
The POWERLINK Command Layer defines commands to accessparameters of the object dictionary. This layer is on top of theSequence Layer and distinguishes between an expedited and asegmented transfer.
Data exchange within a POWERLINK network is structured in fix
intervals, called cycles. The cycle is subdivided into the isochronousand the asynchronous period and is organized by the MN.
The POWERLINK Mode includes all NMT states in which POWERLINK
cycles are run.
Each POWERLINK node (MN, CN and Router) is addressed by an 8 bit
POWERLINK Node ID on the POWERLINK layer. This ID has only local
significance (i.e. it is unique within a POWERLINK segment).

EPSG DS 301 V1.5.1-22-

Precision Time Protocol (PTP) IEEE 1588, Standard for a Precision Clock Synchronisation Protocol for
Networked Measurement and Control Systems
Process Data Object (PDO)
Object for isochronous data exchange between POWERLINK nodes.
Reserved
Reserved bits shall be set 0 by the sender. The receiver shall notinterpret such bits. It is not allowed to use reserved bits.
Their use is reserved for further development or by extensions of thisspecification.
Router Type 1
A Type 1 POWERLINK Router is a coupling element in a network thatallows IP communication between a POWERLINK segment and anyother datalink layer protocol carrying IP e.g. legacy Ethernet,
POWERLINK etc. It is usually a separate network element acting asControlled Node within the POWERLINK segment.
Router Type 2
A Type 2 POWERLINK Router is a router between a POWERLINK
segment and a CANopen network.
Service Data Object (SDO)
Peer to peer communication with access to the object dictionary of adevice.
Sequence Layer
The POWERLINK Sequence Layer provides the service of a reliablebidirectional connection that guarantees that no messages are lost or
duplicated and that all messages arrive in the correct order.
Slot Communication Network In a POWERLINK network, the managing node allocates data transfer
Management (SCNM)
time for data from each node in a cyclic manner within a guaranteed
cycle time. Within each cycle there are slots for Isochronous Data, as
well as for Asynchronous Data for ad-hoc communication. The SCNM
mechanism ensures that there are no collisions during physical network
access of any of the networked nodes thus providing deterministic
communication via Legacy Ethernet.
Source NAT (S-NAT)
S-NAT (Source - Network Address Translation) changes the source
address of the IP / ICMP packet.
StatusRequest
A StatusRequest frame is a special SoA frame used to poll the status ofa node.
StatusResponse
A StatusResponse frame is transmitted by a CN upon assignment of
the asynchronous slot via the StatusRequest in the SoA frame.

Pre 7.2
ACL
ARP
ASnd
CAN
CiA
CN
DCF
EIA
EMC
EPL
EPSG
ICMP
ID
IEC
IEEE
IP
MAC
MIB

Abbreviations
Access Control List
Address Resolution Protocol
Asynchronous Send (POWERLINK frame type)
Controller Area Network
CAN in Automation
POWERLINK Controlled Node
Device Configuration File
Electronic Industries Association
Electro Magnetic Compatibility
Ethernet POWERLINK
Ethernet POWERLINK Standardisation GroupInternet Control Message Protocol
Identifier
International Electrotechnical Comission
Institute of Electrical and Electronic Engineers
Internet Protocol
Media Access Control
Management Information BaseEPSG DS 301 V1.5.1
MN
MS
MSS
MTU
NAT
NIL
NMT
PDO
PR
PReq
PRes
PS
PTP
RD
RFC
RPDO
RS
EA
SCNM
SDO
EN
SNMP
SoA
SoC
TCP
TIA
TPDO
TTL
UDP
VPN
XDC
XDD

-23-

POWERLINK Managing NodeMultiplexed Slot (flag in POWERLINK frame)
Maximum Segment Size
Maximum Transmission Unit
Network Address Translation
Not in List (Basic Data Type)
Network Management
Process Data Object
Priority (bit field in POWERLINK frame)
PollRequest (POWERLINK frame type)
PollResponse (POWERLINK frame type)
Prescaled Slot (flag in POWERLINK frame)
Precision Time Protocol
Ready (flag in POWERLINK frame)
Requests for Comments
Receive Process Data Object
Request to Send (flag in POWERLINK frame)
Exception Achnowledge (flag in POWERLINK frame)
Slot Communication Network Management
Service Data Object
Exception New (flag in POWERLINK frame)
Simple Network Management Protocol
Start of Asynchronous (POWERLINK frame type)Start of Cycle (POWERLINK frame type)Transmission Control Protocol
Telecommunications Industry Association
Transmit Process Data Object
Time to live
User Datagram Protocol
Virtual Private Network
XML device configuration fileXML device description fileEPSG DS 301 V1.5.1

Pre. 8
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]

-24-

References

EPSG Draft Standard 302-A (EPSG DS 302-A), Ethernet POWERLINK, Part A: High
Availability
EPSG Draft Standard 302-B (EPSG DS 302-B), Ethernet POWERLINK, Part B: Multiple-ASnd
EPSG Draft Standard 302-C (EPSG DS 302-C), Ethernet POWERLINK, Part C: PollResponse
Chaining
EPSG Draft Standard 302-D (EPSG WDP 302-D), Ethernet POWERLINK, Part D: Multiple
PReq/PResEPSG Draft Standard 302-E (EPSG WDP 302-E), Ethernet POWERLINK, Part E: Dynamic
Node Allocation
EPSG Draft Standard 302-F (EPSG WDP 302-F), Ethernet POWERLINK, Part F: Modular
DeviceIEC 61918 Industrial communication networks – Installation of communication networks inindustrial premises
IEC 61784-5-13 Industrial communication networks – Profiles – Part 5-13: Installation offieldbuses – Installation profiles for CPF 13

EPSG DS 301 V1.5.1-25-

Introduction

1

Ethernet POWERLINK is a communication profile for Real-Time Ethernet (RTE). It extends Ethernet
according to the IEEE 802.3 standard with mechanisms to transfer data with predictable timing andprecise synchronisation. The communication profile meets timing demands typical for highperformance automation and motion applications. It does not change basic principles of the Fast
Ethernet Standard IEEE 802.3 but extends it towards RTE. Thus it is possible to leverage andcontinue to use any standard Ethernet silicon, infrastructure component or test and measurement
equipment like a network analyzer.

1.1

Slot Communication Network Management

POWERLINK provides mechanisms to achieve the following:
1.
Transmit time-critical data in precise isochronous cycles. Data exchange is based on a
publish/subscribe relationship. Isochronous data communication can be used for exchanging
position data of motion applications of the automation industry.
2.
Synchronise networked nodes with high accuracy.
3.
Transmit less time-critical data asynchronously on request. Asynchronous data communication
can be used to transfer IP-based protocols like TCP or UDP and higher layer protocols such as
HTTP, FTP,…
POWERLINK manages the network traffic in a way that there are dedicated time-slots for isochronousand asynchronous data. It takes care that always only one networked device gains access to the
network media. Thus transmission of isochronous and asynchronous data will never interfere andprecise communication timing is guaranteed. The mechanism is called Slot Communication Network
Management (SCNM). SCNM is managed by one particular networked device – the Managing Node
(MN) – which includes the MN functionality. All other nodes are called Controlled Nodes (CN).

Fig. 1.

Slot Communication Network Management (SCNM)

1.2

POWERLINK key features

POWERLINK provides the following key features:•

Ease-of-Use to be handled by typical automation engineers without indepth Ethernet network
knowledge.

•

Up to 240 networked real-time devices in one network segment•

Deterministic Communication Guaranteed••

Down to 100 µs cycle times•

Ultra-low jitter (down to <1µs) for precise synchronisation of networked devices

Standard Compliant

EPSG DS 301 V1.5.1

-26-

•

IEEE 802.3u Fast Ethernet•

IP based protocols supported (TCP, UDP,...)•

Integration with CANopen Profiles EN 50325-4 for device interoperability•

Implementation based on standard Ethernet Chips - No special ASICs necessary•

Direct peer-to-peer communication of all Nodes (Publish/subscribe)•

Hot Plugging•
Seamless IT-Integration – Routing of IP protocols
POWERLINK is based on the ISO/OSI layer model and supports Client/Server and Producer/
Consumer communications relationships.
The Ethernet POWERLINK Standardisation Group (EPSG) worked closely with the CiA (CAN in
Automation) organisation to integrate CANopen with POWERLINK. CANopen standards define widely
deployed communication profiles, device profiles and application profiles. These profiles are in use
millions of times all over the world. Integration of POWERLINK with CANopen combines profiles, highperformance data exchange and open transparent communication with TCP/UDP/IP protocols.
The POWERLINK communication profile is based on CANopen communication profiles DS301 andDS302. Based on this communication profile, the multitude of CANopen device profiles can be used in
a POWERLINK environment without changes.
A main focus of POWERLINK is ease of use. Ethernet technology can be quite complex and confusing
for machine and plant manufacturers which are not necessarily networking experts. The following
features have been implemented:•

Easy wiring, flexible topologies (line structures, tree structures or star structures). The network
is adapting to the needs of the machine.

•

Utilization of well known industrial infrastructure components•

Simple address assignment by switch is possible•

Easy replacement of devices in case of failure•

Straightforward network diagnostics•

Basic security features•

Simple engineering separated from end user IT infrastructure•

Easy integration of RTE network with IT infrastructure

1.3

Integration

The advantages listed before result from protecting the POWERLINK RTE network segment from
regular office and factory networks. This matches typical machine and plant concepts. Hard real timerequirements are met within the machine with POWERLINK. Full transparency to the factory network
and above is provided, yet it is taken care of protection against hacker attacks on machine level.
Modification efforts through machine integration into existing IT infrastructures are minimized. To
achieve this POWERLINK provides a private Class-C IP segment solution with fixed IP addresses. A
router establishes the connection to factory floor networks or company networks. NAT mechanisms
allow the assignment of any IP address to RTE networked nodes.
RTE based on POWERLINK is ideal to support modern modular machine concepts.
Producer/Consumer and Client/Server communication relationships, enable centralized master/slave
as well as decentral multimaster structures.

EPSG DS 301 V1.5.1-27-

Factory Floor Network and Company Network

LegacyEthernet

LegacyEthernet

MachineEthernet POWERLINK(Protected Ethernet)

IP Address Translation
IP-Telegram Managing
Basic Security

Router

MN

MachineEthernet POWERLINK(Protected Ethernet)

Router

CN

CN

CN

CN

Ethernet HUB

Ethernet HUB

MachineFig. 2.

CN

Ethernet(POWERLINK + TCP/UDP/IP)

Ethernet(POWERLINK + TCP/UDP/IP)

CN

MN

MachineIntegration POWERLINK based machines into the IT infrastructure of end customer

1.4

Modular Machines

MN(PLC, IPC,
IDrive, HMI,…)CN(IO, …)

CN(PLC, IPC,
IDrive, …)

CN(Drive,…)CN(Drive, …)

CN(IO, Drive,...)

CN(IO, …)Machine Module

Machine Module

Machine Module

logical communication
Ethernet HUB

Fig. 3.

Typical centralized and decentralized controller structures

A machine concept with autonomous machine modules is illustrated in Fig. 3. Every machine module
can be designed separetly whith its own internal communication relationships. The assembling of themachine can be done in a flexible way by adding additional direct communication relationships
between machine modules.

EPSG DS 301 V1.5.1-28-

Modelling

2

POWERLINK-based networks use the following reference model, device model, and communication
model.

2.1

Reference Model
DeviceDeviceDeviceProfileProfileProfileNMT

Configuration
Manager

POWERLINK Application Layer

HTTP
FTP

Object Dictionary
PDO

Application

SDO Command

Session /Present.

SDO Sequence
Transport
UDP

TCP
IP

Network

POWERLINK Data Link Layer
Data Link

MAC
PHY

Fig. 4.

Physical

Reference model

The communication concept can be described with reference to the ISO-OSI Reference Model (righthand side of Fig. 4).

2.1.1

Application Layer

The Application Layer comprises a concept to configure and communicate real-time-data as well as
the mechanisms for synchronisation between devices. The functionality the application layer offers toan application is logically divided over different service objects (see SDO) in the application layer. A
service object offers a specific functionality and all related services.
Applications interact by invoking services of a service object in the application layer. To realize these
services, the service object exchanges data via the Network with (a) peer service object(s) via a
protocol. This protocol is described in the Protocol Specification of that service object.

2.1.1.1

Service Primitives

Service primitives are the means by which the application and the application layer interact. There are
four different primitives:•a request is issued by the application to the application layer to request a service•

an indication is issued by the application layer to the application to report an internal event
detected by the application layer or indicate that a service is requested

EPSG DS 301 V1.5.1

-29-

•

a response is issued by the application to the application layer to respond to a previous
received indication•a confirmation is issued by the application layer to the application to report the result of apreviously issued request.

2.1.1.2

Application Layer Service Types

Application X

Application X

requestindication

Local Service

Application X

Provider Initiated Service

Application Y, Z, ..
indication

requestApplication X

Application Y

requestindication

confirmation

response

indication
indication

Unconfirmed Service
Fig. 5.

Confirmed Service

Service types

A service type defines the primitives that are exchanged between the application layer and the cooperating applications for a particular service of a service object.
•

A Local Service involves only the local service object. The application issues a request to its
local service object that executes the requested service without communicating with (a) peer
service object(s).

•An Unconfirmed Service involves one or more peer service objects. The application issues arequest to its local service object. This request is transferred to the peer service object(s) thateach pass it to their application as an indication. The result is not confirmed back.

•

A Confirmed Service can involve only one peer service object. The application issues a request
to its local service object. This request is transferred to the peer service object that passes it tothe other application as an indication. The other application issues a response that istransferred to the originating service object that passes it as a confirmation to the requesting
application.

•

A Provider Initiated service involves only the local service object. The service object (being theservice provider) detects an event not solicited by a requested service. This event is thenindicated to the application.
Unconfirmed and confirmed services are collectively called Remote Services.

2.2

Device Model

2.2.1

GeneralA device is structured as follows (see Fig. 6):•

Communication – This function unit provides the communication objects and the appropriate
functionality to transport data items via the underlying network structure.

EPSG DS 301 V1.5.1•-30-

Object Dictionary – The Object Dictionary is a collection of all the data items that have an
influence on the behaviour of the application objects, the communication objects and the statemachine used on this device.

•

Application – The application comprises the functionality of the device with respect to theinteraction with the process environment.
Thus the Object Dictionary serves as an interface between the communication and the application.
The complete description of a device’s application with respect to the data items in the Object
Dictionary is called the device profile.

Communication

ObjectDictionary

State machine

Application

Application
objectEntry 1Comm.
objectEntry 2Comm.
object:Comm.
objectApplication
objectApplication
objectEntry nComm.
objectBus system
Fig. 6.

2.2.2

Application
objectProcess

Device model

The Object Dictionary

The most important part of a device profile is the Object Dictionary. The Object Dictionary isessentially a grouping of objects accessible via the network in an ordered, pre-defined fashion. Eachobject within the dictionary is addressed using a 16-bit index.
The overall layout of the standard Object Dictionary is shown by Tab. 1. This layout closely conforms
to other industrial serial bus system concepts.
The Object Dictionary may contain a maximum of 65536 entries which are addressed through a 16-bit
index.
The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types
like BOOLEAN, INTEGER, floating point, string, etc. These entries are included for reference only;
they cannot be read or written.

EPSG DS 301 V1.5.1

-31-

Index

Object0000h
0001h .. 001Fh
0020h .. 003Fh
0040h .. 005Fh
0060h .. 007Fh
0080h .. 009Fh
00A0h .. 03FFh
0400h – 041Fh
0420h – 04FFh
0500h .. 0FFFh
1000h .. 1FFFh
2000h .. 5FFFh
6000h .. 9FFFh
A000h .. BFFFh
C000h .. FFFFh

not used
Static Data Types
Complex Data Types
Manufacturer Specific Complex Data Types
Device Profile Specific Static Data Types
Device Profile Specific Complex Data Types
Reserved for further use
POWERLINK Specific Static Data Types
POWERLINK Specific Complex Data Types
Reserved for further use
Communication Profile Area
Manufacturer Specific Profile Area
Standardised Device Profile Area
Standardised Interface Profile Area
Reserved for further use

Object dictionary structure
Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed ofstandard data types and are common to all devices.
Manufacturer Specific Complex Data Types at indices 0040 h through 005Fh are structures composedof standard data types but are specific to a particular device.
Device Profiles may define additional data types specific to their device type. The static data types
defined by the device profile are listed at indices 0060 h - 007Fh, the complex data types at indices0080h - 009Fh.
A device may optionally provide the structure of the supported complex data types (indices 0020 h 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 provides thenumber of entries at this index, and the following sub-indices contain the data type encoded as
UNSIGNED16 according to 6.1.4.5.
POWERLINK Specific Static Data Types shall be described at indices 0400h – 041Fh. These entries
are included for reference only; they cannot be read or written. POWERLINK Specific Complex Data
Types shall be described at indices 0420h – 04FFh
The Communication Profile Area at indices 1000h through 1FFFh contains the communication specificparameters for the POWERLINK network. These entries are common to all devices.
The standardised device profile area at indices 6000h through 9FFFh contains all data objects common
to a class of devices that can be read or written via the network. The device profiles may use entries
from 6000h to 9FFFh to describe the device parameters and the device functionality. Within this range
up to 8 different devices can be described. In such a case the devices are denominated Multiple
Device Modules. Multiple Device Modules are composed of up to 8 device profile segments. In thisway it is possible to build devices with multiple functionality. The different device profile entries areindexed at increments of 800h.
For Multiple Device Modules the object range 6000h to 9FFFh is sub-divided as follows:•

6000h to 67FFh

device 0•6800h to 6FFFh

device 1•

7000h to 77FFh

device 2•7800h to 7FFFh

device 3•

8000h to 87FFh

device 4•8800h to 8FFFh

device 5•9000h to 97FFh

device 6•9800h to 9FFFh

device 7

EPSG DS 301 V1.5.1-32-

The Object Dictionary concept caters for optional device features: a manufacturer does not have toprovide certain extended functionality on his devices but if he wishes to do so he must do it in a predefined fashion.
Space is left in the Object Dictionary at indices 2000h through 5FFFh for truly manufacturer-specificfunctionality.

2.2.2.1

Index and Sub-Index Usage

A 16-bit index is used to address all entries within the Object Dictionary. In the case of a simple
variable the index references the value of this variable directly. In the case of records and arrays,
however, the index addresses the whole data structure.
To allow individual elements of structures of data to be accessed via the network a sub-index isdefined. For single Object Dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32 etc.
the value for the sub-index is always zero. For complex Object Dictionary entries such as arrays orrecords with multiple data fields the sub-index references fields within a data-structure pointed to by
the main index. The fields accessed by the sub-index can be of differing data types.

2.3

Communication Model

The communication model specifies the different communication objects and services and theavailable modes of frame transmission triggering.
The communication model only specifies the POWERLINK-specific communication objects of the
POWERLINK Mode and Basic Ethernet Mode (4.2 resp. 4.3). The mechanism for Legacy Ethernet
communication in Basic Ethernet mode is not within the scope of this specification.
The communication model supports the transmission of isochronous and asynchronous frames.
Isochronous frames are supported in POWERLINK Mode only, asynchronous frames in POWERLINK
Mode and Basic Ethernet Mode.
By means of isochronous frame transmission a network wide coordinated data acquisition andactuation is possible. The isochronous transmission of frames is supported by the POWERLINK Mode
cycle structure. The system is synchronised by SoC frames. Asynchronous frames may be transmitted
in the asynchronous slot of POWERLINK Mode cycle upon transmission grant by the POWERLINK
MN, or at any time in Basic Ethernet Mode.
With respect to their functionality, three types of communication relationships are distinguished•

Master/Slave relationship (Fig. 7 and Fig. 8)•

Client/Server relationship (Fig. 9)•

Producer/Consumer relationship (Fig. 10 and Fig. 11)

2.3.1

Master/Slave relationship

MasterSlavesindication

requestFig. 7.

indication

data

Unconfirmed master slave communication

indicationEPSG DS 301 V1.5.1-33-

MasterSlave

requestindication
Requestconfirmation

Fig. 8.

data

response

Confirmed master slave communication

At any time there is exactly one device in the network serving as a master for a specific functionality.
All other devices in the network are considered as slaves. The master issues a request and theaddressed slave(s) respond(s) if the protocol requires this behaviour.

2.3.2

Client/Server relationshipThis is a relationship between a single client and a single server. A client issues a request(upload/download) thus triggering the server to perform a certain task. After finishing the task theserver answers the request.

ClientServerrequestindication

request data

confirmation

response

response data

Fig. 9.

2.3.3

Client/Server communication

Producer/Consumer relationship - Push/Pullmodel

The producer/consumer relationship model involves a producer and zero or more consumer(s). The
push model is characterized by an unconfirmed service requested by the producer. The pull model ischaracterized by a confirmed service requested by the consumer.

Producer

Consumers
indication
indication

requestFig. 10.

data

Push model

indicationEPSG DS 301 V1.5.1-34-

Producer

Consumers

indication

requestRequestrequestrequestresponse

data

confirmation
indication
indication

Fig. 11.

2.3.4

Pull modelSuperimposing of Communication Relationships

POWERLINK collects more than one function into one frame (refer 4.6). It is therefore not usuallypossible to apply a single communication relationship to the complete frame, but only to particulars
services inside the frame.
The PollResponse frame for example (refer 4.6.1.1.4) transmitted by the CN includes several services:•

Transmission of the current NMT state of the CN is the response part of a confirmed
master/slave relationship triggered by the MN.

•

Request of the asynchronous slot is the request part of a client/server relationship.

•

Transmission of PDO data occurs in conformance to a push model Producer/Consumer
relationship.

EPSG DS 301 V1.5.1

3

-35-

Physical Layer

POWERLINK is a protocol residing on top of the standard IEEE 802.3 MAC layer. The physical layer
is 100BASE-X (copper and fiber, see IEEE 802.3). Half-Duplex transmission mode shall be used.
Autonegotiation is not recommended.
POWERLINK uses Ethernet as it is, without any modifications. Hence any advancement in Ethernet
Technology can be exploited (e.g. Gigabit Ethernet).

3.1

Topology

3.1.1

Hubs

To fit POWERLINK jitter requirements it is recommended to use hubs to build a POWERLINK
network. Class 2 Repeaters shall be used in this case.
Hubs have the advantage of reduced path delay value (indicated by D_PHY_HubDelay_U32) and havesmall frame jitter (indicated by D_PHY_HubJitter_U32).
Hubs may be integrated in the POWERLINK interface cards.
Hub integration shall be indicated by D_PHY_HubIntegrated_BOOL. The number of externallyaccessible POWERLINK ports provided by a device shall be indicated by D_PHY_ExtEPLPorts_U8.

3.1.2

Switches

Switches may be used to build a POWERLINK network. The additional latency and jitter of switches
has to be considered for system configuration.
It has to be considered that any POWERLINK network constructed with anything but Class 2 Repeater
Devices does not conform to the POWERLINK standard as defined in this document.

3.2

Network Guidelines.
Fig. 12.

Star topology and line topology

POWERLINK does not cause collisions. This is why the most extreme topology guideline of the IEEE
standard (5120 ns maximum round trip signal runtime) does not apply.
Due to this leniency in the topology, line structures that are required in applications in the field aremade possible. Nodes may use integrated hubs, further simplifying construction in the field. A mixed
tree and line structure is available when a large number of nodes are being used.
Fiber optic transducers may be used. However, they should be tested to establish whether they cause
more jitter and latency than normal hubs. When designing the network infrastructure some timing
constraints shall be considered. The MN uses a timeout after sending a PollRequest Frame to detect
transmission errors and node failures. The round trip latency between the MN and a CN shall not
exceed the timeout value. The timeout value can be set for every single node.

EPSG DS 301 V1.5.1

3.2.1

-36-

JitterEvery hub level introduces additional Jitter (equal or below 70 ns). Only the number of hub levels
between MN and most distanced CN is relevant. If the MN is located in the center of line or ar star
topology, the number of hub level between the most distanced CNs is irrelevant for synchronisation
jitter.

3.3

Ports and Connectors

To connect POWERLINK devices one of two types of connectors shall be used:
4.
RJ-45: for light duty environments.
5.
M12: for heavy duty environments.
Both types may be mixed on the same cable.
For further information please refer to IEC 61918 and IEC 61784-5-13.

3.3.1

RJ-45

Pin assignment as defined by EIA/TIA T568B.
The following is provided for convenience; please refer to the corresponding International Standards.

Fig. 13.

RJ45 pin assignment (left: connector, right: port)

The pictures shows an RJ45 connector on the cable and a port (on the device or Hub).
The pin assignment on each node shall be that of a hub/switch port. Therefore the port pins are
assigned as follows:
Pin
1
2
3
4

Wire color code
WHT/ORG
ORG
WHT/GRN
BLU

5

WHT/BLU

67GRN
WHT/BRN

8

BRN

Assignment 100BASE-TX
Rx+
RxTx+

Tx-

Pin assignment RJ45 port

3.3.2

M12

For IP67 requirements. 4 pin D-coded as recommended in IEC 61076-2-101.
Male side is fitted on the cable, female on the device or hub.
The following is provided for convinience; please refer to the corresponding International Standard.

EPSG DS 301 V1.5.1-37-

Port (Female)
2

1

3

4

Fig. 14.
Pin
1
2
3
4

IP67 port pin assignment.

Wire color code
BLU/YEL
YEL/WHT
WHT/ORG
ORG/BLU

Assignment 100BASE-TX
Tx+
Rx+
TxRx-

Pin assignment IP67 port

3.3.3

Crossover Pin Assignment

The pin assignment shall be that of a crossover cable.
Therefore all devices can be interconnected by one type of cable. The pin assignment of a crossovercable is defined as:•

Tx+ to Rx+•

Tx- to Rx-•

Rx+ to Tx+•

Rx- to Tx-

3.3.3.1

RJ45 to RJ45

Fig. 15.

recommended RJ45 to RJ45 pin assignment

Fig. 16.

not recommended RJ45 to RJ45 pin assignment

3.3.3.2

M12 to M12

1

1

2

2

3

3

4

4

Fig. 17.

M12 to M12 pin assignmentEPSG DS 301 V1.5.1

3.3.3.3-38-

M12 to RJ45

1
2
3

1

4

2

5

3

6

4

7
8

Fig. 18.

3.4

M12 to RJ45 pin assignment

Cables (recommendation)

Please refer to IEC 61918 and IEC 61784-5-13.
The following is provided for convenience; please refer to the corresponding International Standards.
To increase noise immunity only S/FTP or SF/FTP cables should be used (Cat5). The maximum cable
length (100 meters) predefined by Ethernet 100Base-TX shall apply.
The pin assignment shall be that of a crossover cable.
Regarding wiring and EMC measures, the IEC 61918 and IEC 61784-5-13 shall be considered.

EPSG DS 301 V1.5.1

-39-

4

Data Link Layer

4.1

Modes of Operation

Two operating modes are defined for POWERLINK networks:•

POWERLINK mode
In POWERLINK Mode network traffic follows the set of rules given in this standard for Real-time
Ethernet communication. Network access is managed by a master, the POWERLINK Managing
Node (MN). A node can only be granted the right to send data on the network via the MN. The
central access rules preclude collisions, the network is therefore deterministic in POWERLINKMode.
In POWERLINK Mode most communication transactions are via POWERLINK-specificmessages. An asynchronous slot is available for non-POWERLINK frames. UDP/IP is thepreferred data exchange mechanism in the asynchronous slot; however, it is possible to use
any protocol.

•

Basic Ethernet mode
In Basic Ethernet Mode network communication follows the rules of Legacy Ethernet(IEEE802.3). Network access is via CSMA/CD. Collisions occur, and network traffic is nondeterministic.
Any protocol on top of Ethernet may be used in Basic Ethernet mode, the preferredmechanisms for data exchange between nodes being UDP/IP and TCP/IP.

4.2

POWERLINK Mode

4.2.1

Introduction

POWERLINK Mode is based on the standard Ethernet CSMA/CD technique (IEEE 802.3) and thus
works on all Legacy Ethernet hardware.
Determinism is achieved with a pre-planned and organized message exchange: messages aregrouped in cycles, which are subdivided into the isochronous and the asynchronous phase.
Each node gets permission for sending its own frames by the POWERLINK MN. Therefore, nocollisions should occur and the collision-resolving re-transmission of messages defined by IEEE802.3,
which is responsible for the non-deterministic behavior of Legacy Ethernet, is not used.

4.2.2

POWERLINK Nodes

The node managing the permission to send messages to the Ethernet is called the POWERLINKManaging Node (MN).
All other nodes transmit only within communication slots assigned by the MN. They are thus called
Controlled Nodes (CN).

4.2.2.1

POWERLINK Managing Node

Only the MN may send messages independently – i.e. not as a response to a received message.
Controlled Nodes shall be only allowed to send when requested to by the MN.
The Controlled Nodes shall be accessed cyclically by the MN. Unicast data shall be sent from the MN
to each configured CN (frame: PReq), which shall then publish its data via multicast to all other nodes(frame: PRes).
Optionally, the MN may send a multicast Pres frame in the isochrononous phase (see Fig. 19). With
this frame the MN may publish its own data to all other nodes.
All available nodes in the network shall be configured on the MN.
Only one active MN is permitted in a POWERLINK network.
The ability of a node to perform MN functions shall be indicated by the device description entry
D_DLL_FeatureMN_BOOL.

EPSG DS 301 V1.5.1

4.2.2.2-40-

POWERLINK Controlled Node

CNs shall be passive bus nodes. They shall only send when requested by the MN.
The ability of a node to perform CN functions shall be indicated by the device description entry
D_DLL_FeatureCN_BOOL.

4.2.2.2.1

Isochronous CN

Each isochronous CN shall receive a unicast PReq frame from the MN in the POWERLINK cycle andshall send back a PRes frame to the MN. PReq and PRes frames may transport isochronous data.
CNs may be accessed every cycle or every nth cycle (multiplexed nodes, n > 1).
PReq can only be received by the specifically addressed CN. However, PRes frames shall be sent by
the CN as multicast messages, allowing all other CNs to monitor the data being sent.
Additional data from the MN may be received by a multicast PRes message transmitted by the MN.
Isochronous CNs shall request the right to transmit asynchronous data from the MN, if required.
The ability of a CN to perform isochronous communication shall be indicated by a feature flag in theobject dictionary entry NMT_FeatureFlags_U32 (1F82h) and the device description entry
D_NMT_Isochronous_BOOL.
No POWERLINK CN device shall rely on being polled as isochronous CN, when the network performs
the isochronous POWERLINK cycle (4.2.4.1), Async-only CN type communication shall be
guaranteed. Application level function limitations may occur when a device enabled to perform
isochronous functions is operated in Async-only mode.

4.2.2.2.2

Async-only CN

CNs may be operated in a way, that they aren’t accessed cyclically in the isochronous phase by the
MN.
The MN shall cyclically poll each async-only CN during the asynchronous phase with a StatusRequest– a special form of the SoA frame. The CN shall respond with a StatusResponse, special form ofAsynchronous Send frame. The poll interval shall be at least C_NMT_STATREQ_CYCLE. It isaffected by the asynchronous scheduling and is thus non-deterministic.
Async-only CNs shall request the right to transmit asynchronous data from the MN, if required.
Async-only CNs shall actively communicate during the asynchronous phase only. Nevertheless, they
may listen to the multicast network traffic, transmitted by the MN and the isochronous CNs.

4.2.3

Services

POWERLINK provides three services:•
Isochronous Data Transfer
One pair of messages per node shall be delivered every cycle, or every n th cycle in the case ofmultiplexed CNs.
Additionally, there may be one multicast PRes message from the MN per cycle.
Isochronous data transfer is typically used for the exchange of time critical data (real-time data).
•
Asynchronous Data Transfer
There may be one asynchronous message per cycle. The right to send shall be assigned to arequesting node by the MN via the SoA message.
Asynchronous data transfer is used for the exchange of non time-critical data.
•
Synchronisation of all nodes
At the beginning of each isochronous phase, the MN transmits the multicast SoC message very
precisely to synchronise all nodes in the network.

4.2.4

POWERLINK Cycle

The POWERLINK cycle shall be controlled by the MN.

EPSG DS 301 V1.5.1

4.2.4.1-41-

Isochronous POWERLINK Cycle

Isochronous data exchange between nodes shall occur cyclically. It shall be repeated in a fixedinterval, called POWERLINK cycle.
Managing Node (MN)
Isochronous Phase
PReq
to CN 1PReq
to CN 2
PResfrom CN 1

PResfrom MN
PRes
from CN 2

SoA

AsyncSend

AsyncSend

Idle Phase

SoC

Asynchronous Phase

Controlled Nodes (CN)Fig. 19.

POWERLINK Cycle

The following time phases exist within one cycle:•
Isochronous phase•
Asynchronous phase•
Idle phase
It is important to keep the start time of a POWERLINK cycle as exact (jitter-free) as possible. The
length of individual phases can vary within the preset phase of a POWERLINK cycle.
POWERLINK Cycle Time

Fig. 20.

POWERLINK Cycle Time

POWERLINK Cycle Time

POWERLINK - an isochronous process

The network shall be configured in a way that the preset cycle time is not exceeded. Adherence to thecycle time shall be monitored by the MN.
All data transfers shall be unconfirmed, i.e. there is no confirmation that sent data has been received.
To maintain deterministic behavior, protecting the isochronous data (PReq and PRes) is neither
necessary nor desired. Asynchronous data may be protected by higher protocol layers.

4.2.4.1.1

Isochronous phase

At the beginning of a POWERLINK cycle, the MN shall send a SoC frame to all nodes via Ethernet
multicast. The send and receive time of this frame shall be the basis for the common timing of all thenodes.
Only the SoC frame shall be generated on a periodic basis. The generation of all other frames shall beevent controlled (with additional time monitoring per node).
The MN shall start the isochronous data exchange after the SoC frame has been sent.
A PReq frame shall be sent to every configured and active node. The accessed node shall respond bya PRes frame.
PReq shall be an Ethernet unicast frame. It is received by the target node only. PRes shall be sent as
an Ethernet multicast frame.
Both the PReq and the PRes frames may transfer application data. The MN only sends PReq data to
one CN per frame. PReq transfer is dedicated to data relevant for the addressed CN only.
In contrast, the PRes frame may be received by all nodes. This makes communication relationships
possible according to the producer/consumer model.
The PReq / PRes procedure shall be repeated for each configured and active isochronous CN.

EPSG DS 301 V1.5.1-42-

The MN may send a multicast PRes frame to all nodes. This frame is dedicated to transfer data
relevant for groups of CNs.
Support of PRes transmission by the MN is optional. The ability of an MN to transmit PRes shall be
indicated by the device description entry D_DLL_MNFeaturePResTx_BOOL. If the feature is provided,transmission shall be enabled by NMT_NodeAssignment_AU32[C_ADR_MN_DEF_NODE_ID ].Bit 12.
The isochronous phase shall be calculated from start of SoC to start of SoA.
The size of the POWERLINK cycle is predominantly affected by the size of the isochronous phase.
When configuring the POWERLINK cycle, the sum of the times required by the PReq / PRes accesses
to each configured CN shall be taken into account, i.e. the time needed to access all configured nodes
in one cycle has to be accounted for. Use of the multiplexed access technology (4.2.4.1.1.1) may
reduce the amount of time.
When operating the isochronous phase, the length of this phase may vary according to the number ofactive CNs.
The order in which CNs are polled may be implementation specific or controlled by object
NMT_IsochrSlotAssign_AU8 if supported by the MN. An implementation should pack the performed
PReq / PRes packages to the begin of the isochronous phase. It should provide means to rearrange
the poll order, to avoid location of the nodes having the worst SoC latency time value(D_NMT_CNSoC2PReq_U32) at the slot following SoC.
Isochronous phases may be counted by the device. If implemented, counting shall be performed onbase of transmitted or received SoC frames. The counter value may be accessed via
DIA_NMTTelegrCount_REC.IsochrCyc_U32.

4.2.4.1.1.1

Multiplexed Timeslots

POWERLINK supports CN communication classes, that determine the cycles in which nodes are to beaddressed.
•
Continuous
Continuous data shall be exchanged in every POWERLINK cycle.
•
Multiplexed
Multiplexed data to and from one CN shall not be exchanged in every POWERLINK cycle.
The accesses to the multiplexed CNs shall be dispersed to the multiplexed cycle that consists ofa number of POWERLINK cycles.
The dispersion allows the isochronous access to a large number of CNs without elongating the
POWERLINK cycle to an unacceptable amount. However, multiplexed CN access reduces thepoll frequency to the particular CN.
The configuration of the multiplexed cycle is shown in 4.2.4.4.
Managing Node (MN)

Isochronous Phase
Phase
SoC

1

2

1

3

2

4

3

Multiplexed
Slot 1MN

4Fig. 21.

SoC

Async
Send

Asynchronous
Phase

Isochronous Phase
1

2

1

Multiplexed
Slot 25

2

6

5

Multiplexed
Slot 1

MN

6

Idle
Phase

SoA

Async
Send

Multiplexed
Slot 2Multiplexed Cycle Time

Controlled Node (CN)Cyclic station

SoA

Idle
Phase

Multiplexed station

1 - 6: PReq resp. PRes to/from CN 1 - 6

Multiplexed POWERLINK cycle

Continuous and multiplexed access may be operated in parallel during one POWERLINK cycle. The
apportionment of the isochronous phase to continuous and multiplexed slots shall be fixed byconfiguration (NMT_MultiplCycleAssign_AU8, NMT_IsochrSlotAssign_AU8).
Although the multiplexed nodes are not processed in each cycle, they can monitor the entire datatransfer of the continuous nodes because all PRes frames are sent as multicast frames.

EPSG DS 301 V1.5.1-43-

E.g. in Motion Control, multiplexed timeslots can be used for a large number of slave axes to receive
position data from few master axes. The master axes are configured to communicate continuously,accesses to the slave axes multiplexed. In this way, the master axes transmit their data to the(monitoring) slave axes in each cycle, while the slave axes also take part in the communication in aslower cycle.
The size of each particular multiplexed slot shall be equal to the maximum time necessary for the
PReq / PRes access of the CN assigned to the slot.
In case of MN cycle loss, the multiplexed access sequence shall be continued on a per time base,after the cycle loss error phase is over. E.g. CNs shall be skipped to maintain time equidistance ofaccess to nodes not affected by the cycle loss.
The ability of an MN enabled node to perform control of multiplexed isochronous operation shall be
indicated by the device description entry D_DLL_MNFeatureMultiplex_BOOL. The ability of a CN
enabled node to be isochronously accessed in a multiplexed way shall be indicated by the device
description entry D_DLL_CNFeatureMultiplex_BOOL.

4.2.4.1.2

Asynchronous phase

In the asynchronous phase of the cycle, access to the POWERLINK network may be granted to one
CN or to the MN for the transfer of a single asynchronous message only.
There shall be two types of asynchronous frames available:•
The POWERLINK ASnd frame shall use the POWERLINK addressing scheme and shall besent via unicast or broadcast to any other node.
•
A Legacy Ethernet message may be sent.
If no asynchronous message transmission request is pending at the MN scheduling queues(4.2.4.1.2.1), the MN shall issue a SoA without assignment of the right to send to any node. No ASndframe will follow to the SoA frame in this case.
The MN shall start the asynchronous phase with the SoA. The SoA shall be used to identify CNs,
request status information of a CN, to poll async-only CNs and to grant the asynchronous transmit
right to one CN.
The SoA frame is the first frame in the asynchronous phase and is a signal to all CNs that all
isochronous data have been exchanged during the isochronous phase.
The asynchronous phase shall be calculated from the start of SoA to the end of the asynchronous
response. If no asynchronous response is allowed for any node, the asynchronous phase shall beterminated by the end of SoA .
This definition is valid from the network’s point view. It may be different from the node’s application
point of view. Due to the AsyncSend addressing scheme, the asynchronous phase may be terminatedby the end of SoA on those nodes not being addressed, whereas it ends at the end of theasynchronous response on the addressed nodes.
Asynchronous frames may be counted by the device. If implemented, received frames shall be
indicated by DIA_NMTTelegrCount_REC.AsyncRx_U32 and transmitted frames by
DIA_NMTTelegrCount_REC.AsyncTx_U32.

EPSG DS 301 V1.5.1

4.2.4.1.2.1
GenericRequests
from MN-44-

Asynchronous Scheduling
StatusRequests
from MN

IdentRequests
from MN

Requests from
CNs

Queue

Priority-controlled

Manager Async
Scheduler

Fig. 22.

Asynchronous scheduling

The MN handles scheduling of all asynchronous data transfers.
If a CN wants to send an asynchronous frame, it shall inform the MN via the PRes or the
StatusResponse frame.
The asynchronous scheduler of the MN shall determine in which cycle the right to send theasynchronous frame will be granted. It shall guarantee that no send request will be delayed for anindefinite amount of time, even if network load is high.
The MN shall select a node from all queued send requests (including its own). It shall send a SoA
frame with a Requested Service Target identifying which node is allowed to send an asynchronous
frame.
The MN shall manage the dispatching of the asynchronous phase using different queues:•
Generic transmit requests from the MN.
•
IdentRequest frames from the MN to identify CNs•
StatusRequest frames to poll CNs•
Transmit requests from the CNs

4.2.4.1.2.2

Distribution of the Asynchronous phase

With the PRes, IdentResponse or StatusResponse RS flag (3 bits, see 4.6.1.1.4, 7.3.3.2.1, 7.3.3.3.1)
the CN shall indicate the number of send-ready packages in it’s queues.
An RS value of 0 (000b) shall indicate that the queues are empty and an RS value of 7 (111 b) shallindicate that 7 or more packages are queued.
The assignment of the asynchronous phase shall decrement the MN-administered number of frames
requested by the respective CN. If the MN queue length reached zero, no more further asynchronous
phases are assigned.
The algorithm that is used to assign the asynchronous phase when there are multiple requests
pending shall be manufacturer-specific.

4.2.4.1.2.3

Asynchronous Transmit Priorities

Asynchronous transmit requests may be prioritized by 3 PR bits in the PRes, the IdentResponse andStatusResponse frame (see 4.6.1.1.4, 7.3.3.2.1, 7.3.3.3.1).
POWERLINK supports eight priority levels. Two of these levels are dedicated to POWERLINK
purpose:EPSG DS 301 V1.5.1•-45-

PRIO_NMT_REQUESTThis is the highest priority that shall be exclusively applied if a CN requests an NMT command
to be issued by the MN•
PRIO_GENERIC_REQUEST
Medium priority which is the standard priority level for non-NMT command requests. SDO via
asynchronous communication (see 6.3.2) requests shall apply this priority level. Application
requests may apply PRIO_GENERIC_REQUESTThe remaining priority levels above and below PRIO_GENERIC_REQUEST are available forapplication purpose.
Requests with a high priority level shall be preferentially assigned by the MN compared to those withlow priority numeric value.
Requests of different priorities shall be handled by independent priority specific queues on the CN..
The PRes PR flags shall indicate the highest priority level containing pending requests. The RS flags
shall indicate the number of pending requests at the reported priority level. Lower priority request
indication shall be suspended until all high priority requests have been assigned.
Fig. 23 shows an example of priority related asynchronous request handling.

EPSG DS 301 V1.5.1
Int. Tables

-46-

MN

CN

Int. Queues
Prio0

...

0

Prio3 ...

Prio 700

PReq
PRes( PR= 3 RS=0)
Unspecified messages
ready to tranmsit

SoA

Prio0
Node No. PR

RS

3

0

0

RS

3

5

SoA

0

Prio0

...

Prio3 ...

Prio 70

50

Prio3 ...

Prio 740PReq
PRes( PR= 3 RS=5)..
7

Prio 7

5

PRes( PR= 3 RS=5)

Schedule 5 unspec.
invites
Node No. PR

Prio3 ...

PReq

..
7

...

0

0

SoA( unspec. Invite)
ASnd ( unspec.)

Prio0

...

0
PReq
Node No. PR

RS

3

4

PRes( PR= 3 RS=4)..
7

SoA( unspec. Invite)

0

NMT command andUnspec. Message ready totranmsit

ASnd ( unspec.)
Prio0

...

0
Node No. PR

RS

3

3

3

Prio3 ...

Prio 7

3

1

SoA( unspec. Invite)
ASnd ( unspec.)
Prio0

...

0

RS

PReq

2

..
7

1

PRes( PR= 7 RS=1)0

Schedule 1 NMT
request invite
Node No. PR

Prio 7

4

PReq

..
7

Prio3 ...

PRes( PR= 7 RS=1)

1

SoA( NMT Invite)
ASnd ( NMT)

Unspecified message ready totranmsit
Prio0

0

...

Prio3 ...

Prio 740

PReq
Node No. PR

RS

3

2

PRes( PR= 3 RS=4)..
7

SoA( unspec. Invite)

0

Schedule 2 unspec .
inviteFig. 23.

ASnd ( unspec.)

Asynchronous transmit priority handling(Priority level PR: 7 = PRIO_NMT_REQUEST, 3 = PRIO_GENERIC_REQUEST)EPSG DS 301 V1.5.1

4.2.4.1.3-47-

Idle Phase

The Idle Phase is the remaining time interval between the end of the asynchronous phase and the
beginning of the next cycle.
During the Idle Phase, all network components shall “wait" for the beginning of the following cycle. The
duration of the Idle Phase may be 0, i.e. an implementation shall not rely on an existing or fixed Idle
Phase.
The idle phase shall be calculated from end of SoA or ASnd (see 4.2.4.1.2) to start of SoC.

4.2.4.2

Reduced POWERLINK Cycle

During system startup (NMT state NMT_MS_PRE_OPERATIONAL_1), a reduced POWERLINK Cycle
shall be applied to diminish network load, while the system is being configured via SDO
communication.
The Reduced POWERLINK Cycle shall consist of queued asynchronous phases only. The duration of
the asynchronous phase and thus the duration of the Reduced POWERLINK Cycle may vary from one
cycle to the next.
If a CN is assigned to send and there are no information about the length of the expected AsyncSend
frame available at the MN, the next Reduced POWERLINK Cycle shall not start until at least the
timeout given by the length of a maximum size ethernet frame
NMT_CycleTiming_REC.AsyncMTU_U16) plus the maximum response time to the SoA invite
message required by the CNs (NMT_CycleTiming_REC.ASndMaxLatency_U32) elapsed.
If the MN endues AsyncSend length information, i.e. if the MN assignes the Asynchronus Slot to itself
or if the MN is the target node of the asynchronous message, it may reduce the Reduce POWERLINK
cycle length (Fig. 24).
If there is no assignment to any node (MN included), the next Reduced POWERLINK Cycle may
follow without any timeout.
The assignment mechanism used for the asynchronous phase of the isochronous POWERLINK cycle(4.2.4.1.2) shall also be applied to the Reduced POWERLINK Cycle.
Managing Node (MN)

Asynchronous Phase

Asynchronous Phase

SoA

SoA

SoA

AsyncSend

AsyncSend

Idle Phase

Async
Phase

Idle Phase

AsyncSend

Asynchronous Phase

Idle Phase

SoA

Idle Phase

AsyncSend

Idle Phase

SoA

Asynchronous Phase

Controlled Nodes (CNs)

Fig. 24.

Reduced POWERLINK cycle

The Reduded POWERLINK Cycle shall be robust to collisions. Collisions shall be resolved by
CSMA/CD. In case of collision, the next Reduced POWERLINK Cycle shall start after a timeout givenby the double length of a maximum size ethernet frame (1518 Bytes).

4.2.4.3

POWERLINK Cycle Timing

Fig. 25, Fig. 26 and Fig. 27 show the timing of the isochronous POWERLINK cycle. The figures showa system of three nodes. The MN is physically located between two isochronously accessed CNs.
The figures are a schematic approach. They are valid for the NMT states
NMT_MS_READY_TO_OPERATE and NMT_MS_OPERATIONAL or
NMT_CS_READY_TO_OPERATE and NMT_CS_OPERATIONAL. The amount of time shown does
not reflect the realistic timing relationships of a real system.
Fig. 25 shows the typical sequence of messages in the isochronous phase. The PRes frames fromone CN are received by the other CN (cross traffic). Fig. 26 depicts the timing of a transmission of anasynchronous frame by a CN, Fig. 27 the less critical case of asynchronous transmission by the MN.

EPSG DS 301 V1.5.1-48-

Tab. 4 provides the description of the timing parameters introduced by the figures, the source of thedata, special handling of the data and object dictionary entries containing the parameters.
The node located verifications proposed by Tab. 4 are optional on the node if not mentioned
otherwise. A POWERLINK network configuration tool shall perform all the verifications duringconfiguration process.
Application hint:
The timing parameters introduced by this chapter allows a sophisticated fine tuning of the cycle timing,
required by notably cycle time sensitive high end applications.
The majority of applications will apply default values for most of the parameters. Only a few variables
will remain to be setup to configure a typical POWERLINK network.
MN Timing
Parameters

CN2

CN1

CN2 Timing
Parameters

SoC

tSoC-PReq_CN2
tSoC

SoC

PReq

tPReq_CN1_MN

tpropag_CN1

tSoC
PReq

tSoC-PReq_MN

CN1 Timing
Parameterstpropag_CN2

SoC

tSoC

MN

tSoC-PReq_CN1
PReq

not
addressed

tPReq-PRes_CN1_MN

tPReq-PRes_CN1
PRestcycle_MN

max. Distancetcycle_CN1

tPResRx_CN1_CN2
PReq

tPRes-PReq_CN2

PReq

tPReq_CN2_MN

tPResTx_CN1
tcycle_CN2

PRes
PRes

tPResRx_CN1_MN
tPRes-PReq_MN

tPReq_CN1

tPReq_CN2

tPReq-PRes_CN2_MN
PRes

tPReq-PRes_CN2

PRes

tPRes_CN2_CN2

tPResRx_CN2_MN

PRes

tPRes-SoA_CN2
tPResRx_MN_CN1
tSoA
tPRes-SoA_CN1

SoA

SoA

tSoA

tPResRx_CN2_CN1
tPResRx_MN_CN2
tPRes-PRes_CN1

SoA

tPRes-SoA_MN

PRes

tPResTx_MN

PRes

PRes

tPRes-PRes_MN

Fig. 25.

POWERLINK cycle timing, start phase and isochronous phasetSoA

EPSG DS 301 V1.5.1

MN

CN2 Timing
Parameters

CN1

SoA

tSoA

tSoA

CN1 Timing
Parameterstcycle_CN1

CN2

SoA

MN Timing
Parameters

-49-

tSoA

SoA

tSoA-ASndRx_MN

tSoA-ASndTx_CN1
ASnd

tcycle_MN

max. Distancetcycle_CN2

ASndtidle_CN1

ASnd

tASndRx

tASndTx

tASndRx

tidle_MN
tidle_CN2

tASndRx-SoC_MN
SoC

tASndRx-SoC_CN2
tSoC

SoC

tSoC

tASndRx-SoC_CN1
SoC

tSoC

Hint: ASnd refers to POWERLINK ASnd frames and non-POWERLINK frames

POWERLINK cycle timing, asynchronous phase, AsyncSend transmission by CN
MN

CN1

CN2 Timing
Parameters

ASndtSoA-ASndTx_MN

ASndtSoA-ASndRx_CN2
tSoA
tASndRxtSoA-ASndRx_CN1
ASnd

tcycle_MN

tASndTx

tidle_MN

tSoA

SoA

tSoA

CN1 Timing
Parameterstcycle_CN1

CN2

SoA

MN Timing
Parameters

SoA

Fig. 26.

tASndRx

tcycle_CN2

tidle_CN2
tidle_CN1

tASndRx-SoC_MN
SoC

tASndRx-SoC_CN2
tSoC

SoC

tSoC

SoC

tASndRx-SoC_CN1
tSoC

Hint: ASnd refers to POWERLINK ASnd frames and non-POWERLINK frames

Fig. 27.

POWERLINK cycle timing, asynchronous phase, AsyncSend transmission by MN

EPSG DS 301 V1.5.1

-50-

No
1

Parametertcycle_MN,
tcycle_CNn

Description
length of POWERLINK isochronous
cycle

Data Source
system configuration

2

tSoC

SoC frame time consumption3

tpropag_CNn

signal propagation time MN → CNn
and vice versa

constant
tSoC = C_DLL_T_MIN_FRAME +C_DLL_T_PREAMBLE
system configuration

4

tSoC-PReq_MN

delay between end of SoC
transmission and start of PReq
transmission

system configuration

Handling1
MN may verify before isochronous
access to CNn:tcycle_MN = tcycle_CNn
--

Index
NMT_CycleLen_U32

tpropag_CNn = ( tPReq-PRes_CNn_MN –tPReq-PRes_CNn ) / 2----

depends on implementation of NMT_MNCycleTiming_REC. WaitSoCPReq:
a. tSoC-PReq_MN = max( tSoC-PReq_CNn , tSoC-PReqMin_MN )b. tSoC-PReq_MN = tSoC-PReqMin_MNa.
b.

NMT_MNCycleTiming_REC.
WaitSoCPReq--

5

tSoC-PReqMin_MN

MN minimum delay between end of
SoC transmission and start of PReq
transmission

MN device description
D_NMT_MNSoC2PReq_U32

tSoC-PReqMin_MN  C_DLL_T_IFG--

6

tSoC-PReq_CNn

minimum delay required by CNn
between end of SoC reception andstart of PReq reception

CNn device description
D_NMT_CNSoC2PReq_U32

tSoC-PReq_CNn  C_DLL_T_IFG--

7

tPReq_CNn_MN
tPReq_CNntime consumption of PReq frame to be tPReq_CNn_MN = (tPReqPL_CNn_MN +transmitted to CNn
C_DLL_T_EPL_PDO_HEADER +C_DLL_T_ETH2_WRAPPER) * 8 *C_DLL_T_BITTIME +C_DLL_T_PREAMBLE

--

--

8

tPReqPL_CNn_MN

payload of PReq frame to betransmitted to CNn

NMT_MNPReqPayloadLimitList_AU16[NodeIDCNn]

9tPReqPLMax_MN

size of MN isochronous frame transmit system configurationbuffer (referring to payload)

MN may verify at start up:
tPReqPL_CNn_MN  tPReqPLMax_MN
MN may verify before isochronous
access to CNn:tPReqPL_CNn_MN = tPReqPL_CNn--

10tPReqPL_CNn

payload of PReq frame expected byCNn

CNn may verify at start up:
tPReqPL_CNn  tPReqPLMax_CNn

NMT_CycleTiming_REC.
PReqActPayloadLimit_U16

system configuration

system configuration

NMT_CycleTiming_REC.
IsochrTxMaxPayload_U16

1 The node located verifications are optional if not mentioned otherwise. A configuration tool shall perform the verifications during network configuration process.

EPSG DS 301 V1.5.1

-51-

No
11

Parameter
tPReqPLMax_CNn

Description
Data Source
size of CNn isochronous frame receive system configurationbuffer (referring to payload)Handling1--

Index
NMT_CycleTiming_REC.
IsochrRxMaxPayload_U16

12tPReq-PRes_CNn

delay between end of PReq reception
and start of PRes transmission

system configuration

tPReq-PRes_ CNn  C_DLL_T_IFG

NMT_CycleTiming_REC.
PResMaxLatency_U32

13

tPResTx_CNn
tPResRx_CNn_MN
tPResRx_CNn_ CNm

time consumption of PRes to betransmitted by CNn

tPResTx_CNn = (tPResPLTx_CNn +C_DLL_T_EPL_PDO_HEADER +C_DLL_T_ETH2_WRAPPER) * 8 *C_DLL_T_BITTIME +C_DLL_T_PREAMBLE

--

--

14

tPResPLTx_CNn

payload of PRes to be transmitted byCNnsystem configuration

NMT_CycleTiming_REC.
PResActPayloadLimit_U16

15

tPResPLTxMax_CNn

size of CNn PRes frame transmit buffer system configuration(referring to payload)

CNn may verify at start up:
tPResPLTx_CNn  tPResPLTxMax_CNn--

16

tPReq-PRes_CNn_MN

delay timeout between end oftransmission of PReq to CNn and startof reception of PRes from CNn

system configuration

if 1st device polled after SoC depends on
implementation of
NMT_MNCycleTiming_REC.
WaitSoCPReq(cf. Tab. 4, Line 4):
a. tPReq-PRes_CNn_MN =tPReq-PRes_CNn +2 * tpropag_CNn
b. tPReq-PRes_CNn_MN =max ( tSoC-PReq_CNn ) +tPReq-PRes_CNn +2 * tpropag_CNn
else
tPReq-PRes_CNn_MN = tPReq-PRes_CNn+ 2 * tpropag_CNn
used by CN response supervision ofError Handling DLL

depends on implementation of
NMT_MNCycleTiming_REC.
WaitSoCPReq(cf. Tab. 4, Line 4)
a. NMT_MNCNPResTimeout_AU32[NodeIDCNn]
b. NMT_MNCNPResTimeout_AU32[NodeIDCNn],
NMT_MNCycleTiming_REC.
WaitSoCPReq

17

tPResPLRx_CNn_MN

payload of PRes frame from CNn
expected by MN

system configuration

MN may verify at start up:
tPResPLRx_CNn_MN  tPResPLRxMax_MN
MN may verify before isochronous
access to CNn:tPResPLRx_CNn_MN = tPResPLTx_CNn

NMT_PresPayloadLimitList_AU16

NMT_CycleTiming_REC.
IsochrTxMaxPayload_U16[NodeIDCNn]EPSG DS 301 V1.5.1

-52-

No
18

Parameter
tPResPLRxMax_MN

Description
size of MN PRes frame receive buffer(referring to payload)

Data Source
system configuration

Handling1--

Index
NMT_CycleTiming_REC.
IsochrRxMaxPayload_U16

19

tPResPLRx_CNm_CNn

payload of PRes frame from CNm
expected by CNn

system configuration

CNn may verify at start up:
tPResPLRx_CNm_CNn  tPResPLRxMax_CNn2
andtPResPLRx_CNm_CNn  tPResPLTx_CNm--

NMT_PresPayloadLimitList_AU16[NodeIDCNm]

20

tPResPLRxMax_CNn

size of CNn PRes frame receive buffer(referring to payload)system configuration

NMT_CycleTiming_REC.
IsochrRxMaxPayload_U16

21

tPRes-PReq_MN

delay between end of PRes reception
and start of PReq transmission

MN device description
D_NMT_MNPRes2PReq_U32

tPRes-PReq_MN  C_DLL_T_IFG--

22

tPRes-PReq_CNn

minimum delay between end of PRes
reception and start of PReq reception

CNn implementation requirement

every CN shall support
tPRes-PReq_MN = C_DLL_T_IFG--

23

tPRes-PRes_MN

delay between end of reception ofPRes from CNn and start oftransmission of PRes by MN

MN device description
D_NMT_MNPRes2PRes_U32

tPRes-PRes_MN  C_DLL_T_IFG--

24

tPRes-PRes_CNn

minimum delay between end ofreception of PRes from CNn and startof reception of PRes from MN 3

CNn implementation requirement

every CN shall support
tPRes-PRes_MN = C_DLL_T_IFG--

25

tPResTx_MN
tPResRx_MN_CNn

time consumption of PRes frame to be tPResTx_MN_MN = ( tPResPLTx_MN_MN +transmitted by MN
C_DLL_T_EPL_PDO_HEADER +C_DLL_T_ETH2_WRAPPER ) * 8 *C_DLL_T_BITTIME +C_DLL_T_PREAMBLE

--

--

26

tPResPLTx_MN_MN

payload of PRes frame to betransmitted by MN

system configuration

MN may verify at start up:
tPResPLTx_MN_MN  tPResPLTxMax_MN

NMT_PresPayloadLimitList_AU16[NodeIDMN]

27

tPResPLTxMax_MN

size of MN PRes frame transmit buffer(referring to payload)system configuration--

NMT_CycleTiming_REC.
IsochrTxMaxPayload_U16

28

tPResPLRx_MN_CNn

payload of PRes frame from MN
expected by CNn

system configuration

CNn may verify at start up:
tPResPLRx_MN_CNn  tPResPLRxMax_CNn

NMT_PresPayloadLimitList_AU16

2 see 7.2.1.5.5
3 For future development, CNs shall also support the reception of several PRes from other CNs without intermitting time gaps.

[NodeIDMN]EPSG DS 301 V1.5.1

-53-

No
29

Parameter
tPRes-SoA_MN

Description
if PRes transmission by MN:
delay between end of PRestransmission by MN and start oftransmission of SoA by MN
else
delay between end of reception ofPRes from CNn and start oftransmission of SoA by MN

Data Source
MN device description
D_NMT_MNPResTx2SoA_U32
resp.
D_NMT_MNPResRx2SoA_U32

Handling1
tPRes-SoA_MN  C_DLL_T_IFG

Index
--

30

tPRes-SoA_CNn

minimum delay between end ofreception of PRes and start ofreception of SoA

CNn implementation requirement

every CN shall support
tPRes-SoA_MN = C_DLL_T_IFG

--

31

tSoA

SoA frame time consumption

--

--

32

tSoA-AsndTx_CNn

delay between end of SoA reception
and start of AsyncSend transmission

constanttSoA = C_DLL_T_MIN_FRAME +C_DLL_T_PREAMBLE
system configurationtSoA-AsndTx_CNn  C_DLL_T_IFG

NMT_CycleTiming_REC.
ASndMaxLatency_U32

33

tASndTx
tASndRxtime consumption of asynchronous
frame to be transmitted

tASndTx = ( tASndPLTx +C_DLL_T_ETH2_WRAPPER ) * 8 *C_DLL_T_BITTIME +C_DLL_T_PREAMBLE

--

--

34

tASndPLTx

payload of asynchronous frame to betransmitted

application

Node shall verify:tASndPLTx  tASndMTU_MN/CNn--

35

tASndPLRx

payload of received asynchronous
frame

application

--

--

36

tASndMTU_MN/CNn

maximum size of asynchronous frame system configuration
to be transmitted (referring to payload)Node may verify:tASndMTU_MN/CNn  tASndPLTxMax_MN/CNn
and

NMT_CycleTiming_REC.
AsyncMTU_U16

37

tASndPLTxMax_MN/CNn size of AsyncSend frame transmit
buffer (referring to payload)system configuration

tASndMTU_MN/CNn  tASndPLRxMax_MN/CNn
MN may verify:tASndMTU_MN = tASndMTU_CNn--

38

tASndPLRxMax_MN/CNn size of MN AsyncSend frame receive
buffer (referring to payload)system configuration--

NMT_CycleTiming_REC.
AsyncMTU_U16
NMT_CycleTiming_REC.
AsyncMTU_U16

EPSG DS 301 V1.5.1-54-

Handling1
Index
tSoA-AsndRx_MN = max
NMT_MNCycleTiming_REC( tSoA_AsndTx_CNn + 2 * tpropag_CNn )used by CN response supervision ofError Handling DLL in case of
SoA.StatusRequest or SoA.IdentRequest

No
39

ParametertSoA-AsndRx_MN

Description
delay timeout between end oftransmission of SoA and start ofreception of AsyncSend from that CN,
that requires the most time for signal
travel and response to SoA

Data Source
system configuration

40

tidle_MN, tidle_CNn

idle time before next cycle--

41

tASndRx-SoC_MN

minimum delay between end ofreception of AsyncSend and start oftransmission of SoC

system configuration, time
MN may verify:
consumption by asynchronous traffic tidle_MN  tASndRx-SoC_MN
CNn may verify:
tidle_CNn  tASndRx-SoC_CNn
MN device description
tASndRx-SoC_MN  C_DLL_T_IFG
D_NMT_MNASnd2SoC_U32

42

tASndRx-SoC_CNn

minimum delay between end ofreception of AsyncSend and start ofreception of SoC

CNn implementation requirement

every CN shall support
tASndRx-SoC_MN = C_DLL_T_IFG--

43

tSoA-AsndTx_MN
tSoA-AsndRx_CN

delay between end of transmission of
SoA and start of transmission of
AsyncSend by MN

MN device description
D_NMT_MNSoA2ASndTx_U32

tSoA-AsndTx_MN  C_DLL_T_IFG----

POWERLINK cycle timing parameters
Hint: Tab. 4 does not differentiate between frame size and the time required to transmit the frame. Both quantities shall be regarded to be equivalent. The
transmission time shall be calculated from the size by multiply with transmit time per byte.
When regarding the supporting indices, the frame type specific protocoll overhead in frame size shall be considered by time calculation (see 4.6).

EPSG DS 301 V1.5.1

4.2.4.3.1-55-

POWERLINK Cycle Timing Error Handling

POWERLINK cycle timing may be safeguarded at runtime by the node located verifications claimed by Tab. 4. Tab. 5 provides error codes to be issued, when therespective verification fails and the handling of the errors.
All errors shall be stored at the local error history (see 6.5). Errors identified by the CN shall be entered to the Emergency Queue of the Error Signaling. Mode ofall errors shall be 3h (refer 6.5.1). The errors shall be assigned to the POWERLINK profile (002h).

EPSG DS 301 V1.5.1
Tab. 4
No
1
8
8
10
14
16
17
17

19

26
28
34
36

-56-

Verification

Error Code

MN may verify before isochronous access to CNn:tcycle_MN = tcycle_CNn
MN may verify at start up:
tPReqPL_CNn_MN  tPReqPLMax_MN
MN may verify before isochronous access to CNn:tPReqPL_CNn_MN = tPReqPL_CNn
CNn may verify at start up:
tPReqPL_CNn  tPReqPLMax_CNn
CNn may verify at start up:
tPResPLTx_CNn  tPResPLTxMax_CNn
see Error Handling DLL (see 4.7.6.3)
MN may verify at start up:
tPResPLRx_CNn_MN  tPResPLRxMax_MN
MN may verify before isochronous access to CNn:tPResPLRx_CNn_MN = tPResPLTx_CNn
CNn may verify at start up:
tPResPLRx_CNm_CNn  tPResPLRxMax_CNn
andtPResPLRx_CNm_CNn  tPResPLTx_CNm
MN may verify at start up:
tPResPLTx_MN_MN  tPResPLTxMax_MN
CNn may verify at start up:
tPResPLRx_MN_CNn  tPResPLRxMax_CNn
Node shall verify:tASndPLTx  tASndMTU_MN/CNn
Node may verify:tASndMTU_MN/CNn  tASndPLTxMax_MN/CNn
and

36

tASndMTU_MN/CNn  tASndPLRxMax_MN/CNn
MN may verify:tASndMTU_MN = tASndMTU_CNn

39

see Error Handling DLL (see 4.7.6.4)

Error Handling

E_NMT_CYCLE_LEN

Error History
Additional Information
CNn Node ID

E_NMT_PREQ_LIM--

E_NMT_PREQ_CN

CNn Node ID

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2
do not access CNn isochronously

E_NMT_PREQ_LIM--

E_NMT_PRES_TX_LIM--

E_NMT_PRES_RX_LIM

CNn Node ID

E_NMT_PRES_CN

CNn Node ID

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2
do not access CNn isochronously

E_NMT_PRES_RX_LIM

CNm Node ID

CNn: do not read PRes from CNm

E_NMT_PRES_TX_LIM--

E_NMT_PRES_RX_LIM

MN Node ID

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2
CNn: do not read PRes from MN

E_NMT_ASND_TX_LIM--

do not transmit frame

E_NMT_ASND_MTU_LIM--

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2 or
NMT_CS_PRE_OPERATIONAL_2

E_NMT_ASND_MTU_DIF

CNn Node ID

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2 or
NMT_CS_PRE_OPERATIONAL_2

do not access CNn isochronously

do not change NMT state to
NMT_CS_PRE_OPERATIONAL_2
do not change NMT state to
NMT_CS_PRE_OPERATIONAL_2

EPSG DS 301 V1.5.1-57-

Tab. 4
No

Verification

Error CodeError History
Additional Information

Error Handling40

MN may verify:
tidle_MN  tASndRx-SoC_MN

E_NMT_IDLE_LIM--

40

CNn may verify:
tidle_CNn  tASndRx-SoC_CNn

E_NMT_IDLE_LIM--

do not change NMT state to
NMT_MS_PRE_OPERATIONAL_2
do not change NMT stateto
NMT_CS_PRE_OPERATIONAL_2

POWERLINK cycle timing verification: Error codes and handlingEPSG DS 301 V1.5.1

Multiplexed Slot Timing

cycle
count

3

1

2

Node
d

--

3

idle
SoC

Node
x, y

asynchr.
phase

contin.

Mux 2

Node Nodebcisochr. phase

Mux 1

Node
x, y

isochronous POWERLINK cycle

idle
SoC

--

contin.

asynchr.
phase

Node
a

isochr. phase

Mux 2

Node
x, y

isochronous POWERLINK cycle

idle
SoC

Mux 2

Multiplexedslot
assignment

contin.

Mux 1

idle
SoC

isochr. phaseasynchr.
phase

isochronous POWERLINK cycle

Mux 1

4.2.4.4

-58-

1

1
SoC
MC-Flag 0
prev.
multipl.
cycle

Fig. 28.

next
multipl.
cycle

multiplexed cycle

Multiple slot assignment

Fig. 28 demonstrates the assignment of the multiplexed slots to CNs. The multiplexed slots are
identified by “Mux 1” and “Mux 2”.
The assignment is controlled by the object dictionary entries
NMT_CycleTiming_REC.MultiplCycleCnt_U8 and NMT_MultiplCycleAssign_AU8.
NMT_CycleTiming_REC.MultiplCycleCnt_U8 defines the length of the multiplexed cycle in
POWERLINK cycle counts. If NMT_CycleTiming_REC.MultiplCycleCnt_U8 is zero, the multiplexed
access method shall not be applied, e.g. all CNs shall be accessed continuously.
The respective sub-index of NMT_MultiplCycleAssign_AU8 defines the cycle count inside themultiplexed cycle, when the respective CN shall be polled by the MN. If the sub-index is zero, the CN
shall be accessed continuously.
The order in which the CNs are polled by the MN may be set up by object
NMT_IsochrSlotAssign_AU8.
The number of slots per isochronous cycle can not be programmed directly by the configuration. It isderived from the maximum number of CN assignments that are cumulated to a cycle.
The following table shows the parameter values that contol the system in Fig. 28:
NMT_CycleTiming_REC.MultiplCycleCnt_U8
NMT_MultiplCycleAssign_AU8 [NodeIDa]
NMT_MultiplCycleAssign_AU8 [NodeIDb]
NMT_MultiplCycleAssign_AU8 [NodeIDc]
NMT_MultiplCycleAssign_AU8 [NodeIDd]
NMT_MultiplCycleAssign_AU8 [NodeIDx]
NMT_MultiplCycleAssign_AU8 [NodeIDy]

4.2.4.5

CN Cycle State Machine

4.2.4.5.1

Overview

3
1
2
2
3
0
0

The cycle state machine of the CN (DLL_CS) handles communication within a POWERLINK Cycle.
The DLL_CS tracks the order of the frames received within a cycle and reacts as described below.
The expected order of frame reception is dependant on the NMT_CS state (see 4.2.4.5.4 )If an error in the communication is detected by the DLL_CS, an error event to DLL Error Handling will
be generated. The DLL_CS will attempt to uphold communication regardless of any errors.

EPSG DS 301 V1.5.1

4.2.4.5.2•-59-

StatesDLL_CS_NON_CYCLIC
This state means that the isochronous communication isn’t started yet or the connection was
lost. It depends on the current state of the NMT_CS, which events are processed and which willbe ignored.

•

DLL_CS_WAIT_SOC
The state machine waits in this state after receiving the SoA frame until the beginning of thenext cycle (triggered by a SoC frame from the MN). Ethernet frames of any type may bereceived between the SoA and the SoC frames (asynchronous phase).

•

DLL_CS_WAIT_PREQ
After the beginning of the cycle, the state machine waits in this state for a PReq frame. After
PReq reception the CN shall respond with a PRes Frame. The CN may receive and process
PRes Frames from other CN whilst in this state.

•

DLL_CS_WAIT_SOA
After reception of a PReq frame the state machine waits for the reception of a SoA frame.
Reception of a SoA frame confirms the end of the isochronous phase. The CN may receive andprocess PRes Frames from other nodes whilst in this state.

4.2.4.5.3•

EventsDLL_CE_SOC
This Event signifies that a POWERLINK SoC frame was received from the MN. It marks the
beginning of a new cycle and simultaneously the beginning of the isochronous phase of thecycle.

•

DLL_CE_PREQ
This Event signifies that a POWERLINK PReq frame was received from the MN.

•

DLL_CE_PRES
The CN may be configured to process the PRes frames of other CN’s (cross traffic). Every timea PRes frame is received, a DLL_CE_PRES event is generated•

DLL_CE_SOA
This event signifies that a SoA frame was received from the MN. It marks the end of theisochronous phase of the cycle and the beginning of the asynchronous phase.

•

DLL_CE_ASND
This event signifies that an ASnd frame or a non POWERLINK frame has been received. Since
the frame types during the asynchronous phase are not limited to POWERLINK types, thisevent is generated on reception of all legal Ethernet frames.

•

DLL_CE_SOC_TIMEOUTThis event signifies that a SoC frame of the MN was lost. It occurs, when the SoC timeout
supervision detects a missed SoC frame.

4.2.4.5.4

Dependance of the NMT_CS on the DLL_CS

The state of the NMT_CS represents the network state and is used as a qualifier for certain transitionsof the DLL_CS. Because the NMT state influences the behaviour of the DLL_CS we could filter out therelevant DLL_CS transitions for a single NMT state, so we see only DLL_CS transitions which arepossible in a distinct NMT state.
Notation comment:
For clarity purposes the NMT_CS states as conditions for DLL_CS transitions have been omitted.
Because of comprehension and clarity purposes, the relevant transitions of single NMT_CS states arefiltered out and displayed within an own diagram as an “operation mode” of the DLL_CS. SomeEPSG DS 301 V1.5.1-60-

operation modes are nearly similar, so they are shown within a single figure and the differencies aredescribed in the transition table.

4.2.4.5.4.1

State NMT_GS_INITIALISATION, NMT_CS_NOT_ACTIVE,
NMT_CS_BASIC_ETHERNET,
NMT_CS_PRE_OPERATIONAL_1

In this NMT states the DLL_CS is in state DLL_CS_NON_CYCLIC.
For description of these NMT states see 7.1.4.

(DLL_CT6)
mode specificreaction

DLL_CSNON_CYCLIC(DLL_CT5)
mode specificreaction(DLL_CT11)
mode specificreaction

DLL_CS_CYCLICDLL_CS_
WAIT_SOCDLL_CS_
WAIT_SOADLL_CS_
WAIT_PREQ

Fig. 29.

CN cycle state machine, states NMT_GS_INITIALISATION, NMT_CS_NOT_ACTIVE,
NMT_CS_PRE_OPERATIONAL_1, NMT_CS_BASIC_ETHERNET

4.2.4.5.4.1.1 Transitions in other NMT states
DLL_CT6, DLL_CE_* [ ] / NMT state specific reaction
DLL_CT5 The cycle state machine is not active in the NMT states NMT_GS_INITIALISATION,
NMT_CS_NOT_ACTIVE, NMT_CS_PRE_OPERATIONAL_1 and NMT_CS_BASIC_ETHERNET.
This means, after the initial transition to DLL_CS_NON_CYCLIC its state does not influence thereaction of the CN. The reactions are defined by the state of the NMT_CS only. (see 7.1.4)
DLL_CT11 DLL_CE_* [ ] / NMT state specific reaction
This transition is triggered by the NMT state machine when changing from
NMT_CS_PRE_OPERATIONAL_1 to NMT_CS_PRE_OPERATIONAL_2 (NMT_CT4)

Transitions for CN cycle state machine, states NMT_GS_INITIALISATION,
NMT_CS_NOT_ACTIVE, NMT_CS_PRE_OPERATIONAL_1,
NMT_CS_BASIC_ETHERNETEPSG DS 301 V1.5.1

4.2.4.5.4.2-61-

State NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, NMT_CS_OPERATIONAL,
NMT_CS_STOPPED(DLL_CT4)
DLL_CE_PREQ
DLL_CE_PRES
DLL_CE_SOA
DLL_CE_ASND
DLL_CE_SOC_TIMEOUTDLL_CS_CYCLICDLL_CS_
WAIT_SOADLL_CS_
WAIT_SOC(DLL_CT3)
DLL_CE_SOA
DLL_CE_PREQ
DLL_CE_SOC_TIMEOUT(DLL_CT1)
DLL_CE_SOC(DLL_CT10)
DLL_CE_PRES
DLL_CE_ASND(DLL_CT8)
DLL_CE_SOA
DLL_CE_SOC_TIMEOUT(DLL_CT2)
DLL_CE_PREQ

DLL_CS_
WAIT_PREQ(DLL_CT9)
DLL_CE_SOC(DLL_CT7)
DLL_CE_PRES
DLL_CE_SOC
DLL_CE_ASND

Fig. 30.

CN cycle state machine (DLL_CS), valid for NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, NMT_CS states NMT_CS_OPERATIONAL

In the NMT_CS_OPERATIONAL and NMT_CS_READY_TO_OPERATE states, there are threemandatory frames for a non-multiplexed node, which shall occur each cycle in the specified order:
SoC, PReq and SoA. If a node is accessed multiplexed, only the SoC and SoA frames are mandatoryfor every cycle. The PReq frame is only mandatory in the multiplexed cycle the node was configuredfor.
In the NMT_CS_PRE_OPERATIONAL_2 state, there are two mandatory frames, which shall occur
each cycle in the order SoC and SoA. The PReq frame may occur between SoC and SoA.
In the NMT_CS_PRE_OPERATIONAL_2 state the timeout detection of the SoC is disabled because
the node may not be configured yet.
The cycle state machine keeps track of all receive frames to detect frame losses. Receive frames shallbe accepted by the CN independent of the current cycle state machine state.

4.2.4.5.4.2.1 Transitions
DLL_CT1

DLL_CT2

DLL_CE_SOC [ ] / synchronise the start of cycle and generate a SoC trigger to the application
The occurrence of the SoC event indicates the beginning of a new POWERLINK cycle. The
asynchronous phase of the previous cycle ends and the isochronous phase of the next cycle begins.
DLL_CE_PREQ [ ] / Process the PReq frame and send a PRes frame
The PReq event occurs within the isochronous phase of communication.

EPSG DS 301 V1.5.1-62-

DLL_CT3

DLL_CE_SOA [ ] / process SoA, if allowed send an ASnd frame or a non POWERLINK frame
DLL_CE_SOC_TIMEOUT [CN NMT state != NMT_CS_PRE_OPERATIONAL_2] / Synchronise to thenext SoC, report error DLL_CEV_LOSS_SOC and DLL_CEV_LOSS_SOA
DLL_CE_PREQ [ ] / accept the PReq frame and send a PRes frame, report error
DLL_CEV_LOSS_SOC and DLL_CEV_LOSS_SOAThe DLL_CE_SOA event denotes the end of the isochronous phase and the beginning of theasynchronous phase of the current cycle. If the SoA frame includes an invitation to the CN, the CN
may respond with one valid frame.
The occurrence of a DLL_CE_PREQ signifies that the expected SoA and SoC frames were lost. The
DLL Error Handling shall be notified.
In case of a DLL_CE_SOC_TIMEOUT event happened in NMT_CS_READY_TO_OPERATE or
NMT_CS_OPERATIONAL, SoA and SoC frames may have been lost. The DLL Error Handling shallbe notified.
DLL_CT4 DLL_CE_ASND [ ] / process frame
DLL_CE_PREQ [ ] / respond with PRes frame, report error DLL_CEV_LOSS_SOC
DLL_CE_PRES [ ] / report error DLL_CEV_LOSS_SOC
DLL_CE_SOA [ ] / report error DLL_CEV_LOSS_SOC
DLL_CE_SOC_TIMEOUT [CN NMT state != NMT_CS_PRE_OPERATIONAL_2] / report error
DLL_CEV_LOSS_SOC
If an ASnd frame has been received it shall be processed. The state shall not be changed. Although
only one asynchronous frame per cycle is allowed, the state machine of the CN does not limit theamount of received frames within the asynchronous phase of the cycle.
If a SoA, PReq or PRes frame is received, there may be a loss of a SoC frame in between. The DLL
Error Handling shall be notified with the error DLL_CEV_LOSS_SOC. This event shall be triggered
once per cycle only.
In case of a DLL_CE_SOC_TIMEOUT event happened in NMT_CS_READY_TO_OPERATE or
NMT_CS_OPERATIONAL, SoA and SoC frames may have been lost. The DLL Error Handling shallbe notified.
If a PReq frame was received, the incoming data may be ignored and a PRes frame shall be sent.
DLL_CT7 DLL_CE_PRES [ ] / process PRes frames (cross traffic)
DLL_CE_SOC [ ] / synchronise to the cycle begin, report error DLL_CEV_LOSS_SOA
DLL_CE_ASND [ ] / report error DLL_CEV_LOSS_SOA
If a PRes frame of another CN was received (cross traffic), the PRes frame shall be processed (ifconfigured to do so). The CN waits for either a PRes from another CN (cross traffic) or a PReq frame.
The reaction to a SoC frame is state independent. The state machine synchronises to the start of a
new cycle.
ASnd frames and non POWERLINK frames shall be processed during the isochronous phase.
DLL_CT8 DLL_CE_SOA [CN NMT state = NMT_CS_STOPPED] / process SoA, if invited, transmit a legal
Ethernet frame
DLL_CE_SOA [CN = multiplexed] / process SoA; if invited, transmit a legal Ethernet frame
DLL_CE_SOA [CN != multiplexed] / process SoA; if invited, transmit a legal Ethernet frame,
additionally report error DLL_CEV_LOSS_PREQ
DLL_CE_SOC_TIMEOUT [CN NMT state != NMT_CS_PRE_OPERATIONAL_2] / Synchronise on
the next SoC, report error DLL_CEV_LOSS_SOC and DLL_CEV_LOSS_SOA
If the CN is in the NMT_CS_OPERATIONAL or NMT_CS_READY_TO_OPERATE the CN willassume a LOSS_OF_PREQ if the number of cycles since the last PReq is greater than that
expected. (1 for non multiplexed CNs, n for multiplexed CNs where n is
NMT_CycleTiming_REC.MultiplCycleCnt_U8)
In case of a DLL_CE_SOC_TIMEOUT event happened in NMT_CS_READY_TO_OPERATE;
NMT_CS_OPERATIONAL or NMT_CS_STOPPED, SoA and SoC frames may have been lost. On
non-stopped and non-multiplexed nodes or if a multiplexed node should have been requested thiscycle, the PRes frame was additionally lost. The DLL Error Handling shall be notified.
DLL_CT9 DLL_CE_SOC [ ] / synchronise on the SoC, report error DLL_CEV_LOSS_SOA
The reaction on reception of a SoC is independent of the NMT state, the state machine assumes thatan expected frame was lost and (re-)synchronises on the SoC.
DLL_CT10 DLL_CE_PRES [ ] / process PRes frames (cross traffic)
DLL_CE_ASND [ ] / report error DLL_CEV_LOSS_SOAThe CN may process PRes of other CNs.
ASnd frames and non POWERLINK frames shall be accepted during the isochronous phase.

Transitions for CN cycle state machine, states NMT_CS_OPERATIONAL,
NMT_CS_PRE_OPERATIONAL_2, NMT_CS_READY_TO_OPERATE
Common issues:

EPSG DS 301 V1.5.1

-63-

•

Loss of frames will be detected when an unexpected frame was received or the
DLL_CE_SOC_TIMEOUT occurs.

•

The Cycle State machine informs the NMT_CS of an error, which will then be processed by the
NMT_CS (see 7.1.4).

•

DLL_CEV_LOSS_SOA and DLL_CEV_LOSS_PREQ are optional and may be omitted if notsupported by the DLL Error Handling•

The DLL error handling shall be notified only once for every real error event although the sameerror may be detected more often in a cycle.
e.g. DLL_CEV_LOSS_SOC in DLL_CT4

4.2.4.6

MN Cycle State Machine

4.2.4.6.1

Overview

The cycle state machine of the MN (DLL_MS) shall manage the communication within a POWERLINK
cycle.
The DLL_MS generates the flow of the frames during a POWERLINK cycle and monitors the reactionof the CNs. The flow order is NMT_MS state dependent (see 4.2.4.6.4 ).
Usually the CNs are synchronised by the reception of the SoC. This means the most significant
parameter for the synchronisation of the POWERLINK network is the timing accuracy of the event
DLL_ME_SOC_TRIG.
If an error in the communication is detected by the DLL_MS, an error event to DLL Error Handling will
be generated.

4.2.4.6.2•

States

DLL_MS_NON_CYCLIC
This state means that the cyclic communication is not started yet or was stopped by the
NMT_MS state machine (NMT state NMT_MS_PRE_OPERATIONAL_1). The state machine
waits here until the NMT state changes to NMT_MS_PRE_OPERATIONAL_2. It depends onthe current NMT state, which events will be processed and which will be ignored.

•

DLL_MS_WAIT_SOC_TRIG
If the communication of the cycle is finished, the state machine remains in this state until thenext cycle begins with a DLL_ME_SOC_TRIG.

•

DLL_MS_WAIT_PRES
After the sending of the PReq frame the state machine waits in this state for a response. The
waiting time is limited by a timeout.

•

DLL_MS_WAIT_ASND
If a SoA with an Invite is sent, the state machine waits in this state until the asynchronous phaseends with the event DLL_ME_SOC_TRIG.
In DLL_MS_NON_CYCLIC the event DLL_ME_SOA_TRIG shall be generated instead of
DLL_ME_SOC_TRIG.
If a ASnd is expected and the timeout NMT_MNCycleTiming_REC.AsyncSlotTimeout_U32
occurs, the error DLL_MEV_SOA_TIMEOUT shall be generated.

•

DLL_MS_WAIT_SOA
If a SoA with an Invite is sent that is not to be answered, the MN waits in this state until the
timeout of the async phase elapsed or any Ethernet frame was received before the next
reduced POWERLINK cycle starts.

4.2.4.6.3

EventsThe DLL_MS is triggered by events which are generated by an event handler. The DLL_MS has aninterface to:•the hardware•

the NMT state machineEPSG DS 301 V1.5.1-64-

The event handler should serialize the events (it’s possible that a timeout occurs simultaneously with
an Ethernet frame receiving). The implementation of the interface to the hardware is out of the scopeof this specification.
•

DLL_ME_PRES
This event signifies that a PRes frame was received.

•

DLL_ME_PRES_TIMEOUTThis event is produced when the PRes frame was not (or not completely) received within apreconfigured time.

•

DLL_ME_ASND
This event means that an ASnd frame or an non POWERLINK frame was received.

•

DLL_ME_ASND_TIMEOUTThis event is produced when the ASnd frame was not (or not completely) received within apreconfigured time.

•

DLL_ME_SOC_TRIG
This event triggers emission of the SoC frame and starts a new POWERLINK cycle. The timing
accuracy determines the synchronisation accuracy of the POWERLINK network.

•

DLL_ME_SOA_TRIG
This event means that a new reduced POWERLINK cycle shall start. The event can either be
generated cyclically or directly after the reception of a requested ASnd message to continue thereduced POWERLINK cycle as fast as possible.

4.2.4.6.4

Usage of the NMT_MS state by the DLL_MS

The state of the NMT_MS represents the network state and is used as a condition in some transitionsof the DLL_MS. Relevant DLL_MS transitions for a single NMT state could be filtered out.
A notation comment:
The transitions of DLL_MS could be displayed within a single diagram where the states of the
NMT_MS are conditions for the transitions. Because of comprehension and clarity purposes, therelevant transitions of single NMT_MS states are filtered out and displayed within an own diagram as
an “operation mode” of the DLL_MS.

4.2.4.6.4.1

State NMT_GS_INITIALISATION, NMT_MS_NOT_ACTIVE

In these states the MN cycle state machine is not active. This means, prior to the initial transition to
DLL_MS_NON_CYCLIC its state does not influence the reaction of the MN. The reactions are definedby the state of the NMT_MS.

4.2.4.6.4.2

NMT_MS_BASIC_ETHERNET

In this state the cycle state machine is not active. This means, prior to the initial transition to
DLL_MS_NON_CYCLIC its state does not influence the reaction of the MN. The reactions are definedby the state of the NMT_MS.

4.2.4.6.4.3

State NMT_MS_PRE_OPERATIONAL_1

In the NMT_MS_PRE_OPERATIONAL_1 state, the cycle state machine of the MN generates the
Reduced POWERLINK Cycle and observes the behaviour of the CNs. Error handling is described inchapter 4.6. The DLL_MS is in the DLL_MS_NON_CYCLIC mode.

EPSG DS 301 V1.5.1-65-

DLL_MS_NON_CYCLIC(DLL_MT11)
DLL_ME_SOA_TRIG

DLL_MS_
WAIT_ASND

DLL_MS_
WAIT_SOA(DLL_MT10)
DLL_ME_SOA_TRIG

Fig. 31.

(DLL_MT12)
DLL_ME_ASND_TIMEOUTDLL_ME_SOA_TRIG(DLL_MT13)
DLL_ME_ASND_TIMEOUTDLL_ME_SOA_TRIG

MN cycle state machine, state NMT_MS_PRE_OPERATIONAL_1

4.2.4.6.4.3.1 Transitions
DLL_MT10

DLL_MT11

DLL_MT12

DLL_MT13

DLL_ME_SOA_TRIG [async_in != 0 & no resp. expected] / send SoA with Invite
DLL_ME_SOA_TRIG [async_in = 0 & async_out != 0] / send SoA with Invite to MN and send ASndor non POWERLINK frame
DLL_ME_SOA_TRIG [async_in = 0 & async_out = 0] / send SoA
If there is an asynchronous transmission request from a CN, the MN sends a SoA message with
Invite. The next reduced POWERLINK cycle shall start after the asynchronous slot timeout elapsed
or any frame is received.
If there is outgoing asynchronous MN communication to be done in the current cycle, the MN sends
this frame directly after the SoA frame with an Invite to the MN itself. The next reduced
POWERLINK cycle shall start after transmission of the ASnd or non POWERLINK frame.
If there is no Invite for a CN and no ASnd or non POWERLINK frame from MN the next
DLL_ME_SOA_TRIG shall be generated after the asynchronous slot timeout.
DLL_ME_SOA_TRIG [async_in != 0 & resp. expected] / send SoA with Invite
After sending the SoA invite message to the CN, the MN changes to the state
DLL_MS_WAIT_ASND to detect transmission timeouts.
DLL_ME_SOA_TRIG | DLL_ME_ASND_TIMEOUT [async_in = 0] / send SoA, ASnd if available
DLL_ME_SOA_TRIG | DLL_ME_ASND_TIMEOUT [async_in != 0 & no resp. expected] / send SoA
with Invite
The waiting time ends with either a DLL_ME_SOA_TRIG or a DLL_ME_ASND_TIMEOUT(configurable via NMT_MNCycleTiming_REC.AsyncSlotTimeout_U32). If a certain CN shall be
invited, the MN sends a SoA containing an invite for the node. If there is no CN to be invited, the
MN sends a SoA. If there is outgoing asynchronous communication to be done in the current cycle,
the MN sends this frame after the SoA frame. Afterwards the state changes to
DLL_MS_WAIT_SOA.
The error event DLL_MEV_ASND_TIMEOUT shall be generated.
DLL_ME_SOA_TRIG | DLL_ME_ASND_TIMEOUT [async_in != 0 & resp. expected] / send SoA
with Invite, report error DLL_MEV_ASND_TIMEOUTA SoA message containing an Invite for a CN is transmitted. The MN stays in the state
MS_WAIT_ASND as an answer of the CN is expected.
The timeout event DLL_ME_ASND_TIMEOUT (configurable via
NMT_MNCycleTiming_REC.AsyncSlotTimeout_U32) shall generate DLL_MEV_ASND_TIMEOUT.

Transitions for MN cycle state machine, state NMT_MS_PRE_OPERATIONAL_1
Abbreviations used in the transition table:•„no resp. expected" means that there is no answer expected upon the async invite of the MN(e.g. unicast message exchange)•„async_in != 0" means that an invite must be sent in this cycle and an ASnd or a non
POWERLINK frame could be received.

•“async_out != 0” means that an ASnd must be send in this cycle after a SoA was sent.
Common issues:•

DLL_MEV_ASND_TIMEOUT is optional and may be omitted if not supported by the DLL Error
Handling•

If a StatusRequest was sent and the asynchronous slot time expires without receiving a
StatusResponse frame the DLL Error Handling will be notified with the error
DLL_MEV_LOSS_STATUSRESPONSE.

EPSG DS 301 V1.5.1

4.2.4.6.4.4-66-

State NMT_MS_OPERATIONAL,
NMT_MS_READY_TO_OPERATE and
NMT_MS_PRE_OPERATIONAL_2

In the NMT_MS_OPERATIONAL, NMT_MS_READY_TO_OPERATE and
NMT_MS_PRE_OPERATIONAL_2 state, the cycle state machine of the MN generates the
POWERLINK Cycle and observes the behaviour of the CNs. Error handling is described in chapter
4.6.

DLL_MS_NON_CYCLIC(DLL_MT0)
DLL_ME_SOC_TRIG

DLL_MS_CYCLIC

DLL_MS_
WAIT_SOC_TRIG(DLL_MT7)
DLL_ME_SOC_TRIG(DLL_MT1)
DLL_ME_SOC_TRIG

DLL_MS_
WAIT_PRES(DLL_MT2)
DLL_ME_PRES
DLL_ME_PRES_TIMEOUT

Fig. 32.

(DLL_MT3)
DLL_ME_PRES
DLL_ME_PRES_TIMEOUT(DLL_MT5)
DLL_ME_SOC_TRIG(DLL_MT4)
DLL_ME_PRES
DLL_ME_PRES_TIMEOUT(DLL_MT9)
DLL_ME_SOC_TRIG(DLL_MT6)
DLL_ME_SOC_TRIG

DLL_MS_
WAIT_ASND(DLL_MT8)
DLL_ME_SOC_TRIG
DLL_ME_ASND

MN cycle state machine, States NMT_MS_OPERATIONAL,
NMT_MS_READY_TO_OPERATE and NMT_MS_PRE_OPERATIONAL_2

4.2.4.6.4.4.1 Transitions
DLL_MT0

DLL_MT1

DLL_MT2

DLL_ME_SOC_TRIG [ ] / go to state DLL_MS_WAIT_SOC_TRIG
If the NMT state machine of the MN (NMT_MS) changes the mode to
NMT_MS_PRE_OPERATIONAL_2 the DLL_MS shall start the cycle timer (value configurable by
NMT_CycleLen_U32), which generates the DLL_ME_SOC_TRIG. The DLL_MS shall prepare thesystem for the start of the first cycle.
DLL_ME_SOC_TRIG [ isochr != 0 ] / send SoC, PReq
Immediately after DLL_ME_SOC_TRIG event occurred a SoC frame is sent, the communication with
the NMT state machine will be done. If there are isochronous frames to send, the first PReq will besent and a timer will be started to observe the response time (configurable via
NMT_MNCNPResTimeout_AU32[Node ID]).
DLL_ME_PRES [ isochr != 0 ] / send next PReq
DLL_ME_PRES_TIMEOUT [ isochr != 0 ] / send next PReq, report error DLL_MEV_LOSS_PRES
The waiting time ends with either a DLL_ME_PRES or a DLL_ME_PRES_TIMEOUT. The MN sends
the next PReq if more frames in the isochronous queue exist. The state does not change.

EPSG DS 301 V1.5.1
DLL_MT3

DLL_MT4

DLL_MT5

DLL_MT6

DLL_MT7

DLL_MT8

DLL_MT9-67-

DLL_ME_PRES [ isochr = 0 & async_in = 0] / send PRes [isochr_out != 0], SoA and ASnd [async_out!= 0]
DLL_ME_PRES_TIMEOUT [ isochr = 0 & async_in = 0] / send PRes [isochr_out != 0], SoA and ASnd
[async_out != 0], report error DLL_MEV_LOSS_PRES
The isochronous phase ends with either a DLL_ME_PRES or a DLL_ME_PRES_TIMEOUT(configurable via NMT_MNCNPResTimeout_AU32[Node ID]). If there is no more communication to
be done (neither isochronous nor asynchronous), the MN sends a SoA frame and changes the state
to DLL_MS_WAIT_SOC_TRIG.
If there is outgoing asynchronous communication to be done in the current cycle, the MN sends thisframe after the SoA.
DLL_ME_PRES [ isochr = 0 & async_in != 0] / send PRes [isochr_out != 0] and SoA with Invite
DLL_ME_PRES_TIMEOUT [ isochr = 0 & async_in != 0] / send PRes [isochr_out != 0] and SoA with
Invite, report error DLL_MEV_LOSS_PRES
The isochronous phase ends with either a DLL_ME_PRES or a DLL_ME_PRES_TIMEOUT(configurable via NMT_MNCNPResTimeout_AU32[Node ID]).
If the MN is configured to send a PRes this frame shall be sent before the SoA.
If the scheduled asynchronous communication for the current cycle is directed from the CN to the MN
or another CN, an invite within the SoA frame will be send.
DLL_ME_SOC_TRIG [ isochr = 0 & async_in = 0] / send SoC, PRes [isochr_out != 0], SoA and ASnd
[async_out != 0]
Immediately after the DLL_ME_SOC_TRIG event (value configurable via NMT_CycleLen_U32) a
SoC frame will be sent, the communication with the NMT state machine will be done. If there is nocommunication to be done, then a SoA frame is additionally sent. The state does not change.
If the MN is configured to send a PRes this frame shall be sent before the SoA.
If there is outgoing asynchronous communication to be done in the current cycle, the MN sends thisframe after the SoA frame and changes the state to DLL_MS_WAIT_SOC_TRIG.
DLL_ME_SOC_TRIG [ isochr = 0 & async_in != 0 ] / send SoC, PRes [isochr_out != 0] and SoA with
InviteImmediately after the DLL_ME_SOC_TRIG (value configurable via NMT_CycleLen_U32) a SoC
frame will be sent. Then, the communication with the NMT state machine will be done.
If the MN is configured to send a PRes this frame shall be sent before the SoA.
If there are only asynchronous frames to send, the SoA frame will be send. If the asynchronous
communication is directed to a CN, an ASnd frame will be sent additionaly.
DLL_ME_SOC_TRIG [ isochr = 0 & async_in = 0] / send SoC, PRes [isochr_out != 0], SoA and ASnd
[async_out != 0]
Immediately after the DLL_ME_SOC_TRIG event a SoC frame will be sent, the communication with
the NMT state machine will be done.
If the MN is configured to send a PRes this frame shall be sent before the SoA.
If there is no communication to be done, then a SoA frame is additionally sent. The state does notchange. If there is outgoing asynchronous communication to be done in the current cycle, the MN
sends this frame after the SoA.
DLL_ME_ASND [ ] / process the frame
DLL_ME_SOC_TRIG [ isochr = 0 & async_in != 0 ] / send SoC and SoA with Invite
Immediately after the DLL_ME_SOC_TRIG a SoC frame will be sent. Then, the communication with
the NMT state machine will be done. If there are only asynchronous frames to send, the SoA frame
will be send. If the asynchronous communication is directed to a CN, an ASnd frame will be sent
additionally.
DLL_ME_SOC_TRIG [ isochr != 0 ] / send SoC and PReq
Immediately after DLL_ME_SOC_TRIG event occurred (value configurable via NMT_CycleLen_U32)
a SoC frame is sent, the communication with the NMT state machine will be done. If there areisochronous frames to send, the first PReq will be sent and a timer will be started to observe theresponse time (configurable via NMT_MNCNPResTimeout_AU32[Node ID]).

Transitions for MN cycle state machine, states NMT_MS_OPERATIONAL,
NMT_MS_READY_TO_OPERATE and NMT_MS_PRE_OPERATIONAL_2
Abbreviations used in the transition table:•„isochr != 0" means that there are frames in the isochronous list, which must be send during thecurrent cycle.

•„isochr_out != 0” means that the MN is configured to send a PRes•

„async_in != 0" means that an invite must be sent in this cycle and an ASnd or a non
POWERLINK frame could be received.

EPSG DS 301 V1.5.1-68-•“async_out != 0” means that an ASnd must be send in this cycle after a SoA was sent.
The reaction on unexpected events is not described in the above figures and tables because of clarity
purposes. A general statement for these events can be given:•

The unexpected frame types and unexpected sender shall be accepted. The state does notchange. The PRes frames shall be passed to the NMT state machine, which may analyse thisframes (and e.g. remove the corresponding CN from the communication). The state machine
does not react in any other way to this event.

•If the DLL_MS receives frames, which can be sent by another MN only (SoC, SoA, PReq), it
shall notify the NMT state machine and the DLL Error Handling.

•

If an unexpected internal event (e.g. timeout) occurs, an internal error will be assumed and the
NMT_MS will be notified.

•

It could happen that the DLL_ME_SOC_TRIG occurs in states where it was not expected or
during transmission or reception of Ethernet frames. (e.g. malconfiguration of PRes timeouts).
In this case the DLL Error Handling will be notified with the error DLL_MEV_CYCLE_EXCEED
If a StatusRequest was sent and the asynchronous slot time expires without receiving a
StatusResponse frame the DLL Error Handling will be notified with the error
DLL_MEV_LOSS_STATUSRESPONSE.

4.2.5

Recognizing Active Nodes

The MN shall be configured with a list of all nodes on the network.
All configured nodes shall be marked as inactive when the MN boots. Configured but inactive CNs
shall be periodically accessed by an IdentRequest, a special form of the SoA frame. When a CN
receives an IdentRequest addressed to itself, it shall return an IdentResponse, a special form of an
ASnd frame, in the same asynchronous phase.
The CN shall be marked as active if the MN receives an IdentResponse from the CN. An active CN
may take part in the isochronous data transfer, e.g. it may be accessed via a PReq.

4.3

Basic Ethernet Mode

Network communication behaves according to the rules of the Legacy Ethernet (IEEE 802.3). The
network medium is accessed according to CSMA/CD.
The network communication is collision-prone and non-deterministic.
In the Basic Ethernet Mode any protocol on top of Legacy Ethernet can be used. Data between thenodes are preferentially exchanged via UDP/IP and TCP/IP. The large extension of the maximum
topology of an Ethernet POWERLINK Network conflicts with the topology rules of IEEE 802.3. Due tothis fact, CSMA/CD might work poorly in large POWERLINK networks. Higher layer protocols shall beapplied to handle communication errors caused by collisions unresolved by CSMA/CD.
POWERLINK nodes shouldn’t operate in Basic Ethernet Mode, when the node is part of a automation
system. Basic Ethernet Mode is provided for point to point configurations, to be used for node setup
and service purpose only.

EPSG DS 301 V1.5.1

4.4

-69-

MAC Addressing

A POWERLINK node must support unicast, multicast and broadcast Ethernet MAC addressing inaccordance with IEEE802.3.

4.4.1

MAC Unicast

The high-order bit of the MAC address is 0 for ordinary addresses (unicast). The unicast addresses
used for POWERLINK shall be globally unique, or at least unique within the POWERLINK segment.

4.4.2

MAC Multicast

For group addresses the high-order bit of the MAC address is 1. Group addresses allow multiple
nodes to listen to a single address. When a frame is sent to a group address, all the nodes registered
for this group address receive it. Sending to a group of nodes is called multicast.
The following MAC-multicast addresses shall be used:
MAC-Multicast address

Start of Cycle (SoC)
PollResponse (PRes)
Start of Asynchronous (SoA)
AsynchronousSend (ASnd)

C_DLL_MULTICAST_SOC
C_DLL_MULTICAST_PRES
C_DLL_MULTICAST_SOA
C_DLL_MULTICAST_ASND

Active Managing Node Indication (AMNI) used by EPSG DS302-A [1]

C_DLL_MULTICAST_AMNIAssigned multicast addresses

4.4.3

MAC Broadcast

The address consisting of all 1 bits is reserved for broadcast.

4.5

POWERLINK Addressing

Each POWERLINK node (MN, CN and Router) has a unique Node ID within a POWERLINK segment.
The number 240 is permanently assigned to the MN. A node set to 240 Node ID operates as the MN,
if the node has MN functionality. Devices with pure CN function cannot be assigned the Node ID 240.
POWERLINK Node IDs 1-239 may used for the CNs. Tab. 11 shows the POWERLINK Node ID
assignment and allowed CN access options for the POWERLINK Node ID intervals.
The POWERLINK Node ID is either configured by the application process or is set on the device (e.g.
using address switches).
The terms unicast, multicast and broadcast refer to POWERLINK addresses if not otherwise
mentioned. If the POWERLINK broadcast address is used, the frame shall be sent with the dedicated
MAC multicast address (see Tab. 10). If no MAC multicast address is assigned to this type of
POWERLINK frame the MAC broadcast address shall be used instead.
POWERLINK dummy node shall be used to transmit messages addressing none of the existing node.
POWERLINK dummy Node ID shall never by occupied by an existing node. No node shall expect
valid data from the POWERLINK dummy node.
The self addressing Node ID shall never be assigned to any node. It may be used only by PDO
mapping to indicate reception and evaluation of a PDO transporting PRes frame, transmitted by thereceiving node itself.
Diagnostic device shall be a default node, available without any configuration. It’s default access
options shall be optional and async only. By configuration isochronous operation may be declared.
A device may support less than the maximum number of regular CNs defined by this specification.
The number of supported regular CNs may be provided by the device description entry
D_NMT_MaxCNNumber_U8. The upper limit of the interval of POWERLINK Node IDs available forregular CNs may be reduced by the device description entry D_NMT_MaxCNNodeID_U8.
If only D_NMT_MaxCNNumber_U8 is provided the Node IDs may be selected from the complete
interval 1 .. 239. If D_NMT_MaxCNNodeID_U8 is additionally provided, valid regular CN Node IDs
shall be selected from the interval 1 .. D_NMT_MaxCNNodeID_U8.

EPSG DS 301 V1.5.1-70-

POWERLINK Node ID

Description

access options

Invalidregular POWERLINK
CNs
POWERLINK MNnono / mandatory / optional
isochronous / async only
mandatory
isochronous
no0
1 .. 239

C_ADR_INVALID240

C_ADR_MN_DEF_NODE_ID

241 .. 250

Reserved.
Used by EPSG DS302-A [1]

251

252
253
254
255

C_ADR_SELF_ADR_NODE_ID POWERLINK pseudo no
Node ID to be used bya node to address
itself
C_ADR_DUMMY_NODE_ID
POWERLINK dummy nonode
C_ADR_DIAG_DEF_NODE_ID Diagnostic device
optionalisochronous / async only
C_ADR_RT1_DEF_NODE_ID POWERLINK tono / mandatory / optional
legacy Ethernet Router isochronous
C_ADR_BROADCAST
POWERLINK
nobroadcast
POWERLINK Node ID assignment

4.6

Frame Structures

4.6.1

Integration with Ethernet

POWERLINK is a protocol residing on top of the standard 802.3 MAC layer.
POWERLINK messages shall be encapsulated in Ethernet II frames. The Ethernet Type (Ethertype)field shall be set to 88ABh.
The length of the frame shall be restricted to the configured size. Otherwise the cycle time could not
be guaranteed. Ethernet frames shall not be shorter than the specified minimum of 64 octets.

4.6.1.1

POWERLINK Frame

To be independent of the underlying protocol, POWERLINK defines its own addressing scheme (refer4.5) and header format.

4.6.1.1.1

POWERLINK Basic Frame

The POWERLINK Basic Frame format shall contain 5 fields:•

Reserved (1 bit)•

MessageType (7 bits)•

Destination node address (1 octet), POWERLINK addressing scheme (See 4.5)•

Source node address (1 octet), POWERLINK addressing scheme (See 4.5)•
Payload (n octets)
The POWERLINK Basic Frame format shall be encapsulated by the Ethernet II wrapper consisting of
14 octets of leading Ethernet header (Destination and Source MAC addresses, EtherType) and 4
octets of terminating CRC32 checksum.

EPSG DS 301 V1.5.1

Octet Offset 4

0 .. 56 .. 11
12 .. 13
14
15
16
17 .. nn+1 .. n+4

7

res

-71-

6

5

Bit Offset
4
3

entry defined by
2

1

0

Destination MAC Address
Source MAC Address
EtherType
MessageType
Destination
SourceData
CRC32

Ethernet type II

Ethernet
POWERLINK

Ethernet type II

C_DLL_MIN_PAYL_OFFSET+14 ≤ n ≤ C_DLL_MAX_PAYL_OFFSET+14

Ethernet POWERLINK frame structure
The Ethernet POWERLINK defined part of the Ethernet frame shall be regarded to be the
POWERLINK frame.
Field
Destination MAC
Address
Source MAC
Address
EtherType
MessageType
Destination
Source
Data

Abbr.
dmac

Description
MAC address of the addressed node(s)Valuesee 4.4

smac

MAC address of the transmitting node

see 4.4

etyp
mtyp
dest
src
data

C_DLL_ETHERTYPE_EPL
see Tab. 14
see 4.5
see 4.5
refer below

CRC32

crc

Ethernet message type
POWERLINK message type identification
POWERLINK Node ID of the addressed node(s)POWERLINK Node ID of the transmitting node
Data depending on MessageTypeshall be made up to C_DLL_MIN_PAYL_OFFSET bytes
by lower layer using padding bytes, if data length isbelow this limit
CRC32 checksum

Ethernet POWERLINK frame fields
The following message types shall be applied:
Message TypeID / Abbr.

MAC Transfer typeStart of Cycle
PollRequest
PollResponse
Start of Asynchronous
Asynchronous Send

SoC
PReq
PRes
SoA

Multicast
UnicastMulticastMulticastMulticast

ASnd

POWERLINK message types
Refer 4.4.2 for multicast addresses to be used by the respective message type.
Reserved values shall be set to 0.

4 Octet Offset refers to the start of the Ethernet frame.

EPSG DS 301 V1.5.1

4.6.1.1.2-72-

Start of Cycle (SoC)

Octet Offset 5

7

0
1
2
3
4
5
6 .. 13
14 .. 21
22 .. 45

res

MC
res

6

PS
res

5

Bit Offset
4
3

2

MessageType
Destination
Sourcereserved
res
res
res
res
res
NetTime / reserved
RelativeTime / reserved
reserved

1

0

res
res

res

SoC frame structure
SoC shall be transmitted using a multicast MAC address (See 4.4.2).
Field
MessageType
Destination
SourceMultiplexed
Cycle Completed
Prescaled Slot

NetTimeRelativeTime

Abbr
mtyp
dest
src
MC

Description
Value
POWERLINK message type identification
SoC
POWERLINK Node ID of the addressed node(s)C_ADR_BROADCAST
POWERLINK Node ID of the transmitting node
C_ADR_MN_DEF_NODE_ID
Flag: Shall be toggled when the final multiplexed cycle
has endedPS
Flag: Shall be toggled by the MN every n-th cycle (n isconfigurable by
NMT_CycleTiming_REC.Prescaler_U16).
This prescaled signal is useful for “slow“ nodes, which
can not react every cycle (The SoC reception shall besignalled to the application every n-th cycle).
time
MN may distribute the starting time of the POWERLINK
cycle. NetTime shall be of data type NETTIMENetTime transmission is optional. Support is indicatedby D_NMT_NetTime_BOOL. IEEE 1588 conform
distribution via NetTime is is indicated by
D_NMT_NetTimeIsRealTime_BOOL.
reltime MN may distribute a relative time, which is incremented
by the cycle time (NMT_CycleLen_U32) when a SoC is
generated. RelativeTime shall be set to 0 when NMT
state equals NMT_GS_INITIALISING. RelativeTime
shall be of data type UNSIGNED64. RelativeTime shallbe transmitted in µs.
RelativeTime transmission is optional. Support isindicated by D_NMT_RelativeTime_BOOL.

SoC frame data fields

5 Octet Offset refers to the start of the POWERLINK frame. Offset to the start of the Ethernet frame is

14 Octets.

EPSG DS 301 V1.5.1

4.6.1.1.3-73-

PollRequest (PReq)

Octet Offset 6

7

0
1
2
3
4
5
6
7
8 .. 910 .. n

res

res
res7

6

res
res8

5

MS

Bit Offset
4
3

2

1

0

MessageType
Destination
Source
res
res
res
EA
res
PDOVersionres
Size
Payload

res
res

RD

n ≤ C_DLL_MAX_PAYL_OFFSET

PReq frame structure
PReq shall be transmitted using the unicast MAC address of the CN (See 4.4.1).
Field
MessageType
Destination
SourceMultiplexed
Slot
Exception
Acknowledge
Ready

PDOVersion
Size
PayloadAbbr Description
mtyp POWERLINK message type identification
dest POWERLINK Node ID of the addressed node(s)src
POWERLINK Node ID of the transmitting node
MS Flag: Shall be set in PReq frames to CNs that are served
by a multiplexed timeslot
EA
Flag: Error signaling, refer 6.5.2

Value
PReq
CN Node ID
C_ADR_MN_DEF_NODE_ID

Flag: Shall be set if the transferred payload data are valid.
It shall be set by the application process of the MN. A CN
shall be allowed to accept data only when this bit is set.
pdov Shall indicate the version of the PDO encoding used by the
payload data, refer 6.4.2
0 ..
size Shall indicate the number of payload data octets.
C_DLL_ISOCHR_MAX_PAYL
plIsochronous payload data sent from the MN to theaddressed CN.
The lower layer shall be responsible for padding.
Payload to be used by PDO, refer 6.3.4
RD

PReq frame data fields
The PReq POWERLINK PDO message header consists of all components of the PReq Frame
besides the payload.

6 Octet Offset refers to the start of the POWERLINK frame. Offset to the start of the Ethernet frame is

14 Octets.
7 Used by EPSG DS302-A [1]8 Used by EPSG DS302-A [1]EPSG DS 301 V1.5.1

4.6.1.1.4-74-

PollResponse (PRes)

Octet Offset 9

7

0
1
2
3
4
5
6
7
8 .. 910 .. n

res

res
res10

6

res
res11

5

MS

Bit Offset
4
3

2

1

0

MessageType
Destination
SourceNMTState
EN
res
res
PR
PDOVersion
reserved
Size
Payload

res
RS

RD

n ≤ C_DLL_MAX_PAYL_OFFSET

PRes frame structure
PRes shall be transmitted using the multicast MAC address (See 4.4.2).
Field
MessageType
Destination
SourceNMTState

Abbr Description
mtyp POWERLINK message type identification
dest POWERLINK Node ID of the addressed nodes
src
POWERLINK Node ID of the transmitting nodestat Shall report the current status of the CN’s NMT statemachineMultiplexed Slot MS Flag: Shall be set in PRes frames from CNs that areserved by a multiplexed timeslot. Based on thisinformation, other CNs can identify that thetransmitting CN is served by a multiplexed slot
Exception New EN
Flag: Error signaling, refer 6.5.2
ReadyRD
Flag: Shall be set if the transferred payload data arevalid.
It shall be handled by the application process in the
CN. All other CNs and the MN shall be allowed toaccept data only if RD is set
PriorityPR
Flags: Shall indicate the priority of the frame in theasynchronous send queue with the highest priority.
(See 4.2.4.1.2.2)
RequestToSend RS
Flags: Shall indicate the number of pending frames inasynchronous send queue on the node. The value
C_DLL_MAX_RS shall indicate C_DLL_MAX_RS or
more requests, 0 shall indicate no pending requests
PDOVersion
pdov Shall indicate the version of the PDO encoding usedby the payload data, refer 6.4.2
Sizesize Shall indicate the number of payload data octets
Payloadpl
Isochronous payload data sent from the node to the
POWERLINK network.
The lower layer shall be responsible for padding.
Payload to be used by PDO, refer 6.3.4

Value
PRes
C_ADR_BROADCAST
CN Node ID

C_DLL_ASND_PRIO_NMTRQST,
C_DLL_ASND_PRIO_STD
0 - C_DLL_MAX_RS

0 .. C_DLL_ISOCHR_MAX_PAYL

PRes frame data fields
The PRes POWERLINK PDO message header consists of all components of the PRes Frame besides
the payload.
9 Octet Offset refers to the start of the POWERLINK frame. Offset to the start of the Ethernet frame is

14 Octets.
10 Used by EPSG DS302-A [1]
11 Used by EPSG DS302-A [1]EPSG DS 301 V1.5.1

4.6.1.1.5-75-

Start of Asynchronous (SoA)

Octet Offset 12

7

0
1
2
3
4
5
6
7
8
9 .. 45

res

res
res

Bit Offset
4
3

6

5

2

res
res

MessageType
Destination
SourceNMTState
res
res
res
EA/resres
RequestedServiceID
RequestedServiceTarget
EPLVersion
reserved

1

0

ER/resres

res

SoA frame structure
SoA shall be transmitted using the multicast MAC address 3 (See 4.4.2).
Field
MessageType
Destination
SourceNMTState

Abbr Description
Valuemtyp POWERLINK message type identification
SoA
dest POWERLINK Node ID of the addressed nodes
C_ADR_BROADCAST
src
POWERLINK Node ID of the transmitting node
C_ADR_MN_DEF_NODE_ID
stat Shall report the current status of the MN’s NMT statemachineFlag: Error signaling, refer 6.5.2 EA bit shall be valid only, if
EA
RequestedServiceID equals StatusRequest.
ER
Flag: Error signaling, refer 6.5.2 ER bit shall be valid only, if
RequestedServiceID equals StatusRequest.
svid Shall indicate the asynchronous service ID dedicated to the see Tab. 23
SoA and to the following asynchronous slot (refer below).
NO_SERVICE shall indicate that the asynchronous slot is
not assigned.
svtg Shall indicate the POWERLINK address of the node, whichis allowed to send.
C_ADR_INVALID shall indicate the asynchronous slot is
not assigned.
eplv Shall indicate the current POWERLINK Version of the MN(See Tab. 112).

Exception
Acknowledge
Exception
Reset
Requested
ServiceID

Requested
ServiceTarget

EPLVersion

SoA frame data fields
RequestedServiceID and RequestedServiceTarget are combined to a AsyncInvite Command.

4.6.1.1.5.1

RequestedServiceID s

The following values shall be used for the RequestedServiceID entry, indicating the granted
asynchronous service:

12 Octet Offset refers to the start of the POWERLINK frame. Offset to the start of the Ethernet frame is

14 Octets.

EPSG DS 301 V1.5.1
Description / ID
NoService /NO_SERVICE
IdentRequest /IDENT_REQUEST-76-

Comment
Shall be used if the asynchronous slot is not assigned to any node.
RequestedServiceTarget shall be C_ADR_INVALID.

Shall be used to identify inactive CNs and/or to query the identification data of a CN.
The addressed CN shall answer immediately after the reception of the SoA with thenode specific IdentRequest frame.The IdentResponse frame is based on the ASndframe.
StatusRequest /Shall be used to request the current status and detailed error information of a node.
Async-only CNs shall be cyclically queried by StatusRequest to supervise their status
STATUS_REQUEST
and to query their requests for the asynchronous slot. The addressed node shallanswer immediately after the reception of the SoA, with the node specific
StatusRequest frame. The StatusResponse frame is based on the ASnd frame.
NMTRequestInvite /Shall be used to assign the asynchronous slot to a node that has indicated a pending
NMT_REQUEST_INVITE NMTCommand / NMTRequest by a Request to Send (RS bit of PRes,
StatusResponse or IdentResponse) with the priority level PRIO_NMT_REQUEST. The
addressed node shall answer immediately after the reception of the SoA with the
NMTCommand / NMTRequest frame. The NMTCommand and NMTRequest frames
are based on the ASnd frame.
Manufacturer specific /Shall be used for manufacturer specific purposes.
MANUF_SVC_IDS
UnspecifiedInvite /Shall be used to assign the asynchronous slot to a node that has indicated a pendingtransmit request by a Request to Send (RS bit of PRes, StatusResponse or
UNSPECIFIED_INVITE
IdentResponse). The addressed node shall answer immediately after the reception of
the SoA, with any kind of a POWERLINK ASnd or a Legacy Ethernet frame.

Definition of the RequestedServiceID in the SoA frame
Assignment of the asynchronous slot to the MN itself shall be indicated in the same way asassignments to CNs.

4.6.1.1.6

Asynchronous Send (ASnd)

Octet Offset 13

7

0
1
2
3
4 .. nres

65

Bit Offset
4
3

2

1

0

MessageType
Destination
SourceServiceID
Payloadn ≤ C_DLL_MAX_PAYL_OFFSET

ASnd frame structure

The transmission of an ASnd frame by a node shall occur immediately after the transmission /reception of a SoA frame.
ASnd frames shall be transmitted using a unicast or multicast MAC address (See 4.4). Received ASndframes having a unicast, multicast or broadcast MAC address shall be accepted.
Field
MessageType
Destination
SourceServiceID
PayloadAbbr. Description
mtyp POWERLINK message type identification
dest POWERLINK Node ID of the addressed node(s)src
POWERLINK Node ID of the transmitting node
svid Shall indicate the service ID dedicated to the asynchronous slot
plShall contain data, that are specific for the current ServiceID

Value
ASnd

see Tab. 26

ASnd frame data fields

4.6.1.1.6.1

ServiceID values

The following values shall be used for the ServiceID entry:
13 Octet Offset refers to the start of the POWERLINK frame. Offset to the start of the Ethernet frame is

14 Octets.

EPSG DS 301 V1.5.1
Description / ID
IdentResponse / IDENT_RESPONSE
StatusResponse / STATUS_RESPONSE
NMTRequest / NMT_REQUESTNMTCommand / NMT_COMMAND
SDO / SDO
Manufacturer specific / MANUF_SVC_IDS-77-

Comment
Shall be issued by a node that received an IdentRequest via SoA.
Shall be issued by a node that received a StatusRequest via SoA.
Shall be issued by a CN that received a NMTRequestInvite via SoA.
Shall be issued by the MN upon an internal request or upon an
external request via NMTRequest.
May be issued by a CN that received an UnspecifiedInvite via SoA
to indicate SDO transmission via ASnd.
Shall be used for manufacturer specifc purposes.

ServiceID values in the ASnd frame
Service IDs not listed by Tab. 26 are reserved.

4.6.1.2

Non-POWERLINK Frames

Non-POWERLINK frames may be transmitted in accordance with the specifications of any Legacy
Ethernet protocol. Non-POWERLINK frame transmission is allowed by the MN if the asynchronous
slot is requested by a node..
Refer 5.1 for special requirements to IP (non-POWERLINK) frames.

4.6.1.3

Transfer Protection

Transfer disturbances shall be detected by the Ethernet CRC32.

4.7

Error Handling Data Link Layer (DLL)

The error handling on the data link layer forms the basis for diagnosis. Often the real error source canbe detected only by analysing/interpreting of multiple error symptoms on multiple nodes. Dependingon the error symptom / error source the nodes have to react on different layers. The error handlingshould be simple and easy to implement.

4.7.1

Possible Error Sources and Error Symptoms

The following error sources are handled by the MN and the CN. Details are explained in the following
sections.
••

Physical layer error sources•

Loss of link (no link condition – port of Ethernet controller)•

Incorrect physical Ethernet operating modes (10 Mbit/s or full duplex)•

Transmission Errors detected by CRC errors•

Rx buffer overflow•

Tx buffer underrun

POWERLINK Data Link Layer error symptoms•

Loss of frame•

SoC-Frame/ SoA-Frame•

PReq / PRes Frame•

Collisions•

Cycle Time exceeded•

POWERLINK Address Conflict•

Multiple Managing Nodes•
Timing Violation (late Response)
Error recognition strongly depends of the device’s hardware and software implementation. Device
implementation should be close to this specification but some of the optional error classes listed by thefollowing paragraphs may not be supported. Support shall be indicated by the respective device
description entry.

EPSG DS 301 V1.5.1

Error Handling Table for CN
DLL Local Handling

Error Codes

NMT Local Handling

These are considered
to be error sources

E_DLL_LOSS_OF_LINK
E_DLL_BAD_PHYS_MODE

Logging in Error History
Logging in Error History

E_DLL_MAC_BUFFER

NMT_GT6
Internal Communication Error(handling of internal SW errors)
Logging in Error History
NMT_CT11, Error Condition
Logging in Error History
NMT_GT6
Internal Communication Error(handling of internal SW errors)
Logging in Error History
NMT_GT6
Internal Communication Error(handling of internal SW errors)
Logging in Error History
NMT_CT11, Error Condition
Logging in Error History
NMT_CT11, Error Condition
Logging in Error History
NMT_CT11, Error Condition
Logging in Error History
NMT_CT11, Error Condition
Logging in Error History

Direct Reaction

Cumulative Cnt

Error Symptoms
detected by theCNs

Threshold Cnt

4.7.2

-78-

Loss of link
Incorrect physicaloperating mode
Tx/Rx buffer
underrun / overflowoooCRC errormo

E_DLL_CRC_TH

Collisionoo

E_DLL_COLLISION_THoInvalid formatm

E_DLL_INVALID_FORMATo

E_DLL_JITTER_TH

SoC jitter out of
range
Loss of PReq

o

o

o

o

E_DLL_LOSS_PREQ_TH

Loss of SoAoo

E_DLL_LOSS_SOA_TH

Loss of SoC

mm

CN sends (PRes) the
E_DLL_LOSS_SOC_TH
last or actual values.
Invalid data shall not besent in any case.

CN error handling table
Remarks:•

Change of NMT state shall be signalled to all nodes (reason can be read at
ERR_History_ADOM)•In ERR_History_ADOM, all logging events shall be registered.

•

None of the described Error symptoms on the CN shall be signalled via emergency queue to the
MN.

•

Cumulative Cnt, Threshold Cntmmandatory (Counters: shall be implemented / Detection: shall be detected )ooptionally (Counters: may be implemented / Detection: may be detected )•Direct Reaction:ma direct Reaction on an error occurrence shall be proceeded either on the DLL statemachine or on the NMT state machineoa direct Reaction on an error occurrence may be proceeded either on the DLL statemachine or on the NMT state machineEPSG DS 301 V1.5.1

4.7.3

-79-

Error Handling Table for MN
DLL Local Handling

Error Codes

NMT Local Handling

These are considered
to be an error source

E_DLL_LOSS_OF_LINK
E_DLL_BAD_PHYS_MODE

Logging in Error History
Logging in Error History

E_DLL_MAC_BUFFER

NMT_GT6
Internal Communication Error(handling of internal SW errors)
Logging in Error History
NMT_MT6
Logging in Error History
NMT_GT6
Internal Communication Error(handling of internal SW errors)
Logging in Error History
Logging in Error History

Direct Reaction

Threshold Cnt

Cumulative Cnt

Error Symptoms

Loss of link
Incorrect physicaloperating mode
Tx/Rx buffer
underrun / overflowoooCRC errormo

E_DLL_CRC_TH

Collisionoo

E_DLL_COLLISION_THoCollisionmCommunicationsuspends for a
configurable numberof cycles .
Changes its state to:
DLL_MS_WAIT_SOC_TIME

E_DLL_COLLISION

Invalid formatms

E_DLL_INVALID_FORMAT

Multiple MNsoE_DLL_MULTIPLE_MN

POWERLINK
address conflict
Loss of PResms

E_DLL_ADDRESS_CONFLICT

o
s

m
s

E_DLL_LOSS_PRES_TH

Late PRes

o
s

o
s

E_DLL_LATE_PRES_TH

Loss of
StatusResponse

o
s

m
s

E_DLL_LOSS_STATUSRES_TH

Cycle time exceeded oo

E_DLL_CYCLE_EXCEED_TH

Cycle time exceededm

Skip next cycle

MN error handling table
Remarks:

E_DLL_CYCLE_EXCEED

Remove respective CN from
configuration, send NMT State
Command “NMTResetNode” torespective CN.
Logging in Error History
State !=NMT_MS_NOT_ACTIVE->
NMT_GT6 InternalCommunication Error
State =NMT_MS_NOT_ACTIVE ->reside in
NMT_MS_NOT_ACTIVE
Logging in Error History
Remove all involved CNs from
configuration
Remove respective CN from
configuration, send NMT State
Command NMTResetNode to
respective CN.
Logging in Error History
Remove respective CN from
configuration, send NMT State
Command NMTResetNode to
respective CN
Logging in Error History
Remove respective CN from
configuration, send NMT State
Command NMTResetNode to
respective CN.
Logging in Error History
NMT_MT6
Logging in Error History
Logging in Error HistoryEPSG DS 301 V1.5.1

-80-

•

Change of NMT state shall signalled to all nodes ( See Object ERR_History_ADOM)•In Object ERR_History_ADOM, all logging events shall be registered.

•

Cumulative Cnt, Threshold Cntmmandatory (Counters: shall be implemented / Detection: shall be detected )ooptionally (Counters: may be implemented / Detection: may be detected )s
per CN (Counters: per CN a Counter is used / Detection: Error shall be assigned to a CN)•

Direct Reaction:ma direct reaction on an error occurrence shall be proceeded either on the DLL statemachine or on the NMT state machineoa direct reaction on an error occurrence may be proceeded either on the DLL statemachine or on the NMT state machines
per CN (Reaction: per CN / Detection: Error shall be assigned to a CN)

4.7.4

Error Handling Registration

This section gives an overview of the error registration on the MN and on CNs. The figure below
shows all events that can occur and how the may get registered. On each node an Error History
exists, where the occurred error symptoms are stored.
NMT Layer State Machine
Managing Node

NMT Layer State Machine
Controlled NodeError Events

Error Events

Local MN Counter

Local CN Counter
Error History

DLL_MNLossOfLinkCumCnt_U32

DLL_CNCollisionThrCnt_U32

DLL_MNCRCErrroThrCnt_U32

DLL_CNCollisionCumCnt_U32

DLL_MNCRCErrroCumCnt_U32
DLL_CNLossSoCThrCnt_U32
DLL_CNLossSoCCumCnt_U32

DLL_MNCollisionThrCnt_U32
DLL_MNCollisionCumCnt_U32

DLL_CNLossSoAThrCnt_U32
DLL_MNCycTimeExceedThrCnt_U32
DLL_MNCycTimeExceedCumCnt_U32

Controlled Nodes

Error History

Counters per CN on the MN

DLL_CNLossSoACumCnt_U32
DLL_CNLossPReqThrCnt_U32
DLL_CNLossPReqCumCnt_U32

DLL_MNCNLatePollResThrCnt_U32
DLL MN Error Symptom
CYCLETIME EXEEDEDDLL_MNCNLatePollResCumCnt_U32

DLL_CNSoCJitterThrCnt_U32
DLL_CNSoCJitterCumCnt_U32

COLLISIONSLATE POLLRESPONSE
LOSS POLLRESPONSE

DLL_MNCNLossPRespCumCnt_U32
DLL_CNCRCErrroThrCnt_U32

DLL_MNCNLossPRespThrCnt_U32

DLL_CNCRCErrroCumCnt_U32

MULTIPLE MN
DLL_CNLossOfLinkCumCnt_U32
MULTIPLE POWERLINK ADRESSESFORMAT ERROR
Physical Layer Error souces

DLL CN Error Symptom

Physical Layer Error souces

LOSS OF LINKSOC JITTERRX BUFFER OVERFLOW

CRC ERROR

LOSS POLLREQUESTLOSS SOA

CRC ERRORRX BUFFER OVERFLOWLOSS OF LINKINCORRECT ETHERNET MODE

LOSS SOC

INCORRECT ETHERNET MODETX BUFFER UNDERRUNPACKET COLLISIONTX BUFFER UNDERRUN

Fig. 33.

Error registration

FORMAT ERROREPSG DS 301 V1.5.1

4.7.4.1-81-

Threshold counters
Trigger
ActionThresholdThresholdCounterError Symptom occured

Fig. 34.

Threshold counter

Every time an error symptom occurs the threshold counter shall be incremented by 8. After each cycle
without reoccurance of the error the counter shall be decremented by one (Threshold counter 8:1).
When the threshold value is reached (threshold counter ≥ threshold), it shall trigger an action and thethreshold counter shall be reset to 0.
All kinds of POWERLINK cycle, e.g. reduced and isochronous cycle, shall decrement thresholdcounters. Async-only and multiplexed nodes shall decrement at every cycle but not only to cycles
addressing them.
The threshold value shall be configurable.
Immediate error reaction shall be commanded by a threshold value of 1.
Threshold counting and error reaction may be deactivated by setting the threshold value to 0.
Threshold counter handling shall be performed on a per error source basis.

4.7.4.2

Cumulative Counter

The Cumulative counter shall be incremented by 1 every time an error symptom occurs. An overflow
may occur.
Cumulative counters shall not be reset by reset commands. An application may provide means toreset cumulative counters.

4.7.5

Physical Layer Error Sources

The data link layer uses the physical layer error sources for diagnosis of DLL communication error
symptoms.

4.7.5.1•

Loss of Link

Error source
The Loss of Link can occur if the connection is interrupted, e.g. wire breaks, somebody pulls out
the network cable or a hub in the POWERLINK network is defect.

•

Error recognition
Loss of Link is a late detected error source explaining the primary error detections. Whenever aloss of a frame or a timing violation on the Data Link Layer is detected, the MN resp. CN checks
the Physical Layer for a no link condition on the Ethernet MAC controller.
Recognition is optional.

•

Handling
If the Loss of Link is detected, it is logged in the Error History.
Loss of Link shall be reported regardless any error log triggered by the preceding primary error
detection.

EPSG DS 301 V1.5.1•-82-

Registration
Optionally a cumulative counter (DLL_MNLossOfLinkCum_U32, resp.
DLL_CNLossOfLinkCum_U32) is incremented.
History Entry Object ERR_History_ADOM:
Mode
3h4.7.5.2•

Profile002h

Error Code
E_DLL_LOSS_OF_LINK

Timestamp
XXXX

Additional Information

Incorrect physical Ethernet operating mode

Error source
During the initialisation the new node may check whether it is 100 Mbit/s half duplex Ethernet
operating mode. Otherwise timing requirements won’t be fulfilled. This situation may occur if
auto negotiation is used (not recommended, see Par. 3) and the communication partner is using
10 MBits (e.g. a Hub) or 100 MBit full duplex (e.g. a Switch).

•

Error recognition
Incorrect physical Ethernet operating mode is a late detected error source explaining the
primary error detections. Whenever a loss of a frame or a timing violation on the Data Link
Layer is detected, the MN resp. CN checks the Physical Layer for an incorrect physical Ethernet
operating mode on the Ethernet MAC controller. Every time, when one of the following error
symptoms occurs, it checks if the cause of the error symptom was an incorrect physical
ETHERNET operating mode.
Recognition is optional. Support shall be indicated by D_DLL_ErrBadPhysMode_BOOL.

•

Handling
If an incorrect physical Ethernet operating mode is detected, it is logged in the error history.
Incorrect physical Ethernet operating mode is late detected error source explaining the primaryerror detections specified by 4.7.6.2, 4.7.7.3.1, 4.7.7.3.2 and 4.7.7.3.3. It shall be reported
regardless any error log triggered by the preceding primary error detection.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h4.7.5.3•

Profile002h

Error Code
E_DLL_BAD_PHYS_MODE

Timestamp
XXXX

Additional Information

Rx MAC buffer overflow / Tx MAC buffer underrun

Error source
If the receive MAC buffer of a CN or MN overflows, it cannot receive frames for a while.
The transmit MAC buffer underrun error on the physical layer occurs; when the buffer becomes
empty during transmission.

•

Error recognition
Buffer overflow resp underrun is a late detected error source explaining the primary error
detections. Whenever a loss of a frame or a timing violation on the Data Link Layer is detected,
the MN resp. CN checks the Physical Layer for an Rx MAC buffer overflow or a TX MAC buffer
underrun on the Ethernet MAC controller.
Recognition is optional. Support shall be indicated by D_DLL_ErrMacBuffer_BOOL.

•

Handling
If a Buffer error is detected, it is logged in the error history and the NMT layer is notified. The
CN resp. MN NMT state machine handles this error source as an internal Communication Error(NMT_GT6) and changes its state to NMT_GS_RESET_COMMUNICATION.
It shall be reported regardless any error log triggered by the preceding primary error detection.

EPSG DS 301 V1.5.1•-83-

Registration
History Entry Object ERR_History_ADOM:
Mode
3h4.7.5.4•

Profile002h

Error Code
E_DLL_MAC_BUFFER

Timestamp
XXXX

Additional Information

Transmission / CRC Errors

Error source
Transmission errors are detected by hardware (CRC-Check) in the Ethernet-Controller.
Received frames containing CRC errors are simply discarded.

•

Error recognition
Every time a frame is lost, the node shall check if a CRC error has occurred.
A device may also detect CRC errors on unexpected frames.

•

Handling
If a CRC error is detected, it shall be logged in the error history.
Error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).
If the threshold counter DLL_MNCRCError_REC.ThresholdCnt_U32, resp.
DLL_CNCRCError_REC.ThresholdCnt_U32 violates the threshold
DLL_MNCRCError_REC.Threshold_U32 resp. DLL_CNCRCError_REC.Threshold_U32, theCN resp. MN NMT state machine shall handle this error source as an “error condition“(NMT_CT11 resp. NMT_MT6) and shall change it’s state to NMT_CS_PRE_OPERATIONAL_1
resp. NMT_MS_PRE_OPERATIONAL_1.
It’s not recommended to enable error reaction if unexpected frame CRC error recognition is
active.

•Registration
MN and CN shall operate a cumulative counter (DLL_MNCRCError_REC.CumulativeCnt_U32,
resp. DLL_CNCRCError_REC.CumulativeCnt_U32, see. 4.7.4.2).) and a threshold counter(DLL_MNCRCError_REC.ThresholdCnt_U32, resp.
DLL_CNCRCError_REC.ThresholdCnt_U32).
History Entry Object ERR_History_ADOM:
Mode
3h

4.7.6

Profile002h

Error Code
E_DLL_CRC_TH

Timestamp
XXXX

Additional Information

Communication Error Symptoms detected by the
MN

This section describes the error symptoms on the data link layer which are detected and handled by
the MN.

4.7.6.1

Timing Violation

4.7.6.1.1

Slot Time Exceeded

Certain timing constellations must be distinguished when a frame is received. The timing behaviour ofnodes shall be monitored, otherwise the entire cycle time can exceed.

EPSG DS 301 V1.5.1

Trans. Path
Delay MN

Max. Delay ofall Hubs x2

Start Timer-84-

Max. Line
Delay x 2

Max. Latencyof CN

Rcv. Path
Delay MN

NMT_MNCNPResTimeout_U32 [CNNodeID]
time

time

Poll Req.

Round Trip Delay

Expected
Response Length

Poll Req.

Round Trip Delay

Reserved Slot-Timex slot n

Fig. 35.

Expected
Response Length

Reserved Slot Time yslot n+1

Timeouts

The PRes frame of the CN must have been received completely before the slot timeout given by
NMT_MNCNPResTimeout_AU32[CN Node ID] expires. The violation of the slot time produces thesituations described below.

4.7.6.1.1.1

Case 1-2 Frame received in time

The behaviour is identical. The second case shows the latest acceptable time for the frame receipt.
The current slot timeout is switched off immediately after the frame is received.

4.7.6.1.1.2

Case 3 Loss of PRes: Frame not received

The Loss of a PRes frame is detected by the slot timeout.

4.7.6.1.1.3

Case 4-6 Late PRes: Frame received in foreign slot (alsocollisions)

The cases 4 - 6 have one fact in common: A frame is received, which does not belong to the current
slot. The worst case could lead to a violation of the cycle time. This kind of error can disturb the entire
power link communication. Only in case 4 and 6 a Late PRes error can be detected. In case 5 acollision occurs as a result of a Late PRes error.

EPSG DS 301 V1.5.1-85-

Start PollTimer

Frame received timeout

Poll Req. n

Expected
RespLenRound Trip Delay

Reserved Slot-Time x
slot nReserved Slot-Time yslot n+ 1
Receive
Event

Case 1. Frame received in time

Poll Req. n+1

Response
received

Send
Cmd

PollReq n+1

Receive
Event

Case 2. Frame received just in time

Send
Cmd

Response
received

Poll Req. n+1

Send
Cmd

Case 3. Loss of PollResponse: Frame not received

Poll Req. n+1

Send
Cmd

Case 4. Late PollResponse: Frame received in foreign slot
(carrier detected)

Receive
Event

Response
received

Poll Req. n+1

Send
Cmd

Receive
Event

Case 5. Late PollResponse:Frame received in foreign slot
(collision detected & retransmission)

Response
received
Send
Cmd

Case 6. Late PollResponse:Frame received in foreign slot
(no collision occured)Fig. 36.

Timing violation

4.7.6.2•

Loss of PRes

Error source
Following possible error sources could cause this error symptom:••

Physical error sources on the MN•

Transmission Error (CRC Error)•

Loss of link•

Rx Buffer overflow•

Tx Buffer underrun

Error symptoms on a CN in the POWERLINK network•

Frame Collision error symptom

Poll Req. n+1

Poll Req. n+1
Receive
Event
Poll Res.
nEPSG DS 301 V1.5.1

•

-86-

•

A CN, which response latency is higher than allowed.

•

A component of the network structure is defect.

•

Power failure on a CN

•

Etc.

Error recognition
If the slot timer expires, no frame was received during the reserved slot time. (See Slot Timeexceeded: Case 3).
Loss of PRes is detected by the MN cycle state machine and reported via error event
DLL_MEV_LOSS_PRES.

•

Handling
After detecting a CN’s Loss of PRes by the NMT_MNCNPResTimeout_AU32[CN Node ID], the
MN shall proceed with the PReq for the next CN (or SoA if the end is reached).
Error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).
If the threshold counter DLL_MNCNLossPResThrCnt_AU32[CN Node ID] violates the threshold
DLL_MNCNLossPResThreshold_AU32[CN Node ID], the MN NMT State machine shallconsider the CN inactive and shall remove it from the isochronous processing. Additionally it
shall send the command NMTResetNode to the respective CN. On this command the CN willchange its state (See 7.1.4). Whenever this error symptom is detected, the MN shall check for aphysical layer error source.
The error symptom shall be logged in the Error History every time the threshold value isreached.

•Registration
The MN shall operate a threshold counter array DLL_MNCNLossPResThrCnt_AU32 andoptionally a cumulative counter array DLL_MNCNLossPResCumCnt_AU32 (see. 4.7.4.2). CNs
are represented by the subindices of the arrays.
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

4.7.6.3•

Error Code
E_DLL_LOSS_PRES_TH

Timestamp
XXXX

Additional Information

Late PRes

Error source
Following possible error sources could cause this error symptom:••

Physical error sources on the MN•

Transmission Error (CRC Error)•

Loss of link•

Rx Buffer overflow•

Tx Buffer underrun

Error symptoms on a CN in the POWERLINK network••

Frame Collision error symptom•

A CN, which response latency is higher than allowed.

•

A component of the network structure is defect.

•

Power failure on a CN

•

Etc.

Error recognition
A Late PRes error symptom may be detected on the MN, when the carrier is busy while trying tosend the PReq frame (See Slot Time exceeded: Case 4) or when it receives a PRes frame froman unexpected CN (See Slot Time exceeded: Case 6).

EPSG DS 301 V1.5.1-87-

Error recognition shall be performed at NMT states NMT_MS_PRE_OPERATIONAL_2,
NMT_MS_READY_TO_OPERATE and NMT_MS_OPERATIONAL on isochronous CNs.
Recognition is optional.
•

Handling
After detecting a Late PRes error, the MN proceeds with the PReq for the next CN (or SoA if theend is reached).
Error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).
If the threshold counter DLL_MNCNLatePResThrCnt_AU32[CN Node ID] violates the threshold
DLL_MNCNLatePResThreshold_AU32[CN Node ID], the MN NMT State machine shallconsider the CN inactive and shall remove it from the isochronous processing. Additionally it
shall send the command NMTResetNode to the respective CN. On this command the CN willchange it’s state (See 7.1.4).
If a PRes frame, that does not belong to the current slot, is received, the frame shall berejected.
Whenever a Late PR error is detected, the MN shall check for a physical layer error source.
The error symptom shall be logged in the Error History every time the threshold value isreached•Registration
The MN shall operate a threshold counter array DLL_MNCNLatePResThrCnt_AU32 andoptionally a cumulative counter array DLL_MNCNLatePResCumCnt_AU32 (see. 4.7.4.2). CNs
are represented by the subindices of the arrays.
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

4.7.6.4•

Error Code
E_DLL_LATE_PRES_TH

Timestamp
XXXX

Additional Information

Cycle Time Exceeded

Error source
Following possible error sources could cause this error symptom:••

POWERLINK configuration failure•

A CN, which Response latency is higher than allowed.

•

A component of the network structure, which is defect.

•

Etc.

Error recognition
A cycle time violation situation is defined as: The POWERLINK network was busy up to a time
where a SoC should have been sent. If an ASnd frame or an Ethernet frame at the end of acycle is delayed, then it may cause a collision with the SoC frame or a delay of the SoC frame.
Cycle x

SoC

1

2

3

Cycle x + 1

SoAa

Late Response

Fig. 37.

SoC

Cycle x + 2

SoC

1

2

3

SoA

a

time
Delay of the SoC,
shall not be send

Cycle time exceeded

Error detection is performed by the MN cycle state machine and reported via error event
DLL_MEV_CYCLE_EXCEED.
To prevent cycle time exceed error the cycle shall be dimensioned for the worst case (with max
response times / timeouts).

EPSG DS 301 V1.5.1-88-

On line check may be done by verifying the remaining cycle time ≥ maximum async slot time(refer. DLL) before sending the SoA frame. No inviting SoA shall be transmitted if verification
failed.
•Handling
A cycle time violation is considered a configuration error, hence the default behaviour shall be tosuspend one cycle and to log the error symptom at the error history.
Optionally a threshold counter DLL_MNCycTimeExceed_REC.ThresholdCnt_U32 and acumulative counter DLL_MNCycTimeExceed_REC.CumulativeCnt_U32 may be operated.
Every time DLL_MNCycTimeExceed_REC.ThresholdCnt_U32 reaches the threshold
DLL_MNCycTimeExceed_REC.Threshold_U32 or, if no Threshold counter is implemented,
every time the error symptom occurs, the MN NMT state machine shall be notified. It shallhandle this error source as an “error condition“ (NMT_MT6) and shall change it’s state to
NMT_MS_PRE_OPERATIONAL_1.
Every error event shall be logged at the error history by E_DLL_CYCLE_EXCEED, threshold
violations by E_DLL_CYCLE_EXCEED_TH.

•

Registration
The MN may optionally operate a threshold counter
DLL_MNCycTimeExceed_REC.ThresholdCnt_U32 and optionally a cumulative counter array
DLL_MNCycTimeExceed_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

Error Code
E_DLL_CYCLE_EXCEEDTimestamp
XXXX

3h

002h

E_DLL_CYCLE_EXCEED_TH

XXXX

4.7.6.5•

Additional Information

Collisions

Error Source
The number of hubs in the POWERLINK network may violate the path delay variability
specification of IEEE 802.3. Because standard Ethernet controllers according to IEEE 802.3 areused, collisions can be detected only in some cases.
ETHERNET powerlink does not depend on the discovery of collisions.
In NMT_MS_PRE_OPERATIONAL_1, NMT_MS_PRE_OPERATIONAL_2,
NMT_MS_READY_TO_OPERATE, and NMT_MS_OPERATIONAL, no collisions should occur
due to the POWERLINK cycle design. If a node does not follow these requirements, then thedeterminism and the high precision synchronisation cannot be guaranteed anymore.
Nevertheless collisions can occur in case of configuration failures or defect nodes.

•

Error recognition
If the Ethernet controller discovers a collision in the POWERLINK network, it shall start thestandard Ethernet procedure for collisions.

•Handling
MN shall log the error symptom in the error history and and shall suspends cycle generation for
a configurable number (DLL_MNCycleSuspendNumber_U32) of cycles, before continuing with
the isochronous and asynchronous communication.
The MN data link layer state machine shall change its state to DLL_MS_WAIT_SOC_TIME.
Optionally a threshold counter DLL_MNCollision_REC.ThresholdCnt_U32 and a cumulative
counter DLL_MNCollision_REC.CumulativeCnt_U32 may be operated. Every time
DLL_MNCollision_REC.ThresholdCnt_U32 reaches the threshold
DLL_MNCollision_REC.Threshold_U32 or, if no Threshold counter is implemented, every timethe error symptom occurs, the MN NMT state machine shall be notified. It shall handle this error
source as an “internal Communication Error (NMT_GT6)” and shall change its state to
NMT_GS_RESET_COMMUNICATION.

EPSG DS 301 V1.5.1-89-

Every error event shall be logged in the error history by E_DLL_COLLISION, threshold
violations by E_DLL_COLLISION_TH.
•

Registration
The MN may optionally operate a threshold counter DLL_MNCollision_REC.ThresholdCnt_U32
and a cumulative counter DLL_MNCollision_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

Error Code
E_DLL_COLLISION

Timestamp
XXXX

3h

002h

E_DLL_COLLISION_TH

XXXX

4.7.6.6•

Additional Information

Invalid Formats

Error Source
Invalid Formats can result from software faults or hardware errors in the nodes. Format Errors
shall only be detected on PRes and ASnd frames with correct CRC. Format Errors in theasynchronous communication not using the POWERLINK ASnd frame shall be ignored.
Invalid Format Errors can also occur if there are various firmware versions within the
POWERLINK network. In that case nodes may not support frame formats of other nodes.

•

Error recognition
An invalid Format error symptom shall be recognized if a POWERLINK frame header contains
an unsupported value. This may be a false Node ID, etc. An invalid format error shall also be
caused, if the received frame size is larger than the predicted buffer input size.
A false resp. unknown message type or service ID does not result in an invalid format error.
Note: Otherwise the mixing of old and new devices that support extensions of the specification
with new message types or service IDs will result in invalid format errors in old CNs.

•

Handling
If a CN causes an invalid format error, the MN NMT State machine shall consider the CN
inactive and shall remove it from the isochronous processing. Additionally it shall send to the
CN the command NMTResetNode. On this command the CN will change its state (See 7.1.4).
The error symptom shall be logged to error history, every time it occurs.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h4.7.6.7•

Profile002h

Error Code
E_DLL_INVALID_FORMAT

Timestamp
XXXX

Additional Information

POWERLINK Address Conflicts

Error source
Because of the distinct MAC address of each node it is not possible that two or more nodes own
the same MAC address but it is still possible that two or more nodes own the same powerlink
node address. Only in the asynchronous communication multiple CNs can answer on a SoA
frame (service channel: Ident). Since the MN sends a MAC multicast (SoA frame) to a unicast
powerlink address, several CNs with the same powerlink address are able to respond.

•

Error recognition
The MN shall detect multiple used POWERLINK addresses in a network by counting the
responses on an IdentRequest SoA frame.

•

Handling
If the MN detects that multiple CNs cause POWERLINK address conflicts, the MN NMT Statemachine shall consider the involved CNs inactive and shall remove them from the configuration.

EPSG DS 301 V1.5.1-90-

The error symptom shall be logged to error history, every time it occurs.
•

Registration
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

4.7.6.8•

Error Code
E_DLL_ADDRESS_CONFLICT

Timestamp
XXXX

Additional Information
Status of the MN

Multiple MNs on a single POWERLINK Network

Error source
In NMT_MS_NOT_ACTIVE the MN shall observe the POWERLINK network whether another
MN is already running.
If multiple MNs simultaneously start the communication, a combination of error symptoms will
be detected. One of these symptoms will be the receipt of SoC or SoA frames from the other
MN.

•

Error recognition
The MN will receive SoC or SoA frames from the other MN.
Recognition is optional. Support shall be indicated by D_DLL_ErrMNMultipleMN_BOOL.

•

Handling
If the MN is in the state NMT_MS_NOT_ACTIVE and detects that another MN is running, it shallreside in its state.
If multiple MNs start the communication simultaneously and an MN detects this error symptom it
notifies the NMT state machine. It handles this error source as an “internal Communication
Error (NMT_GT6)” and changes its state to NMT_GS_RESET_COMMUNICATION.
The error symptom shall be logged every time it occurs.

•

Registration
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

4.7.6.9•

Error Code
E_DLL_MULTIPLE_MN

Timestamp
XXXX

Additional Information

Loss of StatusResponse

Error source
Following possible error sources could cause this error symptom:••

Physical error sources on the MN•

Transmission Error (CRC Error)•

Loss of link•

Rx Buffer overflow•

Tx Buffer underrun

Error symptoms on a CN in the POWERLINK network••

Frame Collision error symptom•

A CN, which response latency is higher than allowed.

•

A component of the network structure is defect.

•

Power failure on a CN

•

Etc.

Error recognition
If a StatusRequest was sent and the asynchronous slot time expires, no StatusResponse frame
was received during the asynchronous slot.

EPSG DS 301 V1.5.1-91-

The error is detected by the MN cycle state machine and reported via error event
DLL_MEV_LOSS_STATUSRESPONSE.
•

Handling
After detecting a CN’s Loss of StatusResponse by the NMT_MNCycleTiming_REC.
AsyncSlotTimeout_U32, the MN shall proceed with the SoC of the next cycle.
Error reaction shall be triggered by the threshold counter mechnism (see 4.7.4.1).
If the threshold counter DLL_MNLossStatusResThrCnt_AU32[CN Node ID] violates thethreshold DLL_MNLossStatusResThreshold_AU32[CN Node ID], the MN NMT State machine
shall consider the CN inactive and shall remove it from the (isochronous) processing.
Additionally it shall send the command NMTResetNode to the respective CN. On this command
the CN will change its state (See 7.1.4). Whenever this error symptom is detected, the MN shallcheck for a physical layer error source.
The error symptom shall be logged in the Error History every time the threshold value isreached.

•Registration
The MN shall operate a threshold counter array DLL_MNLossStatusResThrCnt_AU32 andoptionally a cumulative counter array DLL_MNLossStatusResCumCnt_AU32 (see. 4.7.4.2).
CNs are represented by the subindices of the arrays.
History Entry Object ERR_History_ADOM:
Mode
3h

4.7.7

Profile002h

Error Code
E_DLL_LOSS_STATUSRES_TH

Timestamp
XXXX

Additional Information

Communication Error Symptoms detected by theCNThis section describes error symptoms on the data link layer detected and handled by CNs.

4.7.7.1•

Collisions

Error Source
The number of hubs in the POWERLINK network may violate the path delay variability
specification of IEEE 802.3. Because standard Ethernet controllers according to IEEE 802.3 areused, collisions can be detected only in some cases.
ETHERNET powerlink does not depend on the discovery of collisions.
In NMT_CS_PRE_OPERATIONAL_1, NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, and NMT_CS_OPERATIONAL, no collisions should occur
because of the POWERLINK cycle design. If a node does not fullfill these requirements, thenthe determinism and the high precision synchronisation can not be guaranteed anymore.
Nevertheless collisions can occur in case of configuration failures or defect nodes.

•

Error recognition
If the Ethernet controller discovers a collision in the POWERLINK network, it shall start thestandard Ethernet procedure for collisions.

•Handling
A threshold counter DLL_CNCollision_REC.ThresholdCnt_U32 and a cumulative counter
DLL_CNCollision_REC.CumulativeCnt_U32 may be operated optionally. Every time thethreshold counter reaches the threshold DLL_CNCollision_REC.Threshold_U32, the CN NMT
state machine shall be notified. It shall handle this error source as an “Internal Communication
Error (NMT_GT6)” and shall change its state to NMT_GS_RESET_COMMUNICATION.
Threshold violations shall be logged in the error history.

EPSG DS 301 V1.5.1•-92-

Registration
The CN may optionally operate a threshold counter DLL_CNCollision_REC.ThresholdCnt_U32
and a cumulative counter DLL_CNCollision_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:
Mode
3h4.7.7.2•

Profile002h

Error Code
E_DLL_COLLISION_TH

Timestamp
XXXX

Additional Information

Invalid Formats

Error Source
Invalid Formats can result from software faults or hardware errors in the nodes. Format Errors
shall be detected on all POWERLINK frames with correct CRC received by the CN, e.g SoC,
PReq, PRes, SoA and ASnd. Format Errors in the asynchronous communication not using the
POWERLINK ASnd frame shall be ignored.
Invalid Format Errors can also occur if there are various firmware versions within the
POWERLINK network. In that case nodes may not support frame formats of other nodes.

•

Error recognition
An invalid Format error symptom shall be recognized if a POWERLINK frame header contains
an unsupported value. This may be a false Node ID, etc. An invalid format error is also caused,
if the received frame size is larger than the predicted buffer input size.
A false resp. unknown message type or service ID does not result in an invalid format error.
Note: Otherwise the mixing of old and new devices that support extensions of the specification
with new message types or service IDs will result in invalid format errors in old CNs.

•

Handling
If a CN detects an invalid format error, it shall notify it’s NMT State machine. The CN NMT Statemachine handles this error source as an “Internal Communication Error (NMT_GT6)” andchanges its state to NMT_GS_RESET_COMMUNICATION.
The error symptom is logged to error history every time it occurs.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h4.7.7.3

Profile002h

Error Code
E_DLL_INVALID_FORMAT

Timestamp
XXXX

Additional Information

Loss of Frames

Loss of Frame errors are detected by the CN cycle state machine and reported via error events. The
state machine only detects the loss of frames, which were sent by the MN.
•

Error source
Following error sources could cause this error symptom:••

Physical error sources on the MN (see 4.7.5)•

Transmission Error (CRC Error)•

Loss of link•

Rx Buffer overflow•

Tx Buffer underrun

Error symptoms on a CN in the POWERLINK network•

Frame Collision (see 4.7.7.1)•

A component of the network structure is defect.

•

Power failure on a CN or an MNEPSG DS 301 V1.5.1•

Etc.

4.7.7.3.1•-93-

Loss of SoC

Error recognition
Loss of SoC error is detected by the CN Cycle State Machine and reported via error event
DLL_CEV_LOSS_SOC.

•

Handling
On detecting a Loss of SoC the cumulative counter
DLL_CNLossSoC_REC.CumulativeCnt_U32 shall be incremented. The CN shall reply on any
invitation with the data of the previous cycle. The CN shall accept new isochronous or
asynchronous data.
Error reaction shall be triggered by the threshold counter mechnism (see 4.7.4.1).
If the threshold counter DLL_CNLossSoC_REC.ThresholdCnt_U32 violates the threshold
DLL_CNLossSoC_REC.Threshold_U32, the CN shall notify its NMT state machine and shall log
the error symptom to the error history. The CN NMT state machine shall handle this error
source as an “error condition (NMT_CT11)” and shall change it’s state to
NMT_CS_PRE_OPERATIONAL_1.
Whenever this error symptom is detected, the CN shall check for a physical layer error source(see 4.7.5).

•

Registration
The CN shall operate a threshold counter DLL_CNLossSoC_REC.ThresholdCnt_U32 and acumulative counter DLL_CNLossSoC_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:
Mode
3h4.7.7.3.2•

Profile002h

Error Code
E_DLL_LOSS_SOC_TH

Timestamp
XXXX

Additional Information

Loss of SoA

Error recognition
Loss of SoA error is detected by the CN Cycle State Machine and reported via error event
DLL_CEV_LOSS_SOA.

•

Handling
On detecting a Loss of SoA the cumulative counter
DLL_CNLossSoA_REC.CumulativeCnt_U32 shall be incremented. The CN shall continue
operation. It shall accept new isochronous or asynchronous data.
Error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).
If the threshold counter DLL_CNLossSoA_REC.ThresholdCnt_U32 violates the threshold
DLL_CNLossSoA_REC.Threshold_U32, the CN shall notify its NMT state machine and shall log
the error symptom to the error history. The CN NMT state machine shall handle this error
source as an “error condition (NMT_CT11)” and shall change it’s state to
NMT_CS_PRE_OPERATIONAL_1.
Whenever this error symptom is detected, the CN checks for a physical layer error source (see4.7.5).

•

Registration
The CN shall operate a threshold counter DLL_CNLossSoA_REC.ThresholdCnt_U32 and acumulative counter DLL_CNLossSoA_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:EPSG DS 301 V1.5.1
Mode
3hProfile002h

4.7.7.3.3•-94-

Error Code
E_DLL_LOSS_SOA_TH

Timestamp
XXXX

Additional Information

Loss of PReq

Error recognition
Loss of PReq error is detected by the CN Cycle State Machine and reported via error event
DLL_CEV_LOSS_PREQ.

•

Handling
On detecting a Loss of PReq the cumulative counter
DLL_CNLossPReq_REC.CumulativeCnt_U32 shall be incremented. The CN shall continuecommunication and listen to cross traffic. It shall accept new isochronous or asynchronous data.
Further error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).
If the threshold counter DLL_CNLossPReq_REC.ThresholdCnt_U32 violates the threshold
DLL_CNLossPReq_REC.Threshold_U32, the CN shall notify its NMT state machine and shalllog the error symptom to the error history. The CN NMT state machine shall handle this error
source as an “error condition (NMT_CT11)” and shall change it’s state to
NMT_CS_PRE_OPERATIONAL_1.
Whenever this error symptom is detected, the CN checks for a physical layer error source (see4.7.5).

•

Registration
The CN shall operate a threshold counter DLL_CNLossPReq_REC.ThresholdCnt_U32 and acumulative counter DLL_CNLossPReq_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM
Mode
3hProfile002h

4.7.7.3.4•

Error Code
E_DLL_LOSS_PREQ_TH

Timestamp
XXXX

Additional Information

SoC Jitter out of Range

Error sourceThis error could have various error sources:••

Jitter on not POWERLINK compliant network components•

Collisions in the POWERLINK network•

Failure during the transmission•

MN failures•

Late response of CN causes a delay of the SoC

•

Etc.

Error recognition
A CN may control the SoC cycle time jitter.
Every time it receives the SoC frame, it shall measure the cycle time. A SoC jitter error shall berecognized, when the difference between the nominal cycle time and the measured time is outof a configurable range DLL_CNSoCJitterRange_U32.
Recognition shall be performed in NMT_CS_READY_TO_OPERATE and
NMT_CS_OPERATIONAL.

•

Handling
If the CN detects a SoC Jitter range violation the cumulative counter
DLL_CNSoCJitter_REC.CumulativeCnt_U32 shall be incremented,
Further error reaction shall be triggered by the threshold counter mechnism ( see 4.7.4.1).

EPSG DS 301 V1.5.1-95-

If the threshold counter DLL_CNSoCJitter_REC.ThresholdCnt_U32 violates the threshold
DLL_CNSoCJitter_REC.Threshold_U32, the CN shall notify its NMT state machine and shalllog the error symptom to the error history. The CN NMT state machine shall handle this error
source as an “error condition (NMT_CT11)” and shall change it’s state to
NMT_CS_PRE_OPERATIONAL_1.
•

Registration
The CN shall operate a threshold counter DLL_CNSoCJitter_REC.ThresholdCnt_U32 and acumulative counter DLL_CNSoCJitter_REC.CumulativeCnt_U32 (see. 4.7.4.2).
History Entry Object ERR_History_ADOM:
Mode
3h

4.7.8

Profile002h

Error Code
E_DLL_JITTER_TH

Timestamp
XXXX

Additional Information

DLL Error Handling Objects

In this section the objects used by the DLL error handling are described.
Support of threshold counter objects requires support of the respective threshold value object and viceversa.

4.7.8.1

Object 1C00h: DLL_MNCRCError_REC

The following objects are used to monitor CRC errors. The record consists of a cumulative counterand a threshold counter data object and its threshold data object.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: M
CN: -

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C00h
DLL_MNCRCError_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
1 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a CRC error occurs. Its value
monitors all CRC errors that were detected by the MN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a CRC error occurs on the MN anddecremented by 1 at every cycle without reoccurance of the error. Its value monitors the qualityof network in relation to the CRC error occurrence.

EPSG DS 301 V1.5.1•-96-

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.1)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

4.7.8.2

Object 1C01h: DLL_MNCollision_REC

The following objects are used to monitor Collision error symptoms. The record consists of acumulative counter and a threshold counter data object and its threshold data object.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: O
CN: -

AccessPDO Mappingrw
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C01h
DLL_MNCollision_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a Collision error symptom occurs.
Its value monitors all Collision error symptoms that were detected by the MN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a Collision error symptom occurs
on the MN and decremented by 1 at every cycle without reoccurance of the error. Its value
monitors the quality of network in relation to the Collision error occurrence.

EPSG DS 301 V1.5.1•-97-

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.1)
Threshold counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

4.7.8.3

Object 1C02h: DLL_MNCycTimeExceed_REC

The following objects are used to monitor “Cycle time exceeded” error symptoms. The record consistsof a cumulative counter and a threshold counter data object and its threshold data object.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: O
CN: -

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C02h
DLL_MNCycTimeExceed_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Cycle time Exceeded“ error
symptom occurs. Its value monitors all “Cycle Time exceeded” error symptom that weredetected by the MN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a “Cycle Time exceeded” error
symptom occurs on the MN and decremented by 1 at every cycle without reoccurance of theerror. Its value monitors the quality of network in relation to the “Cycle Time exceeded error
occurrence.

EPSG DS 301 V1.5.1•-98-

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.1)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

4.7.8.4

Object 1C03h: DLL_MNLossOfLinkCum_U32

The following objects are used to monitor the “Loss of Link” error source. The cumulative counter shallbe incremented by 1 every time a “Loss of Link“ error symptom occurs. Its value monitors all “Loss ofLink” error symptoms that were detected by the MN.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type

1C03h
DLL_MNLossOfLinkCum_U32
UNSIGNED32

Object Type

VAR

Category

Value Range
Default ValueUNSIGNED32
0

AccessPDO Mapping

MN: Cond
CN: rw
No

4.7.8.5

Object 1C04h: DLL_MNCNLatePResCumCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a cumulative counter of Late
PRes events. The cumulative counter of the respective CN shall be incremented by 1 every time a“Late PollResponse“ error symptom occurs. Its value monitors all “Late PollResponse” error symptoms
that were detected by the MN.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type•

Object Type

ARRAY

Category

MN: Cond
CN: -AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C04h
DLL_MNCNLatePResCumCnt_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CumCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
CumCnt-UNSIGNED32
0

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

EPSG DS 301 V1.5.1

4.7.8.6-99-

Object 1C05h: DLL_MNCNLatePResThrCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold counter of latePRes. The threshold counter of the respective CN shall be incremented by 8 every time a “LatePollResponse” error symptom occurs on the MN and decremented by 1 at every cycle without
reoccurance of the error. Its value monitors the quality of network in relation to the “LatePollResponse” error occurrence.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type•

Object Type

ARRAY

Category

MN: Cond
CN: -AccessPDO MappingroNoCategory
AccessPDO Mapping

M
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C05h
DLL_MNCNLatePResThrCnt_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: ThrCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
ThrCnt-UNSIGNED32
0

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

4.7.8.7

Object 1C06h: DLL_MNCNLatePResThreshold_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold of late PRes.
Every time the respective DLL_MNCNLatePResThrCnt_AU32 value reaches the threshold, a defined
action shall proceed and the respective DLL_MNCNLatePResThrCnt_AU32 value shall be reset to 0.
(See 4.7.7.1)
Threshold Counting may be deactivated by setting respective DLL_MNCNLatePResThreshold_AU32
value to 0. If Threshold Counting is deactivated, no error reaction will occur.
The object may be implemented only if the error recognition is provided.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1C06h
Object Type
DLL_MNCNLatePResThreshold_AU32
UNSIGNED32
Category

ARRAY
MN: Cond
CN: -Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-100-

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 01h – FEh: Threshold
Sub-Index
Name-Value Range
Default Value

01h – FEh
Threshold-UNSIGNED32
15

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

4.7.8.8

Object 1C07h: DLL_MNCNLossPResCumCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a cumulative counter of Lossof PRes events. The cumulative counter of the respective CN shall be incremented by 1 every time a“Loss of PollResponse“ error symptom occurs. Its value monitors all “Loss PollResponse” error
symptoms that were detected by the MN.
Index
Name
Data Type•

Object Type

ARRAY

Category

MN: O
CN: -

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C07h
DLL_MNCNLossPResCumCnt_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CumCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
CumCnt-UNSIGNED32
0

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

4.7.8.9

Object 1C08h: DLL_MNCNLossPResThrCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold counter of Lossof PRes.The threshold counter of the respective CN shall be incremented by 8 every time a “Loss of
PollResponse” error symptom occurs on the MN and decremented by 1 at every cycle without
reoccurance of the error. Its value monitors the quality of network in relation to the “Loss of
PollResponse” error occurrence.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1C08h
DLL_MNCNLossPResThrCnt_AU32
UNSIGNED32

Object Type

ARRAY

Category

MN: M
CN: -

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-101-

00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: ThrCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
ThrCnt-UNSIGNED32
0

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

4.7.8.10

Object 1C09h: DLL_MNCNLossPResThreshold_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold of lost PRes.
Every time the respective DLL_MNCNLossPResThrCnt_AU32 value reaches the threshold, a defined
action shall proceed and the respective DLL_MNCNLossPResThrCnt_AU32 value shall be reset to 0.
(See 4.7.7.1)
Threshold counting may be deactivated by setting respective DLL_MNCNLossPResThreshold_AU32
value to 0. If Threshold Counting is deactivated, no error reaction will occur.
Index
Name
Data Type
•

ARRAY
MN: M
CN: -

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C09h
Object Type
DLL_MNCNLossPResThreshold_AU32
UNSIGNED32
Category

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 01h – FEh: Threshold
Sub-Index
Name-Value Range
Default Value

01h – FEh
Threshold-UNSIGNED32
15

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

EPSG DS 301 V1.5.1

4.7.8.11-102-

Object 1C0Ah: DLL_CNCollision_REC

The following objects are used to monitor “Collision” error symptoms detected by a CN. The record
consists of a cumulative counter and a threshold counter data object and its threshold data object.
The object may be implemented if the error recognition is provided.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: O

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Ah
DLL_CNCollision_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Collision“ error symptom
occurs. Its value monitors all “Collision” error symptoms that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a “Collision” error symptom occurs
and decremented by 1 at every cycle without reoccurance of the error. Its value monitors thequality of network in relation to the “Collision” error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.1)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.12-103-

Object 1C0Bh: DLL_CNLossSoC_REC

The following objects are used to monitor “Loss of Soc” error symptoms detected by a CN. The record
consists of a cumulative counter and a threshold counter data object and its threshold data object.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: M

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Bh
DLL_CNLossSoC_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
3
3

Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Loss of SoC“ error symptom
occurs. Its value monitors all “Loss of SoC” error symptoms that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

M
ro
No

The threshold counter shall be incremented by 8 every time a “Loss of SoC” error symptom
occurs and decremented by 1 at every cycle without reoccurance of the error. Its value monitors
the quality of network in relation to the “Loss of SoC” error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

M
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.3.1)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.13-104-

Object 1C0Ch: DLL_CNLossSoA_REC

The following objects are used to monitor “Loss of SoA” error symptoms detected by a CN. The record
consists of a cumulative counter and a threshold counter data object and its threshold data object.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: Cond

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Ch
DLL_CNLossSoA_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Loss of SoA“ error symptom
occurs. Its value monitors all “Loss of SoA” error symptoms that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a “Loss of SoA” error symptom
occurs and decremented by 1 at every cycle without reoccurance of the error. Its value monitors
the quality of network in relation to the “Loss of SoA” error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.3.2)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.14-105-

Object 1C0Dh: DLL_CNLossPReq_REC

The following objects are used to monitor “Loss of PReq” error symptoms detected by an isochronous
CN. The record consists of a cumulative counter and a threshold counter data object and its thresholddata object.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: Cond

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Dh
DLL_CNLossPReq_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Loss of PReq“ error symptom
occurs. Its value monitors all “Loss of PReq” error symptoms that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a “Loss of PReq” error symptom
occurs and decremented by 1 at every cycle without reoccurance of the error. Its value monitors
the quality of network in relation to the “Loss of PReq” error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.3.3)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.15-106-

Object 1C0Eh: DLL_CNSoCJitter_REC

The following objects are used to monitor “SoC Jitter” error symptoms detected by a CN. The record
consists of a cumulative counter and a threshold counter data object and its threshold data object.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: Cond

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Eh
DLL_CNSoCJitter_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
0 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a “Soc Jitter“ error symptom
occurs. Its value monitors all “SoC Jitter” error symptoms that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a “SoC Jitter” error symptom occurs
and decremented by 1 at every cycle without reoccurance of the error. Its value monitors thequality of network in relation to the “SoC Jitter” error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.7.3.1)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.16-107-

Object 1C0Fh: DLL_CNCRCError_REC

The following objects are used to monitor CRC errors. The record consists of a cumulative counterand a threshold counter data object and its threshold data object.
Index
Name
Data Type•

Object TypeRECORD

Category

MN: CN: M

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C0Fh
DLL_CNCRCError_REC
DLL_ErrorCntRec_TYPE

00h
NumberOfEntries
1 .. 3-Sub-Index 01h: CumulativeCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
CumulativeCnt_U32
UNSIGNED32
UNSIGNED320

The cumulative counter shall be incremented by 1 every time a CRC error occurs. Its value
monitors all CRC errors that were detected by the CN.
•

Sub-Index 02h: ThresholdCnt_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ThresholdCnt_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

The threshold counter shall be incremented by 8 every time a CRC error occurs on the CN anddecremented by 1 at every cycle without reoccurance of the error. Its value monitors the qualityof network in relation to the CRC error occurrence.
•

Sub-Index 03h: Threshold_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Threshold_U32
UNSIGNED32
UNSIGNED32
15

Category
AccessPDO Mapping

O
rws
No

Every time ThresholdCnt_U32 reaches the threshold, a defined action shall proceed andThresholdCnt_U32 shall be reset to 0. (See 4.7.5.4)
Threshold Counting may be deactivated by setting Threshold_U32 to 0. If Threshold Counting isdeactivated, no error reaction will occur.

EPSG DS 301 V1.5.1

4.7.8.17-108-

Object 1C10h: DLL_CNLossOfLinkCum_U32

The following objects are used to monitor the “Loss of Link” error source. The cumulative counter shallbe incremented by 1 every time a “Loss of Link“ error symptom occurs. Its value monitors all “Loss ofLink” error sources that were detected by the CN.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type

1C10h
DLL_CNLossOfLinkCum_U32
UNSIGNED32

Object Type

VAR

Category

Value Range
Default ValueUNSIGNED32
0

AccessPDO Mapping

MN: CN: Condrw
No

4.7.8.18

Object 1C12h: DLL_MNCycleSuspendNumber_U32

The DLL_MNCycleSuspendNumber_U32 parameter is used to define the number of cycles that will besuspended, when a collision has occurred. (See also Tab. 28 MN error handling table and 4.7.6.5
Collisions)
Index
Name
Data Type

1C12h
DLL_MNCycleSuspendNumber_U32
UNSIGNED32

Object Type

VAR

Category

Value Range
Default ValueUNSIGNED32
1

AccessPDO Mapping

MN: M
CN: rw
No

Value 0 means that it will finish the current cycle and continue with the followed cycle; 1 means,that it suspends the followed cycle.

4.7.8.19

Object 1C13h: DLL_CNSoCJitterRange_U32

The DLL_CNSoCJitterRange_U32 parameter is used to define the range in ns within the SoCJitter
may vary.
The object may be implemented only if the error recognition is provided.
Index
Name
Data Type

1C13h
DLL_CNSoCJitterRange_U32
UNSIGNED32

Object Type

VAR

Category

Value Range
Default ValueUNSIGNED32
2000

AccessPDO Mapping

MN: CN: Condrw
No

4.7.8.20

Object 1C14h : DLL_CNLossOfSocTolerance_U32

The object provides a tolerance interval in [ns] to be applied by CN’s Loss of SoC error recognition(see 4.7.7.3.1).

EPSG DS 301 V1.5.1-109-

Index 1C14h

Object VAR
Type

Nam DLL_CNLossOfSocTolerance_U32
eData UNSIGNED32
Type
Value 0 .. D_DLL_CNLossOfSoCToleranceMax_U32
Range
Defa D_DLL_CNLossOfSoCToleranceMax_U32
ult
Value

4.7.8.21

Catego MN: ry
CN: M
Access rws

PDONo
Mapping

Object 1C15h: DLL_MNLossStatusResCumCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a cumulative counter of Lossof StatusResponse events. The cumulative counter of the respective CN shall be incremented by 1
every time a “Loss of StatusResponse“ error symptom occurs. Its value monitors all “LossStatusResponse” error symptoms that were detected by the MN.
Index
Name
Data Type
•

ARRAY
MN: O
CN: -

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C15h
Object Type
DLL_MNLossStatusResCumCnt_AU32
UNSIGNED32
Category

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rw
No

Sub-Index 01h – FEh: CumCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
CumCnt-UNSIGNED32
0

The sub-index is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0 and 1.

4.7.8.22

Object 1C16h: DLL_MNLossStatusResThrCnt_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold counter of Lossof StatusResponse. The threshold counter of the respective CN shall be incremented by 8 every timea “Loss of StatusResponse” error symptom occurs on the MN and decremented by 1 at every
StatusRequest without reoccurance of the error. Its value monitors the quality of network in relation to
the “Loss of StatusResponse” error occurrence.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1C16h
Object Type
DLL_MNLossStatusResThrCnt_AU32
UNSIGNED32
Category

ARRAY
MN: M
CN: -

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-110-

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
ro
No

Sub-Index 01h – FEh: ThrCnt
Sub-Index
Name-Value Range
Default Value

01h – FEh
ThrCnt-UNSIGNED32
0

The sub-index is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0 and 1.

4.7.8.23

Object 1C17h:
DLL_MNLossStatusResThreshold_AU32

This array on the MN contains for every CN in the POWERLINK network a threshold of lost
StatusResponse.
Every time the respective DLL_MNLossStatusResThrCnt_AU32 value reaches the threshold, adefined action shall proceed and the respective DLL_MNLossStatusResThrCnt_AU32 value shall bereset to 0. (See 4.7.7.1)
Threshold counting may be deactivated by setting respective DLL_MNLossStatusResThreshold_AU32
value to 0. If Threshold Counting is deactivated, no error reaction will occur.
Index
Name
Data Type
•

ARRAY
MN: M
CN: -

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1C17h
Object Type
DLL_MNLossStatusResThreshold_AU32
UNSIGNED32
Category

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 01h – FEh: Threshold
Sub-Index
Name-Value Range
Default Value

01h – FEh
Threshold-UNSIGNED32
15

The sub-index is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0 and 1.

EPSG DS 301 V1.5.1

4.7.8.24-111-

Object 0424h: DLL_ErrorCntRec_TYPE

Index
Name

0424h
DLL_ErrorCntRec_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h

Component Name
NumberOfEntries
CumulativeCnt_U32
ThresholdCnt_U32
Threshold_U32

Value
03h
0007h
0007h
0007h

Data TypeUNSIGNED32
UNSIGNED32
UNSIGNED32

EPSG DS 301 V1.5.1

-112-

5

Network / Transport Layer

5.1

Internet Protocol (IP)The Internet Protocol version 4 (IPv4) and its referred transport layer protocols UDP and TCP are thepreferred protocols in the asynchronous phase.
•

RFC 791 defines Internet Protocol (IP)•RFC 768 defines the User Datagram Protocol (UDP)•

RFC 793 defines the Transmission Control Protocol (TCP).

5.1.1

IP Host Requirements

This section discusses the requirements for a POWERLINK node implementation of the Internet
Protocol. To use IP transparently in the asynchronous phase, the POWERLINK nodes shall be
conformed to RFC1122 “Requirements for Internet Hosts -- Communication Layers”. However, thiswould prohibit several low-end POWERLINK nodes, communicating with IP in the asynchronous
phase. Therefore the following conformance classes are introduced.

5.1.1.1

Nodes without IP Communication

MNs shall support IP communication.
CNs that don’t support SDO via UDP/IP do not need an IP stack.
At the CN, support of IP communication may be indicated by the device description entry
D_NWL_IPSupport_BOOL.

5.1.1.2

Minimum Requirements for SDO Communication

This conformance class shall be fulfilled, to ensure that a POWERLINK node is able to communicate
in the asynchronous phase via SDO. It is not guaranteed that protocols from the Internet Protocol suite
will work – e.g. Socket communication, TFTP, FTP HTTP, etc.

5.1.1.2.1

IP Stack Requirements

To communicate via IPv4 in the asynchronous phase, the POWERLINK node shall at least cope with
256 Bytes SDO payload. Therefore, the IP stack shall process at least C_DLL_MIN_ASYNC_MTU bytes(including IP header and IP payload) that can be received. IP fragmentation and reassembly is not
required to fulfil this conformance class. Hence the size of the asynchronous phase shall be equal or
bigger than 256 Bytes SDO payload.

5.1.1.2.2

UDP Requirements

A POWERLINK node shall implement the User Datagram Protocol specified in RFC 768 and shallsupport at least one UDP socket.

5.1.1.3

Minimum Requirements for Standard IP
Communication

This conformance class shall be compatible to RFC 1122 and shall cover the entire conformanceclass for minimum requirements for SDO communication listed above. For convenience the following
core requirements are listed.

EPSG DS 301 V1.5.1

5.1.1.3.1-113-

IP Stack Requirements•

The IPv4 layer shall implement reassembly of IP datagrams – see RFC1122 chapter 3.3.2
Reassembly.

•

The IPv4 layer shall implement a mechanism to fragment outgoing datagrams intentionally –see RFC1122 chapter 3.3.3 Fragmentation.

•

In general an IPv4 capable POWERLINK node shall at least process IP datagrams up to 576
bytes (including header and data) – see RFC 1122 chapter 3.3.2/3.3.3.

•

ICMP (RFC 792) support is optional. It shall be indicated by D_NWL_ICMPSupport_BOOL.

5.1.2

IP Addressing

Each IP-capable POWERLINK node possesses an IPv4 address, a subnet mask and default gateway.
These attributes are referred to as the IP parameters.
•

IPv4 Address
The private class C Net ID 192.168.100.0 shall be used for a POWERLINK network – see
RFC1918. A class C network provides 254 (1-254) IP addresses, which matches the number ofvalid POWERLINK Node ID’s. The Host ID of the private class C Net ID 192.168.100.0 shall beidentical to the POWERLINK Node ID. Hence the last byte of the IP address (Host ID) has thesame value as the POWERLINK Node ID. The following figure illustrates the construction of theIP address.

192.168.100.POWERLINK Node ID
Net ID
Fig. 38.

Host ID
Construction of the IPv4 address

Remarks:
Knowing the Node ID of a POWERLINK node, its IP address and vice versa can be determinedeasily without any communication overhead.
•

Subnet mask
The subnet mask of a POWERLINK node shall be 255.255.255.0. This is the subnet mask of aclass C net.

•Default Gateway

The Default Gateway preset shall use the IP address 192.168.100.254. The value may be
modified to another valid IP address.
Generally the IPv4 Address and Subnet mask parameters of a POWERLINK node shall be fixed. The
downside of the fixed IP parameters are compensated by the POWERLINK Router using Network
Address Translation (see 9.1.4.2.2).
The following table summarises the default IP parameters.
IP Parameter

IP address

IP address
Subnet mask
Default Gateway

192.168.100.<POWERLINK Node ID>
255.255.255.0
192.168.100.254 (may be modified)IP parameters of a POWERLINK node

5.1.3

Address Resolution

The Address Resolution Protocol (ARP) specified in RFC 826 shall be used to obtain the IP to
Ethernet MAC relation of a POWERLINK node. Depending on the POWERLINK node state:•

NMT_CS_EPL_MODE and NMT_MS_EPL_MODE state: ARP shall be performed in theasynchronous phase. To reduce the traffic in the asynchronus phase, the MN may determine
the IP to MAC address relation from the ident process.

EPSG DS 301 V1.5.1

-114-

•

NMT_CS_BASIC_ETHERNET state: ARP shall be performed like an IEEE802.3 compliant
node does, using CSMA/CD.
Optional the MN or CN may send the NMT Managing command NMTFlushArpEntry (see 7.3.2.1.2) if
one of them detects that an upcoming node has a new MAC address. This can be done to flush the
ARP cache of all nodes in the POWERLINK network. The POWERLINK node may process
NMTFlushArpEntry.
Alternativley an unsolicited ARP request frame (containing its IP address) may be broadcasted
initiated by the respective POWERLINK node at startup. As a result, the neighbours ARP caches shallbe updated.

5.1.4

Hostname

Each IP capable POWERLINK node shall have a hostname. The hostname is of type
VISIBLE_STRING32. The hostname can be used to access POWERLINK nodes with its name insteadof its IP address.
The admissible values of type VISIBLE_STRING for the hostname shall be restricted to:•
30h - 39h (0 - 9)•41h - 5Ah (A - Z)•
61h - 7Ah (a - z)•
2D h (-)
The data are interpreted as ISO 646-1973(E) 7-bit coded characters.
The default hostname shall be constructed from the POWERLINK Node ID and the Vendor ID parted
by the character “-“ (<POWERLINK Node ID>-<Vendor ID>). POWERLINK Node ID and the Vendor
ID shall be hexadecimally coded.
If no hostname is explicitly assigned, the POWERLINK node shall use the default hostname instead.
The hostname located on the POWERLINK node shall be set with the NMT Managing command
NMTNetHostNameSet (refer 7.3.2.1.1). Modification of the hostname value shall not take effect until
the POWERLINK node enters the NMT_GS_INITIALISATION state. The hostname is read by the
ASnd with the Ident Response Service.
A hostname to IP address resolution service may be provided to gather the hostname to IP address
association of all POWERLINK nodes within a POWERLINK network. This service configures forexample the DNS table of the DNS server located on the POWERLINK to legacy Ethernet Router or a
local hostname table on a diagnostics device.

EPSG DS 301 V1.5.1

-115-

5.1.5

Object description

5.1.5.1

Object 1E4Ah: NWL_IpGroup_REC

The NWL_IpGroup_REC object is a subset of the IP Group RFC1213. The object specifies information
about the IP stack.
The Object shall be supported only if IP is supported by the device.
Index
Name
Data Type•

Object TypeRECORD

Category

Cond

AccessPDO Mapping

const
No

Category
AccessM
ro/rwsPDO MappingNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1E4Ah
NWL_IpGroup_REC
NWL_IpGroup_TYPE

00h
NumberOfEntries
2 .. 3-Sub-Index 01h: Forwarding_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

01h
Forwarding_BOOL
BOOLEANFALSE (Not-forwarding)
TRUE (forwarding)
FALSE (Not-forwarding)

The indication whether this entity is acting as an IP router in respect to the forwarding of
datagrams received by, but not addressed to this entity. IP routers forward datagrams. IP hosts
do not (except those source-routed via the host).
The ability to forward datagrams is indicated by D_NWL_Forward_BOOL. On device notsupporting forwarding sub-index 01h shall be FALSE, access shall be ro. On device supporting
forwarding sub-index 01h may be FALSE or TRUE, access shall be rw.
•

Sub-Index 02h: DefaultTTL_U16
Sub-Index
Name
Data Type
Value Range
Default Value

02h
DefaultTTL_U16
UNSIGNED16
UNSIGNED16
64

Category
AccessPDO Mapping

M
rws
No

The default value inserted into the Time-To-Live (TTL) field of the IP header of datagrams
originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.
Note: The TTL field in the IP header is of different length. In the IP protocol TTL is an 8-bit field.
•

Sub-Index 03h: ForwardDatagrams_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
ForwardDatagrams_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
ro
No

The number of input datagrams for which this entity was not their final IP destination, as a resultof which an attempt was made to find a route to forward them to the final destination.

EPSG DS 301 V1.5.1

5.1.5.2-116-

Object 1E40h .. 1E49h: NWL_IpAddrTable_Xh_REC

The IP address table contains this entity's IP addressing information. The NWL_IpAddrTable_Xh_REC
object is a subset of the IP Group RFC1213. It assigns IP parameters to an interface indicated by
NMT_ItfGroup_Xh_REC.ItfIndex_U16. The IP address table shall have 1 to 10 entries that may be
configured via SDO.
The Objects shall be supported only if IP is supported by the device.
POWERLINK interfaces shall be described by the low order objects (e.g. 1E40 h, 1E41h, …).
Index
Name
Data Type•

Object TypeRECORD

Category

1E40h:
Cond
1E41h .. 1E49h: O

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

1E40h .. 1E49h
NWL_IpAddrTable_Xh_REC
NWL_IpAddrTable_TYPE

00h
NumberOfEntries
55

Sub-Index 01h: IfIndex_U16
Sub-Index
Name
Data Type
Value Range
Default Value

01h
IfIndex_U16
UNSIGNED16
1..10-

The index value which uniquely identifies the interface to which this entry is applicable. Theinterface identified by a particular value of this index is the same interface as identified by thesame value of NMT_InterfaceGroup_Xh_REC.InterfaceIndex_U16.
•

Sub-Index 02h: Addr_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
Addr_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO MappingMro/rwsNo

The IP address to which this entry's addressing information pertains.
If the object describes an Ethernet POWERLINK interface, access shall be ro. Addr_IPAD shallbe 192.168.100.xxx with xxx = NMT_EPLNodeID_REC.NodeId_U8 (cf. 5.1.2).
•

Sub-Index 03h: NetMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
NetMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO MappingMro/rws
No

The subnet mask associated with the IP address of this entry. The value of the mask is an IP
address with all the network bits set to 1 and all the hosts bits set to 0.
If the object describes an Ethernet POWERLINK interface, access shall be ro. NetMask_IPAD
shall be 255.255.255.0 (cf. 5.1.2).

EPSG DS 301 V1.5.1
•

-117-

Sub-Index 04h: ReasmMaxSize_U16
Sub-Index
Name
Data Type
Value Range
Default Value

04h
ReasmMaxSize_U16
UNSIGNED16
UNSIGNED16-

Category
AccessPDO Mapping

M
ro
No

The size of the largest IP datagram which this entity can re-assemble from incoming IP
fragmented datagrams received on this interface.
•

Sub-Index 05h: DefaultGateway_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

05h
DefaultGateway_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

The default gateway associated with the IP address of this entry.
If the object describes an Ethernet POWERLINK interface, the entry shall indicate the router
type 1 device. Default value shall be C_ADR_RT1_DEF_NODE_ID .

5.1.5.3

Object 0425h: NWL_IpGroup_TYPE

Index
Name

0425h
NWL_IpGroup_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h

Component Name
NumberOfEntries
Forwarding_BOOL
DefaultTTL_U16
ForwardDatagrams_U32

Value
03h
0001h
0006h
0007h

Data Type5.1.5.4

BOOLEANUNSIGNED16
UNSIGNED32

Object 0426h: NWL_IpAddrTable_TYPE

Index
Name

0426h
NWL_IpAddrTable_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h

Component Name
NumberOfEntries
IfIndex_U16
Addr_IPAD
NetMask_IPAD
ReasmMaxSize_U16
DefaultGateway_IPAD

Value
05h
0006h
0402h
0402h
0006h
0402h

Data TypeUNSIGNED16
IP_ADDRESSIP_ADDRESSUNSIGNED16
IP_ADDRESSEPSG DS 301 V1.5.1

5.2

-118-

POWERLINK compliant UDP/IP format

In order to enable the transmission of POWERLINK frames encapsulated in UDP/IP frames, thepayload portion of the UDP/IP frame shall be leaded by a slightly modified POWERLINK frame
header.
The parameter MessageType defined by Ethernet POWERLINK shall be in conformance to therequirements of 4.6.1.1.1. Destination and Source fields of the original POWERLINK header shall bereserved but shall not be supported, when transmission occurs via UDP/IP.
Octet Offset 14

70-5
6 - 1112 - 13
14 - 33
34 - 4142434445
46 - nn+1 - n+4

6

5

Bit Offset
4
3

entry defined by
2

1

0

Destination MAC Address
Source MAC Address
EtherTypeIP Header
UDP Header
MessageType

RFC 791
RFC 768
Ethernet POWERLINK

reserved (Destination)
reserved (Source)

ServiceID / reserved
Payload Data
CRC32n ≥ 59POWERLINK compliant UDP/IP frame structure

5.3

Ethernet type II

POWERLINK Sequence Layer

see 6.3.2.3, 6.3.3.1

14 Octet Offset refers to the start of the Ethernet frame.

Application
Ethernet type IIEPSG DS 301 V1.5.1

-119-

6

Application Layer

6.1

Data Types and Encoding Rules

This paragraph describes the data formats and encoding rules to be used by frames according to the
Ethernet POWERLINK syntax (EtherType = 88ABh). The rules apply to the POWERLINK-Content,
service specific header and data payload embedded into the Ethernet frame. The encoding of the
Ethernet frame follows the rules of IEEE 802.3.
MAC- Frame- Header(EtherType = 88ABh )Fig. 39.

POWERLINK - Content(Header + Data)

CRC

POWERLINK frame structure

The rules also apply to POWERLINK specific payloads that are embedded into non-POWERLINK
frame types (EtherType ≠ 88ABh), e.g. SDO-Transfer via UDP/IP etc. The Ethertype specific encodingof these frames, described by RFC 791 (IP) and RFC 768 (UDP), is not the concern of these rules.
MAC- Frame- Header(EtherType = 0800h )Fig. 40.

IP- Header( Protocol = 11h )UDP- Header( Port = XXXXh )POWERLINK - Content

CRC

POWERLINK compliant UDP/IP frame structure

The encoding of non-POWERLINK frames (EtherType ≠ 88ABh) without POWERLINK specificpayload is not the concern of these rules.
MAC- Frame- Header(EtherType? 88ABh )Fig. 41.

6.1.1

any Non - POWERLINK - Content

CRC

Legacy Ethernet frame structure

General Description of Data Types and Encoding
Rules

In order to exchange meaningful data across a POWERLINK network, the data format and its meaning
must be known by the producer and consumer(s). This document specifies data formats andmeanings using data types.
The encoding rules define the representation of values of data types and the POWERLINK networktransfer syntax for the representations. Values are represented as bit sequences. Bit sequences aretransferred in sequences of octets (bytes). For numerical data types the encoding is little endian style
as shown in Tab. 31.
Applications often require data types beyond the basic data types. Using the compound data typemechanism the list of available data types can be extended. Some general extended data types aredefined as “Visible String” or “Time of Day” (for example see 6.1.6.2 and 6.1.6.4). The compound datatypes are a means to implement user defined “DEFTYPES” in the terminology of this specification andnot “DEFSTRUCTS” (see 6.2.2).

6.1.2

Data Type Definitions

A data type determines a relation between values and encoding for data of that type. Names are
assigned to data types in their type definitions. The syntax of data and data type definitions is asfollows (see EN 61131-3).
data_definition::=
type_name data_nametype_definition::=
constructor type_nameconstructor::=
compound_constructor |basic_constructorEPSG DS 301 V1.5.1-120-

compound_constructor::=

array_constructor
structure_constructor
component_list
component
basic_constructor

::=
::=
::=
::=
::=

array_constructor |structure_constructor‘ARRAY’ ‘[‘ length ‘]’ ‘OF’ type_name‘STRUCT’ ‘OF’ component_list
component { ‘,’ component }type_name component_name‘BOOLEAN’ |‘VOID’ bit_size |‘BYTE’ bit_size |‘INTEGER’ bit_size |‘UNSIGNED’ bit_size |‘REAL32’ |‘REAL64’ |‘NIL’‘1’ | ‘2’ | <...> | ‘64’
positive_integer
symbolic_namesymbolic_namesymbolic_nameletter { [ ‘_’ ] ( letter | digit ) }( ‘1’ | ‘2’ | <...> | ‘9’ ) { digit }‘A’ | ‘B’ | <...> | ‘Z’ | ‘a’ | ‘b’ | <...> | ‘z’‘0’ | ‘1’ | <...> | ‘9’

bit_size::=
length::=data_name::=type_name::=component_name::=symbolic_name::=positive_integer::=
letter
::=
digit
::=
Recursive definitions are not allowed.
The data type defined by type_definition is termed either basic, when the constructor isbasic_constructor, or compound, when the constructor is compound_constructor.

6.1.3

Bit Sequences

6.1.3.1

Definition of Bit Sequences

A bit can take the values 0 or 1.
A bit sequence b is an ordered set of 0 or more bits.
If a bit sequence b contains more than 0 bits, they are denoted as bj, j ≥ 0.
Let b0, ..., bn-1 be bits, n a positive integer. Thenb = b0 b1 ... bn-1
is called a bit sequence of length |b| = n.
The empty bit sequence of length 0 is denoted .
Examples: 10110100, 1, 101, etc. are bit sequences.
The inversion operator () on bit sequences assigns to a bit sequenceb = b0 b1 ... bn-1
the bit sequenceb = b0 b1 ...  bn-1
Here 0 = 1 and 1 = 0 on bits.
The basic operation on bit sequences is concatenation.
Let a = a0 ... am-1 and b = b0 ... bn-1 be bit sequences. Then the concatenation of a and b, denoted ab,isab = a0 ... am-1 b0 ... bn-1
Example: (10)(111) = 10111 is the concatenation of 10 and 111.
The following holds for arbitrary bit sequences a and b:|ab| = |a| + |b|
andEPSG DS 301 V1.5.1-121-

a = a = a

6.1.3.2

Transfer Syntax for Bit Sequences

For transmission across a POWERLINK network a bit sequence is reordered into a sequence ofoctets. Here and in the following hexadecimal notation is used for octets. Let b = b 0... bn-1 be a bit
sequence with n ≤ 11920d (1490d Byte * 8d Bit/Byte).
Denote k a non-negative integer such that 8(k-1) < n ≤ 8k. Then b is transferred in k octets assembled
as shown in Tab. 31. The bits bi, i ≥ n of the highest numbered octet shall be ignored.
octet number

1.

2.

k.

b7 .. b0

b15 .. b8

b8k–1 .. b8k-8

Transfer syntax for bit sequences
Octet 1 is transmitted first and octet k is transmitted last. The bit sequence is transferred as follows
across the POWERLINK network:b7, b6, ..., b0, b15, ..., b8, ...
Example:
Bit 9

...

Bit 0

10b
2h

0001b 1100b
1h
Ch= 21ChThe bit sequence b = b0 .. b9 = 0011 1000 01b represents an UNSIGNED10 with the value
21Ch and is transferred in two octets:
First 1Ch and then 02h.

6.1.4

Basic Data Types

For basic data types “type_name” equals the literal string of the associated constructor (cf.
symbolic_name), e.g.,
BOOLEANBOOLEANis the type definition for the BOOLEAN data type.

6.1.4.1

NIL

Data of basic data type NIL is represented by .

6.1.4.2

BooleanData of basic data type BOOLEAN attains the values TRUE or FALSE.
The values are represented as bit sequences of length 1. The value TRUE is represented by the bit
sequence 1, and FALSE by 0.
A BOOLEAN shall be transferred over the network as UNSIGNED8 of value 1 (TRUE) resp. 0(FALSE). Sequent BOOLEANs may be packed to one UNSIGNED8. Sequences of BOOLEAN and
BIT type items may be also packed to one UNSIGNED8.

6.1.4.3

Void

Data of basic data type VOIDn is represented as bit sequences of length n bits.
The value of data of type VOIDn is undefined. The bits in the sequence of data of type VOIDn must
either be specified explicitly or else marked "do not care".
Data of type VOIDn is useful for reserved fields and for aligning components of compound values onoctet boundaries.

6.1.4.4

Bit

Data of basic data type BITn are represented as bit sequences of length n bits.
The interpretation of the value of type BITn data is defined by the context of the variable, that is
implemented using BITn data type.

EPSG DS 301 V1.5.1-122-

If a BIT value is not member of compound data type, it shall be transferred over the network as
UNSIGNED8 of value 1 resp. 0. Sequent BITs may be packed to one UNSIGNED8. Sequences of
BOOLEAN and BIT type items may be also packed to one UNSIGNED8.

6.1.4.5

Unsigned Integer

Data of basic data type UNSIGNEDn has values in the non-negative integers. The value range is 0, ...,
2n-1. The data is represented as bit sequences of length n.
The bit sequenceb = b0 ... bn-1
is assigned the value
UNSIGNEDn(b) = bn-1 2n-1+ ...+ b1 21 + b0 20
Note that the bit sequence starts on the left with the least significant byte.
Example: The value 266d = 10Ah with data type UNSIGNED16 is transferred in two octets
across the bus, first 0Ah and then 01h.
The following UNSIGNEDn data types are transferred as shown below:
octet number

0

1

2

3

4

5

6

7

UNSIGNED8UNSIGNED16
UNSIGNED24
UNSIGNED32
UNSIGNED40
UNSIGNED48
UNSIGNED56
UNSIGNED64

b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b15..b8
b15..b8
b15..b8
b15..b8
b15..b8
b15..b8
b15..b8

b23..b16
b23..b16
b23..b16
b23..b16
b23..b16
b23..b16

b31..b24
b31..b24
b31..b24
b31..b24
b31..b24

b39..b32
b39..b32
b39..b32
b39..b32

b47..b40
b47..b40
b47..b40

b55..b48
b55..b48

b63..b56

Transfer syntax for data type UNSIGNEDn
The data types UNSIGNED24, UNSIGNED40, UNSIGNED48 and UNSIGNED56 should not beapplied by new applications.
UNSIGNEDn data types of length deviating from the values listed by Tab. 32 may be applied bycompound data types only.

6.1.4.6

Signed Integer

Data of basic data type INTEGERn has values in the integers. The value range is -2n-1, … , 2n-1-1.
The data is represented as bit sequences of length n.
The bit sequenceb = b0 .. bn-1
is assigned the value
INTEGERn(b) = bn-2 2n-2 + … + b1 21 + b0 20
if bn-1 = 0
and, performing two's complement arithmetic,
INTEGERn(b) = - INTEGERn(^b) - 1
if bn-1 = 1
Note that the bit sequence starts on the left with the least significant bit.
Example: The value –266d = FEF6h with data type INTEGER16 is transfered in two
octets across the bus, first F6h and then FEh.
The following INTEGERn data types are transfered as shown below:

EPSG DS 301 V1.5.1-123-octet number

0

1

2

3

4

5

6

7

INTEGER8
INTEGER16
INTEGER24
INTEGER32
INTEGER40
INTEGER48
INTEGER56
INTEGER64

b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b7..b0b15..b8
b15..b8
b15..b8
b15..b8
b15..b8
b15..b8
b15..b8

b23..b16
b23..b16
b23..b16
b23..b16
b23..b16
b23..b16

b31..b24
b31..b24
b31..b24
b31..b24
b31..b24

b39..b32
b39..b32
b39..b32
b39..b32

b47..b40
b47..b40
b47..b40

b55..b48
b55..b48

b63..b56

Transfer syntax for data type INTEGERn
The data types INTEGER24, INTEGER40, INTEGER48 and INTEGER56 should not be applied by
new applications.
INTEGERn data types of length deviating from the values listed by Tab. 33 may be applied bycompound data types only.

6.1.4.7

Floating-Point Numbers

Data of basic data types REAL32 and REAL64 have values in the real numbers.
The data type REAL32 is represented as bit sequence of length 32. The encoding of values follows
the IEEE 754-1985 Standard for single precision floating-point.
The data type REAL64 is represented as bit sequence of length 64. The encoding of values follows
the IEEE 754-1985 Standard for double precision floating-point numbers.
A bit sequence of length 32 either has a value (finite non-zero real number, ± 0, ± _) or is NaN (not-anumber). The bit sequenceb = b0 … b31
is assigned the value (finite non-zero number)
REAL32(b) = (-1)S 2E-127 (1+ F)
Here
S = b31 is the sign.
E = b30 27 + …+ b23 20, 0 < E < 255, is the un-biased exponent.
F = 2-23 (b22 222 + …+ b1 21 + b0 20) is the fractional part of the number.
E = 0 is used to represent ± 0. E = 255 is used to represent infinities and NaN's.
Note that the bit sequence starts on the left with the least significant bit.
Example:6.25 = 2 E-127 (1 + F) with
E =129 =27 +20 and
F = 2-1 +2-4 = 2 -23(222+219) hence the number is represented as:
S
b31
0

E
b30 .. b23
100 0000 1

F
b22 .. b0
100 1000 0000 0000 0000 0000

6.25 = b0 .. b31 = 0000 0000 0000 0000 0001 0011 0000 0010
It is transferred in the following order:
octet number

0

1

2

3

REAL3200hb7..b000hb15..b8C8h
b23..b1640h
b31..b24

Transfer syntax of data type REAL32

6.1.4.8

MAC Address

The data type MAC_ADDRESS is used to describe the MAC address of an Ethernet adapter. It isrepresented by 6 octets. It may be interpreted as UNSIGNED48.

EPSG DS 301 V1.5.1-124-

The MAC address is divided into two sub-items:•

Organisational Unique Identifier (OUI), describing the adapter’s manufacturer•

adapter specific unique identifier

Octet

5

Example

4

3

OUI
0Ah

00h

2

1

0

adapter’s individual identifier
xxh
xxh
xxh

86h

MAC address encoding, example 00-0A-86-xx-xx-xx shows a Lenze device

6.1.4.9

IP address

The data type IP_ADDRESS is used to describe the IP address of a network adapter, subnet masksetc. It is represented by 4 octets. It may be interpreted as UNSIGNED32.
The IP address is divided to a Net Id part and a Host ID part. Tab. 36 shows the the coding of Net andHost ID. The bit consumption of these parts depends on the type of the subnet and is therefore not
fixed.
Octet

3

2

1

0

NetID
Example

C0h
192

HostID
A8h
168

64h
100

F0h
240

IP address encoding, example shows the IP address of a POWERLINK MN
192.168.100.240

6.1.5

Compound Data Types

Type definitions of compound data types expand to a unique list of type definitions involving only basic
data types. Correspondingly, data of compound type ´type_name´ are ordered lists of component datanamed ´component_name_i´ of basic type ´basic_type_i´.
Compound data types constructors are ARRAY and STRUCT OF.
STRUCT OF
basic_type_1
component_name_1,
basic_type_2
component_name_2,…
…
basic_type_N
component_name_N
type_name
ARRAY [ length ] OF basic_type
type_name
The bit sequence representing data of compound type is obtained by concatenating the bit sequences
representing the component data.
Assume that the components ´component_name_i´ are represented by their bit sequencesb(i), for i = 1,…,N.
Then the compound data is represented by the concatenated sequence.
b0(1) .. bn-1(1) .. bn-1(N).
Example: Consider the data type
STRUCT OF
INTEGER10x,
UNSIGNED5u
NewData
Assume x = - 423d = 259h and u = 30d = 1Eh. Let b(x) and b(u) denote the bit sequences
representing the values of x and u, respectively. Then:b(x)= b0(x) .. b9(x)= 1001101001
b(u)= b0(u) .. b4(u)= 01111b(xu) = b(x) b(u)= b0(xu) .. b14(xu)= 1001101001 01111
The value of the structure is transferred with two octets, first 59h and then 7Ah.

EPSG DS 301 V1.5.1

6.1.6

-125-

Extended Data Types

The extended data types consist of the basic data types and the compound data types defined in thefollowing subsections.

6.1.6.1

Octet String

The data type OCTET_STRINGlength is defined below; length is the maximum length of the octet
string.
ARRAY [ length ] OF UNSIGNED8
OCTET_STRINGlength
If the actual length of the string is shorter than length the rest shall be filled up with 0h.

6.1.6.2

Visible String

The data type VISIBLE_STRINGlength is defined below. The data type is VISIBLE_STRING whether
a length is defined in the data type name or not. A VISIBLE_STRING with a length definition defines
the maximum length allowed. Otherwise any length is allowed.
The admissible values of data of type VISIBLE_CHAR are 0h and the range from 20h to 7Eh. The data
are interpreted as ISO 646-1973(E) 7-bit coded characters.
UNSIGNED8VISIBLE_CHAR
ARRAY [ length ] OF VISIBLE_CHAR
VISIBLE_STRINGlength
There is no 0h necessary to terminate the string. However, if the actual length of the string is shorter
than length the rest shall be filled up with 0h.

6.1.6.3

Unicode String

The data type UNICODE_STRINGlength is defined below; length is the maximum length of theunicode string.
ARRAY [ length ] OF UNSIGNED16
UNICODE_STRINGlength
If the actual length of the string is shorter than length the rest shall be filled up with 0h.

6.1.6.4

Time of Day

The data type TIME_OF_DAY represents absolute time. It follows from the definition and the encoding
rules that TIME_OF_DAY is represented as bit sequence of length 48.
Component ms is the time in milliseconds after midnight. Component days is the number of days since
January 1, 1984.
STRUCT OF
UNSIGNED28
ms,
VOID4
reserved,
UNSIGNED16
days
TIME_OF_DAY

6.1.6.5

Time Difference

The data type TIME_DIFFERENCE represents a time difference. It follows from the definition and theencoding rules that TIME_DIFFERENCE is represented as bit sequence of length 48.
Time differences are sums of numbers of days and milliseconds. Component ms is the number
milliseconds. Component days is the number of days.
STRUCT OF
UNSIGNED28
ms,
VOID4
reserved,
UNSIGNED16
days
TIME_DIFFERENCE

6.1.6.6

Domain

Domains can be used to transfer an arbitrarily large block of data from a client to a server.

EPSG DS 301 V1.5.1

6.1.6.7-126-

Net Time

The data type NETTIME represents a high precision time value. The NETTIME data type isidentical to an improved version of the TimeRepresentation type of IEEE 1588.
NETTIME is composed as follows:
STRUCT OF
UNSIGNED32 seconds
UNSIGNED32 nanoseconds
NETTIMEThe nanoseconds member is defined such that the most significant bit represents the sign bit, 1
indicating a negative number, and the least significant 31 bits represent the nanoseconds portion of
the time being represented. TimeRepresentation thus defines a sign magnitude representation for timestamps and time intervals.
The range of the absolute value of the least significant 31 bits of the nanoseconds portion of therepresentation shall be restricted to:
0 <= | least significant 31 bits of nanoseconds | < 109
The sign of the nanoseconds member shall be interpreted as the sign of the entire representation. For
example:•+2.0 seconds is represented by seconds = 00000002h and nanoseconds = 00000000h•-2.0 seconds is represented by seconds = 00000002h and nanoseconds = 80000000h•+2.000000001 seconds is represented by seconds = 00000002 h and nanoseconds = 00000001h•-2.000000001 seconds is represented by seconds = 00000002 h and nanoseconds = 80000001h
Timestamps shall be relative to 01-01-1970 00:00 h. A negative timestamp shall indicate time prior tothis point of time. Timestamps using NETTIME will overflow in January 2106.
NETTIME shall be used for timestamps and time increments.

6.2

Object Dictionary

This section details the Object Dictionary structure and entries which are common to all devices.
The overall layout of the Object Dictionary is shown in 2.2.2.

6.2.1

Object Dictionary Entry Definition

An Object Dictionary entry shall be defined by the following items:•

Index
Index denotes the objects position within the Object Dictionary. This acts as a kind of address toreference the desired data field. Index shall be declared as hexadecimal value.
Index shall be used to indicate the accessed object of “by index”-type SDO commands.
Object may be subdivided to sub-indices. The sub-index is used to reference data fields within acomplex object such as an array or record. The sub-index is not specified here.

•

Object Type
Object Type contains an entry according to Tab. 37. It is used to denote what kind of object is atthat particular index within the Object Dictionary. The following definitions are used:EPSG DS 301 V1.5.1-127-

Object Type

Comments

Code

NULL
DEFTYPE

A dictionary entry with no data fields
Denotes a static data type definition such as a Boolean,
UNSIGNED16, float and so on
Defines a record typeA single value such as an UNSIGNED8, Boolean, float, Integer16,
visible string etc.
A multiple data field object where each data field is a simple
variable of the same basic or extended data type e.g. array of
UNSIGNED16 etc. Sub-index 0 is of UNSIGNED8 and therefore
not part of the ARRAY data
A multiple data field object where the data fields may be any
combination of simple variables. Sub-index 0 is of UNSIGNED8
and therefore not part of the RECORD data

05

DEFSTRUCT
VAR
ARRAY

RECORD

67
8

9

Object type definitions•

Name
Name provides a simple textual description of the function of that particular object.
Name shall be in accordance to IEC 61131-3. It consists of:
domain prefix, indicating the association of the object to a functional domain,
3 uppercase characters followed by underline
name (verbally). composed of words, each word shall be leaded by an uppercase character
followed by lowercase characters or digits, no underlines or spaces
data type postfix, indicating the data type of the object (underline followed by up to 5 uppercase
characters or digits)
Total length of name shall be equal or below 32 characters.
Name shall be used to indicate the accessed object of “by name”-type SDO commands.

•

Data TypeThe entry provides information about the data type of the object. These include the following
pre-defined static data types: Boolean, floating point number, unsigned integer, signed integer,
visible/octet string, time-of-day, time-difference and DOMAIN (see 6.1). It also includes the predefined complex data types and may also include types which are either manufacturer or device
specific.
It is not allowed to define records of records, arrays of records or records with arrays as fields ofthat record. In the case where an object is an array or a record the sub-index is used toreference one static data type data field within the object.

•

Category

Category defines whether the object is Mandatory (M) or Optional (O). A mandatory object shallbe implemented on a device. An optional object needs not to be implemented on a device. The
support of certain objects or features however may require the implementation of related
objects. In this case, the relations are described in the detailed object specification.
Category may be Conditional (Cond) if the M/O category of an object depends on theimplementation of another object.
Category may be Not-Relevant (“-“) if the object is of no meaning for MN resp. CN.
The following entries shall be indicated for static data types only. In case of complex data types therespective entries shall be provided for each sub-index individually.
•

Access
The entry defines the access rights for a particular object. The view point is from the bus into
the device. It can be one of the following:EPSG DS 301 V1.5.1
rw

-128-

read and write access, value shall not be stored on writing dedicated subindices of NMT_StoreParam_REC
read and write access, value shall be stored on writing dedicated subindices of NMT_StoreParam_REC
write only access, value shall not be stored on writing dedicated subindices of NMT_StoreParam_REC
write only access, value shall be stored on writing dedicated sub-indicesof NMT_StoreParam_REC
read only accessread only access, value is constantvariable access controlled by the device
further information about access is provided by the object description

rws
wo
wos
ro
const
cond

Access attributes for data objects
Optional objects listed in the Object Dictionary with the Attribute rw may be implemented asread only. Exceptions are defined in the detailed object specification.
Access type entries may be supplemented by additional information, e.g. reflecting data validity
restrictions.
•

Value Range
The entry indicates the value range of the respective object. It may consist of one or more
distinct values or ranges of values. If the item shows a data type identifier, the complete value
range of the mentioned data type shall be allowed.
“-“ means that this specification does not predefine a value range. In this case the value rangeof the device profile resp. device description shall apply.
Default value ranges in the device description file shall be equal to predefined default value
ranges in this specification.

•

Default Value
The entry indicates the initialisation value that shall be assigned by the communication profile
implementation.
“-“ means that this specification does not predefine a default value. In this case the default valueof the device profile resp. device description shall apply.
Default values in the device description file shall be equal to predefined default values in thisspecification.

•

PDO Mapping
The entry indicates whether an entry may be mapped to a PDO message. It can be one of thefollowing:
Opt
Def
No

Object shall be mappable into a PDO
Object is part of the default mapping (see device profile)
Object shall not be mappable into a PDO
PDO mapping attributes for data objects

A complete static data type object definition (Object Type = VAR) example is displayed below:
Index
Name
Data Type
Value Range
Default Value

1234h
SDO_VarDummyParameter_S16
INTEGER16-15 000 .. 10 000
0Static data type object definition example

Object Type

VAR

Category
AccessPDO Mapping

M
rw
Opt

EPSG DS 301 V1.5.1-129-Complex data type object definitions (Object Type = ARRAY or RECORD) are of reduced form,
because Access, Value Range, Default Value, and PDO mapping must be defined individually for thethe sub-indices
Index
Name
Data Type

2345h
SDO_ArrayDummyParameter_AU16
UNSIGNED16

Object Type

ARRAY

Category

M

Complex data type object definition example•

Categoryrefers to the complex data type object as a whole, but not to the particular sub-index. A
mandatory object may be composed of mandatory and optional sub-indices. This means thatthe object must be supported but some of its’ sub-indices are optional. It’s also allowed, todefine optional object with mandatory sub-indices. This means that these sub-indices must be
supported, if the object is implemented.

•

Data Typeshall contain a static data type in case of ARRAY type objects and a complex data type in caseof RECORD type objects.
The definition of data type describing objects (Object Type = DEFTYPE or DEFSTRUCT) is shown by
6.2.2.

6.2.1.1

Sub-Index Definition

Complex object types (ARRAY, RECORD) objects are composed of up to 256 data items. Each data
item may be addressed by an UNSIGNED8 type sub-index.
Sub-Indices are used in the following way:•

Sub-Index 00h

NumberOfEntries

NumberOfEntries describes the highest available sub-index that follows, not considering FFh.
This entry is encoded as UNSIGNED8, regardless the type of the object. If the object exists,
NumberOfEntries is mandatory. Data Type and Category are not denoted at NumberOfEntries
descriptions.
NumberOfEntries is described by this specification as displayed below:
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1..15
15

AccessPDO Mapping

rw
No

NumberOfEntries sub-index description example
In case of ARRAYs, NumberOfEntries may be modified (Access = rw) to show the umber ofoccupied items in a list. In case of RECORDs, NumberOfEntries shall be hold constant (Access= ro or Const).
NumberOfEntries may mapped to PDO to indicate the number of occupied items.
•

Sub-Index 01h - FEh

Object Specific Data

Sub-Indices between 01h and FEh hold the object’s payload data. The highest accessible index
is given by NumberOfEntries.
Sub-Indices of RECORD type objects are defined as follows:
Sub-Index
Name
Data Type
Value Range
Default Value

01h
RecItem1_U8
UNSIGNED8
1..255
1Category
AccessPDO Mapping

Record type object sub-index description example

M
rw
Def

EPSG DS 301 V1.5.1
•

-130-

Name is composed of a describing text followed by a data type postfix. Refer the object
name rules for further information, the domain prefix is omitted.
If a name entry is defined by a data type definition, the sub-index name shall be equal toit.
The sub-index name shall be used in combination to the object name to access the subindex via “by name” SDO commands. According to IEC 61131-3 object and sub-index
name shall be separated by a dot:
SDO_RecordExamle_REC.RecItem1_U8.

•

Category refers to respective sub-index only. Mandatory (M) means that the sub-index
must be implemented when the object ist implemented. A mandatory sub-index does notforce the hosting object to be mandatory.
Sub-Indices of ARRAY type objects are defined as follows:
Sub-Index
Name-Value Range
Default Value

01h
ArraySubindex1-UNSIGNED160

Category
AccessPDO Mapping

M
rw
Opt

Array type object sub-index description example
Name consists of a describing text. Refer the object name rules for further information, thedomain prefix and data type postfix are omitted. If a name entry is defined by a data typedefinition, the sub-index name shall be equal to it.

••

The sub-index name is for informational purpose only. Sub-index access via “by name”
SDO commands shall occur according to IEC 61131-3 via numerical index:
SDO_ArrayExamle_AU16[1]•Category refers to respective sub-index only. Mandatory (M) means that the sub-index
must be implemented when the object ist implemented. A mandatory sub-index does notforce the hosting object to be mandatory.

•

Despite of the functional equivalence of all sub-indices of an array, there may be defined
more than one sub-index entry to a particular object to show differences of the Category,
Access and / or PDO Mappings options of the sub-indices.

Sub-Index FFh

StructureOfObject

Sub-index FFh describes the structure of the entry by providing the data type and the object typeof the entry. Regardless the type of the object, it is encoded as UNSIGNED32 and organised asfollows:
MSB
Bit-No.
Value

31 - 2400h

LSB

23 - 16
15 - 8
Data Type (refer 6.2.2)(High Byte )(Low Byte )7-0
Object Type(refer Tab. 37)

Structure of sub-index FFh
It is optional to support sub-index FFh. If it is supported throughout the Object Dictionary and thestructure of the complex data types is provided as well, it enables to upload the entire structureof the Object Dictionary. If StructureOfEntry is not supported, sub-index FFh shall be reserved.
StructureOfObject is not shown by object definitions of this specification.

6.2.2

Data Type Entry Specification

The static data types are placed in the Object Dictionary for definition purposes only. However, indicesin the range 0001h - 0007h may be mapped in order to define the appropriate space of the RPDO
(Dummy Mapping) as not being used by the device (do not care). The indices 0009h - 000Bh, 000Fh
may not be mapped to a PDO.
See App. 1.1, index range 0001h to 04FFh for data type specifiing object dictionary entries.

EPSG DS 301 V1.5.1

6.2.2.1-131-

Static Data Types

The static data type (Object Type = DEFTYPE) representations used are detailed in 6.1.
A device may optionally provide the length of the static data types encoded as UNSIGNED32 at readaccess to the index that refers to the data type. E.g. index 000Ch (Time of Day) contains the value
30h=48d as the data type „Time of Day“ is encoded using a bit sequence of 48 bit. If the length isvariable (e.g. 000Fh = Domain), the entry contains 0h.

6.2.2.2

Complex Data Types

The predefined complex data types’ (Object Type = DEFSTRUCT) representations are provided by
the respective paragraph or by the device profile.
For the supported complex data types a device may optionally provide the structure of that data typeat read access to the corresponding data type index. Sub-index 0 then provides the number of entries
at this index not counting sub-indices 0 and 255 and the following sub-indices contain the data typeaccording to App. 3.5 encoded as UNSIGNED16.
As an example the entry at Index 0023h describing the structure of the Identity object
NMT_IdentityObject_REC looks as follows:
Index
Name

0023h
IDENTITY

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
VendorId_U32
ProductCode_U32
RevisionNo_U32
SerialNo_U32

Value
04h
0007h
0007h
0007h
0007h

Data TypeUNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

Complex data type description example
Standard (simple) and complex manufacturer specific data types can be distinguished by attempting toread sub-index 1h: At a complex data type the device returns a value and sub-index 0h contains thenumber of sub-indices that follow, at a standard data type the device aborts the SDO transfer as no
sub-index 1h available.
Note that some entries of data type UNSIGNED32 may have the character of a structure (e.g.
NMT_DeviceType_U32, see 7.2.1.1.1).

6.2.2.3

Extension for Multiple Device Modules

For devices or device profiles that provide Multiple Device Modules like multiple axis controllers e.g.
the DEFTYPE / DEFSTRUCT mechanism is enhanced for each virtual device with an offset of 40 h for
up to 7 additional virtual devices.

6.3

Service Data (SDO)

To access the entries of the object dictionary of a device via Ethernet POWERLINK a set of commandservices is specified.
SDO communication attends to the client / server model (see 2.3.2). Support of SDO client functions
shall be indicated by D_SDO_Client_BOOL, support of SDO server functions by
D_SDO_Server_BOOL.

EPSG DS 301 V1.5.1

6.3.1

-132-

SDO Layer Model
POWERLINK
Command
HeaderSDO Command Layer

POWERLINK
SequenceLayer

SDO Sequence Layer

Hosting Frame

Frame Header,Non- SDO Payload
Hosting Frame non-

Fig. 42.

SDO Payload

Data

SDO

Non- SDO Payload,
CRC

SDO payload only available at SDO embedded in PDO

SDO layer model

Two sublayers are distinguished in the POWERLINK Protocol:•

POWERLINK Sequence Layer (6.3.2.3, 6.3.3.1)
The Sequence Layer is responsible for sorting the segments of a segmented transfer commandso that a correct byte stream is offered to the POWERLINK Command Layer.

•

POWERLINK Command Layer (6.3.2.4, 6.3.3.2)
The Command Layer defines commands to access the parameters of the object dictionary. This
layer distinguishes between an expedited and a segmented transfer.

6.3.1.1

SDO Hosting in Frames

Ethernet POWERLINK provides three SDO transfer methods:
1.
SDO transfer via UDP/IP frames in asynchronous phase2.
SDO transfer via POWERLINK ASnd frames in asynchronous phase3.
SDO embedded in PDO in isochronous phase
The methods 1 (6.3.2.1) and 2 (6.3.2.2) share a common Sequence (6.3.2.3) and Command Layer(6.3.2.4).
At method 3 (6.3.3), SDO data are packed to a compact container to be inserted to the PDO data.
Sequence and Command Layer are adapted to the compact layout of the container.
On an MN, support of methods 1 and 2 shall be mandatory.
Support of method 1 shall be indicated at the object dictionary by NMT_FeatureFlags_U32 Bit 1 andand in the device description by D_SDO_SupportUdpIp_BOOL. Support of method 2 shall be indicatedby NMT_FeatureFlags_U32 Bit 2 and D_SDO_SupportASnd_BOOL.
Support of method 3 is optional at MN and CN. Support of method 3 shall be indicated at the object
dictionary by NMT_FeatureFlags_U32 Bit 3 and in the device description by
D_SDO_SupportPDO_BOOL.
Remark: The NMT_FeatureFlags_U32 are reported to the MN by IdentResponse.

6.3.2

SDO in Asynchronous Phase

6.3.2.1

SDO via UDP/IP

The parameter transfer is based on a UDP/IP frame, allowing data transfer via a standard IP-router.
Because UDP does not support a reliable connection oriented data transfer, this task must be
supported by the sequence and command services.

EPSG DS 301 V1.5.1-133-

Layer model

Frame structure
POWERLINK
Command
Layer

Application

POWERLINK
Command
Layer

POWERLINK
Sequence
Layer

POWERLINK
Sequ.

Data

Data

Transport
MessageType

UDP

Network
DLL

Ethernet
Header

Data

IP

Ethernet
CRC

Data

UDP/IP frameFig. 43.

POWERLINK SDO embedded in UDP/IP frame

SDO via UDP/IP uses the Asynchronous Sequence Layer (6.3.2.1) and the Asynchronous Command
Layer (6.3.2.2).
For applications that do not require short cycle times and low jitter, POWERLINK telegrams may beinserted in a UDP/IP datagram, in effect running POWERLINK over UDP/IP. For this reason themessage type (defined in the Data Link Layer) is inserted in front of the Sequence Layer.
Octet Offset

0
1 .. 27

6

5

Bit Offset
4
3

2

1

0

MessageType = ASnd
reserved

3
4 .. 78 .. k-1
k .. 1471

ServiceID = SDO
Sequence Layer Protocol
Command Layer Protocol
SDO Payload Data
SDO via UDP/IP

Field

Abbr.

Description

MessageTypereservedmtypresServiceID
Sequence Layer
ProtocolCommand Layer
Protocolsid

POWERLINK Message type (App. 3.1)
These fields are reserved
They are used for POWERLINK Destinationand Source Address when sending SDO
without UDP/IP
ASnd ServiceID (App. 3.3)
POWERLINK Sequence Layer (6.3.2.1)
POWERLINK Command Layer (6.3.2.2)

SDO via UDP/IP field interpretation

6.3.2.1.1

UDP Layer

The UDP Header contains:

Value
ASnd

Zero, when embedded in
UDP/IP Frameelse mt specificSDOEPSG DS 301 V1.5.1

-134-

Field

Size

Description

Used in
POWERLINK

Source Port
Destination Port
LengthChecksum

2 Byte2 Byte2 Byte2 BytePort Number of the sending process
Port Number of the receiving process
Data length of the whole UDP frame incl. header
optional Checksum

Logicalchannel15
not used
not used

UDP header
Parameters are transferred in a communication channel characterized by the IP addresses (sourceand destination) and UDP Ports (source and destination). This communication channel is known as adatagram socket. It establishes a peer-to-peer communication channel between two devices. A device
may support more than one channel. One supported server channel is the default case (Default
Channel). The default channel uses the UDP port C_SDO_EPL_PORT.
The maximum number of supported channels shall be indicated by D_SDO_MaxConnections_U32.
There may be multiple channels established between one client and one server. The maximum
number of such parallel channels shall be indicated by D_SDO_MaxParallelConnections_U32.
The client starts the transfer using the standard destination port C_SDO_EPL_PORT and a client
dependent source port (> 1024). The server responds to the request with the source port
C_SDO_EPL_PORT and the destination port defined by the client. Therefore up to (216–1024) logicalchannels (sockets) can be opened between a client and a server. Each device is responsible forhandling its logical channels.

ClientServerCreate Socket
listen socket
port C_SDO_EPL_PORT

Create Socket
source port = YYYYh (1024)
destination port =C_SDO_EPL_PORT

UDP
source port = YYYYh
destination port =C_SDO_EPL_PORT
port YYYYhclient IP address

logicalchannel 1

UDP
source port =C_SDO_EPL_PORT
destination port = YYYYh

Create Socket
source port = ZZZZh (1024)
destination port =C_SDO_EPL_PORT

UDP
source port = ZZZZhdestination port =C_SDO_EPL_PORT
UDP
source port =C_SDO_EPL_PORT
destination port = ZZZZhFig. 44.

UDP socket

15 in combination with the client and server IP address.

port ZZZZhclient IP address

logicalchannel 2

EPSG DS 301 V1.5.1

6.3.2.2-135-

SDO via POWERLINK ASnd

SDO via POWERLINK ASnd applies POWERLINK frames for SDO communication.
Since POWERLINK frames are not forwarded by a POWERLINK Router Type 1 (s. 9.1), it is notpossible to access nodes exclusively providing SDO via POWERLINK ASnd from outside of the
POWERLINK segment.
SDO transfer by POWERLINK ASnd frames is well suited for devices providing reduced ressources,
because it does not require an IP stack.
Octet Offset

7

6

Bit Offset
4
3

5

0
1
2
3
4 .. 78 .. k-1
k .. 1471

2

1

0

MessageType = ASnd
Destination
SourceServiceID = SDO
Sequence Layer Protocol
Command Layer Protocol
SDO Payload Data
SDO via POWERLINK ASnd

Field

Abbr.

Description

MessageType
Destination

mtyp
dest

SourceServiceID
Sequence Layer
ProtocolCommand Layer
Protocol

src
sid

ASnd
POWERLINK Message type (App. 3.1)
POWERLINK Node ID of the addressed
node(s)POWERLINK Node ID of the transmitting node
SDO
ASnd ServiceID (App. 3.3)
POWERLINK Sequence Layer (6.3.2.3)

Value

POWERLINK Command Layer (6.3.2.4)

SDO via ASnd field interpretation
SDO via POWERLINK ASnd applies the Asynchronous Sequence Layer (6.3.2.3) and the
Asynchronous Command Layer (6.3.2.4).

6.3.2.3

Asynchronous SDO Sequence Layer

The POWERLINK Sequence Layer provides the service of a reliable bidirectional connection thatguarantees that no messages are lost or duplicated and that all messages arrive in the correct order.
Fragmentation is handled by the SDO Command Layer (6.3.2.4).
The POWERLINK Sequence Layer Header for asynchronous transfer shall consist of 2 bytes.
There shall be a sequence number for each sent frame, and an acknowledgement for the sequencenumber of the opposite node, as well a connection state and a connection acknowledge.
Octet Offset

0
1
2 .. 37

6

5

Bit Offset
4
3

2

ReceiveSequenceNumber
SendSequenceNumber

10ReceiveCon
SendConreserved
POWERLINK sequence layer in asynchronous data frame

Remark:Using bits 0 and 1 for connection instead of bits 6 and 7 eases the handling of sequence number. The
sequence number easily can be increased by one by increasing the whole byte by four. This
increment has no influence to ReceiveCon and SendCon.

EPSG DS 301 V1.5.1

-136-

Field

Abbr.

Description

Value

ReceiveSequenceNumber

rsnr

0 ... 63

ReceiveCon

rcon

Sequence number of the lastcorrectly received frame
Acknowledge of connection code
to the opposite node

SendSequenceNumber

ssnr

SendConscon

Own sequence number of theframe, shall be increased by 1with every new frame
Own connection code

0: No connection
1: Initialisation
2: Connection valid
3: Error Response(retransmission request)
0 ... 63

0: No connection
1: Initialisation
2: Connection valid
3: Connection valid withacknowledge request

Fields of POWERLINK sequence layer in asynchronous data frame

6.3.2.3.1

Connection

6.3.2.3.1.1

Initialisation of Connection

The client shall request initialisation by setting scon to 1. This shall be responded by the server withthe same connection code and the same sequence number.
If the server had already a connection to the client the existing connection shall be shut down, i.e.
closed internally without sending an explicit close request before opening the new one.
Additionally the sequence number shall be initialised at the server.

Client
The client requests a
connection

The client responds tothe initialization requestof the server and sets
the connection to valid

Fig. 45.

Serverm1 (rsnr = ?, rcon = 0,

ssnr = i, scon = 1)

m2 (rsnr = i, rcon = 1,

ssnr = j, scon = 1)

m3 (rsnr = j, rcon = 1,

ssnr = i, scon = 2)

m4 (rsnr = i, rcon = 2,

ssnr = j, scon = 2)

The server
acknowledges therequest andrequests a
connection too

The server sets theconnection to valid
too

Initialisation of a asynchronous connection

After this the bidirectional connection is established.
The sequence numbers shall not be incremented until the bidirectional connection initialisation has
been completed. It shall be increased by 1 for the first SDO command after the initialisation. No
command shall be sent while initialising the bidirectional connection.

6.3.2.3.1.2

Closing a connection

A connection should be shut down, when it is no longer needed.
A node, i.e. client or server, may shut down a connection, if it needs the resources for other reasons.
Clientresp.
ServerThe client/server requests
a shut down of theconnection

Fig. 46.

Serverresp.
Clientm1 (rsnr = ?, rcon = 0,

ssnr = ?, scon = 0)

Closing of asynchronous connection

The server/client
shuts down theconnection, there is
no response!

EPSG DS 301 V1.5.1-137-

Closing a connection shall be indicated by rcon = 0 and scon = 0.
There shall be no acknowledge for closing a connection.

6.3.2.3.1.3

Data Transfer

When the connection is established each node is allowed to send frames.
Each node shall keep the sent data in a history buffer until it is acknowledged. Size of the history
buffer is indicated by D_SDO_SeqLayerTxHistorySize_U16. If all history buffer slots are occupied byunacknowledged frames, no additional frame may be sent (see 6.3.2.3.1.5).
Each sent frame shall contain the acknowledgement of the last correctly received frame from the
opposite side.
When the sender sends an acknowledge request, the receiver shall send an acknowledge.

ClientServerm1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = j, rcon = 2,

ssnr = i+2, scon = 2)

m4 (rsnr = j, rcon = 2,

ssnr = i+3, scon = 2)

m5 (rsnr = i+3, rcon = 2,

ssnr = j+1, scon = 2)

m6 (rsnr = j+1, rcon = 2,

ssnr = i+4, scon = 2)

m7 (rsnr = i+4, rcon = 2,

ssnr = j+1, scon = 2)

Send anacknowledgementwith the last
acknowledged ssnr,
if there is no data to
be sent from client toserverNo communication
until one of the twosides has something
to send.
m8 (rsnr = j+1, rcon = 2,

If the client has
new data

m9

ssnr = i+5, scon = 2)

(rsnr = i+5, rcon = 2,

ssnr = j+1, scon = 2)

m10 (rsnr = i+5, rcon = 2,

m11 (rsnr = j+2, rcon = 2,

Fig. 47.

ssnr = j+2, scon = 2)

If the server has
new data

ssnr = i+5, scon = 2)

Normal asynchronous communication

If the receiver has no new data to transmit it shall send an acknowledge frame to the sender, that
contains the last sent ssnr. If that ssnr was already acknowledged, the data may be omitted, because
the other side will drop the data (as repeated) anyway.
Because of the sliding window protocol only half of the sequence number range may be used. So the
maximum possible History Buffer size is 31. Otherwise it is not possible to distinguish between old
duplicated frames and new frames.
On the receiving node no buffering of the received frames is required. This may cause flooding of thereceiving node with commands (cf. 6.3.2.3.2.6).

6.3.2.3.1.4

Data Transfer with Delay

Due to delays in network, hardware and software layers it may take some cycles until the frame isreceived by the receiver, and the acknowledge gets back to the sender.

EPSG DS 301 V1.5.1-138-

The sender shall not forward more than D_SDO_SeqLayerTxHistorySize_U16 frames before receiving
an acknowledgement.
This example shows a configuration where the frames are delayed. A typical situation where frames
are delayed is when POWERLINK Networks are connected by means of routers over a legacy
Ethernet.

ClientServer

m1 (r
m2 (r
s

nr =

m3 (r
s

m4 (r

m5 (r

m7 (r

Fig. 48.

sn r =

j, rconr =sn r =

sn r =

sn r =

j, rcon=2

n=2j, rco,n=2i+1, rc

,

on =

ssn r
ssn r

,

2,
on =
i+2, rc m6(rsnr

j+2, rc

on =

2,

= i+1

ssn r

2,

= i, s

, sco

= i+2

ssn r

ssn r

, sco

= i+4

)

n=2

, sco
= j+2

on =

2)

n=2

, sco
= j+1

= j, rcssn r

co n =

2,

, sco

)

n=2

)

n=2

)

ssn r

= i+3

, sco

n=2

)

n=2
)

Delayed asynchronous communication

6.3.2.3.1.5

Sender History Full

When the buffer for keeping frames is full (sliding window size exhausted), the sending node may
explicitly request an acknowledgement by sending a frame with acknowledge request.
The receiver shall acknowledge this frame with an empty acknowledge frame, if it has no frames of its
own to be sent.

ClientHistory buffer is fullServerm1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2

m3 (rsnr = j, rcon = 2,

ssnr = i+2, scon = 2)

m4 (rsnr = j, rcon = 2,

ssnr = i+3, scon = 3)

m5 (rsnr = i+3, rcon = 2, ssnr = j, scon = 2)

Client can discard
history buffers when aacnowledge is received

m6 (rsnr = j, rcon = 2,

Fig. 49.

6.3.2.3.2

ssnr = i+4, scon = 2)

Asynchronous communication when history buffer gets fullErrorsErrors that may occur in the physical and data link layer:•

send requested
acknowledge

Loss of frames

EPSG DS 301 V1.5.1

-139-

•

Duplication of frames•

Overtaking of frames•
Broken connection
Errors that may occur in the sequence layer:•

Flooding with commands

6.3.2.3.2.1

Error: Loss of Frame with Data
ClientServerm1 (rsnr = j , rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j , rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = j , rcon = 2,

ssnr = i+2, scon = 2)

m4 (rsnr = j , rcon = 2,

ssnr = i+3, scon = 2)

Server detects
unexpectedsequence number

m5 (rsnr = i+1, rcon = 3, ssnr = j, scon = 2)

Repeat data from history
bufferm6 (rsnr = j , rcon = 2,

ssnr = i+2, scon = 2)

Repeat data from history
bufferm7 (rsnr = j , rcon = 2,

ssnr = i+3, scon = 2)

m8 (rsnr = j , rcon = 2,

ssnr = i+4, scon = 2)Continue with new data

Fig. 50.

Send error
acknowledge

Error loss of asynchronous frame

If the receiver detects a sequence number that is more than 1 higher than the last correctly received
sequence number, it shall respond with rcon=3 and the last correctly received sequence number toindicate this error.
This error response may contain data (from the command layer).
The sender shall repeat all the frames that followed the responded sequence number.
The acknowledge fields in the repeated frames shall be updated.

6.3.2.3.2.2

Error: Loss of Acknowledge Frame
ClientRepeat with acknowledge
requestFig. 51.

Serverm1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = i+1, rcon = 2,

ssnr = j, scon = 2)

m4 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 3

m5 (rsnr = i+1, rcon = 2,

ssnr = j, scon = 2)

Data is dropped,
send the requested
acknowledge

Error loss of asynchronous acknowledge

If the sender is waiting for an acknowledgement and has no new frames to be sent, it shall repeat thelatest message with acknowledge request after a timeout.

EPSG DS 301 V1.5.1

6.3.2.3.2.3-140-

Error: Duplication of Frame
ClientDuplication caused bylower communication
layersServerm1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)

m4 (rsnr = j, rcon = 2,

ssnr = i+2, scon = 2)

m5 (rsnr = i+2, rcon = 2,

Fig. 52.

Data is dropped

ssnr = j, scon = 2)

Error duplication of asynchronous frame

If the receiver detects a sender sequence number that is lower than or equal to the last correctly
received sequence, it shall drop that message.
If that message has scon=2 no further action is required.
If that message has scon=3 the receiver shall acknowledge the last correctly received sequence to thesender.

6.3.2.3.2.4

Error: Overtaking of Frames

When a frame overtakes, the receiver at first detects a lost frame. The receiver shall send an error
response to the sender so that the sender repeats the frame.
Then the overtaken frame arrives at the receiver and is accepted.
After this the repeated frame arrives and is dropped at the receiver, because it is recognized as a
duplicated frame.
Remark:Overtaking of frames will never occur inside the POWERLINK network domain. Only on connections
over Internet using Type I routers overtaking can occur on the Legacy Ethernet side.

6.3.2.3.2.5

Broken Connection

It shall be detected, that the connection is broken, if the opposite node is shut down or disconnectedfrom the network.
The connection shall be considered broken when no acknowledgement is received within the timeout
given by SDO_SequLayerTimeout_U32.
Within this timeout multiple acknowledge requests shall be sent (see 6.3.2.3.2.2). The number of
acknowledge requests to be sent shall be described by SDO_SequLayerNoAck_U32. If
SDO_SequLayerNoAck_U32 is not implemented a minimum value of C_SDO_SEQULAYERNOACK
shall be used instead.

EPSG DS 301 V1.5.1-141-

ClientServerRepeat withacknowledge request

m1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 3)

Server is
disconnectedor shut down.
.
.
Repeat withacknowledge request
Timeout no response
despite acknowledge
request, shut down theconnection when giving up

Fig. 53.

m3 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 3)m3 (rsnr = ?, rcon = 0,

ssnr = ?, scon = 0)

Error asynchronous communication broken

6.3.2.3.2.6

Error: Flooding with commands
ClientServerm1 (rsnr = j, rcon = 2,

ssnr = i, scon = 2)m2 (rsnr = j, rcon = 2,

ssnr = i+1, scon = 2)m3 (rsnr = j, rcon = 2,

ssnr = i+2, scon = 2)

m4 (rsnr = i+1, rcon = 3,

Repeat data from history
bufferFig. 54.

The shut down may or
may not arrive at theserver. It is necessary
to shut down
connections, in thespecial case where allframes from the serverto the client are lost.

m5 (rsnr = j, rcon = 2,

ssnr = j, scon = 2)

Server's commandlayer did not fetch m2
yet, so drop m3 andrepeat request

ssnr = i+2, scon = 2)

Error flooding with asynchronous commands

If the sender sends commands at a rate too high, the command layer at the receiver may not be able
to process the commands in time. In this case the sequence layer on the receiver side drops newly
arriving frames and shall send an acknowledgement of the last correctly handled frame and a rcon=3
back to the sender.
This causes the sender to repeat the dropped frame, and the receiver gains some time to handle therequest.
This shall not be misused as a flow control mechanism, flow control shall be done in higher layers.

6.3.2.4

Asynchronous SDO Command Layer

Tasks of the POWERLINK Command Layer
1.
Addressing of the parameters, e.g. via index/sub-index or via name2.
Provide additional services
3.
Distinguish between expedited and segmented transfer
The POWERLINK Command Layer is embedded in the POWERLINK Sequence Layer. If a large blockis to be transferred the POWERLINK Command Layer has to decide whether the transfer can becompleted in one frame (expedited transfer) or if it must be segmented in several frames (segmented
transfer). Further it has to know whether an Upload or a Download should be initiated.
For all transfer types it is the client that takes the initiative for a transfer. The owner of the accessed
object dictionary is the server of the Service Data Object (SDO). Either the client or the server cantake the initiative to abort the transfer of a SDO. All commands are confirmed. The remote result

EPSG DS 301 V1.5.1-142-

parameter indicates the success of the request. In case of a failure, an Abort Transfer Request must
be executed.
Fig. 55 shows the structure of the information in the POWERLINK Command Layer Header.
CommandDirection

Segmentation
Expedited
Segmented

RequestInitiate
Segment
Complete

Expedited
CommandID
Segmented
Response

Initiate
Segment
Complete

Abort

Fig. 55.

Expedited

Information structure of POWERLINK command layer

6.3.2.4.1

POWERLINK Command Layer Protocol

This chapter defines the fixed part of the POWERLINK Command Layer protocol.
The POWERLINK Command Layer is structured in the following way:
Octet
Offset16

7

6

0
1
2

5

Bit Offset
4

3

2

1

reserved
Response

Abort

Transaction ID
Segmentation

0

Fixed part
reserved

3
4 .. 56 .. 7

Command ID
Segment Size
reserved

8 .. 11(8 + 4*d) ..
k-1
k .. 1463

Data Size (only if Segmentation = Initiate)
Command ID specific header
Optional Payload Datak = Length of Command ID specific header; k < 1464
d: if seg = Initiate d = 1
else
d=0

POWERLINK command layer

16 Offset related to beginning of POWERLINK command layer.

Variable part
Command ID specificpartEPSG DS 301 V1.5.1
Field
reserved-143-

Response

Abbr. Description
Reserved
resThis byte is used when embedding the SDO in
cyclic data (chapter 6.3.3).
tidUnambiguous transaction ID for a command.
Changed by the client with every new command.
rsp
Request / Response

Abort

a

Segmentationseg

Command ID
Segment Sizecid
ss

Data Size

ds

Transaction ID

Command ID specific

The requested Transfer could not be completed
by the client/server
Differentiates between expedited and segmented
transferValue
0

0 – 255
0: Request
1: Response
0: transfer ok
1: abort transfer
0: Expedited Transfer
1: Initiate Segment Transfer
2: Segment
3: Segment Transfer Complete
see Tab. 58
256 –1456

Specifies the command
Length of segment data.
Counting from the end of the command header(beginning with octet offset 8)
Contains the number of bytes of the transferred0 – 232-1
block.
Counting from the end of the command header(beginning with octet offset 8)
Only used for the Initiate SegmentTransfer Frame(seg = Initiate)If ds = 0000h, the size is not indicatedSpecifies the command referenced by the cid.
See 6.3.2.4.2

POWERLINK command layer field interpretation
The Transaction ID may be used to support several logic channels parallel via the same UDP socket
resp. ASnd channel.
The Segment Size (ss) indicates the length of the segment in the command layer, i.e. the valid data
length in the command layer. A minimum size of 256 bytes must be supported by every device. A
maximum of 1456 bytes (i.e. 1500 byte payload data for the Ethernet frame) may be supported. The
client can use the command “Maximum Segment Size” (see 6.3.2.4.2.4.1) to get the maximum usable
size for a communication to a server.
Note: The maximum segment size is limited to 1456 bytes, because an Ethernet frame can carry amaximum of 1500 bytes. In case of SDO via UDP all the remaining bytes are needed for the protocol
overhead (IP (20 bytes), UDP (8 bytes), message type / service ID / etc. (4 bytes), POWERLINK
Sequence Layer (4 bytes) and the fixed part of the POWERLINK Command Layer (8 bytes)). In caseof SDO via ASnd the maximum possible length of 1500 bytes is not fully used because the protocol
overhead is shorter (message type / service ID / etc. (4 bytes), POWERLINK Sequence Layer (4bytes) and the fixed part of the POWERLINK Command Layer (8 bytes)). However this guarantees an
SDO command layer independent of the underlaying transfer method (UDP/IP or ASnd).
Ethernet
HeaderIP

UDP

Msg. POWERLINK POWERLINK
Type Sequ. Layer Command Layer

Payload Data

Ethernet
CRC

opt.
fix
cmd.
Data
part
spec.
Size
Segment SizeFig. 56.

Definition of segment size

For Initiate Segmented Transfer (seg=1) the number of bytes to be transferred in the command isindicated in the Data Size field. Therefore the offset for the Command ID specific header is 8
(Expedited Transfer) or 12 (Initiate Segmented Transfer) (cf. Tab. 54).

EPSG DS 301 V1.5.1

6.3.2.4.1.1-144-

Download Protocol

The download service is used by the SDO client to download data to the server (owner of the object
dictionary).
Expedited Download Transfer Command Layer)
ClientServerrequesttidyrsp a seg
0 0 exp.

Expedited Transfer
cid
ss
x

confirmationtidyrsp a seg
1 0 exp.

TransferResponse
cid
ss
x

cid specificheaderpayload data

indication

response

Domain Download Transfer (Command Layer)
ClientServerInitiate Domain Transfer
cid
ssdata size cid specificxheaderrequesttidyrsp a seg
0 0 init.

requesttidyrsp a seg
0 0 seg.

cidxrequesttidyrsp a seg
0 0 seg.

cidxrequesttidyrsp a seg
0 0 comp.

Domain Transfer Complete
cid
ss
x

confirmationtidyrsp a seg
1 0 exp.

TransferResponse
cid
ss
x

payloaddata

indication

Segment
ss

payload datasspayload data

indication

Segment

Fig. 57.

payload data

indication

indication

response

POWERLINK command layer: Typical download transfer

In an expedited download, the data identified by the cid specific header is transferred to the server.
In a segmented transfer SDOs are downloaded as a sequence of zero or more Download SDO
Segment services preceded by an Initiate SDO Download service and followed by a Segment Transfer
Complete frame. The sequence is terminated by:••

A response/confirm, indicating the successful completion of a normal download sequence.

An Abort SDO Transfer request/indication, indicating the unsuccessful completion of thedownload sequence.
The SDO Sequence Layer is not shown in Fig. 57. There may be more frames involved in theinitialisation of the SDO Sequence Layer, see chapter 6.3.2.3 for details.

EPSG DS 301 V1.5.1

6.3.2.4.1.2-145-

Upload Protocol

The Upload service is used by the SDO client to upload data from the server.
Expedited Upload Transfer (Command Layer)
ClientServerrequesttidyrsp a seg
0 0 exp.

UploadTransfer
cid
ss
x

confirmationtidyrsp a seg
1 0 exp.

Expedited Transfer Response
cid
ss
x

cid specificheaderindication

payload data

response

Domain Upload Transfer (Command Layer)
ClientServerUploadTransfer
cid
ss
x

requesttidyrsp a seg
0 0 exp.

confirmationtidyInitiate Domain Upload Transfer
rsp a segcidclldata size
1 0 init.
x

confirmationtidyrsp a seg
1 0 seg.

cidx

confirmationtidyrsp a seg
1 0 seg.

cidx

confirmationtidyrsp a seg
1 0 comp.

cid specificheaderindication

payload data

response

Segment
ss

payload datasspayload data

response

Segment

Fig. 58.

Domain Transfer Complete
cid
ss
x

payload data

response

response

POWERLINK command layer: Typical upload transfer

If an expedited upload is successful, the service concludes the upload of the data set identified by thecid specific header and the corresponding data is confirmed.
In a segmented transfer, SDOs are uploaded as a sequence of zero or more Upload SDO Segment
services preceded by an Initiate SDO Upload service and followed by a Segment Transfer Complete
frame. The sequence is terminated by:•

The Segment Transfer Complete frame, indicating the successful completion of a normal upload
sequence.

•

An Abort SDO Transfer request/indication, indicating the unsuccessful completion of the upload
sequence.

EPSG DS 301 V1.5.1

6.3.2.4.1.3-146-

Abort Transfer

The Abort Transfer service aborts the up- or download referenced by the Transaction ID. The reason
is indicated.
Abort Transfer Client → Server
ClientServerUpload / Download Protocol (Expedited, Initiate, Segment, End)request /confirmationtidyrequestrsp a seg
0 1 exp.

indication /response

Abort Transfer requestcidss
Abort Codex

indication

Abort Transfer Server → Client
ClientServerUpload / Download Protocol (Expedited, Initiate, Segment, End)request /confirmation

indication /response

Abort Transfer requesttidyconfirmation

Fig. 59.

rsp a seg
1 1 exp.

cid
x

ss

Abort Coderesponse

Abort transfer

The Abort service is unconfirmed. The service may be executed at any time by either the client or theserver of a SDO. If the client of a SDO has a confirmed service outstanding, the indication of the abort
is taken to be the confirmation of that service.
Octet Offset

70

reserved

1
2

6

Res- Abort
ponse
1

3
4 .. 56 .. 7

Bit Offset
4
3

5

2

1

0

Transaction ID
Segmentation reserved
Command ID
Segment Size

reserved

8 .. 11

Abort Code

Abort transfer frame
Field

Abbr.

Description

Value

Abort Codeac

Reason of the abort

see App. 3.10

Abort transfer frame field interpretation
The abort code is encoded as UNSIGNED32. A list of SDO abort codes is provided by App. 3.10.

EPSG DS 301 V1.5.1

6.3.2.4.2-147-

Commands

This chapter describes the Command ID specific part of the POWERLINK Command Layer.
CommandCommand Description // Device Description Entry

Cmd IDM/O

NIL17
SDO Protocol
Write by Index

Not in List

0h

M

Write a parameter,
addressing via index/sub-index
Read a parameter,
addressing via index/sub-index
Write a parameter,
addressing via index, all sub-indices //D_SDO_CmdWriteAllByIndex_BOOL
Read a parameter,
addressing via index, all sub-indices //D_SDO_CmdReadAllByIndex_BOOL
Write a parameter, addressing via name //D_SDO_CmdWriteByName_BOOL
Read a parameter, addressing via name //D_SDO_CmdReadByName_BOOL

1h

M

2h

M

3h

O

4h

O

5h

O

6h

O

Simple file transfer //D_SDO_CmdFileWrite_BOOL
Simple file transfer //D_SDO_CmdFileRead_BOOL

20h

O

21h

O

31h

O

32h

O

70h
80h –
FFh

Cond18O

Read by Index
Write All by Index

Read All by Index

Write by Name
Read by Name
File Transfer
File Write
File Read

Variable groups
Write Multiple Parameter Write multiple parameter within one command,by Index
addressing via index/sub-index //D_SDO_CmdWriteMultParam_BOOL
Read Multiple Parameter Read multiple parameter within one command,by Index
addressing via index/sub-index //D_SDO_CmdReadMultParam_BOOL
Parameter Services
Maximum Segment Size Exchange the maximum segment size
Manufacturer specificCommand services and command ID

Support of particular commands is optional. Support shall be indicated by device description entries(c.f. Tab. 58).

6.3.2.4.2.1

SDO Protocol

Note: The Download Protocol (6.3.2.4.1.1, including Fig. 57) is used for write commands and theUpload Protocol (6.3.2.4.1.2, including Fig. 58)is used for read commands.

6.3.2.4.2.1.1 Command: Write by Index
Using the Write by Index service the client of a SDO downloads data to the server (owner of the object
dictionary). The data, the multiplexor (index and sub-index) of the data set that has been downloaded
and its size (only for segmented transfer) is indicated to the server.

17 The NIL command shall be ignored on the command layer but processed at the sequence layer,that is the sequence layer shall send an acknowledge response but the NIL command will otherwise
be ignored.
18 Conditional: Only necessary if a segment size > 256 Byte should be transferredEPSG DS 301 V1.5.1

Octet Offset

-148-

7

0 .. 78 .. 11(8 .. 9) + 4*d
10 + 4*d
11 + 4*d

6

Bit Offset
4
3

5

1

0

reserved(12 + 4*d) .. 1463
d: if seg = Initiateelse

2

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Index
Sub-Index
Payload Data

d=1
d=0

Command: Write by Index request
Field

Abbr.

Description

Value

Index
Sub-Indexi
si

Specifies an entry of the device object dictionary
Specifies a component of a device object dictionary entry

0 .. 65535
0 .. 254

Write by Index request field interpretation

6.3.2.4.2.1.2 Command: Read by Index
Using the Read by Index service the client of a SDO requests that the server upload data to the client.
The multiplexor (index and sub-index) of the data set whose upload is initiated is indicated to theserver.
Octet Offset

7

0 .. 78 .. 910
11

6

Bit Offset
4
3

5

2

1

0

Command Layer (fixed part)Index
Sub-Index
reserved
Command: Read by Index Request

Field

Abbr.

Description

Value

Index
Sub-Indexi
si

Specifies an entry of the device object dictionary
Specifies a component of a device object dictionary entry

0 .. 65535
0 .. 254

Read by Index request field interpretation

6.3.2.4.2.1.3 Command: Write All by Index
Using the Write All by Index service the client of a SDO downloads data to the server (owner of theobject dictionary). The service addresses all sub-indices (except sub-index 0) of the indicated index.
The length of the payload data must confirm to the length of data for all sub-indices and all sub-indicesmust be writable.
Octet Offset

7

0 .. 78 .. 11(8 .. 9) + 4*d
10 + 4*dreserved

11 + 4*dreserved(12 + 4*d) .. 1463
d: if seg = Initiate
else

6

5

Bit Offset
4
3

2

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Index

Payload Data

d=1
d=0

Command: Write All by Index request

1

0

EPSG DS 301 V1.5.1

-149-

Field

Abbr.

Description

Value

Index

i

Specifies an entry of the device object dictionary

0 .. 65535

Write All by Index request field interpretation

6.3.2.4.2.1.4 Command: Read All by Index
Using the Read All by Index service the client of a SDO requests that the server upload data to theclient. The service addresses all sub-indices (except sub-index 0) of the indicated index. All subindices must be readable.
Octet Offset

0 .. 78 .. 910 .. 117

6

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)Index
reserved
Command: Read All by Index Request

Field

Abbr.

Description

Value

Index

i

Specifies an entry of the device object dictionary

0 .. 65535

Read All by Index request field interpretation

6.3.2.4.2.1.5 Command: Write by Name
Using the Write by Name service the client of a SDO downloads data to the server. The data, thename of the data set that has been downloaded and its size (only for segmented transfer) areindicated to the server.
Octet Offset

7

0 .. 78 .. 11(8 .. 9) + 4*d(10 + 4*d) .. (k – 1)
k .. 1463

65

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Offset Payload Data (k)Name
Payload Datak = Offset of the name length; k < 1464, 4-aligned
d: if seg = Initiate d = 1
else
d=0

Command: Write by Name request
Field

Abbr.

Description

Value

Offset Payload Data

opd

0 .. 1463

NamenSpecifies the beginning of the payload data (in bytes)
in this segment, counting from end of the fixedcommand header (beginning with octet offset 8)
Specifies an entry of the device object dictionary

Write by Name request field interpretation•

The name may not be terminated by a \0.

•

The definitions made in IEC 61131-3 for identifiers are adapted to the name conventions19.
These are:•

A name is a sequence of characters, dots, digits and underlines, beginning with acharacter or an underline.

•

Underlines shall be significant in identifiers, e.g. A_BC and AB_C are different identifiers.

•

Multiple leading or embedded underlines are not allowed.

•

Identifiers shall not contain embedded space (SP) characters.

19 The IEC 61131-3 defines several keywords utilized as individual syntax elements. These keywords

shall not be used as a parameter name. POWERLINK does not define further keywords.

EPSG DS 301 V1.5.1
•

-150-

At least six unique characters shall be supported in all systems.

•
The payload data shall be 4-byte-aligned. Therefore the name may have to be padded.
The Write by Name service is defined to access application objects (e.g. global variables) that do nothave an index/sub-index.

6.3.2.4.2.1.6 Command: Read by Name
Using the Read by Name service the client of a SDO requests that the server upload data to the client.
The name of the data set whose upload is initiated is indicated to the server.
Octet Offset

7

0–7
8 – 11(8 + 4*d) .. k

6

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)Name

k < 1464
d: if seg = Initiate
else

d=1
d=0

Command: Read by Name request
Field

Abbr.

Description

Value

Name

N

Specifies an entry of the device object dictionary

see 6.3.2.4.2.1.5

Read by Name request field interpretation
The payload data shall be 4-byte-aligned. Therefore the name may have to be padded.
The Read by Name service is defined to access application objects (e.g. global variables) that do nothave an index/sub-index.

6.3.2.4.2.2

File Transfer

A simple File transfer protocol is defined.
For file access, in addition to the naming conventions (see 6.3.2.4.2.1.5) the valid character set isextended with the characters:•“/” and “\”

•

“*”

•
“:”
A file open/close service is not defined because this would cause related services with different
Command IDs.

6.3.2.4.2.2.1 Command: File Write
The File Write protocol combines several typical operation system commands for file access:•File open•

File seek•

File write
Octet Offset

0 .. 78 .. 11(8 .. 11) + 4*d(12 .. 13) + 4*d(14 .. 15) + 4*d(16 + 4*d) .. (k – 1)
k .. 1463

76

5

Bit Offset
4
3

2

1

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Address
Offset Payload Data (k)reserved
File Name
Payload Datak = Offset of the payload data; k < 1464, 4-aligned
d: if seg = Initiate d = 1
else
d=0

0

EPSG DS 301 V1.5.1-151-

Command: File Write request
Field

Abbr.

Description

Value

Address
Offset Payload
Data

addr
opd

0 .. 232-1
0 .. 1463

File Name

fn

Address of the data from the beginning of the file.
Specifies the beginning of the payload data (in bytes)
in this segment, counting from the end of the fixedcommand header (beginning with octet offset 8)File name (complete path)

File Write request field interpretation
The Address field indicates the relative address of the data in the file.

6.3.2.4.2.2.2 Command: File Read
Octet Offset

7

0 .. 78 .. 11(8 .. 11) + 4*d(12 + 4*d) .. kk < 1464
d: if seg = Initiate
else

6

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Address
File Name

d=1
d=0

Command: File Read request
Field

Abbr.

Description

Value

Address
File Nameaddr
fn

Address of the data from the beginning of the file.
File name (complete path)

0 .. 232-1

File Read request field interpretation

6.3.2.4.2.3

Variable groups

6.3.2.4.2.3.1 Command: Write Multiple Parameter by Index
Using the Write Multiple Parameter by Index service the client of a SDO downloads multiple data sets
to the server. The data, the multiplexor (index and sub-index) of the data sets that are downloaded
and the size of the transfer (only for segmented transfer) are indicated to the server.
A device shall be able to process this command up to a size which can be transferred in a maximum
sized Ethernet frame.

EPSG DS 301 V1.5.1-152-

6.3.2.4.2.3.2 Write Multiple Parameter by Index Request
Octet Offset

7

0 .. 78 .. 11(8 .. 11) + 4*d(12 .. 13) + 4*d
14 + 4*d
15 + 4*dreserved

6

5

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Octet Offset of next Data Set (k)Index
Sub-Index
Padding Length(16 + 4*d) .. (k – 1)
k .. (k + 3)
(k + 4) .. (k + 5)
k+6
k+7
reserved

Payload Data
Octet Offset of next Data Set (m)Index
Sub-Index
Padding Length(k + 8) .. (m – 1)
m…
d: if seg = Initiate
elsek, m 4-aligned

Bit Offset
43…

Payload Data
(further write requests)

d=1
d=0

Command: Write Multiple Parameter by Index Request
Field

Abbr.

Description

Value

Octet Offset ofnext Data Set

o2d

0 .. 232-1

Index
Sub-Index
Padding
LengthreservedisiplOctet offset of the next data set. The value is the absoluteoffset, counting from the beginning of the fixed command
header (beginning with octet offset 0)
If o2d=ZERO the last data set has been reached.
Specifies an entry of the device object dictionary
Specifies a component of a device object dictionary entry
Number of padding bytes in the last quadlet (4-byte word) of
the payload data
Reserved for future use.

res

Write Multiple Parameter by Index request field interpretation

6.3.2.4.2.3.3 Write Multiple Parameter by Index Response
Octet Offset

7

0 .. 78 .. 11(8 .. 9) +.4*d
10 + 4*d
11 + 4*d(12 .. 15) + 4*d(16 .. 17) + 4*d
18 + 4*d19 + 4*d(20 .. 23) + 4*d
24 …
d: if seg = Initiate
else

6

5

Bit Offset
4
3

2

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Index
Sub-Index
SubAbort reserved
Sub-Abort Code
Index
Sub-Index
SubAbort reserved
Sub-Abort Code… (further write responses)

d=1
d=0

Command: Write Multiple Parameter by Index Response

100 .. 65535
0 .. 254
0 .. 30

EPSG DS 301 V1.5.1

-153-

Field

Abbr.

Description

Value

Index
Sub-Indexisi

0 .. 65.535
0 .. 254

Sub-Abortsareserved
Sub-Abort Code

res
sac

Specifies an entry of the device object dictionary
Specifies a component of a device object dictionaryentry
The requested transfer could not be processed by theserverReserved for future use
Reason of the sub-abort

0: transfer ok
1: abort transfer
0
see App. 3.10

Write Multiple Parameter by Index response field interpretation
In the response a list of all invalid object accesses is transferred.
The list entries consist of the index and sub-index of the object, a sub-abort flag (sa) and the sub-abort
code (sac).
The abort flag (a) in the command header is set only if the data contain one single abort code insteadof a response list. E.g. “Command ID not valid or unknown”.
If all accesses are valid and processed by the server the command specific header is empty, i.e. theabort flag (a) is not set and the list of faulty accesses is empty.

6.3.2.4.2.3.4 Command: Read Multiple Parameter by Index
Using the Read multiple parameter service the client of a SDO requests that the server for upload
multiple data sets to the client. The multiplexor (index and sub-index) of the data sets whose upload is
initiated is indicated to the server.
A device shall be able to process this command up to a size which can be transferred in a maximum
sized Ethernet frame.

6.3.2.4.2.3.5 Read Multiple Parameter by Index Request
Octet Offset

7

0 .. 78 .. 11(8 .. 9) + 4*d
10 + 4*d
11 + 4*d(12 .. 13) + 4*d
14+4*d15+4*d6

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Index
Sub-Index
reserved
Index
Sub-Index
reserved

16 …

… (further read requests)

d: if seg = Initiate
else

d=1
d=0

Command: Read Multiple Parameter by Index request
Field

Abbr.

Description

Value

Index
Sub-Index
reservedisi
res

Specifies an entry of the device object dictionary
Specifies a component of a device object dictionary entry
Reserved for alignment

0 .. 65535
0 .. 254
0Read Multiple Parameter by Index request field interpretationEPSG DS 301 V1.5.1-154-

6.3.2.4.2.3.6 Read Multiple Parameter by Index Response
Octet Offset

7

6

0 .. 78 .. 11(8 .. 11) + 4*d(12 .. 13) + 4*d
14 + 4*d
SubAbort
15 + 4*d(16 + 4*d) .. (k – 1)
k .. (k + 3)
(k + 4) .. (k + 5)
k+6
SubAbort
k+7(k + 8) .. (m – 1)
m…
d: if seg = Initiate
elsek, m 4-aligned

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
Data Size (only if Segmentation = Initiate)
Octet Offset of next Data Set (k)Index
Sub-Index
reserved
Padding Length
Payload Data / Sub-Abort Code
Octet Offset of next Data Set (m)Index
Sub-Index
reserved
Padding Length
Payload Data / Sub-Abort Code… (further read responses)

d=1
d=0

Command: Read Multiple Parameter by Index response
Field

Abbr.

Description

Value

Octet Offset ofnext Data Set

o2d

0 – 232-1

Index
Sub-Index
Sub-Abortisisa

Octet offset of the next data set. The value is theabsolute offset, counting from the beginning of the fixedcommand header (beginning with octet offset 0)
If o2d=ZERO the last data set has been reached.
Specifies an entry of the device object dictionary
Specifies a component of a device object dictionary entry
The requested transfer could not be served by the server

Padding Length plreserved
Sub-Abort
Code

res
sac

Number of padding bytes in the last quadlet (4-byteword) of the payload data
Reserved for future use
Reason of the sub-abort

0 – 65.535
0 – 254
0: transfer ok
1: abort transfer
0–3
0
see App. 3.10

Read Multiple Parameter by Index response field interpretation
In the response a list of all object accesses is transferred.
The list entries consist of the index and sub-index of the object, a sub-abort flag (sa) and the payload
data resp. the sub-abort code (sac).
The abort flag (a) in the command header is set only if the data contain one single abort code insteadof a response list. E.g. “Command ID not valid or unknown”.

6.3.2.4.2.4

Parameter Services

6.3.2.4.2.4.1 Command: Maximum Segment Size
The maximum segment size (MSS) indicates the maximum length of a segment in the command layer.
The minimum segment size that must be supported by every device is 256 bytes. If the client and theserver can handle more than 256 bytes the client can use this command to negotiate the maximum
segment size.

EPSG DS 301 V1.5.1

Octet Offset

7

-155-

6

0 .. 78 .. 910 .. 11

5

Bit Offset
4
3

2

1

0

Command Layer (fixed part)
MSS Client
MSS Server

Command: Maximum Segment Size
Field

Abbr.

MSS Client mssc
MSS
msss
ServerDescription

Value

MSS of the client
MSS of the server
If 0000h the length is not indicated (request fromclient to server)

256 –1456
256 –1456

Maximum Segment Size field interpretation
The maximum segment size is limited to 1456 independent of the transfer method (UDP/IP or ASnd).
In the request frame from the client the mssc is indicated to the server. The msss is set to ZERO andtherefore not indicated.
In the response the server repeats the mssc of the client and indicates its own msss.
Both, client and server, must compare the mssc to the indicated msss and must calculate theminimum of both. This is the used MSS.
Used MSS = min {mssc; msss}

6.3.3

SDO Embedded in PDO

It is possible to embed the SDO in the cyclic PDO. The embedded SDO is used as a container
mapped into the PDO.
The Read/Write by Index command layer protocol is used to access the data. The Header of thecontainer starts with a shortened Sequence Layer (1 Byte). The fixed part of the following
POWERLINK Command Layer protocol is adopted in the following points:•

as the container has a fixed length, the valid data length has to be indicated. Therefore the field“valid payload length” is inserted. Up to 255 bytes of payload data may be transferred in acontainer.
Octet Offset

0
1
2

7

Response

3
4
5 .. 67
8 – 11(8 + 4*d) ..
k – (8 + 4*d)

6

5

Bit Offset
4
3

2

1

0

Sequence Layer embedded in PDO
Transaction ID
Abort Segmentation
reserved

Sequence Layer

Valid Payload LengthCommand ID
Index
Sub-Index
Data Size (only if Segmentation = Initiate)
Optional Payload Data

Command Layerk = Length of container in byte
d: if seg = initiate d = 1
else
d=0

SDO embedded in PDO

Variable Part
PayloadEPSG DS 301 V1.5.1
Field

-156-

Abbr. Description

Value

Sequence Layer (see chapter 6.3.3.1)
Command Layer
Transaction ID tid
Unambiguous transaction ID for a command.
Must be changed by the client with every newcommand.
Responsersp
Request / Response

0 .. 255

0 : Request
1 : Response
The requested Transfer could not be served
0: Transfer ok
by the client/server
1: Abort transfer
Differentiates between expedited and
0: Expedited Transfer
segmented transfer
1: Initiate Segment Transfer
2: Segment
3: Segment Transfer Complete
Length of valid payload data in the container in 0 .. 255
bytes.
Specifies the command
See Tab. 58
Specifies an entry of the device object
0 .. 65535
dictionary

Abort

a

Segmentation

seg

Valid Payload
LengthCommand ID
Index

vpl

Sub-Index

si

Specifies a component of a device object
dictionary entry

Data Sizeds

see definition in Tab. 57

cidi

0 .. 254

SDO embedded in PDO field interpretation
The container needs a minimum of 8 bytes for header information.
If segmented transfer is supported, the data size field must be inserted for the initiate frame as definedin the POWERLINK Command Layer Protocol so the header will be 12 byte.
The embedded SDO transfer establishes a peer-to-peer communication channel between two
devices. This is a unidirectional Client-Server connection. If a device needs to transfer data using thismethod to several other devices it must establish a SDO communication channels for each.
The client SDO container (CSDO) and the server SDO container (SSDO) parameter are described by
the SDO communication parameter objects SDO_ServerContainerParam_XXh_REC resp.
SDO_ClientContainerParam_XXh_REC. For each SDO channel a pair the communication parameters
is mandatory.

6.3.3.1

Embedded Sequence Layer for SDO in PDO

For embedding of SDO in cyclic data (PollRequest and PollResponse) the first byte within
POWERLINK Command Layer is reserved for Embedded Sequence Layer.
Octet Offset

0
1…

7

6

5

Bit Offset
4
3

SequenceNumber
Command Layer Protocol

2

1

0

Connection

POWERLINK sequence layer for embedding of SDO in cyclic data
Remark:Only one sequence number for both directions is suitable, because the communication is embedded in
the cyclic communication. And therefore it is guaranteed that there are messages in both directions.

EPSG DS 301 V1.5.1

-157-

Field

Abbr.

Description

Value

SequenceNumber

snr

0 ... 63

Connection

con

Shall be increased by one with eachnew request frame.
Shows the different connection states

0: No connection
1: Initialisation
2: Connection valid
3: Error Response(Retransmission
Request)Fields of POWERLINK sequence layer for embedding of SDO in cyclic data

6.3.3.1.1

Connection

6.3.3.1.1.1

Initialisation of Connection

Connection is not initialised (e.g. after power up). The server has shut down the connection to thisclient. Now client and server know that the connection is down. “?” is used for counters that shall beignored.
After this the connection is established.
The sequence number shall not be incremented until the connection initialisation has been completed
No command shall be transferred during the initialisation.

ClientServerConnection is shut down
m1 (snr = ?

, con = 0)m2 (snr = ?

Client requests
initialization.

m3 (snr = i, con = 1)

m4 (snr = ?
m5 (snr = i

m7 (snr = i, con = 1)

, con = 2)

m10 (snr = i

Fig. 60.

, con = 1)

Server responds withthe same connection
code and the same
sequence number, con = 2)

m8 (snr = i
m9 (snr = i, con = 0)

, con = 1)

m6 (snr = i

Client sets connection tovalid, con = 0)

Server cannot
respond immediately,
because the poll
response has to besent directly after thepoll request so that
there is no time forprocessing.

, con = 2)

Initialisation of embedded connection

Server responds withvalid connectionEPSG DS 301 V1.5.1

6.3.3.1.1.2-158-

Closing a connection

A connection should be shut down, when it is no longer needed.
A node may shut down a connection if it needs the resources for other reasons.

ClientClient requests a shut
down of the connection

Further telegrams havethe con = 0

Fig. 61.

Serverm1 (snr = ?, con = 0)m2 (snr = ?, con = ?)m3 (snr = ?, con = 0)m4 (snr = ?, con = 0)

Closing of connection

Closing a connection shall be indicated by con = 0.

The server shuts
down the connection

Further telegrams havethe con = 0

EPSG DS 301 V1.5.1

6.3.3.1.1.3-159-

Data Transfer

When the connection is established the client is allowed to send new request frames. Client andserver have to keep the sent frames in some sort of a history buffer.
It is possible to send request frames in advance from client to server in consecutive cyclic frames,
even if the responses to the preceding requests have not yet been received. The response frames
then are received some cycles later than the corresponding request frames.
If there is nothing to send, the most recently sent packet shall be repeated.
To make the error recovery (see next chapter) for this protocol work, the client has to know how many
responses the send history on the server holds. This history size parameter can be read from theobject directory, the default value is 1.
The client holds a send history to be able to regain a lost response by repeating the request.
With a send history size of n in the server and a send history size of m in the client, the client shall not
forward more than min(m, n) requests before receiving the response.
Sample with six new request frames:

Clientrep eatin g last te leg ram
un ti l th ere is a ne w one

Serverm1 (snr = i, con = 2)m2 (snr = i, con = 2)m3 (snr = i, con = 2)
m4 (snr = i, con = 2)
m5 (snr = i + 1, con = 2)
m6 (snr = i, con = 2)
m7 (snr = i + 2, con = 2)

m8 (snr = i, con = 2)
m9 (snr = i + 3, con = 2)

m10 (snr = i + 1, con = 2)
m11 (snr = i + 4, con = 2)
m12 (snr = i + 2, con = 2)

m13 (snr = i + 5, con = 2)
m14 (snr = i + 3, con = 2)
m15 (snr = i + 6, con = 2)
m16 (snr = i + 4, con = 2)

m17 (snr = i + 6, con = 2)
m18 (snr = i + 5, con = 2)
m19 (snr = i + 6, con = 2)
m20 (snr = i + 6, con = 2)
m21 (snr = i + 6, con = 2)

m22 (snr = i + 6, con = 2)

Fig. 62.

Normal embedded communicationEPSG DS 301 V1.5.1-160-

6.3.3.1.2

Errors

6.3.3.1.2.1

Error: Request Lost

If server detects an unexpected sequence number, that is not 1 higher than the last correctly received
sequence number, it responds with connection code 3 and the sequence number of the last
successful received frame. The client then has to repeat all frames starting after the sequence numberof the last successful transferred frame.

ClientServerm1 (snr = i + 1, con = 2)m2 (snr = i, con = 2)m3 (snr = i + 2, con = 2)

Request i+2 lostm5 (snr = i + 3, con = 2)
m6 (snr = i + 1, con = 2)
m7 (snr = i + 4, con = 2)client repeats from
history buffer startingwith i+2

m8 (snr = i + 1, con = 3)
m9 (snr = i + 2, con = 2)

Server detects
unexpectedsequence number
Server again detects
unexpectedsequence number

m10 (snr = i + 1, con = 3)client repeats again
from history buffer
starting with i+2

m11 (snr = i + 2, con = 2)
m12 (snr = i + 2, con = 2)
m13 (snr = i + 3, con = 2)
m14 (snr = i + 2, con = 2)
m15 (snr = i + 4, con = 2)
m16 (snr = i +Fig. 63.

Error embedded request lostServer drops second
repeat of i+2

EPSG DS 301 V1.5.1

6.3.3.1.2.2-161-

Error: Response Lost

If the client detects an unexpected sequence number that is not 1 higher than the last correctly
received sequence number, it has to repeat that frames with connection code 3 for which no response
was received.

ClientServerm1 (snr = i + 1, con = 2)m2 (snr = i, con = 2)m3 (snr = i + 2, con = 2)
m4 (snr = i + 1, con = 2)
m5 (snr = i + 3, con = 2)

Response i+2 lostm6 (snr = i + 2, con = 2)
m7 (snr = i + 4, con = 2)

Client detects
unexpected sequencenumber, so it repeats
telegram i+2 until it getsthe response

m8 (snr = i + 3, con = 2)
m9 (snr = i + 2, con = 3)
Server drops thealready received
frames, and sends
the responses fromits history bufferm10 (snr = i + 4, con = 2)
m11 (snr = i + 2, con = 3)
m12 (snr = i + 2, con = 2)

Client repeats the othermessages too

m13 (snr = i + 3, con = 3)
m14 (snr = i + 2, con = 2)
m15 (snr = i + 4, con = 3)
m16 (snr = i +Client goes on withnormal communication

m17 (snr = i + 5, con = 2)
m18 (snr = i + 4, con = 2)

Fig. 64.

Error embedded response lost

6.3.3.1.3

Handling of Segmented Transfers

6.3.3.1.3.1

Segmented Download from Client to Server

ClientCommandLayer

ClientSequenceLayer

ServerSequenceLayer

ServerCommandLayer

c1 (seg=init, cmd)
m1 (snr = i + 1, con = 2, (c1))
m2 (snr = i, con = 2)c2 (seg=segm, cmd)

c1 (seg=init, cmd)
s1 (dummy)

m3 (snr = i + 2, con = 2, (c2))
s1 (dummy)

m4 (snr = i + 1, con = 2, (s1))

c3 (seg=segm, cmd)

c2 (seg=segm, cmd)
s2 (seg = segm)

m5 (snr = i + 3, con = 2, (c3))
s2 (dummy)

m6 (snr = i + 2, con = 2, (s2))

c4 (seg=comp, cmd)

c3 (seg=segm, cmd)
s3 (seg = segm)

m7 (snr = i + 4, con = 2, (c4))
s3 (dummy)

m8 (snr = i + 3, con = 3, (s3))

c4 (seg=comp, cmd)
s4 (resp)

m9 (snr = i + 4, con = 2)
s4 (resp)

Fig. 65.

m10 (snr = i + 4, con = 3, (s4))

Embedded segmented download

EPSG DS 301 V1.5.1-162-

For SDO embedded in cyclic data each new frame requested by the client shall be responded by theserver. In the case of a segmented download from the client to the server, the client will produce morecommand frames than the server.
So the server shall acknowledge the sequence numbers with dummy frames that contain Command
ID “NIL”, while the segmented transfer is running.

6.3.3.1.3.2

Segmented Upload from Server to Client

In the case of a segmented upload from the server to the client the server will produce morecommands than the client. To provide the server with enough sequence numbers the client shall send
dummy commands that contain Command ID “NIL”, to the server until the upload is complete.
ClientCommandLayer

ClientSequenceLayer

ServerSequenceLayer

ServerCommandLayer

c1 (cmd)
m1 (snr = i + 1, con = 2, (c1))
m2 (snr = i, con = 2)c2 (dummy)c1 (cmd)
s1 (seg = init)

m3 (snr = i + 2, con = 2, (c2))
s1 (seg = init

m4 (snr = i + 1, con = 2, (s1))

c3 (dummy)c2 (dummy)s2 (seg = segm)

m5 (snr = i + 3, con = 2, (c3))
s2 (seg = segm)

m6(snr = i + 2, con = 2, (s2))

c4 (dummy)c3 (dummy)s3 (seg = segm)

m7 (snr = i + 4, con = 2, (c4))
s3 (seg = segm)

m8 (snr = i + 3, con = 3, (s3))

c5 (dummy)c4 (dummy)s4 (seg = comp)m9 (snr = i + 5, con = 2, (c5))
s4 (seg = comp)Fig. 66.

m10 (snr = i + 4, con = 3, (s4))

c5 (dummy)

Embedded segmented upload

6.3.3.2

Embedded Command Layer for SDO in Cyclic Data

Remark: Even though this specification only defines the services Write / Read by Index via SDO in
PDO all other commands specified in the SDO Command Layer (chapter 6.3.2.4) can be supported ina similar way.

6.3.3.2.1

Command Write by Index via PDO

Octet Offset

0
1
2

7

Response

3
4
5 .. 6
7
8 .. 11
8 + 4*d k – (8 + 4*d)

6

5

Bit Offset
4
3

2

Sequence Layer embedded in PDO
Transaction ID
Abort Segmentation
reserved
Valid Payload LengthCommand ID = Write by Index
Index
Sub-Index
Data Size (only if Segmentation = Initiate)
Payload Datak = Length of container in byte

Command: Write by Index Request via PDO

10

EPSG DS 301 V1.5.1

6.3.3.2.2

Command Read by Index via PDO

Octet Offset

0
1
2

-163-

7

6

Response

3
4
5–6
7

5

Bit Offset
4
3

2

1

0

Sequence Layer embedded in PDO
Transaction ID
Abort Segmentation
reserved
Valid Payload LengthCommand ID = Read by Index
Index
Sub-Index

Command: Read by Index Request via PDO

6.3.3.3

Object Description

6.3.3.3.1

Object 1200h .. 127Fh:
SDO_ServerContainerParam_XXh_REC

The SDO_ServerContainerParam_XXh_REC objects contain the parameters for the SDOs for which
the device is the server.
To map the container in the PDO the corresponding index shall be mapped.
To allow access by name “_XXh” shall be replaced by a name index. Name index shall be “_00h” ifobject index is 1200h. It shall be incremented up to “_7Fh” corresponding to object index 127Fh.
Index
1200h .. 127Fh
Name
SDO_ServerContainerParam_XXh_REC
Data Type SDO_ParameterRecord_TYPE•

RECORD

CategoryO

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

Object Type00h
NumberOfEntries
44

Sub-Index 01h: ClientNodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

01h
ClientNodeID_U8
UNSIGNED8UNSIGNED8-POWERLINK Node ID of SDO client•

Sub-Index 02h: ServerNodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ServerNodeID_U8
UNSIGNED8UNSIGNED8-POWERLINK Node ID of SDO server

EPSG DS 301 V1.5.1
•

-164-

Sub-Index 03h: ContainerLen_U8
Sub-Index
Name
Data Type
Value Range
Default Value

03h
ContainerLen_U8
UNSIGNED8UNSIGNED8-

Category
AccessPDO Mapping

M
rws
No

Category
AccessPDO Mapping

M
rws
No

Max. data length of the container (incl. header) in byte•

Sub-Index 04h: HistorySize_U8
Sub-Index
Name
Data Type
Value Range
Default Value

04h
HistorySize_U8
UNSIGNED8
0 .. 63-

Client Request history size (for sequence layer, see 6.3.3.1)

6.3.3.3.2

Object 1280h .. 12FFh:
SDO_ClientContainerParam_XXh_REC

The SDO_ClientContainerParam_XXh_REC objects contain the parameters for the SDOs for which
the device is the client. If the entry is supported, all sub-indices must be available.
To map the container in the PDO the corresponding index shall be mapped.
To allow access by name “_XXh” shall be replaced by a name index. Name index shall be “_00h” ifobject index is 1280h. It shall be incremented up to “_7Fh” corresponding to object index 12FFh.
Index
Name
Data Type•1280h .. 12FFh
SDO_ClientContainerParam_XXh_REC
SDO_ParameterRecord_TYPE

RECORD

CategoryO

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

Object Type00h
NumberOfEntries
55

Sub-Index 01h: ClientNodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

01h
ClientNodeID_U8
UNSIGNED8UNSIGNED8-POWERLINK Node ID of SDO client•

Sub-Index 02h: ServerNodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ServerNodeID_U8
UNSIGNED8UNSIGNED8-POWERLINK Node ID of SDO server

EPSG DS 301 V1.5.1
•

-165-

Sub-Index 03h: ContainerLen_U8
Sub-Index
Name
Data Type
Value Range
Default Value

03h
ContainerLen_U8
UNSIGNED8UNSIGNED8-

Category
AccessPDO Mapping

M
rws
No

Category
AccessPDO Mapping

M
rws
No

Max. data length of the container (incl. header) in byte•

Sub-Index 04h: HistorySize_U8
Sub-Index
Name
Data Type
Value Range
Default Value

04h
HistorySize_U8
UNSIGNED8
0 .. 63-

Server Response history size (for sequence layer, see 6.3.3.1)•

Sub-Index 05h: reserved

6.3.3.3.3

Object 0422h: SDO_ParameterRecord_TYPE

Index
Name

0422h
SDO_ParameterRecord_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
ClientNodeID_U8
ServerNodeID_U8
ContainerLen_U8
HistorySize_U8

Value
04h
0005h
0005h
0005h
0005h

Data TypeUNSIGNED8UNSIGNED8UNSIGNED8UNSIGNED8

6.3.4

SDO Timeouts

6.3.4.1

Object 1300h: SDO_SequLayerTimeout_U32

The object provides a timeout value in [ms] for the connection abort recognition of the SDO sequencelayer (see 6.3.2.3.2.5).
Index
Name
Data Type
Value Range
Default Value

1300h
SDO_SequLayerTimeout_U32
UNSIGNED32
100 ms – Max(UNSIGNED32)
C_SDO_SEQULAYERTIMEOUT

Object Type

VAR

Category
AccessPDO MappingMrws, valid on resetNo

Note: The default value of C_SDO_SEQULAYERTIMEOUT will be high enough even for diagnosing
nodes over the internet.
Note: Take care when configuring the sequence layer timeout. If the configured value is too low, SDO
access to the device is impossible after ResetConfiguration.

6.3.4.2

Object 1301h: SDO_CmdLayerTimeout_U32

The object provides a timeout value in [ms] for the connection abort recognition of the SDO commandlayer.
If SDO_CmdLayerTimeout_U32 is not implemented a value of C_SDO_CMDLAYERTIMEOUT shallbe used instead for detecting a command layer timeout.

EPSG DS 301 V1.5.1
Index
Name
Data Type
Value Range
Default Value

-166-

1301h
SDO_CmdLayerTimeout_U32
UNSIGNED32
100 ms – Max(UNSIGNED32)
C_SDO_CMDLAYERTIMEOUT

Object Type

VAR

Category
AccessPDO MappingO
rws, valid on resetNo

Note: Take care when configuring the command layer timeout.
This timeout is valid for each and every SDO command. When configuring its value a long duration for
SDO access has to be considered, e.g. for firmware download or storing the OD.
If the configured value is too low, SDO access to the device is impossible after ResetConfiguration.

6.3.4.3

Object 1302h: SDO_SequLayerNoAck_U32

The object provides the number of acknowledge requests for the connection abort recognition of the
SDO sequence layer (see 6.3.2.3.2.5).
Index
Name
Data Type
Value Range
Default Value

6.4

1302h
SDO_SequLayerNoAck_U32
UNSIGNED32
2 – Max(UNSIGNED32)
C_SDO_SEQULAYERNOACK

Object Type

VAR

Category
AccessPDO MappingO
rws, valid on reset
No

Process Data Object (PDO)

The real-time data transfer is performed by means of Process Data Objects (PDO).
PDO communication in POWERLINK is always performed isochronously by PReq and/or PRes
frames. The PRes frames are sent as broadcasts following the producer/consumer scheme. The
PReq frames with unicast addresses comply with the master/slave relationship.
The transmission type of PDO is continuous. There is no “on event” or “on change” transmission typeprovided.
From the device’s view, there are two types of PDO usage: data transmission and data reception.
Transmit PDOs (TPDOs) and Receive PDOs (RPDOs) shall be distinguished. Devices supporting
TPDOs are PDO producers or PDO masters and devices which are able to receive PDOs are called
PDO consumers or PDO slaves.
The numbers of supported channels shall be provided by the application.
An MN device may support up to 256 RPDO and 256 TPDO channels.
On a CN device, only one TPDO channel may be available while up to 256 RPDO may be supported .
An Async-only CN device shall not support any TPDO channel but may provide up to 256 RPDO
channels.
The size of PDO channels is application-specific.
A PDO channel shall be described by a pair of objects:••

PDO communication parameter describing communication attributes of the PDO. Mapping
version and address information are provided.
PDO communication parameter are held by the objects PDO_TxCommParam_XXh_REC andPDO_RxCommParam_XXh_REC (Index number 1800h .. 18FFh resp. 1400h .. 14FFh).

PDO mapping parameter describing the mapping of the objects contained in PDO payload to
object dictionary entries.
PDO mapping parameter are held by the objects PDO_TxMappParam_XXh_AU64 and
PDO_RxMappParam_XXh_AU64 (Index number 1A00h .. 1AFFh resp. 1600h .. 16FFh ).
Corresponding PDO communication and mapping parameters shall be identified by equal low byte
values of the index numbers. TPDO and RPDO object pairs shall be distinguished.
The mapping of application objects into a PDO may be transmitted to a device during the device
configuration process by applying the SDO services to the corresponding entries of the Object
Dictionary.

EPSG DS 301 V1.5.1-167-

Regarding the complete network, TPDO and RPDO mappings applied to a dedicated isochronous
frame may be different. Especially in producer/consumer relationships using PRes frames, individual
objects mapped by the TPDO mapping of the producer may be targeted to different consumers. The
RPDO mapping of a consumer may skip objects not targeted to it.

6.4.1

PDO Mapping Limitations

PDO mapping description may require a large amount of memory. Other restriction may derive fromthe internal structure of a device, e.g. buffer size, interfaces etc.
Devices may limit the amount of PDO data to be transmitted and received per POWERLINK cycle.
A device shall not impose restrictions on the sequence of mapped objects within a PDO.

6.4.1.1

TPDO Mapping Limitations

Transmit PDO description amount may be limited in following ways:•

The maximum number of supported TPDO channels may be indicated by
D_PDO_TPDOChannels_U16. It limits the number of PDO_TxCommParam_XXh_REC andPDO_TxMappParam_XXh_AU64 objects.

•

The maximum number of mapped objects per TPDO channel may be indicated by
D_PDO_TPDOChannelObjects_U8. It limits the number of PDO_TxMappParam_XXh_AU64
sub-indices.

•

An overall limit to the number of mapped objects regardless their distribution to channels may
be indicated by D_PDO_TPDOOverallObjects_U16. It provides an upper limit to the sum of the
TPDO objects of all channels.

•

D_PDO_TPDOChannels_U16, D_PDO_TPDOChannelObjects_U8 and
D_PDO_TPDOOverallObjects_U16 may be combined. If one of the values violates a
calculatoric limit given by the other ones it shall be ignored.
Example: D_PDO_TPDOChannels_U16 and D_PDO_TPDOChannelObjects_U8 together
provide an upper limit to the overall number of available mapping object entries. If
D_PDO_TPDOOverallObjects_U16 is greater than the product of D_PDO_TPDOChannels_U16
and D_PDO_TPDOChannelObjects_U8, it shall be ignored.
TPDO limits caused by the internal structure of a device shall indicated as following:•

On a per telegram base, TPDO may be limited by•

TX buffer size,•

the bandwidth of an internal interface, that transport complete TPDO payload fromapplication to POWERLINK stack•etc.
Such kind of limits shall be indicated by NMT_CycleTiming_REC.IsochrTxMaxPayload_U16.
•

On a per cycle base, TPDO data amount may be limited by the bandwidth of an internalinterface that transports all TPDO data that shall be transmitted during a cycle.
D_PDO_TPDOCycleDataLim_U32 shall indicate such kind of limit.
It is assumed that TPDO telegram generation is performed on the POWERLINK stack side of
the interface. TPDO objects mapped to multiple TPDO channels shall be transported once overthe interface and distributed to the channels on the POWERLINK stack side. Thus they shall be
once taken into account when calculating the bandwidth.

6.4.1.2

RPDO Mapping Limitations

Receive PDO description amount may be limited in following ways:•

The maximum number of supported RPDO channels may be indicated by
D_PDO_RPDOChannels_U16. It limits the number of PDO_RxCommParam_XXh_REC andPDO_RxMappParam_XXh_AU64 objects.

•

The maximum number of mapped objects per RPDO channel may be indicated by
D_PDO_RPDOChannelObjects_U8. It limits the number of PDO_RxMappParam_XXh_AU64
sub-indices.

EPSG DS 301 V1.5.1
•

-168-

An overall limit to the number of mapped objects regardless their distribution to channels may
be indicated by D_PDO_RPDOOverallObjects_U16. It provides an upper limit to the sum of the
RPDO objects of all channels.

•

D_PDO_RPDOChannels_U16, D_PDO_RPDOChannelObjects_U8 and
D_PDO_RPDOOverallObjects_U16 may be combined. If one of the values violates a
calculatoric limit given by the other ones it shall be ignored.
Example: refer 6.4.1.1
RPDO limits caused by the internal structure of a device shall indicated as following:•

On a per telegram base, RPDO may be limited by•

RX buffer size,•

the bandwidth of an internal interface, that transport complete RPDO payload fromPOWERLINK stack to application•
etc.
Such kind of limits shall be indicated by NMT_CycleTiming_REC.IsochrRxMaxPayload_U16.
•

On a per cycle base, RPDO data amount may be limited by the bandwidth of an internalinterface that transports all RPDO data that have been received during a cycle.
D_PDO_RPDOCycleDataLim_U32 shall indicate such kind of limit.

6.4.1.3

Further Limitations

The overall memory consumption of the objects defining the mapping(PDO_TxMappParam_XXh_AU64, PDO_TxCommParam_XXh_REC,
PDO_RxMappParam_XXh_AU64 and PDO_RxCommParam_XXh_REC) may be limited. The limit isgiven by D_PDO_MaxDescrMem_U32. The size is calculated as follows:•

Each object PDO_TxCommParam_XXh_REC whose mapping is activated(PDO_TxMappParam_XXh_AU64.NumberOfEntries is not equal to 0) uses 2 Bytes.

•

Each object PDO_RxCommParam_XXh_REC whose mapping is activated(PDO_RxMappParam_XXh_AU64.NumberOfEntries is not equal to 0) uses 2 Bytes.

•

Each object PDO_TxMappParam_XXh_AU64 uses
PDO_TxMappParam_XXh_AU64.NumberOfEntries * 8 Bytes.

•

Each object PDO_RxMappParam_XXh_AU64 uses
PDO_RxMappParam_XXh_AU64.NumberOfEntries * 8 Bytes.
The sum of these sizes must not exceed D_PDO_MaxDescrMem_U32.
The minimum size of mapped objects may be indicated by D_PDO_Granularity_U8. The mapped
offset shall be a multiple of the granularity.

6.4.2

PDO Mapping Version

Compatibility of TPDO channels and corresponding RPDO channels may be ensured by PDO
mapping version handling.
PDO mapping version is held by PDO_TxCommParam_XXh_REC.MappingVersion_U8 and
PDO_RxCommParam_XXh_REC.MappingVersion_U8. Tab. 91 shows the PDO mapping main andsub version encoding.
High nibble

Low nibble

Main version

Sub version
Structure of PDO Mapping version

The assigned value of the PDO Mapping version is application specific.
If the PDO Mapping is changed in a compatible manner e.g. expanding the PDO contents, the sub
version shall be incremented.
PDO Mapping may be variable or static. Variable mapping may be dynamically modified by theapplication, even under operation. Static mapping is pre-defined and may not be modified in any way.
Support of variable mapping shall be indicated by NMT_FeatureFlags_U32 Bit 6 and
D_PDO_DynamicMapping_BOOL.

EPSG DS 301 V1.5.1-169-

To control compatibility of PDO mapping, PDO_TxCommParam_XXh_REC.MappingVersion shall beset. The version info shall be transmitted by the master or producer with every PDO transporting PReq
and PRes frame (s. 4.6.1.1.3 resp. 4.6.1.1.4).
The PDO slave or consumer shall check the mapping version of received PDOs using thecorresponding PDO_RxCommParam_XXh_REC.MappingVersion entry. PDOs with differing main
version shall be ignored. PDOs with equal main version but differing sub version shall be accepted.
A PDO mapping version value of 0 indicates that there is no mapping version available. This does notdisable the version check. If the mapping version in the received PDO is 0 the corresponding
PDO_RxCommParam_XXh_REC.MappingVersion entry shall be 0 too and vice versa. Otherwise thereceived mapping is ignored.

6.4.3

SDO via PDO Container

A container may be used by the PDO mapping to enable exchange of SDO data via PDO
communication channels.
See 6.3.3 for detailed description of SDO embedded in PDO.
The type of container is defined by a referencing object at index
SDO_ServerContainerParam_XXh_REC or SDO_ClientContainerParam_XXh_REC

6.4.4

Transmit PDOs

If sub-index 0 of the mapping object (PDO_TxMappParam_XXh_AU64) is 0 the TPDO is invalid. The
RD flag of the TPDO transporting Frame shall be reset. (refer Tab. 105 or 7.1.4)
Sending PDO data is implicitly isochronous for a node in the state NMT_CS_OPERATIONAL and
NMT_MS_OPERATIONAL. In NMT_CS_READY_TO_OPERATE and
NMT_MS_READY_TO_OPERATE, PDO data are sent in the same way, but they are not valid. The
RD flag of the TPDO transporting Frame shall be reset..

6.4.5

Receive PDOs

RPDO data shall be valid if the RD flag of the RPDO transporting frame is set in the state
NMT_CS_OPERATIONAL and NMT_MS_OPERATIONAL. The data shall be occurred to the objects
assigned by the RPDO mapping parameters. The application may access the received PDO data byreading these objects.
If the RD flag is not set in the received message, the mapping shall not be performed, e.g. the data
shall not be copied to the mapped objects. The application shall further make use of the old data
earlier received. RD flag signaling to the application shall be implementation specific.
In NMT states not equal NMT_CS_OPERATIONAL resp. NMT_MS_OPERATIONAL, RPDO data shallbe invalid and shall be ignored.
If the length of the data actually received is less than the length of the mapped objects or if thereceived and the expected PDO mapping versions differ in an incompatible manner the received data
has to be ignored and a fault situation occurs.

6.4.6

PDO via PReq

PDO via PReq transmission follows the master/slave relationship as described in 2.3.1.
PDO via PReq is carried out according to the following protocol.
POWERLINK
MN

POWERLINK
CN
indication

requestPollRequest

The following data elements in the PReq frame (for the frame structure see 4.6.1.1.3) are relevant for
PDO transport:

EPSG DS 301 V1.5.1

-170-

•

The RD flag indicates if the PDO data is valid. If the bit is 0b, the PDO data is not valid and shallnot be interpreted by the POWERLINK CN.

•

Size indicates the user data length of the PDO payload data.

•

Payload indicates the PDO data.

6.4.7

PDO via PRes

PDO via PRes transmission follows the producer/consumer relationship as described in 2.3.3.
PDO via PRes from a CN is carried out according to the following protocol.
POWERLINKCN

POWERLINK
MN

requestPollResponse

indication

POWERLINK
CNs
indication
indication

PDO via PRes from the MN is carried out according to the following protocol.
POWERLINK
MN

POWERLINK
CNsrequestPollResponse

indication
indication
indication

The following data elements in the PRes frame (for the frame structure see 4.6.1.1.4) are relevant for
PDO transport:•

The RD flag indicates if the PDO data is valid. If the bit is 0b, the PDO data is not valid and shallnot be interpreted by the POWERLINK CN.

•

Size indicates the user data length of the PDO payload data.

•

Payload indicates the PDO data.

6.4.8

PDO Error Handling

6.4.8.1

Dynamic Errors

6.4.8.1.1

Incompatible Mapping

If an incompatible PDO Mapping version is received, the PDO shall be ignored.
This error situation shall be logged and signaled to the application. Typically this error occurs manytimes, so the error shall be logged and signaled once for every received wrong PDO mapping version.
The bit corresponding to the error causing node may be set to 1 b in PDO_ErrMapVers_OSTR.
Error code

Description

E_PDO_MAP_VERS

PDO with wrong Mapping version received, PDO ignored

6.4.8.1.2

Unexpected End of PDO

If a PDO is received which is shorter than the amount of mapped objects, the PDO shall be ignored.
This error situation shall be logged and signaled to the application. Normally this error occurs manytimes, so the error shall be logged and signaled once for each PDO. The bit corresponding to the error
causing Node may be set to 1b in PDO_ErrShort_RX_OSTR.

EPSG DS 301 V1.5.1-171-

Error code

Description

E_PDO_SHORT_RX

RX PDO length too short, PDO ignored

6.4.8.2

Configuration Errors

If an attempt to change the PDO mapping results in a memory consumption of mapped objects thatexceeds the configured payload size limits NMT_CycleTiming_REC.IsochrRxMaxPayload_U16 or
NMT_CycleTiming_REC.IsochrTxMaxPayload_U16, this attempt shall be rejected anyway.
If only the limit NMT_CycleTiming_REC.PReqActPayloadLimit_U16 or NMT_CycleTiming_REC.
PResActPayloadLimit_U16 is violated the mapping shall be activated. However the RD flag shall bereset resp. the received data shall be ignored.
If any of the limits introduced in 6.4.1 is violated, the attempt shall be rejected too.
The memory size check shall be done when a mapping is enabled by writing the number of mapped
objects to PDO_RxMappParam_XXh_AU64.NumberOfEntries or PDO_TxMappParam_XXh_AU64.
NumberOfEntries. .
Error code

Description

E_PDO_MAP_OVERRUN

Mapping exceeds payload size or mapped object number limit

6.4.9

Object Description

6.4.9.1

Object 1400h .. 14FFh:
PDO_RxCommParam_XXh_REC

This description handles a sequence of up to 256 objects. These indices describe the communication
attributes of the RPDO channels. Mapping version and address information are provided.
The number of objects may be less than 256 (refer 6.4.1). Objects shall be implemented starting at
Index 1400h.
The validity of the respective object depends on the NumberOfEntries_U8 entry of the corresponding(s. 6.3.4) RPDO mapping index PDO_RxMappParam_XXh_AU64.
To change the PDO communication parameter, the PDO shall be deactivated by setting
PDO_RxMappParam_XXh_AU64.NumberOfEntries
to0.
To
enablemodifications,
PDO_RxMappParam_XXh_AU64.NumberOfEntries shall be set to a value not equal 0.
Inde 1400h .. 14FFhx
Nam PDO_RxCommParam_XXh_RECeData PDO_CommParamRecord_TYPE
TypeObjectTypeRECORD

Categor Condy

To allow access by name, “_XXh” shall be replaced by a name index. Name index shall be“_00h” if object index is 1400h. It shall be incremented up to “_FFh” corresponding to object
index 14FFh.

EPSG DS 301 V1.5.1•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-172-

00h
NumberOfEntries
2
2

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 01h: NodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

01h
NodeID_U8
UNSIGNED8
0, 1 .. 254-

Node ID of the node transmitting the corresponding PRes. Valid Node IDs shall be determined
by NMT_NodeAssignment_AU32 [Node ID] Bits 0 and 8.
Node ID entry 0 is reserved for PReq received by a CN.
Node ID entry C_ADR_SELF_ADR_NODE_ID shall indicate mapping of the RPDO to the
TPDO describing the locally transmitted PRes frame. This Node ID always refers to the locallytransmitted PRes, independent of the local Node ID setting.
The local Node ID may be also used to indicate the reception of self-transmitted PDO (e.g.
Node ID 3). But in this case the mapping is fixed to this Node ID. If the local Node ID changes(e.g. from 3 to 4), the mapping still refers to the PRes of Node ID 3
Receipt of self-transmitted PDO is optional. It shall be indicated by the device description entry
D_PDO_SelfReceipt_BOOL.
•

Sub-Index 02h: MappingVersion_U8
Sub-Index
Name
Data Type
Value Range
Default Value

02h
MappingVersion_U8
UNSIGNED8UNSIGNED8-

Category
AccessPDO MappingM
rws / roNo

Access shall be ro if only static mapping is provided by the device.

6.4.9.2

Object 1600h .. 16FFh
PDO_RxMappParam_XXh_AU64

This description handles a sequence of up to 256 objects. These indices describe the mapping of theobjects contained in RPDO payload to object dictionary entries.
The number of objects and subindices may be limited (refer 6.4.1). Objects shall be implemented
starting at Index 1600h.
To change the PDO mapping, the PDO shall be deactivated by setting NumberOfEntries to 0. The
new mapping may then be given by writing object mapping entries to sub-index 1 and higher. To
enable the PDO mapping again, NumberOfEntries shall be set to the number of the highest sub-index
containing the object mapping to be activated. When the mapping is enabled, it shall be verified, thatthe cumulative length of all mapped objects does not violate the payload size limit
NMT_CycleTiming_REC.IsochrRxMaxPayload_U16 and on the CN additionally the limit
NMT_CycleTiming_REC.PReqActPayloadLimit_U16 for the PReq frame. For the appropriate error
handling see 6.4.8.2.
On some device, add or remove entries to or from the current list of mapping entries may be
performed by modifying NumberOfEntries without effecting the ObjectMapping sub-indices. To do so,
NumberOfEntries shall be set to 0 before writing the new NumberOfEntries value.
Default mapping values may be provided by the device profile.

EPSG DS 301 V1.5.1
Index
Name
Data Type-173-

1600h .. 16FFh
PDO_RxMappParam_XXh_AU64
UNSIGNED64

Object Type

ARRAY

CategoryCond

To allow access by name, “_XXh” shall be replaced by a name index. Name index shall be“_00h” if object index is 1600h. It shall be incremented up to “_FFh” corresponding to object
index 16FFh.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
0, 1 .. 254-

AccessPDO Mapping

rws
No

Number of mapped objects. 0 indicates that the mapping index and the corresponding RPDO
communication index (6.4.9.1) is deactivated.
On devices providing only static mapping, the value shall be set to the number of entries
corresponding to the static mapping or 0.
Note: By this it is also possible to activate / deactivate (0) a static mapping.
•

Sub-Index 01h .. FEh: ObjectMapping
Sub-Index
Name-Value Range
Default Value

01h .. FEh
ObjectMapping-UNSIGNED64-

Category
AccessPDO MappingO
rws / roNo

Access shall be ro if only static mapping is provided by the device.
•

Sub-Index 01h .. FEh Value Interpretation
For every PDO channel up to 254 objects may be mapped.
The offset related to the start address of the PDO payload and the length of data shall be
provided for every mapped object.
Octet Offset

0–1
2
3
4–5
6–7

Name

Index
Sub-index
reserved
OffsetLengthDescription

Index of the object to be mapped
Sub-index of the object to be mapped
for alignment purpose
Offset related to start of PDO payload (Bit count)
Length of the mapped object (Bit count)

Structure of PDO Mapping Entry
Tab. 93 shows the internal bit mapping of an object mapping entry. See 6.1.4.5 for information
about data type encoding for transmission purpose.
UNSIGNED64
MSB
Bits
Name
Encoding

63 .. 48
LengthUNSIGNED16LSB

47 .. 32
OffsetUNSIGNED16

31 .. 24
23 .. 16
reserved
Sub-index
UNSIGNED8

15 .. 0Index
UNSIGNED16

Internal bit mapping of PDO mapping entry
Mapped objects of length ≥ 8 Bits shall be aligned to a byte boundary offset.
Overlapping of mapped objects should be avoided.
The following example shows the mapping interpretation:
Index 6000h, Sub-index 4 with a data length of 8 bit shall be mapped to offset 16 [bit].

EPSG DS 301 V1.5.1
Bits
Name
Data

63 .. 48
Length8-174-

47 .. 32
Offset16

31 .. 24
reserved
0

23 .. 16
Sub-index
4

15 .. 0
Index
6000h

The object above is mapped with the following value (big endian):•
0008.0010.00.04.6000h
It is transmitted in the following order (little endian):•

0060.04.00.1000.0800h

6.4.9.3

Object 1800h .. 18FFh
PDO_TxCommParam_XXh_REC

This description handles a sequence of up to 256 objects. These indices describe the communication
attributes of the TPDO channels. Mapping version and address information are provided.
As a CN has only one TPDO channel, only the first index PDO_TxCommParam_XXh_REC shall be
implemented on a CN.
On the MN, the number of objects may be less than 256 (refer 6.4.1).
Objects shall be implemented starting at Index 1800h.
The validity of the respective object depends on the NumberOfEntries_U8 entry of the corresponding(s. 6.3.4) TPDO mapping index PDO_TxMappParam_XXh_AU64.
To change the PDO communication parameter, first the PDO has to be deactivated by means ofsetting PDO_TxMappParam_XXh_AU64.NumberOfEntries to 0. To enable modifications,
PDO_TxMappParam_XXh_AU64.NumberOfEntries shall be set to a value not equal to 0.
Inde 1800h .. 18FFhx
Nam PDO_TxCommParam_XXh_RECeData PDO_CommParamRecord_TYPE
TypeObjectTypeRECORD

Categor Condy

To allow access by name, “_XXh” shall be replaced by a name index. Name index shall be“_00h” if object index is 1800h. It shall be incremented up to “_FFh” corresponding to object
index 18FFh.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

00h
NumberOfEntries
2
2

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 01h: NodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

01h
NodeID_U8
UNSIGNED8
0, 1 .. 254-

Node ID of the PDO target:•

CN: not used (0)•MN: Node ID of the PReq target (CN). Valid Node IDs shall be released by
NMT_NodeAssignment_AU32 [Node ID] Bits 0 and 8.
Node ID entry 0 shall indicate multicast PRes transmitted by the MN.

EPSG DS 301 V1.5.1
•

-175-

Sub-Index 02h: MappingVersion_U8
Sub-Index
Name
Data Type
Value Range
Default Value

02h
MappingVersion_U8
UNSIGNED8UNSIGNED8-

Category
AccessPDO MappingM
rws / roNo

Access shall be ro if only static mapping is provided by the device.

6.4.9.4

Object 1A00h .. 1AFFh
PDO_TxMappParam_XXh_AU64

This description handles a sequence of up to 256 objects. These indices describe the mapping of theobjects contained in TPDO payload to object dictionary entries.
As a CN has only one TPDO channel, only the first index PDO_TxMappParam_XXh_AU64 shall be
implemented on a CN.
On the MN, the number of objects may be less than 256 (refer 6.4.1).
Objects shall be implemented starting at Index 1A00h.
The number of subindices may be limited (refer 6.4.1).
To change the PDO mapping, the PDO shall be deactivated by setting NumberOfEntries to 0. The
new mapping may then be given by writing object mapping entries to sub-index 1 and higher. To
enable the PDO mapping again, NumberOfEntries shall be set to the number of the highest sub-index
containing the object mapping to be activated. When the mapping is enabled, it shall be verified, thatthe cumulative length of all mapped objects does not violate the payload size limit
NMT_CycleTiming_REC.IsochrTxMaxPayload_U16
andadditionally
the
limit
NMT_CycleTiming_REC.PResActPayloadLimit_U16 for the Pres frame. For the appropriate error
handling see 6.4.8.2.
On some device, add or remove entries to or from the current list of mapping entries may be
performed by modifying NumberOfEntries without effecting the ObjectMapping sub-indices. To do so,
NumberOfEntries shall be set to 0 before writing the new NumberOfEntries value.
Default values may be provided by the device profile.
Index
Name
Data Type

1A00h .. 1AFFh
PDO_TxMappParam_XXh_AU64
UNSIGNED64

Object Type

ARRAY

CategoryCond

To allow access by name, “_XXh” shall be replaced by a name index. Name index shall be“_00h” if object index is 1A00h. It shall be incremented up to “_FFh” corresponding to object
index 1AFFh.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
0, 1 .. 254-

AccessPDO Mappingrws
No

0 indicates that the mapping index and the corresponding TPDO communication index (6.4.9.1)
is deactivated. The RD flag of the TPDO transporting frame shall be reset (TPDO is invalid).
On devices only providing static mapping, the value shall be set to the number of entries
corresponding to the static mapping or 0.
Note: By this it is also possible to activate / deactivate (0) a static mapping.

EPSG DS 301 V1.5.1
•

-176-

Sub-Index 01h .. FEh: ObjectMapping
Sub-Index
Name-Value Range
Default Value

01h .. FEh
ObjectMapping-UNSIGNED64-

Category
AccessPDO MappingO
rws / roNo

Access shall be ro if only static mapping is provided by the device.
•

Sub-Index 01h .. FEh Value Interpretation
see PDO_RxMappParam_XXh_AU64.ObjectMapping Value Interpretation (6.4.9.2)

6.4.9.5

Object 1C80h: PDO_ErrMapVers_OSTR

This object contains a list of all the nodes, sending a wrong mapping version (see 6.4.8.1.1).
The bits are arranged in the node list format (refer 7.3.1.2.3). If a wrong mapping version is detected,
the bit corresponding to the node transmitting the PDO, shall be set to 1b. Reset shall be handled by
the application.
Hint: A configuration tool shall refresh the object to avoid erroneously pending error indication.
Index
Name
Data Type
Value Range
Default Value

1C80h
PDO_ErrMapVers_OSTR
OCTET_STRING32
0

Object Type

VAR

Category
AccessPDO Mapping

O
rw
No

EPSG DS 301 V1.5.1

6.4.9.6-177-

Object 1C81h: PDO_ErrShort_RX_OSTR

This object contains a list of all the nodes, sending a too short PDO (see 6.4.8.1.2).
The bits are arranged in the node list format (refer 7.3.1.2.3). If a short PDO is detected, the bitcorresponding to the node transmitting the PDO, shall be set to 1b. Reset shall be handled by theapplication.
Hint: A configuration tool shall refresh the object to avoid erroneously pending error indication.
Index
Name
Data Type
Value Range
Default Value

6.4.9.7

6.5

1C81h
PDO_ErrShort_RX_OSTR
OCTET_STRING32
0

Object Type

VAR

Category
AccessPDO Mapping

O
rw
No

Object 0420h: PDO_CommParamRecord_TYPE

Index
Name

0420h
PDO_CommParamRecord_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h

Component Name
NumberOfEntries
NodeID_U8
MappingVersion_U8

Value
02h
0005h
0005h

Data TypeUNSIGNED8UNSIGNED8

Error Signaling

This chapter describes how to record errors and events which are generated by a POWERLINK Nodeand the procedure how a CN shall indicate and transfer errors/events to the MN.
All communication layers as well as the application shall have access to the Error Signaling.
The Data Link Layer of a CN shall query the Error Signaling cyclically for new StatusResponse data.
If there was no change in the Static Error Bit Field and the Status Entries since the last query from the
DLL and the Emergency Queue is empty, the Error Signaling shall not provide data to the DLL.
If there was a change or the Emergency Queue is not empty the Error Signaling shall generate new
StatusResponse data and pass it to the DLL at the next query.
•

Static Error Bit Field :8 Bytes, see 6.5.8.1•
Error Entry:
20 Bytes / Entry, see Tab. 94
If the Emergency Queue is used, the space for at least 1 History Entry shall be available in the
StatusResponse frame. This History Entry may not contain emergency data to make sure the CN cantransmit the Emergency Queue entries to the MN.
Emergency Queue support is optional. D_NMT_EmergencyQueueSize_U32 indicates support(D_NMT_EmergencyQueueSize_U32 > 0) and queue size.

EPSG DS 301 V1.5.1-178-

Application
Application

DeviceProfile
DeviceNMT
NM

POWERLINK Appl. Layer
HTTP

Object Dictionary
PDO
PDO

FTP

SDO
CommandSDO
Command

Sequence
SDO
Sequence
SDO
UDP
UDP

TCP
IP
P

POWERLINK Data Link Layer

MAC
PHY

Fig. 67.

Error signaling – Reference model

Error Signaling
Object 1003h
ERR_History_ADOM

Emergency Queue
Entry Type.Bit14 = 1

Error Entry

Entry Type.Bit15 = 0

Entry Type.Bit15 = 1

StatusStatus
Entry
Entries

Generation of new frame if changed or the Emergency Queue contai ns data
Static Error Bit Field

StatusResponse data
Data Link Layer

Fig. 68.

Error signaling – Overview

Status and History Entries

Error
Erro
r
SignalingEPSG DS 301 V1.5.1

6.5.1

-179-

Error Entry

This chapter describes the function and the data format of an Error Entry listed in the Error History
object 1003h ERR_History_ADOM or the StatusResponse.
The Error History object holds the errors and events that have occurred on the device..
An ErrorEntry_DOM has the following format:
Octet Offset

Description

0 .. 1
2 .. 34 .. 11
12 .. 19

Entry Type
Error CodeTime Stamp
Additional Information
Format of one entry

Field
Entry Type
Error Code

Abbr.
type
code

Time
Stamp
Additional
Information

time
add

Description
see Tab. 96
Depending on the Entry Type the error codes aredescribed in the device profiles , device descriptions or thecommunication profile. Communication profile specificerror codes are described in App. 3.9.
SoC Nettime from the cycle when the error/event was
detected.
This field contains device profile or vendor specificadditional error information.

Value
UNSIGNED16
UNSIGNED16

NETTIMEUNSIGNED64

Description of one entry
All elements of the Error Entry shall be stored and transferred in little endian format.
Octet

Bit

Value

Description

0 .. 115(status)

0b
1b
0b
1b

ERR_History_ADOM Entry
Status Entry in StatusResponse frame (Bit 14 shall be set to 0b)
ERR_History_ADOM only
Additional to the ERR_History_ADOMthe entry shall also be entered in to
the Emergency Queue of the Error Signaling.
Not allowed in ERR_History_ADOM.
Entries with this mode may only be used by the Error Signaling itself toindicate the termination of the History Entries in the StatusResponse
frame.
An error has occurred and is active (e.g. short circuit of output detected)
An active error was cleared (e.g. no short circuit anymore)(not allowed for Status Entries)
An error / event occurred(not allowed for Status Entries)
Reserved
The field Error Code in Tab. 94 contains a vendor specific error code
The field Error Code in Tab. 94 contains POWERLINK communication
profile specific errors which are listed in App. 3.9 (Network errors,
communication errors, data link errors …)
The field Error Code in Tab. 94 contains device profile specific errors.
e.g.
191h … CiA 401, Device Profile for Generic IO Modules
192h … CiA 402, Drive Profile

14(send)
13 .. 12(mode)

0h

1h
2h
3h
11 .. 0(profile)

000h
001h
002h

003h ..
FFFh

Format of the field entry type

EPSG DS 301 V1.5.1

6.5.2

-180-

Interface to Error Signaling

Any layer of the MN or CN which intends to generate an Error Entry shall provide the following
information to the Error Signaling:•

Entry Type (all fields shall be provided, see Tab. 96)•

Error Code (see Tab. 94)•

Additional Information (see Tab. 94)

6.5.3

Processing of CN Error Information on the MNHistory or Status Entries received from CNs shall be passed to the application layer.

6.5.4

Error Signaling Bits

To avoid that the MN has to poll ERR_History_ADOM for changes, the following mechanism shallinform the MN when the Static Error Bit Field, the Status Entries or the History Entries of the CN
StatusResponse frame have changed.
The following bits shall be used for a confirmed transmission from the CN to the MN:
Field
Exception
Reset

Exception
Clear

Exception
New

Exception
Acknowledge

Abbr. Description
Initialisation of the Error Signaling
ER
When a CN receives the value 1b it shall reset its EN bit to 0b and clear the Emergency
Queue.
The MN shall send the ER bit with the following frame:
SoA( StatusRequest )In this bit the CN shall mirror the last received ER from the MN.
EC
This is required to indicate the MN that the initialisation of the Error Signaling was done.
A CN shall send the EC bit with the following frame:Asnd( StatusResponse )EN
By toggling this bit the CN informs the MN that the Static Error Bit Field or the Status
Entries have changed or that new History Entries are available in the StatusResponse
frame.
A CN shall send the EN bit with the following frames:Pres
Asnd( StatusResponse )For isochronous CNs the MN shall evaluate the EN bit of the Asnd(StatusResponse) only
in NMT_CS_PRE_OPERATIONAL_1.
EA
When the MN detects that the last sent EA bit is different to the last received EN bit itshall send a StatusRequest frame to the CN. After the StatusResonse frame was
successfully received by the MN, it shall set EA=EN.
When the bit is transferred to the CN the next time, the CN knows that it may generate a
new StatusResponse frame and toggle the EN bit again.
The MN shall send the EA bit with the following frames:
Preq
SoA(StatusRequest )Isochronous CNs shall evaluate the EA bit of the SoA(…) only in
NMT_CS_PRE_OPERATIONAL_1.

Error signaling bits
A CN shall only evaluate the ER and EA flags of the respective SoA(…) frames when the
RequestedServiceTarget is the CNs POWERLINK Node ID.

EPSG DS 301 V1.5.1

6.5.5

-181-

Initialisation

With this initialisation the MN shall prepare the CN for the Error Signaling.

MN

CN

SoA( StatusRequest) (ER=1)
ASnd ( StatusResponse) (EC=?)

Because the Asnd(StatusResponse
is sent in the same POWERLINK
cycle the value of EN and EC is notdefined at the beginning.
Because ER=1 the CN shall reset the
EN bit to 0 and clears the Emergency
Queue.
The CN shall set EC=ER

SoA( StatusRequest) (ER=1)
The MN detects thatthe initialisation was
done by the CN andshall set ER back to 0.

ASnd (StatusResponse) (EC=1)

Because ER=1 the CN shall reset the
EN bit to 0 and clears the Emergency
Queue.
The CN shall set EC=ER

SoA( StatusRequest) (ER=0)
ASnd ( StatusResponse) (EC=1)
The CN shall set EC=ER
EC = 0 … Initialisation
finished

Fig. 69.

6.5.5.1

SoA( StatusRequest) (ER=0)
ASnd ( StatusResponse) (EC=0)

Error signaling initialisation

Startup value and behaviour of the EC flag

At startup (NMT_GT1, NMT_GT2 or NMT_GT8) the CN shall reset the Error Signaling and set EC=1.
The CN shall not change the EC flag before at least 1 valid frame with ER=1 was received.
This regulation is necessary for the following case :•The MN completes the initialisation until ER=0, the CN is still in
NMT_CS_PRE_OPERATIONAL_1•

The CN has a power fail and starts up again. The next received frame from the MN contains
ER=0 … Now the CN shall respond with EC=1 to show the MN that the Error Signaling is notinitialised.

•
The MN shall restart the intialization of the Error Signaling
Other NMT transitions shall not automatically initialise the Error Signaling in order to allow the MN toreceive emergency messages even if the NMT state of the CN changes for e.g. to
NMT_GS_INITIALISATION because of any reason.
The Error Signaling shall only be initialised by NMT_GT1, NMT_GT8, NMT_GT2 or explicit Error
Signaling reset by the MN (ER=1).

EPSG DS 301 V1.5.1

6.5.6

-182-

Error Signaling with Preq and Pres frames

For isochronous CNs only the Preq and Pres frames shall be used for the Error Signaling.
If an isochronous CN is in the state NMT_CS_PRE_OPERATIONAL_1 the Error Signaling shallbehave like an Async-only CN (6.5.7)
MN

CN
PReq (EA=0)
PRes (EN=0)
PReq (EA=0).
.
.

When EA=EN the CN shallcyclically query the Error Signaling
for new StatusResponse data. If
no new data is available EN shallnot be changed.

PRes (EN=0)
If the Error Signaling passes new
StatusResponse data to the DLL
the EN bit shall be toggled.
PReq (EA=0)
The MN detects that EN isdifferent to the last sent
EA, the MN shall get the
new status via
SoA(StatusRequest)

PRes (EN=1)

PReq (EA=0)

As long as the last received EA is
not equal to EN the DLL shall NOT
query the Error Signaling for new
StatusResponse data.

PRes (EN=1)
It may take several cycles
until the MN has a freeasynchronous slot to send
the SoA(StatusRequest)

PReq (EA=0)
PRes (EN=1)
PReq (EA=0)
PRes (EN=1)
SoA (StatusRequest)

In case of acommunication error the
MN shall retry to send
the StatusRequest

ASnd (StatusResponse)

SoA (StatusRequest)
ASnd (StatusResponse)

After theASnd(StatusResponse)
was received the MN shallset EA equal to the lastreceived EN

PReq (EA=1)
PRes (EN=1)
PReq (EA=1)
PRes (EN=1)

Fig. 70.

Error signaling with Preq and Pres

When EA=EN the CN shallcontinue to query the Error
Signaling for new StatusResponse
data. If no new data is available
EN shall not be changed.

EPSG DS 301 V1.5.1

6.5.7

-183-

Error Signaling with Async-only CNs

Async only CNs are periodically requested by the MN.
This shall be also done for isochronous CNs in NMT_CS_PRE_OPERATIONAL_1.
MN

CN

SoA(StatusRequest) (EA=0)
ASnd

SoA(StatusRequest) (EA=0).
.
.

When EA=EN the CN shallcyclically query the Error Signaling
for new StatusResponse data. If
no new data is available EN shallnot be changed.

ASnd
The MN shall periodicallysend aSoA(StatusRequest) to the
CN

SoA( StatusRequest) (EA=0)
ASnd( StatusResponse) (EN=0)

EN is equal to the last sent
EA, the MN does not needto evaluate theStatusResponse data.

SoA(StatusRequest) (EA=0)

.
.
.

ASnd

SoA(StatusRequest) (EA=0)

If the Error Signaling passes new
StatusResponse data to the DLL
the EN bit shall be toggled.
EN is now 1 but can not betransferred to the MN until the MN
sends a SoA(StatusRequest)
The DLL shall stop to query theError Signaling for new
StatusResponse data.

ASnd
SoA( StatusRequest) (EA=0)
EN is different to the lastsent EA, the MN shallevaluate theStatusResponse data andset EA = EN

Now the EN flag is transferred to
the MN combined with the new
StatusResponse data.

ASnd( StatusResponse) (EN=1)

SoA(StatusRequest) (EA=1)
ASnd

Fig. 71.

.
.
.

EA is equal to the last sent EN, theCN shall continue to query theError Signaling for new
StatusResponse data.

Error signaling for Async-only CNs and CNs in state NMT_CS_PRE_OPERATIONAL_1

6.5.8

Format of StatusResponse Data

Refer to 7.3.3.3.1 for StatusResponse frame structure.

6.5.8.1

Static Error Bit Field

Octet Offset20

Description

6
7
8 .. 13

Content of ERR_ErrorRegister_U8
Reserved
Device profile or vendor specific errors
Static error bit field

6.5.8.2

Status and History Entries

If not all available entries of the StatusResponse are used, an entry with Mode 0 (see Tab. 96) shallbe used to terminate the History and Status Entry list and declare this and all following entries as
unused.
The CN may also change the length of the StatusResponse frame to fit the required Status andHistory fields. In this case no entry for termination is required.
20 Octet offset relates to the beginning of the ASnd service slot (See 7.3.3.3.1)

EPSG DS 301 V1.5.1-184-

The number of used Status / History Entries is defined by D_NMT_ErrorEntries_U32 .
Status Entries shall be located in front of the History Entries inside the StatusResponse frame.

6.5.9

ExamplesThe examples in this chapter are an implementation proposal for the creation of the StatusResponse
frames on the CN.
Another buffer handling may be implemented in consideration of the following points:•
The CN shall notify the MN about changes of the StatusResponse frame using the EN bit asshown in 6.5.6 or 6.5.7•
After the CN has indicated new StatusResponse data to the MN by toggling the EN flag, theStatusResponse frame on the CN may not be changed anymore as it can be requested by the
MN at any time. Only if the reception of the response is acknowledged by the EA flag of the MN,
the CN may change the StatusResponse frame data again.
The following examples make use of the following abbreviations:
Abbreviation

Description

BF
S
M
C

Static Error Bit Field
Bit 15 (status) of the Entry Type (see Tab. 94 Format of one entry)
Bit 13-12 (mode) of the Entry Type (see Tab. 94 Format of one entry)
Error Code (see Tab. 94 Format of one entry)
Abbreviations for the following examples

The Octet Offsets relates to the beginning of the Ethernet frame.

Case 1 – Only Bit Field, No Status/History Entries

6.5.9.1

This is the most simple implementation of the Error Signaling. Only the Static Error Bit Field is used tosignal errors from the CN to the MN.
The length of the StatusResponse frame is fixed and does not change during runtime:
Octet Offset

Description

0 .. 23
24 .. 31
32 .. 51
52 .. 71
72 .. 75

Headers
Static Error Bit Field
Entry 0 (M=0)
Entry 1 (M=0)
Ethernet CRC

Field
Headers
Static Error Bit Field
Entry 0, Entry 1

Description
Ethernet / POWERLINK / Asnd(StatusResponse) Header (see 7.3.3.3.1)
The bit field containing the status information (see 6.5.8.1)
For this example no Status Entry is required. Since the frame must have a minimum
length the first two entries can not be removed by shortening the frame. To avoid that
the MN processes this data, the field Mode of the Entry Type is 0.

At startup the Error Signaling shall generate 2 identical empty StatusResponse Frames and pass oneof them to the Data Link Layer as initial StatusResponse data. A third frame shall be generated forfurther use.
This frame of the Data Link Layer may be requested by the MN at any time.
•

Frame 1: Owner = Error Signaling (May be changed at any time)•

Frame 2: Owner = Data Link Layer•
Frame 3: Owner = Error Signaling (unused until Frame 1 is changed)
If the Static Error Bit Field has changed, the value is copied to frame 3 which will be passed to the
Data Link Layer:•

Frame 1: Owner = Error Signaling (May be changed at any time)•

Frame 2: Owner = Data Link Layer (DLL)EPSG DS 301 V1.5.1

-185-

•

Frame 3: Owner = Error Signaling (Copy of the changed Frame 1, ready to be taken from the
DLL)
Now the Error Signaling is not allowed to change this Frame 3 because it can be taken from the Data
Link Layer at any time.
The next time the DLL queries for new data the Error Signaling passes Frame 3 to the DLL which shallset the EN flag to signal the MN that new data is available. Frame 2 shall be passed back to the Error
Signaling for further use:•

Frame 1: Owner = Error Signaling (May be changed at any time)•

Frame 2: Owner = Error Signaling (unused until Frame 1 is changed)•
Frame 3: Owner = Data Link Layer (DLL)
If the Error Signaling has changed Frame 1 before Frame 2 was passed back it shall immediately
create a copy of Frame 1, otherwise it shall wait for the next change of Frame 1 and then create the
copy.
•

Frame 1: Owner = Error Signaling (May be changed at any time)•

Frame 2: Owner = Error Signaling (Copy of the changed Frame 1, ready to be taken from the
DLL)•
Frame 3: Owner = Data Link Layer (DLL)
The sequence continues in this manner and Frame 2/Frame 3 are passed alternatively to the DLL fortransmission to the MN. The DLL shall only query the Error Signaling for the next frame if EN=EA, thatmeans the MN has successfully picked up the last changed frame.

6.5.9.2

Case 2 – Status Entries

In this example the CNs are allowed to signal errors using the Static Error Bit Field and/or the Status
Entries of the StatusResponse frame.
The frame sequence is the same as in Example 1. Every time the Error Signaling makes changes of
the StatusResponse frame content (Static Error Bit Field or in one of the Status Entries) it shallprovide a new frame for the DLL which will be I as soon as EN=EA.
Example with 4 Status Entries:
Octet Offset

Description

0 .. 23
24 .. 31
32 .. 51
52 .. 71
72 .. 91
92 .. 111
112 .. 115

Headers
Static Error Bit Field
Status Entry 0
Status Entry 1
Status Entry 2
Status Entry 3
Ethernet CRC

Field
Status Entry
0 .. 3

Description
S=X,M=0This entry and all following entries are not valid
S=1,M=1,C=0
The entry does not contain status information but the next entry is valid
S=1.M=1,C>0
The entry contains valid status information

If all 4 status entries contain status information and the CN wants to remove Status Entry 1 and 2 it
has two ways to do so.
•

Set C of Entry 1 and Entry 2 to 0 to invalidate the entries•

Copy Entry 3 to Entry 1 and set M of Entry 2 to 0 to terminate the list•

Copy Entry 3 to Entry 1 and shorten the frame size

EPSG DS 301 V1.5.1

6.5.9.3-186-

Case 3 – History Entries

The CN sends History Entries or static errors to the MN. The MN shall only process the received
History Entries if EN is not equal EA so each entry will be processed only once.
The initial frame shall not contain valid Status or History Entries.
Octet Offset

Description

0 .. 23
24 .. 31
32 .. 51
52 .. 59
60 .. 63

Headers
Static Error Bit Field
Entry 0 (M=0)
Padding
Ethernet CRC

Initial frames at startup:•

Frame 1: Owner = Error Signaling (May be changed at any time)•

Frame 2: Owner = Data Link Layer•
Frame 3: Owner = Error Signaling (unused until Frame 1 is changed)
As in Example 1, the CN may change the Static Error Bit Field and perform the same sequence as in
Example 1 to signal the change to the MN.
Additionally the Error Signaling shall check periodically if the Emergency Queue (see Fig. 68 Error
signaling – Overview) contains any entries. In this case the Error Signaling also shall create a copy of
Frame 1 and append as many History Entries from the Emergency Queue to the frame as possible
and remove these entries from the queue.
Frame 1 never contains History Entries.They shall be only added to the frame passed to the DLL !
Assume the Emergency Queue contains 10 History Entries and the length of the Status Response islimited to a maximum of 150 byte, the next frame prepared for the DLL will be the following:
Octet Offset

Description

0 .. 23
24 .. 31
32 .. 51
52 .. 71
72 .. 91
92 .. 111
112 .. 131
132 .. 135

Headers
Static Error Bit Field
History Entry 0
History Entry 1
History Entry 2
History Entry 3
History Entry 4
Ethernet CRC

The frame will transport 5 of the 10 queue entries to the MN. The next time the Error Signaling shalltransfer the rest of the entries in the queue (but always maximum 5 entires in this case). The
sequence will continue in this manner until the Emergency Queue is empty.

6.5.9.4

Case 4 – Status and History Entries

The CN may also send StatusResponse frames containing both Status and History Entries. In thiscase the History Entries shall be located in the frame after the Status Entries. As shown in theexamples above the Status Entries contain static information and the History Entries are taken fromthe Emergency Queue.
The MN shall be aware that the number of Status Entries and History Entries as well as the frame
length of the StatusResponse can vary at every frame.

6.5.10Object descriptions

6.5.10.1

Object 1001h : ERR_ErrorRegister_U8

The object ERR_ErrorRegister_U8 is compatible to the object ‘error register’ of the standard
communication profile CiA DS 301.

EPSG DS 301 V1.5.1
Index
Name
Data Type
Value Range
Default Value
•

-187-

1001h
ERR_ErrorRegister_U8
UNSIGNED8
0..2550

Object Type

VAR

Category
AccessPDO Mapping

M
ro
Opt

Value Interpretation
Bit

M/O

Description

0

M

1
2
3
4
5
6
7

O
O
O
O
O
O
O

Generic error
This bit shall be set to 1b if the Static Error Bit Field or the Status Entries in the
StatusResponse frame show one or more errors.
If this bit is 0b the MN only needs to evaluate the History Entries of the
StatusResponse frame.
Current
Voltage
Temperature
Communication error
Device profile specificReserved (always 0)
Manufacturer specific6.5.10.2

Object 1003h: ERR_History_ADOM

Sub-index 0 contains the number of actual errors/events that are recorded in the array starting at subindex 1. Every new error/event is stored at sub-index 1, the older ones move down the list.
Object ERR_History_ADOM shall not be cleared upon initialisation during an NMTResetConfiguration,
NMTResetCommunication or NMTResetNode.
Note: This facilitates reading the error history after the CN performed an NMTReset following an error.
Index
Name
Data Type•

1003h
ERR_History_ADOM
DOMAIN

Object Type

ARRAY

CategoryO

AccessPDO Mappingrw
Opt

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
0 .. 254
0When writing to this sub-index only value 0 is allowed (clear history). All other values will berejected with an error code.
•

Sub-Index 01h – FE h : ErrorEntry_DOM
Sub-Index
Name-Value Range
Default Value

6.6

01h – FEhErrorEntry_DOM-see Tab. 94-

Category
AccessPDO Mapping

O
ro
No

Program Download

In this chapter, a common method for downloading a program to a device via its object dictionary is
specified. Here only the mechanism for performing the program download is specified, not thestructure of program data or the data structure. The specified mechanism can be used for
downloading complete programs to devices (e.g. if a device only provides a kind of POWERLINKEPSG DS 301 V1.5.1-188-

bootstrap loader) or only parts of a program (e.g. specific tasks of real-time systems). The data
structure of the transferred program data must be specified by the manufacturer (e.g. INTEL-HEX
format or binary format).
Further specifications for the program download are given in specific device profiles (e.g. in CiA DS405 for the download of PLC programs).
Programmability of a CN is indicated by NMT_NodeAssignment_AU32[sub-index] Bit 6.

6.6.1

Object Dictionary Entries on the CN

6.6.1.1

Object 1F50h: PDL_DownloadProgData_ADOM

PDL_DownloadProgData_ADOM holds downloaded programs. It allows the access to up to 254
programs.
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO Mappingrw
No

Category
AccessPDO Mapping

Cond
cond
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F50h
PDL_DownloadProgData_ADOM
DOMAIN00h
NumberOfEntries
00h .. FEh-

Sub-Index 01h: Program
Sub-Index
Name-Value Range
Default Value

01h
Program-DOMAIN-

Sub-index 1 is the program access point of a device that is reserved for the firmware of thedevice holding the device communication profile. Therefore no common program download tothis sub-index is allowed.
If the download fails, the device responds with an Abort SDO Transfer (error code 0606 0000h).
If the device does not support firmware download via SDO Write by Index this sub-index shallnot be present.
Note: The firmware may also be downloaded to a device by FTP or SDO File Write transfer.
If the device supports reading of the program the access shall be rw otherwise wo.
•

Sub-Index 02h .. FEh: Program
Sub-Index
Name-Value Range
Default Value

02h .. FEh
Program-DOMAIN-

Category
AccessPDO Mapping

O
cond
No

Program sub-indices provide access to additional programs in a device.
If the device supports reading of the program the access shall be rw otherwise wo.

6.6.1.2

Object 1F51h: PDL_ProgCtrl_AU8

PDL_ProgCtrl_AU8 is specified for controlling the execution of stored programs:

EPSG DS 301 V1.5.1
Index
Name
Data Type

-189-

1F51h
PDL_ProgCtrl_AU8
UNSIGNED8

Object Type

ARRAY

Category

Cond

PDL_ProgCtrl_AU8 shall be implemented if PDL_DownloadProgData_ADOM is supported by
the device.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

00h
NumberOfEntries
01h .. FEh
01hAccessPDO Mappingrw
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 01h: ProgCtrl
Sub-Index
Name-Value Range
Default Value

01h
ProgCtrl-0 .. 2 (refer Tab. 100)-

ProgCtrl controls the program holding the device communication profile to be accessed by
PDL_DownloadProgData_ADOM[1].
On write access program execution will be commanded, on read access the current execution
state of the program may be queried. The following values are defined:0
1
2

Write Access

Read Accessstop program
start program
reset program

program stopped
program running
program stopped

PDL_ProgCtrl_AU8 sub-index value interpretation
If the action is not possible, the device shall responds with an Abort SDO Transfer (error code
0800 0024h).
•

Sub-Index 02h .. FEh: ProgCtrl
Sub-Index
Name-Value Range
Default Value

02h .. FEh
ProgCtrl-0 .. 2 (refer Tab. 100)-

Category
AccessPDO Mapping

Cond
rw
No

ProgCtrl sub-indices control the additional programs to be accessed via the
PDL_DownloadProgData_ADOM sub-indices 02h .. FEh. The respective sub-index shall be
implemented if the corresponding sub-index of PDL_DownloadProgData_ADOM is provided by
the device.

6.6.1.3

Object 1F52h: PDL_LocVerApplSw_REC

PDL_LocVerApplSw_REC is defined to support verification of the version of the program holding thedevice communication profile to be accessed via PDL_DownloadProgData_ADOM[1] 21.

21 Note that the object NMT_ManufactDevName_VS can be regarded as a version number of a fixed

program of a non-programmable node or as a firmware (like boot block and operating system) version
number of a programmable node. Hence, a separate object for re-programmable application softwareis defined.

EPSG DS 301 V1.5.1
Index
Name
Data Type

-190-

1F52h
PDL_LocVerApplSw_REC
PDL_LocVerApplSw_TYPE

Object TypeRECORD

Category

Cond

PDL_LocVerApplSw_REC shall be implemented if PDL_DownloadProgData_ADOM is
supported by the device.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

00h
NumberOfEntries
2
2

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 01h: ApplSwDate_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
ApplSwDate_U32
UNSIGNED32
UNSIGNED32-

ApplSwDate_U32 shall contain the number of days since January 1, 1984.
•

Sub-Index 02h: ApplSwTime_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ApplSwTime_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

M
rw
No

ApplSwTime_U32 shall contain the number of ms since midnight.
Note that the date and time are only supported for the default application program. Dates andtimes of additional programs 2 to 254 are not supported. In case of two or more programs, one
possibility could be to store the latest update time and date of any of the programs 2 to 254 in
the objects PDL_MnExpAppSwDateList_AU32 and PDL_MnExpAppSwTimeList_AU32.

6.6.1.4

Object 0427h: PDL_LocVerApplSw_TYPE

Index
Name

0427h
PDL_LocVerApplSw_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h

Component Name
NumberOfEntries
ApplSwDate_U32
ApplSwTime_U32

Value
02h
0007h
0007h

Data Type

6.6.2

UNSIGNED32
UNSIGNED32

Object Dictionary Entries on the MN

Two MN located objects are specified for verification of the version of the application software at theCNs.
In programmable devices the objects shall be compared to PDL_LocVerApplSw_REC reflecting theversion of the downloaded program holding the device communication profile accessible via
PDL_DownloadProgData_ADOM[1].
In non-programmable devices the objects may be used to store verification data to be compared to
NMT_ManufactSwVers_VS.

EPSG DS 301 V1.5.1

6.6.2.1-191-

Object 1F53h: PDL_MnExpAppSwDateList_AU32

PDL_MnExpAppSwDateList_AU32 holds the expected Application SW date to be compared to theactual value on the CN in order to verify the Application SW.
Index
Name
Data Type•

1F53h
PDL_MnExpAppSwDateList_AU32
UNSIGNED32

ARRAY

Category

Cond

AccessPDO Mapping

rws
No

Category
AccessPDO Mapping

O
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

Object Type00h
NumberOfEntries
01h .. FEh
FEh

Sub-Index 01h .. FEh: AppSwDate
Sub-Index
Name-Value Range
Default Value

01h .. FEh
AppSwDate-UNSIGNED32
0Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 5.
AppSwDate contains the number of days since January 1, 1984.
PDL_MnExpAppSwDateList_AU32 shall be implemented by MNs if the MN supports program
verification.
PDL_MnExpAppSwDateList_AU32 may be implemented by CNs to hold latest update date ofadditional programs to be accessed via PDL_DownloadProgData_ADOM sub-indices 02h .. FEh.

6.6.2.2

Object 1F54h: PDL_MnExpAppSwTimeList_AU32

PDL_MnExpAppSwTimeList_AU32 holds the expected Application SW time to be compared to theactual value on the CN in order to verify the Application SW.
Index
Name
Data Type•

Object Type

ARRAY

Category

Cond

AccessPDO Mapping

rws
No

Category
AccessPDO Mapping

O
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F54h
PDL_MnExpAppSwTimeList_AU32
UNSIGNED3200h
NumberOfEntries
01h .. FEh
FEh

Sub-Index 01h .. FEh: AppSwTime
Sub-Index
Name-Value Range
Default Value

01h .. FEh
AppSwTime-UNSIGNED32
0Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 5.
AppSwTime contains the number of milliseconds after midnight (00:00).

EPSG DS 301 V1.5.1-192-

PDL_MnExpAppSwTimeList_AU32 shall be implemented by MNs if the MN supports program
verification.
PDL_MnExpAppSwTimeList_AU32 may be implemented by CNs to hold latest update time ofadditional programs to be accessed via PDL_DownloadProgData_ADOM sub-indices 02h .. FEh.

6.7

Configuration Management

The configuration of a device may be stored locally on the device in a non-volatile memory or centrally
on the MN performing the Configuration Manager function.
The Configuration Manager is an optional application residing on the MN. It may configure network
devices at network boot-up. Support of Configuration Manager functions shall be indicated by device
description entry D_CFM_ConfigManager_BOOL.
For this it has to know the (application dependent) parameter values. This information may beprovided by a Device Configuration File for each device. This file is stored on the MN. In order toreduce memory consumption Concise Configuration Storage may be applied.
POWERLINK defines a XML based Device Description (XDD) and Device Configuration (XDC) fileformat. The file format is described in detail in a separate paper (POWERLINK XML Specification).

6.7.1

Device Description

The Device Description File provides information about the device’s basic communication andfunctional properties.
POWERLINK employs XDD Files for Device Description. These files shall be provided by the
manufacturer of the device.
XDD files may be stored locally on the device or centrally on the MN.

6.7.1.1

Local Storage on the Device

With some devices it may be possible to store the Device Description File (XDD) locally on the device.
Local XDD File storage has some advantages:•

The manufacturer does not have the problem of distributing the XDD File via data carrier.

•Management of different XDD File versions for different software versions is less error prone, ifthey are stored together.

•

The complete network settings may be stored on the network. This makes the task of analyzingor reconfiguring a network easier for tools and more transparent for the users.
The object CFM_StoreDevDescrFile_DOM contains the XDD File. The format of the file is describedby object CFM_StoreDevDescrFormat_U16.
The XDD File is downloaded from a Configuration Tool to the device by writing the file as a domain to
CFM_StoreDevDescrFile_DOM. The file is uploaded by reading CFM_StoreDevDescrFile_DOM.

6.7.1.2

Central Storage on the MN

For those devices which are not able to store their XDD Files, the Configuration Manager on the MN
may take over this task. The objects CFM_StoreDevDescrFileList_ADOM and
CFM_DevDescrFileFormatList_AU8 are defined at the Configuration Manager to hold the fileinformation.
The device XDD File is downloaded from a Configuration Tool to the Configuration Manager by writing
the file as a domain to CFM_StoreDevDescrFileList_ADOM with the sub-index equal to the device’s
Node ID.
The file is uploaded to a tool by reading CFM_StoreDevDescrFileList_ADOM with the sub-index equal
to the device’s Node ID.

6.7.2

Device Configuration Storage

Device Configuration provides application specific setup values.

EPSG DS 301 V1.5.1

6.7.2.1-193-

Device Configuration File Storage

Centralized storage of device configuration is performed by the Configuration Manager on the MN.
Data is stored in the form of a Device Configuration File (XDC).
XDC Storage is managed by the the objects CFM_StoreDcfList_ADOM and
CFM_DcfStorageFormatList_AU8. CFM_StoreDcfList_ADOM holds the XDC Files and
CFM_DcfStorageFormatList_AU8 provides information about the files’ storage format. Each sub-index
of the ARRAYs points to the Node ID of the device to which the XDC belongs.
The XDC is downloaded from a Configuration Tool to the Configuration Manager by writing the XDCFile as a domain to CFM_StoreDcfList_ADOM with the sub-index equal to the device’s Node ID.
The XDC is uploaded from the Configuration Manager to a Tool by reading the object
CFM_StoreDcfList_ADOM with the sub-index equal to the device’s Node ID.

6.7.2.2

Concise Configuration Storage

The Concise Device Configuration does not contain all of the information contained in the XDC. The
information to be stored consists of the parameter values of the object dictionary entries. The
information is stored by a stream assigning data values to the particular objects and sub-indices. (SeeTab. 102)
It is recommended that Concise Configuration Storage is used when complete XDC storage is notpossible.
The concise configuration of a device is downloaded from a Configuration Tool to the Configuration
Manager by writing the stream as a domain to CFM_ConciseDcfList_ADOM with the sub-index equal
to the device’s Node ID.
The concise DCF of a device is uploaded from the Configuration Manager to a Tool by reading theobject CFM_ConciseDcfList_ADOM with the sub-index equal to the device’s Node ID.

6.7.2.3

Check Configuration Process

POWERLINK defines the object CFM_VerifyConfiguration_REC. If a device supports saving ofparameters in non-volatile memory, the MN or a configuration tool may use this object to verify theconfiguration after a device is reset and to check whether a reconfiguration is necessary. The
configuration tool shall store configuration date, time and ID in CFM_VerifyConfiguration_REC andshall store the same values in the respective sub-indices of CFM_ExpConfDateList_AU32,
CFM_ExpConfTimeList_AU32 and CFM_ExpConfIdList_AU32.
Now the configuration tool orders the device to save its configuration by writing the signature “save” to
NMT_StoreParam_REC.AllParam_U32.
After a reset the device restores the last configuration and the signature automatically or by request.
The Configuration Manager compares the signature in CFM_VerifyConfiguration_REC to therespective sub-indices of CFM_ExpConfDateList_AU32, CFM_ExpConfTimeList_AU32 and/or
CFM_ExpConfIdList_AU32 and decides if a reconfiguration is necessary or not.

6.7.2.4

Request Configuration

In some applications there might be situations where it is necessary to configure CNs during run-time– for example, if a CN fails and re-boots. The NMT master will recognize this and inform theapplication (see chapter 7.4.2.2.1.2). With the object CFM_ConfCNRequest_AU32 the NMT master
application is able to tell the Configuration Manager to configure that CN.
Another example is the connection of a new machine part with several devices. The application needs
the ability to start the Configuration Manager at least for the new nodes.
Configuration may be also requested by the target CN itself or by a tool residing on another CN.
To initiate the configuration process of a single CN, the requester writes the signature “conf” to thesub-index equal to the CN’s Node ID.
A SDO Write Request to sub-index FFh is used to start an overall re-configuration of all CNs on thesystem. This function enables simple applications to request the Configuration Management without
knowing the actual project configuration.

EPSG DS 301 V1.5.1

-194-

6.7.3

Object Dictionary Entries

6.7.3.1

Object 1020h: CFM_VerifyConfiguration_REC

CFM_VerifyConfiguration_REC holds device local Configuration date and time.
Index
Name
Data Type•

Object TypeRECORD

CategoryM

AccessPDO Mapping

const
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1020h
CFM_VerifyConfiguration_REC
CFM_VerifyConfiguration_TYPE

00h
NumberOfEntries
2 .. 4-Sub-Index 01h: ConfDate_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
ConfDate_U32
UNSIGNED32
UNSIGNED32
0

ConfDate_U32 holds the local configuration date. It contains the number of days since January
1, 1984.
•

Sub-Index 02h: ConfTime_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ConfTime_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO MappingMrws, valid on reset
No

ConfDate_U32 holds the local configuration time. It contains the number of ms since midnight.
•

Sub-Index 03h: ConfId_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
ConfId_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
rws
No

ConfId_U32 holds a configuration ID value.
The value shall be created by a configuration tool in a manufacturer specific way.
In a POWERLINK network it should be identical only on those nodes, that have an identical HW
and configuration besides some node specific objects like POWERLINK Node ID(NMT_EPLNodeID_REC.NodeID_U8), SerialNumber (NMT_IdentityObject_REC.SerialNo_U32)
etc. Otherwise ConfId_U32 should be unique for each node in an Ethernet POWERLINK
network segment.

EPSG DS 301 V1.5.1
•

-195-

Sub-Index 04h: VerifyConfInvalid_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

04h
VerifyConfInvalid_BOOL
BOOLEANBOOLEAN
TRUE

Category
AccessPDO Mapping

O
ro
No

VerifyConfInvalid_BOOL enables temporary local modifications of configuration parameters fortest purpose while maintaining the bootability of the network.
VerifyConfInvalid_BOOL = FALSE indicates that the configuration was not modified since thelast storage of ConfId_U32 (sub-index 03h).
A change of a parameter defined in this specification which is stored in permanent memory shallset VerifyConfInvalid_BOOL to TRUE. It may be set also by the application.
VerifyConfInvalid_BOOL shall be set to FALSE upon writing a value > 0 to ConfId_U32.
A configuration tool or an application may use this information to display a warning if theconfiguration of a node was modified.

6.7.3.2

Object 1021h: CFM_StoreDevDescrFile_DOM

CFM_StoreDevDescrFile_DOM holds the device local Device Description File.
Index
Name
Data Type
Value Range
Default Value

1021h
CFM_StoreDevDescrFile_DOM
DOMAINDOMAIN-

Object Type

VAR

Category
AccessPDO MappingOro or rws
No

The object is read-only if the Device Description File stored by CFM_StoreDevDescrFile_DOM
is unchangable.
Otherwise a Device Description File may be downloaded from a configuration tool by writing thefile as a domain to CFM_StoreDevDescrFile_DOM. Reading the object uploads to the tool.
The availability of a Device Description File at CFM_StoreDevDescrFile_DOM is indicated by
CFM_StoreDevDescrFormat_U16. If no data had been stored(CFM_StoreDevDescrFormat_U16 = FFh), a SDO Read Request to
CFM_StoreDevDescrFile_DOM is aborted with the error code E_CFM_DATA_SET_EMPTY.

6.7.3.3

Object 1022h: CFM_StoreDevDescrFormat_U16

CFM_StoreDevDescrFormat_U16 holds the format of the Device Description File stored by
CFM_StoreDevDescrFile_DOM.
Index
Name
Data Type
Value Range
Default Value

1022h
CFM_StoreDevDescrFormat_U16
UNSIGNED16
refer Tab. 101-

Object Type

VAR

Category
AccessPDO MappingCondro or rws
No

The object shall be implemented if CFM_StoreDevDescrFile_DOM is implemented.
The object is read-only if the Device Description File stored by CFM_StoreDevDescrFile_DOM
is unchangable.
CFM_StoreDevDescrFormat_U16 describes the format of the storage. This allows the use ofcompressed formats. The device may always store the file in a compressed format internally.
The CFM_StoreDevDescrFormat_U16 object describes the external behavior.
Valid values are:EPSG DS 301 V1.5.1

-196-

Value

Format00h

XML XDD format as defined inseparate paper, not compressed
reserved
no Device Description File available

01h to FEh
FFh

Device description file and device configuration storage formats

6.7.3.4

Object 1F20h: CFM_StoreDcfList_ADOM

CFM_StoreDcfList_ADOM holds XDC files for configured CNs. The object may be implemented on the
MN only, if object CFM_DcfStorageFormatList_AU8 is implemented.
Index
Name
Data Type•

Object Type

ARRAY

Category

Cond

AccessPDO MappingroNoCategory
AccessPDO Mapping

Cond
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F20h
CFM_StoreDcfList_ADOM
DOMAIN00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNDcf
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNDcf-DOMAIN-

Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
A XDC is downloaded from a Configuration Tool to the Configuration Manager by writing theXDC File to the respective CFM_StoreDcfList_ADOM sub-index. The tool uploads the XDC byreading the sub-index.
The availability of XDC data at a CFM_StoreDcfList_ADOM sub-index is indicated by thecorresponding CFM_DcfStorageFormatList_AU8 sub-index. If no data is stored(CFM_DcfStorageFormatList_AU8.CNDcfFormat[sub-index] = FFh), a SDO Read Request to
the CFM_StoreDcfList_ADOM sub-index is aborted with the error code
E_CFM_DATA_SET_EMPTY.

6.7.3.5

Object 1F21h: CFM_DcfStorageFormatList_AU8

CFM_DcfStorageFormatList_AU8 holds the format of the XDC files for configured CNs. The object
may be implemented on the MN only.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1F21h
CFM_DcfStorageFormatList_AU8
UNSIGNED8

Object Type

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

Cond
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-197-

00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNDcfFormat
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNDcfFormat-refer Tab. 101FFh

CNDcfFormat describes the format of the storage. This allows the use of compressed formats.
The device may always store the file in a compressed format internally. The CNDcfFormat
object describes the external behavior.
Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0 and 1.
If no data is stored (CNDcfFormat[sub-index] = FFh), a SDO Read Request to the
CFM_StoreDcfList_ADOM sub-index is aborted with the error code
E_CFM_DATA_SET_EMPTY.

6.7.3.6

Object 1F22h: CFM_ConciseDcfList_ADOM

CFM_ConciseDcfList_ADOM holds Concise Configuration data for configured CNs. The object may
be implemented on the MN only.
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

O
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F22h
CFM_ConciseDcfList_ADOM
DOMAIN00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNConciseDcfData
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNConciseDcfData-DOMAIN-

The content of CNConciseDcfData is a stream with the following structure:EPSG DS 301 V1.5.1

Item nItem 2Item 1

Number of supported entries
Index 1Sub-index 1
Data size of parameter 1
Data of parameter 1
Index 2Sub-index 2
Data size of parameter 2
Data of parameter 2:::::::
Index nSub-index nData size of parameter nData of parameter n-198-

UNSIGNED32
UNSIGNED16
UNSIGNED8UNSIGNED32
DOMAINUNSIGNED16
UNSIGNED8UNSIGNED32
DOMAINUNSIGNED16
UNSIGNED8UNSIGNED32
DOMAIN

Concise DCF stream format
The Data Size is measured in octets (i.e. UNSIGNED16 has size 2; size of BOOL is given as 1).
Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
Device configuration is uploaded from a Configuration Tool to the Configuration Manager by
writing the stream as domain to the respective CNConciseDcfData sub-index. Reading thestream uploads to a tool.
An empty data set is written by the following concise stream:
Number of supported entries

0 (UNSIGNED32)

If no data has been stored, a SDO Read Request will return a valid concise stream with thefollowing content:
Number of supported entries

6.7.3.7

0 (UNSIGNED32)

Object 1F23h: CFM_StoreDevDescrFileList_ADOM

CFM_StoreDevDescrFileList_ADOM holds Device Description Files of configured CNs. The object
may be implemented on the MN only, if object CFM_DevDescrFileFormatList_AU8 is implemented.
Index
Name
Data Type•

1F23h
CFM_StoreDevDescrFileList_ADOM
DOMAIN

Object Type

ARRAY

Category

Cond

AccessPDO MappingroNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1 .. 254
254

EPSG DS 301 V1.5.1

•

-199-

Sub-Index 01h .. FEh: CNDevDescrFile
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNDevDescrFile-DOMAIN-

Category
AccessPDO Mapping

O
rws
No

Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
A Device Description File is downloaded from a Configuration Tool to the Configuration
Manager by writing the file to the respective CFM_StoreDevDescrFileList_ADOM sub-index.
Reading the the sub-index uploads to the tool.
The availability of a Device Description File at a CFM_StoreDevDescrFileList_ADOM sub-index
is indicated by the corresponding CFM_DevDescrFileFormatList_AU8 sub-index. If no data had
been stored (CFM_DevDescrFileFormatList_AU8. CNDevDescrFileFormat [sub-index] = FFh), a
SDO Read Request to the CFM_StoreDevDescrFileList_ADOM sub-index is aborted with theerror code E_CFM_DATA_SET_EMPTY.

6.7.3.8

Object 1F24h: CFM_DevDescrFileFormatList_AU8

CFM_DevDescrFileFormatList_AU8 holds the format of the Device Description Files for configured
CNs. The object may be implemented on the MN only.
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

Cond
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F24h
CFM_DevDescrFileFormatList_AU8
UNSIGNED800h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNDevDescrFileFormat
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNDevDescrFileFormat-refer Tab. 101FFh

CNDevDescrFileFormat describes the format of the storage. This allows the usage ofcompressed formats. The device may always store the file in a compressed format internally.
The object describes the external behavior.
Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
A sub-index is implemented if the corresponding sub-index of
CFM_StoreDevDescrFileList_ADOM is implemented.

6.7.3.9

Object 1F25h: CFM_ConfCNRequest_AU32

CFM_ConfCNRequest_AU32 is used to request configuration data by a CN from the Configuration
Manager under runtime conditions. The object may be implemented on the MN only.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1F25h
CFM_ConfCNRequest_AU32
UNSIGNED32

Object Type

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

O
wo
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-200-

00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNConfigurationRequest
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNConfigurationRequest-UNSIGNED32
0Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
To initiate the configuration process, the CN writes the signature “conf” to the respective subindex.
Signature

MSB

ISO 8859 (“ASCII”)
hex

f
66h

LSB

n
6Eh

o
6Fh

c
63h

CNConfigurationRequest write access signature
If no data had been stored, a SDO Write Request to 01 h to FEh is aborted with the error code
E_CFM_DATA_SET_EMPTY.
A SDO Write Request to sub-index FFh returns without error.

6.7.3.10

Object 1F26h: CFM_ExpConfDateList_AU32

CFM_ExpConfDateList_AU32 holds a list of expected Configuration dates of configured CNs. The
object may be implemented on the MN only.
Index
Name
Data Type•

1F26h
CFM_ExpConfDateList_AU32
UNSIGNED32

Object Type

ARRAY

CategoryO

AccessPDO MappingroNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1 .. 254
254

EPSG DS 301 V1.5.1

•

-201-

Sub-Index 01h .. FEh: CNConfigurationDate
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNConfigurationDate-UNSIGNED32
0

Category
AccessPDO Mapping

O
rws
No

Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
Each sub-index holds the configuration date of the respective CN. It contains the number ofdays since January 1, 1984. It is evaluated in conjunction with the corresponding
CFM_ExpConfTimeList_AU32 sub-index.

6.7.3.11

Object 1F27h: CFM_ExpConfTimeList_AU32

CFM_ExpConfTimeList_AU32 holds a list of expected Configuration times of configured CNs. The
object may be implemented on the MN only.
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

Cond
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F27h
CFM_ExpConfTimeList_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: CNConfigurationTime
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNConfigurationTime-UNSIGNED32
0Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
Each Sub-index holds the configuration time of the respective CN. It contains the number of mssince midnight. It is evaluated in conjunction with the corresponding
CFM_ExpConfDateList_AU32 sub-index.
A sub-index is implemented if the corresponding sub-index of CFM_ExpConfDateList_AU32 is
implemented.

6.7.3.12

Object 1F28h: CFM_ExpConfIdList_AU32

CFM_ExpConfIdList_AU32 holds a list of expected Configuration IDs of configured CNs. The object
may be implemented on the MN only.
Index
Name
Data Type

1F28h
CFM_ExpConfIdList_AU32
UNSIGNED32

Object Type

ARRAY

CategoryOEPSG DS 301 V1.5.1•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-202-

00h
NumberOfEntries
1 .. 254
254

AccessPDO MappingroNoCategory
AccessPDO Mapping

Cond
rws
No

Sub-Index 01h .. FEh: CNConfigurationId
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNConfigurationId-UNSIGNED32
0Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] bits 0 and 1.
Each Sub-index holds the configuration ID of the respective CN.

6.7.3.13

Object 0435h: CFM_VerifyConfiguration_TYPE

Index
Name

0435h
CFM_VerifyConfiguration_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
ConfDate_U32
ConfTime_U32
ConfId_U32
VerifyConfInvalid_BOOL

Value
04h
0007h
0007h
0007h
0001h

Data Type

6.8

Input from a Programmable Device

6.8.1

BasicsUNSIGNED32
UNSIGNED32
UNSIGNED32
BOOLEANIn a network a programmable node can be characterised as a process having input and output
variables. The set of variables will be arguments of the program and hence their values will not be
determined until after the programm is written. The arguments must be handled as variables located in
the object dictionary.
The definition of such parameters depends on the programming system (e.g. IEC61131-3) and can
not be standardised here. It can be assumed, however, that there exists a set of network variables
with the logic attribute EXTERN.
Compiling/Linking (or interpreting) a program including EXTERN variables requires relocation
information. Within POWERLINK devices this information is the index (and sub-index) of the variable.
Most programming systems use the mechanism of a resource definition, used to assign the
POWERLINK attributes (index, sub-index, rw, assignment of POWERLINK data type to local data
type, etc.) to the corresponding symbolic names (variable name in the program). The resource
definition may be created by the user with a simple editor, or, more conveniently using a configuration
tool. On systems with a disk-based file system a direct exchange via the DCF format is possible.
Variable names must meet the rules of the underlying programming system. POWERLINK imposes nosystem-specific restrictions on variable names: correct naming is the responsibility of the
programmer/manufacturer.
Defining EXTERN variables requires a rule for distributing the indices, called “dynamic index
assignment”.

EPSG DS 301 V1.5.1

6.8.2

-203-

Dynamic index assignment

The index area used for dynamic index assignment is dependent on the device. Each data type anddirection (Input/Output) has its own area, called a segment. Segments must not overlap. Variables ofthe same data type are gathered in an array. If all elements of an array are defined (sub-index 01h toFEh), the next free object of the area is allocated.
In order to allow programmable devices the use of a process image, they may implement a conversion
formula to calculate the offset of a variable in the process image directly from the index and sub-index.
Definition of the abstract object segment (also called dynamic channel):A segment is a range of indices in the object dictionary with the following attributes:•

Data typeThe data type of the objects which can be defined in this segment.

•

Direction
The direction flag distinguishes between inputs and outputs. The values are ‘wo’ for outputs and‘ro’ for inputs. The distinction is important to enable the correct mapping of the variable into a
receive PDO (wo) or transmit PDO (ro). This does not affect the access possibilities via SDO.

•

Index range
The range of indices with start index and end index.

•

PIOffset
The offset in the process image, where the first object of this segment is allocated.
For byte and multi-byte variables the PIOffset is a 32-bit unsigned offset value.
For Boolean variables it is the offset and additionally the address difference between two
Boolean variables counted in bits. If Boolean variables are packed in bytes one bit after theother, the value is 1. If Booleans are each stored in a byte cell, the value is 8.

•

Maximum count

The maximum number of variables in this segment.
Some devices distinguish strictly between different segments in the process image for different datatypes. For these devices the PIOffset of the first segment will be 0, the PIOffset of the second segment
will be the maximum count of the first segment multiplied by the data type size of the first segment andso on. If the result does not exactly meet the physical configuration, the device software is free to map
the segments into the object dictionary in a logical fashion using internal segment descriptors/offsets.
Some devices mix different data types in the same segment. For these devices all PIOffset attributes
will have the value 0. Configuration Tools that allocate space in the process image by assigning
indices must ensure that under these circumstances indices are omitted to avoid overlapping. (Forspecial applications there may be a feature to explicitly overlap variables – for example, to aid
debuggers interpreting memory cells as different data types.)
Any mixed form of these two device types is possible.

6.8.3

Object dictionary entries

The network variables are accessed via the entries described by the segments. In some applications it
is desirable to read or write the complete process image as one block:EPSG DS 301 V1.5.1

6.8.3.1-204-

Object 1F70h: INP_ProcessImage_REC

INP_ProcessImage_REC provides access to process image segments.
Index
Name
Data Type•

1F70h
INP_ProcessImage_REC
INP_ProcessImage_TYPE

RECORD

CategoryO

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

Object Type00h
NumberOfEntries2
2

Sub-Index 01h: SelectedRange_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
SelectedRange_U32
UNSIGNED32
UNSIGNED32
0

Defines the process image segment to be accessed. After writing to SelectedRange_U32 thecorresponding data can be read from or written to the addressed area with
ProcessImageDomain_DOM as an unstructured stream of bytes.
The structure of SelectedRange_U32 is as follows:
MSB
31

16

Data length

15

LSB
0

Object segment

Structure of SelectedRange_U32
The Object Segment to be addressed is given by the Index. If several Segments areoverlapping, the same memory area can be addressed with each of the indices.
The Data Length gives the maximum size of the transfer in bytes. If the value is 0, the complete
segment is to be accessed.
•

Sub-Index 02h: ProcessImageDomain_DOM
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ProcessImageDomain_DOM
DOMAINDOMAIN0

Category
AccessPDO Mapping

M
rw
No

Holds the data of the segment addressed by SelectedRange_U32 as an unstructured stream ofbytes.

6.8.3.2

Object 0428h: INP_ProcessImage_TYPE

Index
Name

0428h
INP_ProcessImage_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h

Component Name
NumberOfEntries
SelectedRange_U32
ProcessImageDomain_DOM

Value
02h
0007h
000Fh

Data TypeUNSIGNED32
DOMAINEPSG DS 301 V1.5.1

-205-

7

Network Management (NMT)

7.1

NMT State Machine

7.1.1

Overview

The NMT state machine determines the behaviour of the communication function unit (see 2.2.1). The
coupling of the application state machine to the NMT state machine is device dependent and falls into
the scope of device profiles.
Both MN and CN start up by common initialisation process. At the end of this process, the nodespecific POWERLINK Node ID is evaluated in order to decide, if the node is setup to be an MN or a
CN. The further process differentiates between an MN specific branch and a CN specific one.
The common initialisation process is described by 7.1.2. The paragraph also handles PowerOn,
PowerOff and reset levels common to MN and CN.
The MN specific branch is described by Tab. 105, the CN specific one by 7.1.4. Only one of thesebranches shall be executed on a node.

7.1.2

Common Initialisation NMT State Machine

In Fig. 72 the initialisation of the NMT state machine, common to MN and CN is shown. Fig. 72 also
displays PowerOn, PowerOff and common reset levels that affect both MN and CN.
The common initialisation NMT state machine is the nodes upper layer NMT state machine. The MN
and CN specific NMT state machines are nested into this state machine. Only one of these nested
state machines shall be executed on a node. PowerOff and Reset displayed by the upper layermachine affect each of the nested state machines.

7.1.2.1

States

7.1.2.1.1

NMT_GS_POWEREDAll the states handled by this paragraph are states that are valid when the device is powered, e.g. theyshall be regarded to be sub-states of the super-state NMT_GS_POWERED.
NMT_GS_POWERED shall be entered on PowerOn (NMT_GT1). It shall be left on PowerOff(NMT_GT3).
NMT_GS_POWERED is a super-state that will not be signalled over the network by an individual NMT
state value.

7.1.2.1.1.1

NMT_GS_INITIALISATION

After system start, the node attains the state NMT_GS_INITIALISATION. The node automatically shallenter this state, an NMT command shall not be necessary. In the state NMT_GS_INITIALISATION,
the network functionality shall be initialised.
NMT_GS_INITIALISATION and its sub-states are node internal states only. They will not be signalledover the network by NMT state.

EPSG DS 301 V1.5.1-206-(NMT_GT1)
PowerOn

NMT_GS_POWERED(NMT_GT2)Reset

NMT_GS_INITIALISATION

NMT_GS_INITIALISING(NMT_GT8)
NMT_SwReset(NMT_GT10)
auto

NMT_GS_RESET_APPLICATION(NMT_GT11)
auto(NMT_GT4)
NMT_ResetNode

NMT_GS_RESET_COMMUNICATION(NMT_GT5)
NMT_ResetCommunication(NMT_GT12)
auto(NMT_GT6)Internal Communication Error

NMT_GS_RESET_CONFIGURATION(NMT_GT7)
NMT_ResetConfiguration(NMT_CT1)(NMT_MT1)
Auto
Auto[NodeID !=[NodeID ==C_ADR_MN_DEF_NODE_ID] C_ADR_MN_DEF_NODE_ID]

NMT_GS_COMMUNICATING

NMT_CSNMT CN STATEMACHINE

NMT_MNNMT MN STATEMACHINE(NMT_GT3)
PowerOffFig. 72.

Common initialisation NMT state machine

7.1.2.1.1.1.1

Sub-states

The state NMT_GS_INITIALISATION is divided into four sub-states in order to enable a complete orpartial reset of a node (see Fig. 72).
•

NMT_GS_INITIALISING
This is the first sub-state the POWERLINK node shall enter after Power On (NMT_GT1),
hardware resp. software Reset (NMT_GT2) or the reception of an NMTSwReset (NMT_GT8)
command. After finishing the basic node initialisation, the POWERLINK node shallautonomously enter the sub-state NMT_GS_RESET_APPLICATION (NMT_GT10).

•

NMT_GS_RESET_APPLICATIONIn this sub-state, the parameters of the manufacturer-specific profile area and of thestandardised device profile area shall be set to their PowerOn values. After setting the PowerOnvalues, the sub-state NMT_GS_RESET_COMMUNICATION shall be entered autonomously(NMT_GT11).
NMT_GS_RESET_APPLICATION shall be entered upon the reception of an NMTResetNodecommand from all sub-states of NMT_GS_COMMUNICATING, e.g. the NMT MN resp. CN statemachine.

EPSG DS 301 V1.5.1
•

-207-

NMT_GS_RESET_COMMUNICATIONIn this sub-state the parameters of the communication profile area (except
ERR_History_ADOM) shall be set to their PowerOn values.
NMT_GS_RESET_COMMUNICATION shall be entered upon the recognition of an internal
communication error or the reception of an NMTResetCommunication command from all substates of NMT_GS_COMMUNICATING, e.g. the MN resp. CN NMT state machine.
PowerOn values are the last stored parameters. If no stored configuration is available or if theReset was preceded by a restore default command (object NMT_RestoreDefParam_REC), thePowerOn values shall be set to the default values according to the communication and device
profile specifications.

•

NMT_GS_RESET_CONFIGURATIONIn this sub-state the configuration parameters set in the object dictionary are used to generate
the active device configuration. The node shall examine its Node ID in order to decide if it’sconfigured to be an MN or a CN. If the node is equal to C_ADR_MN_DEF_NODE_ID , the node
shall enter the MN NMT state machine (NMT_MT1), otherwise the CN NMT state machine shallbe entered (NMT_CT1).
NMT_GS_RESET_CONFIGURATION shall be entered upon the reception of an
NMTResetConfiguration command from all substates of NMT_GS_COMMUNICATING.
This sub-state is used to re-configure devices which do not support storing of communication
parameters.

7.1.2.1.1.2

NMT_GS_COMMUNICATING

When leaving the state NMT_GS_INITIALISATION (NMT_MT1 resp. NMT_CT1) the super-state
NMT_GS_COMMUNICATING will be entered. NMT_GS_COMMUNICATING includes the MN NMT
state machine (refer 7.1.3) as well as the CN NMT state machine (refer 7.1.4).
There shall be a transition from NMT_GS_COMMUNICATING to NMT_GS_INITIALISATION if an
NMTSwReset (NMT_GT8), NMTResetNode (NMT_GT4), NMTResetCommunication (NMT_GT5) or
NMTResetConfiguration (NMT_GT7) command is received or an internal communication error occurs(NMT_GT6).
NMT_GS_COMMUNICATING is a super-state that won’t be signalled over the network by anindividual NMT state value.

7.1.2.2(NMT_GT1)

Transitions(NMT_GT2)

PowerOn [ ] / start basic node initialisation
On PowerOn, NMT_GS_INITIALISATION sub-state NMT_GS_INITIALISING shall be enteredautonomously.
NMT_GT1, NMT_GT2 and NMT_GT8 are equivalent transitions, triggered by different reset
sources.
Reset [ ] / start basic node initialisation(NMT_GT3)

After Hardware or local software Reset, NMT_GS_INITIALISATION sub-state
NMT_GS_INITIALISING shall be entered autonomously.
NMT_GT1, NMT_GT2 and NMT_GT8 are equivalent transitions, triggered by different reset
sources.
PowerOff [ ]POWERLINK node was powered off in NMT_GS_POWERED(NMT_GT4) NMTResetNode [ ] / start application initialisation
If an NMTResetNode command is received in NMT_GS_COMMUNICATING,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_APPLICATION shall be entered.
(NMT_GT5) NMTResetCommunication [ ] / start communication initialisation
If an NMTResetCommunication command is received in NMT_GS_COMMUNICATING,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_COMMUNICATION shall be entered.

EPSG DS 301 V1.5.1(NMT_GT6)(NMT_GT7)-208-

Internal Communication Error [ ] / start communication initialisation
If an Internal Communication Error is recognized in NMT_GS_COMMUNICATING,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_COMMUNICATION shall be entered.
NMTResetConfiguration [ ] / activate device configuration

If an NMTResetConfiguration command is received in NMT_GS_COMMUNICATING,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_CONFIGURATION shall be entered.
If parameters of the object dictionary concerning the device’s cycle configuration (node assigment
and timing) are changed, the modification shall take effect after the NMTResetConfigurationcommand is received.
(NMT_GT8) NMTSwReset [ ] / start basic node initialisation
If an NMTSwReset command is received in NMT_GS_COMMUNICATING,
NMT_GS_INITIALISATION sub-state NMT_GS_INITIALISING shall be entered.
NMT_GT1, NMT_GT2 and NMT_GT8 are equivalent transitions, triggered by different reset
sources.
(NMT_GT10) Auto [basic node initialisation completed] / start application initialisation
NMT_GS_INITIALISATION sub-state NMT_GS_INITIALISING completed,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_APPLICATION shall be enteredautonomously.
(NMT_GT11) Auto [application initialisation completed] / start communication initialisation
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_APPLICATION completed,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_COMMUNICATION shall be enteredautonomously.
Auto [communication initialisation completed] / start configuration setup(NMT_GT12) NMT_GS_INITIALISATION sub-state NMT_GS_RESET_COMMUNICATION completed,
NMT_GS_INITIALISATION sub-state NMT_GS_RESET_CONFIGURATION shall be enteredautonomously.
(NMT_MT1) Auto [configuration setup completed, Node ID = C_ADR_MN_DEF_NODE_ID ] / start observing
network traffic
If NMT_GS_INITIALISATION sub-state NMT_GS_RESET_CONFIGURATION is completed andNode ID configuration is equal to the default MN address (C_ADR_MN_DEF_NODE_ID ), state
NMT_MS_NOT_ACTIVE shall be entered autonomously, e.g. the MN NMT state machine shall beentered.
(NMT_CT1) Auto [communication initialisation completed, Node ID not equal to C_ADR_MN_DEF_NODE_ID ] /start observing network traffic
If NMT_GS_INITIALISATION sub-state NMT_GS_RESET_CONFIGURATION is completed andNode ID configuration is not equal to the default MN address (C_ADR_MN_DEF_NODE_ID ), state
NMT_CS_NOT_ACTIVE shall be entered autonomously, e.g. the CN NMT state machine shall beentered.

Common initialisation NMT state transitionsEPSG DS 301 V1.5.1

-209-

7.1.3

MN NMT State Machine

7.1.3.1

Overview
NMT_GS_INITIALISATION

NMT_MSNMT MN State Machine(NMT_MT1)
auto[NodeID ==C_ADR_MN_DEF_NODE_ID](NMT_MT7)
Timout (SoC, SoA)[NMT_StartUp_U32.Bit13 == 1]

NMT_MS_
NOT_ACTIVE

NMT_MS_
BASIC_ETHERNET

NMT_MS_EPL_MODE(NMT_MT2)
Timeout (SoC, SoA)[NMT_StartUp_U32.Bit13 == 0]

NMT_MS_
PRE_OPERATIONAL_1(NMT_MT6)
Error Condition(NMT_MT3)
auto
NMT_MS_
PRE_OPERATIONAL_2(NMT_MT4)
auto
NMT_MS_READY_TO_OPERATE(NMT_MT5)
auto
NMT_MS_OPERATIONAL

Type of Communication
no Communication

Fig. 73.

Listen Only

Legacy Ethernet(IP and others)

POWERLINK
Reduced Cycle(SoA-ASnd)

POWERLINK Cycle(SoC-PReq-PResSoA-Asnd)

NMT state diagram of an MN

The MN NMT state machine shall be regarded to be hosted by the common initialisation NMT statemachine (7.1.2). The MN NMT state machine represents a sub-state of the super-states
NMT_GS_POWERED (7.1.2.1.1) and NMT_GS_COMMUNICATING (7.1.2.1.1.2). The transitions
defined by these states shall be valid at the MN NMT state machine.

7.1.3.2

States

The current state of the MN shall define the current state of the POWERLINK network.

7.1.3.2.1

NMT_MS_NOT_ACTIVE

The MN shall observe network traffic in NMT_MS_NOT_ACTIVE in order to ensure, that there is noother MN active on the network.
Reception of a SoC or a SoA frame indicates that there is another MN active. On SoC or SoA, thenode shall freeze boot-up. An error shall be signalled to the MN application and the current MN stateshall be maintained.

EPSG DS 301 V1.5.1-210-

The node shall be not authorised to send any frame in NMT_MS_NOT_ACTIVE.
Depending on NMT_StartUp_U32.Bit13 the transition to NMT_MS_PRE_OPERATIONAL_1(NMT_MT2) or NMT_MS_BASIC_ETHERNET (NMT_MT7) shall be triggered, if there are no SoA or
SoC frames received inside the time interval defined by index
NMT_BootTime_REC.MNWaitNoAct_U32.
A node that does not support MN mode shall stay in state NMT_MS_NOT_ACTIVE. An error message
E_NMT_BA1_NO_MN_SUPPORT shall be issued to the application.

7.1.3.2.2

NMT_MS_EPL_MODE

NMT_MS_EPL_MODE is a super-state that is not signalled over the network by an individual NMT
state value.

7.1.3.2.2.1

NMT_MS_PRE_OPERATIONAL_1

In the state NMT_MS_PRE_OPERATIONAL_1, the MN shall start executing the reduced
POWERLINK cycle.
Communication in NMT_MS_PRE_OPERATIONAL_1 shall be robust to collisions. Collisions shall be
resolved by CSMA/CD.
After entering NMT_MS_PRE_OPERATIONAL_1, the MN shall transmit a sequence of
C_DLL_PREOP1_START_CYCLES SoA frames, not assigning the asynchrous slot to any node
including the MN. This start sequence allows collisions pending from pre-NMT_MS_EPL_MODE
phase to be resolved.
It shall identify the configured nodes (index NMT_NodeAssignment_AU32[Node ID].Bit1) and may
check their identification. Identification check completion may be delayed if application SW or
configuration data have to be downloaded by the node.
Identified nodes shall be cyclically accessed via StatusRequest.
There is no PDO exchange in NMT_MS_PRE_OPERATIONAL_1.
The transition from NMT_MS_PRE_OPERATIONAL_1 to NMT_MS_PRE_OPERATIONAL_2(NMT_MT3) may be triggered if all mandatory CNs have been successfully identified.
It’s recommended, that the MN has completed it’s configuration in NMT_MS_PRE_OPERATIONAL_1.
Refer 7.4.1.3 for further information about NMT_MS_PRE_OPERATIONAL_1.

7.1.3.2.2.2

NMT_MS_PRE_OPERATIONAL_2

In the state NMT_MS_PRE_OPERATIONAL_2, the MN shall start executing the isochronous
POWERLINK cycle.
It shall start polling the identified CNs, that are in state NMT_CS_PRE_OPERATIONAL_2 and that are
not marked as AsyncOnly CNs, by Preq frames in order to start PDO transfer, synchronisation andheartbeat. The transmitted Preq frames may differ to the PDO mapping requirements. The data shallbe declared invalid by not setting the RD flag.
The received Pres frames from the polled CNs shall be ignored.
Identified async-only CNs (index NMT_NodeAssignment_AU32[Node ID].Bit8) shall be cyclicallyaccessed via StatusRequest.
Configured but unidentified CNs shall be searched for via SoA IdentRequest frames.
The MN state transition from NMT_MS_PRE_OPERATIONAL_2 to
NMT_MS_READY_TO_OPERATE (NMT_MT4) shall be triggered when all mandatory CNs havesignalled to be in state NMT_CS_READY_TO_OPERATE and the MN has completed its
configuration.
Refer 7.4.1.4 for further information about NMT_MS_PRE_OPERATIONAL_2.

7.1.3.2.2.3

NMT_MS_READY_TO_OPERATEIn NMT_MS_READY_TO_OPERATE, the MN shall execute the isochronous POWERLINK cycle.
When entering NMT_MS_READY_TO_OPERATE, the MN shall start transmitting PDO data to theidentified isochronous CNs according to the requirements of the PDO mapping. The transmitted data
shall be declared invalid by resetting the RD flag. The length of the Preq frames shall be equal to theconfigured Preq payload size of the respective CN (index NMT_MNPReqPayloadLimitList_AU16[NodeID]).

EPSG DS 301 V1.5.1-211-

PDO data received from the CNs shall be ignored.
Identified async-only CNs shall be cyclically accessed via SoA StatusRequest frames.
Configured but unidentified CNs shall be searched via SoA IdentRequest frames.
The MN state transition from NMT_MS_READY_TO_OPERATE to NMT_MS_OPERATIONAL(NMT_MT5) shall be triggered if all mandatory CNs transmit their Pres frames with correct frame
length and timing.
Refer 7.4.1.5 for further information about NMT_MS_READY_TO_OPERATE.

7.1.3.2.2.4

NMT_MS_OPERATIONAL

NMT_MS_OPERATIONAL is the normal operating state of the POWERLINK MN. The MN shall
execute the isochronous POWERLINK cycle.
The MN shall transmit PDO data to the identified isochronous CNs according to the requirements of
the PDO mapping. The transmitted data may be declared valid by setting the RD flag, if requested by
the application. The length of the Preq frames shall be equal to the configured Preq payload size ofthe respective CN.
The MN may transmit NMTStartNode commands to force CNs state transition from
NMT_CS_READY_TO_OPERATE to NMT_CS_OPERATIONAL. The NMTStartNode transmission iscontrolled by index NMT_StartUp_U32.Bits1 and NMT_StartUp_U32.Bit3.
Identified Async-only CNs shall be cyclically accessed via SoA StatusRequest frames.
Configured but unidentified CNs shall be searched for via SoA IdentRequest frames.
All mandatory CNs shall be in NMT_CS_OPERATIONAL and free of POWERLINK protocol relevant
errors. If a mandatory CN is lost, if it has a state not equal to NMT_CS_OPERATIONAL or if it has
signalled an error, the MN shall change over to NMT_MS_PRE_OPERATIONAL_1 (NMT_MT6).
The error reaction of the MN is controlled by index NMT_StartUp_U32.Bit4 and
NMT_StartUp_U32.Bit6.
Refer 7.4.1.6 for further information about NMT_MS_OPERATIONAL.

7.1.3.2.3

NMT_MS_BASIC_ETHERNETIn NMT_MS_BASIC_ETHERNET the MN may perform Legacy Ethernet communication according toIEEE 802.3. There is no POWERLINK specific network traffic control. The CSMA/CD collision
handling shall control the network access. The node is allowed to transmit autonomously.
Any Legacy Ethernet protocol may be applied. Asnd frames may be transmitted by the MN in state
NMT_MS_BASIC_ETHERNET.
To leave NMT_MS_BASIC_ETHERNET, NMT_MS_EPL_MODE has to be enabled by setting
NMT_StartUp_U32.Bit13 to 0b and the device has to be reset by NMTResetCommunication or anotherreset command.
Support of NMT_MS_BASIC_ETHERNET is optional. Support shall be indicated by
D_NMT_MNBasicEthernet_BOOL.

EPSG DS 301 V1.5.1

7.1.3.3(NMT_MT1)(NMT_MT2)(NMT_MT3)(NMT_MT4)(NMT_MT5)(NMT_MT6)(NMT_MT7)22-212-

Transitions
Refer Tab. 105
Timeout (SoC, SoA) [NMT_StartUp_U32.Bit13 = 0b] / enable POWERLINK reduced cycle
communication
If NMT_MS_EPL_MODE is enabled by NMT_StartUp_U32.Bit13 = 0b and the node does notreceive any SoA or SoC frame during a definable timeout interval after entering the
NMT_MS_NOT_ACTIVE state, the node shall change over to NMT_MS_PRE_OPERATIONAL_1.
Timeout defined by NMT_BootTime_REC.MNWaitNoAct_U32
Auto [All mandatory CNs identified] / enable isochronous POWERLINK cycle communication,
invalid PDO, dummy Preq allowed
If the node has identified all mandatory CNs, the node shall change to
NMT_MS_PRE_OPERATIONAL_2.
The state transition may be delayed by the application.
Auto [MN configuration completed, all mandatory CNs in NMT_CS_READY_TO_OPERATE] /invalid PDO, configured Preq, PresIf the MN has completed its configuration and if all mandatory CNs are in state
NMT_CS_READY_TO_OPERATE, the node shall change to the state
NMT_MS_READY_TO_OPERATE.
The state transition may be delayed by the application.
Auto [The isochronous communication is error free ] / enable configured Preq and Pres, start
operation
If all mandatory CNs transmit their Pres frames with correct frame length and timing, the MN shallchange to the state NMT_MS_OPERATIONAL.
The state transition may be delayed by the application
Auto [Mandatory CN lost, mandatory CN not in NMT_CS_OPERATIONAL, error] / enable
POWERLINK reduced cycle communication
If the MN detects errors of a mandatory CN, it shall change over to
NMT_MS_PRE_OPERATIONAL_1
Timeout (SoC, SoA) [NMT_StartUp_U32.Bit13 = 1b] / enable Legacy Ethernet communication
If NMT_StartUp_U32.Bit13 is set, the MN shall change over to NMT_MS_BASIC_ETHERNET

MN specific state transitions
Refer Fig. 72 and Tab. 105 for state transitions defined by the common Initialisation NMT state, whichhave to be applied to the MN NMT state machine.

22 optional transition (cf. 7.1.3.2.3)

EPSG DS 301 V1.5.1

7.1.4

-213-

CN NMT State Machine

The CN NMT state machine shall be regarded to be hosted by the common initialisation NMT statemachine (7.1.2). The CN NMT state machine represents a sub-state of the super-states
NMT_GS_POWERED (7.1.2.1.1) and NMT_GS_COMMUNICATING (7.1.2.1.1.2). The transitions
defined by these states shall be valid at the CN NMT state machine.
NMT_GS_INITIALISATIONNMT_CSNMT CN State Machine(NMT_CT3)
Timeout(SoA,SoC,PReq,PRes)

NMT_CS_
BASIC_ETHERNET(NMT_CT1)
auto,[NodeID !=C_ADR_MN_DEF_NODE_ID]

NMT_CS_
NOT_ACTIVE(NMT_CT12)
SoA,SoC,PReq,PRes(NMT_CT2)
SoA,SoC

NMT_CS_EPL_MODE
NMT_CS_
PRE_OPERATIONAL_1(NMT_CT5)
NMT
EnableReadyToOperate(NMT_CT11)
Error Condition(NMT_CT4)SoC

NMT_CS_
PRE_OPERATIONAL_2(NMT_CT10)NMTEnterPreoperational2(NMT_CT6)
auto

NMT_CS_READY_TO_OPERATE(NMT_CT7)
NMT
StartNode(NMT_CT9)NMTEnterPreoperational2

NMT_CS_OPERATIONAL(NMT_CT8)NMT
StopNode

NMT_CS_STOPPED

Type of Communication
no Communication

Listen Only

Legacy Ethernet(IP and others)

Fig. 74.

State diagram of a CN

7.1.4.1

States

7.1.4.1.1

NMT_CS_NOT_ACTIVE

POWERLINK
Reduced Cycle(SoA-Asnd)

POWERLINK Cycle(SoC-PReq-PRes-SoAAsnd)

NMT_CS_NOT_ACTIVE is a non-permanent state which allows a starting node to recognize thecurrent network state.
The CN shall observe network traffic. The node shall be not authorised to send frames autonomously.
There shall be no Legacy Ethernet frame transmission allowed at NMT_CS_NOT_ACTIVE. The node
shall be able to recognize NMTReset commands sent via Asnd.
The transition from NMT_CS_NOT_ACTIVE to NMT_CS_PRE_OPERATIONAL_1 shall be triggeredby a SoA or SoC frame being received.

EPSG DS 301 V1.5.1-214-

The transition from NMT_CS_NOT_ACTIVE to NMT_CS_BASIC_ETHERNET shall be triggered bytimeout for SoC, Preq, Pres and SoA frames.

7.1.4.1.2

NMT_CS_EPL_MODE

NMT_CS_EPL_MODE is a super-state that won’t be signalled over the network by an individual NMT
state value.

7.1.4.1.2.1

NMT_CS_PRE_OPERATIONAL_1

In the state NMT_CS_PRE_OPERATIONAL_1, the CN shall send a frame only if the MN has
authorised it to do so by a SoA AsyncInvite command.
In NMT_CS_PRE_OPERATIONAL_1 the node shall be identified by the MN via IdentRequest (see7.3.3.2). If required the CN shall download its configuration data from a configuration server. Bothprocesses may be completely or partially shifted to NMT_CS_PRE_OPERATIONAL_2, if the MN is
not in NMT_MS_PRE_OPERATIONAL_1 resp. leaves NMT_MS_PRE_OPERATIONAL_1 before theCN has completed its configuration.
Communication in NMT_CS_PRE_OPERATIONAL_1 shall be robust to collisions. Collisions shall be
resolved by CSMA/CD.
The transition from NMT_CS_PRE_OPERATIONAL_1 to the following state shall be triggered by a
SoC frame being received (see Fig. 74).
There is no PDO communication in NMT_CS_PRE_OPERATIONAL_1.

7.1.4.1.2.2

NMT_CS_PRE_OPERATIONAL_2

In the state NMT_CS_PRE_OPERATIONAL_2, the CN shall wait for the configuration to becompleted.
The node is queried by the MN via Preq. The received PDO data may be invalid, they may differ to the
PDO mapping requirements.
The PDO data received from the MN via Preq and from other CNs and the MN via Pres shall beignored by the CN.
The transmitted Pres frames may differ to the PDO mapping requirements. The data shall be declaredinvalid by not setting the RD flag.
Async-only CNs shall not be queried by the MN via Preq and thus shall not respond via Pres.
Both types of CN shall respond to AsyncInvite commands via SoA. If not invited by the MN, there shallbe no Ethernet frame transmission allowed at the NMT_CS_PRE_OPERATIONAL_2 state.
Precondition for the transition from NMT_CS_PRE_OPERATIONAL_2 to
NMT_CS_READY_TO_OPERATE shall be the reception of an NMTEnableReadyToOperatecommand. The transition shall be triggered if the application is ready for operation. The maximum
transition time from reception of NMTEnableReadyToOperate until the CN is in
NMT_CS_READY_TO_OPERATE may be given by D_NMT_CNPreOp2ToReady2Op_U32.
The transition from NMT_CS_PRE_OPERATIONAL_2 to NMT_CS_PRE_OPERATIONAL_1 shall be
triggered by an error recognition (see 4.7.7).
The transition from NMT_CS_PRE_OPERATIONAL_2 to NMT_CS_STOPPED shall be triggered byreception of NMT state command NMTStopNode (see 7.3.1.2.1).

7.1.4.1.2.3

NMT_CS_READY_TO_OPERATE

With the state NMT_CS_READY_TO_OPERATE, the CN shall signal its readiness to operation to the
MN.
The node may participate in cyclic frame exchange. Cyclic nodes shall respond via Pres when queried
via Preq by the MN.
Async-only CNs shall not be queried by the MN via Preq and thus shall not respond via Pres.
Both types of CN shall respond to AsyncInvite commands via SoA. If not invited by the MN, there shallbe no Ethernet frame transmission allowed at the NMT_CS_READY_TO_OPERATE state.
The RD flag shall be set to 0, regardless if valid process data is available.
The length of the Pres payload shall be less or equal to the configured limit (Object
NMT_CycleTiming_REC.PresActPayloadLimit_U16). The transmitted data shall correspond to therequirements defined by the PDO mapping (see 6.4.4).

EPSG DS 301 V1.5.1-215-

The transition from NMT_CS_READY_TO_OPERATE to NMT_CS_OPERATIONAL shall be triggeredby the reception of NMT state command NMTStartNode (see 7.3.1.2.1)
The transition from NMT_CS_READY_TO_OPERATE to NMT_CS_PRE_OPERATIONAL_1 shall be
triggered by an error recognition (see 4.7.7).
The transition from NMT_CS_READY_TO_OPERATE to NMT_CS_STOPPED shall be triggered byreception of NMT state command NMTStopNode (see 7.3.1.2.1).

7.1.4.1.2.4

NMT_CS_OPERATIONAL

NMT_CS_OPERATIONAL is the normal operating state of a CN.
The CN may participate in cyclic frame exchange. A cyclic CN shall respond via Pres when queried
via Preq by the MN.
An Async-only CN isn’t queried by the MN via Preq and thus does not respond via Pres.
Both types of CN shall respond to AsyncInvite commands via SoA. If not invited by the MN, there is no
Ethernet frame transmission allowed at the NMT_CS_OPERATIONAL state.
The CN may perform surveillance of other nodes using the NMT guarding mechanism (7.3.5).
The PDO data received from the MN via Preq and from other CNs and the MN via Pres shall beinterpreted if selected by the CN application.
The RD flag is controlled by the application. Temporary clearing the RD flag is allowed if PDO data are
not valid. The length of the Pres payload shall be less or equal to the configured limit (Object
NMT_CycleTiming_REC.PresActPayloadLimit_U16). The transmitted data shall correspond to therequirements defined by the PDO mapping (see 6.4.4).
The transition from NMT_CS_OPERATIONAL to NMT_CS_PRE_OPERATIONAL_2 shall be triggeredby the reception of NMT state command NMTEnterPreOperational2 (see 7.3.1.2.1).
The transition from NMT_CS_OPERATIONAL to NMT_CS_PRE_OPERATIONAL_1 shall be triggeredby an error recognition(see 4.7.7).
The transition from NMT_CS_OPERATIONAL to NMT_CS_STOPPED shall be triggered by receptionof NMT state command NMTStopNode (see 7.3.1.2.1).

7.1.4.1.2.5

NMT_CS_STOPPEDIn the NMT_CS_STOPPED state, the node shall be largely passive. NMT_CS_STOPPED shall be
used for controlled shutdown of a selected CN while the system is still running.
The node shall not participate in cyclic frame exchange, but still observes SoA frames.
It shall not be queried by the MN via Preq.
The node shall not respond via Pres when queried by the MN via Preq.
The node shall respond to AsyncInvite commands via SoA. If not invited by the MN, there is no
Ethernet frame transmission allowed at the NMT_CS_STOPPED state.
The transition from NMT_CS_STOPPED to NMT_CS_PRE_OPERATIONAL_2 shall be triggered by
the reception of NMT state command NMTEnterPreOperational2 (see 7.3.1.2.1)
The transition from NMT_CS_STOPPED to NMT_CS_PRE_OPERATIONAL_1 shall be triggered byan error recognition (see 4.7.7).

7.1.4.1.3

NMT_CS_BASIC_ETHERNET

In the NMT_CS_BASIC_ETHERNET state the node may perform Legacy Ethernet communicationaccording to IEEE 802.3. There is no POWERLINK specific network traffic control. The CSMA/CD
collision handling shall control the network access. The node is allowed to transmit autonomiously.
Any Legacy Ethernet protocol may be applied.
Asnd frames may be transmitted by a CN in state NMT_CS_BASIC_ETHERNET.
To avoid disturbance of POWERLINK network traffic when the node is in
NMT_CS_BASIC_ETHERNET , the node shall recognize SoC, Preq, Pres and SoA frames. On thereception of such a frame, the CN shall immediately stall any autonomous frame transmission andchange over to. NMT_CS_PRE_OPERATIONAL_1.

EPSG DS 301 V1.5.1

7.1.4.2-216-

Transitions(NMT_CT1)(NMT_CT2)

Refer Tab. 105
SoA, SoC [ ] / enable POWERLINK reduced cycle communication(NMT_CT3)

If a SoA or SoC frame is received in NMT_CS_NOT_ACTIVE, the node shall change over to thestate NMT_CS_PRE_OPERATIONAL_1.
Timeout (SoC, Preq, Pres and SoA) [ ] / enable Legacy Ethernet communication(NMT_CT4)

If the node does not receive any SoC, Preq, Pres or SoA frame during a definable timeout interval
after entering the NMT_CS_NOT_ACTIVE state, the node shall change over to
NMT_CS_BASIC_ETHERNET.
The timeout interval shall be defined by Object NMT_CNBasicEthernetTimeout_U32.
SoC [ ] / enable POWERLINK cycle communication, not valid, dummy Pres allowed(NMT_CT5)

If the node receives a SoC frame in NMT_CS_PRE_OPERATIONAL_1, the node shall changeover to NMT_CS_PRE_OPERATIONAL_2.
NMTEnableReadyToOperate [] / enable transition to NMT_CS_READY_TO_OPERATE(NMT_CT6)The CN is free to change over to NMT_CS_READY_TO_OPERATE after configuration andsynchronisation is completed
Auto [application is ready and NMTEnableReadyToOperate was received] / enable configured
Pres, not valid
The CN shall automatically change over to NMT_CS_READY_TO_OPERATE(NMT_CT7)

NMTStartNode [configuration valid] / enable configured Pres, start operation(NMT_CT8)

If the CN receives the NMTStartNode command in NMT_CS_READY_TO_OPERATE, it shallchange over to NMT_CS_OPERATIONAL
NMTStopNode [ ] / freeze cyclic communication(NMT_CT9)

If the node receives an NMTStopNode command in NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE or NMT_CS_OPERATIONAL, it shall change over to
NMT_CS_STOPPED.
NMTEnterPreoperational2 [ ] / reset RD flag in Pres, dummy Pres only

(NMT_CT10)

If the node receives the NMTEnterPreoperational2 command in NMT_CS_OPERATIONAL, it
shall change over to NMT_CS_PRE_OPERATIONAL_2
NMTEnterPreoperational2 [ ] / re-enable POWERLINK cycle communication, dummy Pres only

(NMT_CT11)

If the node receives the NMTEnterPreoperational2 command in NMT_CS_STOPPED, it shallchange over to NMT_CS_PRE_OPERATIONAL_2.
Error condition [ ] / enable POWERLINK reduced cycle communication
If the node recognizes an error condition (refer 4.7.7) in NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, NMT_CS_OPERATIONAL or NMT_CS_STOPPED, the node
shall change over to NMT_CS_PRE_OPERATIONAL_1(NMT_CT12)

SoC, Preq, Pres or SoA [ ] / stall autonomous frame transmission
If a SoC, Preq, Pres or SoA frame is received in NMT_CS_BASIC_ETHERNET, the node shallchange over to NMT_CS_PRE_OPERATIONAL_1.
It’s extremely important that the node immediately stops any autonomous frametransmission, when it recognizes a SoC, Preq, Pres or SoA frame.

CN specific state transitions
Refer Fig. 72 and Tab. 105 for state transitions defined by the common Initialisation NMT state, thathave to applied to the CN NMT state machine.

7.1.4.3

States and Communication Object Relation

Tab. 108 shows the relation between communication states and communication objects. Services on
the listed communication objects may only be executed if the devices involved in the communication
are in the appropriate communication states.

EPSG DS 301 V1.5.1

POWERLINK controlled network traffic
SoC
R/S
R/S
R
R
Preq
R
R
PDO reception(x)1
Pres receive
R
Pres transmit(T)T
PDO transmission
(x)2
SoA
R/S
R
R
R
IdentRequestxxx
StatusRequestxxx
NMTRequestInvitexxx
UnspecifiedInvitex
x
x
Reception of asynchronous frames
R
R
R
R
SDO receptionx
x
x
NMT Command
(x)3
(x)4
(x)4
(x)4
other protocolsxxx
Transmission, assigned by SoA
T
TT
SDO transmissionx
x
x
NMTRequest transmissionxx
x
IdentResponsexxx
StatusResponsexxxother protocolsxxx
Network traffic not controlled by POWERLINK
Legacy Ethernet reception
UDP/IP reception
SDO reception (UDP/IP)
POWERLINK-Asnd reception
SDO reception (POWERLINK-Asnd)
Legacy Ethernet transmission
UDP/IP, autonomiously sent
SDO transmission (UDP/IP)
POWERLINK-Asnd, autonomiously sent
SDO transmission (POWERLINK-Asnd)R
frame accepted
R/S
frame accepted, triggers state transitionTframe transmitted(T)dummy Pres onlyxframe data interpreted resp. transmitted(x)1frame data may be interpreted(x)2
data invalidated by resetting the RD flag(x)3
only selected NMT commands accepted, shall cause state transition, refer 7.3.1.2.1(x)4
may cause state transition, refer 7.3.1.2.1(x)5
depends on protocol support
no frame handling

NMT_CS_BASIC_ETHERNETNMT_CS_STOPPEDNMT_CS_OPERATIONAL

NMT_CS_READY_TO_OPERATENMT_CS_PRE_OPERATIONAL_2

NMT_CS_PRE_OPERATIONAL_1

NMT_CS_NOT_ACTIVE

NMT_GS_INITIALISATION

-217-

R
R
x
R
T
x
R
x
x
x
x
R
x
(x)4
x
T
x
x
x
x
x

R
x
x
x
x
R
x
(x)4
x
T
x
x
x
x
x

R/S
R/S
R/S
R/S
R
(x)3
-

-

-

R
(x)5
(x)5
(x)5
(x)5
T
(x)5
(x)5
(x)5
(x)5

States and communication objects

7.1.4.4

Relationship to other state machines

The CN NMT state machine is commanded by the MN NMT state machine via NMT commands.
The NMT state machines are operating in close relationship to the cycle state machines (refer 4.2.4.5
resp. 4.2.4.6).

EPSG DS 301 V1.5.1

7.2

-218-

NMT Object Dictionary Entries

NMT Object Dictionary hosts entries defining node internal parameters that control the isochronous
POWERLINK cycle. These internal parameters shall not be changed when the isochronous
POWERLINK cycle is in operation.
Modifications of the respective OD entries shall be restricted to the OD data handling but shall not
immediately influence the internal parameter set controlling the current POWERLINK cycle. To make
POWERLINK cycle relevant OD entries valid, the device shall be set to
NMT_GS_RESET_CONFIGURATION by NMTResetConfiguration, a more powerful NMT reset
command or a HW reset.
OD entries that require a such type handling are indicated by the access type supplement “valid on
reset”.

7.2.1

NMT General Objects

Most of the objects decribed by this paragraph apply to all nodes.
Some sub-indices of objects otherwise mandatory to the MN may not be implemented on the MN.
Refer to the Category entry to identify unsupported items on the MN (Category = No).

7.2.1.1

Identification

7.2.1.1.1

Object 1000h: NMT_DeviceType_U32

Contains information about the device type. The object describes the type of device and its
functionality.
The value shall be setup by the device firmware during system initialisation.
Index
Name
Data Type
Value Range
Default Value•

1000h
NMT_DeviceType_U32
UNSIGNED32
UNSIGNED32-

Object Type

VAR

Category
AccessPDO Mapping

M
const
No

Value Interpretation
Byte:

MSB

Additional Information

LSB

Device Profile Number

NMT_DeviceType_U32 value interpretation
NMT_DeviceType_U32 is composed of a 16-bit field which describes the device profile that isused and a second 16-bit field which gives additional information about optional functionality ofthe device.
The Additional Information parameter is device profile specific. Its specification does not fallwithin the scope of this document, it is defined in the appropriate device profile. The value 0000 h
indicates a device that does not follow a standardised device profile.
For multiple device modules the Additional Information parameter contains FFFF h and thedevice profile number referenced by object 1000h is the device profile of the first device in the
Object Dictionary. All other devices of a multiple device module identify their profiles at objects
67FFh + x * 800h with x = internal number of the device (0 – 7). These entries describe thedevice type of the preceding device.

7.2.1.1.2

Object 1008h: NMT_ManufactDevName_VS

Contains the manufacturer device name.
If implemented, it shall be setup by the device firmware during system initialisation.
Remark: In the device description file (see separate paper) the sub element “productName” of element“DeviceIdentity” must be equal to NMT_ManufactDevName_VS.

EPSG DS 301 V1.5.1
Index
Name
Data Type
Value Range
Default Value

7.2.1.1.3

-219-

1008h
NMT_ManufactDevName_VS
VISIBLE_STRING-

Object Type

VAR

Category
AccessPDO Mapping

O
const
No

Object 1009h: NMT_ManufactHwVers_VS

Contains the manufacturer hardware version description.
Remark: In the device description file (see separate paper) the sub element “version” (with attribute“versionType” set to “HW”) of element “DeviceIdentity” must be equal to NMT_ManufactHwVers_VS.
Index
Name
Data Type
Value Range
Default Value

7.2.1.1.4

1009h
NMT_ManufactHwVers_VS
VISIBLE_STRING-

Object Type

VAR

Category
AccessPDO Mapping

O
const
No

Object 100Ah: NMT_ManufactSwVers_VS

Contains the manufacturer software version description.
Remark: In the device description file (see separate paper) the sub element “version” (with attribute“versionType” set to “FW”) of element “DeviceIdentity” must be equal to NMT_ManufactSwVers_VS.
Index
Name
Data Type
Value Range
Default Value

7.2.1.1.5

100Ah
NMT_ManufactSwVers_VS
VISIBLE_STRING-

Object Type

VAR

Category
AccessPDO Mapping

O
const
No

Object 1018h: NMT_IdentityObject_REC

The object at index 1018h contains general information about the device.
The values shall be setup by the device firmware during system initialisation.
Index
Name
Data Type•

Object TypeRECORD

CategoryM

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1018h
NMT_IdentityObject_REC
IDENTITY

00h
NumberOfEntries
1 .. 4-Sub-Index 01h: VendorId_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
VendorId_U32
UNSIGNED32
UNSIGNED32-

The sub-index provides the manufacturer-specific vendor ID.
The POWERLINK vendor ID is equal to the CANopen vendor ID.
Note: A CANopen vendor ID can be obtained from CAN in Automation (CiA).

EPSG DS 301 V1.5.1
•

-220-

Sub-Index 02h: ProductCode_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ProductCode_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
const
No

The manufacturer-specific Product code identifies a specific device version. The value shall beequal to the device description entry D_NMT_ProductCode_U32.
•

Sub-Index 03h: RevisionNo_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
RevisionNo_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
const
No

The manufacturer-specific revision number consists of a major revision number and a minor
revision number. The major revision number identifies a specific device behaviour. If the device
functionality is expanded, the major revision has to be incremented. The minor revision number
identifies different versions with the same device behaviour. The value shall be equal to thedevice description entry D_NMT_RevisionNo_U32.
31

16major revision number

15

0minor revision number

MSB

LSB

Structure of Revision number•

Sub-Index 04h: SerialNo_U32
Sub-Index
Name
Data Type
Value Range
Default Value

04h
SerialNo_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
const
No

The sub-index provides the Serial Number of the device.

7.2.1.1.6

Object 1F82h: NMT_FeatureFlags_U32

Feature Flags indicate communication profile specific properties of the device given by it’s design.
The object shall be setup by the device firmware during system initialisation.
Index
Name
Data Type
Value Range
Default Value

1F82h
NMT_FeatureFlags_U32
UNSIGNED32-

Object Type

VAR

Category
AccessPDO Mapping

M
const
No

EPSG DS 301 V1.5.1

•

-221-

Value Interpretation
Octet Bit
00Name
Isochronous

TRUE
FALSE
device may be
device does not support
isochronously accessed via isochronous access via
PReq, it may be operated
PReq, it may be exclusively
as isochronous CN
used as async-only CN(see 4.2.2.2.1)(see 4.2.2.2.2)
D_NMT_Isochronous_BOOL

1

SDO by UDP/IP

2

SDO by Asnd

3

SDO by PDO

4

NMT Info Services

device supports
device does not support
SDO communication via UDP/IP frames (see 6.3.3.1)
D_SDO_SupportUdpIp_BOOL
device supports
device does not support
SDO communication via POWERLINK ASnd frames (see6.3.3.1)
D_SDO_SupportASnd_BOOL
device supports
device does not support
SDO communication via container embedded in PDO
communication (see 6.3.3.1)
D_SDO_SupportPDO_BOOL
device supports
device does not support
NMT Info Services (see 7.3.4)

5

Extended NMT State
Commands

6

Dynamic PDO Mapping

7

NMT Services by UDP/IP

8

Configuration Manager

9Multiplexed Access

10

Node ID setup by SW

11

MN Basic Ethernet Mode

12

Routing Type 1 Support

13

Routing Type 2 Support

14

SDO Read/Write All by
Index

15

SDO Read/Write Multiple
Parameter by Index

Note: Device description entries are defined for each service.

1

device supports
device does not support
reception of Extended NMT State Commands (see7.3.1.2.2) D_NMT_ExtNmtCmds_BOOL
device supports
device does not support
dynamic PDO mapping (see 6.4.2)
D_PDO_DynamicMapping_BOOL
device supports
device does not support
NMT Services by UDP/IP (see 7.3.8)
D_NMT_ServiceUdpIp_BOOL
device supports
device does not support
Configuration manager functions (see 6.7)
D_CFM_ConfigManager_BOOL
CN device supports
CN device does not support
Multiplexed isochronous access (see 4.2.4.1.1.1)
D_DLL_CNFeatureMultiplex_BOOL
device supports
device does not support
Node ID setup by SW (see 7.2.1.3.1)
D_NMT_NodeIDBySW_BOOL
MN device supports
MN device does not support
Basic Ethernet Mode (see 7.1.3.2.3)
D_NMT_MNBasicEthernet_BOOL
device supports
device does not support
Routing Type 1 functions (see 9.1)
D_RT1_RT1Support_BOOL
device supports
device does not support
Routing Type 2 functions (see 9.2)
D_RT2_RT2Support_BOOL
device supports
device does not support
SDO commands Read and Write All by Index (see6.3.2.4.2)
D_SDO_CmdReadAllByIndex_BOOL,
D_SDO_CmdWriteAllByIndex_BOOL
device supports
device does not support
SDO commands Read and Write Multiple Parameter byIndex (see 6.3.2.4.2)
D_SDO_CmdReadMultParam_BOOL,EPSG DS 301 V1.5.1-222-

Octet Bit

Name

TRUE
FALSE
D_SDO_CmdWriteMultParam_BOOL

2

reserved
reserved
reserved
reserved
reserved
reserved
reserved

Used by EPSG DS302-B [2]----reserved

--

--

16
17
18
19
20
21
22 ..
23
24 ..
31

3

Used by EPSG DS302-A [1]
Used by EPSG DS302-C [3]
Used by EPSG DS302-D [4]Used by EPSG DS302-E [5]Used by EPSG DS302-F [6]

NMT_FeatureFlags_U32 interpretation

7.2.1.1.7

Object 1F83h: NMT_EPLVersion_U8

The index holds the POWERLINK communication profile version that is implemented by device.
The value shall be setup by the device firmware during system initialisation.
Index
Name
Data Type
Value Range
Default Value•

1F83h
NMT_EPLVersion_U8
UNSIGNED8-

Object Type

VAR

Category
AccessPDO Mapping

M
const
No

Value Interpretation
High Nibble

Low Nibble

POWERLINK Main
Version

POWERLINK Sub
Version

NMT_EPLVersion_U8 encoding

7.2.1.2

Parameter Storage

7.2.1.2.1

Object 1010h: NMT_StoreParam_REC

This object supports the saving of parameters in non volatile memory. By read access the device
provides information about its saving capabilities.
Index
Name
Data Type•

1010h
NMT_StoreParam_REC
NMT_ParameterStorage_TYPE

Object TypeRECORD

CategoryO

AccessPDO Mapping

const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
01h .. 7Fh-

NumberOfEntries is implemetation specific.

EPSG DS 301 V1.5.1
•

-223-

Sub-Index 01h: AllParam_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
AllParam_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

M
rw
No

Category
AccessPDO Mapping

O
rw
No

Refers to all parameters that can be stored on the device.
•

Sub-Index 02h: CommunicationParam_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
CommunicationParam_U32
UNSIGNED32
UNSIGNED32-

Refers to communication related parameters (Index 1000h .. 1FFFh: manufacturer specificcommunication parameters).
•

Sub-Index 03h: ApplicationParam_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
ApplicationParam_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
rw
No

Refers to application related parameters (Index 6000h .. 9FFFh: manufacturer specificapplication parameters).
•

Sub-Index 04h .. 7Fh: ManufacturerParam_XXh_U32
Sub-Index
Name
Data Type
Value Range
Default Value

04h .. 7Fh
ManufacturerParam_XXh_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

O
rw
No

ManufacturerParam_XXh_U32 provide means to store manufacturer specific lists of data.
To allow access by name “_XXh” is replaced with a name index. For example, the name index
is “_04h” if the sub-index is 04h. The name index is incremented up to “_7Fh” corresponding to
sub-index 7Fh.
•

Value Interpretation of Sub-Index 01h .. 7Fh
In order to avoid storage of parameters by mistake, storage is only executed when a specificsignature is written to the appropriate sub-index. The signature is „save“.
Signature

MSB

ISO 8859 (“ASCII”)
hex

e
65h

LSB

v
76h

a
61h

s
73h

NMT_StoreParam_REC storage write access signature
On reception of the correct signature in the appropriate sub-index the device stores theparameter and then confirms the SDO transmission. If the storing fails, the device responds with
an Abort SDO Transfer.
If a wrong signature is written, the device refuses to store it and responds with Abort SDO
Transfer.

EPSG DS 301 V1.5.1-224-

On read access to the appropriate sub-index the device provides information about its storage
functionality with the following format:

bits

UNSIGNED32MSB
31 .. 2
reserved (=0)

1
0/1

LSB
0
0/1

NMT_StoreParam_REC storage read access structure
bit

value

meaning

31 .. 2
1

0
0
1
0
1

Reserved (=0b)
Device does not save parameters autonomously
Device saves parameters autonomously
Device does not save parameters on command
Device saves parameters on command0

NMT_StoreParam_REC structure of read access
Autonomous saving means that a device stores the storable parameters in a non-volatile memory
without user request.

7.2.1.2.2

Object 1011h: NMT_RestoreDefParam_REC

With this object the default values of parameters according to the communication or device profile arerestored. By read access the device provides information about its capabilities to restore these values.
Several parameter groups are distinguished:
Index
Name
Data Type•

1011h
NMT_RestoreDefParam_REC
NMT_ParameterStorage_TYPE

Object TypeRECORD

CategoryO

AccessPDO Mapping

const
No

M
rw, cf. Validation
information
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
01h .. 7Fh-

NumberOfEntries is implemetation specific.
•

Sub-Index 01h: AllParam_U32
Sub-Index
Name
Data Type
Value Range

01h
AllParam_U32
UNSIGNED32
UNSIGNED32

Category
AccessDefault Value-PDO Mapping

Refers to all parameters that can be stored on the device.

EPSG DS 301 V1.5.1
•

-225-

Sub-Index 02h: CommunicationParam_U32
Sub-Index
Name
Data Type
Value Range

02hCommunicationParam_U32
UNSIGNED32
UNSIGNED32

Category
AccessDefault Value-PDO MappingO
rw, cf. Validation
information
No

Restore communication default parameters, refers to communication related parameters (Index
1000h .. 1FFFh: manufacturer specific communication parameters).
•

Sub-Index 03h: ApplicationParam_U32
Sub-Index
Name
Data Type
Value Range

03hApplicationParam_U32
UNSIGNED32
UNSIGNED32

Category
AccessDefault Value-PDO MappingO
rw, cf. Validation
information
No

Restore application default parameters, refers to application related parameters (Index 6000 h –9FFFh manufacturer specific application parameters).
•

Sub-Index 04h .. 7Fh: ManufacturerParam_XXh_U32
Sub-Index
Name
Data Type
Value Range

04h .. 7Fh
ManufacturerParam_XXh_U32
UNSIGNED32
UNSIGNED32

Category
AccessDefault Value-PDO MappingO
rw, cf. Validation
information
No

Restore manufacturer defined default parameters. Manufacturers may restore their individual
choice of parameters.
To allow access by name “_XXh” is replaced with a name index. For example, the name index
is “_04h” if the sub-index is 04h. The name index is incremented up to “_7Fh” corresponding to
sub-index 7Fh.
•

Sub-Index 01h – 7Fh Value Interpretation
In order to avoid the restoring of default parameters by mistake, restoring is only executed whena specific signature is written to the appropriate sub-index. The signature is „load“.
Signature

MSB

ISO 8859 (“ASCII”)
hex

d
64h

LSB

a
61h

o
6Fh

l
6Ch

NMT_RestoreDefParam_REC restoring write access signature
On reception of the correct signature in the appropriate sub-index the device restores thedefault parameters and then confirms the SDO transmission. If the restoring failed, the device
responds with an Abort SDO Transfer. If a wrong signature is written, the device refuses torestore the defaults and responds with an Abort SDO Transfer.
On read access to the appropriate sub-index the device provides information about its default
parameter restoring capability with the following format:

EPSG DS 301 V1.5.1-226-

UNSIGNED32MSB
31 .. 1reserved (=0)

bits

LSB
0
0/1

NMT_RestoreDefParam_REC restoring default values read access structure
bit number

valuemeaning

31 .. 10001reserved (=0)
Device does not restore default parameters
Device restores parameters

NMT_RestoreDefParam_REC structure of restore read access•

Validation Information
Following a restore-default-parameter SDO command the objects initially keep their current
values and are set to their default values after the device is reset (NMTResetNode for sub-index
01h, 03h .. 7Fh, NMTResetCommunicationsufficient for sub-index 2h) or power cycled.
restore default

reset / power cycle

default values valid

Fig. 75.

NMT_RestoreDefParam_REC restore procedure

7.2.1.3

Communication Interface Description

7.2.1.3.1

Object 1F93h: NMT_EPLNodeID_REC

The object stores the devices’s POWERLINK Node ID.
Index
Name
Data Type•

Object TypeRECORD

CategoryM

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F93h
NMT_EPLNodeID_REC
NMT_EPLNodeID_TYPE

00h
NumberOfEntries
2,3
Accessdepends on presence of Sub-Index 03h PDO Mapping

const
No

Sub-Index 01h: NodeID_U8
Sub-Index
Name
Data Type
Value Range
Default Value

01h
NodeID_U8
UNSIGNED8
1 .. 240, 253, 254-

Category
AccessPDO Mapping

M
ro
No

The sub-index holds the device’s actual Node ID. NodeID_U8 may be provided by hardware
settings (dip switch etc.) or set up by software.

EPSG DS 301 V1.5.1
•

-227-

Sub-Index 02h: NodeIDByHW_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

02h
NodeIDByHW_BOOL
BOOLEANBOOLEAN-

Category
AccessPDO Mapping

M
ro
No

The sub-index displays the Node ID setup mode of the device. It shall be setup during system
initialisation.
•

On devices, that setup the POWERLINK Node ID exclusively by HW, the object subindex be set to TRUE.

•

On devices, that setup the POWERLINK Node ID exclusively by SW, the object subindex be set to FALSE.

•

On devices, that enable SW POWERLINK Node ID setup by a special HW setup, thesub-index shall be set to FALSE, if POWERLINK Node ID setup by SW is enabled.
If SW POWERLINK Node ID setup is enabled by a Node ID HW switch, it’srecommended to use Node ID setup = 0.
The ability to define the POWERLINK Node ID by SW shall be indicated in the object dictionary
entry NMT_FeatureFlags_U32 Bit 10 and in the device description by
D_NMT_NodeIDBySW_BOOL. HW setup ability is indicated in the device description by
D_NMT_NodeIDByHW_BOOL .
•Sub-Index 03h: SWNodeID_U8
Sub-Index
Name
Data Type
Value Range

03h
SWNodeID_U8
UNSIGNED8
1 .. 240, 253, 254

Category
AccessDefault Value-PDO Mapping

Cond
cond,
valid on resetNo

The sub-index may be used to setup the Node ID by SW.
If the device supports Node ID setup by SW (NMT_FeatureFlags_U32 Bit 10 is set and
D_NMT_NodeIDBySW_BOOL is true), the sub-index shall be mandatory. Access shall be rws.
Activation of the setting shall be indicated by sub_index 02h.
If the device does not support Node ID setup by SW, the sub-index shall be optional. If
implemented, access shall be ro.

7.2.1.3.2

Object 1030h .. 1039h : NMT_InterfaceGroup_Xh_REC

The following objects are used to configure and retrieve parameters of the network interfaces (physicalor virtual) via SDO. Each interface has one entry. The InterfaceGroup_REC object is a subset of theInterface Group RFC1213.
POWERLINK interfaces shall be described by the low order objects (e.g. 1030h, 1031h, …).
Index
Name
Data Type1030h .. 1039h
NMT_InterfaceGroup_Xh_REC
NMT_InterfaceGroup_TYPE

Object TypeRECORD

Category

1030h:
M
1031h .. 1039h: O

To allow access by name “_Xh” is replaced with a name index. For example, the name index is“_0h” if the object index is 1030h. The name index is incremented up to “_9h” corresponding to
object index 1039h.

EPSG DS 301 V1.5.1•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-228-

00h
NumberOfEntries
99

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
ro
No

Sub-Index 01h: InterfaceIndex_U16
Sub-Index
Name
Data Type
Value Range
Default Value

01h
InterfaceIndex_U16
UNSIGNED16
1..10-Interface index of the physical interface. This number is the index number subtracted by 102Fh.
The POWERLINK node that adds an interface generates the respective value.
The interface identified by a particular value of this index is the same interface as identified by
the same value of NWL_IpAddrTable_Xh_REC.IfIndex_U16.
•

Sub-Index 02h: InterfaceDescription_VSTR
Sub-Index
Name
Data Type
Value Range
Default Value

02h
InterfaceDescription_VSTRVISIBLE_STRING-

Category
AccessPDO Mapping

M
const
No

A textual string containing information about the interface. This string should include the nameof the manufacturer, the product name and the version of the hardware interface.
The value shall be setup by the device firmware during system initialisation.
•

Sub-Index 03h: InterfaceType_U8
Sub-Index
Name
Data Type
Value Range

Default Value

03h
InterfaceType_U8
UNSIGNED8
1 – other6 – ethernet-csmacd
7 – iso88023-csmacd
see RFC1213 Interface Group object
if Type for further numbers
6 – ethernet-csmacd

Category
AccessM
const

PDO MappingNo

The type of interface, distinguished according to the physical/link protocol(s) immediately‘below’ the network layer in the protocol stack.
The value shall be setup by the device firmware during system initialisation.
•

Sub-Index 04h: InterfaceMtu_U16
Sub-Index
Name
Data Type
Value Range
Default Value

04h
InterfaceMtu_U16
UNSIGNED16
UNSIGNED16-

Category
AccessPDO Mapping

M
const
No

The size of the largest datagram which can be sent/received on the interface, specified inoctets. This size also includes the header of the data link layer.
Example: for Ethernet this is the size of the largest frame including MAC addresses, EtherTypeand checksum at the end of the frame.

EPSG DS 301 V1.5.1-229-

The value shall be setup by the device firmware during system initialisation.
•

Sub-Index 05h: InterfacePhysAddress_OSTR
Sub-Index
Name
Data Type
Value Range
Default Value

05h
InterfacePhysAddress_OSTR
OCTET_STRING-

Category
AccessPDO Mapping

M
const
No

The interface’s address at the protocol layer immediately ‘below’ the network layer in the
protocol stack, e.g. the MAC address of an Ethernet interface. For interfaces which do not havesuch an address (e.g. a serial line), this object should contain an octet string of zero length.
The value shall be setup by the device firmware during system initialisation. It shall be read fromthe hardware.
•

Sub-Index 06h: InterfaceName_VSTR
Sub-Index
Name
Data Type
Value Range
Default Value

06h
InterfaceName_VSTRVISIBLE_STRING-

Category
AccessPDO Mapping

M
ro
No

A user reference name for the interface. This name shall be the name used by the device driverto access the interface (e.g. for Linux “eth0”).
•

Sub-Index 07h: InterfaceOperStatus_U8
Sub-Index
Name
Data Type
Value Range
Default Value

07h
InterfaceOperStatus_U8
UNSIGNED8
0 – Down
1 – Up-Category
AccessM
ro

PDO Mapping

No

Category
AccessM
rws

PDO Mapping

No

The current operational state of the interface.
•

Sub-Index 08h: InterfaceAdminState_U8
Sub-Index
Name
Data Type
Value Range
Default Value

08h
InterfaceAdminState_U8
UNSIGNED8
0 – Down
1 – UpUp

The current administration state (Down/Up) of the interface.
The value shall not be set to “Down” if this is the only interface that is “Up”.
•

Sub-Index 09h: Valid_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

09h
Valid_BOOL
BOOLEANBOOLEAN-

Category
AccessPDO Mapping

M
rws
No

Specifies whether or not the data of this object is valid. If the value is TRUE the data of thisobject is valid. If the value is FALSE the data of this object is invalid.

EPSG DS 301 V1.5.1
•

-230-

Sub-Index 0Ah:
Used by EPSG DS302-E [5]7.2.1.3.3

Object 1F9Ah: NMT_HostName_VSTR

Provides the node’s DNS hostname.
The Object shall be supported only if IP is supported by the device. (refer 5.1)
Index
Name
Data Type
Value Range
Default Value

1F9Ah
NMT_HostName_VSTRVISIBLE_STRING32
see 5.1.4-

Object Type

VAR

Category
AccessPDO Mapping

Cond
rws
No

EPSG DS 301 V1.5.1-231-

7.2.1.4

Node List

7.2.1.4.1

Object 1F81h: NMT_NodeAssignment_AU32

This object assigns nodes to the NMT Master (MN).
On the CN the object is conditional. It shall be supplied if one of the following the ARRAY type objects
are implemented by the CN: NMT_MultiplCycleAssign_AU8, NMT_ConsumerHeartbeatTime_AU32,
or NMT_PresPayloadLimitList_AU16.
Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
Available Node IDs may be restricted by the device description entries D_NMT_MaxCNNumber_U8
and D_NMT_MaxCNNodeID_U8 (cf 4.5). Sub-Indices corresponding to invalid Node IDs shall be set
to 0.
The sub-index equal to the MN’s Node ID C_ADR_MN_DEF_NODE_ID shall represent the MN.
The object should be set by the system configuration. It should be equal on all nodes providing thisobject.
On the MN, the object controls the identification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1, the identification process shall be restarted.
Index
Name
Data Type•

Object Type

ARRAY

Category

MN: M
CN: Cond

AccessPDO Mappingrws, valid on reset
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F81h
NMT_NodeAssignment_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h .. FEh: NodeAssignment
Sub-Index
Name-Value Range
Default Value

01h .. FEh
NodeAssignment-Bit field, see below
0

EPSG DS 301 V1.5.1

•

-232-

NodeAssignment Value Interpretation
Octet Bit23

Value

Description

Property

Evaluate

000b

MN, CN11b0bNode with this ID does not exist, Bits 1 to 30
MN, CN
above are not used.
Node with this ID exists.
Node with this ID is not a CN, Bits 2 .. 7, 9, 13 .. 30 MN, CN
are not used.
Node with this ID is a CN. After configuration (withConfiguration Manager) the Node will be set tostate NMT_CS_OPERATIONAL.
On detection of a booting CN inform theCNapplication but do NOT automatically configureand start the node.
On detection of a booting CN inform theapplication and continue the process “START_CN”(see 7.4.2.2.4)
Optional CN.
CN
Mandatory CN.
The CN node may be reset by the NMTSwReset, CN
NMTResetNode, NMTResetCommunication or
NMTResetConfiguration command independent of
its state. Hence no checking of its state needs tobe performed prior to NMT Reset Communication.
MN must not send any of the reset commands
listed above to this node if it notices that the CN isin NMT_CS_OPERATIONAL state.
Application software version verification for thisCN
node is not required.
Application software version verification for thisnode is required.
Automatic application software update (download) CN
is not allowed.
Automatic application software update (download)
is allowed.
Reserved (0b).
--Isochronously accessed node
MN, CN
AsyncOnly nodecontinuously accessed CN
CNmultiplexed CN
device is not a Router Type 1
MN, CNdevice is a Router Type 1
device is not a Router Type 2
MN, CNdevice is a Router Type 2
MN does not transmit Pres
MN
MN transmits Pres
Reserved (0b), used by EPSG DS302-B [2]--Reserved (0b), used by EPSG DS302-C [3]--Reserved (0b), used by EPSG DS302-E [5]--Reserved (00h).
--Reserved (000 0000b).
---

1b

2

0b

1b

3
4

0b
1b
0b

1b

5

0b
1b

6

0b
1b

1

2
3

7
8

--0b
1b
9
0b
1b
10
0b
1b
11
0b
1b
12
0b
1b
13
--14
--15
--16 .. 23 --24 .. 30 ---23 Bit 0 and further bits may be used to control allocation of memory for depending OD entries

MN, CN

MN

MN, CN
MN

MN

MN--MN, CN
MN, CN
MN, CN
MN, CN
MN, CN-----------EPSG DS 301 V1.5.1
Octet Bit23

31

-233-

Value

Description

Property

Evaluate0b1b

Bit 0 .. 30 not valid
Bit 0 .. 30 valid

MN, CN

MN, CN

NMT_NodeAssignment_AU32 interpretation
Bits that control a feature that is not supported by the implementation are ro.
Bit 31 may be used to control memory allocation for Node list array sub-indices located on the
MN and the CN.

7.2.1.5

Timing

The indices described by this paragraph control the timing behavior of the POWERLINK network
traffic. They are common for MN and CN as well. Additional values, that are provided by the MN
implementation only, are listed in 7.2.2.3.

7.2.1.5.1

Object 1006h: NMT_CycleLen_U32

This object defines the communication cycle time interval in µs. This period defines the SYNC interval.
The object should be set by the system configuration.
Index
Name
Data Type
Value Range
Default Value

1006h
NMT_CycleLen_U32
UNSIGNED32
refer below-

Object Type

VAR

Category
AccessPDO MappingMrws, valid on reset
No

Communication cycle period setup values shall be limited by the device description entries
D_NMT_CycleTimeMin_U32 and D_NMT_CycleTimeMax_U32. Both limits shall be multiples of
D_NMT_CycleTimeGranularity_U32. Between the limits, values may be taken from thecontinuum (D_NMT_CycleTimeGranularity_U32 = 1) or stepwise setup may be applied(D_NMT_CycleTimeGranularity_U32 > 1).
To avoid incompatible step sizes that lead to a huge cycle time,
D_NMT_CycleTimeGranularity_U32 should be a multiple of the two base granularities 100 µs or
125 µs.

7.2.1.5.2

Object 1F98h: NMT_CycleTiming_REC

NMT_CycleTiming_REC provides node specific timing parameters, that influence the POWERLINK
cycle timing.
Index
Name
Data Type•

1F98h
NMT_CycleTiming_REC
NMT_CycleTiming_TYPE

Object TypeRECORD

CategoryM

AccessPDO Mapping

const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
MN: 9; CN: 8 .. 9
MN: 9, CN: -EPSG DS 301 V1.5.1

•

-234-

Sub-Index 01h: IsochrTxMaxPayload_U16
SubIndex
Name
Data
Type
Value
Range
Default
Value

01h
IsochrTxMaxPayload_U16
Category

UNSIGNED16
36 .. C_DLL_ISOCHR_MAX_PAYL-

M

Accessconst

PDO
Mapping

No

Provides the device specific upper limit for payload data size in octets of isochronous messages
to be transmitted by the device.
On all nodes, the sub-index limits the size of the Pres frame issued by the node (sub-index
PresActPayloadLimit_U16, refer below). Additionally on the MN, the size of transmitted Preq
messages (object NMT_MNPReqPayloadLimitList_AU16) is affected.
The limit shall be setup by the device firmware during system initialisation.
•

Sub-Index 02h: IsochrRxMaxPayload_U16
SubIndex
Name
Data
Type
Value
Range
Default
Value

02h
IsochrRxMaxPayload_U16
Category

UNSIGNED16
36 .. C_DLL_ISOCHR_MAX_PAYL-

M

Accessconst

PDO
Mapping

No

Provides the device specific upper limit for payload data size in octets of isochronous messages
to be received by the device.
On all nodes, the sub-index limits the size of the Pres frames received by the node (object
NMT_PresPayloadLimitList_AU16, see 7.2.1.5.5). Additionally on the CN, the size of thereceived Preq message (sub-index PreqActPayloadLimit_U16, refer below) is affected.
The limit shall be setup by the device firmware during system initialisation.
•

Sub-Index 03h: PresMaxLatency_U32
Sub-Index
Name
Data Type03h
PresMaxLatency_U32
UNSIGNED32

Category

Value Range
Default ValueUNSIGNED32-

AccessPDO Mapping

CN: M
MN: const
No

Provides the maximum time in ns, that is required by the CN to respond to Preq.
The value shall be setup by the device firmware during system initialisation.

EPSG DS 301 V1.5.1
•

-235-

Sub-Index 04h: PreqActPayloadLimit_U16
Sub-Index
Name
Data Type

04h
PreqActPayloadLimit_U16
UNSIGNED16

Category

Value Range
Default Value

36 .. sub-index 02h-

AccessPDO Mapping

CN: M
MN: rws, valid on reset *)No

Provides the configured Preq payload data slot size in octets expected by the CN. The payload
data slot size plus headers gives the size of the Preq frame. The data slot may be filled by PDO
data up to this limit.
Note: This results in a fixed frame size regardless of the size of PDO data used.
*) The current value of PreqActPayloadLimit_U16 shall be used for checking the mapping at
activation.
Note: The new mapping is active immediately. If the mapping is active but the mapped data arelarger than frame size the received frame shall be ignored. See 6.4.8.2
However the frame size shall change to the current version of PreqActPayloadLimit_U16 after areset configuration only.
The MN holds a list of node specific Preq payload data slot values to be transmitted in object
NMT_MNPReqPayloadLimitList_AU16.
•

Sub-Index 05h: PresActPayloadLimit_U16
Sub-Index
Name
Data Type

05h
PresActPayloadLimit_U16
UNSIGNED16

Category

Value Range
Default Value

36 .. sub-index 01h-

AccessPDO Mapping

CN: M
MN: O
rws, valid on reset *)No

Provides the configured Pres payload data slot size in octets sent by the CN. The payload data
slot size plus headers gives the size of the Pres frame. The data slot may be filled by PDO data
up to this limit.
Note: This results in a fixed frame size regardless of the size of PDO data used*) The current value of PresActPayloadLimit_U16 shall be used for checking the mapping at
activation.
Note: The new mapping is active immediately. If the mapping is active but the mapped data arelarger than the frame size the RD flag shall be reset. See 6.4.8.2
However the frame size shall change to the current version of PresActPayloadLimit_U16 after areset configuration only.
The Pres payload values expected to be received by the node are listed in object
NMT_PresPayloadLimitList_AU16.
•

Sub-Index 06h: AsndMaxLatency_U32
Sub-Index
Name
Data Type06h
AsndMaxLatency_U32
UNSIGNED32

Category

Value Range
Default ValueUNSIGNED32-

AccessPDO Mapping

CN: M
MN: const
No

Provides the maximum time in ns, that is required by the CN to respond to SoA.
The value shall be setup by the device firmware during system initialisation.

EPSG DS 301 V1.5.1
•

-236-

Sub-Index 07h: MultiplCycleCnt_U8
Sub-Index
Name
Data Type
Value Range
Default Value

07h
MultiplCycleCnt_U8
UNSIGNED8UNSIGNED80

Category
AccessPDO MappingMrws, valid on reset
No

This sub-index describes the length of the multiplexed cycle in multiples of the POWERLINK
cycle.
The MultiplCycleCnt_U8 value shall be upper limited by the MN’s device description entry
D_NMT_MNMultiplCycMax_U8. It shall be equal in all nodes of the segment.
If MultiplCycleCnt_U8 is zero, there is no support of multiplexed cycle on the network.
Note: A value of one is a valid value despite the fact that this does not result in a multiplexing.
•

Sub-Index 08h: AsyncMTU_U16
Sub-Index
Name
Data Type
Value
Range
Default
Value

08h
AsyncMTU_U16
UNSIGNED16
C_DLL_MIN_ASYNC_MTU .. see below
C_DLL_MIN_ASYNC_MTU

Category
AccessPDO
MappingMrws, valid
on reset
No

This sub-index describes the maximum asynchronous frame size in octets. The value applies toAsnd frames as well as to UDP/IP and other legacy Ethernet type frames. For this reason thevalue describes the length of the complete Ethernet frame minus 14 octets Ethernet header and4 octets checksum.
AsyncMTU_U16 is upper limited by the NMT_InterfaceGroup_Xh_REC.InterfaceMTU_U16
values of all devices in the segment. This limit shall be 18 octets less than the minimumInterfaceMTU_U16 value provided by any node in the segment. AsyncMTU_U16 may grow up
to C_DLL_MAX_ASYNC_MTU.
AsyncMTU_U16 shall be equal in all nodes of the segment.
Sub-Index 08h shall be valid in all NMT states.
•

Sub-Index 09h: Prescaler_U16
Sub-Index
Name
Data Type
Value Range
Default Value

09h
Prescaler_U16
UNSIGNED16
0, 1 .. 1000
2

Category
AccessPDO Mapping

MN: M, CN: O
rws, valid on reset
No

This sub-index configurates the toggle rate of the SoC PS flag. The value provides the numberof cycles that have to be completed to toggle the flag by the MN.
If Prescaler_U16 is 0, there shall be no toggling of the SoC PS flag.
If Prescaler_U16 is 1 the flag shall be toggled every cycle, if its value is 2 every 2 nd cycle and soon.
Prescaler_U16 shall be equal in all nodes of the segment.
•

Sub-Index 0Ah:
Used by EPSG DS302-C [3]•

Sub-Index 0Bh:
Used by EPSG DS302-C [3]•

Sub-Index 0Ch:
Used by EPSG DS302-C [3]EPSG DS 301 V1.5.1
•

-237-

Sub-Index 0Dh:
Used by EPSG DS302-C [3]•

Sub-Index 0Eh:
Used by EPSG DS302-C [3]•

Sub-Index 0Fh:
Used by EPSG DS302-E [5]7.2.1.5.3

Object 1F9Bh: NMT_MultiplCycleAssign_AU8

This object assigns nodes to the particular POWERLINK cycles of the multiplexed cycle period definedby NMT_CycleTiming_REC.MultiplCycleCnt_U8. The value shall be equal in all nodes of the segment.
Index
Name
Data Type

1F9Bh
NMT_MultiplCycleAssign_AU8
UNSIGNED8

Object Type

ARRAY

Category

Cond

The index shall be supported if the node supports Multiplexing (see NMT_FeatureFlags_U32,
D_DLL_CNFeatureMultiplex_BOOL resp. D_DLL_MNFeatureMultiplex_BOOL) and is valid only
if NMT_CycleTiming_REC.MultiplCycleCnt_U8 is not zero.
•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

00h
NumberOfEntries
0 .. 254-

AccessPDO Mappingrws, valid on reset
No

Category
AccessOrws, valid on reset

PDO MappingNo

Sub-Index 01h – FEh: CycleNo
Sub-Index
Name-Value Range
Default Value

01h – FEh
CycleNo-0 .. NMT_CycleTiming_REC.
MultiplCycleCnt_U8
0Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a multiplexed node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 9.
CycleNo defines the POWERLINK cycle index in the multiplexed cycle, when the respective
node shall be accessed. If CycleNo is zero, the node shall be accessed continuously (see4.2.4.4).

7.2.1.5.4

Object 1016h: NMT_ConsumerHeartbeatTime_AU32

The consumer heartbeat time defines the expected heartbeat cycle time (see 7.3.5). Monitoring starts
after the reception of the first heartbeat. If the consumer heartbeat time is 0 the corresponding entry is
not used. The time must be a multiple of 1ms.

EPSG DS 301 V1.5.1
Index
Name
Data Type
•

-238-

1016h
Object Type
NMT_ConsumerHeartbeatTime_AU32
UNSIGNED32
Category

ARRAY
O

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value
Range
Default
Value

00h
NumberOfEntries
1 .. D_NMT_MaxHeartbeats_U8-

Accessrws

PDO
Mapping

No

Number of Entries, e.g. number of guard channels, may be limited by the device description
entry D_NMT_MaxHeartbeats_U8.
•

Sub-Index 01h – FEh: HeartbeatDescription
Sub-Index
Name-Value Range
Default Value•

01h – FEhHeartbeatDescription-UNSIGNED32
0

Category
AccessPDO Mapping

O
rws
No

Sub-Index 01h – FEh Value Description

Bits
Value
Encoded as

UNSIGNED32
MSB
31-24

23-16

15-0

reserved (value: 00h)-

Node IDUNSIGNED8

heartbeat time
UNSIGNED16LSBHeartbeatDescription value interpretation
If an attempt is made to configure several non-zero consumer heartbeat times for the same
Node ID the device aborts the SDO download with abort code E_NMT_INVALID_HEARTBEAT.

7.2.1.5.5

Object 1F8Dh: NMT_PresPayloadLimitList_AU16

This object holds a list of the expected Pres payload data slot size in octets for each configured nodethat is isochronously accessed, e.g. via Preq / Pres frame exchange. The payload data slot size is ameasure for the configured size of the Pres frame. The data slot may be filled by PDO data up to thislimit.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1F8Dh
NMT_PresPayloadLimitList_AU16
UNSIGNED16

Object Type

ARRAY

Category

MN: M
CN: O

AccessPDO Mappingrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-239-

00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: PresPayloadLimit
SubIndexName-ValueRange

01h .. FEh
PresPayloadLimit-36 .. C_DLL_ISOCHR_MAX_PAYL,
0, FFFFh

Default
Value

36

Category
AccessPDO
MappingM
rws,
valid onreset
No

Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is an isochronous node assigned to the Node ID byindex NMT_NodeAssignment_AU32[sub-index] Bits 0 and 8.
Sub-index C_ADR_MN_DEF_NODE_ID indicates the payload size of the Pres frame issued by
the MN.
A CN shall support the object only if it listens to Pres messages issued by another node (crosstraffic). If the value of NMT_PresPayloadLimitList_AU16 [Node ID] equals 0, the node does notlisten to the Pres of that Node ID. If the value equals FFFFh, the Pres payload limit of this nodeequals NMT_CycleTiming_REC.IsochrRxMaxPayload_U16.
Values should be equal on all nodes of the segment.

7.2.1.6

NMT Service Interface

7.2.1.6.1

Object 1F9Eh: NMT_ResetCmd_U8

NMT_ResetCmd_U8 may be used to initiate the reset of a node.
Index
Name
Data Type
Value
Range
Default
Value

1F9Eh
NMT_ResetCmd_U8
UNSIGNED8NMTInvalidService, NMTResetNode,
NMTResetConfiguration, NMTResetCommunication,
NMTSwReset
NMTInvalidService

Object Type VAR
Category
AccessM
rw

PDO
Mapping

No

Setting NMT_ResetCmd_U8 to the NMT Command ID NMTResetNode,
NMTResetConfiguration, NMTResetCommunication or NMTSwReset (see App. 3.7) shalltrigger the node internal generation of a respective NMT command to itself.
On read access, NMT_ResetCmd_U8 will always show NMTInvalidService.
If applied in NMT_CS_EPL_MODE or NMT_MS_EPL_MODE, resets by NMT_ResetCmd_U8
may violate the NMT rules and stimulate DLL and NMT Guarding errors.

EPSG DS 301 V1.5.1-240-

7.2.1.7

NMT Diagnostics

7.2.1.7.1

Object 1F8Ch: NMT_CurrNMTState_U8

The index holds the node’s current NMT state.
Index
Name
Data Type
Value
Range
Default
Value

1F8Ch
NMT_CurrNMTState_U8
UNSIGNED8
see App. 3.6
NMT_CS_NOT_ACTIVE resp.
NMT_MS_NOT_ACTIVE

Object Type

VAR

Category
AccessM
ro

PDO
MappingNo

An overview list containing the NMT states of all nodes in the segment is provided by MN object
NMT_MNNodeCurrState_AU8.

7.2.2

NMT MN Objects

The NMT Master provides services for controlling the network behavior of nodes. Only one NMT
Master can exist in an Ethernet POWERLINK Network. In POWERLINK the NMT Master is located in
the MN.
The NMT Master Control Settings activate the MN functions and define the boot behavior and error
reactions.

7.2.2.1

MN Start Up Behavior

Hint: MN and CN startup timing should be well balanced. System power up sequence should beconsidered.

7.2.2.1.1

Object 1F80h: NMT_StartUp_U32

This object configures the boot behavior of a device that is able to become the MN.
Object NMT_StartUp_U32 is a configuration object. Internal state transitions must not change thisobject.
The object should be set by the system configuration.
The object controls the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted.

EPSG DS 301 V1.5.1
Index
Name
Data Type
Value Range
Default Value
•

-241-

1F80h
NMT_StartUp_U32
UNSIGNED32
Bit field, see below-

Object Type

VAR

Category
AccessPDO MappingMrws, valid on resetNo

NMT_StartUp_U32 Value Interpretation
Octet

Bit

Value

Description

0

0
1

--0b
1b
0b
1b

Reserved (0b).
Start only explicitly assigned CNs (if Bit 3 = 0b).
Perform the service NMTStartNode with broadcast addressing (if Bit 3 = 0b).
Automatically enter state NMT_MS_OPERATIONAL.
Do not automatically enter state NMT_MS_OPERATIONAL. Application will
decide when to enter the state.
Allow to start up the CNs (i.e. to send NMTStartNode).
Do not allow to send NMTStartNode; the application may start the CNs.
On error event from guarding a mandatory CN deal with the CN individually.
On error event from guarding a mandatory CN perform NMTResetNode withbroadcast addressing. Refer to Bit 6 and NMT_NodeAssignment_AU32 Bit
3.
Reserved (0b).
On error event from guarding a mandatory CN deal with the CN according to
Bit 4.
On error event from guarding a mandatory CN send NMTStopNode withbroadcast addressing. Ignore Bit 4.
Automatically enter state NMT_MS_PRE_OPERATIONAL_2.
Do not automatically enter NMT_MS_PRE_OPERATIONAL_2. Application
will decide when to enter the state.
Automatically enter state NMT_MS_READY_TO_OPERATE.
Do not automatically enter NMT_MS_READY_TO_OPERATE. Application
will decide when to enter the state.
The identification of the CNs shall be limited to verification of the respective
NMT_MNDeviceTypeIdList_AU32 sub-index.
The identification of the CNs shall be completely checked.
The SW-Version of the CNs shall not be checked.
The SW-Version of the CNs shall be checked. If the check fails, the CN’s
SW has to be updated.
The Configuration of the CNs shall not be checked.
The Configuration of the CNs shall be checked. If the check fails, the CN’s
configuration has to be updated.
In case of error event return automatically from NMT_MS_OPERATIONAL
to NMT_MS_PRE_OPERATIONAL_1.
Do not return to NMT_MS_PRE_OPERATIONAL_1. Application will decide
whether to enter the state.
NMT_MS_EPL_MODE activation:
in NMT_MS_NOT_ACTIVE observe the network and change over to
NMT_MS_PRE_OPERATIONAL_1 if there is no other MN detected
NMT_MS_BASIC_ETHERNET released:from NMT_MS_NOT_ACTIVE change over to
NMT_MS_BASIC_ETHERNET
Reserved (0b), used by EPSG DS302-A [1]Reserved (0b)Reserved (00 00h)

2

3

0b
1b
0b
1b

4

5
6

--0b
1b

1

7

0b
1b

8

0b
1b

9

0b

10

1b
0b
1b

11

0b
1b

12

0b
1b

13

0b

1b

2–3

14
15
16 – 31-------NMT_StartUp_U32 interpretationEPSG DS 301 V1.5.1

7.2.2.1.2-242-

Object 1F89h: NMT_BootTime_REC

This object describes time interval values to be used by the MN when it starts the network.
It gives the maximum time, in µs, the master will wait for all mandatory CNs before signaling an error.
If the time is zero (0), it will wait indefinitely.
Hint: MN and CN startup timing should be well balanced. System power up sequence should beconsidered.
Index
Name
Data Type•

Object TypeRECORD

CategoryM

AccessPDO Mapping

const
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F89h
NMT_BootTime_REC
NMT_BootTime_TYPE

00h
NumberOfEntries
99

Sub-Index 01h: MNWaitNotAct_U32
Sub-Index
Name
Data Type
Value Range
Default Value01h
MNWaitNotAct_U32
UNSIGNED32>=250
1 000 000

This sub-index describes the time interval in µs that the MN shall remain in state
NMT_MS_NOT_ACTIVE and listen for POWERLINK frames on the network before it changes
over to NMT_MS_PRE_OPERATIONAL_1.
•

Sub-Index 02h: MNTimeoutPreOp1_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
MNTimeoutPreOp1_U32
UNSIGNED32
0, 50 000 – 5 000 000
500 000

Category
AccessPDO MappingMrws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait in state
NMT_MS_PRE_OPERATIONAL_1 for all mandatory CNs to be identified via the IdentRequest /IdentResponse mechanism before it signals an error to the application.
If the timeout value is zero (0), there shall be no timeout for CN identification.
•

Sub-Index 03h: MNWaitPreOp1_U32
Sub-Index
Name
Data Type
Value Range
Default Value03h
MNWaitPreOp1_U32
UNSIGNED32
0, 50 000 – 5 000 000
500 000

Category
AccessPDO MappingO
rws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall remain in state
NMT_MS_PRE_OPERATIONAL_1.
If the wait value is zero (0), NMT_MS_PRE_OPERATIONAL_1 shall be left as soon as all
mandatory CNs have been identified.

EPSG DS 301 V1.5.1
•

-243-

Sub-Index 04h: MNTimeoutPreOp2_U32
Sub-Index
Name
Data Type
Value Range
Default Value

04h
MNTimeoutPreOp2_U32
UNSIGNED32
UNSIGNED32
500 000

Category
AccessPDO MappingMrws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait in state
NMT_MS_PRE_OPERATIONAL_2 for all mandatory CNs to complete the initialisation of theerror signaling and to be in state NMT_CS_READY_TO_OPERATE before it signals an error to
the application.
For all optional CNs this sub-index describes the time interval in µs that the MN shall wait after
sending the NMT command NMTEnableReadyToOperate to a CN before BOOT_STEP2
returns with an error.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.
•

Sub-Index 05h: MNTimeoutReadyToOp_U32
Sub-Index
Name
Data Type
Value Range
Default Value

05h
MNTimeoutReadyToOp_U32
UNSIGNED32
0, 50 000 – 5 000 000
500 000

Category
AccessPDO MappingMrws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait in state
NMT_MS_READY_TO_OPERATE for all mandatory CNs to be in state
NMT_CS_OPERATIONAL before it signals an error to the application.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.
•

Sub-Index 06h: MNIdentificationTimeout_U32
Sub-Index
Name
Data Type
Value Range
Default Value

06h
MNIdentificationTimeout_U32
UNSIGNED32
UNSIGNED32
500 000

Category
AccessPDO MappingO
rws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait in the
CHECK_IDENTIFICATION state of the boot process until a device must be able to reply to an
Ident Request message before an error is signaled to the application.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.
•

Sub-Index 07h: MNSoftwareTimeout_U32
Sub-Index
Name
Data Type
Value Range
Default Value

07h
MNSoftwareTimeout_U32
UNSIGNED32
UNSIGNED32
500 000

Category
AccessPDO MappingO
rws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait after the software updatein the CHECK_SOFTWARE state until a device must be able to reply to an Ident Request
message before an error is signaled to the application.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.

EPSG DS 301 V1.5.1
•

-244-

Sub-Index 08h: MNConfigurationTimeout_U32
Sub-Index
Name
Data Type
Value Range
Default Value

08h
MNConfigurationTimeout_U32
UNSIGNED32
UNSIGNED32
500 000

Category
AccessPDO MappingO
rws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait after the configuration ofa CN was updated in the CHECK_CONFIGURATION state until a device must be able to reply
to an Ident Request message before an error is signaled to the application.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.
•

Sub-Index 09h: MNStartCNTimeout_U32
Sub-Index
Name
Data Type
Value Range
Default Value09h
MNStartCNTimeout_U32
UNSIGNED32
UNSIGNED32
500 000

Category
AccessPDO MappingO
rws, valid on reset
No

This sub-index describes the time interval in µs that the MN shall wait for a CN in the
START_CN state to switch over to NMT_CS_OPERATIONAL before an error is signaled to theapplication.
If the timeout value is zero (0), there shall be no timeout, i.e. the MN will wait indefinitely.
•

Sub-Index 0Ah
Used by EPSG DS302-A [1]•Sub-Index 0Bh
Used by EPSG DS302-A [1]•Sub-Index 0Ch
Used by EPSG DS302-A [1]7.2.2.2

NMT Master Network Node Lists

The Network List consists of objects that give information about which CNs must be managed, how
they should be booted and information concerning requested actions on Error events.

7.2.2.2.1

Object 1F84h: NMT_MNDeviceTypeIdList_AU32

This object holds a list of the expected NMT_DeviceTypeId_U32 value for each configured CN.
The object should be set by the system configuration. It shall be filled with the NMT_DeviceType_U32
object dictionary entry of the respective device.
It may be used by the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted.
Index
Name
Data Type•

1F84h
NMT_MNDeviceTypeIdList_AU32
UNSIGNED32

Object Type

ARRAY

CategoryM

AccessPDO Mappingrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1 .. 254
254

EPSG DS 301 V1.5.1

•

-245-

Sub-Index 01h .. FEh: CNDeviceTypeId
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNDeviceTypeId-UNSIGNED32
0

Category
AccessPDO MappingMrws, valid on reset
No

Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID may represent the MN.
On Boot-Up, the CN’s NMT_DeviceType_U32 value is reported to the MN via IdentResponse.
The MN shall compare the received value with the respective CNDeviceTypeId sub-index value.
The Boot-Up for that device is only continued when the two values are equal.
If the value in CNDeviceTypeId is 0, this read access only gives information about the mere
existence of a device with this Node ID. There is no comparison to the reported
NMT_DeviceType_U32 value.
For multi-device-modules the application may perform additional checks.

7.2.2.2.2

Object 1F85h: NMT_MNVendorIdList_AU32

This object holds a list of the expected NMT_IdentityObject_REC.VendorId_U32 value for eachconfigured CN.
The object should be set by the system configuration. It shall be filled with the
NMT_IdentityObject_REC.VendorId_U32 object dictionary entry of the respective device.
It may be used by the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted.
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO Mappingrws, valid on reset
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F85h
NMT_MNVendorIdList_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CNVendorId
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNVendorId-UNSIGNED32
0Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID may represent the MN.
On Boot-Up, the CN’s NMT_IdentityObject_REC.VendorId_U32 value is reported to the MN via
IdentResponse. The MN compares the received value with the respective CNVendorId subindex value. The Boot-Up for that device is only continued when the two values are equal.
If the value in CNVendorId is 0, this read access only gives information about the mere
existence of a device with this Node ID. There is no comparison with the reported
NMT_IdentityObject_REC.VendorId_U32 value.

EPSG DS 301 V1.5.1-246-

For multi-device-modules the application may perform additional checks.

7.2.2.2.3

Object 1F86h: NMT_MNProductCodeList_AU32

This object holds a list of the expected NMT_IdentityObject_REC.ProductCode_U32 value for eachconfigured CN.
The object should be set by the system configuration. It shall be filled with the
D_NMT_ProductCode_U32 device descrition entry of the respective device.
It may be used by the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted
Index
Name
Data Type•

Object Type

ARRAY

CategoryO

AccessPDO Mappingrws, valid on reset
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F86h
NMT_MNProductCodeList_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CNProductCode
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNProductCode-UNSIGNED32
0Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID may represent the MN.
On Boot-Up, the CN’s NMT_IdentityObject_REC.ProductCode_U32 value is reported to the MN
via IdentResponse. The MN compares the received value with the respective CNProductCode
sub-index value. The Boot-Up for that device is only continued when the two values are equal.
If the value in CNProductCode is 0, this read access only gives information about the mere
existence of a device with this Node ID. There is no comparison with the reported
NMT_IdentityObject_REC.ProductCode_U32 value.
For multi-device-modules the application may perform additional checks.

7.2.2.2.4

Object 1F87h: NMT_MNRevisionNoList_AU32

This object holds a list of the expected NMT_IdentityObject_REC.RevisionNo_U32 value for eachconfigured CN.
The object should be set by the system configuration. It shall be filled with the
D_NMT_RevisionNo_U32 device descrition entry of the respective device.
It may be used by the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1F87h
NMT_MNRevisionNoList_AU32
UNSIGNED32

Object Type

ARRAY

CategoryO

AccessPDO Mappingrws, valid on reset
No

Category
AccessPDO MappingMrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-247-

00h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CNRevisionNo
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNRevisionNo-UNSIGNED32
0Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID may represent the MN.
On Boot-Up, the CN’s NMT_IdentityObject_REC.RevisionNo_U32 is reported to the MN via
IdentResponse. The MN compares the received value with the respective CNRevisionNo subindex value. The Boot-Up for that device is only continued when the two values are equal.
If the value in CNRevisionNo is 0, this read access only gives information about the mere
existence of a device with this Node ID. There is no comparison with the reported
NMT_IdentityObject_REC.RevisionNo_U32 value.
For multi-device-modules the application may perform additional checks.

7.2.2.2.5

Object 1F88h: NMT_MNSerialNoList_AU32

This object holds a list of the expected NMT_IdentityObject_REC.SerialNo_U32 value for eachconfigured CN.
The object should be set by the system configuration.
It may be used by the verification of CNs. If the object is modified in state
NMT_MS_PRE_OPERATIONAL_1 after start of verification, verification process shall be restarted
Index
Name
Data Type•

1F88h
NMT_MNSerialNoList_AU32
UNSIGNED32

Object Type

ARRAY

CategoryO

AccessPDO Mappingrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1 .. 254
254

EPSG DS 301 V1.5.1

•

-248-

Sub-Index 01h – FEh: CNSerialNo
Sub-Index
Name-Value Range
Default Value

01h .. FEh
CNSerialNo-UNSIGNED32
0

Category
AccessPDO MappingMrws, valid on reset
No

Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID may represent the MN.
On Boot-Up, the CN’s NMT_IdentityObject_REC.SerialNo_U32 is reported to the MN via
IdentResponse. The MN compares the received value with the respective CNSerialNo subindex value. If the values are different a warning is issued.
If the value in CNSerialNo is 0, this read access only gives information about the mere
existence of a device with this Node ID. There is no comparison with the reported
NMT_IdentityObject_REC.SerialNo_U32 value.
For multi-device-modules the application may perform additional checks.

7.2.2.3

Timing

The indices described by this paragraph shall be implemented by the MN only. They control the timing
behavior of the POWERLINK network traffic. They are supplemetal to the the objects described by
7.2.1.4.

7.2.2.3.1

Object 1F8Ah: NMT_MNCycleTiming_REC

This object holds timing parameter use by the MN only to control the POWERLINK cycle.
Index 1F8Ah

ObjectType

Nam NMT_MNCycleTiming_REC
e
Data
NMT_MNCycleTiming_TYPE
Type•

CategorMySub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

RECORD00h
NumberOfEntries
1 .. 4-

AccessPDO MappingroNoCategory
AccessPDO MappingMrws, valid on resetNo

Sub-Index 01h: WaitSoCPReq_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
WaitSoCPReq_U32
UNSIGNED32
UNSIGNED32
1000

The sub-index provides a time interval in ns between end of SoC transmission and begin of thenext frame transmission (Preq or PresMN). This wait interval enables the CN first accessed
after SoC to complete it’s SoC handling.
WaitSoCPReq_U32
shall
be
set
to
the
maximumof
D_NMT_MNSoC2PReq_U32D_NMT_MNSoC2PReq_U32 and the D_NMT_CNSoC2PReq_U32
values of all configured isochronous CNs (cf. NMT_NodeAssignment_AU32[sub-index] Bits 0, 1
and 8).
WaitSoCPReq_U32 handling may be implemented in 2 ways (see 4.2.4.3):

EPSG DS 301 V1.5.1
a.
b.

-249-

delayed transmision of 1st Preq following SoC by MN, sub-index provides time interval
between the end of the SoC transmission and the start of the first Preq
Transmission of the 1st Preq to the non existing node addressed by

C_ADR_DUMMY_NODE_ID. The Pres frame receive timeout shall be set to
WaitSoCPReq_U32. Timeout error handling (see 4.7.6.2, 4.7.6.3) shall be disabled forthis dummy message.
•

Sub-Index 02h: AsyncSlotTimeout_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
AsyncSlotTimeout_U32
UNSIGNED32>=250
100 000

Category
AccessPDO MappingO
rws, valid on resetNo

The sub-index describes the worst case time interval in ns between the end of the SoA
transmission and the begin of the reception of an Asnd frame issued by a CN.
•

Sub-Index 03h:
Used by EPSG DS302-B [2]•Sub-Index 04h: MinRedCycleTime_U32
Sub-Index
Name
Data Type
Value Range
Default Value04h
MinRedCycleTime_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO MappingO
rws, valid on resetNo

The minimum reduced cycle time (MinRedCycleTime_U32) holds the minimum time between
SoA frames in the reduced cycle.
MinRedCycleTime_U32 shall be set to the maximum of D_NMT_MinRedCycleTime_U32 of theCNs.

7.2.2.3.2

Object 1F8Bh: NMT_MNPReqPayloadLimitList_AU16

This object holds a list of the Preq payload data slot size in octets for each configured node that is
isochronously accessed, e.g. via Preq / Pres frame exchange. The payload data slot size is a measurefor the configured size of the Preq frame. The data slot may be filled by PDO data up to this limit.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1F8Bh
Object Type
NMT_MNPReqPayloadLimitList_AU16
UNSIGNED16
Category

ARRAY
M

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-250-

00h
NumberOfEntries
1 .. 254
254

AccessPDO Mappingrws, valid on resetNo

Sub-Index 01h – FEh: CNPReqPayload
SubIndexName-ValueRange

01h .. FEh
CNPReqPayload--

Category
Access36 .. C_DLL_ISOCHR_MAX_PAYL

Default
Value

PDO
Mapping

36

M
rws,
valid onreset
No

Each sub-index in the array corresponds to the CN with the Node ID equal to the sub-index.
The sub-index value is valid only if there is an isochronous CN assigned to the Node ID byindex NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.

7.2.2.3.3

Object 1F92h: NMT_MNCNPResTimeout_AU32

This object holds a list of all configured CNs in [ns] with PollRequest to PollResponse timeouts (see4.7.6.2, 4.7.6.3).
The object should be set by the system configuration.
Index
Name
Data Type•

Object Type

ARRAY

CategoryM

AccessPDO Mappingrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F92h
NMT_MNCNPResTimeout_AU32
UNSIGNED3200h
NumberOfEntries
1 .. 254
254

Sub-Index 01h – FEh: CNPResTimeout
Sub-Index

01h .. FEh

Name

CNPResTimeout----

Category

M

Value Range

UNSIGNED32

Accessrws, valid on reset

Default Value

25 000PDO MappingNo

Each sub-index in the array corresponds to a CN with the Node ID equal to the sub-index. The
sub-index value is valid only if there is an isochronous CN assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bits 0, 1 and 8.
This parameter describes the POWERLINK node specific timeout values in ns. Whenever a
PollRequest frame is sent to a CN this timer is started. (refer 4.7.6.1.1)

EPSG DS 301 V1.5.1

7.2.2.3.4-251-

Object 1F9Ch: NMT_IsochrSlotAssign_AU8

This object assigns nodes to a particular isochronous slot. The isochronous POWERLINK cycle canbe divided into communication slots each consisting of Preq and Pres message for a particular node(see slot 1 to n in Fig. 76).

Fig. 76.

POWERLINK communication slots

The object 1F9Ch can be used to request fast processing nodes first and give slower nodes enoughtime for the SoC processing for example.
Index
Name
Data Type•

1F9Ch
NMT_IsochrSlotAssign_AU8
UNSIGNED8

Object Type

ARRAY

CategoryO

AccessPDO Mappingrws, valid on resetNo

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
1 .. 254
254

Sub-index 0 may be used to limit the number of isochronous slots per cycle to be checked by
the cycle producing in the DLL_MS.
•

Sub-Index 01h – Feh: NodeId
Sub-Index
Name-Value Range
Default Value

01h-FEh
NodeId-0 .. 254
0Category
AccessPDO MappingO
rws, valid on reset
No

Each sub-index in the array corresponds to an individual communication slot which is equal to
the sub-index. The slot shall only be used if there is an isochronous node with the Node ID
assigned by index NMT_NodeAssignment_AU32[sub-index] Bits 0, 1, 8 and 9. Value 0
indicates that there is no particular node assigned to the communication slot.
The sub-indices can also be used for the slot assignment of multiplexed nodes. If multiplexedand non-multiplexed nodes shall be assigned to particular communication slots, it must be
ensured that all the isochronous non-multiplexed stations are configured on the lower subindices of object 1F9Ch. Care has also to be taken that the multiplex slots are mapped to thecommunication slots in ascending order. That means the first multiplexed node assigned toobject 1F9Ch must be configured in the first multiplex slot in object 1F9Bh and so on.

EPSG DS 301 V1.5.1-252-

Gaps in the NMT_IsochrSlotAssign_AU8 are allowed as unused communication slots are
skipped.
Example:Let’s assume nodes 10 to 14 are non-multiplexed nodes and nodes 15-18 are multiplexed
nodes. Furthermore node 10 is a slow processing node which must be shifted away from thecycle beginning. The slot diagram for the isochronous cycle will look as follows:
Cycle iSlot
Station

1
11

2
12

3
13

4
14

Cycle i+1
5
10

non-multiplexed

6
16

7
17

1
11

2
12

3
13

4
14

5
10

non-multiplexed

multiplexed

618

multiplexed

The above example results in the following setup of object NMT_IsochrSlotAssign_AU8:
Index
1F9Ch
sub-index 0
value
9

1
11

2
12

3
13

4
14

5
10

6
16

7
17

7
15

8
18

9
15

EPSG DS 301 V1.5.1-253-

The setup of object 1F9Bh NMT_MultiplCycleAssign_AU8 for the multiplexed nodes 15 to 18
must look as follows:
Index
1F9Bh
sub-index 10value0

7.2.2.4

11
0

12
0

13
0

14
0

15
2

16
1

17
1

18
2

CN NMT State Surveillance

The objects described by this paragraph are used by the MN surveillance of the CN NMT states as
described at 7.1.4.

7.2.2.4.1

Object 1F8Eh: NMT_MNNodeCurrState_AU8

This object holds a list of the current NMT states of the configured nodes.
Index
Name
Data Type•

Object Type

ARRAY

CategoryM

AccessPDO Mapping

const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F8Eh
NMT_MNNodeCurrState_AU8
UNSIGNED800h
NumberOfEntries
254
254

Sub-Index 01h – FEh: CurrState
Sub-Index
Name-ValueRange
Default
Value

01h .. FEh
CurrState-see App. 3.6
NMT_CS_NOT_ACTIVE resp.
NMT_MS_NOT_ACTIVE

Category
AccessM
ro

PDO
Mapping

No

Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID indicates the current state of the MN state machine. It
holds values described by Tab. 105.
The individual states of the nodes may be locally accessed via NMT_CurrNMTState_U8.

7.2.2.4.2

Object 1F8Fh: NMT_MNNodeExpState_AU8

This object holds a list of the expected NMT states of the configured nodes in accordance with theCNs’ boot-up behavior and the NMT state commands transmitted by the MN. See 7.1.4.
The sub-indices of NMT_MNNodeExpState_AU8 should be equal to those of
NMT_MNNodeCurrState_AU8 expect for an interval of C_NMT_STATE_TOLERANCE after an NMT
state command to the respective CN.
Index
Name
Data Type

1F8Fh
NMT_MNNodeExpState_AU8
UNSIGNED8

Object Type

ARRAY

CategoryOEPSG DS 301 V1.5.1•

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-254-

00h
NumberOfEntries
254
254

AccessPDO Mapping

const
No

Sub-Index 01h – FEh: ExpState
Sub-Index
Name-ValueRange
Default
Value

01h .. FEh
ExpState-see App. 3.6
NMT_CS_NOT_ACTIVE resp.
NMT_MS_NOT_ACTIVE

Category
AccessM
ro

PDO
Mapping

No

Each sub-index in the array corresponds to the node with the Node ID equal to the sub-index.
The sub-index value is valid only if there is a node assigned to the Node ID by index
NMT_NodeAssignment_AU32[sub-index] Bit 0.
Sub-index C_ADR_MN_DEF_NODE_ID indicates the current state of the MN state machine. It
holds values described by Tab. 105.

7.2.2.5

NMT Service Interface

7.2.2.5.1

Object 1F9Fh: NMT_RequestCmd_REC

NMT_RequestCmd_REC may be used by a diagnostic node outside of the POWERLINK segment
connected via a router to initiate an NMT command by the MN.
Index
Name
Data Type•

Object TypeRECORD

CategoryM

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rw
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1F9Fh
NMT_RequestCmd_REC
NMT_RequestCmd_TYPE

00h
NumberOfEntries
3 .. 4-Sub-Index 01h: Release_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

01h
Release_BOOL
BOOLEANBOOLEAN
FALSE

Writing TRUE to Release_BOOL shall trigger the positioning of the NMT command describedby sub-indices 02h to 04h to the transmission queues of the MN.
Release_BOOL shall be automatically reset to FALSE by the MN, when queuing of the NMT
services has been completed.

EPSG DS 301 V1.5.1
•

-255-

Sub-Index 02h: CmdID_U8
Sub-Index
Name
Data Type
Value Range
Default Value02h
CmdID_U8
UNSIGNED8
see.App. 3.7
NMTInvalidService

Category
AccessPDO Mapping

M
rw
No

CmdID_U8 indicates the requested NMT service. It is equivalent to the
NMTRequestedCommandID entry of the NMTRequest Frame NMT Service Slot (see 7.3.6.1)•

Sub-Index 03h: CmdTarget_U8
Sub-Index
Name
Data Type
Value Range
Default Value

03h
CmdTarget_U8
UNSIGNED8UNSIGNED8C_ADR_INVALID

Category
AccessPDO Mapping

M
rw
No

CmdTarget_U8 indicates POWERLINK address of the target node of the requested NMT
service. It is equivalent to the NMTRequestedCommandTarget entry of the NMTRequest FrameNMT Service Slot (see 7.3.6.1)•

Sub-Index 04h: CmdData_DOM
Sub-Index
Name
Data Type
Value Range
Default Value

04h
CmdData_DOM
DOMAINDOMAIN-

Category
AccessPDO Mapping

Cond
rw
No

CmdData_DOM provides data specific to the requested NMT service. It is equivalent to the
NMTRequestedCommandData entry of the NMTRequest Frame NMT Service Slot (see 7.3.6.1)
CmdData_DOM shall be supported if extended NMT State Command Services are supportedby the MN, support shall be indicated by the object dictionary index NMT_FeatureFlags_U32 Bit
5.

7.2.3

NMT CN Objects

7.2.3.1

CN StartUp Behaviour

Hint: MN and CN startup timing should be well balanced. System power up sequence should beconsidered.

7.2.3.1.1

Object 1F99h: NMT_CNBasicEthernetTimeout_U32

Provide the time in µs to be applied before changing from NMT_CS_NOT_ACTIVE to
NMT_CS_BASIC_ETHERNET.
Index
Name
Data Type
Value Range
Default Value

1F99h
NMT_CNBasicEthernetTimeout_U32
UNSIGNED32
UNSIGNED32
5 000 000

Object Type

VAR

Category
AccessPDO MappingMrws, valid on reset
No

Value 0 shall mean, never change to NMT_CS_BASIC_ETHERNET. If not 0, the value shall begreater than NMT_CycleLen_U32.
To avoid erroneous change over to NMT_CS_BASIC_ETHERNET at system startup,
NMT_CNBasicEthernetTimeout_U32 should be greater than the MN’s
NMT_BootTime_REC.MNWaitNotAct_U32.
Note: It is the responsibility of the user resp. configuration tool to set an appropriate value.

EPSG DS 301 V1.5.1

-256-

7.2.4

NMT Object Types

7.2.4.1

Object 0023h: IDENTITY

Index
Name

0023h
IDENTITY

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
VendorId_U32
ProductCode_U32
RevisionNo_U32
SerialNo_U32

Value
04h
0007h
0007h
0007h
0007h

Data Type

7.2.4.2

UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

Object 0429h: NMT_ParameterStorage_TYPE

Index
Name

0429h
NMT_ParameterStorage_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h .. 7Fh

Component Name
NumberOfEntries
AllParam_U32
CommunicationParam_U32
ApplicationParam_U32
ManufacturerParam_XXh_U32

Value
7Fh
0007h
0007h
0007h
0007h

Data Type

7.2.4.3

UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

Object 042Bh: NMT_InterfaceGroup_TYPE

Index
Name

042Bh
NMT_InterfaceGroup_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h
06h
07h
08h
09h

Component Name
NumberOfEntries
InterfaceIndex_U16
InterfaceDescription_VSTR
InterfaceType_U8
InterfaceMtu_U16
InterfacePhysAddress_OSTR
InterfaceName_VSTR
InterfaceOperStatus_U8
InterfaceAdminState_U8
Valid_BOOL

Value
09h
0006h
0009h
0005h
0006h
000Ah
0009h
0005h
0005h
0001h

Data Type

7.2.4.4

UNSIGNED16
VISIBLE_STRINGUNSIGNED8UNSIGNED16
OCTET_STRINGVISIBLE_STRINGUNSIGNED8UNSIGNED8BOOLEAN

Object 042Ch: NMT_CycleTiming_TYPE

Index
Name

042Ch
NMT_CycleTiming_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h

Component Name
NumberOfEntries
IsochrTxMaxPayload_U16
IsochrRxMaxPayload_U16
PresMaxLatency_U32
PreqActPayloadLimit_U16
PresActPayloadLimit_U16

Value
09h
0006h
0006h
0007h
0006h
0006h

Data TypeUNSIGNED16
UNSIGNED16
UNSIGNED32
UNSIGNED16
UNSIGNED16

EPSG DS 301 V1.5.1
06h
07h
08h
09h

7.2.4.5-257-

AsndMaxLatency_U32
MultiplCycleCnt_U8
AsyncMTU_U16
Prescaler_U16

0007h
0005h
0006h
0006h

UNSIGNED32
UNSIGNED8UNSIGNED16
UNSIGNED16

Object 042Eh: NMT_BootTime_TYPE

Index
Name

042Eh
NMT_BootTime_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h
06h
07h
08h
09h

Component Name
NumberOfEntries
MNWaitNotAct_U32
MNTimeoutPreOp1_U32
MNWaitPreOp1_U32
MNTimeoutPreOp2_U32
MNTimeoutReadyToOp_U32
MNIdentificationTimeout_U32
MNSoftwareTimeout_U32
MNConfigurationTimeout_U32
MNStartCNTimeout_U32

Value
05h
0007h
0007h
0007h
0007h
0007h
0007h
0007h
0007h
0007h

Data Type

7.2.4.6

UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

Object 042Fh: NMT_MNCycleTiming_TYPE

Index
Name

042Fh
NMT_MNCycleTiming_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h

Component Name
NumberOfEntries
WaitSoCPReq_U32
AsyncSlotTimeout_U32

Value
02h
0007h
0007h

Data Type

7.2.4.7

UNSIGNED32
UNSIGNED32

Object 0439h: NMT_EPLNodeID_TYPE

Index
Name

0439h
NMT_EPLNodeID_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h

Component Name
NumberOfEntries
NodeID_U8
NodeIDByHW_BOOL
SWNodeID_U8

Value
02h
0005h
0001h
0005h

Data Type

7.2.4.8

UNSIGNED8BOOLEANUNSIGNED8

Object 043Ah: NMT_RequestCmd_TYPE

Index
Name

043Ah
NMT_RequestCmd_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
Release_BOOL
CmdID_U8
CmdTarget_U8
CmdData_DOM

Value
04h
0001h
0005h
0005h
000Fh

Data Type
BOOLEANUNSIGNED8UNSIGNED8
DOMAINEPSG DS 301 V1.5.1

7.3

-258-

Network Management Services

POWERLINK Network Management (NMT) is node-oriented and follows a master/slave relationship.
The function of the NMT master is carried out by the MN.
CNs are administrated as NMT slaves by the master. An NMT slave is uniquely identified in the
network by its POWERLINK Node ID.
According to the definition, Network Management is directed from the NMT master (MN) to the NMT
slaves (CNs).
POWERLINK defines five categories of NMT services:•

NMT State Command Services
The MN uses NMT State Command Services to control the CN state machine(s).

•NMT Managing Command Services
The MN uses NMT Managing Command Services to access NMT data items of the CN(s) in afast coordinated way.

•

NMT Response Services
NMT Response Services indicate the current NMT state of a CN to the MN.

•

NMT Info Services
NMT Info Services are used to transmit NMT information from the MN to a CN.

•

NMT Guard services

NMT Guard Services are used by the MN and CNs to detect failures in a POWERLINK network.
A CN may request NMT command and info services to be issued by the MN (NMTRequest, see
7.3.6).
In NMT_CS_EPL_MODE, a CN shall ignore NMT command services that are not issued by the MN. In
NMT_CS_BASIC_ETHERNET NMT command services shall be accepted regardless their source
node.

7.3.1

NMT State Command Services

The MN controls the state of the CN via NMT State Command Services. The state transitions aredefined by the CN state machine (see 7.1.4).
POWERLINK distinguishes between implicit and explicit NMT State Commands.

7.3.1.1

Implicit NMT State Command Services

At system startup, the reception or the timeout of SoA, PReq, PRes or SoC frames trigger CN statemachine transitions from the state NMT_CS_NOT_ACTIVE to the next states. In
NMT_CS_PRE_OPERATIONAL_1 the reception of SoC triggers the transition to
NMT_CS_PRE_OPERATIONAL_2. SoA, PReq, PRes or SoC are used to synchronise a CN with thecurrent network mode after system start or reset. (see 7.1.4).
In Basic Ethernet Mode, the reception of POWERLINK SoA, PReq, PRes or SoC will trigger a changeover to NMT_CS_EPL_MODE. (see 7.1.4).

EPSG DS 301 V1.5.1-259-

Implicit NMT State Command
MN

CN(s)
SoA / SoC / PReq /PRes

requestFig. 77.

indication
indication
indication

Implicit NMT state command service protocol

SoA, PReq, PRes or SoC acting as shown above are termed implicit NMT state commands. They arevalid regardless of their data content and without further extensions.
Tab. 122 displays implicit NMT state commands in relation to the current CN state when the commandis received. SoA and SoC reception or timeouts not mentioned in the table do not trigger statetransitions.
Current State

Implicit NMT State
Command

Destination State

NMT_CS_NOT_ACTIVE

SoA, SoC
Timeout (SoA, PReq,
PRes, SoC)
SoC
SoA, PReq, PRes, SoC

NMT_CS_PRE_OPERATIONAL_1
NMT_CS_BASIC_ETHERNETNMT_CS_PRE_OPERATIONAL_1
NMT_CS_BASIC_ETHERNETNMT_CS_PRE_OPERATIONAL_2
NMT_CS_PRE_OPERATIONAL_1

Implicit NMT state commands
An NMT Response Service (see 7.3.3) requested by the implicit NMT State Command shall indicate
the current state.

7.3.1.1.1

Implicit NMT State Command Transmission

Implicit NMT State Command services (7.3.1.1) do not require explicit NMT frame transmission by the
MN. Regular SoA, PReq, PRes and SoC frames (refer 4.6.1.1) can be valid Implicit NMT State
Commands on their own.
SoA, PRes and SoC frames cannot be sent directly to a single node – they are multicast. The CN
decides according to its own current state whether a received implicit NMT State command is active(i.e. is to be carried out).

7.3.1.2

Explicit NMT State Command Services

An explicit NMT State Command shall be transmitted by the MN in the ASnd frame.
The target CN shall be addressed via the ASnd Destination field. The ASnd frame shall be either
unicast to one CN or broadcast to all CNs (using the POWERLINK broadcast address
C_ADR_BROADCAST). A command sent via broadcast shall be ignored at the transmitting MN.
Special broadcast NMT commands may be sent to selected groups of CNs (see 7.3.1.2.2).
The explicit NMT State Command services shall be identified by ASnd ServiceID = NMT_COMMAND.
Fig. 78 shows the protocol used to implement the explicit NMT State Command Services.

EPSG DS 301 V1.5.1-260-

Explicit NMT State Command
MN

CN(s)
ASnd
(ServiceID =NMT_COMMAND)

requestFig. 78.

indication(indication)(indication)

Explicit NMT state command service protocol

The ASnd ServiceID value of explicit NMT State Command Services shall be NMT_COMMAND. The
specific NMT State Command identification and its data shall be located in the ASnd Payload field,
called NMT Service Slot in the following.
Octet offset 24

7

6

0
1
2 .. n5

Bit Offset
4
3

2

1

0

NMTCommandID
Reserved
NMTCommandDatan ≤ C_DLL_MAX_PAYL_OFFSET – 4

NMT state command service, NMT managing command service and NMT info service
structure of the NMT Service Slot field
Field

Abbr.

Description

Value

NMTCommandID

cid

Qualifies the NMT state command.

Tab. 125, Tab.
126

NMTCommandData cdat

0..C_DLL_MAX_PAYL_OFFSET – 6 octets of NMT
command-specific data to be issued by the MN.
The lower layer is responsible for padding.

NMT Service Slot fields of explicit NMT state command services

7.3.1.2.1

Plain NMT State Command

The Plain NMT State Command shall be unicast to a specific CN or broadcast to all CNs.
Plain NMT State Commands shall ignore NMTCommandData.
The following Plain NMT State Commands are defined:

24 Octet offset is measured from the begin of the ASnd Payload field. The offset relative to thebeginning of the Ethernet frame is 18 octets.

EPSG DS 301 V1.5.1
NMTCommandID
NMTStartNode
NMTStopNode

NMTEnterPreOperational2
NMTEnableReadyToOperate
NMTResetNode

NMTResetCommunication

NMTResetConfiguration

NMTSwReset-261-

Initial state
NMT_CS_READY_TO_OPERATENMT_CS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATENMT_CS_OPERATIONAL
NMT_CS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_PRE_OPERATIONAL_2
NMT_CS_NOT_ACTIVE /NMT_MS_NOT_ACTIVE
NMT_CS_PRE_OPERATIONAL_1 /NMT_MS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2 /NMT_MS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATE /NMT_MS_READY_TO_OPERATENMT_CS_OPERATIONAL /NMT_MS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNETNMT_CS_NOT_ACTIVE /NMT_MS_NOT_ACTIVE
NMT_CS_PRE_OPERATIONAL_1 /NMT_MS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2 /NMT_MS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATE /NMT_MS_READY_TO_OPERATENMT_CS_OPERATIONAL /NMT_MS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNETNMT_CS_NOT_ACTIVE /NMT_MS_NOT_ACTIVE
NMT_CS_PRE_OPERATIONAL_1 /NMT_MS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2 /NMT_MS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATE /NMT_MS_READY_TO_OPERATENMT_CS_OPERATIONAL /NMT_MS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNETNMT_CS_NOT_ACTIVE /NMT_MS_NOT_ACTIVE
NMT_CS_PRE_OPERATIONAL_1 /NMT_MS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2 /NMT_MS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATE /NMT_MS_READY_TO_OPERATENMT_CS_OPERATIONAL /NMT_MS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNET

Plain NMT state commands

Destination state
NMT_CS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_PRE_OPERATIONAL_2
NMT_CS_PRE_OPERATIONAL_2
NMT_GS_INITIALISATION
sub-state
NMT_GS_RESET_APPLICATION

NMT_GS_INITIALISATION
sub-state
NMT_GS_RESET_COMMUNICATION

NMT_GS_INITIALISATION
sub-state
NMT_GS_RESET_CONFIGURATION

NMT_GS_INITIALISATION
sub-state NMT_GS_INITIALISINGEPSG DS 301 V1.5.1-262-

All commands listed in Tab. 125 are mandatory. The commands shall be only acted on if the CN is in
the appropriate initial state (see Tab. 125); otherwise the command is ignored and an entry made in
the CN error log.

7.3.1.2.1.1

NMT Reset Commands to the MN

NMTSwReset, NMTResetNode, NMTResetConfiguration and NMTResetCommunication addressed to
the MN as unicast may be requested by a diagnostic node (refer 7.3.6). Since MN resets will affect thecomplete network they shall be forwarded to all nodes. The requested command shall be performedby the MN in the following way:
1. route the command to all CNs.
2. perform the requested reset.

7.3.1.2.2

Extended NMT State Command

Extended NMT State Commands are used to access groups of CNs.
The Asnd frame transporting the command is broadcast to all CNs.
The “NMTCommand Specific Data” field contains a POWERLINK Node List according to the
POWERLINK Node List Format (see 7.3.1.2.3). The POWERLINK Node List indicates the validity of
the command for the individual nodes (i.e. whether the node acts on the command). Node IDs towhich the command is addressed are indicated by 1b. Nodes that have to ignore the command are
indicated by 0b.
Tab. 126 lists the Extended NMT State Commands. Initial State, Destination State and the validity of
the commands at the initial states are identical to the respective plain commands (see Tab. 125).
NMTCommandID

M/O

NMTStartNodeEx
NMTStopNodeEx
NMTEnterPreOperational2Ex
NMTEnableReadyToOperateEx
NMTResetNodeEx
NMTResetCommunicationEx
NMTResetConfigurationEx
NMTSwResetEx

O
O
O
O
O
O
O
O

Extended NMT state commands
Support of Extended NMT State Commands is optional. Support shall be indicated by the object
dictionary index NMT_FeatureFlags_U32 Bit 5 and D_NMT_ExtNmtCmds_BOOL. The Flags don’t
differentiate particular Extended NMT State Commands. They indicate support of all Extended NMT
State Commands defined by this specification.

7.3.1.2.3

POWERLINK Node List Format

The POWERLINK Node List is transmitted by the NMTCommandData field.
The POWERLINK Node List format assigns one bit for each POWERLINK Node ID. The Node ID
assignment is given in Tab. 127.

EPSG DS 301 V1.5.1-263-

Octet offset 25

Bit offset
7
6

5

4

3

2

1

0

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

7
15
23
31
39
47
55
63
71
79
87
95
103
111
119
127
135
143
151
159
167
175
183
191
199
207
215
223
231
239
247
-

5
13
21
29
37
45
53
61
69
77
85
93
101
109
117
125
133
141
149
157
165
173
181
189
197
205
213
221
229
237
245
253

4
12
20
28
36
44
52
60
68
76
84
92
100
108
116
124
132
140
148
156
164
172
180
188
196
204
212
220
228
236
244
252

3
11
19
27
35
43
51
59
67
75
83
91
99
107
115
123
131
139
147
155
163
171
179
187
195
203
211
219
227
235
243
251

2
10
18
26
34
42
50
58
66
74
82
90
98
106
114
122
130
138
146
154
162
170
178
186
194
202
210
218
226
234
242
250

1
9
17
25
33
41
49
57
65
73
81
89
97
105
113
121
129
137
145
153
161
169
177
185
193
201
209
217
225
233
241
249

8
16
24
32
40
48
56
64
72
80
88
96
104
112
120
128
136
144
152
160
168
176
184
192
200
208
216
224
232
240
248

6
14
22
30
38
46
54
62
70
78
86
94
102
110
118
126
135
142
150
158
166
174
182
190
198
206
214
222
230
238
246
254

POWERLINK node list: Node ID to bit assignment

7.3.2

NMT Managing Command Services

The MN uses NMT Managing Command Services to configure NMT-relevant entries in the databaseof the CN. These commands do not directly influence the state machine of the CN.
NMT Managing Commands are transmitted in an ASnd frame by the MN. They are unicast to a single
CN or broadcast to all CNs (using the POWERLINK broadcast address C_ADR_BROADCAST).
The services are identified by ASnd ServiceID set to NMT_COMMAND.
Fig. 79 shows the protocol used to implement the NMT Managing Command Services.

25 Octet offset is measured from the beginning of NMTCommandData. The offset relative to the

Ethernet frame is 20 octets.

EPSG DS 301 V1.5.1-264-

NMT Managing Command
MN

CN(s)
ASnd

requestFig. 79.

indication(indication)(indication)(ServiceID =NMT_COMMAND)NMT managing command service protocol

The ASnd ServiceID value of NMT Managing Command Services is NMT_COMMAND. The specific
NMT Managing Command identification and its data are located in the ASnd Payload field.
Field

Abbr.

NMTCommandID
cid
NMTCommandData cdat

Description

Value

qualifies the NMT Managing Command.
0..C_DLL_MAX_PAYL_OFFSET – 6 octets of NMT
managing command-specific data to be issued by the MN.
The lower layers are responsible for padding.

Tab. 129NMT Service Slot fields of NMT managing command services
The following NMT Managing Command Services are defined:
NMTCommandID

M/O

Short description

NMTNetHostNameSet
NMTFlushArpEntry

O
O

Sets hostname of an individual CN.
Clears local MAC and IP address list at all CNs.

NMT managing command services
Support of particular NMT Managing Command Services shall be indicated by specific device
description entries (see 7.3.2.1.1, 7.3.2.1.2)

7.3.2.1

Service Descriptions

7.3.2.1.1

NMTNetHostNameSet

NMTNetHostNameSet sets the hostname of the CN.
NMTCommandID is NMTNetHostNameSet.
Octet offset 26

7

6

5

0 .. 31

Bit Offset
4
3

2

1

0

HostName
NMTCommandData structure of NMTNetHostNameSet

Field

Abbr.

Description

HostNamehn

May be used to modify CN’s local DNS hostname

Value

NMTCommandData data fields of NMTNetHostNameSet
The NMTNetHostNameSet command is addressed unicast to an individual CN.
After execution of NMTNetSetHostName command, the modified hostname is published by the CN.
Publishing is carried out in the following manner:
1.
The CN indicates an ASnd Transmission Request using the RS bits of the Pres frame or a
StatusResponse ASnd frame using the priority level C_DLL_ASND_PRIO_NMTRQST.
2.
The MN assigns the asynchronous phase to the CN via an SoA frame. (RequestedServiceID =NMT_REQUEST_INVITE).

26 Octet offset is measured from the beginning of NMTCommandData. The offset relative to the

Ethernet frame is 20 octets.

EPSG DS 301 V1.5.1
3.
4.
5.

-265-

The CN requests an IdentRequest to itself using the NMTRequest ASnd frame (see 7.3.6).
The MN transmits an SoA (RequestedServiceID = IDENT_REQUEST) to the requesting CN.
The CN publishes its modified HostName via an IdentResponse ASnd frame.

Support shall be indicated by D_NMT_NetHostNameSet_BOOL.

7.3.2.1.2

NMTFlushArpEntry

NMTFlushArpEntry removes the entries for a CN from the address tables of all other CNs. The entry
to be eliminated is indicated by the Node ID of the CN to be removed.
NMTCommandID is NMTFlushArpEntry.
Octet offset 27

7

6

5

0

Bit Offset
4
3

2

1

0

Node ID
NMTFlushArpEntry ASnd service slot structure

Field

Abbr.

Description

Value

Node ID

nid

Identifies the node whose ARP entry is to be deleted. Using
C_ADR_BROADCAST flushes all ARP entries.

NMTCommandData data fields of NMTFlushArpEntry
The NMTFlushArpEntry command is broadcast to all CNs.
Support shall be indicated by D_NMT_FlushArpEntry_BOOL.

7.3.3

NMT Response Services

NMT Response Services are used by the MN to query NMT information from the CN, e.g. current
state, error and setup data.

7.3.3.1

NMT State Response

The CNs shall signal their state to the MN via NMT State Response services.
CNs that communicate isochronously via PReq / PRes shall use the PRes frame to indicate theircurrent state.
Fig. 80 shows the protocol used to implement the NMT State Response Service from isochronously
communicating CNs. The service is mandatory on the MN and every CN device, that is able tocommunicate isochronously.
NMT State Response
CN

MN
requestconfirmation(iso chr. )PReq

indicationPRes

responseCN(s)Fig. 80.

NMT state response service protocol (isochronous CN)

The MN shall receive the NMT State Response. CNs may receive NMT State Response if configured
to do so.
CNs which do not communicate isochronously (i.e. Async-only CNs or ioschronous CNs in state
NMT_CS_PRE_OPERATIONAL_1) shall signal their state via StatusResponse and IdentResponse
27

Octet offset is measured from the beginning of NMTCommandData. The offset relative to the
Ethernet frame is 20 octets.

EPSG DS 301 V1.5.1-266-

ASnd frames. Isochronous CNs in NMT_CS_PRE_OPERATIONAL_2,

NMT_CS_READY_TO_OPERATE or NMT_CS_OPERATIONAL may be triggered by the MN to
respond via StatusResponse and IdentResponse ASnd frames.
Fig. 81 shows the protocol used to implement the NMT Response Service from CNs that are notcommunicating isochronously. The service is mandatory on the MN and every CN device.
NMT State ResponseCNMN(a sync .)SoArequest(RequestedServiceID =STATUS_REQUEST /IDENT_REQUEST)

confirmation(ServiceID =STATUS_RESPONSE /IDENT_RESPONSE)

ASnd

indication

responseCN(s)Fig. 81.

NMT state response service protocol (async-only CN)

The MN shall receive the NMT State Response. CNs may receive the NMT State Response if
configured to do so and if the NMT State Response is transmitted via an IdentResponse ASnd frame.
NMT State Response shall use the following data fields of the PRes, StatusResponse or
IdentResponse frames:•

NMTState
NMTState shall report the current NMT state of the CN.
If the NMT state reponse requesting message triggers a CN NMT state transition, the pretransition state shall be reported. No response shall be issued if the CN is in state
NMT_CS_NOT_ACTIVE when receiving the request.

•

Exception New (EN)EN shall report unread entries at the CN emergency queue (see 6.5.2).

•

Exception Clear (EC)EC shall be used by Error Signaling management (see 6.5.2). EC shall be operated by
StatusResponse and IdentResponse only.
Refer to 4.6.1.1.4, 7.3.3.2.1 and 7.3.3.3.1 for detailed information about frame format.

7.3.3.2

IdentResponse Service
IdentResponse

MN
requestconfirmation

CN
SoA(RequestedServiceID =IDENT_REQUEST)

ASnd(ServiceID =IDENT_RESPONSE)

indication

responseCN(s)Fig. 82.

IdentResponse service protocol

EPSG DS 301 V1.5.1-267-

The IdentResponse service is used by the MN to identify configured but unrecognized CNs at systemstartup or after loss of communication. The service may be used after start-up to query a CN’s setup
information.
Fig. 82 shows the protocol that is used to implement the IdentResponse service. The service ismandatory on the MN and every CN device.
ASnd frames transporting IdentResponses are broadcast. The MN shall receive IdentResponses; CNs
may receive IdentResponses if configured to do so.
The IdentResponse service may be initiated by a CN via the NMT Request mechanism (see 7.3.6).
The NMTRequestedCommandID field of the NMT requesting ASnd frame shall be set to
IDENT_REQUEST.

7.3.3.2.1

IdentResponse FrameThe IdentResponse service frames are identified by ASnd ServiceID set to IDENT_RESPONSE.
Octet Offset 28

0
1
2
3
4
5
6 .. 910 .. 11
12 .. 13
14 .. 15
16 .. 19
20 .. 21
22 .. 25
26 .. 29
30 .. 33
34 .. 37
38 .. 41
42 .. 49
50 .. 53
54 .. 57
58 .. 61
62 .. 65
66 .. 69
70 .. 73
74 .. 77
78 .. 109110 .. 157

7

res
res
res29 res30

5

res

Bit Offset
4
3

res resPR
NMTState

2

1

0

res

res
RS

res

Reserved

EPLVersion
Reserved
FeatureFlags
MTU
PollInSize
PollOutSize
ResponseTime
Reserved
DeviceType
VendorID
ProductCode
RevisionNumber
SerialNumber
VendorSpecificExtension1
VerifyConfigurationDate
VerifyConfigurationTime
ApplicationSwDate
ApplicationSwTime
IPAddress
SubnetMask
DefaultGateway
HostName
VendorSpecificExtension2
NMT Service Slot structure of IdentResponse

28 Octet Offset is measured from the begin of the ASnd Payload field. The offset relative to thebeginning of the Ethernet frame is 18 octets.
29 Used by EPSG DS302-A [1]30 Used by EPSG DS302-A [1]EPSG DS 301 V1.5.1
Field

Abbr

Priority

PR

RequestToSend

NMTState
EPLVersion

FeatureFlags
MTU

PollInSize
PollOutSize
ResponseTime

DeviceType
VendorID
ProductCode
RevisionNumber
SerialNumber
VendorSpecificExtension1
VerifyConfigurationDate
VerifyConfigurationTime
ApplicationSWDate

ApplicationSWTime

IPAddress
SubnetMask
DefaultGateway
HostName

Description

-268-

Value

Flags: Indicates the priority of the requested
asynchronous frame.
(see 4.2.4.1.2.3)
Flags: Indicates the number of pending requests toRS
0 – C_DLL_MAX_RS
send at the CN. The value C_DLL_MAX_RS indicates
C_DLL_MAX_RS or more requests, 0 indicates nopending request.
stat Reports the current status of the CN’s NMT statemachine.
eplv Indicates the POWERLINK Version to which the CN
conforms.
coding of entry (see Tab. 112)feat Reports the device’s feature flags(NMT_FeatureFlags_U32)
C_DLL_MIN_ASYNC_MTU –mtu Reports the largest packet-size of the ISO/OSI
network layer that can be transmitted over the
C_DLL_MAX_ASYNC_MTU
network. See
NMT_MNCycleTiming_REC.AsyncMTU_U16
pis
Reports the actual CN setting for Preq data block size
(NMT_CycleTiming_REC.PreqActPayloadLimit_U16).
pos Reports the actual CN setting for Pres data block size
(NMT_CycleTiming_REC.PresActPayloadLimit_U16).
rst
Reports the time required by the CN to respond to
Preq(NMT_CycleTiming_REC.PresMaxLatency_U32).
Reports the CN’s Device typedt
(NMT_DeviceType_U32).
Reports the CN’s Vendor ID, index
vid(NMT_IdentityObject_REC.VendorId_U32)
prdc Reports the CN’s Product Code, index(NMT_IdentityObject_REC.ProductCode_U32)
Reports the CN’s Revision Number,rno(NMT_IdentityObject_REC.RevisionNo_U32).
sno Reports the CN’s Serial Number,(NMT_IdentityObject_REC.SerialNo_U32).
vex1 May be used for vendor specific purpose, to be filledwith zeros if not in use.
vcd Reports the CN’s Configuration date
(CFM_VerifyConfiguration_REC.ConfDate_U32).
Reports the CN’s Configuration time
vct
(CFM_VerifyConfiguration_REC.ConfTime_U32).
ad
Reports the CN’s Application SW date
(PDL_LocVerApplSw_REC.ApplSwDate_U32 on
programmable device or date portion of
NMT_ManufactSwVers_VS on non-programmabledevice).
at
Reports the CN’s Application SW time
(PDL_LocVerApplSw_REC.ApplSwTime_U32 on
programmable device ortime portion of NMT_ManufactSwVers_VS on nonprogrammable device).
ipa
Reports the current IP address value of the CN(NWL_IpAddrTable_Xh_REC.Addr_IPAD).
snm Reports the current IP subnet mask value of the CN(NWL_IpAddrTable_Xh_REC.NetMask_IPAD).
gtw Reports the current IP default gateway value of the
CN (NWL_IpAddrTable_Xh_REC.DefGateway_IPAD).
hn
Reports the current DNS hostname of the CN(NMT_HostName_VSTR).
Unused bytes of the hostname shall be set to 0h in the
IdentResponse.

EPSG DS 301 V1.5.1

-269-

Field

Abbr

Description

Value

VendorSpecificExtension2

vex2 May be used for vendor specific purpose, to be filledwith zeros if not in use.

NMT Service Slot data fields of IdentResponse
If the respective object dictionary entry is not implemented by the device, the data field shall be set to
0 resp. empty string.

7.3.3.3

StatusResponse Service

The StatusResponse service is used by the MN to query the current status of CNs that are notcommunicating isochronously.
Fig. 83 shows the protocol used to implement the StatusResponse Service. The service is mandatoryon the MN and every CN device.
ASnd frames transporting StatusResponses are broadcast. The MN shall receive StatusResponses;
CNs may receive StatusResponses if configured to do so.
The StatusResponse service can be initiated by a CN via the NMT Request mechanism (7.3.6). The
NMTRequestedCommandID entry of the NMT requesting ASnd frame is set to STATUS_REQUEST.
StatusResponse
MN

CN
SoA

request(RequestedServiceID =STATUS_REQUEST)

ASnd

confirmation(ServiceID =STATUS_RESPONSE)

indication

responseCN(s)Fig. 83.

StatusResponse service protocol

7.3.3.3.1

StatusResponse Frame

The StatusResponse service frames are identified by ASnd ServiceID set to STATUS_RESPONSE.
Octet offset 31

7

6

5

0
1
2
3 .. 56 .. 13
14 .. 14+n*20

res
res32

res
res33

res

Bit Offset
4
3

2

EN
EC
res
PR
NMTState
Reserved
StaticErrorBitField
List of Errors / Events (see 6.5.8)
20 Byte / Entry , minimum n=2

1

0

res
RS

res

n (2-14) : Number of error/event entries

NMT Service Slot structure of StatusResponse

31 Octet Offset is measured from the begin of the ASnd Payload field. The offset relative to thebeginning of the Ethernet frame is 18 octets.
32 Used by EPSG DS302-A [1]33 Used by EPSG DS302-A [1]EPSG DS 301 V1.5.1

-270-

Field

Abbr

Description

ExceptionNew
ExceptionClear
Priority

EN
EC
PR

RequestToSend

RS

NMTState

stat

Flag: Error signaling (see 6.5.2).
Flag: Error signaling (see 6.5.2).
Flags: indicates the priority of the requested
asynchronous frame. (see 4.2.4.1.2.3).
Flags: indicates the number of pending requests tosend at the CN. The value C_DLL_MAX_RS indicates
C_DLL_MAX_RS or more requests, 0 indicates nopending request.
Reports the current status of the CN’s NMT statemachine.
Specific bits are set to indicate pending errors at theCN(see 6.5.8.1 for encoding of errors in the bit field).
Contains a list of errors, that have occurred at the CN.
Each Error Code has a size of 20 octets (see 6.5.8.2).
The lower layer is responsible for padding.
Maximum size of ErrorCodeList is device specific. It is
indicated by D_NMT_ErrorEntries_U32.

StaticErrorBitfield seb

ErrorCodeList

el

Value

0–
C_DLL_MAX_RS

NMT Service Slot data fields of StatusResponse

7.3.4

NMT Info Services

NMT Info Services are used to transmit complex status information in the form of bundles as well as todistribute system-relevant setup information from the MN to the CNs.
All NMT Info services are transmitted via ASnd by the MN.
The target CNs are unicast via the ASnd Destination field to one CN or broadcast to all CNs.
NMT Info Services are identified by ASnd ServiceID = NMT_COMMAND.
Fig. 84 shows the protocol used to implement the NMT Info services.
NMT Info
MN

CN(s)
ASnd

request(ServiceID =NMT_COMMAND)

Fig. 84.

NMT info service protocol

indication(indication)(indication)

The particular NMT Info services including their data are located in the NMT Service Slot.
The NMT Info Services use the following parameters of the NMT Service slot:
Field

Abbr.

NMTCommandID
cid
NMTCommandData cdat

Description

Value

qualifies the NMT Info service.
0..C_DLL_MAX_PAYL_OFFSET – 4 octets of NMT Info
Service-specific data to be issued by the MN.
The lower layers are responsible for padding.

Tab. 139NMT Service Slot data fields of NMT managing info services
The following NMT Info services are defined:EPSG DS 301 V1.5.1
NMTCommandID-271-

Producer
MN CN

Consumer
MN CN

NMTPublishConfiguredNodes

Y

Y

Y

Y

NMTPublishActiveNodes

Y

N

Y

Y

NMTPublishPreOperational1

Y

N

Y

Y

NMTPublishPreOperational2

Y

N

Y

Y

NMTPublishReadyToOperate

Y

N

Y

Y

NMTPublishOperational

Y

N

Y

Y

NMTPublishStopped

Y

N

Y

Y

NMTPublishNodeStates
NMTPublishEmergencyNew

Y
Y

N
N

Y
Y

Y
Y

NMTPublishTime

Y

Y

Y

Y

Short description

Provides CNs declared in the configuration of
the MN.
Provides CNs that have been identified by
the MN.
Provides active CNs in the state
NMT_CS_PRE_OPERATIONAL_1.
Provides active CNs in the state
NMT_CS_PRE_OPERATIONAL_2.
Provides CNs in the state
NMT_CS_READY_TO_OPERATE.
Provides CNs in the state
NMT_CS_OPERATIONAL.
Provides CNs in the state
NMT_CS_STOPPED.
Provides current NMT states
Provides active CNs with the exception new
flag (EN) set.
Provides the system time.

NMT info services
In the object dictionary support shall be indicated by Index NMT_FeatureFlags_U32 Bit 4. The flags do
not differentiate particular NMT Info Services. They indicate support of at least one NMT Info Services
defined by this specification.
Support of particular NMT Info Services shall be indicated by specific device description entries (see7.3.4.1.1 to 7.3.4.1.10).

7.3.4.1

Service Descriptions

7.3.4.1.1

NMTPublishConfiguredNodes

Using the NMTPublishConfiguredNodes service, the MN or a CN may publish a list of nodes
configured in its configuration.
The NMTPublishConfiguredNodes service uses the POWERLINK Node List format (see 7.3.1.2.3).
Node IDs that correspond to configured CNs are indicated by 1b.
Information to be published is obtained from NMT_NodeAssignment_AU32 sub-index Bit 1.
Support shall be indicated by D_NMT_PublishConfigNodes_BOOL.

7.3.4.1.2

NMTPublishActiveNodes

Using the NMTPublishActiveNodes service, the MN may publish a list of the active nodes.
Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices. CNs in thestates NMT_CS_PRE_OPERATIONAL_1, NMT_CS_PRE_OPERATIONAL_2,
NMT_CS_READY_TO_OPERATE, NMT_CS_OPERATIONAL and NMT_CS_STOPPED are
regarded active.
The NMTPublishActiveNodes service uses the POWERLINK Node List format (see 7.3.1.2.3). NodeIDs that correspond to active CNs are indicated by 1b.
The MN itself is regarded to be ever active.
Support shall be indicated by D_NMT_PublishActiveNodes_BOOL.

7.3.4.1.3

NMTPublishPreOperational1

Using the NMTPublishPreOperational1 service, the MN may publish a list of nodes in the state
NMT_CS_PRE_OPERATIONAL_1 resp. NMT_MS_PRE_OPERATIONAL_1.
The NMTPublishPreOperational1 service uses the POWERLINK Node List format (see 7.3.1.2.3).
Node IDs that correspond to active nodes in the state NMT_CS_PRE_OPERATIONAL_1 or
NMT_MS_PRE_OPERATIONAL_1 are indicated by 1b.

EPSG DS 301 V1.5.1-272-

Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices.
Support shall be indicated by D_NMT_PublishPreOp1_BOOL.

7.3.4.1.4

NMTPublishPreOperational2

Using the NMTPublishPreOperational2 service, the MN may publish a list of nodes in the state
NMT_CS_PRE_OPERATIONAL_2 resp. NMT_MS_PRE_OPERATIONAL_2.
The NMTPublishPreOperational2 service uses the POWERLINK Node List format (see 7.3.1.2.3).
Node IDs that correspond to active nodes in the state NMT_CS_PRE_OPERATIONAL_2 or
NMT_MS_PRE_OPERATIONAL_2 are indicated by 1b.
Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices.
Support shall be indicated by D_NMT_PublishPreOp2_BOOL.

7.3.4.1.5

NMTPublishReadyToOperate

Using the NMTPublishReadyToOperate service, the MN may publish a list of nodes in the state
NMT_CS_READY_TO_OPERATE resp. NMT_MS_READY_TO_OPERATE.
The NMTPublishReadyToOperate service uses the POWERLINK Node List format (see 7.3.1.2.3).
Node IDs that correspond to active nodes in the state NMT_CS_READY_TO_OPERATE or
NMT_MS_READY_TO_OPERATE are indicated by 1b.
Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices.
Support shall be indicated by D_NMT_PublishReadyToOp_BOOL.

7.3.4.1.6

NMTPublishOperational

Using the NMTPublishOperational service, the MN may publish a list of nodes in the state
NMT_CS_OPERATIONAL resp. NMT_MS_OPERATIONAL.
The NMTPublishOperational service uses the POWERLINK Node List format (see 7.3.1.2.3). NodeIDs that correspond to active CNs in the state NMT_CS_OPERATIONAL or
NMT_MS_OPERATIONAL are indicated by 1b.
Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices.
Support shall be indicated by D_NMT_PublishOperational_BOOL.

7.3.4.1.7

NMTPublishStopped

Using the NMTPublishStopped service, the MN may publish a list of CNs in the state
NMT_CS_STOPPED.
The NMTPublishStopped service uses the POWERLINK Node List format (see 7.3.1.2.3). Node IDs
that correspond to active CNs in the state NMT_CS_STOPPED are indicated by 1b.
Information to be published is obtained from NMT_MNNodeCurrState_AU8 sub-indices.
Support shall be indicated by D_NMT_PublishStopped_BOOL.

7.3.4.1.8

NMTPublishNodeStates

Using the NMTPublishNodeStates service, the MN may publish the current NMT states of the
POWERLINK nodes as listed in NMT_MNNodeCurrState_AU8 (7.2.2.4.1).
Octet Offset 34

0
1 .. 254

7

6

5

Bit Offset
4
3

2

1

0

reserved
NMTState
NMTCommandData structure of NMTPublishNodeStates

Field

Abbr.

Description

NMTState

stat

Current NMT state of POWERLINK Nodes
Octet Offset = POWERLINK Node ID

Value

NMTCommandData data fields of NMTPublishNodeStates
34 Octet offset is measured from the beginning of NMTCommandData. The offset relative to the

Ethernet frame is 20 octets.

EPSG DS 301 V1.5.1-273-

The octet offset not corresponding to a node configured by index NMT_NodeAssignment_AU32[subindex] Bits 1 and 2 shall be set to NMT_GS_OFF.
Support shall be indicated by D_NMT_PublishNodeState_BOOL.

7.3.4.1.9

NMTPublishEmergencyNew

Using the NMTPublishEmergencyNew service, the MN may publish a list of nodes with the Exception
New flag (EN) set.
The NMTPublishEmergencyNew service uses the POWERLINK Node List format (see 7.3.1.2.3).
Node IDs that correspond to nodes with the EN flag set are indicated by 1b.
Support shall be indicated by D_NMT_PublishEmergencyNew_BOOL.

7.3.4.1.10

NMTPublishTime

Using the NMTPublishTime service, the MN or a CN publishes date and time.
Octet Offset 35

0 .. 57

6

5

Bit Offset
4
3

2

1

0

DateTime
NMTCommandData structure of NMTPublishTime

Field

Abbr.

DateTime dt

Description

Value

Current RTC time value of the MN coded as TIME_OF_DAY.

NMTCommandData data fields of NMTPublishTime
Support shall be indicated by D_NMT_PublishTime_BOOL

7.3.5

NMT Guard Services

MN and CNs may detect failures in an Ethernet POWERLINK-based network using NMT Guard
Services. NMT Guard services are optional.
Local errors in a node may for example lead to a reset or change of state. The definition of such local
errors is not within the scope of this specification.

7.3.5.1

Guarding CNs

Ethernet POWERLINK may use a guard mechanism to monitor nodes. The MN queries the CNs andreceives their replies.
In order to query isochronously-addressed CNs in the POWERLINK Mode, the guard mechanism uses
the ioschronous PReq / PRes message exchange.
The supervising node monitors the reception of PRes frames from the monitored node. If the PRes
frames do not arrive in time, the supervising node informs its application.
Due to the multicast transmission of the PRes frame, CNs are able to monitor other CNs.
If the MN transmits PRes, it may be monitored by the CNs too.
The monitoring time is configurable via the object dictionary entry
NMT_ConsumerHeartbeatTime_AU32.

7.3.5.1.1

Guarding Async-Only CNs

An asynchronous channel is allocated to nodes which are not addressed isochronously. They are
queried by the MN via a StatusRequest SoA telegram and respond with a StatusResponse ASnd
message. If no StatusResponse is received within the monitoring time, the MN informs its application.
The guarded CN is the only one that receives the StatusRequest, other CNs shall ignore it. They shallnot rely on a StatusRequest frequency satisfying their guard time requirements regarding therespective CN. That’s why, no guarding of async-only CNs by other CNs is possible.
Hint: StatusRequest and StatusResponse transmission is affected by the asynchronous schedulingmechanism. The timing severely influenced by the sum of asynchronous transmission requests in the
35 Octet offset is measured from the beginning of NMTCommandData. The offset relative to the

Ethernet frame is 20 octets.

EPSG DS 301 V1.5.1-274-

system. That’s why, NMT_ConsumerHeartbeatTime_AU32 of async-only CNs shall be set to large
values.

7.3.5.2

Guarding the MN

The CNs may control the function of the MN by timeout-monitoring the SoC frames (see 7.3.1.1). If a
CN does not receive any frames, it changes to the state NMT_CS_PRE_OPERATIONAL_1. Thistransition is signalled to the CN’s application.

7.3.6

Request NMT Services by a CN

A CN may request the execution of explicit NMT State Commands, NMT Management Commands,
NMT Info Services, IdentResponse and StatusResponse services at the MN.
1. The CN indicates an NMTRequest using the RS bits of the PRes frame or a StatusResponse ASnd
Frame using the priority level C_DLL_ASND_PRIO_NMTRQST.
2. The MN assigns the asynchronous phase to the CN via SoA (RequestedServiceID =NMT_REQUEST_INVITE).
3. The CN requests the desired service using the ASnd NMTRequest frame (ServiceID =NMT_REQUEST).
The service is mandatory on the MN.

7.3.6.1

NMTRequest Frame

NMTRequests are transmitted by a CN via ASnd upon assignment of the asynchronous phase via an
NMTRequestInvite SoA frame.
The NMTRequest frames are identified by ASnd ServiceID = NMT_REQUEST.
Octet offset 36

70
12 .. n6

5

Bit Offset
4
3

2

1

0

NMTRequestedCommandID
NMTRequestedCommandTarget
NMTRequestedCommandDatan ≤ C_DLL_MAX_PAYL_OFFSET – 4

NMT Service Slot structure of NMTRequest
Field

Abbr.

Description

NMTRequestedCommandID

rcid

The NMT service to be issued by the MN by its
NMTCommandID value.
StatusResponse and IdentResponse services are indicated by
the SoA RequestedServiceID values STATUS_REQUEST
and IDENT_REQUEST.
Indicates the target node of the requested NMT command.

NMTRequested- rct
CommandTarget
NMTRequested- rcd
CommandData

Value

0..C_DLL_MAX_PAYL_OFFSET – 6 octets of NMT commandspecific data to be issued by the MN.
The lower layers are responsible for padding.

NMT Service Slot data fields of an NMTRequest frame
The NMTRequest ASnd frame is unicast to the MN.

7.3.6.1.1

Invalid NMTRequests

If the CN requests an NMT service not supported by the MN, the MN responds with a unicast ASndframe with ServiceID = NMT_COMMAND to the requesting CN.
The NMTCommandID NMTInvalidService is used:

36

Octet offset is measured from the begin of the ASnd Payload field. The offset relative to thebeginning of the Ethernet frame is 18 octets.

EPSG DS 301 V1.5.1-275-This special service is mandatory. It must not influence the state machine of the CNs and must nottransport any data to the CN.

7.3.7

NMT Services via Object Dictionary

7.3.7.1

NMT Reset Commands

The NMT Command Services NMTSwReset, NMTResetNode, NMTResetConfiguration, andNMTResetCommunication may be initiated by writing the respective NMTServiceID to
NMT_ResetCmd_U8.
NMT Reset via NMT_ResetCmd_U8 should be applied to CNs in NMT_CS_BASIC_ETHERNET only.
If applied to nodes in NMT_CS_EPL_MODE or NMT_MS_EPL_MODE, resets by
NMT_ResetCmd_U8 may violate the NMT rules and stimulate DLL and NMT Guarding errors. Use
NMT Request via Object Dictionary (see 7.3.7.2) instead.

7.3.7.2

NMT Requests to the MN

NMT Requests may be posted to the MN by writing to NMT_RequestCmd_REC.
The objects sub-indices shall be mapped to the NMT Service Slot of a virtual NMTRequest Frame(see 7.3.6.1):
NMT_RequestCmd_REC.CmdID_U8→
NMTRequested-CommandID
NMT_RequestCmd_REC.CmdTarget_U8→
NMTRequested-CommandTarget
NMT_RequestCmd_REC.CmdData_DOM→
NMTRequested-CommandData
The NMT Request shall be triggered by writing TRUE to NMT_RequestCmd_REC.Release_BOOL.
The NMT Services via Object Dictionary mechanism does not provide a response channel. Therefore,
only Explicit NMT State Command Services (see 7.3.1.2) may by requested via Object Dictionary.

7.3.8

NMT Services via UDP/IP

NMT requests coming from a diagnostic node outside of the POWERLINK segment via a router may
be hosted by UDP/IP frames. Hosting shall be in accordance to the POWERLINK compliant UDP/IP
format (see 4.6.1.2).
The NMT Services via UDP/IP mechanism does not provide a response channel. Therefore, only
Explicit NMT State Command Services (see 7.3.1.2) may by requested via UDP/IP.
Support of NMT Services via UDP/IP by an MN is optional. Support shall be indicated by object
dictionary entry NMT_FeatureFlags_U32 Bit 7 and D_NMT_ServiceUdpIp_BOOL.

EPSG DS 301 V1.5.1

-276-

7.4

Boot-up Managing Node

7.4.1

NMT_MS dependant Network Boot-up

7.4.1.1

Overview

When a POWERLINK Node starts after PowerOn (NMT_GT1), Reset (NMT_GT2) or NMTSwReset(NMT_GT8), the state machine will begin to execute according to the NMT state diagram of a
POWERLINK node (see 7.1.2) and will attain the NMT_GS_INITIALISATION state automatically. Aftercompletion of the initialisation, the node will enter the super state NMT_GS_COMMUNICATING. In
this super state the node will perform as either a Managing Node (MN) or Controlled Node (CN)depending on the configured Node ID. The state NMT_GS_INITIALISATION is reachable from every
state within the super state after processing the NMT command service NMTResetNode (NMT_GT4),
NMTResetCommunication (NMT_GT5), NMTResetConfiguration (NMT_GT7), NMTSwReset(NMT_GT8) or after internal errors (NMT_GT6).

7.4.1.2

NMT_MS_NOT_ACTIVE

There shall be only one active MN on a POWERLINK network.The purpose of the state
NMT_MS_NOT_ACTIVE is to enable a potential MN to detect whether the bus is already managed byanother MN.
Detecting SoC or SoA during this state indicates to the potential MN that the network already has anactive MN.
The state NMT_MS_NOT_ACTIVE is entered from the NMT_GS_INITIALISATION state (NMT_MT1).
Enter State„NMT_MS_NOT_ACTIVE“
from„NMT_GS_INITIALISATION“

NMT_MT1

NMT_MS_NOT_ACTIVE

NMT_BootTime_REC.MnWaitNotAct_U32

Check bus activity

SoA/ SoC
received

Inform application
Error status E_NMT_BA1
Halt network boot-up procedure

Timeout

NMT_MT2

Fig. 85.

Leave State„NMT_MS_NOT_ACTIVE“
to- „NMT_MS_PRE_OPERATIONAL_1“State NMT_MS_NOT_ACTIVEEPSG DS 301 V1.5.1-277-

In the state NMT_MS_NOT_ACTIVE the MN proceeds as follows:•

Check for bus activity. Reception of SoC or SoA frames indicates that another MN is currently
managing the network. In case of the reception of SoA or SoC frames, the error•
E_NMT_BA1(see 7.4.3.1)
shall be signalled to the MN application.
The current MN state shall be maintained. The MN shall halt network boot-up procedure.

•

If the potential MN does not detect either SoC or SoA frames within a time interval defined byindex NMT_BootTime_REC.MNWaitNoAct_U32, it shall transition from
NMT_MS_NOT_ACTIVE to NMT_MS_PRE_OPERATIONAL_1.

7.4.1.3

NMT_MS_PRE_OPERATIONAL_1

In the state NMT_MS_PRE_OPERATIONAL_1 the MN assumes bus master-ship. It will attempt toreach all configured CNs and examine their configuration versions. The MN communicates with the
CN using the Reduced POWERLINK Cycle (SoA and Asnd frames) (see 4.2.4.2). In case ofcommunication errors such as frame losses, the MN signals the error to the application. If the error
was caused by a mandatory node, the MN shall remain in this state.
This state is entered from the NMT_MS_NOT_ACTIVE (NMT_MT2) or the NMT_MS_OPERATIONAL(NMT_MT6) state.
The steps of the network boot process in NMT_MS_PRE_OPERATIONAL_1 are as follows:•

If the state was entered from NMT_MS_NOT_ACTIVE (NMT_MT2), all nodes of the network will
be reset using the NMT command service NMTResetNode.

•

Initiate boot process BOOT_STEP1 for all configured CNs.
Configured CNs are identified by:•

NMT_NodeAssignment_AU32[1..254].Bit0•

NMT_NodeAssignment_AU32[1..254].Bit1•

If mandatory CNs are booted sequentially, the boot process shall not be halted in case of anerror associated with the particular CN. The MN shall continue to attempt to contact all
configured but not responding CNs.

•

If an application SW update of one or more nodes was done, the MN must send out the NMT
command•
NMTSwResetto all CNs and restart the BOOT_STEP1 for all configured CNs.

•

When the BOOT_STEP1 process has been successfully terminated for all mandatory CNs, the
MN may switch to the state NMT_MS_PRE_OPERATIONAL_2
Mandatory CNs are identified by :••NMT_NodeAssignment_AU32[1..254].Bit3

The MN can switch to the state NMT_MS_PRE_OPERATIONAL_2 either automatically or
under control of the application. The transition policy is defined by:•
NMT_StartUp_U32.Bit7.
If the waiting time interval•
NMT_BootTime_REC.MnWaitPreOp1_U32
has not expired, the MN waits in this state until the waiting time expires.

•

If BOOT_STEP1 has not been processed successfully for all mandatory CNs, the MN shallsignal the error•
E_NMT_BPO1(see 7.4.3.2)
to the MN application.
In this case the MN shall halt the network boot-up procedure and maintain its current state.

•

If optional CNs answered with IdentResponse successfully, but could not finish BOOT_STEP1
without errors, the application will be notified. In this case the network boot procedure for theseparticular CNs shall be restarted.

EPSG DS 301 V1.5.1

NMT_MT6-278-

Enter State„NMT_MS_PRE_OPERATIONAL_1“
From„NMT_MS_NOT_ACTIVE“„NMT_MS_OPERATIONAL“

NMT_MT2

NMT_MS_PRE_OPERATIONAL_1

Send NMT command Service
NMT ResetNode to all CNs

Send NMT command Service
NMTSwReset to all CNs
NMT_NodeAssignment_AU32[1..254].Bit0
NMT_NodeAssignment_AU32[1..254].Bit1

CN Boot
Perform BOOT_STEP1
on all CNs

One or more
CN with new Software
No Software Updates

Timeout
BOOT_STEP1 E_NOK

NMT_StartUp_U32.Bit7
All Nodes
BOOT_STEP1 E_OK
Enter
NMT_MS_PRE_
OPERATIONAL_2
from application expected

All mandatory
BOOT_STEP1 E_OK

one and more mandatory
BOOT_STEP1
E_NOK

NMT_NodeAssignment_AU32[1..254].Bit3
Wait for application
Automatically Enter
NMT_MS_PRE_
OPERATIONAL_2
Triggered by application

Inform application
Error status E_NMT_BPO1
Halt network boot- up procedure

Wait for end of
NMT_MS_PRE_OPERATIONAL_1

NMT_BootTime_REC.MNWaitPreOp1_U32

Leave State„NMT_MS_PRE_OPERATIONAL_1“to„NMT_MS_PRE_OPERATIONAL_2“
NMT_MT3

Fig. 86.

7.4.1.4

Detail state NMT_MS_PRE_OPERATIONAL_1

NMT_MS_PRE_OPERATIONAL_2

In the state NMT_MS_PRE_OPERATIONAL_2 the MN will initiate isochronous communication with
the CNs and insure their transition from NMT_CS_PRE_OPERATIONAL_2 to
NMT_CS_READY_TO_OPERATE.
When all mandatory CNs have reached the NMT_CS_READY_TO_OPERATE state, the MN willchange to the state NMT_MS_READY_TO_OPERATE.
In case of an error associated with the mandatory CNs, the MN will signal the error to the application.
In this case the MN shall halt the network boot-up procedure and maintain its current state.
The NMT_MS_PRE_OPERATIONAL_2 state is entered from the NMT_MS_PRE_OPERATIONAL_1(NMT_MT3) state.

EPSG DS 301 V1.5.1-279-

NMT_MT3

Enter State„NMT_MS_PRE_OPERATIONAL_2“from„NMT_MS_PRE_OPERATIONAL_1“
NMT_MS_PRE_OPERATIONAL_2

Start Isochronous
POWERLINK cycle

Timeout and / orBOOT_STEP2 E_NOK

BOOT_STEP2

NMT_NodeAssignment_AU32[1..254].Bit3
All No des
BOOT_STEP2 E_OK

NMT_StartU p_U32.Bit8

All mandatory
BOOT_STEP2
E_OK

Enter
NMT_MS_READ Y_TO_OPERATE
from application expected

one or more mandatory
BOOT_STEP2
E_NOKAutomatically Enter
NMT_MS_READY_TO_OPERATE

Inform application
Error status E_NMT_BPO2
Haltn etwork boot- up procedure

Wait for application

Triggered by application

Leave State„NMT_MS_PRE_OPERATIONAL_2“to„NMT_MS_READY_TO_OPERATE“

Fig. 87.

NMT_MT4

Detail state NMT_MS_PRE_OPERATIONAL_2

The network boot steps and tasks in the NMT_MS_PRE_OPERATIONAL_2 state are as follows:•

Start isochronous POWERLINK Cycle with SoC /SoA frames to synchronise the CNs to the MN
POWERLINK Cycle.

•

Start process BOOT_STEP2 for all configured CNs. Configured CNs are identified by:••

NMT_NodeAssignment_AU32[1..254].Bit0•

NMT_NodeAssignment_AU32[1..254].Bit1

After the BOOT_STEP2 process is successfully terminated for all mandatory CNs (allmandatory CNs are in the NMT_CS_READY_TO_OPERATE state), the MN itself shall switch tothe state NMT_MS_READY_TO_OPERATE direct or after application trigger, depending on thefollowing object:•
NMT_StartUp_U32.Bit8
Mandatory CNs are identified by:•
NMT_NodeAssignment_AU32[1..254].Bit3
In case of errors or timeout condition during the BOOT_STEP2 process of one or more mandatory
CN, the error•
E_NMT_BPO2(see 7.4.3.3)
shall be signaled to the application.
•

Errors of optional CNs in BOOT_STEP2 shall be signaled to the application. The network bootup process for these CNs shall be restarted.

EPSG DS 301 V1.5.1
•

-280-

Keep trying to engage previous boot-up processes for all configured optional CNs.

7.4.1.5

NMT_MS_READY_TO_OPERATENMT_MT4

Enter State „NMT_MS_READY_TO_OPERATE“from- „NMT_MS_PRE_OPERATIONAL_2“
NMT_MS_READY_TO_OPERATECHECK_COMMUNICATIONAll Nodes
CHECK_COMMUNICATION
E_OK

Timeout and / or
CHECK_COMMUNICATION
E_NOK

NMT_NodeAssignment_AU32[1..254].Bit3
All mandatory
CHECK_COMMUNICATION
E_OK
one or more mandatory
CHECK_COMMUNICATION
E_NOK

Enter
NMT_MS_OPERATIONAL
from application expected

NMT_StartUp_U32.Bit2

Automatically enter
NMT_MS_OPERATIONAL
Inform application
Error status E_NMT_BRO
Halt network boot up procedure-

Wait for application

Triggered by application

Leave State„NMT_MS_READY_TO_OPERATE“to- „NMT_MS_OPERATIONAL“
NMT_MT5

Fig. 88.

Detail state NMT_MS_READY_TO_OPERATEThe purpose of the network boot process in NMT_MS_READY_TO_OPERATE state is to start andcheck the isochronous communication with all identified isochronous CNs. The length of theisochronous frames shall be checked against the configured values of
NMT_PresPayloadLimitList_AU16.
If isochronous communication with all mandatory CNs operates correctly, the MN may enter the
NMT_MS_OPERATIONAL state.
In case of communication or configuration errors within one or more mandatory CNs, the MN signals
the error to the application and shall remain in this state.
This NMT state is entered from the NMT_MS_PRE_OPERATIONAL_2 state (NMT_MT4).
In the state NMT_MS_READY_TO_OPERATE the MN proceeds as follows:••

Start process CHECK_COMMUNICATION for all configured CN.
Configured CNs are identified by:•

NMT_NodeAssignment_AU32[1..254].Bit0•

NMT_NodeAssignment_AU32[1..254].Bit1

After the CHECK_COMMUNICATION process is terminated successfully for all mandatory CNs,
the MN shall switch to the state NMT_MS_OPERATIONAL direct or after the application trigger.
The transition policy is defined by:•
NMT_StartUp_U32.Bit2
Mandatory CNs are identified by:

EPSG DS 301 V1.5.1

-281-

•
NMT_NodeAssignment_AU32[1..254].Bit3
If the CHECK_COMMUNICATION process of one or more mandatory CN failed, the error:•
E_NMT_BRO(see 7.4.3.4)
shall be signaled to the application.
The current MN state shall be maintained. The MN shall halt the network boot-up procedure.
•

Errors of optional CNs during the CHECK_COMMUNICATION process shall be signaled to theapplication. The boot process for these CN shall be halted. The restart of the boot-up process
for these CNs may be triggered by the application.

•

Keep trying to engage previous boot processes for all configured optional CNs.

7.4.1.6

NMT_MS_OPERATIONAL

In the state NMT_MS_OPERATIONAL, the MN forces all CNs that are in the state
NMT_CS_READY_TO_OPERATE to the state NMT_CS_OPERATIONAL.
In the NMT_MS_OPERATIONAL state the MN continues isochronous communication with all
identified isochronous CNs.
The MN can force each CN to NMT_CS_OPERATIONAL either individually, with the NMTStartNodeunicast command, or all CNs, with the NMTStartNode broadcast command. After all identified CNs arein the state NMT_CS_OPERATIONAL, the MN shall start the process OPERATIONAL for all identifiedCNs.
In case of communication errors of mandatory nodes, the sub-state ERROR_TREATMENT of the
network boot-up procedure is entered. Finally the MN enters the state
NMT_MS_PRE_OPERATIONAL_1.
The NMT_MS_OPERATIONAL state is entered from the NMT_MS_READY_TO_OPERATE state(NMT_MT5).

EPSG DS 301 V1.5.1

NMT_MT5-282-

Enter State „NMT_MS_OPERATIONAL“from- „NMT_MS_READY_TO_OPERATE“
NMT_MS_OPERATIONAL

NMT_StartUp_U32.Bit1
NMT Start All NodeenabledNMT Start All Nodedisabled

START_CN(individually)

START_ALL

START_CN or START_ALL
E_NOK
NMT_NodeAssignment_AU32[1..254].Bit3
START_CN or
START_ALL
E_OK
all mandatory START_CN or
START_ALL
E_OK

OPERATIONAL

one ormore mandatory START_CN
E_NOK

Error in one ormore mandatory CN

ERROR_TREATMENTNMT_StartUp_U32.Bit12
Enter NMT_MS_PRE_OPERATIONAL_1
not automatical
Wait for application

enableddisabled
Triggered byapplication

Leave State„NMT_MS_OPERATIONAL“to- „NMT_MS_PRE_OPERATIONAL_1“
NMT_MT6

Fig. 89.

Detail state NMT_MS_OPERATIONAL

The network boot steps and tasks of the NMT_MS_OPERATIONAL state are as follows:•

Start process START_ALL or START_CN either for all CNs or individuallydepending on the following object:•
NMT_StartUp_U32.Bit1
Configured CNs are identified by:••

NMT_NodeAssignment_AU32[1..254].Bit0•

NMT_NodeAssignment_AU32[1..254].Bit1,

In case of errors of mandatory nodes during START_CN or START_ALL, the MN shall start the
ERROR_TREATMENT process. Finally the MN enters state NMT_MS_PRE_OPERATIONAL_1
direct or after application trigger, depending on the following object:EPSG DS 301 V1.5.1

-283-

•
NMT_StartUp_U32.Bit12
If START_ALL or START_CN for all mandatory nodes finished successfully, the MN shall enter theboot-up sub-state OPERATIONAL.
•
In case of communication errors during OPERATIONAL of one or more mandatory node, the
MN shall enter the ERROR_TREATMENT sub-state. Finally the MN shall enter
NMT_MS_PRE_OPERATIONAL_1 direct or after the application trigger, depending on thefollowing object:•

NMT_StartUp_U32.Bit12•

Errors of optional CNs during the START_CN, START_ALL or OPERATIONAL process shall besignaled to the application. The boot process for these CN shall be halted. The restart of theboot-up process for these CNs may be triggered by the application.

•

Keep trying to engage previous boot processes for all configured optional CNs.

7.4.2

MN Boot-up Procedure on CN Level

7.4.2.1

Overview

The previous chapter describes how the MN performs the network boot-up. This chapter describes
how the MN manages the boot-up procedure for a single CN.
On network level, optional and mandatory CNs are handled differently. On CN level the handling is thesame.

Power On

NMT_MS
NMT_NodeAssignment_AU32[1..254].Bit0
NMT_NodeAssignment_AU32[1..254].Bit1

BOOT CN1

Fig. 90.

7.4.2.2

BOOT CN2

BOOT CNn

Overview of the boot process in NMT super-state NMT_MS

Boot-up of optional and mandatory CNs

Optional CNs are able to link in the network everytime. For the consistency and errorless working of
the network it is important to run the complete boot process also for the optional nodes. Therefore theoptional CNs must be booted-up without any impact on the MN NMT state. Errors during the boot-up
process of optional CNs do not cause an NMT state change of the MN. The application shall be
informed about the errors.
The mandatory CN boot process correlates directly to the MN NMT states. Only if all mandatory CNs
reach the same target NMT state within a sub-state of the boot process, the MN will proceed with theboot process.
The MN force all CNs into a specific NMT state. Fig. 91 shows the dependencies between the MN
NMT state and the boot process actions. Optional CNs are able to be linked to the network later, even
if the MN is already in the NMT_MS_OPERATIONAL state .
It is possible to carry out the boot steps of one NMT state in parallel for all nodes or in serial i.e. one
CN after the other. For optional nodes, even boot steps of different NMT states can be carried out inparallel for different CNs as there must not be a common NMT state for all optional nodes in the
network.

EPSG DS 301 V1.5.1-284-

Optional CN

Mandatory CN
NMT_MS

NMT_MS

BOOT_STEP1

NMT_MS_PRE_OPERATIONAL_1

BOOT_STEP1

NMT_MS_PRE_OPERATIONAL_1
BOOT_STEP2
BOOT_STEP2

NMT_MS_PRE_OPERATIONAL_2
NMT_MS_PRE_OPERATIONAL_2

CHECK_COMMUNICATIONCHECK_COMMUNICATION

NMT_MS_READY_TO_OPERATENMT_MS_READY_TO_OPERATENMT _StartUp _U32.Bit1

Start all nodes
disabled

Start all nodes
enabledSTART_CN

START_ALL

7.4.2.2.1

Start all nodes
disabled

Start all nodes
enabledSTART_CN

START_ALL

OPERATIONALOPERATIONALERROR _TREATMENTERROR _TREATMENT

NMT_MS_OPERATIONAL

Fig. 91.

NMT _StartUp _U32.Bit 1

NMT_MS_OPERATIONAL

Network boot process dependencies to the NMT_MS for optional and mandatory CNs

BOOT_STEP1

The BOOT_STEP1 process is started for all configured CNs. The purpose of the BOOT_STEP1
process is to check the identification of the configured CNs and to check the CN’s software andconfiguration.
The BOOT_STEP1[Node ID] returns E_OK after all checks or updates are terminated successfully. If
one of the checks or updates fails, BOOT_STEP1[Node ID] returns E_NOK.
The following steps are performed in BOOT_STEP1:•

Check Identification (see chapter 7.4.2.2.1.1)•

Check Software (see chapter 7.4.2.2.1.2)•

Check Configuration (see chapter 7.4.2.2.1.3)

EPSG DS 301 V1.5.1-285-

BOOT_STEP1[Node ID]
CHECK_IDENTIFICATION

Identification
E_NOK

Identification
E_OK

Software
E_UPDATECHECK_SOFTWARE

Software
E_NOK

Software
E_OK

CHECK_
CONFIGURATION

Configuration
E_NOK

Configuration
E_OK

BOOT_STEP1[Node ID]
E_OK

Fig. 92.

BOOT_STEP1[Node ID]
E_NOK

Sub-state BOOT_STEP1

7.4.2.2.1.1

CHECK_IDENTIFICATION

The purpose of the CHECK_IDENTIFICATION state is to check the identification of a CN.
CHECK_IDENTIFICATION [Node ID] returns E_OK after all identifications are finished successfully. If
one of the identifications fails, CHECK_IDENTIFICATION [Node ID] returns E_NOK.
In the sub-state CHECK_IDENTIFICATION the MN proceeds as follows:•

Request IdentResponse from the CN (see 7.3.3.2). In case of a timeout, the error
E_NMT_BPO1_GET_IDENT is set and CHECK_IDENTIFICATION[Node ID] is finished with
E_NOK.

•

Check the device type of the CN against the following object:•
NMT_MNDeviceTypeIdList_AU32[Node ID].
If the device type checking fails, the Error Status E_NMT_BPO1_DEVICE_TYPE is set and
CHECK_IDENTIFICATION[Node ID] finished with E_NOK, otherwise the next step isperformed.

•

If the boot-up process of a CN shall not continue automatically, the boot process waits for an
application trigger to continue. Otherwise the boot process is continued immediately. The
switching policy depends on•

NMT_NodeAssignment_AU32[1..254].Bit2•

If identification check is not required depending on
NMT_StartUp_U32.Bit9, CHECK_IDENTIFICATION[Node ID] returns E_OK.
If the Identification check is required, it is based on the following objects:•

NMT_MNVendorIdList_AU32[Node ID]•

NMT_MNProductCodeList_AU32[Node ID]•
NMT_MNRevisionNoList_AU32[Node ID]
If the identification check fails, CHECK_IDENTIFICATION[Node ID] returns E_NOK and error
E_NMT_BPO1_VENDOR_ID, E_NMT_BPO1_PRODUCT_CODE or
E_NMT_BPO1_REVISION_NO is set, otherwise the boot process continues.
•

The CN serial number is checked based on the following object:EPSG DS 301 V1.5.1

-286-

•
NMT_MNSerialNoList_AU32[Node ID].
If the identification check fails, the error E_NMT_BPO1_SERIAL_NO is set and
CHECK_IDENTIFICATION[Node ID] returns E_NOK. Otherwise
CHECK_IDENTIFICATION[Node ID] returns E_OK.

CHECK _ IDENTIFICATIONGET_IDENT[Node ID ]GET_IDENT E_NOKSet Error Status
E_NMT_BPO1_GET_IDENT

Device TypeE_NOK

Set Error Status
E_NMT_BPO1_DEVICE_TYPE

GET_IDENT E_OK
NMT_MNDeviceTypeIdList_AU32 [Node ID]

Device Type E_OK
or don’t care
NMT_NodeAssignment_AU32.Bit2
Application triggered
Boot CN

Wait for Application

Automatically continue
Boot CN
NMT_StartUp_U32
Identification checkneccesary

Identification Check
not necessary

Identification
E_OK
Serial No
E_OK

NMT_MNVendorIdList_AU32 [Node ID]
NMT_MNProductCodeList_AU32 [Node ID]
NMT_MNRevisionNoList_AU32 [Node ID]

Identification
E_NOK

NMT_MNSerialNoList_AU32 [Node ID]
Serial No
E_NOKCHECK_IDENTIFICATION [Node ID]
E_OK

Fig. 93.

Set one of the Error Status
E_NMT_BPO1_VENDOR_ID
E_NMT_BPO1_PRODUCT_CODE
E_NMT_BPO1_REVISION_NO

Set Error Status
E_NMT_BPO1_SERIAL_NOCHECK_IDENTIFICATION [Node ID]
E_NOK

Sub-state CHECK_IDENTIFICATION[Node ID]

7.4.2.2.1.2

CHECK_SOFTWARE

The purpose of CHECK_SOFTWARE is to check and update the CN software, if required.
The update process itself shall be done by the application. The application signals the result of the
update process to the boot-up process.
CHECK_SOFTWARE [Node ID] returns E_OK after all software checks and updates are finishedsuccessfully. If an error occurred, CHECK_SOFTWARE [Node ID] returns E_NOK.
In the process CHECK_SOFTWARE[Node ID] the MN proceeds as follows:•

If software version check is not required (depending on the following object:•

NMT_StartUp_U32.Bit10,•
NMT_NodeAssignment_AU32[Node ID].Bit5),
CHECK_SOFTWARE[Node ID] returns E_OK, otherwise the reported CN software version ischecked against objects•

PDL_MnExpAppSwDateList_AU32[Node ID],•

PDL_MnExpAppSwTimeList_AU32[Node ID]

EPSG DS 301 V1.5.1-287-

CHECK_SOFTWARE[Node ID]
NMT_StartUp_U32.Bit10
NMT_NodeAssignment_AU32.Bit5

Software Version
Checkneccesary

Software Version
not cofigured

Set Error Status
E_NMT_BPO1_SW_INVALID

PDL_MnExpAppSwDateList_AU32
PDL_MnExpAppSwTimeList_AU32
NMT_MNCNCurrState_AU8
Software Version
other
E_NOK

Set Error Status
E_NMT_BPO1_SW_STATENMT_CS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2
NMT_NodeAssignment_AU32.Bit6
Software Update
not allowed

Set Error Stat
E_NMT_BPO1_SW_REJECT

Application triggered
Software Update

Software Version Check
not neccesary

Software Version E_OK

Wait for Application

Software Update
E_NOK

Set Error Status
E_NMT_BPO1_SW_UPDATE

SoftwareUpdate E_OK

CHECK_SOFTWARE[Node ID]
E_OK

Fig. 94.

CHECK_SOFTWARE[Node ID]
E_UPDATECHECK_SOFTWARE[Node ID]
E_NOK

Sub-state CHECK_SOFTWARE[Node ID]•

If the checking of the software version is not possible because the software version informationon the MN is not configured (corresponding node sub-index of
PDL_MnExpAppSwDateList_AU32 or PDL_MnExpAppSwTimeList_AU32 not found), the error
E_NMT_BPO1_SW_INVALID is set and CHECK_SOFTWARE[Node ID] returns E_NOK. If thereceived software version matches the expected one, CHECK_SOFTWARE[Node ID] returns
E_OK, otherwise the process continues with the NMT state check of the CN.

•

If the current NMT state of the CN is not equal to NMT_CS_PREOPERATIONAL_1 or
NMT_CS_PREOPERATIONAL_2 (check based on object•
NMT_MNNodeCurrState_AU8),
The error E_NMT_BPO1_SW_STATE is set and CHECK_SOFTWARE[Node ID] returns
E_NOK, otherwise the next step is proceeded.

•

If software update is not allowed (depending on the setting of object•
NMT_NodeAssignment_AU32[Node ID].Bit6),
the error E_NMT_BPO1_SW_REJECT is set and CHECK_SOFTWARE[Node ID] returns
E_NOK. If the software update is allowed, the application shall be informed. Continue of theboot-up process shall be triggered by the application update return code.

•

The software update itself is always part of the application. Any protocol (SDO, FTP, …) isallowed to be used for the application software update. A successful completion of the update issignalled by the application with the event E_OK.

•

If there was an error during the application software update, the application will signal this to theboot-up process by returning E_NOK. In case of a software update error, the boot step returns
E_NOK.

•

Running BOOT_STEP1 for an optional CN while the MN is already in
NMT_MS_PRE_OPERATIONAL_2 or higher, the NMTSwReset command shall be sent to theCNs individually after leaving CHECK_SOFTWARE with E_UPDATE.

EPSG DS 301 V1.5.1

7.4.2.2.1.3-288-

CHECK_CONFIGURATION

The purpose of CHECK_CONFIGURATION is to check the configuration of a CN and to update theconfiguration if necessary. CHECK_CONFIGURATION [Node ID] returns E_OK, if the configurationfits, otherwise CHECK_ CONFIGURATION [Node ID] returns E_NOK.
The steps of CHECK_CONFIGURATION[Node ID] are as follows:•

If configuration verification is not required (configured by object•
NMT_StartUp_U32.Bit11),
CHECK_CONFIGURATION returns E_OK, otherwise the configuration is checked against
objects•

CFM_ExpConfDateList_AU32[Node ID]•
CFM_ExpConfTimeList_AU32[Node ID]
If the configuration date and time received within the IdentResponse of the CN is correct,
CHECK_CONFIGURATION[Node ID] returns E_OK. Otherwise the boot-up process continues
with the next step.
•

After the configuration update is finished successfully, the MN shall request an IdentResponse
from the updated CN (see 7.3.3.2). If a timeout occurs, the error E_NMT_BPO1_GET_IDENT is
set and CHECK_CONFIGURATION[Node ID] returns E_NOK, otherwise the boot-up processcontinues with the next step.

•

Configuration date and time is checked against objects•

CFM_ExpConfDateList_AU32[Node ID]•
CFM_ExpConfTimeList_AU32[Node ID]
If the configuration check fails, the error E_NMT_BPO1_CF_VERIFY is set and
CHECK_CONFIGURATION[Node ID] returns E_NOK, otherwise it returns E_OK.

CHECK_CONFIGURATION[Node ID]
CFM_ExpConfDateList_AU32[Node ID]
CFM_ExpConfTimeList_AU32[Node ID]

NMT_StartUp_U32.Bit11

ConfigurationCheckneccesary

Configuration
E_NOK
or not configured

CN Configuration
UpdateNMT_BootTime_REC.MNConfigurationTimeout_U32

GET_IDENT
Configuration E_OK

Configuration
Check notneccesary

GET_IDENT
E_NOK

Set Error Status
E_NMT_BPO1_GET_IDENTGET_IDENT E_OK
CFM_ExpConfDateList_AU32[Node ID]
CFM_ExpConfTimeList_AU32[Node ID]

Configuration E_OK

CHECK_CONFIGURATION[Node ID]
E_OK

Configuration
E_NOK

Set Error Status
E_NMT_BPO1_CF_VERIFYCHECK_CONFIGURATION[Node ID]
E_NOK

_E_OK

Fig. 95.

Sub-state CHECK_CONFIGURATION[Node ID]

EPSG DS 301 V1.5.1-289-

7.4.2.2.1.3.1 GET_IDENT
The purpose of the sub-state GET_IDENT is to request the IdentResponse from a CN. GET_IDENT[Node ID] returns E_OK, if the CN answers within a timeout interval, otherwise GET_IDENT [Node ID]
returns E_NOK. The timeout interval depends on the actual boot-up state.
GET_IDENT[Node ID] proceeds as follows:•

Request IdentResponse from the CN.

•

The IdentRequest will be repeated until the CN responds with its Ident Response or atimeout occurs (timeout value passed by the caller of this sub state).

•

If the CN answers with its IdentResponse, GET_IDENT[Node ID] returns E_OK.

•

If the CN does not respond within the configured timeout interval, GET_IDENT[Node ID] returns
E_NOK.

GET_IDENT [Node ID,
Timeout]
no timeout

Send
SOA:IdentRequest to
Node ID

Timeout

IdentResponse
notreceived

Fig. 96.

received

timeout

GET_IDENT
E_OK

GET_IDENT
E_NOK

Sub-state GET_IDENT[Node ID]

EPSG DS 301 V1.5.1

7.4.2.2.2-290-

BOOT_STEP2

The purpose of BOOT_STEP2 is to send the NMT command NMTEnableReadyToOperate to a CN
and to check the CN’s NMT state change to NMT_CS_READY_TO_OPERATE. Furthermore theinitialisation of the error signaling shall be completed in BOOT_STEP2.
BOOT_STEP2 [Node ID] returns E_OK, if the initialisation of the error signaling is completed and the
CN NMT state is NMT_CS_READY_TO_OPERATE.
BOOT_STEP2 [Node ID] returns E_NOK, if the initialisation of the error signaling is not completed or
the CN NMT state did not change from NMT_CS_PRE_OPERATIONAL_2 to
NMT_CS_READY_TO_OPERATE state within a timeout interval (see MNTimeoutPreOp2_U32).

BOOT_STEP2[Node ID]

CHECK_STATE[Node ID]
NMT_CS_PRE_OPERATIONAL_2

E_NOK

E_OK

NMT_BootTime_REC.
MNTimeOutPreOp2_U32

CHANGE_NMT_STATE[Node ID]
NMTEnableReadyToOperate

Fig. 97.

E_NOK

E_OK

E_NOK

BOOT_STEP2[Node ID]
E_OK

BOOT_STEP2[Node ID]
E_OK

Sub-state BOOT_STEP2[Node ID]

BOOT_STEP2[Node ID] proceeds as follows:•

Verify that the CN is in state NMT_CS_PRE_OPERATIONAL_2 by CHECK_STATE.

•

Start the process CHANGE_NMT_STATE to send the NMT command
NMTEnableReadyToOperate to the CN and to check the NMT state change of the CN.

•

Check for the end of the initialisation of the error signaling.

EPSG DS 301 V1.5.1

7.4.2.2.3-291-

CHECK_COMMUNICATION

The purpose of CHECK_COMMUNICATION[Node ID] is to check the communication with a CN after
start of the isochronous POWERLINK cycle in the NMT state NMT_MS_READY_TO_OPERATE.
CHECK_COMMUNICATION[Node ID] will return E_OK, if the Pres frame checking of isochronous
CNs returnes no error. Otherwise CHECK_ COMMUNICATION [Node ID] returns E_NOK.
CHECK_COMMUNICATION[Node ID] proceeds as follows:••

Check the received CN Pres:•No loss of frame occurs•

The payload length is less or equal than the length configured in object▪
NMT_PresPayloadLimitList_AU16 [Node ID].

•

The frame receive time is less or equal than the time configured in object▪
NMT_MNCNPResTimeout_AU32[Node ID].

CHECK_COMMUNICATION[Node ID] returns E_NOK, if the communication with the CN fails or
the expected parameter values do not fit. Otherwise CHECK_COMMUNICATION[Node ID] returns
E_OK.

CHECK_COMMUNICATION [Node ID]
NMT_NodeAssignment_AU32[NodeID].Bit8
Async.
CN
Isochronous
CN

Send
PReq [Node ID]
PRes
received

No Response
NMT_MNPResPayloadLimitList_AU16[NodeID]

Payloadsize E_NOKPayloadsize E_OK
NMT_MNCNPResTimeout_AU16[NodeID]
Telegram receive Time E_NOK
Telegram receive Time E_OK

CHECK_COMMUNICATION [Node ID]
E_OK

Fig. 98.

CHECK_COMMUNICATION [Node ID]
E_NOK

Sub-state CHECK_COMMUNICATION[Node ID]

EPSG DS 301 V1.5.1

7.4.2.2.4-292-

START_CNIn the sub-state START_CN[Node ID] the MN sends NMTStartNode to an individual CN.
START_CN[Node ID] returns E_OK, if the CN changes its state to NMT_CS_OPERATIONAL within atimeout interval, otherwise E_NOK will be returned.

START_CN[Node ID]

NMT_StartUp_U32.Bit3
Start CN
automaticallyStart CN
trigger expectedfrom application

Wait for application

Triggered byapplication

Request
NMTStatusResponse

NMT_MNCNCurrSta te_AU8[Node ID]

CN State=
all other states

CN State =NMT_CS_OPERATIONAL

CN State =NMT_CS_READY_TO_OPERATENMT_BootTime_REC.MNStartCNTimeout_U32

CHANGE_NMT_STATE[Node ID]
NMT_StartNode

E_NOK

E_OK

START_CN[Node ID]
E_OK

Fig. 99.

START_CN[Node ID]
E_NOK

Sub-state START_CN[Node ID]

START_CN[Node ID] proceeds as follows:•

START_CN[Node ID] starts immediately or after the application trigger, depending on object•

NMT_StartUp_U32.Bit3.

•

The MN checks the current state of the CN. If the CN is in the state NMT_CS_OPERATIONAL,
START_CN[Node ID] returns E_OK.

•

If the CN is in the state NMT_CS_READY_TO_OPERATE the boot-up procedure enters the
sub-state CHANGE_NMT_STATE[Node ID] to send NMTStartNode to the CN and control its
state change.

•

If CHANGE_NMT_STATE[Node ID] returns E_OK, START_CN[Node ID] returns E_OK.

EPSG DS 301 V1.5.1
•

-293-

If the CN is in a wrong state (neither NMT_CS_OPERATIONAL nor
NMT_CS_READY_TO_OPERATE) or if CHANGE_NMT_STATE[Node ID] returns E_NOK,START_CN[Node ID] returns E_NOK, too.

7.4.2.2.5

START_ALL

In the sub-state START_ALL, NMTStartNode is sent to all CNs as broadcast. START_ALL returns
E_OK, if all CNs change their state to NMT_CS_OPERATIONAL within a timeout interval, otherwise
START_ALL returns E_NOK.

START_ALL

NMT_StartUp_U32.Bit 3
Start CN
automaticallyStart CN
trigger expectedfrom application

Wait for application

Triggered byapplication

Send NMT command service
NMTStartNode to all CN

CHECK_STATENMT_CS_OPERATIONALCN 1

CHECK_STATENMT_CS_OPERATIONALCN 2

CHECK_STATE[Node ID] of
one or more mandatory CN E_NOKSTART_ALL
E_NOK

Fig. 100.

CHECK_STATENMT_CS_OPERATIONALCN n

CHECK_STATE[Node ID] of
all mandatory CN E_OK

START_ALL
E_OK

Sub-state START_ALL

START_ALL proceeds as follows:•

START_ALL proceeds immediately or after the application trigger, depending on the following
object:•NMT_StartUp_U32.Bit3.

•

After transmission of the broadcast NMT command NMTStartNode, the MN starts the
sub-state CHECK_STATE for all identified CNs. If all CNs are in the state
NMT_CS_OPERATIONAL, START_ALL returns E_OK. If one or more mandatory CNs
caused an error in CHECK_STATE, START_ALL returns E_NOK.

EPSG DS 301 V1.5.1

7.4.2.2.6-294-

CHECK_STATE

The purpose of CHECK_STATE is to check the current NMT state of a CN.
CHECK_STATE returns E_OK, if the current CN state is already equal to the expected state. It returns
E_NOK, if the CN did not switch to the target state within a timeout interval.
If the CN is in an unexpected state, CHECK_STATE returns E_NOK.

CHECK_STATE [NodeID,
TargetState,
Timeout]

Request
NMTStateResponse[Node ID]

No Timeout
NMT_MNCNCurrState_AU8[Node ID]

Timeout
Last State
Timeout
all other states

TargetStateSet Error Status
E_NMT_WRONG_STATECHECK_STATE
E_OK

Fig. 101.

CHECK_STATE
E_NOKSub-state CHECK_STATECHECK_STATE proceeds as follows:•

If the CN state equals to the target state, CHECK_STATE returns E_OK.

•

If the CN state corresponds to the last state, the CN state is further checked within a timeinterval until the state changes to the target state or a timeout occurs.
For a state change to NMT_CS_READY_TO_OPERATE the timeout is configured via object
NMT_BootTime_REC.MNTimeoutPreOp2_U32.
In all other cases the timeout is defined by C_NMT_STATE_TOLERANCE.
In case of a timeout CHECK_STATE returns E_NOK.

•

If the CN is in an unexpected state, CHECK_STATE returns E_NOK.

EPSG DS 301 V1.5.1

7.4.2.2.7-295-

CHANGE_NMT_STATECHANGE_NMT_COMMAND sends a NMT command to a particular CN. The resulting NMT statechange is checked. Before checking the status, the MN waits for C_NMT_STATE_TOLERANCE
cycles to allow the CN’s NMT state change.
CHANGE_NMT_STATE returns E_OK, if the CN state is equal to the target state. Otherwise E_NOK
will be returned.
If the CN state is not in an expected state, CHANGE_NMT_STATE returns with status E_NOK.

Send
SOA:NMT Command to
Node ID

Request
NMTStatusResponse[Node ID]

CHANGE_NMT_STATE[Node ID],
Command,
Timeout

NMT_MNCNCurrState_AU8[Node ID]
no timeout
Timeout

Target State

Last State
all other states

timeout

Set Error Status
E_NMT_WRONG_STATESEND_NMT_COMMAND
E_OK

Fig. 102.

7.4.2.2.8

SEND_NMT_COMMAND
E_NOKSub-state CHANGE_NMT_STATEOPERATIONAL

In the OPERATIONAL state, the MN supervises all CNs that are in NMT_CS_OPERATIONAL state. If
a mandatory CN generates an error such as response timeouts or wrong NMT states, the
ERROR_TREATMENT substate shall be entered.
Errors of optional nodes in state OPERATIONAL are reported to the application. The boot-up of these
optional CNs shall be restarted after sending the NMT command NMTResetNode.

7.4.2.2.9

ERROR_TREATMENT

In the sub-state ERROR_TREATMENT the MN will, depending on the NMT_StartUp_U32.Bit4 and
NMT_StartUp_U32.Bit6, either send a NMTResetNode or a NMTStopNode to all CNs or it shallhandle errors on CN in an application specific manner.
Errors of optional CNs do not have any influence on the MN or the other CNs.
The steps of the ERROR_TREATMENT process are as follows:•

Depending on the following bits:•

NMT_StartUp_U32.Bit6•

NMT_StartUp_U32.Bit4

EPSG DS 301 V1.5.1-296-

the errors are treated different. For optional nodes these bits are always ignored as only theindividual CN error treatment is allowed.
•

If NMT_StartUp_U32.Bit6 is true, the NMT command NMTStopNode shall be transmitted to allCNs•

If NMT_StartUp_U32.Bit4 is true, the NMT command NMTResetNode shall be transmitted to allCNs. If NMT_StartUp_U32.Bit4 is false, errors are treated individually by the application.

ERROR_TREATMENTNMT_StartUp_U32.Bit6
TRUE

FALSE

NMT_StartUp_U32.Bit4

TRUE

FALSE
Treat CN individuallyby the application
Send NMT command service
NMTResetNode to all CN

Send NMT command service
NMTStopNode to all CN

Inform application

Fig. 103.

Sub-state ERROR_TREATMENT

7.4.3

Boot-up Errors

7.4.3.1

Bus activity•

Error Source
The device is configured as an MN and detects another MN (SoC, IdentRequest, …).

•Handling
The MN shall halt the boot procedure. The error is logged in the error history.

•

Registration
History Entry Object ERR_History_ADOM:EPSG DS 301 V1.5.1
Mode3h

7.4.3.2•

Profile
002h

-297-

Error Code
E_NMT_BA1

Timestamp
XXXX

Additional Information

BOOT_STEP1 failed

Error Source
Boot process in the NMT_MS_PRE_OPERATIONAL_1 state failed. One or more mandatory
CNs failed.

•Handling
The MN shall stop the boot-up procedure. The error is logged in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.3•

Profile002h

Error Code
E_NMT_BPO1

Timestamp
XXXX

Additional Information

BOOT_STEP2 failed

Error Source
Boot process in the NMT_MS_PRE_OPERATIONAL_2 state failed. One or more of themandatory configured CNs failed.

•Handling
The MN shall stop the boot-up procedure. The error is logged in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.4•

Profile002h

Error Code
E_NMT_BPO2

Timestamp
XXXX

Additional Information

Boot-up in NMT_MS_READY_TO_OPERATE failed

Error Source
The process CHECK_COMMUNICATION in the NMT_MS_READY_TO_OPERATE state failed
because of the reception of at least one incorrect or missing Pres.

•

Handling
The MN shall stop the boot-up procedure and log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.5•

Profile002h

Error Code
E_NMT_BRO

Get Ident failed

Error Source
No response on an Ident Request was received.

•

Handling
Log the error in the error history.

Timestamp
XXXX

Additional InformationEPSG DS 301 V1.5.1
•

-298-

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.6•

Profile002h

Error CodeTimestamp
E_NMT_BPO1_GET_IDENT XXXX

Additional Information

Device Type Invalid

Error Source
Actual device type of the CN (value of object NMT_DeviceType_U32 reported via
IdentResponse) did not match the expected device type configured on the MN via object
NMT_MNDeviceTypeIdList_AU32.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.7•

Profile002h

Error Code
E_NMT_BPO1_DEVICE_TYPE

Timestamp Additional Information
XXXX

Vendor ID invalid

Error Source
Vendor ID reported via IdentResponse of the CN did not match the expected vendor ID
configured on the MN via object NMT_MNVendorIdList_AU32.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.8•

Profile002h

Error Code
E_NMT_BPO1_VENDOR_ID

Timestamp Additional Information
XXXX

Configuration failed

Error Source
Configuration update failed.

•Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.9•

Profile002h

Error Code
E_NMT_BPO1_CF_VERIFY

Timestamp Additional Information
XXXX

Product Code invalid

Error Source
Product Code reported via IdentResponse of the CN did not match the expected product code
configured on the MN via object NMT_MNProductCodeList_AU32.

EPSG DS 301 V1.5.1
•

-299-

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.10•

Profile002h

Error CodeTimestamp Additional Information
E_NMT_BPO1_PRODUCT_CODE XXXX

Revision number invalid

Error Source
Revision number reported via IdentResponse of the CN did not match the expected revision
number configured on the MN via object NMT_MNRevisionNoList_AU32.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.11•

Profile002h

Error Code
E_NMT_BPO1_REVISION_NO

Timestamp
XXXX

Additional Information

Serial number invalid

Error Source
Serial number reported via IdentResponse of the CN did not match the expected serial number
configured on the MN via object NMT_MNSerialNoList_AU32.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.12•

Profile002h

Error Code
E_NMT_BPO1_SERIAL_NO

Timestamp
XXXX

Additional Information

NMT state invalid

Error Source
Reported CN NMT state does not match the expected NMT state.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.13•

Profile002h

Error Code
E_NMT_WRONG_STATE

Timestamp
XXXX

Invalid Software

Error Source
Software version information for a certain CN not available on the MN.

Additional InformationEPSG DS 301 V1.5.1
•

-300-

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.14•

Profile002h

Error Code
E_NMT_BPO1_SW_INVALID

Timestamp
XXXX

Additional Information

Invalid NMT state for SW update

Error Source
Software update failed due to wrong NMT state of the target CN.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.15•

Profile002h

Error Code
E_NMT_BPO1_SW_STATE

Timestamp
XXXX

Additional Information

Timestamp
XXXX

Additional Information

SW update not allowed

Error Source
Software update of a CN not allowed.

•

Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:
Mode
3h

7.4.3.16•

Profile002h

Error Code
E_NMT_BPO1_SW_REJECT

SW update failed

Error Source
An error occurred during the application SW update process.

•Handling
Log the error in the error history.

•

Registration
History Entry Object ERR_History_ADOM:Mode
3hProfile002h

Error Code
E_NMT_BPO1_SW_UPDATE

Timestamp
XXXX

Additional InformationEPSG DS 301 V1.5.1

7.4.4

-301-

Minimal Boot-up MNPower OnMINIMAL_MN

NMT_MS_INITIALISATION

NMT_MS_NOT_ACTIVE– Check bus activity

NMT_MS_PRE_OPERATIONAL_1- Start POWERLINK reduced cycle- Identify all CNs

NMT_MS_PRE_OPERATIONAL_2- Start isochronous POWERLINK cycle- Check CN state- Send NMTEnableReadyToOperate- Check CN Poll_OutSize

NMT_MS_READY_TO_OPERATE- Check communication

NMT_MS_OPERATIONAL- Send NMTStartNodeAll- NORMAL OPERATION

Fig. 104.

Minimal NMT boot-up process

Fig. 104 depicts a minimal MN boot-up, which allows to implement a simple NMT state machine on
low-cost MNs. Only small applications should use this type of boot-up as there is no error treatment or
configuration checking. The minimal MN boot-up guarantees only that all devices reach theoperational state and that no device violates the POWERLINK cycle.

EPSG DS 301 V1.5.1

7.4.5

-302-

Example Boot-up Sequence

In this example a typical boot-up with a single CN and without boot-up errors is depicted. The example
also shows a configuration update of the CN in BOOT_STEP1.
MN

CN
NMT_GS_POWEREDNMT_GS_INITIALISING
NMT_GS_RESET_APPLICATION
NMT_GS_RESET_CONFIGURATION
NMT_MS_NOT_ACTIVE

NMT_CS_NOT_ACTIVE

NMT_MS_PRE_OPERATIONAL_1

NMT_CS_BASIC_ETHERNET_MODE

Start reduced cycle

SoA

NMT_CS_PRE_OPERATIONAL_1
SoA (R.- ServiceID: IdentRequest)

ASnd

SDO Communication [Client]

BOOT_STEP1

SoA

ASnd (ServiceID: IdentResponse)*

SDO Communication [Server]*

SoA (R.- ServiceID: IdentRequest)

SoA
ASnd

ASnd (ServiceID: IdentResponse)

BOOT_STEP1 E_OK
NMT_MS_PRE_OPERATIONAL_2
Start isochronous cycle

SoC

NMT_CS_PRE_OPERATIONAL_2
Command: NMTEnableReadyToOperate

BOOT_STEP2

ASnd

NMT_CS_READY_TO_OPERATESoA (R.- ServiceID: StatusRequest)

SoA
ASnd

ASnd (ServiceID: StatusResponse)

BOOT_STEP2 E_OK
NMT_MS_READY_TO_OPERATE
Send PReq

CHECK_COMMUNICATION

PReq

Send PRes

PRes

CHECK_COMMUNICATION E_OK
NMT_MS_OPERATIONAL
Command: NMTStartNode

START

ASnd

NMT_CS_OPERATIONAL
SoA (R.- ServiceID: StatusRequest)

SoA
ASnd

ASnd (ServiceID: StatusResponse)

START_CN E_OK
Operational* Operation is done several times

Fig. 105.

Boot procedure example for a single CN

7.4.6

Application Notes•

It is permitted to boot-up one device after another (sequential boot-up) or all in parallel. If thesequential boot-up procedure is implemented, it must be ensured that a particular boot step isstill performed for all devices even if an error of a mandatory node occurred within that bootstep. The reaction of the boot-up process upon an error within a mandatory node shall bedelayed until the boot step was finished for all the other devices, too.

EPSG DS 301 V1.5.1

-303-

•

The defined processes shall give an overview to the boot-up, they do not define a specific API.
The main purpose is to have common rules for the MN boot-up procedure and to give CNs theknowledge, what they have to expect on boot-up.

•

The same procedure, except for the error handling, will be used if an optional CN has to bebooted while the rest of the system is already running, e.g. after a reset or error. In that case the
NMT command NMTStartNode may always be sent individually.

EPSG DS 301 V1.5.1

-304-

8

Diagnostics

8.1

Diagnostic Object Dictionary Entries

8.1.1

Object 1101h: DIA_NMTTelegrCount_REC

The object’s sub-indices count cycles, synchronous and asynchronous frames, SDO telegrams andStatusRequests since NMT_GS_RESET_COMMUNICATION. The counters shall be reset in
NMT_GS_RESET_COMMUNICATION.
The application may provide additional means to reset the conters.
Index
Name
Data Type•

Object TypeRECORD

CategoryO

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1101h
DIA_NMTTelegrCount_REC
DIA_NMTTelegrCount_TYPE

00h
NumberOfEntries
88

Sub-Index 01h: IsochrCyc_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
IsochrCyc_U32
UNSIGNED32
UNSIGNED32
0This sub-index holds the number of transmitted (MN) or received (CN) SoC frames.
•

Sub-Index 02h: IsochrRx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
IsochrRx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of received Preq and Pres frames.
•

Sub-Index 03h: IsochrTx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
IsochrTx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO MappingThis sub-index holds the number of transmitted Preq and Pres frames.

O
ro
No

EPSG DS 301 V1.5.1
•

-305-

Sub-Index 04h: AsyncRx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

04h
AsyncRx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of received asynchronous frames (POWERLINK Asnd, IP
frames etc., but not SoA).
•

Sub-Index 05h: AsyncTx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

05h
AsyncTx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of transmitted asynchronous frames (POWERLINK Asnd, IP
frames etc., but not SoA).
•

Sub-Index 06h: SdoRx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

06h
SdoRx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of received SDO telegrams via UDP/IP or POWERLINK Asnd.
•

Sub-Index 07h: SdoTx_U32
Sub-Index
Name
Data Type
Value Range
Default Value

07h
SdoTx_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of transmitted SDO telegrams via UDP/IP or POWERLINK
Asnd.
•

Sub-Index 08h: Status_U32
Sub-Index
Name
Data Type
Value Range
Default Value

08h
Status_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO MappingThis sub-index holds the number of received StatusRequest SoA telegrams.

O
ro
No

EPSG DS 301 V1.5.1

8.1.2

-306-

Object 1102h: DIA_ERRStatistics_REC

The object’s sub-indices count events which occurred in the Error Signaling module. When reaching
their maximum value the counters shall continue with 0.
Index
Name
Data Type•

Object TypeRECORD

CategoryO

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

O
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1102h
DIA_ERRStatistics_REC
DIA_ERRStatistics_TYPE

00h
NumberOfEntries
7
7

Sub-Index 01h: HistoryEntryWrite_U32
Sub-Index
Name
Data Type
Value Range
Default Value

01h
HistoryEntryWrite_U32
UNSIGNED32
UNSIGNED32
0This sub-index holds the number of entries written to the error history (see 6.5.1).
•

Sub-Index 02h: EmergencyQueueWrite_U32
Sub-Index
Name
Data Type
Value Range
Default Value

02h
EmergencyQueueWrite_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of successful write actions to the emergency queue. Write
actions which can not be performed because the queue is full shall not be counted here.
•

Sub-Index 03h: EmergencyQueueOverflow_U32
Sub-Index
Name
Data Type
Value Range
Default Value

03h
EmergencyQueueOverflow_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of write actions to the emergency queue which could not bedone because the queue was full.
•

Sub-Index 04h: StatusEntryChanged_U32
Sub-Index
Name
Data Type
Value Range
Default Value

04h
StatusEntryChanged_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO MappingThis sub-index holds the number of changes in the StatusEntries.

O
ro
No

EPSG DS 301 V1.5.1
•

-307-

Sub-Index 05h: StaticErrorBitFieldChanged_U32
Sub-Index
Name
Data Type
Value Range
Default Value

05h
StaticErrorBitFieldChanged_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of changes in the Static Error Bit Field.
•

Sub-Index 06h: ExceptionResetEdgePos_U32
Sub-Index
Name
Data Type
Value Range
Default Value

06h
ExceptionResetEdgePos_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of detected 0 to 1 transitions of the bit ER.
•

Sub-Index 07h: ExceptionNewEdge_U32
Sub-Index
Name
Data Type
Value Range
Default Value

07h
ExceptionNewEdge_U32
UNSIGNED32
UNSIGNED32
0

Category
AccessPDO Mapping

O
ro
No

This sub-index holds the number of all generated transitions on the bit EN.

8.1.3

Diagnostics Object Types

8.1.3.1

Object 0437h: DIA_NMTTelegrCount_TYPE

Index
Name

0437h
DIA_NMTTelegrCount_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h
06h
07h
08h

Component Name
NumberOfEntries
IsochrCyc_U32
IsochrRx_U32
IsochrTx_U32
AsyncRx_U32
AsyncTx_U32
SdoRx_U32
SdoTx_U32
Status_U32

Value
08h
0007h
0007h
0007h
0007h
0007h
0007h
0007h
0007h

Data TypeUNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

EPSG DS 301 V1.5.1

8.1.3.2-308-

Object 0438h: DIA_ERRStatistics_TYPE

Index
Name

0438h
DIA_ERRStatistics_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h
06h
07h

Component Name
NumberOfEntries
HistoryEntryWrite_U32
EmergencyQueueWrite_U32
EmergencyQueueOverflow_U32
StatusEntryChanged_U32
StaticErrorBitFieldChanged_U32
ExceptionResetEdgePos_U32
ExceptionNewEdge_U32

Value
07h
0007h
0007h
0007h
0007h
0007h
0007h
0007h

Data TypeUNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32
UNSIGNED32

EPSG DS 301 V1.5.1-309-

Routing

9

A POWERLINK Router is a coupling element in a network that allows IP communication between a
POWERLINK segment and any other datalink layer protocol carrying IP e.g. legacy Ethernet,
POWERLINK etc.

9.1

Routing Type 1

A POWERLINK Router Type 1 is a coupling element in a network that allows IP communication
between a POWERLINK network and any other datalink layer protocol carrying IP e.g. Legacy
Ethernet, POWERLINK etc. It enables the communication between two networks using IP and ICMP.
Other network layer protocols besides IP cannot be coupled via the Routing Type 1. MN and CNs may
have router functionality implemented. A POWERLINK Router runs an application that forwards IP and
ICMP datagrams from the POWERLINK network to an external network and vice versa. Fig. 106
illustrates the black box model of the POWERLINK Router.
POWERLINK
Network

POWERLINK Router IP →Outbound traffic

Fig. 106.

External Network
e.g. Legacy Ethernet

Inbound traffic

POWERLINK router, black box model

Traffic from the external network to the POWERLINK network is called inbound traffic. The traffic fromthe POWERLINK network to the external network e.g. Legacy Ethernet is called outbound traffic.
Routing Type 1 is optional. Support shall be indicated by D_RT1_RT1Support_BOOL.

9.1.1

Core Tasks of a POWERLINK RouterThis section describes some relevant application scenarios in more detail. Possible application
scenarios for the use of a POWERLINK Router are listed below. Only scenarios for communication
paths that involve a POWERLINK Router are listed.
•

Diagnostics, Remote Maintenance, Monitoring•

Alarm Messages•

Software Download•

Configuration / Engineering•

Secure Access•
SDO communication
Each data transmission that originates from the POWERLINK network and terminates out-side of it(including inside the router), falls within the responsibility of the POWERLINK Router. The same
applies for traffic that originates from the external network and terminates inside the POWERLINK
network.
There are several use cases that require the above mentioned traffic pattern. While they can all be
subsumed under the view that they require the functionality of the POWERLINK Router, they will beoutlined below because each use case has its own peculiarities. In any case, the coupling by meansof a POWERLINK Router is only possible on layer 3, because the POWERLINK Router only handles
data link frames that contain IP and ICMP packets. Fig. 107 illustrates these use cases.
1.
Access from the Factory Floor network (e. g., for diagnostics)
2.
Access from the Company Network (e. g., for inventory purposes)
In this scenario, additional security effort may be necessary, which may require further
processing in the data path POWERLINK Router <-> company network.
3.
Remote Access (e. g., for remote maintenance)
Strict security aspects should be taken into account. These are outside the scope of thisdocument.
4.
POWERLINK inter-segment communication (e. g., for exchange of manufacturing service data)EPSG DS 301 V1.5.1-310-

Internet
Office3. Remote access e.g. from untrusted network

Network
RouterLegacy Ethernet

Company

Router
2. Access from company or office network

Network

Router
Factory

Legacy Ethernet

Floor
Network

1. Access from
Host

factory floor network

POWERLINK
RouterInter

POWERLINK
CN
4. POWERLINK Inter segment
accessPOWERLINK
RouterMachineNetwork

POWERLINK
RouterPOWERLINKPOWERLINK

MachineNetworkFig. 107.

Possible communication relations via a POWERLINK router

A POWERLINK Router shall provide at least one interface of type POWERLINK. In Fig. 107 that is the
POWERLINK Router (yellow) between Factory Floor and Inter Machine Network and the
POWERLINK Routers (orange) between Inter Machine and Machine Network. The other routers do
not contain a POWERLINK interface and are therefore outside the scope of this specification.

9.1.2

Reference Model

The reference model of the POWERLINK Router is shown below.
Layer
Application

POWERLINK node

TCP/IP Host

Application

Application

iso. dataasync. data
TCP

Transport

UDP

TCP

POWERLINK Router

UDP

NetworkIP

Data Link

Ethernet
POWERLINK

Ethernet
POWERLINK

Ethernet
CSMA/CD

Ethernet
CSMA/CD

Physical

PHY

PHY

PHY

PHY

IP

Ethernet POWERLINK Segment

IP

Standard Ethernet Segment

Layer that is specific
to POWERLINK

Fig. 108.

POWERLINK router reference model

9.1.3

Data Link Layer

A POWERLINK Router shall at least provide two interfaces. One interface to the POWERLINK and asecond interface to the external network. IP operates on top of the data link layer – e.g. POWERLINK,
Legacy Ethernet.

EPSG DS 301 V1.5.1

9.1.3.1-311-

DLL POWERLINK Interface

The Interface of the POWERLINK Router to the POWERLINK network shall behave exactly like a
POWERLINK CN (see 4.2.2.2).

9.1.3.2

DLL interface to the external network

Depending on the application requirements, the interface to the external network can be chosen. Any
datalink layer protocol that can embed IP may be used. Legacy Ethernet, POWERLINK, X.25, etc.
may be used for the interface connecting to the external network.

9.1.4

Network Layer

The POWERLINK Router connects a POWERLINK network to an external network only via theInternet Protocol (IP). Therefore, the router’s tasks on this layer are basically the same as that of any
other standard IP router, as described in RFC 1812. These include the routing or forwarding and
Network Address Translation (NAT) described in 9.1.4.2. If other protocols are used, they shall be
encapsulated in IP to communicate via the POWERLINK Router.

9.1.4.1

Communication between POWERLINK and theexternal network

The POWERLINK Router shall forward the following types of packets:•

The POWERLINK Router shall forward only the IP and ICMP packets from the external networkthat are addressed and permitted (see 9.1.5) to the POWERLINK network. How the IP
datagrams are sent on the POWERLINK network, depends on the POWERLINK network state– see 9.1.4.2.

•

The POWERLINK Router shall forward only the IP and ICMP packets from the POWERLINK
network that are addressed to the external network.
The ICMP datagrams supported by the POWERLINK Router are given in 9.1.4.2.1.

9.1.4.2

IP Coupling

The main difference between an IP router using only Legacy Ethernet and a POWERLINK Router isthat the POWERLINK Router forwards IP and ICMP packets depending on the current POWERLINK
network state. Note, that the POWERLINK Router accesses the POWERLINK network in the same
way a CN does, because a POWERLINK Router runs only the IP coupling application.
•

In the NMT_CS_EPL_MODE state, the POWERLINK Router shall forward the respective IP and
ICMP packets to and from the asynchronous phase. The POWERLINK Router shall respect the
network access rules of the POWERLINK network, i.e. it’s only allowed to send, when invited by
the MN.

•In the NMT_CS_BASIC_ETHERNET state, the POWERLINK Router shall access the
POWERLINK network like an IEEE802.3 compliant node using CSMA/CD. There is no cycle
time interval in basic ethernet mode.
Since a POWERLINK network uses fixed IP addresses, supporting only IP routing would limit theflexibility of the system. This restriction is removed using IP routing and Network Address Translation(NAT).

9.1.4.2.1

IP Routing

Forwarding an IP datagram generally requires the router to choose the relevant local interface and theaddress of the next-hop router resp. (for the final hop) of the destination host. This choice depends
upon a route database within the router. The route database is called routing table
RT1_IpRoutingTable_XXh_REC.
Ipv4 routing is specified in RFC 1812. Nothing should prevent a POWERLINK Router from
implementing standard IP routing procedures, but it is recommended that the following points beconsidered:A router’s functionality, as given in RFC 1812 (Requirements for IP Version 4 Routers) is rather
extensive and complex, even if only mandatory functions are implemented. A considerable fraction ofthese functions are neither required nor of meaningful use for a typical POWERLINK RouterEPSG DS 301 V1.5.1-312-

application scenario. It seems therefore sensible to define the POWERLINK Router’s functionality withreference to RFC 1812 and explicitly list the functions that vary from RFC1812.
•

The POWERLINK Router shall use static routing. The POWERLINK Router may not support
any dynamic routing algorithms like RIP or OSPF. Especially for the interface to the
POWERLINK network, the POWERLINK Router should be aware of the limited bandwidth.
Therefore, the POWERLINK Router shall not use dynamic routing algorithms on the
POWERLINK network.

•

The POWERLINK Router shall not support IP multicasting.

•

The POWERLINK Router shall support IP fragmentation. IP datagrams larger than the MTU of
the respective network shall be fragmented.

•

The POWERLINK Router may not support MTU discovery. The MTU of the POWERLINK
network is given in NMT_CycleTiming_REC.AsyncMTU_U16. The POWERLINK Router shallnot send frames longer than the respective Layer 2 MTU limit. However, it may receive andprocess frames addressed to it exceeding this limit.

•

The POWERLINK Router shall use the standard ARP (RFC 826) protocol to find out the IP to
MAC address relation – see 5.1.3•

Traffic precedence features (Layer 2 priority (IEEE 802.1Q-1999) as well as Layer 3 IP TOS)
may be supported.

•

The typical location for a POWERLINK Router is comparable to what RFC 1812 calls a “fringe
router”, i. e., it connects a local network to a network of another hierarchy.

•

The POWERLINK Router shall support the following ICMP messages: Echo Request/Reply,
Destination Unreachable, Redirect, Time Exceeded, Parameter Problem, Address Mask
Request•The POWERLINK Router need not support the following options: Time Stamp, Source Route,
Record Route.

9.1.4.2.1.1

Configuration

Routers shall be manageable by POWERLINK SDO and optionally by the Simple Network
Management Protocol version 3 (SNMPv3).

9.1.4.2.1.1.1 SNMP
The POWERLINK Router may support SNMPv3 RFC 3410-3418 on non-POWERLINK interfaces. If
so the following standard MIBs for management shall be supported.
•

The System, Interface, IP, ICMP, and UDP groups of MIB-II “Management Information Base of
TCP/IP-Based Internets: MIB-II”, RFC 1213 shall be implemented.

•

If the router implements TCP (e.g., for Telnet) then the TCP group of MIB-II “Management
Information Base of TCP/IP-Based Internets: MIB-II”, STD 16, RFC1213 shall be implemented•

The IP Forwarding Table MIB “IP Forwarding Table MIB”, RFC 1354 shall be implemented.

9.1.4.2.1.1.2 SDO
The functionality, which can be configured and retrieved via SDO, is a subset of that provided by
SNMP. For the POWERLINK Router configuration and diagnostics the relevant objects from MIB-II
RFC 1213 and RFC 1354 are mapped to SDO – see 9.1.7. Objects, which are not accessible via
SDO, can be accessed via SNMP.

9.1.4.2.2

Network Address Translation (NAT)

NAT allows POWERLINK nodes within a POWERLINK network to transparently communicate withhosts in the external network. Basic NAT and NAPT are two varieties of NAT. Since POWERLINK
nodes have fixed IP addresses, each POWERLINK Router shall implement Basic NAT which is
specified in:•

RFC 2663 – IP Network Address Translator (NAT) Terminology and Considerations•
RFC 3022 – Traditional IP Network Address Translator (Traditional NAT) – extends RFC 1631
With Basic NAT, a block of external IP addresses are set aside for translating IP addresses of
POWERLINK nodes in the POWERLINK network. POWERLINK nodes that must be addressed fromthe external network, shall be configured in the NAT table RT1_NatTable_XXh_REC. The NAT tablecontains the POWERLINK IP EplIpAddr_IPAD to external IP ExtIpAddr_IPAD address translation. For

EPSG DS 301 V1.5.1-313-

datagrams outbound from the POWERLINK network, the source IP address EplIpAddr_IPAD shall betranslated to the associated ExtIpAddr_IPAD called Source-NAT. For inbound packets, the destination
IP address ExtIpAddr_IPAD shall be translated to the associated EplIpAddr_IPAD, called DestinationNAT. Independent from inbound or outbound IP telegrams, the related fields such as IP, TCP, UDP
and ICMP header checksums shall be corrected. This kind of NAT is also called bidirectional NAT or
1to1 NAT (see RFC 2663). Fig. 109 illustrates an example for bidirectional NAT.
External network
Dst 134.14.12.45
Src 134.14.12.35

Destination-NAT

Host
134.14.12.35

Eth1

Dst 134.14.12.35
Src 134.14.12.43

134.14.12.254

POWERLINK
Router
192.168.1.254
Dst 192.168.1.56
Src 134.14.12.35

Eth0Manager
192.168.1.56
Dst 134.14.12.35
Src 192.168.1.76

NAT Table
IP Addr. (Eth0)

192.168.1.56
192.168.1.4
192.168.1.76

Public IP Addr (Eth1)
134.14.12.45
134.14.12.43

Source-NAT

Controller 1
192.168.1.76

POWERLINK segment
Controller 2
192.168.1.4

Fig. 109.

Symmetrical n-to-n NAT

The visibility of POWERLINK nodes to the external network can be controlled by bidirectional NAT.
Therefore, nodes that should not be accessed from the external network, can be concealed.
POWERLINK nodes that are not configured in the NAT table may not communicate with nodes in theexternal network i.e. the packets are dropped.
In more detail POWERLINK differentiates between Source-NAT where the source address is changed
and Destination-NAT where the destination address is changed. Fig. 110 illustrates the general NAT
architecture.
IP Routing
NAT perInterface

Destination-NAT

Destination-NAT
inboundFig. 110.

Local process

Source-NAT
outbound

NAT architecture

For outbound IP datagrams, that is from the POWERLINK network to the external network we shalluse Source-NAT (S-NAT). S-NAT changes the source address of the IP / ICMP packet. This is done in
the output chain, just before it is finally sent out. This is an important detail, since it means thatanything else on the Router itself (routing, packet filtering) will see the packet unchanged.
For inbound IP datagrams, that is from the external network to the POWERLINK network we shall use
Destination-NAT (D-NAT). D-NAT changes the destination address of the IP / ICMP packet. D-NAT isdone in the input chain, just as the packet comes in. This means that anything else on the Router itself(routing, packet filtering) will see the packet going to its `real’ destination.
The following figure illustrates the interaction between a POWERLINK network and an external
network. It is presented for informative purpose only.

EPSG DS 301 V1.5.1-314-

POWERLINK Router
TX Port 2

TX Port 1

IP routing engine
RX Port 2

RX Port 1

Routing
Table

Network

S-NAT

MAC

Datalink

D-NAT

NAT
Table

Port 2
TX

D-NAT

MAC
RX

outboundPOWERLINK network

Fig. 111.

S-NAT

Port 1RX

TX

inboundexternal network

Integration of NAT in the POWERLINK routerIf bidirectional NAT is configured for a POWERLINK-host a host on the external network who wants tocommunicate with that POWERLINK-host it looks as if the POWERLINK-host is on the same network
like itself.
External addresses of the NAT table are in the subnet of the external network:
On the interface to the external network the POWERLINK Router shall behave like a host,accepting all external IP addresses ExtIpAddr_IPAD listed in the NAT table
RT1_NatTable_XXh_REC. Note, that the POWERLINK Router must respond to an ARP
request, requesting one of the external IP addresses StaticExtIpAddr_IPAD listed in the NAT
table. Therefore this interface does not obtain the IP packet like a router does i.e. the packet isaddressed to the router if it is not in the subnet.
•

External addresses of the NAT table are not in the subnet of the direct connected external
network:
The interface to the external Network is addressed like a router.

•In every case:
The interface of the POWERLINK Router to the POWERLINK network shall act like a router.
Additional information about NAT is given in http://www.netfilter.org, RFC 2993 – Architectural
Implications of NAT and RFC 3027 – Protocol Complications with the IP Network Address Translator.

9.1.4.2.2.1

Configuration

Network address translation shall be manageable by POWERLINK SDO and optionally by SNMPv3.

9.1.4.2.2.1.1 SNMP
The POWERLINK Router MIB specifies the managed objects to configure NAT. Therefore the NATGroup of the POWERLINK Router MIB shall be implemented.

9.1.4.2.2.1.2 SDO
The RT1_NatTable_XXh_REC object specifies the NAT table.

9.1.5

Security

Connecting a POWERLINK network via the POWERLINK Router to an external network (e.g. a LAN)
enables the communication with other resources and services. This presents an enormous benefit to
the entire system. On the other hand a POWERLINK Router represents a security risk, giving hackers,
crackers and intruders the opportunity to access nodes in the POWERLINK network. The
POWERLINK Router is the best place to add security mechanisms to protect a POWERLINK network,
since the POWERLINK Router connects an un-trusted network with the trusted POWERLINK network.

EPSG DS 301 V1.5.1-315-

Security mechanisms consist of rules and restriction but also must ensure availability and ease of use.
Therefore, security must always be used at the right level. When applying security, a risk assessment
must typically be performed. The risk assessment shows the level of security that must be supported.
A risk assessment examines the following questions.
•

Which network is connected to the POWERLINK network (trusted or un-trusted) ?

•Must we cope with accidental “attacks/errors” (handling errors) ?

•Must we cope with “evil-minded” malicious attacks (hackers, crackers, intruders, sabotage) ?

•...
Depending on the result of the risk assessment, the appropriate mechanisms, listed below, must be
used.
•

Secrecy•Integrity•

Authentication and Authorisation•
Availability of the information
This specification for the POWERLINK Router assumes that:•

The POWERLINK Router is connected to a trusted network (e. g. the factory floor network).
Note that additional security considerations must be taken if the factory floor network isconnected to the office network or –even harder – to the internet.

•

The POWERLINK Router does not protect the POWERLINK network against evil mindedattacks such as ICMP attacks, spoofing, etc..
The security assumption stated above, requires that a POWERLINK Router shall provide a basic
security level. The basic security level is achieved using a Packet Filter (stateless Firewall). For higher
security demands stateful Firewalls, VPN servers and Intrusion Detection systems must be
considered. However, this is outside the scope of this specification.
Support of Routing Type 1 security features is optional. Support shall be indicated by
D_RT1_RT1SecuritySupport_BOOL.

Packet Filter – Firewall

9.1.5.1

A Packet Filter is a firewall element that analyses and controls inbound and outbound traffic of thedatalink-, network and transport layers. A firewall in the sense of a Packet Filter physically decouples
an un-trusted network from a trusted network. This enables a global point of security control. The
Packet Filter functionality shall be implemented on the POWERLINK Router since the POWERLINK
Router separates both networks.
In an effort to protect the POWERLINK network from various risks, both accidental and malicious, aPacket Filter should be deployed at a network’s ingress points – the POWERLINK Router. A Packet
Filter maintains the access between the interfaces through Access Control Lists (ACLs).
This specification defines the filter entries and the tables that shall be implemented. Fig. 112 illustrates
the involved tables that represent also the position where the IP datagrams shall be evaluated.
Local process
OUTPUT

INPUT

IP Routing

FORWARD

NAT

inboundoutboundThe bold arrows present the route between POWERLINK and external network.

Fig. 112.

Filter tables of the packet filter

The INPUT table RT1_AclInTable_Xh_REC shall contain the filter entries for packets that are
addressed to the POWERLINK Router itself. The FORWARD table RT1_AclFwdTable_XXh_REC
shall contain the filter entries for packets routed through the POWERLINK Router. The OUTPUT table
RT1_AclOutTable_Xh_REC shall contain the filter entries for packets locally generated. Each tableEPSG DS 301 V1.5.1-316-

shall have its default policy (RT1_SecurityGroup_REC.InTablePolicy_U8,
RT1_SecurityGroup_REC.FwdTablePolicy_U8, RT1_SecurityGroup_REC.OutTablePolicy_U8).

9.1.5.1.1

ACL – Filter Entries

An Access Control List is a sequential list of permit and deny conditions known as a rule. The list
defines the connections permitted to pass through the POWERLINK Router as well as connections
that are denied. ACL’s act as a basic method of limiting access to the POWERLINK network.
A POWERLINK Router can support the following optional filter entries:
Datalink Layer Ethernet MAC frames (DIX2):•
Source MAC address (SrcMac_MAC) of the Ethernet MAC header.
A POWERLINK Router shall support the following filter entries:
Network Layer•

Source IP address (SrcIp_IPAD) field of the IP header / Source IP network mask
(SrcMask_IPAD)•

Destination IP address (DstIp_IPAD) field of the IP header / Destination IP network mask
(DstMask_IPAD)•
Protocol (Protocol_U8) field of the IP header.
Transport Layer if the Protocol is either UDP or TCP•

Source L4 Port (SrcPort_U16) of the TCP or UDP header.

•

Destination L4 Port (DstPort_U16) of the TCP or UDP header.

9.1.5.1.2

Filter strategy

A firewall rule specifies criteria for a packet, and a target. A target specifies what do with this packet if
the rule matches. A rule matches if all specified entries from the assessed packet match thecorresponding entry of the current rule. If the packet does not match, the next rule in the respective
table is examined; if it does match, then the target (Target_U8) of the rule is executed, which is either
ACCEPT or DROP. ACCEPT means to let the packet through. DROP means to drop the packet on
the floor.
If no rule matches, it shall be up to the policy of the respective table(RT1_SecurityGroup_REC.InTablePolicy_U8, RT1_SecurityGroup_REC.FwdTablePolicy_U8,
RT1_SecurityGroup_REC.OutTablePolicy_U8) to process the packet.

9.1.5.1.3

Configuration

The security settings and the ACLs shall be manageable by POWERLINK SDO and optionally by
SNMPv3.

9.1.5.1.3.1

SNMP

The POWERLINK Router MIB specifies the managed objects to configure the Packet Filter. Therefore
the Security Group of the POWERLINK Router MIB shall be implemented.

9.1.5.1.3.2

SDO

The following objects shall be implemented to configure the Packet Filter:•

RT1_SecurityGroup_REC•

RT1_AclFwdTable_XXh_REC•

RT1_AclInTable_Xh_REC•

RT1_AclOutTable_Xh_REC

9.1.6

Additional Services of a POWERLINK Router

Besides the data transport service between the POWERLINK and the normal Ethernet network, the
POWERLINK Router may offer extended services. These are:•

Precision Time Protocol (IEEE 1588) boundary clock functionality,•

BOOTP/DHCP Relay,•

Address Allocation DHCP (Option 82),EPSG DS 301 V1.5.1

-317-

•

Enhanced security mechanisms such as IEEE 802.1X-2001 Port-Based Network AccessControl Virtual Private Network (VPN) Server, Intrusion Detection.

•

DNS Server / Cache

9.1.7

Object description

9.1.7.1

Object 1E80h: RT1_EplRouter_REC

RT1_EplRouter_REC specifies attributes for POWERLINK Router configuration. This object shall only
be implemented for routing type 1.
Index
Name
Data Type•

Object TypeRECORD

Category

Conditional

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1E80h
RT1_EplRouter_REC
RT1_EplRouter_TYPE

00h
NumberOfEntries2
2

Sub-Index 01h: EnableNat_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

01h
EnableNat_BOOL
BOOLEANBOOLEAN
TRUE

Enables or disables the Network Address Translation on the POWERLINK Router.
•

Sub-Index 02h: EnablePacketFiltering_BOOL
Sub-Index
Name
Data Type
Value Range
Default Value

02h
EnablePacketFiltering_BOOL
BOOLEANBOOLEAN
TRUE

Category
AccessPDO Mapping

M
rws
No

Depending on the value of EnablePacketFiltering_BOOL, the Packet Filer on the POWERLINK
Router is enabled or disabled.

9.1.7.2

Object 1E90h .. 1ECFh:
RT1_IpRoutingTable_XXh_REC

The RT1_IpRoutingTable_XXh_REC object is a subset of RFC1354, which defines the routers
forwarding table. The routing table shall have 64 entries that may be configured via SDO.
To allow access by name “_XXh” shall be replaced by a name index. Name index shall be “_00h” ifobject index is 1E90h. It shall be incremented up to “_3Fh” corresponding to object index 1ECF h. Thisobject shall only be implemented for routing type 1.

EPSG DS 301 V1.5.1
Index
Name
Data Type•

1E90h .. 1ECFh
RT1_IpRoutingTable_XXh_REC
RT1_IpRoutingTable_TYPE

Object TypeRECORD

Category

Conditional

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

-318-

00h
NumberOfEntries
7
7

Sub-Index 01h: IpForwardDest_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

01h
IpForwardDest_IPAD
IP_ADDRESSIP_ADDRESS-

The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default
route. This object may not take a Multicast (Class D) address value. Any assignment (implicit orotherwise) of an instance of this object to a value x must be rejected if the bitwise logical-ANDof x with the value of the corresponding instance of the IpForwardMask_IPAD object is notequal to x.
•

Sub-Index 02h: IpForwardMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
IpForwardMask_IPAD
IP_ADDRESSIP_ADDRESS
0.0.0.0

Category
AccessPDO Mapping

M
rws
No

Indicate the mask to be logical-ANDed with the destination address before being compared to
the value in the IpForwardDest_IPAD field. For those systems that do not support arbitrary
subnet masks, an agent constructs the value of the IpForwardMask_IPAD by reference to the IP
Address Class. Any assignment (implicit or otherwise) of an instance of this object to a value x
must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of
the IpForwardDest_IPAD object is not equal to IpForwardDest_IPAD.
•

Sub-Index 03h: IpForwardNextHop_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
IpForwardNextHop_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

On remote routes, the address of the next system en route; Otherwise, 0.0.0.0.

EPSG DS 301 V1.5.1
•

-319-

Sub-Index 04h: IpForwardType_U8
Sub-Index
Name
Data Type
Value Range

Default Value

04h
IpForwardType_U8
UNSIGNED8
Other (1), -- not specified
invalid (2), -- logically deleted
local (3), -- local interface
remote (4), -- remote destination
invalid (2)Category
AccessM
rws

PDO MappingNo

The type of route. Note that local(3) refers to a route for which the next hop is the finaldestination; remote(4) refers to a route for which the next hop is not the final destination. Setting
this object to the value invalid(2) has the effect of invalidating the corresponding entry in the
IpForwardTable_REC object. That is, it effectively disassociates the destination identified withsaid entry from the route identified with said entry. It is an implementation-specific matter as towhether the agent removes an invalidated entry from the table. Accordingly, management
nodes must be prepared to receive tabular information from agents that corresponds to entries
not currently in use. Proper interpretation of such entries requires examination of the relevant
IpForwardType_U8 object.
•

Sub-Index 05h: IpForwardAge_U32
Sub-Index
Name
Data Type
Value Range
Default Value

05h
IpForwardAge_U32
UNSIGNED32
UNSIGNED32-

Category
AccessPDO Mapping

M
ro
No

The number of seconds since this route was last updated or otherwise determined to be correct.
Note that no semantics of `too old’ can be implied except through knowledge of the routing
protocol by which the route was learned.
•

Sub-Index 06h: IpForwardItfIndex_U16
Sub-Index
Name
Data Type
Value Range
Default Value

06h
IpForwardItfIndex_U16
UNSIGNED16
UNSIGNED16-

Category
AccessPDO Mapping

M
rws
No

The IpForwardItfIndex_U16 identifies the local interface (NMT_LocItfGroupN_REC.ItfIndex_U16) through which the next hop of this route should be reached.
•

Sub-Index 07h: IpForwardMetric1_S32
Sub-Index
Name
Data Type
Value Range
Default Value

07h
IpForwardMetric1_S32
INTEGER32
INTEGER32-1

Category
AccessPDO Mapping

M
rws
No

An alternate routing metric for this route. If this metric is not used, its value should be set to -1.
A metric indicates the cost of using a route, which is typically the number of hops to the IP
destination. Anything on the local subnet is one hop, and each router crossed after that is anadditional hop. If there are multiple routes to the same destination with different metrics, theroute with the lowest metric is selected.

9.1.7.3

Object 1D00h .. 1DFFh: RT1_NatTable_XXh_REC

This object specifies the NAT table located on the POWERLINK Router for bidirectional (1to1) NAT.
The NAT table shall have 256 entries that may be configured via SDO.

EPSG DS 301 V1.5.1-320-

To allow access by name “_XXh” shall be replaced by a name index. Name index shall be “_00h” ifobject index is 1D00h. It shall be incremented up to “_FFh” corresponding to object index 1DFFh. Thisobject shall only be implemented for routing type 1.
Index
Name
Data Type•

Object TypeRECORD

Category

Conditional

AccessPDO MappingroNoCategory
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

1D00h .. 1DFFh
RT1_NatTable_XXh_REC
RT1_NatTable_TYPE

00h
NumberOfEntries
44

Sub-Index 01h: EplIpAddr_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

01h
EplIpAddr_IPAD
IP_ADDRESSIP_ADDRESS-

StaticEplIpAddr_IPAD contains the IP address to the POWERLINK network.
•

Sub-Index 02h: ExtIpAddr_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
ExtIpAddr_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

StaticExtIpAddr_IPAD contains the IP address to the external network.
•

Sub-Index 03h: Mask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
Mask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

This is the Network-mask for EplIpAddr_IPAD and ExtIpAddr_IPAD. Bidirectional NAT only
works for single hosts or IP-address ranges which are equal in size for source and destination.
Thus only one mask is needed.
•

Sub-Index 04h: Type_U8
Sub-Index
Name
Data Type
Value Range

Default Value

04h
Type_U8UNSIGNED8other (1), -- not specified
invalid (2), -- logically deletedbidirectional-nat (3) – bidirectional NAT
invalid (2)Category
AccessM
rws

PDO Mapping No

Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in
the Type_U8 object. That is, it effectively disassociates the respective entry from Table_REC. It
is an implementation-specific matter as to whether the agent removes an invalidated entry fromthe table. Accordingly, management nodes must be prepared to receive tabular informationEPSG DS 301 V1.5.1-321-from agents that corresponds to entries not currently in use. Proper interpretation of such
entries requires examination of the relevant Type_U8.

9.1.7.4

Object 1E81h: RT1_SecurityGroup_REC

The RT1_SecurityGroup_REC contains information about the security settings of the POWERLINK
Router. This object shall only be implemented for routing type 1.
Index
Name
Data Type•

Object TypeRECORD

Category

Conditional

AccessPDO Mapping

const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

•

1E81h
RT1_SecurityGroup_REC
RT1_SecurityGroup_TYPE

00h
NumberOfEntries
3
3

Sub-Index 01h: FwdTablePolicy_U8
Sub-Index
Name
Data Type
Value Range

Default Value

01h
FwdTablePolicy_U8
UNSIGNED8
accept (1)drop (2)reject (3)acceptCategory
AccessM
rws

PDO Mapping No

FwdTablePolicy_U8 specifies the default policy of the FORWARD table(RT1_AclFwdTable_XXh_REC).
•

Sub-Index 02h: InTablePolicy_U8
Sub-Index
Name
Data Type
Value Range

Default Value

02h
InTablePolicy_U8
UNSIGNED8
accept (1)drop (2)reject (3)acceptCategory
AccessM
rws

PDO Mapping No

InTablePolicy_U8 specifies the default policy of the INPUT table (RT1_AclInTable_Xh_REC).
•

Sub-Index 03h: OutTablePolicy_U8
Sub-Index
Name
Data Type
Value Range

Default Value

03h
OutTablePolicy_U8
UNSIGNED8
accept (1)drop (2)reject (3)acceptCategory
AccessM
rws

PDO Mapping No

OutTablePolicy_U8 specifies the default policy of the OUTPUT table(RT1_AclOutTable_Xh_REC).

9.1.7.5

Object 1B00h .. 1BFFh: RT1_AclFwdTable_XXh_REC

This object specifies the Access Control List (ACL) for the FORWARD table located on the
POWERLINK Router – see 9.1.5.1. The FORWARD table shall have 256 entries that may be
configured via SDO.

EPSG DS 301 V1.5.1-322-

To allow access by name “_XXh” shall be replaced by a name index. Name index shall be “_00h” ifobject index is 1B00h. It shall be incremented up to “_3Fh” corresponding to object index 1BFFh. Thisobject shall only be implemented for routing type 1.
Index
Name
Data Type•

Object TypeRECORD

Category

Conditional

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

1B00h .. 1BFFh
RT1_AclFwdTable_XXh_REC
RT1_AclTable_TYPE

00h
NumberOfEntries
99

Sub-Index 01h: SrcIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

01h
SrcIp_IPAD
IP_ADDRESSIP_ADDRESS-

SrcIp_IPAD specifies a plain source IP address for the respective entry. A value of 0.0.0.0 anda SrcMask_IPAD of 0.0.0.0 shall indicate any IP address.
•

Sub-Index 02h: SrcMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
SrcMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

SrcMask_IPAD is the network mask to the according source IP address SrcIp_IPAD for therespective entry. A value of 0.0.0.0 for SrcIp_IPAD and a SrcMask_IPAD of 0.0.0.0 shallindicate any IP address.
•

Sub-Index 03h: DstIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
DstIp_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstIp_IPAD specifies a plain destination IP address for the respective entry. A value of 0.0.0.0
and a DstMask_IPAD of 0.0.0.0 shall indicate any IP address.
•

Sub-Index 04h: DstMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

04h
DstMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstMask_IPAD is the network mask to the according destination IP address DstIp_IPAD for therespective entry. A value of 0.0.0.0 for DstIp_IPAD and a DstMask_IPAD of 0.0.0.0 shallindicate any IP address.

EPSG DS 301 V1.5.1
•

-323-

Sub-Index 05h: Protocol_U8
Sub-Index
Name
Data Type
Value Range
Default Value

05h
Protocol_U8
UNSIGNED8UNSIGNED80

Category
AccessPDO Mapping

M
rws
No

The protocol of the rule or the packet to check. In the Internet Protocol version 4 (Ipv4)[RFC791] there is a field, called “Protocol”, to identify the next level protocol. This is an 8 bit
field. The specified protocol is a numeric number listed in
http://www.iana.org/assignments/protocol-numbers. The number zero is equivalent to all
protocols.
•

Sub-Index 06h: SrcPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value

06h
SrcPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

SrcPort_U16 specifies the source port if the protocol (Protocol_U8) TCP or UDP is specified. A
value of zero indicates any protocol.
•

Sub-Index 07h: DstPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value07h
DstPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

DstPort_U16 contains the destination port if the protocol (Protocol_U8) TCP or UDP is
specified. A value of zero indicates any protocol.
•

Sub-Index 08h: SrcMac_MAC
Sub-Index
Name
Data Type
Value Range
Default Value

08h
SrcMac_MAC
MAC_ADDRESS
MAC_ADDRESS
00:00:00:00:00:00

Category
AccessPDO Mapping

M
rws
No

Match source MAC address. A value of 00:00:00:00:00:00 specifies any source MAC.
•

Sub-Index 09h: Target_U8
Sub-Index
Name
Data Type
Value Range

Default Value

09h
Target_U8
UNSIGNED8
Invalid (0)accept (1)drop (2)reject (3)Invalid (0)Category
AccessM
rws

PDO MappingNo

Specifies the target of the rule. If the value is zero, the entry shall be invalid. If the rule matches
the target, the value is either accept, drop or reject.

EPSG DS 301 V1.5.1

9.1.7.6-324-

Object 1ED0h .. 1EDFh: RT1_AclInTable_Xh_REC

This object specifies the Access Control List (ACL) for the INPUT table located on the POWERLINK
Router – see 9.1.5.1. The INPUT table shall have 16 entries that may be configured via SDO.
To allow access by name “_Xh” shall be replaced by a name index. Name index shall be “_0h” ifobject index is 1ED0h. It shall be incremented up to “_Fh” corresponding to object index 1EDFh. Thisobject shall only be implemented for routing type 1.
Index
Name
Data Type•

Object TypeRECORD

Category

Conditional

AccessPDO Mapping

const
No

Category
AccessPDO Mapping

M
rws
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

1ED0h .. 1EDFh
RT1_AclInTable_Xh_REC
RT1_AclTable_TYPE

00h
NumberOfEntries
99

Sub-Index 01h: SrcIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

01h
SrcIp_IPAD
IP_ADDRESSIP_ADDRESS-

SrcIp_IPAD contains a plain source IP address for the respective entry. A value of 0.0.0.0 and a
SrcMask_IPAD of 0.0.0.0 shall indicate any IP address.
•

Sub-Index 02h: SrcMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
SrcMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

SrcMask_IPAD is the network mask to the according source IP address SrcIp_IPAD for therespective entry. A value of 0.0.0.0 for SrcIp_IPAD and a SrcMask_IPAD of 0.0.0.0 shallindicate any IP address.
•

Sub-Index 03h: DstIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
DstIp_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstIp_IPAD specifies a plain destination IP address for the respective entry. A value of 0.0.0.0
and a DstMask_IPAD of 0.0.0.0 shall indicate any IP address.

EPSG DS 301 V1.5.1
•

-325-

Sub-Index 04h: DstMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

04h
DstMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstMask_IPAD is the network mask to the according destination IP address DstIp_IPAD for therespective entry. A value of 0.0.0.0 for DstIp_IPAD and a DstMask_IPAD of 0.0.0.0 shallindicate any IP address.
•

Sub-Index 05h: Protocol_U8
Sub-Index
Name
Data Type
Value Range
Default Value

05h
Protocol_U8
UNSIGNED8UNSIGNED80

Category
AccessPDO Mapping

M
rws
No

The protocol of the rule or the packet to check. In the Internet Protocol version 4 (Ipv4)[RFC791] there is a field, called “Protocol”, to identify the next level protocol. This is an 8 bit
field. The specified protocol is a numeric number listed in
http://www.iana.org/assignments/protocol-numbers. The number zero is equivalent to all
protocols.
•

Sub-Index 06h: SrcPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value

06h
SrcPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

SrcPort_U16 specifies the source port if the protocol (Protocol_U8) TCP or UDP is specified. A
value of zero indicates any protocol.
•

Sub-Index 07h: DstPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value07h
DstPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

DstPort_U16 contains the destination port if the protocol (Protocol_U8) TCP or UDP is
specified. A value of zero indicates any protocol.
•

Sub-Index 08h: SrcMac_MAC
Sub-Index
Name
Data Type
Value Range
Default Value

08h
SrcMac_MAC
MAC_ADDRESS
MAC_ADDRESS
00:00:00:00:00:00

Category
AccessPDO Mapping

M
rws
No

Match source MAC address. A value of 00:00:00:00:00:00 specifies any source MAC.

EPSG DS 301 V1.5.1
•

-326-

Sub-Index 09h: Target_U8
Sub-Index
Name
Data Type
Value Range

Default Value

09h
Target_U8
UNSIGNED8
Invalid (0)accept (1)drop (2)reject (3)Invalid (0)Category
AccessM
rws

PDO MappingNo

Specifies the target of the rule. If the value is zero, the entry shall be invalid. If the rule matches
the target, the value is either accept, drop or reject.

9.1.7.7

Object 1EE0h .. 1EEFh: RT1_AclOutTable_Xh_REC

This object specifies the Access Control List (ACL) for the OUTPUT table located on the POWERLINK
Router – see 9.1.5.1. The routing table shall have 16 entries that may be configured via SDO.
To allow access by name “_Xh” shall be replaced by a name index. Name index shall be “_0h” ifobject index is 1EE0h. It shall be incremented up to “_Fh” corresponding to object index 1EEFh. Thisobject shall only be implemented for routing type 1.
Index
Name
Data Type•

1EE0h .. 1EEFh
RT1_AclOutTable_Xh_REC
RT1_AclTable_TYPE

Object TypeRECORD

Category

Conditional

AccessPDO Mapping

const
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value

00h
NumberOfEntries
99

EPSG DS 301 V1.5.1

•

-327-

Sub-Index 01h: SrcIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

01h
SrcIp_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

SrcIp_IPAD specifies a plain source IP address for the respective entry. A value of 0.0.0.0 anda SrcMask_IPAD of 0.0.0.0 shall indicate any IP address.
•

Sub-Index 02h: SrcMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

02h
SrcMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

SrcMask_IPAD is the network mask to the according source IP address SrcIp_IPAD for therespective entry. A value of 0.0.0.0 for SrcIp_IPAD and a SrcMask_IPAD of 0.0.0.0 shallindicate any IP address.
•

Sub-Index 03h: DstIp_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

03h
DstIp_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstIp_IPAD specifies a plain destination IP address for the respective entry. A value of 0.0.0.0
and a DstMask_IPAD of 0.0.0.0 shall indicate any IP address.
•

Sub-Index 04h: DstMask_IPAD
Sub-Index
Name
Data Type
Value Range
Default Value

04h
DstMask_IPAD
IP_ADDRESSIP_ADDRESS-

Category
AccessPDO Mapping

M
rws
No

DstMask_IPAD is the network mask to the according destination IP address DstIp_IPAD for therespective entry. A value of 0.0.0.0 for DstIp_IPAD and a DstMask_IPAD of 0.0.0.0 shallindicate any IP address.
•

Sub-Index 05h: Protocol_U8
Sub-Index
Name
Data Type
Value Range
Default Value

05h
Protocol_U8
UNSIGNED8UNSIGNED80

Category
AccessPDO Mapping

M
rws
No

The protocol of the rule or the packet to check. In the Internet Protocol version 4 (Ipv4)[RFC791] there is a field, called “Protocol”, to identify the next level protocol. This is an 8 bit
field. The specified protocol is a numeric number listed in
http://www.iana.org/assignments/protocol-numbers. The number zero is equivalent to all
protocols.

EPSG DS 301 V1.5.1
•

-328-

Sub-Index 06h: SrcPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value

06h
SrcPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

SrcPort_U16 specifies the source port if the protocol (Protocol_U8) TCP or UDP is specified. A
value of zero indicates any protocol.
•

Sub-Index 07h: DstPort_U16
Sub-Index
Name
Data Type
Value Range
Default Value07h
DstPort_U16
UNSIGNED16
UNSIGNED160

Category
AccessPDO Mapping

M
rws
No

DstPort_U16 contains the destination port if the protocol (Protocol_U8) TCP or UDP is
specified. A value of zero indicates any protocol.
•

Sub-Index 08h: SrcMac_MAC
Sub-Index
Name
Data Type
Value Range
Default Value

08h
SrcMac_MAC
MAC_ADDRESS
MAC_ADDRESS
00:00:00:00:00:00

Category
AccessPDO Mapping

M
rws
No

Match source MAC address. A value of 00:00:00:00:00:00 specifies any source MAC.
•

Sub-Index 09h: Target_U8
Sub-Index
Name
Data Type
Value Range

Default Value

09h
Target_U8
UNSIGNED8
Invalid (0)accept (1)drop (2)reject (3)Invalid (0)Category
AccessM
rws

PDO MappingNo

Specifies the target of the rule. If the value is zero, the entry shall be invalid. If the rule matches
the target, the value is either accept, drop or reject.

EPSG DS 301 V1.5.1-329-

9.1.7.8

Router Type I Object Types

9.1.7.8.1

Object 0430h: RT1_EplRouter_TYPE

Index
Name

0430h
RT1_EplRouter_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h

Component Name
NumberOfEntries
EnableNat_BOOL
EnablePacketFiltering_BOOL

Value
02h
0001h
0001h

Data Type9.1.7.8.2

BOOLEANBOOLEAN

Object 0431h: RT1_IpRoutingTable_TYPE

Index
Name

0431h
RT1_IpRoutingTable_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h
05h
06h
07h

Component Name
NumberOfEntries
IpForwardDest_IPAD
IpForwardMask_IPAD
IpForwardNextHop_IPAD
IpForwardType_U8
IpForwardAge_U32
IpForwardItfIndex_U16
IpForwardMetric1_S32

Value
07h
0402h
0402h
0402h
0005h
0007h
0006h
0004h

Data Type9.1.7.8.3

IP_ADDRESSIP_ADDRESSIP_ADDRESSUNSIGNED8UNSIGNED32
UNSIGNED16
INTEGER32

Object 0432h: RT1_NatTable_TYPE

Index
Name

0432h
RT1_NatTable_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h
04h

Component Name
NumberOfEntries
EplIpAddr_IPAD
ExtIpAddr_IPAD
Mask_IPAD
Type_U8

Value
04h
0402h
0402h
0402h
0005h

Data Type9.1.7.8.4

IP_ADDRESSIP_ADDRESSIP_ADDRESSUNSIGNED8

Object 0433h: RT1_SecurityGroup_TYPE

Index
Name

0433h
RT1_SecurityGroup_TYPE

Object TypeDEFSTRUCT

Sub-Index
00h
01h
02h
03h

Component Name
NumberOfEntries
FwdTablePolicy_U8
InTablePolicy_U8
OutTablePolicy_U8

Value
03h
0005h
0005h
0005h

Data Type9.1.7.8.5

UNSIGNED8UNSIGNED8UNSIGNED8

Object 0434h: RT1_AclTable_TYPE

Index
Name

0434h
RT1_AclTable_TYPE

Object Type

Sub-Index
00h
01h

Component Name
NumberOfEntries
SrcIp_IPAD

Value
09h
0402h

DEFSTRUCT
Data Type
IP_ADDRESSEPSG DS 301 V1.5.1
02h
03h
04h
05h
06h
07h
08h
09h

9.1.8

-330-

SrcMask_IPAD
DstIp_IPAD
DstMask_IPAD
Protocol_U8
SrcPort_U16
DstPort_U16
SrcMac_MAC
Target_U8

0402h
0402h
0402h
0005h
0006h
0006h
0401h
0005h

IP_ADDRESSIP_ADDRESSIP_ADDRESSUNSIGNED8UNSIGNED16
UNSIGNED16
MAC_ADDRESSUNSIGNED8POWERLINK Router MIB

The POWERLINK Router Management Information Base (MIB) specifies the managed objects which
are accessible via SNMP.

9.2

Routing Type 2

A POWERLINK Router Type 2 is a coupling element that allows communication between nodes in a
POWERLINK network and nodes in an CANopen network.

POWERLINK

Fig. 113.

POWERLINK
RouterType 2

CANopenPOWERLINK router type 2

Routing Type 2 will provide CANopen compliant SDO communication between POWERLINK and
CANopen nodes.
CANopen to CANopen cross traffic over a POWERLINK based Machine Network (see Fig. 107) will be
provided.
Access from the Factory Floor Network and further IP based networks (see Fig. 107) to CANopen
nodes via POWERLINK Router Type 1 and POWERLINK Router Type 2 will be possible.
POWERLINK Routing Type 2 will be specified by a separate standard.
Routing Type 2 is optional. Support shall be indicated by D_RT2_RT2Support_BOOL.

EPSG DS 301 V1.5.1-331-

Indicators

10

Each POWERLINK node shall support:•
either two LEDsoa red ERROR LEDoa green STATUS LED•
or a combination of both using one bicolor (green/red) LED called S/E LED.
The red subfunction of the S/E LED is equivalent to the ERROR LED, the green one to the
STATUS LED.
The following POWERLINK specific LEDs may be additionally used:•
per nodeo•Transmit data (TX LED): yellow
per port:ooooReceive data (RX LED): yellowooEthernet Link/Data Activity (LINK/DATA ACTIVITY LED) bicolor (green/yellow) LED or

Ethernet Link (LINK LED): green
Collision (COL LED): red (recommended)

For the LINK LED and the COL LED, a bicolor (green/red) LED (L/C LED) may be used.
Alternative following POWERLINK specific LED may be additionally used:•
per port:

10.1

Ethernet Link/Data Activity (LINK/DATA ACTIVITY LED) green LED

Indicator states and flash rates

The following indicator states are distinguished:
LED onLED off
LED flickering
LED blinking
LED single flash
LED double flash

LED triple flash

constantly on
constantly off
equal on and off times with a frequency of approximately 10 Hz: on for
approximately 50 ms and off for approximately 50 ms.
equal on and off times with a frequency of approximately 2,5 Hz: on for
approximately 200 ms followed by off for approximately 200 ms.
one short flash (approximately 200ms) followed by a long off phase(approximately 1000 ms).
a sequence of two short flashes (approximately 200ms), separated by an
off phase (approximately 200ms). The sequence is finished by a long offphase (approximately 1000 ms).
a sequence of three short flashes (approximately 200ms), separated by
an off phase (approximately 200ms). The sequence is finished by a longoff phase (approximately 1000 ms).

LED indicator states

EPSG DS 301 V1.5.1

10.2
•

-332-

Indicator Signaling

ERROR LEDERROR LED function is controlled by NMT state machine transitions.
PowerON

LED OFF
NMT_CT7,
NMT_GT2,
NMT_CT3,
NMT_MT5

NMT_CT11,
NMT_GT6,
NMT_MT6,
Detection of illegal node ID (optional)
LED ON

Fig. 114.

ERROR LED state machine

In case of detection of an illegal Node ID switching on the error LED is optional.
Example for an illegal Node ID: Node ID setting 240 on a CN only device.
•

STATUS LEDSTATUS LED function is controlled by NMT state machine states.
STATUS LED
LED off
LED flickering
LED single flash
LED double flash
LED triple flash
LED onLED blinking

State
NMT_GS_OFF, NMT_GS_INITIALISATION,
NMT_CS_NOT_ACTIVE / NMT_MS_NOT_ACTIVE
NMT_CS_BASIC_ETHERNETNMT_CS_PRE_OPERATIONAL_1 / NMT_MS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2 / NMT_MS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATE / NMT_MS_READY_TO_OPERATENMT_CS_OPERATIONAL / NMT_MS_OPERATIONAL
NMT_CS_STOPPED

Status LED states•

S/E LEDcombination of ERROR LED and STATUS LED,STATUS LED is dominant over the ERROR LED function, e.g. if a STATUS LED flash isrequired, the ERROR LED will be off during the flash•

TX LED
shall be LED on, when data are currently transmitted•

RX LED
shall be LED on, when data are currently received•

LINK LED
shall be LED on, when etherlink link is established•

COLLISION LED
shall be LED on, when an ethernet frame collision is recognized•

LINK/DATA ACTIVITY LED•

Bicolor (yellow/green) LED
shall be LED on green when ethernet link is established, shall be on yellow when data
received or transmitted it is allowed to indicate only the TX- or RX- direction or both, theDATA ACTIVITY LED is dominant over the LINK LED

EPSG DS 301 V1.5.1
•

10.3
•

-333-

green LED
shall be LED on green when ethernet link is established, shall be flash when data
received or transmitted it is allowed to indicate only the TX- or RX- direction or both, theDATA ACTIVITY LED is dominat over the LINK LED

Recommended labelling„BS“ or „Status“ for the STATUS LED„BE“ or „Error“ for the ERROR LED•„S/E“for the S/E LED•„Tx“ for the TX LED•„Rx“ for the RX LED•„L“ for the LINK LED•„C“ for the COLLISION LED•„L/C“ for the combined LINK LED and COL LED•„L/A”or alternatively „LS/DA” for the LINK/DATA ACTIVITY LED
Case of labelling shall not be significant, e.g. „RUN“, „run“ and „Run“ shall be equivalent.
•

EPSG DS 301 V1.5.1-334-

App. 1

Summary Object Library (normative)

App. 1.1

Object Dictionary Entries, sorted by index

Index

Name

0001h
0002h
0003h
0004h
0005h
0006h
0007h
0008h
0009h
000Ah
000Bh
000Ch
000Dh
000Fh
0010h
0011h
0012h
0013h
0014h
0015h
0016h
0018h
0019h
001Ah
001Bh
0023h
0040h
..
005Fh
0060h
..
007Fh
0080h
..
009Fh
00A0h
..
00BFh
00C0h
..
00DFh
00E0h
..
00FFh
0100h
..
011Fh

BOOLEANINTEGER8
INTEGER16
INTEGER32
UNSIGNED8UNSIGNED16
UNSIGNED32
REAL32
VISIBLE_STRING
OCTET_STRINGUNICODE_STRING
TIME_OF_DAY
TIME_DIFFERENCE
DOMAININTEGER24
REAL64
INTEGER40
INTEGER48
INTEGER56
INTEGER64
UNSIGNED24
UNSIGNED40
UNSIGNED48
UNSIGNED56
UNSIGNED64
IDENTITY
Manufacturer Specific Complex Data TypesStore

Category

Object TypeDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPEDEFTYPE
DEFSTRUCT
DEFSTRUCT

Device Profile (0) Specific Standard Data Types

DEFTYPE

Device Profile (0) Specific Complex Data Types

DEFSTRUCT

Device Profile 1 Specific Standard Data Types

DEFTYPE

Device Profile 1 Specific Complex Data Types

DEFSTRUCT

Device Profile 2 Specific Standard Data Types

DEFTYPE

Device Profile 2 Specific Complex Data Types

DEFSTRUCTEPSG DS 301 V1.5.1

-335-

Index

Name

0120h
..
013Fh
0140h
..
015Fh
0160h
..
017Fh
0180h
..
019Fh
01A0h
..
01BFh
01C0h
..
01DFh
01E0h
..
01FFh
0200h
..
021Fh
0220h
..
023Fh
0240h
..
025Fh
0401h
0402h
0403h
0420h
0422h
0424h
0425h
0426h
0427h
0428h
0429h
042Bh
042Ch
042Eh
042Fh
0430h
0431h
0432h
0433h
0434h
0435h
0437h

Device Profile 3 Specific Standard Data TypesStore

Category

Object TypeDEFTYPE

Device Profile 3 Specific Complex Data Types

DEFSTRUCT

Device Profile 4 Specific Standard Data Types

DEFTYPE

Device Profile 4 Specific Complex Data Types

DEFSTRUCT

Device Profile 5 Specific Standard Data Types

DEFTYPE

Device Profile 5 Specific Complex Data Types

DEFSTRUCT

Device Profile 6 Specific Standard Data Types

DEFTYPE

Device Profile 6 Specific Complex Data Types

DEFSTRUCT

Device Profile 7 Specific Standard Data Types

DEFTYPE

Device Profile 7 Specific Complex Data Types

DEFSTRUCT

MAC_ADDRESSIP_ADDRESSNETTIMEPDO_CommParamRecord_TYPE
SDO_ParameterRecord_TYPE
DLL_ErrorCntRec_TYPE
NWL_IpGroup_TYPE
NWL_IpAddrTable_TYPE
PDL_LocVerApplSw_TYPE
INP_ProcessImage_TYPE
NMT_ParameterStorage_TYPE
NMT_InterfaceGroup_TYPE
NMT_CycleTiming_TYPE
NMT_BootTime_TYPE
NMT_MNCycleTiming_TYPE
RT1_EplRouter_TYPE
RT1_IpRoutingTable_TYPE
RT1_NatTable_TYPE
RT1_SecurityGroup_TYPE
RT1_AclTable_TYPE
CFM_VerifyConfiguration_TYPE
DIA_NMTTelegrCount_TYPE

DEFTYPEDEFTYPEDEFTYPE
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCTEPSG DS 301 V1.5.1

-336-

Index

Name

0438h
0439h
043Ah

DIA_ERRStatistics_TYPE
NMT_EPLNodeID_TYPE
NMT_RequestCmd_TYPE

043Bh

DLL_MNRingRedundancy_TYPE used by EPSG DS302-A [1]

1000h
1001h
1003h
1006h
1008h
1009h
100Ah
1010h
1011h
1016h
1018h
1020h
1021h
1022h

NMT_DeviceType_U32
ERR_ErrorRegister_U8
ERR_History_ADOM
NMT_CycleLen_U32
NMT_ManufactDevName_VS
NMT_ManufactHwVers_VS
NMT_ManufactSwVers_VS
NMT_StoreParam_REC
NMT_RestoreDefParam_REC
NMT_ConsumerHeartbeatTime_AU32
NMT_IdentityObject_REC
CFM_VerifyConfiguration_REC
CFM_StoreDevDescrFile_DOM
CFM_StoreDevDescrFormat_U16

1027h

NMT_ChildIdentList_AU16 used by EPSG DS302-F [6]

1030h
..
1039h

NMT_InterfaceGroup_Xh_REC

1050h

DLL_RelativeLatencyDiff_AU32 used by EPSG DS302-C [3]

1101h
1102h
1200h
..
127Fh
1280h
..
12FFh
1300h
1301h
1302h
1400h
..
14FFh
1600h
..
16FFh
1800h
..
18FFh
1A00h
..
1AFFh
1B00h
..
1BFFh
1C00h

DIA_NMTTelegrCount_REC
DIA_ERRStatistics_REC
SDO_ServerContainerParam_XXh_REC

1C01h

Store

Category

Object TypeDEFSTRUCT
DEFSTRUCT
DEFSTRUCT
DEFSTRUCT

x
1-254
1-3
x
x

M
M
O
M
O
O
O
O
O
O
M
M
O
Cond

VAR
VAR
ARRAY
VAR
VAR
VAR
VAR
RECORD
RECORD
ARRAY
RECORD
RECORD
VAR
VAR

Cond

ARRAY

M(1030h)/ORECORD

Cond

ARRAY

1-4

O
O
O

RECORD
RECORD
RECORD

SDO_ClientContainerParam_XXh_REC

1-4

ORECORD

SDO_SequLayerTimeout_U32
SDO_CmdLayerTimeout_U32
SDO_SequLayerNoAck_U32
PDO_RxCommParam_XXh_REC

x
x
x
1-2

M
O
O
Cond

VAR
VAR
VAR
RECORD

PDO_RxMappParam_XXh_AU64

0-254 Cond

ARRAY

PDO_TxCommParam_XXh_REC

1-2

RECORDPDO_TxMappParam_XXh_AU64

0-254 Cond

ARRAY

RT1_AclFwdTable_XXh_REC

1-9

Cond

RECORD

DLL_MNCRCError_REC

3

RECORD

DLL_MNCollision_REC

3

MN: M
CN: MN: O

8-9

Cond

RECORDEPSG DS 301 V1.5.1
Index

-337-

Name

1C02h

DLL_MNCycTimeExceed_REC

1C03h

DLL_MNLossOfLinkCum_U32

1C04h

DLL_MNCNLatePResCumCnt_AU32

1C05h

DLL_MNCNLatePResThrCnt_AU32

1C06h

DLL_MNCNLatePResThreshold_AU32

1C07h

DLL_MNCNLossPResCumCnt_AU32

1C08h

DLL_MNCNLossPResThrCnt_AU32

1C09h

DLL_MNCNLossPResThreshold_AU32

1C0Ah DLL_CNCollision_REC
1C0Bh DLL_CNLossSoC_REC
1C0Ch DLL_CNLossSoA_REC
1C0Dh DLL_CNLossPReq_REC
1C0Eh DLL_CNSoCJitter_REC
1C0Fh

DLL_CNCRCError_REC

1C10h

DLL_CNLossOfLinkCum_U32

1C12h

DLL_MNCycleSuspendNumber_U32

1C13h

DLL_CNSoCJitterRange_U32

1C14h

DLL_CNLossOfSocTolerance_U32

1C15h

DLL_MNLossStatusResCumCnt_AU32

1C16h

DLL_MNLossStatusResThrCnt_AU32

1C17h

DLL_MNLossStatusResThreshold_AU32

1C40h

DLL_MNRingRedundancy_REC used by EPSG DS302-A [1]

1C80h
1C81h
1D00h
..
1DFFh
1E40h
..
1E49h
1E4Ah

PDO_ErrMapVers_OSTR
PDO_ErrShort_RX_OSTR
RT1_NatTable_XXh_REC

Store

Category

CN: 3
MN: O
CN: MN: Cond
CN: MN: Cond
CN: MN: Cond
CN: 1-254 MN: Cond
CN: MN: O
CN: MN: M
CN: 1-254 MN: M
CN: 3
MN: CN: O
3
MN: CN: M
3
MN: CN: Cond3
MN: CN: Cond3
MN: CN: Cond3
MN: CN: M
MN: CN: Cond
x
MN: M
CN: x
MN: CN: Condx
MN: CN: M
MN: O
CN: MN: M
CN: 1-254 MN: M
CN: -Object TypeRECORD
VAR
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
RECORD
RECORD
RECORD
RECORD
RECORD
RECORD
VAR
VAR
VAR
VAR
ARRAY
ARRAY
ARRAY

MN: Cond
CN: -RECORD

1-4

O
O
Cond

VAR
VAR
RECORDNWL_IpAddrTable_Xh_REC(2,3,)
5Cond(1E40h)/O

RECORDNWL_IpGroup_REC(1,) 2

Cond

RECORDEPSG DS 301 V1.5.1

-338-

Index

Name

Store

Category

Object Type

1E80h
1E81h
1E90h
..
1ECFh
1ED0h
..
1EDFh
1EE0h
..
1EEFh
1F20h

RT1_EplRouter_REC
RT1_SecurityGroup_REC
RT1_IpRoutingTable_XXh_REC

1,2
1-3
1-4,
6,7

Cond
Cond
Cond

RECORD
RECORD
RECORD

RT1_AclInTable_Xh_REC

1-9

Cond

RECORD

RT1_AclOutTable_Xh_REC

1-9

Cond

RECORD

CFM_StoreDcfList_ADOM

ARRAY

1F21h

CFM_DcfStorageFormatList_AU8

1F22h

CFM_ConciseDcfList_ADOM

1F23h

CFM_StoreDevDescrFileList_ADOM

1F24h

CFM_DevDescrFileFormatList_AU8

1F25h

CFM_ConfCNRequest_AU32

1F26h

CFM_ExpConfDateList_AU32

1F27h

CFM_ExpConfTimeList_AU32

1F28h

CFM_ExpConfIdList_AU32

1F50h
1F51h
1F52h
1F53h
1F54h

PDL_DownloadProgData_ADOM
PDL_ProgCtrl_AU8
PDL_LocVerApplSw_REC
PDL_MnExpAppSwDateList_AU32
PDL_MnExpAppSwTimeList_AU32

1-254 MN: Cond
CN: 1-254 MN: O
CN: 1-254 MN: O
CN: 1-254 MN: Cond
CN: 1-254 MN: O
CN: MN: O
CN: 1-254 MN: O
CN: 1-254 MN: O
CN: 1-254 MN: O
CN: O
Cond
Cond
0-254 Cond
0-254 Cond

1F55h

PDL_DownloadChildProgList_AU16 used by EPSG DS302-F [6]

Cond

ARRAY

1F70h
1F80h

INP_ProcessImage_REC
NMT_StartUp_U32

xRECORDVAR

1F81h

NMT_NodeAssignment_AU32

x

1F82h
1F83h
1F84h

NMT_FeatureFlags_U32
NMT_EPLVersion_U8
NMT_MNDeviceTypeIdList_AU32

0-254

1F85h

NMT_MNVendorIdList_AU32

0-254

1F86h

NMT_MNProductCodeList_AU32

0-254

1F87h

NMT_MNRevisionNoList_AU32

0-254

1F88h

NMT_MNSerialNoList_AU32

0-254

1F89h

NMT_BootTime_REC

1-9

O
MN: M
CN: MN: M
CN: CondM
M
MN: M
CN: MN: O
CN: MN: O
CN: MN: O
CN: MN: O
CN: MN: M

ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
RECORD
ARRAY
ARRAY

ARRAY
VAR
VAR
ARRAY
ARRAY
ARRAY
ARRAY
ARRAY
RECORDEPSG DS 301 V1.5.1
Index

Name

1F8Ah

NMT_MNCycleTiming_REC

1F8Bh

NMT_MNPReqPayloadLimitList_AU16

1F8Ch
1F8Dh

NMT_CurrNMTState_U8
NMT_PresPayloadLimitList_AU16

1F8Eh

NMT_MNNodeCurrState_AU8

1F8Fh

-339-

NMT_MNNodeExpState_AU8

1F92h

NMT_MNCNPResTimeout_AU32

1F93h

NMT_EPLNodeID_REC

1F94h

NMT_PdoNodeAssign_AU8 used by EPSG DS302-D [4]1F98h

NMT_CycleTiming_REC

1F99h

NMT_CNBasicEthernetTimeout_U32

1F9Ah
1F9Bh
1F9Ch

Store

Category

CN: 1,2,4 MN: M
CN: 0-254 MN: M
CN: M
0-254 MN: M
CN: O
MN: M
CN: MN: O
CN: 0-254 MN: M
CN: 3
M
4,5,
7-9
x

Object Type

VAR
ARRAY
VAR

ARRAY
ARRAY
ARRAY
ARRAY
RECORD

Cond

ARRAY

M

RECORDVAR

NMT_HostName_VSTR
NMT_MultiplCycleAssign_AU8
NMT_IsochrSlotAssign_AU8

MN: CN: Mx
Cond0-254 Cond
0-254 O

1F9Eh
1F9Fh

NMT_ResetCmd_U8
NMT_RequestCmd_REC

-

M
MN: M
CN: -

VAR

1FA0h
1FA1h

NMT_PredecessorNodeNumberList_AU32 used by EPSG DS302-E [5]
NMT_PredecessorHubPortList_AU32 used by EPSG DS302-E [5]

Cond
Cond

ARRAY
ARRAY

VAR
ARRAY
ARRAY
RECORDEPSG DS 301 V1.5.1

App. 1.2-340-

Object Dictionary Entries, sorted by name

Name

Index

BOOLEAN
CFM_ConciseDcfList_ADOM
CFM_ConfCNRequest_AU32
CFM_DcfStorageFormatList_AU8
CFM_DevDescrFileFormatList_AU8
CFM_ExpConfDateList_AU32
CFM_ExpConfIdList_AU32
CFM_ExpConfTimeList_AU32
CFM_StoreDcfList_ADOM
CFM_StoreDevDescrFile_DOM
CFM_StoreDevDescrFileList_ADOM
CFM_StoreDevDescrFormat_U16
CFM_VerifyConfiguration_REC
CFM_VerifyConfiguration_TYPE
Device Profile (0) Specific Complex Data Types

0001h DEFTYPE
1F22h ARRAY
1F25h ARRAY
1F21h ARRAY
1F24h ARRAY
1F26h ARRAY
1F28h ARRAY
1F27h ARRAY
1F20h ARRAY1021h VAR
1F23h ARRAY1022h VAR
1020h RECORD
0435h DEFSTRUCT
0080h DEFSTRUCT..
009Fh
0060h DEFTYPE..
007Fh
00C0h DEFSTRUCT..
00DFh
00A0h DEFTYPE..
00BFh
0100h DEFSTRUCT..
011Fh
00E0h DEFTYPE..
00FFh
0140h DEFSTRUCT..
015Fh
0120h DEFTYPE..
013Fh
0180h DEFSTRUCT..
019Fh
0160h DEFTYPE..
017Fh
01C0h DEFSTRUCT..
01DFh
01A0h DEFTYPE
..
01BFh

Device Profile (0) Specific Standard Data Types

Device Profile 1 Specific Complex Data Types

Device Profile 1 Specific Standard Data Types

Device Profile 2 Specific Complex Data Types

Device Profile 2 Specific Standard Data Types

Device Profile 3 Specific Complex Data Types

Device Profile 3 Specific Standard Data Types

Device Profile 4 Specific Complex Data Types

Device Profile 4 Specific Standard Data Types

Device Profile 5 Specific Complex Data Types

Device Profile 5 Specific Standard Data Types

Object TypeEPSG DS 301 V1.5.1

-341-

Name

Index

Device Profile 6 Specific Complex Data Types

DIA_ERRStatistics_REC
DIA_ERRStatistics_TYPE
DIA_NMTTelegrCount_REC
DIA_NMTTelegrCount_TYPE
DLL_CNCollision_REC
DLL_CNCRCError_REC
DLL_CNLossOfLinkCum_U32
DLL_CNLossPReq_REC
DLL_CNLossSoA_REC
DLL_CNLossSoC_REC
DLL_CNSoCJitter_REC
DLL_CNSoCJitterRange_U32
DLL_ErrorCntRec_TYPE
DLL_CNLossOfSocTolerance_U32
DLL_MNCNLatePResCumCnt_AU32
DLL_MNCNLatePResThrCnt_AU32
DLL_MNCNLatePResThreshold_AU32
DLL_MNCNLossPResCumCnt_AU32
DLL_MNCNLossPResThrCnt_AU32
DLL_MNCNLossPResThreshold_AU32
DLL_MNCollision_REC
DLL_MNCRCError_REC
DLL_MNCycleSuspendNumber_U32
DLL_MNCycTimeExceed_REC
DLL_MNLossOfLinkCum_U32
DLL_MNLossStatusResCumCnt_AU32
DLL_MNLossStatusResThrCnt_AU32
DLL_MNLossStatusResThreshold_AU32

0200h DEFSTRUCT..
021Fh
01E0h DEFTYPE..
01FFh
0240h DEFSTRUCT..
025Fh
0220h DEFTYPE..
023Fh
1102h RECORD
0438h DEFSTRUCT1101h RECORD
0437h DEFSTRUCT
1C0Ah RECORD
1C0Fh RECORD
1C10h VAR
1C0Dh RECORD
1C0Ch RECORD
1C0Bh RECORD
1C0Eh RECORD
1C13h VAR
0424h DEFSTRUCT
1C14h VAR
1C04h ARRAY
1C05h ARRAY
1C06h ARRAY
1C07h ARRAY
1C08h ARRAY
1C09h ARRAY
1C01h RECORD
1C00h RECORD
1C12h VAR
1C02h RECORD
1C03h VAR
1C15h ARRAY
1C16h ARRAY
1C17h ARRAYDLL_MNRingRedundancy_REC used by EPSG DS302-A [1]
DLL_MNRingRedundancy_TYPE used by EPSG DS302-A [1]
DLL_RelativeLatencyDiff_AU32 used by EPSG DS302-C [3]

1C40h
043Bh
1050h

RECORD
DEFSTRUCTARRAYDOMAIN
ERR_ErrorRegister_U8
ERR_History_ADOMIDENTITYINP_ProcessImage_REC
INP_ProcessImage_TYPE
INTEGER16

000Fh
1001h
1003h
0023h
1F70h
0428h
0003h

DEFTYPE
VAR
ARRAY
DEFSTRUCTRECORD
DEFSTRUCTDEFTYPE

Device Profile 6 Specific Standard Data Types

Device Profile 7 Specific Complex Data Types

Device Profile 7 Specific Standard Data Types

Object TypeEPSG DS 301 V1.5.1

-342-

Name

Index

INTEGER24
INTEGER32
INTEGER40
INTEGER48
INTEGER56
INTEGER64
INTEGER8
IP_ADDRESS
MAC_ADDRESSManufacturer Specific Complex Data Types

0010h DEFTYPE
0004h DEFTYPE
0012h DEFTYPE
0013h DEFTYPE
0014h DEFTYPE
0015h DEFTYPE
0002h DEFTYPE
0402h DEFTYPE
0401h DEFTYPE
0040h DEFSTRUCT..
005Fh
0403h DEFTYPE
1F89h RECORD
042Eh DEFSTRUCT
1F99h VAR
1016h ARRAY
1F8Ch VAR
1006h VAR
1F98h RECORD
042Ch DEFSTRUCT
1000h VAR
1F93h RECORD
0439h DEFSTRUCT
1F83h VAR
1F82h VAR
1F9Ah VAR
1018h RECORD
042Bh DEFSTRUCT1030h RECORD..
1039h
1F9Ch ARRAY
1008h VAR
1009h VAR
100Ah VAR
1F92h ARRAY
1F8Ah VAR
042Fh DEFSTRUCT
1F84h ARRAY
1F8Eh ARRAY
1F8Fh ARRAY
1F8Bh ARRAY
1F86h ARRAY
1F87h ARRAY
1F88h ARRAY
1F85h ARRAY
1F9Bh ARRAYNETTIME
NMT_BootTime_REC
NMT_BootTime_TYPE
NMT_CNBasicEthernetTimeout_U32
NMT_ConsumerHeartbeatTime_AU32
NMT_CurrNMTState_U8
NMT_CycleLen_U32
NMT_CycleTiming_REC
NMT_CycleTiming_TYPE
NMT_DeviceType_U32
NMT_EPLNodeID_REC
NMT_EPLNodeID_TYPE
NMT_EPLVersion_U8
NMT_FeatureFlags_U32
NMT_HostName_VSTR
NMT_IdentityObject_REC
NMT_InterfaceGroup_TYPE
NMT_InterfaceGroup_Xh_REC

NMT_IsochrSlotAssign_AU8
NMT_ManufactDevName_VS
NMT_ManufactHwVers_VS
NMT_ManufactSwVers_VS
NMT_MNCNPResTimeout_AU32
NMT_MNCycleTiming_REC
NMT_MNCycleTiming_TYPE
NMT_MNDeviceTypeIdList_AU32
NMT_MNNodeCurrState_AU8
NMT_MNNodeExpState_AU8
NMT_MNPReqPayloadLimitList_AU16
NMT_MNProductCodeList_AU32
NMT_MNRevisionNoList_AU32
NMT_MNSerialNoList_AU32
NMT_MNVendorIdList_AU32
NMT_MultiplCycleAssign_AU8

Object TypeEPSG DS 301 V1.5.1

-343-

Name

Index

NMT_NodeAssignment_AU32
NMT_ParameterStorage_TYPE

1F81h ARRAY0429h DEFSTRUCTNMT_PdoNodeAssign_AU8 used by EPSG DS302-D [4]
NMT_PredecessorHubPortList used by EPSG DS302-E [5]
NMT_PredecessorNodeNumberList used by EPSG DS302-E [5]

1F94h
1FA0h
1FA1h

NMT_PresPayloadLimitList_AU16
NMT_RequestCmd_REC
NMT_RequestCmd_TYPE
NMT_ResetCmd_U8
NMT_RestoreDefParam_REC
NMT_StartUp_U32
NMT_StoreParam_REC
NWL_IpAddrTable_TYPE
NWL_IpAddrTable_Xh_REC

1F8Dh ARRAY
1F9Fh RECORD
043Ah DEFSTRUCT
1F9Eh VAR
1011h RECORD
1F80h VAR
1010h RECORD
0426h DEFSTRUCT
1E40h RECORD..
1E49h
1E4Ah RECORD
0425h DEFSTRUCT
000Ah DEFTYPE
1F50h ARRAY
1F52h RECORD
0427h DEFSTRUCT
1F53h ARRAY
1F54h ARRAY
1F51h ARRAY
0420h DEFSTRUCT
1C80h VAR
1C81h VAR
1400h RECORD..
14FFh
1600h ARRAY..
16FFh
1800h RECORD..
18FFh
1A00h ARRAY..
1AFFh
0008h DEFTYPE
0011h DEFTYPE
1B00h RECORD..
1BFFh
1ED0h RECORD..
1EDFh
1EE0h RECORD
..
1EEFh

NWL_IpGroup_REC
NWL_IpGroup_TYPE
OCTET_STRINGPDL_DownloadProgData_ADOM
PDL_LocVerApplSw_REC
PDL_LocVerApplSw_TYPE
PDL_MnExpAppSwDateList_AU32
PDL_MnExpAppSwTimeList_AU32
PDL_ProgCtrl_AU8
PDO_CommParamRecord_TYPE
PDO_ErrMapVers_OSTR
PDO_ErrShort_RX_OSTR
PDO_RxCommParam_XXh_REC

PDO_RxMappParam_XXh_AU64

PDO_TxCommParam_XXh_REC

PDO_TxMappParam_XXh_AU64

REAL32
REAL64
RT1_AclFwdTable_XXh_REC

RT1_AclInTable_Xh_REC

RT1_AclOutTable_Xh_REC

Object Type

ARRAY
ARRAY
ARRAY

EPSG DS 301 V1.5.1

-344-

Name

Index

RT1_AclTable_TYPE
RT1_EplRouter_REC
RT1_EplRouter_TYPE
RT1_IpRoutingTable_TYPE
RT1_IpRoutingTable_XXh_REC

0434h DEFSTRUCT
1E80h RECORD
0430h DEFSTRUCT
0431h DEFSTRUCT
1E90h RECORD..
1ECFh
0432h DEFSTRUCT
1D00h RECORD..
1DFFh
1E81h RECORD
0433h DEFSTRUCT
1280h RECORD..
12FFh
1301h VAR
0422h DEFSTRUCT
1302h VAR
1300h VAR
1200h RECORD..
127Fh
000Dh DEFTYPE
000Ch DEFTYPE
000Bh DEFTYPE
0006h DEFTYPE
0016h DEFTYPE
0007h DEFTYPE
0018h DEFTYPE
0019h DEFTYPE
001Ah DEFTYPE
001Bh DEFTYPE
0005h DEFTYPE
0009h DEFTYPE

RT1_NatTable_TYPE
RT1_NatTable_XXh_REC

RT1_SecurityGroup_REC
RT1_SecurityGroup_TYPE
SDO_ClientContainerParam_XXh_REC

SDO_CmdLayerTimeout_U32
SDO_ParameterRecord_TYPE
SDO_SequLayerNoAck_U32
SDO_SequLayerTimeout_U32
SDO_ServerContainerParam_XXh_REC

TIME_DIFFERENCE
TIME_OF_DAY
UNICODE_STRINGUNSIGNED16
UNSIGNED24
UNSIGNED32
UNSIGNED40
UNSIGNED48
UNSIGNED56
UNSIGNED64
UNSIGNED8VISIBLE_STRING

Object TypeEPSG DS 301 V1.5.1

App. 2-345-

Device Description Entries (normative)

Name

Description

Type

D_CFM_ConfigManager_BOOL

Ability of a node to perform Configuration Manager functions
maximum value for object DLL_CNLossOfSocTolerance_U32
node’s ability to perform control of multiplexed isochronous communication
Support of Data Link Layer Error recognition: Incorrect physical operation mode
Support of Data Link Layer Error recognition: TX / RX buffer underrun / overrun
Support of MN Data Link Layer Error recognition: Multiple MNsnode’s ability to perform CN functions
node’s ability to perform MN functions
MN’s ability to perform control of multiplexed isochronous communication
MN’s ability to transmit Presmax. boot time from cold start to NMT_MS_NOT_ACTIVEresp.
NMT_CS_NOT_ACTIVE [µs]maximum transition time of a CN from reception of
NMTEnableReadyToOperate until the CN is in state
NMT_CS_READY_TO_OPERATE [µs]CN SoC handling maximum time [ns],a subsequent PReq won’t be handled before SoC handling was finished
POWERLINK cycle time granularity [µs]Value shall be 1 µs if POWERLINK cycle time settings may be taken from acontinuum. Otherwise granularity should be a multiple of the base granularity
values 100 µs or 125 µs.
maximum POWERLINK cycle time [µs]minimum POWERLINK cycle time [µs]maximum number of history entries in the Error Signaling emergency queue(see 6.5)
maximum number of error entries (Status and History Entries) in the
StatusResponse frame (see 7.3.3.3.1)
value range: 2 .. 14
Support of Extended NMT State Command
Support of NMT Managing Command Service NMTFlushArpEntry
Device may be accessed isochronously

BOOLEANUNSIGNED32
BOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANUNSIGNED32

D_DLL_CNLossOfSoCToleranceMax_U32

D_DLL_CNFeatureMultiplex_BOOL
D_DLL_ErrBadPhysMode_BOOL
D_DLL_ErrMacBuffer_BOOL
D_DLL_ErrMNMultipleMN_BOOL
D_DLL_FeatureCN_BOOL
D_DLL_FeatureMN_BOOL
D_DLL_MNFeatureMultiplex_BOOL
D_DLL_MNFeaturePResTx_BOOL
D_NMT_BootTimeNotActive_U32
D_NMT_CNPreOp2ToReady2Op_U32

D_NMT_CNSoC2PReq_U32
D_NMT_CycleTimeGranularity_U32

D_NMT_CycleTimeMax_U32
D_NMT_CycleTimeMin_U32
D_NMT_EmergencyQueueSize_U32
D_NMT_ErrorEntries_U32

D_NMT_ExtNmtCmds_BOOL
D_NMT_FlushArpEntry_BOOL
D_NMT_Isochronous_BOOL

Category
MN CN
O
O
O
O
O
O
O
O
O
O
O
M
M
O
O
M
M

Default
MN
N
N
N
N
Y
Y
Y
-

CN
N
100000N
NNY-UNSIGNED32

-

O

-

-

UNSIGNED32

-

M

-

-

UNSIGNED32

O

O

1

1

UNSIGNED32
UNSIGNED32
UNSIGNED32

M
M
O

M
M
O

0

0

UNSIGNED32

M

M

-

-

BOOLEANBOOLEANBOOLEAN

O
O
O

O
O
O

N
N
Y

N
N
Y

EPSG DS 301 V1.5.1
D_NMT_MaxCNNodeID_U8-346-

maximum Node ID available for regular CNs
the entry provides an upper limit to the Node ID available for cross traffic PDO
reception from a regular CN
D_NMT_MaxCNNumber_U8
maximum number of supported regular CNs in the Node ID range 1 .. 239
D_NMT_MaxHeartbeats_U8
number of guard channels
D_NMT_MinRedCycleTime_U32
Minimum reduced cycle time [µs], i.e. minimum time between SoA frames
D_NMT_MNASnd2SoC_U32
minimum delay between end of reception of ASnd and start of transmission of
SoC [ns]
D_NMT_MNBasicEthernet_BOOL
support of NMT_MS_BASIC_ETHERNET
D_NMT_MNMultiplCycMax_U8
maximum number of POWERLINK cycles per multiplexed cycle
D_NMT_MNPRes2PReq_U32
delay between end of PRes reception and start of PReq transmission [ns]delay between end of reception of PRes from CNn and start of transmission of
D_NMT_MNPRes2PRes_U32
PRes by MN [ns]D_NMT_MNPResRx2SoA_U32
delay between end of reception of PRes from CNn and start of transmission of
SoA by MN [ns]D_NMT_MNPResTx2SoA_U32
delay between end of PRes transmission by MN and start of transmission of
SoA by MN [ns]delay between end of transmission of SoA and start of transmission of ASnd by
D_NMT_MNSoA2ASndTx_U32
MN [ns]
D_NMT_MNSoC2PReq_U32
MN minimum delay between end of SoC transmission and start of PReq
transmission [ns]D_NMT_NetHostNameSet_BOOL
Support of NMT Managing Command Service NMTNetHostNameSet
D_NMT_NetTime_BOOL
Support of NetTime transmission via SoC
D_NMT_NetTimeIsRealTime_BOOL
Support of real time via NetTime in SoC
D_NMT_NodeIDByHW_BOOL
Ability of a node to support Node ID setup by HW
D_NMT_NodeIDBySW_BOOL
Ability of a node to support Node ID setup by SW
D_NMT_ProductCode_U32
Identity Object Product Code
D_NMT_PublishActiveNodes_BOOL
Support of NMT Info service NMTPublishActiveNodes
D_NMT_PublishConfigNodes_BOOL
Support of NMT Info service NMTPublishConfiguredNodes
D_NMT_PublishEmergencyNew_BOOL Support of NMT Info service NMTPublishEmergencyNew
D_NMT_PublishNodeState_BOOL
Support of NMT Info service NMTPublishNodeStates
D_NMT_PublishOperational_BOOL
Support of NMT Info service NMTPublishOperational
D_NMT_PublishPreOp1_BOOL
Support of NMT Info service NMTPublishPreOperational1
D_NMT_PublishPreOp2_BOOL
Support of NMT Info service NMTPublishPreOperational2
D_NMT_PublishReadyToOp_BOOL
Support of NMT Info service NMTPublishReadyToOperate

UNSIGNED8

O

O

239

239

UNSIGNED8UNSIGNED8UNSIGNED32
UNSIGNED32

O
O
O
M

O
O
O
-

239
254
-

239
254
-

BOOLEANUNSIGNED8UNSIGNED32
UNSIGNED32

O
O
M
M

-

N
0
-

-

UNSIGNED32

M

-

-

-

UNSIGNED32

M

-

-

-

UNSIGNED32

M

-

-

-

UNSIGNED32

M

-

-

-

BOOLEANBOOLEANBOOLEANBOOLEANBOOLEANUNSIGNED32
BOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEAN

O
O
O
O
O
O
O
O
O
O
O
O
O
O

O
O
O
O
O
-

N
N
N
Y
N
0
N
N
N
N
N
N
N
N

N
Y
N
0
N
-

EPSG DS 301 V1.5.1

-347-

Name

Description

Type

D_NMT_PublishStopped_BOOL
D_NMT_PublishTime_BOOL
D_NMT_RelativeTime_BOOL
D_NMT_RevisionNo_U32
D_NMT_ServiceUdpIp_BOOL
D_NMT_SimpleBoot_BOOL

Support of NMT Info service NMTPublishStopped
Support of NMT Info service NMTPublishTime
Support of RelativeTime transmission via SoC
Identity Object Revision Number
Support of NMT services via UDP/IP
Ability of an MN node to perform only Simple Boot Process, if not set Indivual
Boot Process shall be proviced
Ability of node to forward datagrams
Support of ICMP
Ability of the node cummunicate via IP
Support of dynamic PDO mapping
minimum size of objects to be mapped [bit]maximum cumulative memory consumption of TPDO and RPDO mapping
describing objects [byte]
Number of supported mapped objects per RPDO channel
number of supported RPDO channels
maximum sum of data size of RPDO data to be received per cycle [Byte]
maximum number of mapped RPDO objects, sum of all channels
node’s ability to receive PDO data transmitted by itself
maximum Number of mapped objects per TPDO channel
number of supported TPDO channels
maximum sum of data size of TPDO data to be transmitted per cycle [Byte]
maximum number of mapped RPDO objects, sum of all channels
number of externally accessible Ethernet POWERLINK ports
network propagation delay of the hub integrated in the device in [ns]indicates a hub integrated by the device
jitter of the propagation delay caused by the integrated hub in [ns]Support of Routing Type 1 security functions
Support of Routing Type 1 functions
Support of Routing Type 2 functions
device implements a SDO client
Support of SDO command FileRead

BOOLEANBOOLEANBOOLEANUNSIGNED32
BOOLEANBOOLEAN

D_NWL_Forward_BOOL
D_NWL_ICMPSupport_BOOL
D_NWL_IPSupport_BOOL
D_PDO_DynamicMapping_BOOL
D_PDO_Granularity_U8
D_PDO_MaxDescrMem_U32
D_PDO_RPDOChannelObjects_U8
D_PDO_RPDOChannels_U16
D_PDO_RPDOCycleDataLim_U32
D_PDO_RPDOOverallObjects_U16
D_PDO_SelfReceipt_BOOL
D_PDO_TPDOChannelObjects_U8
D_PDO_TPDOChannels_U16
D_PDO_TPDOCycleDataLim_U32
D_PDO_TPDOOverallObjects_U16
D_PHY_ExtEPLPorts_U8
D_PHY_HubDelay_U32
D_PHY_HubIntegrated_BOOL
D_PHY_HubJitter_U32
D_RT1_RT1SecuritySupport_BOOL
D_RT1_RT1Support_BOOL
D_RT2_RT2Support_BOOL
D_SDO_Client_BOOL
D_SDO_CmdFileRead_BOOL

Category
MN CN
O
O
O
O
O
O
O
M
-

Default
MN
N
N
N
0
N
-

CN
N
0
-

BOOLEANBOOLEANBOOLEANBOOLEANUNSIGNED8UNSIGNED32

O
O
O
O
O
O

O
O
O
O
O
O

N
N
N
N
Y
Y
Y
Y
8
8
MAX_U32 MAX_U32

UNSIGNED8UNSIGNED16
UNSIGNED32
UNSIGNED16
BOOLEANUNSIGNED8UNSIGNED16
UNSIGNED32
UNSIGNED16
UNSIGNED8UNSIGNED32
BOOLEANUNSIGNED32
BOOLEANBOOLEANBOOLEANBOOLEANBOOLEAN

O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O

O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O

254
254
256
256
MAX_U32 MAX_U32
MAX_U16 MAX_U16
N
N
254
254
256
MAX_U32 MAX_U32
MAX_U16 MAX_U16
2
2
1000
1000
Y
Y
50
50
N
N
N
N
N
N
Y
Y
N
N

EPSG DS 301 V1.5.1

-348-

Name

Description

Type

D_SDO_CmdFileWrite_BOOL
D_SDO_CmdLinkName_BOOL
D_SDO_CmdReadAllByIndex_BOOL
D_SDO_CmdReadByName_BOOL
D_SDO_CmdReadMultParam_BOOL
D_SDO_CmdWriteAllByIndex_BOOL
D_SDO_CmdWriteByName_BOOL
D_SDO_CmdWriteMultParam_BOOL
D_SDO_MaxConnections_U32
D_SDO_MaxParallelConnections_U32
D_SDO_SeqLayerTxHistorySize_U16

Support of SDO command FileWrite
Support of SDO command LinkName
Support of SDO command ReadAllByIndex
Support of SDO command ReadByName
Support of SDO command ReadMultipleParamSupport of SDO command WriteAllByIndex
Support of SDO command WriteByName
Support of SDO command WriteMultParammax. number of SDO connections
max. number of SDO connections between a SDO client/server pairmax. number of frames in SDO sequence layer sender history
value <= 31
device implements a SDO server
Support of SDO via ASnd frames
Support of SDO via PDO frames
Support of SDO via UDP/IP frames

BOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANBOOLEANUNSIGNED32
UNSIGNED32
UNSIGNED16

D_SDO_Server_BOOL
D_SDO_SupportASnd_BOOL
D_SDO_SupportPDO_BOOL
D_SDO_SupportUdpIp_BOOL

BOOLEANBOOLEANBOOLEANBOOLEAN

Category
MN CN
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
M
O
M

O
O
O
O

Default
MN
N
N
N
N
N
N
N
N
1
1
5
Y
Y
N
Y

CN
N
N
N
N
N
N
N
N
1
1
5
Y
N
N
N

Abbreviations in the table:•M

device description entry is mandatory•O

device description entry is optional•
item is irrelevant for the selected type of node (MN or CN), item may be provided if the device supports the other type, too
Comments to Default
Default values shall be used if an optional entry is not provided by the device description. If no default is indicated, zero value resp. empty string shall be applied.
Device description entry names are created according to the following rules:
Name shall be in accordance to IEC 61131-3. It consists of:oDevice description entry identification prefix “D_”odomain prefix, indicating the association of the object to a functional domain, 3 uppercase characters followed by underlineoname (verbally). Composed of words, each word are leaded by an uppercase character followed by lowercase characters or digits, no underlines orspacesodata type postfix, indicating the data type of the object (underline followed by up to 5 uppercase characters or digits)EPSG DS 301 V1.5.1-349-

App. 3

Constant Value Assignments (normative)

App. 3.1

POWERLINK Message Type Ids

Message TypeStart of Cycle
PollRequest
PollResponse
Start of Asynchronous
Asynchronous Send

Abbr.
SoC
PReq
PRes
SoA
ASnd

ID Value
01h
03h
04h
05h
06h

Active Managing Node Indication, used by EPSG DS302-A [1]Asynchronous Invite, used by EPSG DS302-B [2]

AMNI
Ainv

07h
0Dh

ID values not listed by the table are reserved.

App. 3.2

AsyncSend Request Priorities

Priority Level
highesthighermediumlower

Priority Name
PRIO_NMT_REQUEST
available for application purpose
PRIO_GENERIC_REQUEST
available for application purpose

App. 3.3

ASnd ServiceIDs

Service Name
reserved
IdentResponse
StatusResponse
NMTRequest
NMTCommand
SDO
reserved, used by EPSG DS302-C [3]reserved
Manufacturer specificreserved

Service ID
IDENT_RESPONSESTATUS_RESPONSE
NMT_REQUESTNMT_COMMANDSDO

MANUF_SVC_IDS

ID value111b
110b, 101b, 100b011b
010b, 001b, 000b

ID Value
00h
01h
02h
03h
04h
05h
06h
07h .. 9Fh
A0h .. FEh
FFh

EPSG DS 301 V1.5.1

App. 3.4

SoA RequestedServiceIDs

Service Name
NoService
IdentRequest
StatusRequest
NMTRequestInvite
reserved
reserved, used by EPSG DS302-C [3]reserved
Manufacturer specificUnspecifiedInviteApp. 3.5
NULL
DEFTYPE
DEFSTRUCTVAR
ARRAYRECORD-350-

Service ID
NO_SERVICEIDENT_REQUESTSTATUS_REQUESTNMT_REQUEST_INVITE

MANUF_SVC_IDS
UNSPECIFIED_INVITE

ID Value
00h
01h
02h
03h
04h .. 05h
06h
07h .. 9Fh
A0h .. FEh
FFh

Object Dictionary Object Types
0000h
0005h
0006h
0007h
0008h
0009h

Values not listed by the table are reserved.

MN States

CN States

MN and CN States

App. 3.6

NMT States

Name
NMT_GS_OFF
NMT_GS_POWEREDNMT_GS_INITIALISATION
NMT_GS_INITIALISING
NMT_GS_RESET_APPLICATION
NMT_GS_RESET_COMMUNICATION
NMT_GS_RESET_CONFIGURATION
NMT_GS_COMMUNICATING
NMT_CS_NOT_ACTIVE
NMT_CS_EPL_MODE
NMT_CS_PRE_OPERATIONAL_1
NMT_CS_PRE_OPERATIONAL_2
NMT_CS_READY_TO_OPERATENMT_CS_OPERATIONAL
NMT_CS_STOPPEDNMT_CS_BASIC_ETHERNET
NMT_MS_NOT_ACTIVE
NMT_MS_EPL_MODE
NMT_MS_PRE_OPERATIONAL_1
NMT_MS_PRE_OPERATIONAL_2
NMT_MS_READY_TO_OPERATENMT_MS_OPERATIONAL
NMT_MS_BASIC_ETHERNET

Value
0000 0000b
xxxx 1xxx b
xxxx 1001b
0001 1001b
0010 1001b
0011 1001b
0111 1001b
xxxx 11xx b
0001 1100b
xxxx 1101b
0001 1101b
0101 1101b
0110 1101b
1111 1101b
0100 1101b
0001 1110b
0001 1100b
xxxx 1101b
0001 1101b
0101 1101b
0110 1101b
1111 1101b
0001 1110b

Super state
Super state

Super state
Super state

Super state

NMT_CS_OPERATIONAL and NMT_MS_OPERATIONAL can be easily identified by the mostsignifiant bit being set.

EPSG DS 301 V1.5.1

App. 3.7-351-

NMT Commands

Namerequestable ASnd ServiceIDs
IdentResponse
StatusResponse
Plain NMT State Commands
NMTStartNode
NMTStopNode
NMTEnterPreOperational2
NMTEnableReadyToOperate
NMTResetNode
NMTResetCommunication
NMTResetConfiguration
NMTSwReset
NMTGoToStandby used by EPSG DS302-A [1]Extended NMT State Commands
NMTStartNodeEx
NMTStopNodeEx
NMTEnterPreOperational2Ex
NMTEnableReadyToOperateEx
NMTResetNodeEx
NMTResetCommunicationEx
NMTResetConfigurationEx
NMTSwResetEx
NMT Managing Commands
NMTNetHostNameSet
NMTFlushArpEntry
NMT Info services
NMTPublishConfiguredNodes
NMTPublishActiveNodes
NMTPublishPreOperational1
NMTPublishPreOperational2
NMTPublishReadyToOperate
NMTPublishOperational
NMTPublishStopped
NMTPublishNodeStates
NMTPublishEmergencyNew
NMTPublishTime
NMTInvalidService
ID values not listed as distinctive commands are reserved

ID Value
01h .. 1Fh
01h
02h20h .. 3Fh
21h
22h
23h
24h
28h
29h
2Ah
2Bh
2Ch

40h .. 5Fh
41h
42h
43h
44h
48h
49h
4Ah
4Bh
60h .. 7Fh62h63h80h .. BFh
80h
90h
91h
92h
93h
94h
95h
96h
A0h
B0h
FFh

EPSG DS 301 V1.5.1

App. 3.8-352-

General Purpose Constants

Name
C_ADR_BROADCAST
C_ADR_DIAG_DEF_NODE_ID

Value
FFh
FDh

Unit
---

Description
POWERLINK broadcast address
POWERLINK default address of dignostic
devicePOWERLINK dummy node address
POWERLINK pseudo node address to be
used by a node to address itself
invalid POWERLINK address
POWERLINK default address of MN
POWERLINK default address of router type 1
ASnd request priority to be used by NMT
Requests
standard ASnd request priority

C_ADR_DUMMY_NODE_ID
C_ADR_SELF_ADR_NODE_ID

FCh
FBh

---

C_ADR_INVALID
C_ADR_MN_DEF_NODE_ID
C_ADR_RT1_DEF_NODE_ID
C_DLL_ASND_PRIO_NMTRQST

00h
F0h
FEh
7

-----

C_DLL_ASND_PRIO_STD
C_DLL_ETHERTYPE_EPL
C_DLL_ISOCHR_MAX_PAYL

0
88ABh
1490

C_DLL_MAX_ASYNC_MTU

1500

C_DLL_MAX_PAYL_OFFSET

1499

C_DLL_MAX_RS
C_DLL_MIN_ASYNC_MTU

7300

C_DLL_MIN_PAYL_OFFSET

45--Byte maximum size of PReq and PRes payload
data,requires C_DLL_MAX_ASYNC_MTU
Byte maximum asynchronous payload in bytes
including all headers (exclusive the Ethernet
header)Byte maximum offset of Ethernet frame payload,requires C_DLL_MAX_ASYNC_MTU-Byte minimum asynchronous payload in bytes
including all headers (exclusive the Ethernet
header)Byte minimum offset of Ethernet frame payload

C_DLL_MULTICAST_AMNI

01-11-1E-00-00-05--

POWERLINK Active Managing Node Indication,
canonical form. Used by EPSG DS302-A [1]

C_DLL_MULTICAST_ASND

01-11-1E-00-00-04--

C_DLL_MULTICAST_PRES

01-11-1E-00-00-02--

C_DLL_MULTICAST_SOA

01-11-1E-00-00-03--

C_DLL_MULTICAST_SOC

01-11-1E-00-00-01--

C_DLL_PREOP1_START_CYCLES

10--POWERLINK ASnd multicast MAC address,
canonical form
POWERLINK PRes multicast MAC address,
canonical form
POWERLINK SoA multicast MAC address,
canonical form
POWERLINK Soc multicast MAC address,
canonical form
number of unassigning SoA frames at start of
NMT_MS_PRE_OPERATIONAL_1

C_DLL_T_BITTIME

10ns

C_DLL_T_EPL_PDO_HEADER10

C_DLL_T_ETH2_WRAPPER

18

C_DLL_T_IFG
C_DLL_T_MIN_FRAME

960
5120

C_DLL_T_PREAMBLE

640

C_ERR_MONITOR_DELAY

10Transmission time per bit on 100 Mbit/s
network
Byte size of PReq and PRes POWERLINK PDO
message header (see 4.6.1.1.3 and 4.6.1.1.4)
Byte size of Ethernet type II wrapper consisting ofheader and checksum (see 4.6.1.1.1)
ns
Ethernet Interframe Gap
nsSize of minimum Ethernet frame (without
preamble and start-of-frame-delimiter)
Size of Ethernet frame preamble plus start-ofns
frame-delimiter
Error monitoring start delayEPSG DS 301 V1.5.1

-353-

Name
C_IP_ADR_INVALID

Value
00 00 00 00h

Unit
--

Description
invalid IP address (0.0.0.0) used to indicate
no change
Byte invalid MTU size used to indicate no change
Cycl maximum reaction time to NMT stateescommands

C_IP_INVALID_MTU
C_NMT_STATE_TOLERANCE

05

C_NMT_STATREQ_CYCLE

5

sec

StatusRequest cycle time to be applied to
AsyncOnly CNs

C_SDO_EPL_PORT

3819

--

C_SDO_CMDLAYERTIMEOUT
C_SDO_SEQULAYERNOACK
C_SDO_SEQULAYERTIMEOUT

30000
2
15000

ms
-ms

port to be used POWERLINK specific UDP/IP
framesCommand layer timeout
Number of acknowledge requests
Sequence layer timeout

General Purpose Constant names are created according to the following rules:
Name shall be in accordance to IEC 61131-3. It consists of:oGeneral Purpose Constant identification prefix “C_”odomain prefix, indicating the association of the object to a functional domain,
3 uppercase characters followed by underlineoname (verbally).
composed of words, words are separated by underline, upperchase characters only, no
spacesApp. 3.9

Error Code Constants

Name
E_DLL_BAD_PHYS_MODE
E_DLL_COLLISION
E_DLL_COLLISION_TH
E_DLL_CRC_TH
E_DLL_LOSS_OF_LINK
E_DLL_MAC_BUFFER
E_DLL_ADDRESS_CONFLICTE_DLL_MULTIPLE_MN
E_PDO_SHORT_RX
E_PDO_MAP_VERS
E_NMT_ASND_MTU_DIF
E_NMT_ASND_MTU_LIM
E_NMT_ASND_TX_LIM
E_NMT_CYCLE_LEN
E_DLL_CYCLE_EXCEEDE_DLL_CYCLE_EXCEED_TH
E_NMT_IDLE_LIM
E_DLL_JITTER_TH
E_DLL_LATE_PRES_TH
E_NMT_PREQ_CN
E_NMT_PREQ_LIM
E_NMT_PRES_CN
E_NMT_PRES_RX_LIM
E_NMT_PRES_TX_LIM

Value
816xh
8161h
8162h
8163h
8164h
8165h
8166h
82xxh
8201h
8202h
821xh
8210h
8211h
8212h
8213h
8214h
823xh
8231h
8232h
8233h
8234h
8235h
8236h
8237h
8238h
8239h
823Ah
823Bh

Description
HW errors

Protocol errors

Frame size errors

Timing errors

EPSG DS 301 V1.5.1

E_DLL_INVALID_FORMAT
E_DLL_LOSS_PREQ_TH
E_DLL_LOSS_PRES_TH
E_DLL_LOSS_SOA_TH
E_DLL_LOSS_SOC_TH
E_DLL_LOSS_STATUSRES_TH
E_NMT_BA1
E_NMT_BA1_NO_MN_SUPPORTE_NMT_BPO1
E_NMT_BPO1_GET_IDENT
E_NMT_BPO1_DEVICE_TYPE
E_NMT_BPO1_VENDOR_ID
E_NMT_BPO1_PRODUCT_CODE
E_NMT_BPO1_REVISION_NO
E_NMT_BPO1_SERIAL_NO
E_NMT_BPO1_CF_VERIFY
E_NMT_BPO1_SW_INVALID
E_NMT_BPO1_SW_STATE
E_NMT_BPO1_SW_UPDATEE_NMT_BPO1_SW_REJECT
E_NMT_BPO2
E_NMT_BRO
E_NMT_WRONG_STATE

-354-

824xh
8241h
8242h
8243h
8244h
8245h
8246h
84xxh
8410h
8411h
8420h
8421h
8422h
8423h
8424h
8425h
8426h
8428h
8429h
842Ah
842Bh
842Ch
8430h
8440h
8480h

Frame errors

Boot-up Errors

Error Code Constant names are created according to the following rules:
Name shall be in accordance to IEC 61131-3. It consists of:oError Code Constant identification prefix “E_”odomain prefix, indicating the association of the object to a functional domain,
3 uppercase characters followed by underlineoname (verbally).
composed of words, words are separated by underline, upperchase characters only, no
spacesEPSG DS 301 V1.5.1-355-

App. 3.10 SDO Abort Codes
Name

E_PDO_MAP_OVERRUN

Abort code
0503 0000h
0504 0000h
0504 0001h
0504 0002h
0504 0003h
0504 0004h
0504 0005h
0601 0000h
0601 0001h
0601 0002h
0602 0000h
0604 0041h
0604 0042h

0604 0043h
E_NMT_INVALID_HEARTBEAT 0604 0044h
0604 0047h
0606 0000h
0607 0010h
0607 0012h
0607 0013h
0609 0011h
0609 0030h
0609 0031h0609 0032h
0609 0036h
0800 0000h
0800 0020h
0800 0021h
0800 0022h
0800 0023h

E_CFM_DATA_SET_EMPTY

0800 0024h

Description
reserved
SDO protocol timed out.
Client/server Command ID not valid or unknown.
Invalid block size.
Invalid sequence number.
reserved
Out of memory.
Unsupported access to an object.
Attempt to read a write-only object.
Attempt to write a read-only object.
Object does not exist in the object dictionary.
Object cannot be mapped to the PDO.
The number and length of the objects to be mapped would
exceed PDO length.
General parameter incompatibility.
Invalid heartbeat declaration
General internal incompatibility in the device.
Access failed due to an hardware error.
Data type does not match, length of service parameter does
not match
Data type does not match, length of service parameter too highData type does not match, length of service parameter too low
Sub-index does not exist.
Value range of parameter exceeded (only for write access).
Value of parameter written too high.
Value of parameter written too low.
Maximum value is less than minimum value.
General error
Data cannot be transferred or stored to the application.
Data cannot be transferred or stored to the application becauseof local control.
Data cannot be transferred or stored to the application becauseof the present device state.
Object dictionary dynamic generation fails or no object
dictionary is present (e.g. object dictionary is generated fromfile and generation fails because of a file error).
EDS, DCF or Concise DCF Data set empty

The abort codes not listed here are reserved.

EPSG DS 301 V1.5.1-356-

Data Sheet Requirements (normative)

App. 4The hardware used to implement POWERLINK devices may be spread over a broad range of amountof resources as well as calculation power. These differences result in highly different reaction times
and buffer sizes affecting the POWERLINK communication timing.
In order to give a compact overview to the project engineer, each manufacturer of a POWERLINK
device shall provide a short data sheet displaying critical device properties.
•

For CN devices, the data sheet shall provide the following parameters:••

POWERLINK cycle time•minimum value, if device supports adjustment over a continuous range•

list of values, if device supports discrete values only•

size of isochronous transmit buffer (maximal size of isochronous frames)•

size of isochronous receive buffer (maximal size of isochronous frames)•

overall buffer size available for isochronous data•

PReq to PRes latency (CN isochronous reaction time)•

SoA to ASnd latency (CN asynchronous reaction time)•

maximum asynchronous MTU•

ability to support multiplexed isochronous access•asynchronous SDO transfer method (UDP/IP and/or POWERLINK ASnd)

For MN devices, the data sheet shall provide the following parameters:•

POWERLINK cycle time•minimum value, if device supports adjustment over a continuous range•

list of values, if device supports discrete values only•

size of isochronous transmit buffer (maximal size of isochronous frames)•

size of isochronous receive buffer (maximal size of isochronous frames)•

overall buffer size available for isochronous data•

minimum transmit-to-transmit gap (controls sequence of MN frame transmission)•

minimum receive-to-transmit gap (controls sequence of MN frame transmission)•

maximum asynchronous MTU•
ability to support multiplexed isochronous access
For devices that support CN and MN, both parameter lists shall be independently provided.
End of File