0% found this document useful (0 votes)

304 views

Profinet Io-Device v4 and v5 Protocol API 05 en

Uploaded by

Carlos Gonzalez Martinez

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

304 views

Profinet Io-Device v4 and v5 Protocol API 05 en

Uploaded by

Carlos Gonzalez Martinez

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 323

Protocol API

PROFINET IO-Device

V4.6.0 / V5.4.0

Hilscher Gesellschaft für Systemautomation mbH

Table of contents
1 Introduction............................................................................................................................................. 7
1.1 About this document ...................................................................................................................... 7
1.2 List of revisions .............................................................................................................................. 7
1.3 Functional overview ....................................................................................................................... 8
1.4 System requirements ..................................................................................................................... 8
1.4.1 System requirements for firmware generation V4 ............................................................................. 8
1.4.2 System requirements for firmware generation V5 ............................................................................. 8
1.5 Target group ................................................................................................................................... 8
1.6 Specification ................................................................................................................................... 9
1.6.1 Technical data ................................................................................................................................... 9
1.6.2 Limitations ....................................................................................................................................... 12
1.7 References to documents ............................................................................................................ 13
2 Getting started ...................................................................................................................................... 14
2.1 Configuration methods ................................................................................................................. 14
2.2 Input and output data conventions ............................................................................................... 14
2.3 Overview of loadable firmware ..................................................................................................... 15
3 Exchanging cyclic data........................................................................................................................ 16
3.1 General concepts ......................................................................................................................... 16
3.2 Behavior regarding I/O data and IOPS ........................................................................................ 17
4 Stack features ....................................................................................................................................... 19
4.1 Structure of the PROFINET IO-Device firmware ......................................................................... 19
4.2 Configuration ................................................................................................................................ 20
4.2.1 Sequence of configuration evaluation ............................................................................................. 20
4.2.2 Configuration lock ............................................................................................................................ 20
4.2.3 Setting Parameters by means of DCP ............................................................................................. 20
4.3 Ethernet MAC addresses ............................................................................................................. 21
4.4 Identification & Maintenance 5 (I&M5) ......................................................................................... 22
4.4.1 API for the use of I&M5 ................................................................................................................... 22
4.4.2 Usage of OEM Vendor ID and OEM Device ID ............................................................................... 23
4.5 Device data .................................................................................................................................. 24
4.6 Status information ........................................................................................................................ 25
4.6.1 Communication state ....................................................................................................................... 25
4.7 Event mechanism......................................................................................................................... 25
4.8 Multiple ARs ................................................................................................................................. 26
4.8.1 Ownership ....................................................................................................................................... 26
4.8.2 Possibilities and Limitations for the Feature Shared Device ............................................................ 27
4.9 Asset Management ...................................................................................................................... 28
4.10 PROFIenergy ASE ....................................................................................................................... 29
4.11 System Redundancy .................................................................................................................... 30
4.11.1 System Redundancy service ........................................................................................................... 31
4.11.2 Application interface ........................................................................................................................ 32
4.11.3 Switchover sequence ...................................................................................................................... 33
4.11.4 Redundancy data hold time (RDHT) ............................................................................................... 37
4.12 Dynamic Reconfiguration ............................................................................................................. 39
4.13 Synchronization signal ................................................................................................................. 47
4.14 Isochronous application ............................................................................................................... 47
4.14.1 Overview ......................................................................................................................................... 47
4.14.2 Isochrounous model ........................................................................................................................ 47
4.14.3 GSDML related parameters............................................................................................................. 48
4.14.4 Isochronous mode data ................................................................................................................... 50
4.14.5 Isochronous Process ....................................................................................................................... 51
4.14.5.1 Output Process ............................................................................................................... 52
4.14.5.2 Input Process.................................................................................................................. 53
4.14.6 netX Synchronization....................................................................................................................... 54
4.14.6.1 Hardware-assisted synchronization ................................................................................ 54
4.14.6.2 Software-assisted synchronization ................................................................................. 57
5 Requirements to the application......................................................................................................... 58
5.1 What the application always has to do......................................................................................... 58
5.2 Device handle .............................................................................................................................. 58
5.3 Handling I/O data ......................................................................................................................... 59

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Introduction 3/323
5.4 Remanent data handling .............................................................................................................. 60
5.4.1 Remanent data ................................................................................................................................ 60
5.4.1.1 Stack stores remanent data ............................................................................................ 60
5.4.1.2 Application stores remanent data ................................................................................... 61
5.4.2 Parameters ‘Name of Station’ and ‘IP Address Parameters’ ........................................................... 62
5.5 Isochronous Application ............................................................................................................... 62
6 Application interface ............................................................................................................................ 63
6.1 Configuring the IO-Device stack .................................................................................................. 63
6.1.1 Service overview ............................................................................................................................. 63
6.1.2 Cyclic process data image............................................................................................................... 64
6.1.3 Configuration of process data images ............................................................................................. 65
6.1.4 Configuration of the submodules ..................................................................................................... 67
6.1.5 Configuring the PROFINET IO-Device stack ................................................................................... 67
6.1.5.1 Remark on Reconfiguration ............................................................................................ 68
6.1.6 Set Configuration service ................................................................................................................ 69
6.1.6.1 Set Configuration request ............................................................................................... 70
6.1.6.2 Set Configuration confirmation ....................................................................................... 79
6.1.6.3 Behavior when receiving a Set Configuration Command ............................................... 79
6.1.7 Register Application service ............................................................................................................ 80
6.1.7.1 Register Application for selective indications only .......................................................... 81
6.1.8 Unregister Application service ......................................................................................................... 82
6.1.9 Set OEM Parameters service .......................................................................................................... 82
6.1.9.1 Set OEM Parameters request......................................................................................... 85
6.1.9.2 OEM parameter: type 1 .................................................................................................. 89
6.1.9.3 OEM parameter: type 2 .................................................................................................. 89
6.1.9.4 OEM parameter: type 3 .................................................................................................. 89
6.1.9.5 OEM parameter: type 4 .................................................................................................. 89
6.1.9.6 OEM parameter: type 5 .................................................................................................. 90
6.1.9.7 OEM parameter: type 6 .................................................................................................. 91
6.1.9.8 OEM parameter: type 7 .................................................................................................. 91
6.1.9.9 OEM parameter: type 8 .................................................................................................. 92
6.1.9.10 OEM parameter: type 9 .................................................................................................. 92
6.1.9.11 OEM parameter: type 10 ................................................................................................ 93
6.1.9.12 OEM parameter: type 11 ................................................................................................ 93
6.1.9.13 OEM parameter: type 12 ................................................................................................ 93
6.1.9.14 OEM parameter: type 13 ................................................................................................ 94
6.1.9.15 OEM parameter: type 14 ................................................................................................ 94
6.1.9.16 OEM parameter: type 15 ................................................................................................ 94
6.1.9.17 OEM parameter: type 16 ................................................................................................ 94
6.1.9.18 OEM parameter: type 17 ................................................................................................ 94
6.1.9.19 OEM parameter: type 18 ................................................................................................ 95
6.1.9.20 OEM parameter: type 19 ................................................................................................ 96
6.1.9.21 Set OEM Parameters confirmation ................................................................................. 97
6.1.10 Set Remanent Data service............................................................................................................. 98
6.1.11 Configuration Delete service ........................................................................................................... 98
6.1.12 Set IOXS Config service .................................................................................................................. 99
6.1.12.1 Set IOXS Config request ................................................................................................ 99
6.1.12.2 Set IOXS Config confirmation ....................................................................................... 100
6.1.13 Load Remanent Data service ........................................................................................................ 101
6.1.13.1 Load Remanent Data request....................................................................................... 101
6.1.13.2 Load Remanent Data confirmation ............................................................................... 102
6.1.14 Set Trigger Type service ............................................................................................................... 103
6.1.15 Config Trigger Event service ......................................................................................................... 106
6.1.15.1 Config Trigger Event Request ...................................................................................... 106
6.1.15.2 Config Trigger Event Confirmation ............................................................................... 107
6.2 Connection Establishment .........................................................................................................109
6.2.1 Service overview ........................................................................................................................... 116
6.2.2 AR Check service .......................................................................................................................... 117
6.2.2.1 AR Check indication ..................................................................................................... 117
6.2.2.2 AR Check response ...................................................................................................... 119
6.2.3 Check Indication service................................................................................................................ 120
6.2.3.1 Check Indication ........................................................................................................... 122
6.2.3.2 Check Response .......................................................................................................... 124
6.2.4 Connect Request Done service ..................................................................................................... 126
6.2.4.1 Connect Request Done indication ................................................................................ 126
6.2.4.2 Connect Request Done response................................................................................. 127
6.2.5 Parameter End service .................................................................................................................. 128
6.2.5.1 Parameter End indication ............................................................................................. 129

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Introduction 4/323
6.2.5.2 Parameter End response .............................................................................................. 130
6.2.6 Application Ready service ............................................................................................................. 131
6.2.6.1 Application Ready request ............................................................................................ 132
6.2.6.2 Application Ready confirmation .................................................................................... 133
6.2.7 AR InData service ......................................................................................................................... 134
6.2.7.1 AR InData indication ..................................................................................................... 134
6.2.7.2 AR InData response ..................................................................................................... 135
6.2.8 Store Remanent Data service ....................................................................................................... 136
6.2.8.1 Store Remanent Data indication ................................................................................... 136
6.2.8.2 Store Remanent Data response ................................................................................... 137
6.3 Acyclic Events indicated by the Stack........................................................................................138
6.3.1 Service overview ........................................................................................................................... 138
6.3.2 Read Record service ..................................................................................................................... 139
6.3.2.1 Read Record indication ................................................................................................ 139
6.3.2.2 Read Record response ................................................................................................. 140
6.3.3 Write Record service ..................................................................................................................... 143
6.3.3.1 Write Record indication ................................................................................................ 144
6.3.3.2 Write Record response ................................................................................................. 146
6.3.4 AR Abort Indication service ........................................................................................................... 148
6.3.4.1 AR Abort Indication ....................................................................................................... 149
6.3.4.2 AR Abort Indication response ....................................................................................... 150
6.3.5 Save Station Name service ........................................................................................................... 151
6.3.5.1 Save Station Name indication....................................................................................... 152
6.3.5.2 Save Station Name response ....................................................................................... 152
6.3.6 Save IP Address service ............................................................................................................... 153
6.3.6.1 Save IP Address indication ........................................................................................... 154
6.3.6.2 Save IP Address response ........................................................................................... 154
6.3.7 Start LED Blinking service ............................................................................................................. 155
6.3.7.1 Start LED Blinking indication ........................................................................................ 155
6.3.7.2 Start LED Blinking response ......................................................................................... 155
6.3.8 Stop LED Blinking service ............................................................................................................. 156
6.3.8.1 Stop LED Blinking indication ........................................................................................ 156
6.3.8.2 Stop LED Blinking response ......................................................................................... 156
6.3.9 Reset Factory Settings service ...................................................................................................... 157
6.3.9.1 Reset Factory Settings indication ................................................................................. 158
6.3.9.2 Reset Factory Settings response.................................................................................. 160
6.3.10 APDU Status Changed service ..................................................................................................... 161
6.3.10.1 APDU Status Changed indication ................................................................................. 161
6.3.10.2 APDU Status Changed response ................................................................................. 162
6.3.11 Alarm Indication service ................................................................................................................ 163
6.3.11.1 Alarm Indication ............................................................................................................ 163
6.3.11.2 Alarm Indication response ............................................................................................ 165
6.3.12 Error Indication service .................................................................................................................. 166
6.3.12.1 Error Indication ............................................................................................................. 166
6.3.12.2 Error Indication response ............................................................................................. 166
6.3.13 Read I&M service .......................................................................................................................... 167
6.3.13.1 Read I&M indication ..................................................................................................... 167
6.3.13.2 Read I&M response ...................................................................................................... 168
6.3.14 Write I&M service .......................................................................................................................... 173
6.3.14.1 Write I&M indication ...................................................................................................... 173
6.3.14.2 Write I&M response ...................................................................................................... 175
6.3.15 Get Asset service .......................................................................................................................... 176
6.3.15.1 Get Asset indication ...................................................................................................... 178
6.3.15.2 Get Asset response ...................................................................................................... 179
6.3.16 Parameterization Speedup Support service .................................................................................. 183
6.3.16.1 Parameterization Speedup Support indication.............................................................. 184
6.3.16.2 Parameterization Speedup Supported response .......................................................... 184
6.3.17 Event Indication service................................................................................................................. 185
6.3.17.1 Event Indication ............................................................................................................ 185
6.3.17.2 Event Indication response ............................................................................................ 186
6.3.18 ARset Status service ..................................................................................................................... 187
6.3.18.1 ARset Status indication ................................................................................................ 187
6.3.18.2 ARset Status response ................................................................................................. 188
6.3.19 Parameter Begin service ............................................................................................................... 189
6.3.19.1 Parameter Begin indication .......................................................................................... 191
6.3.19.2 Parameter Begin response ........................................................................................... 192
6.3.20 Dynamic Reconfiguration service .................................................................................................. 193
6.3.20.1 Dynamic Reconfiguration indication ............................................................................. 193
6.3.20.2 Dynamic Reconfiguration response .............................................................................. 193

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Introduction 5/323
6.4 Acyclic Events requested by the Application .............................................................................194
6.4.1 Service overview ........................................................................................................................... 194
6.4.2 Get Diagnosis service.................................................................................................................... 195
6.4.2.1 Get Diagnosis request .................................................................................................. 195
6.4.2.2 Get Diagnosis confirmation .......................................................................................... 196
6.4.3 Get XMAC (EDD) Diagnosis service ............................................................................................. 199
6.4.3.1 Get XMAC (EDD) Diagnosis request ............................................................................ 199
6.4.3.2 Get XMAC (EDD) Diagnosis confirmation .................................................................... 199
6.4.4 AR Abort Request service ............................................................................................................. 201
6.4.4.1 AR Abort Request......................................................................................................... 201
6.4.4.2 AR Abort Request confirmation .................................................................................... 202
6.4.5 Plug Module service ...................................................................................................................... 203
6.4.5.1 Plug Module request ..................................................................................................... 203
6.4.5.2 Plug Module confirmation ............................................................................................. 204
6.4.6 Plug Submodule service ................................................................................................................ 205
6.4.6.1 Plug Submodule request .............................................................................................. 206
6.4.6.2 Plug Submodule confirmation ....................................................................................... 208
6.4.6.3 Extended Plug Submodule request .............................................................................. 209
6.4.6.4 Extended Plug Submodule confirmation ....................................................................... 211
6.4.7 Pull Module service ....................................................................................................................... 212
6.4.7.1 Pull Module request ...................................................................................................... 213
6.4.7.2 Pull Module confirmation .............................................................................................. 213
6.4.8 Pull Submodule service ................................................................................................................. 214
6.4.8.1 Pull Submodule request ............................................................................................... 215
6.4.8.2 Pull Submodule confirmation ........................................................................................ 216
6.4.9 Get Station Name service.............................................................................................................. 217
6.4.9.1 Get Station Name request ............................................................................................ 217
6.4.9.2 Get Station Name confirmation..................................................................................... 217
6.4.10 Get IP Address service .................................................................................................................. 218
6.4.10.1 Get IP Address request ................................................................................................ 218
6.4.10.2 Get IP Address confirmation ......................................................................................... 218
6.4.11 Add Channel Diagnosis service ..................................................................................................... 219
6.4.11.1 Add Channel Diagnosis request ................................................................................... 219
6.4.11.2 Add Channel Diagnosis confirmation ............................................................................ 220
6.4.12 Add Extended Channel Diagnosis service..................................................................................... 221
6.4.12.1 Add Extended Channel Diagnosis request ................................................................... 221
6.4.12.2 Add Extended Channel Diagnosis confirmation............................................................ 222
6.4.13 Add Generic Diagnosis service ..................................................................................................... 223
6.4.13.1 Add Generic Channel Diagnosis request ...................................................................... 224
6.4.13.2 Add Generic Channel Diagnosis confirmation .............................................................. 226
6.4.14 Remove Diagnosis service ............................................................................................................ 227
6.4.14.1 Remove Diagnosis request .......................................................................................... 227
6.4.14.2 Remove Diagnosis confirmation ................................................................................... 227
6.4.15 Set Submodule State service ........................................................................................................ 228
6.4.15.1 Set Submodule State request ....................................................................................... 228
6.4.15.2 Set Submodule State confirmation ............................................................................... 230
6.4.16 Get Parameter service................................................................................................................... 231
6.4.16.1 Get Parameter request ................................................................................................. 231
6.4.16.2 Get Parameter confirmation ......................................................................................... 232
6.4.17 Add PE Entity service .................................................................................................................... 239
6.4.17.1 Add PE Entity request .................................................................................................. 239
6.4.17.2 Add PE Entity confirmation ........................................................................................... 240
6.4.18 Remove PE Entity service ............................................................................................................. 241
6.4.18.1 Remove PE Entity request ........................................................................................... 241
6.4.18.2 Remove PE Entity confirmation .................................................................................... 242
6.4.19 Update PE Entity service ............................................................................................................... 243
6.4.19.1 Update PE Entity request ............................................................................................. 243
6.4.19.2 Update PE Entity confirmation ...................................................................................... 244
6.4.20 Send Alarm service ....................................................................................................................... 245
6.4.20.1 Send Alarm request ...................................................................................................... 245
6.4.20.2 Send Alarm confirmation .............................................................................................. 252
7 Linkable Object Module (LOM)..........................................................................................................253
8 PROFINET Certification .....................................................................................................................254
8.1 RT tests (Conformance class A, B and C) .................................................................................254
8.1.1 Description .................................................................................................................................... 254
8.1.2 General requirements for RT tests ................................................................................................ 254
8.1.3 Common checks before certification (GSDML) ............................................................................. 255
8.1.4 Basic application behavior ............................................................................................................. 255
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Introduction 6/323
8.2 IRT tests (Conformance class C only) .......................................................................................256
8.2.1 Description .................................................................................................................................... 256
8.2.2 General requirements for IRT tests ............................................................................................... 256
8.2.3 Hardware requirements for IRT tests ............................................................................................ 256
8.2.4 Software requirements for IRT tests .............................................................................................. 256
8.2.5 GSDML requirements for IRT tests ............................................................................................... 257
8.3 Network load tests......................................................................................................................258
8.3.1 Description .................................................................................................................................... 258
8.4 How to handle I&M Data ............................................................................................................259
8.4.1 Overview ....................................................................................................................................... 259
8.4.2 Structure and access paths of I&M objects ................................................................................... 260
8.4.3 Usage of I&M: Stack or application ............................................................................................... 261
9 Resource and feature configuration via tag list ..............................................................................263
9.1 PROFINET IO-Device V4 tag list ...............................................................................................263
9.1.1 LED tag list parameter ................................................................................................................... 263
9.1.2 PROFINET Product Information tag list parameter ....................................................................... 264
9.1.3 Common tag list parameter ........................................................................................................... 264
9.1.4 PROFINET tag list parameter ........................................................................................................ 265
9.2 PROFINET IO-Device V5 tag list ...............................................................................................267
9.2.1 Common tag list parameter ........................................................................................................... 267
9.2.2 PROFINET tag list parameter ........................................................................................................ 268
10 GSDML file adaption for System Redundancy ................................................................................270
10.1 Parameter Begin ........................................................................................................................270
10.2 System Redundancy ..................................................................................................................270
10.3 Dynamic Reconfiguration ...........................................................................................................271
11 Error codes and status codes ...........................................................................................................272
11.1 Common status codes ...............................................................................................................272
11.2 PROFINET core .........................................................................................................................278
11.3 PROFINET IO-Device Interface Task ........................................................................................279
11.4 Socket API..................................................................................................................................293
11.5 PROFINET status codes ............................................................................................................294
11.5.1 The ErrorCode field ....................................................................................................................... 295
11.5.2 The ErrorDecode field ................................................................................................................... 295
11.5.3 The ErrorCode1 and ErrorCode2 fields ......................................................................................... 296
11.5.3.1 ErrorCode1 and ErrorCode2 for ErrorDecode = PNIORW ........................................... 296
11.5.3.2 ErrorCode1 and ErrorCode2 for ErrorDecode = PNIO ................................................. 297
11.5.3.3 ErrorCode1 and ErrorCode2 for ErrorDecode is manufacturer specific ........................ 302
11.6 Generic AP .................................................................................................................................303
12 Coding of Diagnosis ..........................................................................................................................305
13 Appendix .............................................................................................................................................309
13.1 Name encoding ..........................................................................................................................309
13.2 SNMP MIBs and local OIDs .......................................................................................................310
13.3 Legal notes .................................................................................................................................313
13.4 Third party software licenses .....................................................................................................316
13.5 List of tables ...............................................................................................................................318
13.6 List of figures ..............................................................................................................................322
13.7 Contacts .....................................................................................................................................323

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

1 Introduction

1.1 About this document

This manual describes the application interface of the PROFINET IO-Device implementation. The
aim of this manual is to support the integration of devices based on the netX chip into applications
based on direct access to the protocol stack.

1.2 List of revisions

Revision Date Author Revision

5 2021-10-13 BME, Firmware / stack version V4.6.0 / V5.4.0
HHE
Merge documents of firmware / stack generation V4 and V5 into one document.
Limitation regarding FiberOptic added.
OEM parameter: type 19 supported.
Clarification about required order of submodules in Read I&M response.
Clarification about SystemRedundancy firmware limitations.
Remove outdated figure in Set Submodule State service.
Wrong RDHT values fixed.
Clarification about creation of APDU Status Changed indication.
Clarification regarding packet length in case of error. Has to be 0 in this case.
Sections Get Asset indication and Get Asset response: usEntryNumber clarified.
Section Synchronization signal added.
Section Isochronous application added.
Section PROFINET IO-Device V4 tag list added.
Section SNMP MIBs and local OIDs added.
Table 1: List of revisions

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

1.3 Functional overview

The stack has been written to meet the PROFINET specification. This general-purpose software
package includes the realization of:
 the PROFINET IO-Device context management
 the PROFINET IO-Device cyclic data exchange
 the PROFINET IO-Device acyclic data exchange
 the DCP protocol

1.4 System requirements

This software package has the following system requirements to its environment:

1.4.1 System requirements for firmware generation V4

 Supported netX-chip as CPU hardware platform
 if Fast Startup is used, the Flash memory circuit containing the firmware has to be fast
enough
 application should have access to a non-volatile memory (e.g. a Flash) with a min. storage
capacity of 8192 bytes for remanent data storage

1.4.2 System requirements for firmware generation V5

netX 90 chip as CPU hardware platform.

Compatibility between PROFINET IO-Device firmware and Maintenance Firmware for netX90
This compatibility statement is important for use case C firmware for netX 90 which uses a Flash
file system: To ensure proper usage of Flash sectors during file write operations, a Flash
Translation Layer (FTL) has been integrated in the operating system of the firmware. The Flash file
system layout has changed and is not compatible to earlier versions.

Note: Starting with firmware V5.3.0.0, the firmware requires a Flash file system in the new
format and Maintenance Firmware V1.3.0.0 (or higher).

In case you intent to update the PROFINET IO-Device firmware from version 5.1/5.2 to version 5.3,
this requires
1. to update the Maintenance Firmware to V1.3.0.0 (or higher),
2. to update the PROFINET IO-Device firmware to V5.3.0.0 (or higher) and finally
3. to reformat the file system using a full format request (HIL_FORMAT_REQ).
The full format request is a system service in the PROFINET IO-Device firmware to V5.3.0.0 (or
higher).

1.5 Target group

This manual is intended for software developers with knowledge of:
 the programming language C
 the PROFINET IO communication system
 the netX DPM interface and communication mechanism, e.g. communication via packets
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Introduction 9/323

1.6 Specification

1.6.1 Technical data

Feature Value
Maximum number of total cyclic input data 1440 bytes (including IOPS and IOCS)
Maximum number of total cyclic output data 1440 bytes (including IOPS and IOCS)
Maximum number of submodules Depends on the firmware, can be configured via "Number of
configurable submodules" in tag list. Up to 256 in general and may be
smaller number for specific firmware.
Note: If the application uses max. 2 APIs, the "Number of configurable
submodules" can be used. Each further API reduces the total number
of usable submodules by 1.
Multiple Application Relations (AR) Depends on the firmware, can be configured via “Number of additional
IO Connections (ARs)” in tag list. Up to 4 IO-ARs and one Supervisor-
DA AR in general and may be smaller for numbers specific firmware.
Acyclic communication (Record objects) Read/Write Record, max supported size can be configured via taglist.
Alarm types Process Alarm, Diagnostic Alarm, Return Of Submodule Alarm, Plug
Alarm (implicit), Pull Alarm (implicit), Update Alarm, Status Alarm,
Upload and Retrieval Notification Alarm
Diagnosis entries Depends on the firmware, can be configured via “Number of available
Diagnosis buffers” in tag list. Up to 256 application diagnosis records
of type Channel or Extended Channel Diagnosis in general and may
be smaller number for specific firmware.
Identification & Maintenance (I&M) I&M0 Read: Either built in for Slot 0 / Subslot 1 or pass through to
application for any submodule.
I&M1-5 Read/Write: Either built in for Slot 0 / Subslot 1 or pass
through to application for any submodule. I&M4 and I&M5 are
disabled by default.
I&M0FilterData: Either one submodule in Slot 0 / Subslot 1 or if
handled by application, max. 128 submodules.
Topology recognition LLDP, SNMP V1, Physical Device Record Objects
Minimum cycle time (MinDeviceInterval) Firmware generation V4
RT_CLASS_1: 1 ms (min. SendClockFactor 32)
RT_CLASS_3: 250 µs (min. SendClockFactor 8)
Firmware generation V5
netX90 Use case A firmware:
RT_CLASS_3: 250 µs (min. SendClockFactor 8)
netX90 Use case C firmware:
RT_CLASS_3: 1 ms (min. SendClockFactor 32)
Note (Firmware generation V4 and V5): The network cycle time of
250 µs can be used with asynchroneous applications only, which do
not update the dual-port memory on every network cycle.
(Isochroneous) applications are not supported for 250 µs network
cycle time, only for 500 µs, 1 ms, 2 ms and 4 ms.
Media redundancy MRP client
Additional supported features Shared Device
Fast Startup
Asset management
PROFIenergy ASE
Baud rate 100 MBit/s

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Feature Value
Data transport layer Ethernet II, IEEE 802.3, MAUType 16
PROFINET IO specification V2.4, PNIO_Version 2.41
legacy startup of specification V2.2 is supported
Conformance Class C
Application IP stack API The lwIP IP stack can be used by the application via Socket API
Packets. The number of sockets available to the Application as well
as the number of parallel useable services can be configured via
taglist.
Application Raw Ethernet API Sending and Receiving Raw Ethernet Frames as Application is
supported.
Minimum RDHT (SystemRedundancy only) 200 ms
TCP ports 80 (webserver), default
UDP ports 161 (SNMP)
25383 (Hilscher netIdent)
34964 (PROFINET RPC Endpointmapper)
49152 (PROFINET RPC Device)
Table 2: Technical data

The maximum values for number of submodules, Multiple Application Relations, Acyclic
communication, and Diagnosis entries are configuration parameters in the tag list of a firmware.
Each of these features require resources and have to be set in order to not exceed the available
resource (e.g. RAM) of a device.
The same applies for the socket related quantity structures to be used by application which is part
of the tag list as well.
All these configuration parameters compete with each other against the same limited available
memory.

Firmware generation 4 available for netX

netX Available with standard Available with standard feature set and
feature set additional features System Redundancy
and Dynamic Reconfiguration
netX 50 no no
netX 51 yes yes
netX 52 yes no
netX 90 no no
netX 100 yes yes
netX 500 yes yes
Table 3: Availability of PROFINET IO-Device stack V4

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

netX Available with standard Available with standard Available with standard feature set and
feature set feature set for single port additional features System Redundancy
and Dynamic Reconfiguration
netX 50 no no no
netX 51 no no no
netX 52 no no no
netX 90 yes yes yes
netX 100 no no no
netX 500 no no no
Table 4: Availability of PROFINET IO-Device stack V5

PROFINET IO-Device stack including the features System Redundancy and Dynamic
Reconfiguration
The PROFINET IO-Device firmware including the features System Redundancy and Dynamic
Reconfiguration additionally support:
Feature Value
Additional supported features System Redundancy: S2 – single NAP, min. RDHT 200 ms
Dynamic Reconfiguration
Table 5: Technical data (additional features)

PROFINET IO-Device firmware including the features SystemRedundancy and Dynamic

Reconfiguration is not available as
 Firmware for netX52
 Single-port firmware

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

1.6.2 Limitations
 RT over UDP not supported.
 Multicast communication not supported.
 Only one device instance is supported.
 DHCP is not supported.
 The amount of configured IO-data influences the minimum cycle time that can be reached.
 Only 1 Input-CR and 1 Output-CR per AR are supported.
 The amount of usable submodules is reduced by 1 for each used different API (in case more
than 2 APIs are used in parallel).
 Little endian byte order not supported.
 System Redundancy (SR-AR) and Dynamic Reconfiguration (formerly known as
Configuration-in-Run, CiR) are not supported. (*)
 The usage of PROFINET CombinedObjectContainer
 is not supported at all (for standard firmware)
 is not supported for user application parameters (for SystemRedundancy enabled
firmware) (*)
 SharedInput is not supported.
 MRPD is not supported.
 DFP and other HighPerformance-profile related features are not supported.
 Submodules cannot be configured or used by an AR in subslot 0.
 The stack does not support usage of PDEV submodules (InterfaceSubmodule or
PortSubmodule) outside of slot 0. In addition the InterfaceSubmodule is only supported in
subslot 0x8000 and the PortSubmodules are only supported in subslots 0x8001 and 0x8002.
 In case of using a firmware including the feature System Redundancy, the combination of the
features “System Redundancy” and “Shared Device” is not supported. Recommendation: Set
“NumberOfAdditional IO ARs” in tag list to 1.
 Applications implementing an application profile with a defined API != 0 (e.g. Profidrive, IO
Link) need to handle I&M data on their own.
 FiberOptic Ethernet Physics are not supported. Neither Profinet specific “POF” nor real
optical fiber is supported. Only copper-based Ethernet 100BASETXFD (MAUType 16) is
supported.
 Configuration with iniBatch configuration file (inibatch.nxd) is not supported. This
configuration file is generated by configuration software “netX Configuration Tool” that is not
supported.
(*) A separate PROFINET IO-Device firmware is available that support the features System
Redundancy and Dynamic Reconfiguration. To use the firmware requires a separate license
agreement.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

1.7 References to documents

[1] PROFIBUS International: Technical Specification for PROFINET IO: Application Layer
protocol for decentralized periphery, Version 2.4MU2, March 2021, Order No. 2.722, English.
[2] PROFIBUS International: Profile Guidelines Part 1: Identification & Maintenance Functions,
Version V2.1, Order No. 3.502, English, 2016-05.
[3] PROFIBUS International: PROFINET Field Devices, Recommendations for Design and
Implementation, http://www.profibus.com/nc/download/technical-descriptions-
books/downloads/profinet-field-devices-recommendations-for-design-and-
implementation/display/
[4] Hilscher Gesellschaft für Systemautomation mbH: Dual-Port Memory Interface Manual, netX
Dual-Port Memory Interface, Revision 16, DOC060302DPM16EN, English, 2019.
[5] Hilscher Gesellschaft für Systemautomation mbH: Protocol API, Socket Interface, Packet
Interface, Revision 5, DOC140401API05EN, English, 2019.
[6] Hilscher Gesellschaft für Systemautomation mbH: Protocol API, Ethernet, Packet interface,
Revision 11, DOC060901API11EN, English, 2020.

Referenced documents if using PROFINET IO-Device V4 (netX 10/50/51/52/100/500-based

firmware)
[7] Hilscher Gesellschaft für Systemautomation mbH: Packet API, netX Dual-Port Memory,
Packet-based services (netX 10/50/51/52/100/500), DOC161001API04EN, Revision 4,
English, 2020.

Referenced documents if using PROFINET IO-Device V5 (netX 90-based firmware)

[8] Hilscher Gesellschaft für Systemautomation mbH: Packet API, netX Dual-Port Memory,
Packet-based services (netX 90/4000/4100), Revision 5, DOC190301API05EN, Englisch,
2021.
[9] Hilscher Gesellschaft für Systemautomation mbH: Application note, Fragmentation of
packets, Revision 1, DOC181003AN01EN, English, 2018.

Firmware with “Standard feature set and additional features System Redundancy and Dynamic
Reconfiguration”
[10] PROFIBUS International: System Redundancy, Common profile for PROFINET, Order No.
7.122.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

2 Getting started
2.1 Configuration methods
The PROFINET IO Device stack requires configuration parameters. The stack offers the following
configuration methods:
 The application can set the configuration parameters using the Set Configuration service to
transfer the parameters within one (or serveral) packets to the stack.
 You can use SYCON.net configuration software to set the configuration parameters.
However, this is not supported in the following cases:
 netX 52-based loadable firmware
 netX 90 use case A firmware

2.2 Input and output data conventions

PROFINET IO and the netX use different naming schemes in certain cases. To avoid problems,
this section clarifies the naming conventions:

PROFINET IO netX PROFINET IO-Device stack Description

Inputs (data) Application writes data to the Provider image / provider Data of input submodules.
output area of the process data Send from Device to
data memory Controller
Outputs (data) Application reads data from Consumer image / consumer Data of output submodules.
the input area of the process data Send from Controller to
data memory Device
Table 6: Naming convention of input / output data

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

2.3 Overview of loadable firmware

This section gives an overview about existing firmware files
Several types of PROFINET IO-Device firmware files are available:
 A PROFINET IO-Device firmware with a standard feature set.
 A separate PROFINET IO-Device firmware including the additional features System
Redundancy and Dynamic Reconfiguration.
 A separate PROFINET IO-Device firmware supporting one Ethernet port only and without
IRT and without MRP functionality.
Firmware type netX Firmware file Features
Standard feature set netX 51 X060D000.nxf PROFINET IO-Device stack for netX 51 with
standard feature set.
netX 52 X070D000.nxf PROFINET IO-Device stack for netX 52 with
standard feature set.
netX 90 X090D000.nxi PROFINET IO-Device stack for netX 90 with
standard feature set for use case A.
X090D001.nxi PROFINET IO-Device stack for netX 90 with
standard feature set for use case C.
netX 100 X020D000.nxf PROFINET IO-Device stack for netX 100
with standard feature set.
netX 500 X010D000.nxf PROFINET IO-Device stack for netX 500
with standard feature set.
Standard feature set netX 90 X290D000.nxi PROFINET IO-Device stack for netX 90
and additional including the features System Redundancy
features System and Dynamic Reconfiguration for use case A.
Redundancy and
Dynamic X290D001.nxi PROFINET IO-Device stack for netX 90
Reconfiguration including the features System Redundancy
and Dynamic Reconfiguration for use case C.
Note: License
agreement required. netX 100 X220D000.nxf PROFINET IO-Device stack for netX 100
including the features System Redundancy
and Dynamic Reconfiguration for use case C.
netX 500 X210D000.nxf PROFINET IO-Device stack for netX 500
including the features System Redundancy
and Dynamic Reconfiguration for use case C.
Single-port feature netX 51 X160D000.nxf PROFINET IO-Device stack single port for
set netX 51 (without IRT and without MRP
functionality).
netX 52 X170D000.nxf PROFINET IO-Device stack single port for
netX 52 (without IRT and without MRP
functionality).
netX 90 X190D000.nxi PROFINET IO-Device stack single port for
netX 90 for use case A (without IRT and
without MRP functionality).
X190D001.nxi PROFINET IO-Device stack single port for
netX90 use case C (without IRT and without
MRP functionality).
Table 7: Overview of loadable firmware (NXLFW-PNS and NXLFW-PNS SR)

Note: The table above only lists the file names of loadable firmware for NXLFW-PNS and
NXLFW-PNS SR products and does not list the loadable firmware for CIFX, COMX
products, etc.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

3 Exchanging cyclic data

This section describes how the application can access the cyclic I/O data to be exchanged with the
PROFINET IO-Controller.
The netX chip is used as a dedicated communication processor while the application is running on
a separate host processor. The communication processor provides I/O data in a dual-port memory.
The application can read and write this DPM using functions of the cifX/netX API to access the I/O
data: xChannelIORead and xChannelIOWrite.

3.1 General concepts

PROFINET IO uses the concept of a cyclic process data image. Each PROFINET IO network
Controller or Device has an image of input and output data. Each image is updated via
communication partner images using periodic Ethernet frames. These frames are sent at intervals
configured by the engineering tool. The frames contain the I/O data and the data status associated
with it. Moreover, each frame contains a “global” frame data status field which can be used e.g. to
mark the whole frame as invalid.
PROFINET IO organizes the cyclic data in a Provider Consumer model, i.e. an I/O data
consumer exists for every I/O data provider. Both indicate their current state to each other in
several frames. These states are:
 the IO Provider State (IOPS) and
 the IO Consumer State (IOCS).
The IOPS indicates whether the associated data is valid (good) or invalid (bad). For instance, a
faulty submodule in a device will mark its input data as good or bad by setting the IOPS.
To indicate whether the data has been handled, the consumer returns the IOCS to the provider.
For instance, a Digital Analog Converter submodule can use this status to indicate to the controller
an output value that is outside the range.
With PROFINET IO, each submodule has its I/O data and I/O data states, i.e. the I/O data plus two
I/O data states are exchanged for every submodule used by the IO-Controller. Regarding the
Ethernet frame structure, the provider data state is located directly behind the I/O data and
contains information on whether the I/O data is good and may be evaluated or not. The consumer
state is sent in the opposite direction in an other frame and contains information on whether the I/O
data can be handled by the consumer.

Important: Due to the concept of a cyclic process data image, we strongly recommend designing
the application in a way that the consumer data can be read cyclically and that the
provider data can be written regardless of the state of communication. If no
communication is active, the stack will set the consumer data to zero.

Note: If the application cannot be designed in a way that the process data can be read or
written cyclically or if the cycle is slow (larger than 50 ms), the consumer data must be
read when the PNS_IF_IO_EVENT_CONSUMER_UPDATE_REQUIRED occurs, and the
provider data must be written when the
PNS_IF_IO_EVENT_PROVIDER_UPDATE_REQUIRED event is signaled.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

3.2 Behavior regarding I/O data and IOPS

An application determines the behavior of physical outputs. The stack transfers the output data
received from the controller into the IO image only (e.g. DPM). The application has to decide on
whether this data is transferred to physical outputs or not. The stack, if activated, can add status
information (IOPS) to the data. IOPS is generated by the provider of the data (PROFINET IO-
Controller). Using IOPS, the application can decide on whether the data is to be transferred to the
physical outputs or not, depending on the data validity indicated by IOPS.
In case of an error, the default behavior of the PROFINET IO stack is the copying of zeros into the
IO image of all affected submodules.
Section Set IOXS Config service on page 99 describes how to activate the IOPS. Depending on
the configuration, three possible modes exist which use data with or without status.

Data without IOPS

The stack transfers the data only. In case of an error, the stack sets the data of all affected
submodules to zero. If all values of a submodule are zero, the application cannot detect whether
the controller sends valid values (which are zero) or whether this data is invalid due to an error.

Note: Using data without IOPS is not recommended.

Important: The application has to use the IOXS interface (Set IOXS Config service on page 99 to
be able to detect invalid data because zero values can also be valid data.

Data with IOPS - mode Bitwise

IOPS is activated in mode Bitwise. Each submodule has one status bit. The following table lists the
coding for a bit.
IOPS Description
DataState 0 - Bad, data not valid.
1 - Good, data is valid.
Table 8: IOPS - DataState – mode Bitwise

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Exchanging cyclic data 18/323
Data with IOPS - mode Bytewise
IOPS is activated in mode Bytewise.
The application has to verify / set bit 7 of the IOPS. Bits 5-6 has additional information on the
instance that has detected invalid data.

IOPS Description
Bits 5 and 6 - Instance These bits indicate the instance that has detected the invalid data.
If DataState is set to good, bits 5-6 can be ignored.
00 - Detected by subslot.
01 - Detected by slot.
10 - Detected by IO-Device.
11 - Detected by IO-Controller.
Bit 7 - DataState 0 - Bad, data not valid.
1 - Good, data is valid.
Table 9: IOPS - DataState – mode Bytewise

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4 Stack features

4.1 Structure of the PROFINET IO-Device firmware

The following figure shows the structure of the PROFINET IO-Device firmware.

Figure 1: Firmware structure

AP task
The DPM interface of the PROFINET IO-Device.

Ethernet/PROFINET IO switch and Ethernet driver

The xC PROFINET IO switch and the associated Ethernet driver provides the following
functionality:
 Standard Ethernet 2-port switch functionality (local send & receive of frames, forwarding of
frames between ports)
 Ethernet PHY handling (LinkUp/Down/State)
 Handling of protocols e.g. PTCP and MRP
This part provides the LMPM according to the PROFINET specification. Additionally, the
associated Ethernet driver implements the following PN IO state machines:
 PTCP delay requester,
 PTCP delay responder,
 MRP client.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.2 Configuration

4.2.1 Sequence of configuration evaluation

The stack offers several configuration methods. Exactly one method can be used at a time. At
startup, the stack evaluates the configuration in the following order:
1. In case the file CONFIG.NXD and NWID.NXD are available, the stack will use the
configuration parameters from these files and starts working.
2. The stack “waits” for the configuration parameters and remains unconfigured. The application
has to use the Set Configuration service on page 69 packet to configure the PROFINET IO
Device and a Channel Init service to activate the configuration parameters.

4.2.2 Configuration lock

The application can lock the configuration, for details see reference [8] (on page 13).
If the configuration of the stack is locked (via Services described in [DPM Manual]), the following
behavior is implemented in the stack:
 A Set Configuration packet is not accepted.
 Configuration Reload / Channel Init will be rejected.
However, PROFINET specific services affecting the configuration are still working as defined by
PROFINET specification. This includes setting IP parameters and NameOfStation by means of
DCP and writing PDEV Parameters using records.

4.2.3 Setting Parameters by means of DCP

The PROFINET specification defines the Discovery and basic Configuration Protocol (DCP) to
change/set PROFINET device parameters over the network.
A PROFINET IO-Controller, a PROFINET IO-Supervisor or an Engineering System can easily
change the IP parameters or the NameOfStation of a PROFINET IO Device at any time. These
new parameters can either be marked to be used temporarily or marked to be stored remanent.
The receipt of such a request is indicated to the application with the Save Station Name service
(page 151), the Save IP Address service (page 153) or the Reset Factory Settings service (page
157).
The stack will adapt to these new parameters at runtime. New parameters have to be stored
remanent. The stack has a configuration parameter whether the stack or the application store the
remanent data, for details see section Remanent data handling (page 60).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.3 Ethernet MAC addresses

The stack requires the following MAC addresses for operation:

MAC address Used for Mapping to Required

Flash Device Label /
Device Data Provider
Chassis MAC PROFINET and IP MAC address 1 Yes
communication (communication CPU)
Ethernet Port 1 PROFINET, LLDP, and MAC address 2 Yes
MAC MRP communication (communication CPU)
(Channel 0)
Ethernet Port 2 PROFINET, LLDP, and MAC address 3 Yes (except for
MAC MRP communication (communication CPU) specific single port
(Channel 1) firmware)
Second Chassis Ethernet interface MAC address 4 Required if the
MAC (NDIS), if activated (communication CPU) Ethernet interface
(NDIS) is activated.
- Unused MAC address 5–8 No
(communication CPU)
Table 10: Ethernet MAC addresses

The stack uses the MAC addresses from the Device Data Provider (DDP) which is part of the
operating system. The DDP uses the following sources:
 Flash Device Label: The stack reads all MAC addresses from the Flash Device Label
located in the Flash memory (either integrated in netX 90 or attached to netX 51 or netX 52)
and uses them. A Flash Device Label offers up to four (netX 51 and netX 52) or eight (netX
90) MAC addresses.
 Application: The application can change each MAC address using the Device Data Provider
Set service before configuring the firmware. In this case, the following prerequisites must be
met: The tag list parameter “DDP mode” in the firmware file must be set to “passive” and
downloaded to the device. The application can use the Device Data Provider Set service only
if the Device Data Provider is in the state “passive”. For more details about the Device Data
Provider state, see reference [8] (on page 13).
 Security Memory (firmware generation 4 only): The operating system reads the (start)
MAC address from the Security Memory. Up to four MAC addresses are available: the start
MAC address and the three following MAC addresses (start MAC address + 1, start MAC
address + 2, and start MAC address + 3).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.4 Identification & Maintenance 5 (I&M5)

While the data sets I&M0 to I&M4 are rather old (from PROFIBUS times), PROFINET IO
introduced a new I&M5 data set. Its main purpose is the visibility of communication interfaces in
PROFINET IO-Devices.
If a fixed communication module (e.g. a PC card) is used to handle the whole PROFINET IO
communication and the application running is decoupled (e.g. like an application program on the
PC), the I&M0 data set has to show the Vendor ID of the application.
Since tools cannot read out the information “a PC card with its own dedicated firmware is used”
from I&M0, the new data set I&M5 has been introduced as a solution.
This type of IO-Devices is expected to support the data sets I&M0 and I&M5. The I&M0 data set
provides the Vendor ID and Device ID of the whole device (as set by its application). The I&M5
data set provides the Vendor ID and Device ID of the manufacturer of the PC card.

4.4.1 API for the use of I&M5

The PROFINET IO-Device stack provided by Hilscher supports two modes of operation with I&M
which includes I&M5:
 the stack handles I&M requests or
 the application handles I&M requests.
Bit D8 of the system flags sets the mode, see section Set Configuration service on page 69.
If I&M5 support is required, the application has to enable the feature I&M5 for both modes first. For
this purpose, the application has to use the Set OEM Parameters service on page 82 with
PNS_IF_SET_OEM_PARAMETERS_TYPE_5.
Mode “Stack handles I&M requests”
In this mode, the application has to use the Set OEM Parameters service on page 82 with
PNS_IF_SET_OEM_PARAMETERS_TYPE_9 to change/set the content of I&M5 data.
The application can use the Get Parameter service (page 231) with parameter type
PNS_IF_PARAM_IM5_DATA to read the I&M5 data used by the stack.
Mode “Application handles I&M requests”
In this mode, the stack uses the Read I&M service (page 167) with parameter type being equal to
PNS_IF_PARAM_IM5_DATA to indicate “I&M5 data is read”. The application has to respond.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.4.2 Usage of OEM Vendor ID and OEM Device ID

These parameters have been implemented for the very special use case of ready-for-use
PROFINET IO communication modules (e.g. Hilscher comX modules).This approach allows the
device to identify itself with two different pairs of Vendor ID and Device ID, namely:
1. The identity of the manufacturer of the entire device (to be stored in I&M0 vendor and device
parameters)
2. The identity of the manufacturer’s communication module (to be stored in I&M5 vendor and
device parameters)
In this way, customers running a plant have access to information on the manufacturer of the
communication module within a component of their plant.
There are mainly two possible implementation scenarios for using the OEM Vendor ID and the
OEM Device ID:

Minimal applications
 do not use mailbox-based communication,
 perform configurations via database (generated e.g. by SYCON.net),
 use startup parameters to set OEM Vendor ID and OEM Device ID.
 For LFW applications, a special tool is available for adjustment of startup parameters.

Full-featured mailbox-based applications

 use mailbox-based communication.
 perform configurations via packet interface (configuration parameters),
 access Vendor ID and Device ID via the Read I&M service (page 167) or the Write I&M
service (page 173),
 use the Set OEM Parameter service as follows:
 to switch I&M5 on and off (via Set OEM Parameter service, type 5),
 to switch between I&M5 control by stack or application, even at runtime (via Set OEM
Parameter service, type 8)!

Note: For general information on the PROFINET IO feature Information and Maintenance
(I&M), see references [2] and [3] (on page 13).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.5 Device data

The Flash Device Label contains device data. The device-specific data in the Flash Device Label is
set during production of the device. During start of the firmware, the firmware reads this data into
the Device Data Provider.
The following table lists the device data and describes how the PROFINET IO-Device stack maps
this data to PROFINET.
Name PROFINET mapping
Manufacturer ID Not mapped to PROFINET.
Device class Not mapped to PROFINET.
Device number Mapped to OrderID of I&M0. Mapped to OrderID of
I&M5, if I&M5 is activated.
Serial number Mapped to IM_Serial_Number of I&M0. Mapped to
IM_Serial_Number of I&M5, if I&M5 is activated.

Hardware compatibility Not mapped to PROFINET.

number
Hardware revision number Mapped to IM_Hardware_Revision of I&M0. Mapped to
IM_Hardware_Revision of I&M5, if I&M5 is activated.

Production date Not mapped to PROFINET.

Table 11: Basic Device Data in the Flash Device Label

The Flash Device Label offers the possibility to store OEM-specific device data. The following table
lists the mapping of the OEM-specific device data to PROFINET.

Note: If OEM-specific device data is required to be used, all enabling bits (bits 0 – 3) have to
be set. It is not possible to set a single parameter only, all parameters have to be set
simultaneously.

Name PROFINET mapping PROFINET

coding
OEM data option flags Each flag determine whether the parameter -
value from the Basic Device Data or from OEM
identification is to be used.
Bit 0: If 1, OEM Serial number is valid.
Bit 1: If 1, OEM order number is valid.
Bit 2: OEM hardware revision is valid.
Bit 3: OEM production date/time is valid.

OEM serial number Mapped to IM_Serial_Number of I&M0 VisibleString[16].

instead of the Serial number of the Basic
Device Data.
OEM order number Mapped to OrderID of I&M0 instead of the VisibleString[20].
Device number of the Basic Device Data.

OEM hardware Mapped to IM_Hardware_Revision of I&M0 UINT16

revision instead of the Hardware revision number
of the Basic Device Data.
OEM production Not mapped to PROFINET. -
date/time
Table 12: OEM identification in the Flash Device Label

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.6 Status information

4.6.1 Communication state

This section describes how the communication state is used by PROFINET IO Device.

State Description
OFFLINE The IO Device has no valid configuration.
STOP The IO Device has no communication to the IO Controller. Connection
establishment is not in progress. The Bus state of the IO Device may be
set to on or off.
IDLE The communication establishment is in progress (at least one CMDEV
state is > W_CIND and no CMDEV state is INDATA).
OPERATE The I/O connection is established and valid I/O data is exchanged
between the Controller and the Device (at least one CMDEV state is
INDATA).
Table 13: Communication state

4.7 Event mechanism

The PROFINET Device stack uses an event mechanism to indicate some import events to the
application. The events will be indicated using the Event Indication service (page 185).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.8 Multiple ARs

4.8.1 Ownership
The PROFINET Device stack supports multiple ARs at the same time. This allows you to use
several controllers to access different output or input submodules of one device at the same time.
In term of the PROFINET specification this is called Shared Device. Of course, a Shared Output is
not defined as it makes no sense to access an output submodule from more than one controller at
the same time. In order to solve the problem of which controller gets the right to write the outputs of
a submodule and perform parameterization, the PROFINET specification V2.3 defines a new state
machine, the Ownership-State machine (OWNSM). Depending on the submodule-specific
Ownership, the following access rights are defined:
 AR is the owner of the submodule: The submodule puts its input process data to this AR,
takes the output process data from this AR and accepts parameter read and writes on this
AR.
 AR is not the owner of the submodule: The submodule ignores output process data from
this AR and rejects parameter reads and writes on this AR.
The ownership itself is assigned according to the rule “First Come First Serve” e.g. the first AR will
get the ownership of all requested submodules, the second AR will get the ownership of requested
submodules not already owned by the first AR. If the first AR is disconnected, the second AR will
get the ownership of all requested submodules not yet assigned to this AR (This is called a
Release). There is only one exception from this rule: If a Supervisor AR connects, it takes over the
ownership of all requested submodules if the owning ARs allow Ownership Takeover (Depends on
AR Properties in Connect.req of the AR). Furthermore, if a Supervisor AR is active and was not
allowed to take over the ownership of a submodule and the owning AR disconnects, the Supervisor
AR will always get the ownership of the submodule (Supervisor AR has higher Priority than “First
Come First Serve” Principle).

Note: The multi AR feature renders the definition of a “communicating state” ad absurdum.
The application usually has no information about which of the submodules is used by
any AR. Therefore it is strongly recommended to cyclically update the process data
from/to the physical submodules, regardless of any communication state. If the
application insists on knowing if a submodule is in data exchange or not, the IOxS
status of the submodule should be examined.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Stack features 27/323
4.8.2 Possibilities and Limitations for the Feature Shared Device
The stack supports the feature Shared Device. For the maximum number of supported IO-ARs,
see “Multiple Application Relations (AR)” in section Technical data.

Note: When using PROFINET IRT it is not possible to use Shared Device for IRT.

The netX-based IO-Device only supports exactly 1 IRT IO AR. Additional RT IO ARs are possible.

Reachable Cycle Time Depending on the Amount of IO ARs

To give the user of the PROFINET IO Device protocol stack a better understanding of reachable
cycle times for this feature, extensions of this chapter will give some performance indicators.
As the variety of combinations is very large obviously this chapter can not show every possible use
case. Thus only a small subset of possibilities is shown here.
This does neither mean that a not shown combination is not supported nor that it is supported.
Configurations to be used have to be tested by the one combining the netX PROFINET IO Device
with his application.

Note: As each netX chip type has different calculation power this chapter differs the netX chip
type.

For the following tables it is assumed that two 20 byte input submodules and two 20 byte output
submodules are used per IO AR.
Please note, that the amount of submodules influences the reachable cycle time.

netX Amount of ARs Smallest possible cycle time

netX 51/52/90 1-2 1 ms
3-4 2 ms
Table 14: Smalles possible Cycle Time depending using multiple ARs

GSDML, startup Parameterization and Certification

In any case to pass PROFINET certification it is required that the supported amount of ARs
documented in GSDML file matches to the capabilities of the product. Thus the value in GSDML
(“NumberOfAR”) needs to match the configured amount of ARs of the PROFINET protocol stack.
Loadable firmware offers a tag list entry to modify the amount of ARs supported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.9 Asset Management

Asset Management is a feature defined by PROFINET specification V2.34. It is used to provide
information about all installed software and hardware versions within the PROFINET IO-Device or
accessible via subsequent field busses / networks in case of a gateway or more complex device
(e.g. robot unit with internal busses). Diagnostic tools will use this feature to show detailed version
information about a device or unit. The functionality uses a globally defined record object to
exchange the information.
The PROFINET IO-Device stack offers the Get Asset service (page 176) to retrieve the asset
information from the application. The stack will collect the data using multiple Get Asset services
and generates a properly encoded read record response.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.10 PROFIenergy ASE

The protocol stack has implemented the PROFIenergy ASE as defined by PROFINET
specification. For that purpose, it maintains an internal database of PE entities. PE entities are
added removed or updated in this database by the application using the corresponding packet
services. The protocol stack generates all PROFINET alarms associated with these operations
internally. Furthermore the protocol stack implements the PE Filter Data and PE Status Data
records using the information from the database. Read or Write access to the PESAP record object
(Index 0x80A0) is filtered by the protocol stack using the database. If the database contains a PE
entity associated with the accessed submodule, a regular Read/Write record service is used to
hand over processing of the record object access to the application. If no PE entity is associated
with the accessed submodule, the access is rejected by the protocol stack.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.11 System Redundancy

Note: This section is only valid in a firmware/stack which includes the features System
Redundancy and Dynamic Reconfiguration. For an overview, see section Overview of
loadable firmware (page 15).

The stack supports the System Redundancy feature as defined by the PROFINET specification
V2.34.
System Redundancy ensures a reliable and smooth communication between IO-Controller
application and IO-Device application in case of a controller failure or during maintenance. For
detailed information on PROFINET System Redundancy, refer to reference [10].

Number of ARs
To support System Redundancy, the device must support at least two ARs. For the value in
GSDML NumberOfAR and the tag list parameter “Number of additional IO connections”, see
section PROFINET tag list parameter (page 268).
The resources of the ARset (including resources of the two SR-ARs) are reserved as soon as the
first SR-AR is established, i.e. if NumberOfAR is set to 2, the device will reject the AR
establishment of a new IO-AR even if only one SR-AR is established.

Note: The combination of the features “System Redundancy” and “Shared Device” is not
supported. Recommendation: Set “NumberOfAdditional IO ARs” in tag list to 1.

Device type
The Hilscher stack supports only device type S2.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.11.1 System Redundancy service

Within the scope of System Redundancy, the redundancy controller(s) establishes two ARs with
the IO-Device via separate communication paths, without the need for additional hardware (S2).

Figure 2: System Redundancy

In this context, the following rules apply:

 Both SR-ARs use the same configuration (submodule configuration and AR parameters).
 At the same time, only one SR-AR can be a primary SR-AR.
 Diagnosis and alarms are reported only via the primary SR-AR.
 Records can be read via every SR-AR.
 Records can be written via the primary SR-AR or the first SR-AR while establishing the
connection.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.11.2 Application interface

The PROFINET stack abstracts the established SR-ARs and combines the two SR-ARs to one AR
as if one AR were established only.

Figure 3: Application interface

Explanation:
 The connection establishment of the first SR-AR is identical to the connection establishment
of an IO AR expect the AR type value.
 The stack does not report the connection establishment of the second SR-AR to the
application.
 Only one device handle is used for both SR-ARs, independently of which SR-AR is currently
the primary one.
 The stack informs the application about ARset status changes (e.g. if primary SR-AR exists)
and the amount of established SR-ARs using ARset Status Indication service.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 4: System Redundancy sequence

Note: The application must update its provider data even if no Primary exists!

4.11.3 Switchover sequence

From the point of view of the IO-Device, the state change from backup to primary or primary to
backup is called switchover. The IO-Controller always initiates a switchover.

Note: SR Events (e.g. PrimaryReq, BackupReq) are transferred cyclically. Changes of its
value leads to an internal stack event.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Switch to primary
In case of a transition from backup to primary:
 The IO-Controller sends a primary request to start the transition.
 The IO-Device always uses the SR-AR with the most recent primary request as primary SR-
AR.
 The primary SR-AR now has the full ownership privileges:
 Access to I/O data
 Write record data requests are allowed
 Alarms are no longer blocked
The application has to update the input data (provider data) before acknowledging the primary
request.

Figure 5: Switch to primary

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Switch to backup
In case a transition from primary to backup, which happens if the IO-Controller forces it or if a
failure of the primary SR-AR occurs:
 Output data (consumer data) is frozen and still valid
 The RDHT is running because no primary SR-AR exists
 If the RDHT expires, the error “RDHT expired” will abort the (whole) SR-ARset.

Figure 6: Switch to Backup

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Special case: PrimaryFault

If the IO-Device received a primary request for an AR while another primary AR exists, the IO-
Device follows this primary request and informs the previous primary AR about the status change
using the PrimaryFault signal.

Note: In this case, the stack does not report any indication to the application because the
ARset status has not been changed: It is still primary.

Figure 7: PrimaryFault

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.11.4 Redundancy data hold time (RDHT)

The IO-Device uses the RDHT to monitor the ARset. The RDHT defines the maximum time during
which the IO-Device holds the output data if the primary SR-AR fails or during switchover. The
available IO-Controller takes control of the SR-AR before the RDHT expires, otherwise the error
“RDHT expired” will abort the SR-ARset.
The fastest supported RDHT supported by the Protocol stack is 200ms.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 8: Redundancy Data Hold Time

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.12 Dynamic Reconfiguration

Note: This section is only valid in a firmware/stack which includes the features System
Redundancy and Dynamic Reconfiguration. For an overview, see section Overview of
loadable firmware on page 15.

The stack supports the Dynamic Reconfiguration (DR) feature as defined by the PROFINET
specification V2.34. Dynamic Reconfiguration uses the features
 Parameter Begin service for changes of device parameters during operation.
 Dynamic Reconfiguration service for changes e.g. of elements that have failed to work or
communication parameters during operation.
Dynamic Reconfiguration allows a change of application relationship configuration such as AR
parameters, selected submodules, and its parameters.
During the DR sequence, the IO Controller uses the PrmBegin service to change the parameters
being related to AR and submodules.
For detailed information on the Dynamic Reconfiguration feature, refer to reference [!!!].

Note: Dynamic Reconfiguration support is disabled by default. To activate the Dynamic

Reconfiguration feature, use the Set OEM Parameters request with ulParamType set to
PNS_IF_SET_OEM_PARAMETERS_TYPE_16.

Dynamic Reconfiguration scenarios

As described, Dynamic Reconfiguration may be used to change the AR configuration without
interrupting an established application. The following configuration items may be changed during a
DR sequence:
 Changeable AR parameters and CR parameters (e.g. Cycle Time, Watchdog Time, …)
 Changeable PDEV parameters (e.g. enable/disable port monitoring)
 User-specific parameters
 Submodule configuration. A submodule may be
 added to SR-ARset configuration
 removed from SR-ARset configuration
 exchanged by another submodule with a different configuration.

Dynamic Reconfiguration sequence

A DR sequence can be issued only within the context of System Redundancy while a primary SR-
AR (with a different configuration) is established.
Steps of the DR sequence:
 Prerequisite: Two SR-ARs are established, a Primary SR-AR and a Backup SR-AR. Both
SR-ARs use the same configuration (ConfigID 1).
 Step 1: Release Backup SR-AR.
 Step 2: Establish SR-AR with a new configuration (ConfigID 2)
 Step 3: Perform switchover. The newly established SR-AR becomes primary.
 Step 4 (conditional): Configure added/exchanged submodules using Plug sequence.
 Step 5: Primary SR-AR uses PrmBegin service to change parameters.
 Step 6: Release Backup SR-ARs (old primary AR with ConfigID 1).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Initial state
Prerequisite for starting a DR sequence is that two SR-ARs have been established and that one of
them has the status Primary.

Figure 9: Dynamic Reconfiguration – Init state

Step 1
The IO Controller application releases the backup SR-AR

Figure 10: Dynamic Reconfiguration – Step 1

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 2
The previously released backup SR-AR will now be established using a different AR configuration
(ConfigID2). The primary SR-AR (Controller 1) still controls the IO-Device.
During establishment of the new SR-AR, the IO-Device does not report configuration changes to
the application.

Figure 11: Dynamic Reconfiguration – Step 2

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 3
Now, when the SR-AR with the new configuration (ConfigID2) is completely established, the IO
Controller application initiates a switchover. The new SR-AR becomes the new primary and the
other SR-AR the backup.

Figure 12: Dynamic Reconfiguration – Step 3

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 4
The following steps will be performed only if the submodule configuration is changed.
The IO Device will check the expected submodules and perform the appropriate action if a change
is detected.

Step 4.1
If a submodule is added to the SR-ARset configuration:

Figure 13: Dynamic Reconfiguration – Step 4.1

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 4.2
If a submodule is removed from the SR-ARset configuration:

Figure 14: Dynamic Reconfiguration – Step 4.2

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 4.3
If a submodule is exchanged:

Figure 15: Dynamic Reconfiguration – Step 4.3

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Step 5
The IO Controller application uses PrmBegin sequence to change submodule parameters.

Figure 16: Dynamic Reconfiguration – Step 5

Step 6
Finally, the IO Controller application releases the backup SR-AR (ConfigID 1)
From the point of view of the IO Controller application, the DR sequence is finished.

Figure 17: Dynamic Reconfiguration – Step 6

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.13 Synchronization signal

The stack triggers the synchronization pin on the hardware every “SendClock”, even if
“ReductionRatio” is not 1. Starting with stack V4.6 and starting with stack V5.4, the signal is high
active.

4.14 Isochronous application

4.14.1 Overview
This section provides some basic information about the Isochronous Mode and its function defined
by PROFINET to operate I/O modules isochronously.
It first describes the general view of isochronous processing, from data acquisition through
processing to data transmission. The timing parameters relevant for the IO device are indicated
and their definitions are described. GSDML parameters which are relevant for the Isochronous
mode are listed and described and finally the isochronous mode data record is described from the
isochronous point of view.

Note: This chapter uses the descriptive conventions given in section Input and output data
conventions (page 14).

4.14.2 Isochrounous model

In order to achieve a high control quality and to drastically reduce possible jitter in the process
reaction times, measured values are synchronously acquired, process reactions defined and
simultaneously executed. Such systems are called synochronous systems.
In this context, the PROFINET specification defines Isochronous Mode to guarantee that measured
values are acquired and transmitted in the process at predefined times according to the following
Sequence:

Figure 18 Isochronous application processes

The figure above shows an isochronous process where the sampling times of the inputs (1) and
and update times of the outputs (8) are synchronised through the IO-Device application and the IO-
Controller application.
The inputs are acquired and processed by the device application and then sent to the controller
whose application calculates the new output values (may be also forwarded to other IO-Devices in
case of an isochronous distributed application).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Stack features 48/323
The following table explains the individual steps of the isochronous process:
Item Description
1 Acquisition of measured value by IO-Device application process
2 Processing the aquired mesured values (inputs data)
3 Transmitting the mesured values to the IO-Controller before the new data cycle is started
4 Processing of the input values by IO-Controller process
5 Computing the new output values in the IO-Controller application
6 Transmitting the output values to the IO-Device
7 Processing the output values by IO-Device
8 Apply outputs values to the physical output
Table 15: Description of the Isochronus processes

Steps 4, 5 and 6, which are part of the IO-Controller isochronous process. The following sections
do not consider these steps further.

Note: A precondition for isochronous operation is IRT communication (RTC3), where data
exchange is synchronized at reserved time interval (red phase).

4.14.3 GSDML related parameters

The isochronous mode requires that the application on the IO-Controller is synchronized with the
application on the IO-Device, because only then the IO-Controller is able to know exactly when
input data is acquired and output is applied.
These times which describe the time behaviour of the device and the isochronous application are
described using specified parameters in the GSDML file.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Parameter Value / Range Description

CertificationInfo
ApplicationClass "Isochronous" shall containns the token "Isochronous" if the applikation supports
isochronous operation and at least one of the configurable
submodules may be operated synchronously.
DeviceAccessPoint
IsochroneModeInRT_Classes “RT_CLASS_3” Has to contain the token "Isochronous" if the applikation supports
isochronous operation and at least one of the configurable
submodules may be operated synchronously.
IsochroneMode
T_DC_Base 1 ... 1024 The time factor for the application cycle granularity. The Time Data
Cycle Base is specified in multiples of 31.25 microseconds.
The smallest possible value has to be declared.
Time Data Cycle = T_DC_Base * 31.25 microseconds
T_DC_Min 1 ... 1024 The time factor for the smallest possible application data cycle.
The Time Data Cycle Minimum is specified in multiples of
T_DC_Base.
Time Data Cycle Minimum =
T_DC_Min * T_DC_Base * 31.25 microseconds
T_DC_Max 1 ... 1024 The time factor for the largest possible application cycle. The Time
Data Cycle Minimum is specified in multiples of T_DC_Base.
Time Data Cycle Maximum =
T_DC_Max * T_DC_Base * 31.25 microseconds
T_IO_Base 1 ... 32000000 The time factor for the granularity for the devices input/output delay
time in units of 1 nanosecond. It is the time base of following
parameters: T_IO_Input, T_IO_Output (parameters of Isochronous
Mode Record).
T_IO_InputMin, T_IO_OutputMin.
The smallest possible value has to be declared. Time IO Base =
T_IO_Base * 1 nanosecond
T_IO_InputMin 1 ... 32000000 The time factor for the smallest possible time that is necessary to
get and update the input values of an individual input submodule,
in units of T_IO_Base.
Time IO Input Minimum =
T_IO_InputMin * T_IO_Base * 31.25 microseconds
T_IO_OutputMin 1 ... 32000000 The time factor for the smallest possible time that is necessary to
get and update the output values of an individual output
submodule, in units of T_IO_Base. T_IO_OutputMin is releated to
the start of the next data cycle.
Time IO Output Maximum =
T_IO_OutputMax * T_IO_Base * 31.25 microseconds
sochroneModeRequired True, False This attribute indicates whether the related submodule may only be
operated in isochronous mode.
Table 16: Isochronous mode specific GSDML parameters

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Stack features 50/323
4.14.4 Isochronous mode data
In order to synchronize the application on the IO-Device side with the application at IO-Controller
side, based on the GSDML parameters the engineering tool generates isochronous mode data
record for each submodule, which is configured to operate in isochronous mode. The isochronous
mode data record will be convoyed to the application on the IO-Device side at startup phase while
establishing the IRT connection. The data of this record will be passed to the user application using
Write Record Service. The application has to evaluate and apply the record data according to the
following structure:
Variable Type Value / Range Description PNIO Status
Header
usType Unsigned16 0x0204 The type of the PDU structure. The actual value has 0xDF80B300
to be checked against the expected value (0x0204).
usLen Unsigned16 28 The length of the PDU structure (remaining bytes). 0xDF80B100
The actual value has to be checked against the
expected value (28).
bMajor Unsigned8 1 Major version of the PDU structure. The actual value 0xDF80A800
has to be checked against the expected value (1).
bMinor Unsigned8 0 Minor version of the PDU structure. The actual value 0xDF80A800
has to be checked against the expected value (0).
usPadding Unsigned16 0 Padding bytes to ensure DWord alignment.

Data
Slot number Unsigned16 1 ... 0xFFFF The slot the addressed submodule is assigned to. 0xDF80B200

Subslot Unsigned16 1 ... 0xFFFF The subslot the addressed submodule is assigned to. 0xDF80B200
Number
Controller Unsigned16 1 ... 1024 The time factor for the IO-Controller application cycle 0xDF80B800
Application time that is necessary to process input and output
Cycle Factor data (isochronous task) in units of T_DC.
(CACF) IO-Controller application cycle = CACF * T_DC
Time Data Unsigned16 1 ... 1024 The time factor for the data cycle in units of 0xDF80B800
Cycle (T_DC) 31.25 ms.
Data Cycle = T_DC * T_DC_Base * 31.25 ms.
Time IO Input Unsigned32 1 ...32000000 The point of time when the input values has to be 0xDF80B800
fetched in units of T_IO_BASE.
Time IO Input is related to the start of the next data
cycle.
Time IO Ouput Unsigned32 1 … 32000000 The point of time when the output values are taken 0xDF80B800
over in units of T_IO_BASE.
Time IO Ouput is related to the start of the "current"
data cycle.
Time IO Input Unsigned32 1 ... 32000000 The point of time when the input values has to be 0xDF80B80
Valid available for sending in units of T_IO_BASE.
Time IO Input Valid is related to the start of the next
data cycle.
Time IO Ouput Unsigned32 1 ... 32000000 The point of time when the output values are 0xDF80B800
Valid available for processing in units of T_IO_BASE. Time
IO Ouput Valid is related to the start of the "current"
data cycle.
Table 17: Structure of Isochrone Mode Data Record

Note: PNIO Status has to be set according to [ErrorCode1 and ErrorCode2 for ErrorDecode
= PNIORW].

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Stack features 51/323
While processing the record data, if an error is detected the application may freely set
the least significant byte of PNIO status (ErrorCode2) to a specific value. This simplifies
the process of identifying the faulty parameter.

Instead of “Invalid Parameter” (0xDF80B800) the application may also use the error code
“Invalid Range” (0xDF80B700).

4.14.5 Isochronous Process

From the point of view of the IO-Device, Isochronous mode defines a system that:
 acquires measured values (Input Data) at a predefined time offset T_IO_Input
 process and apply Ouput data at a predefined time offset T_IO_Output
 processes these data within a constant cycle time
All these actions are performed by the isochronous task in the device application. For clarity, the
task is divided into two processes Output Process and Input Processes.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.14.5.1 Output Process

The synchronisation sequence for output process data has to proceed as follows:

Figure 19: Isochronous Output Process

Note: All Ouput-timings are related to the start of the "current" Data Cycle.

Note: The outputs are applied exactly at the time instant T_IO_Output (6), independently on
the point in time when they are get valid at the Application process.

Step Description
1 Processing of output data in the isochronous application of the IO-Controller
2 After IRT red phase (after reciving IRT Frames) output data is forwarded to profinet stack for further
processing. The time needer for is called “IO Input Valid”
3 Process and copy output data into the consumer data image of DPM
4 Toggel the DPM handshake flag to confirm the update of output data
5 The point of time when the new output data get be available to process
6 At the point of time, the output values get valid. This step includes e.g digital- analog conversion and
transferring the data to the peripheries or on a back plane bus for internal processing
Table 18: The individual steps of the ouput process within the isochronous application

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.14.5.2 Input Process

The synchronisation sequence for output process data has to proceed as follows:

Figure 20 Isochronous Input Process

Note: All input-timings are related to the start of the next Data Cycle.

Note: The inputs are read exactly at the same time instant T_IO_Input (1), independently on
the point in time when they are sent to the Controller as the input values.

Step Description
1 At this point (releated to the start of the next data cycle) the application should acquire mesuered values from
available input modules and peripheries
2 Point of time to process the input values to prepare it for transmission
3 Toggel Output handshak to transfer cyclic output data from isochronous application to the profinet stack
4 The point of time when the new input data get be available to further process at the level of the
communication interface.
5 The time at which the new input data shall be available to transfer to IO-Controller. It will be transmitted at the
begginnig of the next cycle time
6 Input data will be processed by the isochronous task at the IO-Controller application
Table 19: The individual steps of the input process within the isochronous application

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.14.6 netX Synchronization

This chapter describes how the trigger events reported to the application. For an application
running on a companion chip, there are two possibilities to report trigger events:
 Hardware-assisted synchronization using the physical synchronization pins "XC_Trigger_0"
and "XC_Trigger_1" (recommended)
 Software-assisted synchronization using DPM synchronization handshakes. The latency and
jitter of this solution are still considerable and only conditionally suitable for an isochronous
application.

Note Due to the considerable jitter, DPM Sync handshakes have to be used for informative
purposes only, i.e. as a supplement to the hardware synchronization.

4.14.6.1 Hardware-assisted synchronization

The netX is able to generate two sync signals "xC Trigger 0" and "xC Trigger 1". In this case the
companion chip needs additional physical wires to get the sync signals.
In order to output the trigger signals, it is required to specify the timing parameters listed in the
following table:
Variable Type Value / Description
Range
ulCycleTime uint32_t 0 ... 32 ms Specifes the signal frequency.
The value 0 can be used to disable the trigger signal.
ulOffset uint32_t 0 ... 32 ms Time offset depending on the start of the period when the signal will be
triggered.
Table 20: Trigger Event configuration

By default, xC trigger signals will be cnfigured and started automatically by the PROFINET stack at
start up using the following default settings:
Variable Defualt value Description
ulCycleTime 4 ms "xC Trigger 0" and "xC Trigger 1" Sync signals are triggered in a cycle of 4 ms if
no Sync Data available.
ulOffset 0 The signal is fix generated at the begin of a network cycle
Table 21: Default configuration of trigger events

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 21: Configuration sequence of Trigger Events

Once the application configures the trigger unit, the automatic reconfiguration of trigger events by
stack is disabled.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Synchronization pins
The physical synchronization pins are activated in any type of the application. The physical signals
for "xC Trigger 0" and "xC Trigger 1" are available on the netX pins. netX 51 and netX 90 can
provide synchronization pins on any MMIO pin according to the configuration of the multiplex
matrix:
Signal Signal name Multiplex Matrix Configuration
netX 100 and netX 500

xC Trigger 0 XM3_IO0 Not available

xC Trigger 1 XM3_IO1 Not available

netX 51 and netX 90

xC Trigger 0 MMIOxx MMIO_CONFIG_XC_TRIGGER0

xC Trigger 1 MMIOxx MMIO_CONFIG_XC_TRIGGER1

Table 22 netX Synchronozation pins

For more details, see [4] and the appropriate chapter of the Programming reference guide of the
respective chip.

Note The length of impulse on the physical synchronization pins "XC Trigger 0" and "xC
Trigger 1" is not configurable. The default used impulse length is 31.25 µs.

An example how the sync signals are generated by using the following Trigger Event
Configuration:
Variable xC Trigger 0 xC Trigger 1
ulCycleTime 1ms 1ms
ulOffset 200us 600us
Table 23: Example of the configuration of trigger events

Figure 22: Hardware synchronization using xC-Trigger events

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

4.14.6.2 Software-assisted synchronization

Besides the physical signals "xC Trigger", the stack can generate a software interrupt at the same
time on stack side to inform the application about the trigger event by toggeling the sync
handshake "NSYNCF_CHx". To be able to receive the Sync DPM Interrupt request, the application
has to configure DPM Host side to enable the external interrupt request for Pin 47 "HIF Interrupt".
For more details, see [4] and the appropriate chapter of the Programming reference guide of the
respective chip.
Please note, software-assisted synchronization requires that trigger unit is already configured and
the sync signals can be triggered.

Note: DPM Sync Handshakes might only be generated if the Sync Trigger Event is
configured see section Set Trigger Type service (page 103).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

5 Requirements to the application

5.1 What the application always has to do

The application must answer each indication packet as fast as possible.
The application must always update the I/O data.
You have to determine whether the stack or your application handles remanent data. For details,
see section Remanent data handling (page 60).

5.2 Device handle

The PROFINET Device Stack supports handling multiple ARs at the same time. This means, that
for instance Parameter Writes, Parameter Reads, Connect Sequences and Abort Sequence may
occur at the same time. In order to distinguish between the different ARs, the stack provides the
attribute hDeviceHandle in all affected packets. The device handle may hold the following
values:
 hDeviceHandle = 0: The request is associated with no AR (Only ReadImplicit) or the
request is associated with a Supervisor DA AR.
 hDeviceHandle != 0: The request is associated with a Supervisor AR or an IO-AR. The
Type of the AR is indicated to the application using the AR Check service (page 117).
As a consequence, the application must be able to handle multiple instances of the following
indications at the same time:
 AR Check indication (page 117)
 Check Indication (page 122)
 Connect Request Done service (page 126)
 Parameter End indication (page 129)
 AR InData indication (page 134)
 Read Record indication (page 139)
 Write Record indication (page 144)
 AR Abort Indication (page 149)
 APDU Status Changed indication (page 161)
 Alarm Indication (page 163)
 Read I&M indication (page 167)
 Write I&M indication (page 173)
 Parameterization Speedup Support indication (page 184)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

5.3 Handling I/O data

The application has to read and write the I/O data continuously
The application has to continue reading (updating) consumer data cyclically even if all ARs have
been shut down or if an error occurs. If the application does not continue updating the data, a
PROFINET state conflict error may result.
The application has to continue writing (updating) the provider data regardless of the
communication state.

The application has to use IOPS to be able to indicate invalid data

The application has to activate and use IOPS. To activate IOPS, see section Set IOXS Config
service (page 99). To indicate the data state good or bad, see section Behavior regarding I/O data
and IOPS (page 17).

I/O data update time

The application can update the I/O data in the dual-port memory once per network cycle or less
often than the network cycle. The time for the network cycle used from the protocol stack is based
on the SendClock which is configured by the PROFINET IO-Controller during connection
establishment.
NetworkCycleTime = 31.25 µs * SendClock
The protocol stack uses the smallest value for the SendClock of all submodules and ARs to
calculate the NetworkCycleTime and uses this time for updating the I/O data in the dual-port
memory.
If for example the application intends to use a cycle time of 1 ms to update the I/O data and the IO-
Controller has configured the SendClock to 128 for each submodule and uses one AR only, the
protocol stack updates the I/O data with a cycle time of 4 ms (31.25 µs * 128 = 4 ms). The
application must adapt the I/O data update time to 4 ms (or slower) to avoid I/O data access errors.
The application can use the Get Parameter service (page 231) with usPrmType set to 2 to read the
SendClock of a submodule (e.g. API 0, slot 0 and subslot 1).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

5.4 Remanent data handling

5.4.1 Remanent data

Remanent data contain device parameters e.g. Name of Station, IP Address Parameters, Ethernet-
port related parameters, IRT related parameters, which an IO Device has to store permanently.
The stack automatically updates the remanent data when requested via PROFINET by DCP Set
NameOfStation and DPC SET IP.
When you design your application, you have to determine whether
 the protocol stack stores the remanent data or
 the application stores the remanent data.
In case “application stores the remanent data”, the firmware file (PNSV4: *.nxf, PNSV5: *.nxi) has
to be configured using the Tag List Editor software. In the tag list “Remanent Data Responsibility”
the tag “Remanent Data stored by Host” has to be set to enabled. In case “stack stores the
remanent data”, no change in the tag list of the firmware is required.
The setting of the parameter Device name and IP Parameters Handling (D17) of ulSystemFlags
is also relevant for the behavior of the application, see section Parameters ‘Name of Station’ and
‘IP Address Parameters’ on page 62.

5.4.1.1 Stack stores remanent data

Requirements
For PNSV4:
 a non-volatile memory has to be connected to the netX
 a Flash-based file system
For PNSV5: The protocol stack requires access to non-volatile memory. For netX 90, the internal
non-volatile memory is used.

Configuration
In the tag list “Remanent Data Responsibility” the tag “Remanent Data stored by Host” has to be
set to disabled in the firmware file. This is the default setting in a firmware.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

5.4.1.2 Application stores remanent data

In case the host application stores remanent data, the protocol stack provides the complete
remanent data block towards the host application per indication. The host application has to store
the provided data with each indication and has to set this data back to the stack in the
(re)configuration process.

Requirement
For PNSV4: The application has to use the Load Remanent Data service (page 101) and to
support the Store Remanent Data service (page 136).
For PNSV5: The application has to use the Channel Component Information service
(GENAP_GET_COMPONENT_IDS_REQ) to get the information about the required size for remanent
data of each protocol stack component. The application has to use the Set Remanent Data service
(HIL_SET_REMANENT_DATA_REQ) and to support the Store Remanent Data service
(HIL_STORE_REMAMENT_DATA_IND).

Firmware configuration
In the tag list “Remanent Data Responsibility” the tag “Remanent Data stored by Host” has to be
set to enabled in the firmware file.

Configuration
For PNSV4: The application has to send the Load Remanent Data service to the stack, before the
application sends the Set Configuration service.
For PNSV5: The application has to use the Set Remanent Data service
(HIL_SET_REMANENT_DATA_REQ) to provide the remanent data to each protocol stack
component any time the host application starts up for the first time (e.g. if coming from power up)
and before the application sends the Set Configuration service on page 69. For a sequence
diagram, see section Configuring the PROFINET IO-Device stack (page 67).

During runtime
For PNSV4: The stack indicates to the application the Store Remanent Data service and provides
the remanent data as a block towards the application. The application has to store the remanent
data with each indication.
For PNSV5: The stack component indicates to the application the Store Remanent Data service
(HIL_STORE_REMAMENT_DATA_IND) each time remanent data has been changed. The stack
component provides the remanent data as a block towards the application. The application has to
store the remanent data with each indication.

Description of the services for handling remanent data

For PNSV4: This manual.
For PNSV5: For a detailed description of the Channel Component Information service, the Set
Remanent Data service, and the Store Remanent Data service, see reference see reference [8]
(on page 13).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

5.4.2 Parameters ‘Name of Station’ and ‘IP Address Parameters’

The Set Configuration service on page 69 includes the setting for the Name of Station and the IP
Parameters. These parameters can change during runtime. The stack always indicates to the
application a change of the Name of Station (section Save Station Name service on page 151) or a
change of the IP Address (section Save IP Address service on page 153). The application has to
store these parameters permanently and use them for the next Set Configuration service. For this
purpose, the setting of parameter Device Name and IP Parameters Handling (D17) is relevant for
the storing of parameters and for the behavior of the application.
 If set to 0 (PNS_IF_SYSTEM_NAME_IP_HANDLING_BY_STACK_DISABLED), the application
has to store the parameters Name of Station and the IP Address parameters because they
are used in the Set Configuration Service. This means that the application has to store these
parameters permanently when the indications PNS_IF_SAVE_STATION_NAME_IND and/or
PNS_IF_SAVE_IP_ADDR_IND are sent from the stack. The application has to use the stored
values in the next Set Configuration Service. The application has to reset them on
PNS_IF_RESET_FACTORY_SETTINGS_IND and use the reset values in the next Set
Configuration Service.
 If set to 1 (PNS_IF_SYSTEM_NAME_IP_HANDLING_BY_STACK_ENABLED), the application
does not need to store the parameters Name of Station and the IP Address parameters. The
parameters for Name of Station and the IP Address parameters transferred with the Set
Configuration Service are ignored and the values from the remanent data are used instead.
Note: In case, the application stores the remanent data, but the application does not transfer
the remanent data during configuration (as described in section Application stores remanent
data subsection configuration), the Name of Station is not set!

5.5 Isochronous Application

The PROFINET IO-Device firmware supports isochronous (IsochronousMode) applications with
the following restrictions:
 the application must handle the PROFINET record “IsochronousMode data for one
submodule” (index 0x8030) manually,
 a Dual-port memory Sync Handshake is supported, and
 the Sync Signal (XC_Trigger_0) is fix generated at the begin of a network cycle.
 Use Set Trigger Type Service (section Set Trigger Type service on page 103) to enable Sync
Mode.
 Use Config Trigger Event service to configure when the Trigger Event has to be generated.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6 Application interface

6.1 Configuring the IO-Device stack

6.1.1 Service overview

The following table gives an overview about the available services provided by the stack:

Service Command code Command code

(REQ or IND) (CNF or RES)
Set Configuration service (page 69) 0x1FE2 0x1FE3
Register Application service (page 80) 0x2F10 0x2F11
Unregister Application service (page 82) 0x2F12 0x2F13
Set OEM Parameters service (page 82) 0x1FE8 0x1FE9
PNSV4 only: Load Remanent Data service (page 101) 0x1FEC 0x1FED
PNSV5 only: Set Remanent Data service (page 98), 0x2F8C 0x2F8D
see reference [8] (on page 13)
Configuration Delete service (page 98) 0x2F14 0x2F15
Set IOXS Config service (page 99) 0x1FF2 0x1FF3
Table 24: Overview: Configuring the IO-Device stack service

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.2 Cyclic process data image

The PROFINET IO protocol uses a cyclic process data model to exchange process data between
the PROFINET IO Controller and Device. That is, the PROFINET IO Controller's application and
the PROFINET IO Device's application periodically update their own copies of the process data.
The protocol stacks periodically synchronize these two images vice versa.
In PROFINET, process data is organized at the level of submodules. Each submodule can be
assigned input and/or output process data. Submodules without any data are assigned to the input
process data block with a zero length. Each process data block is associated with a provider data
status (IOPS) and a consumer data status (IOCS). The producer of the data generates the provider
data status. Thus, the provider data status is exchanged in the same direction as the process data
itself. It indicates whether the data is valid. In contrast to that, the consumer of the data generates
the consumer data status which is exchanged in the opposite direction compared to the process
data. The consumer data status indicates whether the consumer of the data was able to use the
data. The data status reflects the validity of the process data at application level. That means in
particular, that the application must indicate invalid data. The protocol stack cannot accomplish
this! Nevertheless, the protocol stack might force a Bad Provider/Consumer State on certain
submodules if required by the protocol.

Note: In order to simplify the host application development, the default configuration of the
Hilscher PROFINET Device stack uses an operation mode where it assumes valid data
whenever the DPM Output Area/Provider Data Area is updated. If explicit provider
and/or consumer status processing is required, the application developer has to
configure the stack using the Set IOXS Config service (page 99).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 65/323
6.1.3 Configuration of process data images
From the PROFINET IO Device viewpoint, the Provider process data Image is the data sent from
the PROFINET IO Device to the PROFINET IO Controller. This is usually called Input process data
(Inputs). The application has to place this data in the Provider process data Image. If a loadable
firmware or module is used, the Provider Data Image corresponds to the DPM Output Area.

Note: Remind that process data sent to the PROFINET IO Controller, which is typically called
Inputs, is to be placed within the DPM output area. This naming issue might lead to
confusion.

Figure 23: Provider process data structure

The red color indicates data associated with input submodules. Slot 0 refers to the DAP and PDEV
submodules which are also input submodules and must be always present but have data length 0.
The process data image consists of up to three blocks:
1. the process data itself,
2. a status area for provider data
3. a status area for consumer data.
Figure 23 above shows this.
In contrast to that, the consumer process data image is the data sent from the PROFINET IO
Controller to the PROFINET IO Device. (If looking from PROFINET IO Device Viewpoint). This
data is typically called Output process data (Outputs). The application should take this data from
the consumer process data image. If a loadable firmware or module is used, the consumer process
data image corresponds to the DPM Input Area.

Note: Remind that process data received from the PROFINET Controller, which is typically
called Outputs is to be placed within the DPM input area. This naming issue might lead
to confusion.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 24: Consumer process data structure

The red color indicates data associated with input submodules. Slot 0 refers to the DAP and PDEV
submodules which are also input submodules and must always be present.

Note: If the host application uses consumer data states, it is important to understand that the
consumer data state of a submodule is to be placed in the opposite process data
image compared to the process data itself. This is because the consumer data states
act as a kind of confirmation for the sender of the data by the receiver.

In order to configure the structure of the process data image, the following steps must be
performed:
1. This step is optional and only required if the process data states of the provider and/or
consumer are prepared by the host application. This step enables the IOPS and/or IOCS
blocks, which are disabled by default. If these blocks are used, the host application must
configure the start offsets of them. These offsets are specified relative to the beginning of
the corresponding process data image. For this purpose, the application can use Set IOXS
Config service. These offsets are specified in units of bytes.
2. This step of configuring the process data images is to specify the location of the process data
and the data states within their corresponding areas. These parameters are part of the Set
Configuration service (page 69) and/or Plug Submodule service. Always specify the offset of
the process data in bytes relative to the beginning of the corresponding process data
memory. The offsets of the data states are always relative to the beginning of the
corresponding data state block. These offsets are either in units of bytes or in units of bits.
This depends on the mode configured in the step before.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.4 Configuration of the submodules

To configure submodules, the Set Configuration service (page 69) has to be used.
In case, the application requires to read/write the consumer/provider state in the data image, the
application has to enable this function using the Set IOXS Config service (page 99). In this case,
the application has to use the "Set IOXS Config service" before the "Set Configuration service". If
IOXS is configured, it is mandatory to configure correct offsets for each submodule.

6.1.5 Configuring the PROFINET IO-Device stack

The stack requires configuration parameters. Configuration parameters can be set
 using a configuration software (the configuration software creates a database containing the
configuration parameters) or
 by an application using the packet API.

The application configures the stack using the API

In order to configure an IO-Device, the application has to perform the following configuration
sequence:
 If necessary, change the MAC addesses with the Device Data Provider Set service.
 Restore the remanent data using the Load Remanent Data service if the application handles
remanent data (instead of the stack).
 Set the OEM parameters using the Set OEM Parameters service if the Hilscher default
values are insufficient.
 Register the application using the Register Application service in order to receive indications
from the stack if this is required.
 Configure the IOxS handling with the Set IOXS Config service if IOxS access is required.
 Mandatory: Configure the device using the Set Configuration service. This means supplying
the device with all parameters needed for operation. These include both basic parameters for
identification such as NameOfStation, DeviceID and VendorID as well as the module
configuration. This module configuration contains information about the APIs, modules and
submodules the stack will use. When the stack returns the Set_Configuration packet back to
the application, the given configuration has been evaluated completely and is ready to be
applied.
 Mandatory: Perform the Channel Initialization (see reference [8] (on page 13)) to activate
the new configuration. Now, the stack is ready to start communication with an IO-Controller.
The following figure shows the configuration sequence.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 25: IO-Device configuration sequence

6.1.5.1 Remark on Reconfiguration

It is possible to reconfigure the stack at any time. To do so, simply send a new configuration to the
stack followed by a Channel Init Request (see reference [8] (on page 13)). Sending the new
configuration without the Channel Init Request will not have an effect on any running
communication. The new parameters will simply be stored. Sending the Channel Init Request will
stop any communication and take over the new parameters.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.6 Set Configuration service

Set configuration
The application can use the Set Configuration service to configure the IO-Device stack on startup.
The application provides information about the API, the modules and the submodules to the stack.

Note: After the application has sent the Set Configuration request to the stack, the application
must send a Channel Initialization request (ChannelInit) to the protocol stack in order to
confirm the validity of the new configuration. The stack will use the changed
configuration only after it has received the Channel Initialization request.

Note: In case PNS_IF_SYSTEM_NAME_IP_HANDLING_BY_STACK_ENABLED is set to 0: The

application must register with the stack in order to receive the relevant indications (See
section Register Application service (page 80). The application must handle the Name
Of Station and the IP Parameters.

Changing the configuration at runtime

The module configuration may be changed later at runtime using the
 Pull services (see sections Pull Module service (page 212) and Pull Submodule service
(page 214), and
 Plug services (see sections Plug Module service (page 203) and Plug Submodule service
(page 205).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.6.1 Set Configuration request

The application has to use this request to configure the IO-Device. As the application can (almost)
freely define the configuration of modules and submodules. Due to the number of used modules
and submodules, this packet has a variable length.
If the stack is accessed via dual-port memory, due to the limited mailbox size the application may
need to use packet fragmentation for the request packet. For PNSV4: The handling of packet
fragmentation is described in section “General packet fragmentation” in reference [7]. For PNSV5:
The handling of packet fragmentation is described in section “Communication channel packet
fragmentation” in reference [8] and [9].
Due to further development and standardization, the application has to use the “Communication
channel packet fragmentation” with firmware for netX 90/4000/4100. For a detailed description, see
reference [9] (on page 13).

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t This is a value depending on the amount of
submodules.
ulCmd uint32_t 0x1FE2 PNS_IF_SET_CONFIGURATION_REQ
ulExt uint32_t Sequence number for use in fragmented packets.
Data
ulTotalConfigPckLen uint32_t Length (in bytes) of the entire configuration data.
This parameter in the very first packet shall
contain the complete size of all sequenced
packets (without the packet headers).
The field ulTotalConfigPckLen is not
evaluated by the firmware. Nevertheless, it is
strongly recommended to set the value of this field
to the total length of the data part of the packet.
(including the field itself).
tDeviceParameters PNS_IF_DEVICE_PARAM The structure describing the device parameters,
ETER_T see explanation below.
tModuleConfig PNS_IF_MODULE_CFG_ The structure is used to set the number of APIs,
REQ_DATA_T see explanation below.
- PNS_IF_API_STRUCT_T The structure PNS_IF_API_STRUCT_T and the
followed by structure PNS_IF_SUBMODULE_STRUCT_T[n]
PNS_IF_SUBMODULE_S describe one API including n submodules, see
TRUCT_T[n] explanation below.
This sequence has to be repeated for each further
API.
Table 25: PNS_IF_SET_CONFIGURATION_REQ_T - Set Configuration request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 71/323
Packet structure reference
/** Request Packet */
typedef __HIL_PACKED_PRE struct PNS_IF_SET_CONFIGURATION_REQUEST_REQ_Ttag
{
/** Packet header */
HIL_PACKET_HEADER_T tHead;
/** Data part */
PNS_IF_SET_CONFIGURATION_REQUEST_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SET_CONFIGURATION_REQUEST_REQ_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_CONFIGURATION_REQUEST_DATA_Ttag

{
/** total length of this configuration request.
* This length is needed to handle the case that the request is transferred
* in more than 1 sequence through DPM it shall contain the total length
* in sum) of all sequenced packets (without packet headers) */
uint32_t ulTotalConfigPckLen;
/** the device parameters */
PNS_IF_DEVICE_PARAMETER_T tDeviceParameters;
/** The module configuration */
PNS_IF_MODULE_CFG_REQ_DATA_T tModuleConfig;
} __HIL_PACKED_POST PNS_IF_SET_CONFIGURATION_REQUEST_DATA_T;

Overview
The packet data contains
 Length information
 Device parameter, structure PNS_IF_DEVICE_PARAMETER_T containing system flags, ids,
Name of Station, …
 Module configuration
 Number of APIs, structure PNS_IF_MODULE_CFG_REQ_DATA_T
 API definition for first API, structure PNS_IF_API_STRUCT_T
 Submodules for first API, array of structure PNS_IF_SUBMODULE_STRUCT_T[n] (n
submodules)
 Optional: API definition for second API, structure PNS_IF_API_STRUCT_T
 Optional: Submodules for second API, array of structure
PNS_IF_SUBMODULE_STRUCT_T[]
 Optional: Further APIs with both "API definition" and "submodules"

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Device parameter
tDeviceParameters has the following structure:
typedef __HIL_PACKED_PRE struct PNS_IF_DEVICE_PARAMETER_Ttag
{
uint32_t ulSystemFlags; /** flags to use are defined in this file */
uint32_t ulWdgTime; /** DPM watchdog time*/
uint32_t ulVendorId; /** the Vendor ID */
uint32_t ulDeviceId; /** the Device ID */
uint32_t ulMaxAr; /** currently unused */
uint32_t ulCompleteInputSize; /** max. combined amount of Input bytes */
uint32_t ulCompleteOutputSize; /** max. combined amount of Output bytes */
uint32_t ulNameOfStationLen; /** length of NameOfStation */
uint8_t abNameOfStation[PNS_IF_MAX_NAME_OF_STATION]; /** the NameOfStation */
uint32_t ulTypeOfStationLen; /** length of TypeOfStation */
uint8_t abTypeOfStation[PNS_IF_MAX_TYPE_OF_STATION]; /** the TypeOfStation */
uint8_t abDeviceType[PNS_IF_MAX_DEVICE_TYPE_LEN +3]; /** the DeviceType - ignore the
last 3 padding bytes ! */
uint8_t abOrderId[PNS_IF_MAX_ORDER_ID]; /** OrderID, set to 0 */

uint32_t ulIpAddr; /** IP Address, default: 0.0.0.0 */

uint32_t ulNetMask; /** Netmask, default: 0.0.0.0 */
uint32_t ulGateway; /** Gateway, default: 0.0.0.0 */
uint16_t usHwRevision; /** Hardware Revision, set to 0 */
uint16_t usSwRevision1; /** Software Revision 1, default: 0 */
uint16_t usSwRevision2; /** Software Revision 2, default: 0 */
uint16_t usSwRevision3; /** Software Revision 3, default: 0 */
uint8_t bSwRevisionPrefix; /** Software Prefix, default: 0 */
uint8_t bReserved; /** reserved, shall be set to 0 */
uint16_t usMaxDiagRecords; /** max. mount of parallel Diagnosis records, default: 256
*/
uint16_t usInstanceId; /** GSDML-parameter ObjectUUID_LocalIndex, default: 1 */
uint16_t usReserved; /** reserved, shall be set to 0 */
} __HIL_PACKED_POST PNS_IF_DEVICE_PARAMETER_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

The following table describes the parameters of the structure PNS_IF_DEVICE_PARAMETER_T.

Variable Type Value / Description

Range
ulSystemFlags uint32_t Flags for system behavior. See below.
ulWdgTime uint32_t 0, 20 … Watchdog time in ms.
65535 0 = Watchdog timer is switched off
Default: 1000
ulVendorId uint32_t 1..65535 Vendor ID:
Vendor identification number of the manufacturer, which the
PROFIBUS & PROFINET International organization has assigned
to the vendor. Hilscher products use the value 286 / 0x011E.
Although the parameter VendorID has a defined value range, the
protocol stack will not verify the value received from the
application. All values are accepted, even those outside the
defined value range. The device vendor has the responsibility to
use correct numbers. The VendorID is assigned by PROFIBUS &
PROFINET International organization.
ulDeviceId uint32_t 1 … 65535 Device ID
This is the identification number of the device. The device vendor
can assign a Device ID and has the responsibility to use a fix and
unique number for each device type.
Although the parameter Device ID has a defined value range, the
protocol stack will not verify the value received from the
application.
ulMaxAr uint32_t 0 Currently not used. Set to zero.
ulCompleteInputSize uint32_t 0 Set to 0
ulCompleteOutputSize uint32_t 0 Set to 0
ulNameOfStationLen uint32_t 0 … 240 Length of NameOfStation
abNameOfStation[240] uint8_t[] The NameOfStation as ASCII char-array.
If bit D17 in the system flags ulSystemFlags is set the stack does
not evaluate this parameter, the stack will use the NameOfStation
saved in remanent data.
For details about allowed characters, see section Name encoding
(page 309).
ulTypeOfStationLen uint32_t 0 Set to 0
abTypeOfStation[240] uint8_t[] 0 Set to 0
abDeviceType[28] uint8_t[] The DeviceType as ASCII char-array. The last 3 bytes are
reserved padding bytes and must be set to zero. However, this is
not checked by the stack.
Although parameter DeviceType is defined as ASCII char-array,
the protocol stack will not check the individual characters. The
protocol stack will accept and use all values received from the
application. Note: The DeviceType has to be conform to
DeviceType in the GSDML.
abOrderId[20] uint8_t[] 0 Set all elements of the array to 0
In case the application does not set abOrderId to 0, the stack
reject this service and sets ulSta != 0 in the confirmation and
does not start.
During startup, the stack reads abOrderId from the
DeviceDataProvider (DDP) and uses it. The application can
change abOrderId using the Device Data Provider Set service.
For details see Device data (page 24).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
ulIpAddr uint32_t Valid IP IP address.
address, If bit D17 in the system flags ulSystemFlags is set, the stack does
default: not evaluate this parameter. The stack will use the IP address
0.0.0.0 saved in remanent data.
ulNetMask uint32_t Valid network Network mask.
mask, default: If bit D17 in the system flags ulSystemFlags is set, the stack does
0.0.0.0 not evaluate this parameter. The stack will use the network mask
saved in remanent data.
ulGateway uint32_t Valid gateway Gateway address.
address, If bit D17 in the system flags ulSystemFlags is set, the stack does
default: not evaluate this parameter. The stack will use the gateway
0.0.0.0 address saved in remanent data.
usHwRevision uint16_t 0 Set to 0
In case the application does not set usHwRevision to 0, the
stack reject this service and sets ulSta != 0 in the confirmation
and does not start.
During startup, the stack reads usHwRevision from the
DeviceDataProvider (DDP) and uses it. The application can
change usHwRevision using the Device Data Provider Set
service. For details see Device data (page 24).
usSwRevision1 uint16_t 0 ... 0xFFFF, Software Revision 1, used e.g. in I & M
default: 0
usSwRevision2 uint16_t 0 … 0xFFFF, Software Revision 2
default: 0
usSwRevision3 uint16_t 0 ... 0xFFFF, Software Revision 3
default: 0
bSwRevisionPrefix uint8_t ‘V’, ‘R’, ‘P’, ‘U’, Software Revision Prefix, used e.g. in I & M
‘T’ Possible values and their meanings are:
‘V’: Released version
‘R’: Revision
‘P’: Prototype
‘U’: Under field test
‘T’: Test device
bReserved uint8_t 0 Reserved, set to zero.
usMaxDiagRecords uint16_t 0 Set to 0. The maximum number of diagnosis records can be set
via tag list.
usInstanceId uint16_t 0 … 0xFFFF, Instance ID. This parameter must match to value
default: 0 ObjectUUID_LocalIndex in the GSDML file corresponding to
the IO-Device. The value 1 is recommended.
usReserved uint16_t 0 Reserved for future use, set to zero
Table 26: Structure tDeviceParameters

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Bit Behavior to influence Description

D0 Bus State after applying 0 – PNS_IF_SYSTEM_START_AUTO_START
configuration The stack will enable the Bus (Network access) right after Channel
Initialization.
1 – PNS_IF_SYSTEM_START_APPL_CONTROLLED
The stack disables the Bus after Channel Initialization. Application shall
use Start/Stop Communication Service to enable Bus.
D3 Reserved -
D8 Identification & Maintenance 0 – PNS_IF_SYSTEM_STACK_HANDLE_I_M_DISABLED
Handling This setting enables that the application is responsible to handle I&M
requests. The stack parses I&M requests only and will forward I&M
requests to the application using indications and the Write I&M service
(page 173). The application must handle I&M 0-4 Data sets. I&M 0-3 is
supported on the DAP submodule (Slot 0, subslot 1) by default.
The application must handle the I&M data
in case the configuration contains a submodule with API != 0 or
in case a submodule with API != 0 is plugged during runtime
(PlugSubmodule service).
1 – PNS_IF_SYSTEM_STACK_HANDLE_I_M_ENABLED
The stack internally handles I&M requests. I&M 0-4 is supported on the
DAP submodule (Slot 0, subslot 1).
D9 Automatic Application Ready if 0 – PNS_IF_SYSTEM_ARDY_WOUT_APPL_REG_DISABLED
no application is registered The Stack will never generate an Application Ready Sequence if no
application is registered: Therefore the application must register with the
stack in order to establish an AR.
1 – PNS_IF_SYSTEM_ARDY_WOUT_APPL_REG_ENABLED
The stack will generate an Application Ready automatically if no
application is registered. Use this flag with care: the stack has no
information about the Readiness of the application. Therefore sending
Application Ready automatically can be dangerous.
D11 Generate Check Indications for 0 – PNS_IF_SYSTEM_CHECK_IND_ALL_MODULES_DISABLED
matching submodules The stack will not generate a Check Indication (page 122) for expected
submodules that match the configuration.
1 – PNS_IF_SYSTEM_CHECK_IND_ALL_MODULES_ENABLED
The stack will generate a Check Indication (page 122) for expected
submodules that match the configuration. E.g. the application will receive a
Check Indication (page 122) for each submodule owned by an AR.
D12 Reserved -
D13 Generate Check Indications for 0 – PNS_IF_SYSTEM_CHECK_IND_UNUSED_MODULES_DISABLED
unused modules The stack does not generate a Check Indication (page 122) for modules
not used by any AR.
1 – PNS_IF_SYSTEM_CHECK_IND_UNUSED_MODULES_ENABLED
The stack will generate a Check Indication (page 122) for each submodule
not used by any AR right before generating the Connect Request Done
indication (page 126). If another controller starts establishing an AR while
these Check Indications are generated, the stack will stop generating
these Check Indications and restart after processing another AR expected
submodules.
The stack generates Check Indication (page 122) also after the AR Abort
Indication service (page 148).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Bit Behavior to influence Description

D14 Reserved Note: In the PROFINET IO-Device stack V3 and V4, this bit was used to
set the “Remanent Data Handling”. For PROFINET IO-Device V5 and
starting with V4.6, this bit has no function. For setting the “Remanent Data
Handling”, a tag list entry is used instead.
D15 Reserved -
D16 Check if IO-data offsets in IO- 0 – PNS_IF_SYSTEM_ENABLE_IO_OFFSET_CHECKING
image The stack will check if IO-data offsets in IO-image (or DPM) are configured
properly
1 – PNS_IF_SYSTEM_DISABLE_IO_OFFSET_CHECKING
The stack will never check if IO-data offsets in IO-image (or DPM) are
configured properly. ATTENTION: disabling this check may lead to
inconsistent IO-data in case of a faulty application configuration.
Disabling this check will lead to invalid stack response to the service
RCX_GET_DPM_IO_INFO_REQ!
D17 Device name and IP parameter 0 – PNS_IF_SYSTEM_NAME_IP_HANDLING_BY_STACK_DISABLED
handling The parameters for Name of station and the IP address parameters are
used from the Set Configuration Service. This means, that the application
has to store these parameters, when the indications
PNS_IF_SAVE_STATION_NAME_IND and/or
PNS_IF_SAVE_IP_ADDR_IND are sent from the stack. The application
has to use the stored values and to use them in the next Set Configuration
service. The application has to reset them on
PNS_IF_RESET_FACTORY_SETTINGS_IND and use the reset values in
the next Set Configuration service.
1 – PNS_IF_SYSTEM_NAME_IP_HANDLING_BY_STACK_ENABLED
The parameter for Name of station and the IP address parameters
transferred with the Set Configuration Service are ignored and the values
from the remanent data are used instead.
The stack must have a possibility to save the Remanent Data: DPM is in
use and non-volatile storage (flash memory) is available or application
(using the linkable object module) supports the Store Remanent Data
service (page 136) and the Load Remanent Data service.
Table 27: System flags

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 77/323
Module configuration (IO-Device API)
tModuleConfig has the following structure:
typedef __HIL_PACKED_PRE struct PNS_IF_MODULE_CFG_REQ_DATA_Ttag
{
/** Number of APIs following this structure */
uint32_t ulNumApi;
} __HIL_PACKED_POST PNS_IF_MODULE_CFG_REQ_DATA_T;
The number of APIs (to be used) is set in variable ulNumApi. Typically, one API is used. If the
application requires m APIs, set ulNumApi to the value m.

Note: The “Number of configurable submodules” configured via the tag list depends on the
number of used APIs: If the application uses max. 2 APIs, the “Number of configurable
submodules” can be used. Each further API reduces the total number of usable
submodules by 1.

Example 1: 32 submodules and 2 APIs: No reduction of submodules, i.e. total number

is 32.

Example 2: 32 submodules and 4 APIs: Reduction of 2 submodules, i.e. total number is

30.

The structure PNS_IF_API_STRUCT_T followed by an array with n submodule definitions describe

one API. The structure PNS_IF_SUBMODULE_STRUCT_T defines one submodule and is needed n-
times.
Structure PNS_IF_API_STRUCT_T:
Variable Type Value / Range Description
ulApi uint32_t 0, The number of the API profile to be configured.
application Value 0 means “no application profile”. All other values are
profile-specific application profile-specific values, defined by the PROFIBUS &
number PROFINET International organization.
Although the parameter “API profile” has a defined value range, the
protocol stack will not verify the value received from the application.
All values are accepted, even those outside the defined value
range. The device vendor has the responsibility to use correct
numbers.
ulNumSubmoduleItems uint32_t 1..n Number of submodule items this API contains. These items follow
directly behind this entry.
Table 28: Structure PNS_IF_API_STRUCT_T

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 78/323
Structure PNS_IF_SUBMODULE_STRUCT_T:
Variable Type Value / Description
Range
usSlot uint16_t The slot this submodule belongs to.
usSubslot uint16_t The subslot this submodule belongs to.
ulModuleID uint32_t The ModuleID of the module this submodule belongs to.
ulSubmoduleID uint32_t The SubmoduleID of this submodule.
ulProvDataLen uint32_t 0..1440 The length of data provided by this submodule. This length describes the
data sent by IO-Device and received by IO-Controller.
ulConsDataLen uint32_t 0..1440 The length of data consumed by this submodule. This length describes the
data sent by IO-Controller and received by IO-Device.
ulDPMOffsetIn uint32_t Offset in DPM input area or in Input image (in pbConsImage, see Set IO
Image service) where consumed data for the submodule are copied to.
This data is sent by IO-Controller and received by IO-Device.
Set this value to 0, if ulConsDataLen is 0.

ulDPMOffsetOut uint32_t Offset in DPM output area or in Output image (in pbProvImage, see Set
IO Image service) where provided data of the submodule are taken from.
This data is sent by the IO-Device and received by the IO-Controller.
Set this value to 0, if ulProvDataLen is 0.

usOffsetIOPSProvider uint16_t Offset of the IO provider state (provider) for this submodule. The offset is
relative to the beginning of the IOPS block in DPM output area. Note 12
usOffsetIOPSConsumer uint16_t Offset of the IO provider state (consumer) for this submodule. The offset is
relative to the beginning of the IOPS block in the DPM input area. Note 2
usOffsetIOCSProvider uint16_t Offset of the IO consumer state (provider) for this submodule. The offset is
relative to the beginning of IOCS block in DPM output area. Note 2
usOffsetIOCSConsumer uint16_t Offset of the IO consumer state (consumer) for this submodule relative to
the beginning of the IOCS block in DPM input area. Note 2
ulReserved uint32_t 0 Reserved for future use. Set to zero.
Note 1: If the IOPS mode is set to “bitwise mode”, the application has to ensure that the offset addresses do not
overlap. The stack will not check them for overlapping in this mode.
Note 2: If the IOCS mode is set to “bitwise mode”, the application has to ensure that the offset addresses do not
overlap. The stack will not check them for overlapping in this mode.
Table 29: Structure PNS_IF_SUBMODULE_STRUCT_T

If you configure more than one API (m > 1), then one PNS_IF_API_STRUCT_T and an array
PNS_IF_SUBMODULE_STRUCT_T[n] has to follow for each additional API. The value n can be set
individually for each API.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.6.2 Set Configuration confirmation

The PROFINET IO-Device protocol stack will return this confirmation to the application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t ERR_HIL_BUFFER_TOO_SHORT means that too many submodules
have been configured. Remedy:
Reduce the number of submodules in the Set Configuration service.
Or
Increase the maximum number of submodules in the tag list.
For other codes, see section Error codes and status codes on page
272.
ulCmd uint32_t 0x1FE3 PNS_IF_SET_CONFIGURATION_CNF
Table 30: PNS_IF_SET_CONFIGURATION_CNF_T – Set Configuration confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_SET_CONFIGURATION_REQUEST_CNF_T;

6.1.6.3 Behavior when receiving a Set Configuration Command

The following rules apply for the behavior of the PROFINET IO Device protocol stack when
receiving a set configuration command:
The configuration data are checked for consistency and integrity.
In case of failure, no data are accepted.
In case of success, the configuration parameters are stored internally (within the RAM).

Note: The new configuration is not processed until a channel init is performed!

No automatic registration of the application at the stack happens.

The confirmation packet PNS_IF_SET_CONFIGURATION_CNF only transfers simple status
information, but does not repeat the whole parameter set.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.7 Register Application service

Using the Register Application Service, the user application provides the stack an endpoint to send
indications to.

Figure 26: Register Application service packet sequence

If the user application is registered at the protocol stack, it will receive the following indications (if
the event triggering any of these indications occurs):
 Save Station Name indication (page 152)
 Save IP Address indication (page 154)
 Reset Factory Settings service (page 157)
 AR Check indication (page 117)
 Check Indication (page 122)
 Connect Request Done indication (page 126)
 Parameterization Speedup Support indication (page 184)
 Parameter End indication (page 129)
 Store Remanent Data Indication
 AR InData indication (page 134)
 APDU Status Changed indication (page 161)
 Read Record indication (page 139)
 Write Record indication (page 144)
 Read I&M indication (page 167)
 Write I&M indication (page 173)
 Alarm Indication (page 163)
 AR Abort Indication (page 149)
 Start LED Blinking service (page 155)
 Stop LED Blinking indication (page 156)
 Link Status Changed Indication (For PNSV4, see reference [7]. For PNSV5, see reference
[8])
 Error Indication (page 166)
 Event Indication (page 185)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Note: It is required that the application returns all indications it receives as valid responses to
the stack. Especially, it is not allowed to change any field in packet header except
ulSta, ulCmd, ulLen, and in case of fragmentation ulExt. Otherwise, the stack will
not be able to handle and assign the response successfully.

For a description of this service, see reference [8] (on page 13).
After Register Application, the stack will send a Link Status Changed Indication to the application
(see Figure 26 on page 80).

6.1.7.1 Register Application for selective indications only

With the “selective indications only” function. It is possible for an application to handle only the
indications the application is interested in. For all other indications, it is possible to implement a
default handling in the application. In that case, the stack behaves in the same way as “if no
application would be registered”.
To activate this service there is no special handling required. Just the regular Register Application
service (page 80) is used.
If the application does not want to handle a specific indication, it is required that the application
returns this indications as responses to the stack changing only two fields in the packet header
and does not change anything in the data part of the other fields in the header of the indication:
ulSta = ERR_HIL_NO_APPLICATION_REGISTERED; /*unhandled indication*/
ulCmd = ulCmd | 1; /*response command*/
To meet the conditions of PROFINET certification, the application has to fulfill conventions listes in
the following table.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.8 Unregister Application service

Using this service the application can unregister with the PROFINET Device stack: the stack will
not generate indications any more.
For a description of the service, see reference [4].

6.1.9 Set OEM Parameters service

The application can use this request to
 set or change specific identification parameters (used for I&M for example, for more
information on Information and Maintenance (I&M), see references [2] and [3] (on page 13)),
 set or change specific communication parameters, or
 activate or deactivate features.
Normally, well-defined Hilscher default values are used. If this is not sufficient for the application,
the application can use this service to change the default values.

Note: This service has to be used before using the Set Configuration service (page 69) to
configure the stack if stack is not configured with database.

Note: If the firmware is configured with database, the two following rules must also be met:
1. The database has to contain the option “Start behavior” set to “application
controlled”.
2. This service has to be used before setting “Bus On”.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 83/323
The following table lists the OEM Parameter services and includes
 whether the OEM parameter can be set in case of a configuration based on Set Config or on
a database,
 whether the application can set the OEM parameter multiple time or only once,
 whether the OEM parameter has influence to the device identity (device identity are all
parameters that identify the IO Device in the network, e.g. VendorID, DeviceID,
SerialNumber, ...),
 whether the OEM parameter activates/deactivates a device feature,
 whether the OEM parameter requires GSDML file modifications.
No. Action Usable with Usable with Allowed Device I&M Device GSDML
Set Config database multiple identity feature impact
times
1 - - - - - - - -
2 - - - - - - - -
3 Set timeout value for waiting yes yes yes no - - -
for application packets (in units
of milliseconds)
4 - - - - - - - -
5 Set bit mask for I&M support yes yes yes no I&M0 - yes
(I&M 1 to I&M 5)
6 Offset address of the “Current yes yes yes - - - -
local cycle counter”
7 - - - - - - - -
8 Switch between I&M handling - yes yes no - - -
by protocol stack or by
application
9 Set I&M5 parameters yes yes yes yes I&M5 - -
10 Activate / deactivate PROFI yes yes yes no - yes yes
energy support of the stack
11 Activate/deactivate IRT yes yes no no - yes yes
support
12 Activate/deactivate IO yes yes yes no - yes yes
Supervisor communication
13 Set minimum cycle time (Must yes yes yes no - - yes
match entry MinDeviceInterval
from GSDML file)
14 - - - - - - - -
15 - - - - - - - -
16 Activate/deactivate Dynamic yes yes yes no - yes yes
Reconfiguration support
17 - - - - - - - -
18 Set Device Identity Not intended yes yes yes I&M0 - yes
Parameters and
Softwareversion in case of
database configuration.
19 Activate/deactivate yes yes no no - yes yes
SecurityClass 1 handling
Table 31: OEM Parameters and their related actions

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 84/323
The columns in the table have the following meaning:
Column Description
Usable with Set Yes: The application can use this parameter type in case the
Config firmware/stack has been configured by Set Configuration service
(via mailbox).
Usable with database Yes: The application can use this parameter type in case the
firmware has been configured by a database (e.g. SYCON.net).
Allowed multiple times Yes: The application can use this parameter type multiple times
after firmware startup.
No: The application can use this parameter type only one time after
firmware startup.
Device identity Yes: This parameter type influences the device identity (e.g.
VendorID, DeviceID, SerialNumber, SoftwareVersion, …) visible on
the network (e.g. via I&M).
No: This parameter type does not influences the device identity
I&M I&M: Number of the I&M data set which is influenced from this
parameter type.
Device features Yes: Activates or deactivates a specific device feature.
GSDML impact Yes: The GSDML file has to match the setting of this parameter.
Depending on the setting of the parameter, an adaption of the
GSDML file to match the setting is required.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.1 Set OEM Parameters request

The application can
 set or change specific identification parameters,
 set or change specific communication parameters, or
 activate or deactivate features.

Note: This packet must be sent prior to the Set Configuration Service packet if stack is not
configured with database, otherwise it will be rejected and the well-defined Hilscher
default values will be used.

Note: If the firmware is configured with Sycon.net, the two following rules must also be met:
1. The database must use the option "application controlled startup".
2. This service has to be used before setting "Bus On".

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 4+n Packet data length in bytes. n depends on the parameter type
contained in the packet.
ulCmd uint32_t 0x1FE8 PNS_IF_SET_OEM_PARAMETERS_REQ
Data
ulParamType uint32_t PNS_IF_SET_OEM_PARAMETERS_TYPE_1, …,
This parameter specifies which structure follows. See below.
union PNS_IF_SET_OEM_PARAMETERS_UNION_T
Depending on the chosen Paramtype the corresponding structure
shall be used here. See below.
Table 32: PNS_IF_SET_OEM_PARAMETERS_REQ_T - Set OEM Parameters Request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 86/323
Packet structure reference
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_1 0x01
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_2 0x02
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_3 0x03
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_4 0x04
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_5 0x05
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_6 0x06
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_7 0x07
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_8 0x08
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_9 0x09
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_10 0x0A
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_11 0x0B
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_12 0x0C
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_13 0x0D
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_14 0x0E
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_15 0x0F
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_16 0x10
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_17 0x11
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_18 0x12
#define PNS_IF_SET_OEM_PARAMETERS_TYPE_19 0x13

/* Request packet */
typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_1_Ttag
{
uint8_t abSerialNumber[16];
uint16_t usProfileId;
uint16_t usRevisionCounter;
uint16_t usProfileSpecificType;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_1_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_2_Ttag

{
/* SerialNumber for usage in I&M0, RPC EndPointMapper and SNMP sysDescr */
uint8_t abSerialNumber[16];
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_2_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_3_Ttag

{
uint32_t ulTimeout;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_3_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_4_Ttag

{
uint16_t usSystemNameLen;
uint8_t abSystemName[255];
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_4_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_5_Ttag

{
uint32_t ulIMFlag;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_5_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_6_Ttag

{
uint16_t usIRTCycleCounterOffset;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_6_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_7_Ttag

{
uint32_t fUseOldLinkStateCommandCode; /* if set use the old packet command
PNS_IF_LINK_STATE_CHANGE_IND, else the new RCX_LINK_STATUS_CHANGE_IND */
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_7_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_8_Ttag

{
uint32_t fDisableFirmwareIMHandling; /* if set firmware does not handle I&M requests in
case of database configuration */
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_8_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_10_Ttag

{
uint32_t fSupportProfiEnergyFunction; /* if set firmware supports ProfiEnergy
functionality */
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_10_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_11_Ttag

{
/* if set firmware supports IRT communication
* @Note IRT support is enabled by default */
uint32_t fSupportIRT;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_11_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_12_Ttag

{
/* if set firmware supports IO Supervisor communication
* @Note IO Supervisor communication support is disabled by default. */
uint32_t fSupportIOSupervisorAR;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_12_T;

#define PNS_IF_SET_OEM_MINDEVICE_INTERVAL_MIN 8
#define PNS_IF_SET_OEM_MINDEVICE_INTERVAL_MAX 4096
#define PNS_IF_SET_OEM_MINDEVICE_INTERVAL_IRT_MAX 32

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_13_Ttag

{
/* The minimum supported cycle time in base of 31,25us (allowed values: Power of two in
range [8 - 4096]).
* It must correspond with MinDeviceInterval from GSDML file
* @Note By default the firmware supports a usMinDeviceInterval of 8 is supported
* this means that a cycle time of 250us will be supported (8 * 31,25 = 250us)
* If IRT supported MinDeviceInterval must not be greater than 32 */
uint16_t usMinDeviceInterval;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_13_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_14_Ttag

{
/* HardwareRevision for usage in I&M0, RPC EndPointMapper and SNMP sysDescr */
uint16_t usHardwareRevision;
/* SoftwareVersion for usage in I&M0, RPC EndPointMapper and SNMP sysDescr */
PNS_IF_IM_SWVERSION_T tSoftwareRevision;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_14_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_15_Ttag

{
/* VendorID to be used (instead of the one contained in configuration database file) */
uint16_t usVendorId;
/* DeviceID to be used (instead of the one contained in configuration database file) */
uint16_t usDeviceId;
/* OrderID to be used (instead of the one contained in configuration database file) -
(pad with spaces (0x20) */
uint8_t abOrderId[PNS_IF_MAX_ORDER_ID];
/* DeviceType to be used (instead of the one contained in configuration database file)
- (ignore the last 3 padding bytes */
uint8_t abDeviceType[PNS_IF_MAX_DEVICE_TYPE_LEN +3];
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_15_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_16_Ttag

{
/* if set firmware supports dynamic reconfiguration feature
* @Note dynamic reconfiguration support is disabled by default. */
uint32_t fSupportDynamicReconfiguration;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_16_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_17_Ttag

{
/* if set protocol stack will not touch IP stack configuration if Bus Off is set
* @Note By default the IP stack is deconfigured on Bus off. */

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 88/323
uint32_t fDisableIpStackDeactivationOnBusOff;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_17_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_18_Ttag

{

/* VendorID to be used (instead of the one contained in configuration database file) */

uint16_t usVendorId;
/* DeviceID to be used (instead of the one contained in configuration database file) */
uint16_t usDeviceId;
/* SoftwareVersion for usage in I&M0, RPC EndPointMapper and SNMP sysDescr */
PNS_IF_IM_SWVERSION_T tSoftwareRevision;
/* DeviceType to be used (instead of the one contained in configuration database file)
- (ignore the last 3 padding bytes */
uint8_t abDeviceType[PNS_IF_MAX_DEVICE_TYPE_LEN +3];
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_18_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_TYPE_19_Ttag

{
/* Default(0): security class is disabled, 1 Stack supports SecurityClass One
functionality */
uint32_t ulEnableSecurityClass; /* set security class, 0 (disable, def. ) or 1 */
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_TYPE_19_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_DATA_Ttag

{
uint32_t ulParameterType;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_DATA_T;

typedef union PNS_IF_SET_OEM_PARAMETERS_UNION_Ttag

{
PNS_IF_SET_OEM_PARAMETERS_TYPE_1_T tType1Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_2_T tType2Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_3_T tType3Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_4_T tType4Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_5_T tType5Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_6_T tType6Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_7_T tType7Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_8_T tType8Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_9_T tType9Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_10_T tType10Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_11_T tType11Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_12_T tType12Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_13_T tType13Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_14_T tType14Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_15_T tType15Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_16_T tType16Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_17_T tType17Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_18_T tType18Param;
PNS_IF_SET_OEM_PARAMETERS_TYPE_19_T tType19Param;
} PNS_IF_SET_OEM_PARAMETERS_UNION_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_SET_OEM_PARAMETERS_DATA_T tData;
PNS_IF_SET_OEM_PARAMETERS_UNION_T tParam;
} __HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.2 OEM parameter: type 1

This parameter type is not supported.

6.1.9.3 OEM parameter: type 2

This parameter type is not supported.

6.1.9.4 OEM parameter: type 3

The application can use this OEM parameter type to modify the default timeout for application
supervision.
If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_3 use the structure
tType3Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T. It is defined as follows:

Variable Type Value / Range Description

ulTimeout uint32_t 0x00000BB8 The timeout (in milliseconds) specifies how long the stack waits
(3000) … for application packets. The value can be 3000 ms or higher.
Default: 3000 ms.
Table 33: PNS_IF_SET_OEM_PARAMETERS_TYPE_3_T - Set OEM Parameter type 3

6.1.9.5 OEM parameter: type 4

Parameter type 4 is deprecated and not supported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.6 OEM parameter: type 5

The application can use this OEM parameter type to enable or disable I&M data sets. The stack
will reject the disabled I&M data sets.
This service is relevant for both modes (set by bit D8 of system flags)
 the stack handles I&M requests or
 the application handles I&M requests.
If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_5 use the structure
tType5Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T. It is defined as follows:

Variable Type Value / Range Description

ulIMFlag uint32_t 0x07 (default), A bitmask enables which I&M data sets are supported. Each bit
0x0F, corresponds to an I&M data set.
0x17, I&M1, I&M2, and I&M3 always have to be enabled.
0x1F If a flag is set, the corresponding I&M data set is enabled and will be
either handled by the stack internally or forwarded to the application
depending on system flags used in Set Configuration service (page
69).
Default value is 0x07: I&M1, I&M2, and I&M3 are enabled.
Table 34: PNS_IF_SET_OEM_PARAMETERS_TYPE_5_T – Set OEM Parameter type 5

Coding of ulIMFlag

Bit Description
D0 Set to 1 using PNS_IF_STACK_HANDLE_IM_1 to enable I&M1 data set.
I&M1 always has to be enabled.
D1 Set to 1 using PNS_IF_STACK_HANDLE_IM_2 to enable I&M2 data set.
I&M2 always has to be enabled.
D2 Set to 1 using PNS_IF_STACK_HANDLE_IM_3 to enable I&M3 data set.
I&M3 always has to be enabled.
D3 If this flag is set using PNS_IF_STACK_HANDLE_IM_4, the stack will enable I&M4 data set.
0 = I&M4 data set is disabled.
1 = I&M4 data set is enabled.
D4 If this flag is set using PNS_IF_STACK_HANDLE_IM_5, the stack will enable I&M5 data set.
0 = I&M5 data set is disabled.
1 = I&M5 data set is enabled.
D5 – D15 Reserved, set to zero.
Table 35: Coding of ulIMFlag

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 91/323
6.1.9.7 OEM parameter: type 6
The application can use this OEM parameter type to configure the offset address for the “current
local cycle counter”. The stack copies the value of the “current local cycle counter” (16-bit value) to
the input data memory (consumer data of the IO Device).

Note: This service is intended to be used by Isochrone Mode applications for IRT.

Note: The application can use this service only if the stack is in state unconfigured.

IRT mode
In case of IRT operation of the IO Device, the stack uses the “cycle counter” value from the last
received frame of the IO Controller for the “current local cycle counter” before copying it into the
input data memory. In case of error (e.g. no cyclic frame received), the stack copies an
incremented value of the “current local cycle counter” to the input data memory. As soon as the
communication returns to normal operation, the stack continues to use the “cycle counter” value
from the last received frame of the IO Controller for the “current local cycle counter”.

Note: In IRT operation mode, the “current local cycle counter” is equal to the “cycle counter”
of the IO Controller. Thus in IRT operation mode the cycle counter represents the
“current IRT cycle” counter at any time.

RT mode

Note: In case of RT operation of the IO Device, the value of the “current local cycle counter”
is NOT identical to the “cycle counter” of the IO Controller. This service is not useful for
RT mode.

Description of the parameter

If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_6 use the structure
tType6Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T. It is defined as follows:

Variable Type Value / Range Description

usIRTCycleCounterOf uint16_t 0 … 5758 Offset address in the input data memory the value of the “current
fset local cycle counter” is copied to. The value of the “current local
cycle counter” requires 2 bytes in the input data memory.
0xFFFF “Current local cycle counter” is not copied to the input data
memory (default).
Table 36: PNS_IF_SET_OEM_PARAMETERS_TYPE_6_T - Set OEM Parameter type 6

Note: In case this service is active, a ChannelInit will not deactivate this service. To
deactivate this service, the application has to write offset 0xFFFF.

Note: If the application wants to change the offset address, the application has to write offset
0xFFFF to deactivate this service first. Afterwards, the application can write the new
offset value and reactivates this service.

6.1.9.8 OEM parameter: type 7

This parameter type is not supported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.9 OEM parameter: type 8

In case the stack is configured with a database file, the application can disable the handling of I&M
data by the stack. The application can use this OEM type parameter service at runtime but only in
state “Bus off”.
In case the stack is configured with the Set Configuration service (page 69), the packet will be
accepted and the stack behavior regarding I&M handling will be modified. However, when using
Set Configuration it is recommended to not use this service for modification but instead use Set
Configuration Service means, see ulSystemFlags in Set Configuration service.
If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_8 use the structure
tType8Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T. It is defined as follows:

Variable Type Value / Range Description

fDisableFirmwareIMHandling uint32_t 0 Default: Stack handles I&M data if stack is configured
with a database.
1 … 0xFFFFFFFF Application handles I&M data
Table 37: PNS_IF_OEM_PARAMETERS_TYPE_8_T - Set OEM Parameter type 8

6.1.9.10 OEM parameter: type 9

The application can use this OEM parameter type to modify the I&M5 parameters reported by
stack to the network.
If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_9 the structure tType9Param of
PNS_IF_SET_OEM_PARAMETERS_UNION_T shall be used. It is defined as follows:

Variable Type Value / Range Description

abAnnotation[64] uint8_t String Annotation
abOrderId[64] uint8_t String Order id
usVendorId uint16_t Numeric Vendor id
abSerialNumber[16] uint8_t String Serial number od the device
usHardwareRevision uint16_t Numeric Hardware revision
tSoftwareRevision PNS_IF_IM_SWVERSION_T Software revision including: prefix and version
x, y, and z.
Table 38: PNS_IF_OEM_PARAMETERS_TYPE_9_T - Set OEM Parameter type 9

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Note: The application can use this service only if the stack is in state unconfigured.

If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_10 use the structure

tType10Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T. It is defined as follows:

Variable Type Value / Range Description

fSupportProfiEnergyFunction uint32_t 0 Default: PROFIenergy is disabled
1 … 0xFFFFFFFF Stack supports PROFIenergy functionality
Table 39: PNS_IF_OEM_PARAMETERS_TYPE_10_T - Set OEM Parameter type 10

6.1.9.12 OEM parameter: type 11

Variable Type Value / Range Description

fSupportIRT uint32_t 0 IRT communication deactivated.
1 … 0xFFFFFFFF Default: IRT communication activated.
Table 40: PNS_IF_OEM_PARAMETERS_TYPE_11_T - Set OEM Parameter type 11

6.1.9.13 OEM parameter: type 12

IO Supervisor AR: By default, the support of an “IO Supervisor AR” is disabled and the stacks
rejects an IO Supervisor (with access to I/O) connection request. First, the application has to
activate “IO Supervisor AR support” to allow an “IO Supervisor AR”. If enabled, each IO AR can be
used as “IO Supervisor AR”. The tag list parameter “Number of additional IO connections” allows
the user to configure the maximum number of IO ARs.

Variable Type Value / Range Description

fSupportIOSupervisorAR uint32_t 0 “IO Supervisor AR” disabled (default).
1 … 0xFFFFFFFF “IO Supervisor AR” enabled.
Table 41: PNS_IF_OEM_PARAMETERS_TYPE_12_T - Set OEM Parameter type 12

IO Supervisor Device Access AR: By default, the stack supports “IO Supervisor DA AR”, even if
“IO Supervisor AR support” is disabled. The “IO Supervisor DA AR” can be disabled separately via
the tag list parameter “Number of parallel DA ARs”.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.14 OEM parameter: type 13

Variable Type Value / Range Description

usMinDeviceInterval uint16_t 8, 16, 32, …, 4096 Configures the minimum supported cycletime and has
the time base of 31.25 us. The value has to be a
power of 2.
Default: 8 (8 * 31.25 us = 250 us)
For IRT: 8, 16, 32
This value must correspond with MinDeviceInterval
from the GSDML file.
Table 42: PNS_IF_OEM_PARAMETERS_TYPE_13_T - Set OEM Parameter type 13

6.1.9.15 OEM parameter: type 14

This parameter type is not supported.

6.1.9.16 OEM parameter: type 15

This parameter type is not supported.

6.1.9.17 OEM parameter: type 16

The application can use this OEM parameter type to enable the feature Dynamic Reconfiguration.
This parameter can only be set if the stack is not configured.

Note: This service is available only in a firmware/stack which includes the features System
Redundancy and Dynamic Reconfiguration. For an overview, see section Overview of
loadable firmware (page 15).

If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_16 use the structure

tType16Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T.

Variable Type Value / Range Description

fSupportDynamicReconfiguration uint32_t 0 Dynamic Reconfiguration is disabled (default).
1 … 0xFFFFFFFF Dynamic Reconfiguration is enabled.
Table 43: PNS_IF_OEM_PARAMETERS_TYPE_16_T - Set OEM Parameter type 16

6.1.9.18 OEM parameter: type 17

This parameter type is not supported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.19 OEM parameter: type 18

The application can use this OEM parameter type to modify device identity parameters used for
I&M, SNMP and RPC.

Note: The application can use this service if the stack is configured with a database file, the
start behavior is set in the database “Application Controlled Startup” and bus
communication is still deactivated (bus-off).
Using this service in combination with mailbox configuration (via Set Configuration
Service) is not intended).

If ulParamType is set to PNS_IF_SET_OEM_PARAMETERS_TYPE_18 use the structure

tType18Param of PNS_IF_SET_OEM_PARAMETERS_UNION_T.

Variable Type Value / Range Description

usVendorId uint16_t Vendor ID, see “Set Configuration request” for details
usDeviceId uint16_t Device ID, see “Set Configuration request” for details
tSoftwareRevision PNS_IF_IM_SWVER See table below.
SION_T
abDeviceType[PNS_IF_M uint8_t[] DeviceType, see “Set Configuration request” for
AX_DEVICE_TYPE_LEN details
+3]
Table 44: PNS_IF_OEM_PARAMETERS_TYPE_18_T - Set OEM Parameter type 18

Variable Type Value / Range Description

tSoftwareRevision.bPrefix uint8_t Character describing the software version Prefix.
Allowed values: ‘V’, ‘R’, ‘P’, ‘U’ and ‘T’
tSoftwareRevision.bX uint8_t Function enhancement. (Major version number) of
the application.
tSoftwareRevision.bY uint8_t Bug fix (Minor version number) of the application.
tSoftwareRevision.bZ uint8_t Internal Change (Build version number) of the
application.
Table 45: PNS_IF_IM_SWVERSION_T

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.9.20 OEM parameter: type 19

The application can use this OEM parameter type to activate support of a specific PROFINET
Security Class. Currently, only Security Class 1 is supported.

Note: All PROFINET Security Classes require signed GSDML files in order to fullfil the
requirement of the Security Class. It is not sufficient to simply enable the Security Class
in the firmware. In addition, the Device vendor needs to sign its GSDML file
accordingly.

Variable Type Value / Range Description

ulEnableSecurityClass uint32_t 0 Default: No security class supported.
1 Security Class 1 enabled.
Table 46: PNS_IF_OEM_PARAMETERS_TYPE_19_T - Set OEM Parameter type 19

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination queue handle of PNS_IF task process queue
ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1FE9 PNS_IF_SET_OEM_PARAMETERS_CNF
Table 47: PNS_IF_SET_OEM_PARAMETERS_CNF_T - Set OEM Parameters confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_SET_OEM_PARAMETERS_CNF_Ttag{
HIL_PACKET_HEADER_T tHead;
}__HIL_PACKED_POST PNS_IF_SET_OEM_PARAMETERS_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.10 Set Remanent Data service

This service is relevant for PNSV5 only.
In case the application stores the remanent data, the application has to use Set Remanent Data
service (HIL_SET_REMANENT_DATA_REQ) and has to provide the remanent data to each stack
component. For a description of the packet, see reference [8] (on page 13).
The application has to use the “Communication channel packet fragmentation”. For a detailed
description, see reference [8] (on page 13).

6.1.11 Configuration Delete service

The application can delete the current configuration with the Configuration Delete service, for a
description see HIL_DELETE_CONFIG_REQ in reference [8] (on page 13).
In addition to the current configuration, the stack deletes all remanent data and resets these to
default values.
This service will not delete configuration files downloaded with the configuration software
SYCON.net.
In case the stack performs cyclic data exchange, the configuration will be deleted, however the
cyclic data exchange will not be interrupted and a valid data exchange is still assured.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.12 Set IOXS Config service

The user application must use this service in order to enable reading/writing data states from/to the
consumer/provider data image. When enabling this functionality, the stack will copy the provider
data states of consumer data into the consumer data image and take the provider data states of
provider data from provider data image. In this case, the user application is responsible for setting
these states appropriate. For a detailed description of the structure of the data state block in the
input/output image, refer to the Dual Port Memory interface manual. See also section Configuration
of process data images (page 65) which contains an example.

6.1.12.1 Set IOXS Config request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 32 Packet data length in bytes.
ulCmd uint32_t 0x1FF2 PNS_IF_SET_IOXS_CONFIG_REQ- Command
Data
ulIOPSMode uint32_t 0 ... 2 Desired encoding of the IOPS states. Either disabled, bit list
(valid invalid) or byte list (complete IOPS)
ulConsImageIOPSOffset uint32_t 0 ... 216 -1 The offset, where the provider state block for consumer data
shall start in the consumer data image. The offset is relative to
the beginning of the consumer data image.
See section Configuration of process data images (page 65)
for further information
ulReserved1 uint32_t 0 Reserved. Set to zero for compatibility reasons.
ulProvImageIOPSOffset uint32_t 0 ... 216 -1 The offset, where the provider state block for provider data
shall start in the provider data image. The offset is relative to
the beginning of the provider data image.
See section Configuration of process data images (page 65)
for further information
ulIOCSMode uint32_t 0 …. 2 Desired encoding of the IOCS states. Either disabled, bit list
(valid invalid) or byte list (complete IOCS)
ulConsImageIOCSOffset uint32_t 0 ... 216 -10 The offset, where the consumer state block for consumer data
shall start in the consumer data image. The offset is relative to
the beginning of the consumer data image.
See section Configuration of process data images (page 65)
for further information
ulReserved2 uint32_t 0 Reserved. Set to zero for compatibility reasons.
ulProvImageIOCSOffset uint32_t 0 ... 216 -1 The offset, where the consumer state block for provider data
shall start in the provider data image. The offset is relative to
the beginning of the provider data image.
See section Configuration of process data images (page 65)
for further information
Table 48: PNS_IF_SET_IOXS_CONFIG_REQ_T – Set IOXS Config request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 100/323
Packet structure reference
typedef enum PNS_IF_IOPS_MODE_Etag
{
PNS_IF_IOPS_DISABLED = 0,
PNS_IF_IOPS_BITWISE,
PNS_IF_IOPS_BYTEWISE,
} PNS_IF_IOPS_MODE_E;

typedef enum PNS_IF_IOCS_MODE_Etag

{
PNS_IF_IOCS_DISABLED = 0,
PNS_IF_IOCS_BITWISE,
PNS_IF_IOCS_BYTEWISE,
} PNS_IF_IOCS_MODE_E;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_IOXS_CONFIG_DATA_Ttag

{
uint32_t ulIOPSMode;
uint32_t ulConsImageIOPSOffset;
uint32_t ulReserved1;
uint32_t ulProvImageIOPSOffset;

uint32_t ulIOCSMode;
uint32_t ulConsImageIOCSOffset;
uint32_t ulReserved2;
uint32_t ulProvImageIOCSOffset;
} __HIL_PACKED_POST PNS_IF_SET_IOXS_CONFIG_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_IOXS_CONFIG_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_SET_IOXS_CONFIG_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SET_IOXS_CONFIG_REQ_T ;

6.1.12.2 Set IOXS Config confirmation

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination queue handle of PNS_IF task process queue
ulLen uint32_t 0 Packet data length in bytes.
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1FF3 PNS_IF_SET_IOXS_CONFIG_CNF
Table 49: PNS_IF_SET_IOXS_CONFIG_CNF_T – Set IOXS Config confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_SET_IOXS_CONFIG_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
} __HIL_PACKED_POST PNS_IF_SET_IOXS_CONFIG_CNF_T ;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.13 Load Remanent Data service

This service is relevant for PNSV4 only.
Using this service the application can hand over the required remanent data to the stack. This
service has to be used if the application stores remanent data, which is the case when bit D14 is
set in the system flags of the Set Configuration request.

Note: The request may be rejected by the stack with error code “invalid length” or “invalid
parameter version” after a firmware update. The remanent data contains a fingerprint of
the firmware version and its content may change in future versions of the stack. To
avoid problems with invalid parameters this security check was implemented.

In this case, the application has to continue with startup and ignore the return value.

6.1.13.1 Load Remanent Data request

This service allows the application to hand over the remanent data needed by the stack. The stack
will check the data and if it is correct, this data will be used.
It is necessary for the application to fragment the request packet. This happens due to the limited
size of the mailbox. The handling of packet fragmentation is described in section “General packet
fragmentation” in reference [7].

Important: This packet must be sent prior to the Set Configuration request packet, otherwise this
packet will be rejected and the default values will be used.

Important: This packet must be sent to the stack either once or never at all. Multiple use of this
packet is not allowed.

Packet description

Variable Type Value / Description

Range
ulDest uint32_t Destination queue handle of PNS_IF task process
queue
ulLen uint32_t 1+n Packet data length in bytes.
ulCmd uint32_t 0x1FEC PNS_IF_LOAD_REMANENT_DATA_REQ
ulExt uint32_t Sequence number for use in fragmented packets
Data
abData[1] uint8_t The remanent data, which was reported by the
stack. This is only the first byte as a placeholder. All
remaining bytes have to follow this one.
Table 50: PNS_IF_LOAD_REMANENT_DATA_REQ_T - Load Remanent Data request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 102/323
Packet structure reference
typedef __HIL_PACKED_PRE struct
{
/** this is only the first byte, many others may follow */
uint8_t abData[1];
} __HIL_PACKED_POST PNS_IF_LOAD_REMANENT_DATA_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_LOAD_REMANENT_DATA_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_LOAD_REMANENT_DATA_REQ_T;

6.1.13.2 Load Remanent Data confirmation

The stack informs the application about the success or failure of restoring the remanent data.

Packet description

Variable Type Value / Description

Range
ulDest uint32_t Destination queue handle of PNS_IF task process
queue
ulLen uint32_t 0 Packet data length in bytes.
ulSta uint32_t See section Error codes and status codes on page
272.
ulCmd uint32_t 0x1FED PNS_IF_LOAD_REMANENT_DATA_CNF
Table 51: PNS_IF_LOAD_REMANENT_DATA_CNF_T - Load Remanent Data confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_LOAD_REMANENT_DATA_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.14 Set Trigger Type service

The PROFINET IO-Device stack allows configuration of Sync mode and the DPM IO exchange
modes (free-run and synchronous) for both data directions (Output and Input).
For a description of the packet, see reference [8] (on page 13).

Note: The Please not that the configuration of the consumer and provider data update trigger
mode are restricted. The Profinet stack does not support the time synchronisation of
Input and Output Tigger modes (HIL_TRIGGER_TYPE_PDOUT_TIMED_LATCH,
HIL_TRIGGER_TYPE_PDIN_TIMED_ACTIVATION).

Note: For PNSV4, Freerun mode (HIL_TRIGGER_TYPE_PDOUT_NONE,

HIL_TRIGGER_TYPE_PDIN_NONE) is not supported. In addition, the application should
request the update of the I/O data only once in a cycle time.

Note: Please note that the protocol stack only support the Host controlled Mode. In this case,
the host application initially has access to DPM area and therefore has to request the
trigger event on every cycle so that the events can be triggered by the stack as
expected

The application has to set three parameters for controlling the triggering of the handshake, namely
usPdInHskTriggerType, usPdOutHskTriggerType and usSyncHskTriggerType.
The following table lists the values the application can use with the PROFINET IO-Device stack.
Parameter Supported by the PROFINET IO-Device stack
usPdInHskTriggerType HIL_TRIGGER_TYPE_PDIN_NONE (only for PNSV5)
HIL_TRIGGER_TYPE_PDIN_RX_DATA_RECEIVED
usPdOutHskTriggerType HIL_TRIGGER_TYPE_PDOUT_NONE (only for PNSV5)
HIL_TRIGGER_TYPE_PDOUT_READY_FOR_TX_DATA
usSyncHskTriggerType HIL_TRIGGER_TYPE_SYNC_NONE
HIL_TRIGGER_TYPE_SYNC_TIMED_ACTIVATION
HIL_TRIGGER_TYPE_SYNC_TIMED_LATCH
Table 52: Values Set Trigger Type service supported by the PROFINET IO-Device stack

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 104/323
DPM input trigger event sequence
The following diagram shows when the stack acknowledges the update of the DPM input data.
When the DPM input trigger mode is enabled, regardless of when (in the data cycle) the
application requests the update of the DPM input data, the protocol stack delays the update
confirmation until new Output data is received (after the red phase).

Figure 27: DPM input trigger event

Note: In case the cifX toolkit is used, “Request update of DPM input area” will triggered when
the update of the DPM input area is confirmed by the stack.

DPM Output Trigger event sequence

The following diagram shows when the stack acknowledges the update of the DPM Output data.
When the DPM Output trigger mode is enabled, regardless of when (in the data cycle) the
application requests the update of the DPM Output data, the stack delays the update confirmation
until new cycle is started (after the red phase).

Figure 28: DPM Output trigger event

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Sync Trigger event sequence

Note: The software-assisted synchronisation using DPM Sync Handshak only offers a limited
possibility to report a sync event.This is because there is only one sync handshake per
communication channel and there is no way to identify the trigger event source (Input
or Output event ) via DPM.

The following diagram shows when the stack triggers the Sync event.

Figure 29: DPM Sync trigger event

To configure sync event timing (Cycle time and Offset), the application has to use the service,
otherwise the stack uses the default value specified in "netX Synchronization".
In order to ensure accurate process synchronization and to avoid missing data cycles the
application, the application shall request the sync (toggel HSYNCF_CH0) immediately after the
sync event is reported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.1.15 Config Trigger Event service

The user application may use this service in order to determine when the sync signal should be
triggered within the cycle time.

When enabling this functionality, the stack will re-configure the xC trigger Unit so that the
xC_Trigger signals “xC_Trigger 0" and "xC Trigger 1" are triggered at the configured offsets.

Note: This service is independent of the Isochronous mode. It can also be used even if no
IRT connection established or the IO-Device is not synchron to the IO-Controller (acts
like a free running HW-Timer)

6.1.15.1 Config Trigger Event Request

The cycle time must be equal or an integral multiple of the synchronization cycle time (T_DC) The
configured cycle time may be retreived either from the Isochronous Mode Data Recorde or from
the protocol stack by using the Get Submodule Parameter Service
(PNS_IF_PARAM_SUBMODULE_CYCLE).
The application can disable the triggering of a sync signal by setting the releated ulCycleTime to 0.

Note: The Configuration of trigger events shall be done after receiving Parameter End
Indication

Packet description

Structure Information: PNS_IF_CONFIG_TRIGGER_EVENT_REQ_T

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 16
ulCmd uint32_t 0x1F24 PNS_IF_CONFIG_TRIGGER_EVENT_REQ
Data
atTriggerEvent[2] PNS_IF_CONFIG_TRIGG Triggert event configuration for both signal
ER_EVENT_T sources.

atTriggerEvent[0] provides configuration for trigger

signal "XC_Trigger_0"

atTriggerEvent[1] provides configuration for trigger

signal "XC_Trigger_1"

The structure describing the device parameters,

see explanation below.
Table 53: PNS_IF_SET_CONFIGURATION_REQ_T - Set Configuration request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Structure Information: PNS_IF_CONFIG_TRIGGER_EVENT_T

Variable Type Value / Range Description

ulCycleTime uint32_t 0..1024 The period in which the event should be reported
in unit of 31,25 us.
ulOffset uint32_t 0..32000 The time related to the beginning of the cycle at
which the event is to be reported in microseconds.

Note: The Please note that "T_IO_Input" refers to the start of the next Data Cycle. To
configure trigger event to fetch Input data, The application has to callculate the offset at
which the event shall be reported as follow: ulOffset = (T_DC * 31,25) - T_IO_Input

6.1.15.2 Config Trigger Event Confirmation

The stack will return this packet to application.

Structure Information: PNS_IF_CONFIG_TRIGGER_EVENT_CNF_T

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 0
ulCmd uint32_t 0x1F25 PNS_IF_CONFIG_TRIGGER_EVENT_CNF

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 30: Configure trigger events

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2 Connection Establishment

After the stack has been configured, the device is ready for operation.

Bus On State
If auto start is disabled, the application has to switch the device to Bus On. If auto start is enabled,
the device automatically reaches the Bus On state. In Bus On state, the device waits for incoming
events from the network.

NameOfStation
If the device is activated for the first time, usually NameOfStation has not been configured yet in
the device. The NameOfStation stored in the device must match to the configuration of the
controller in order that the controller can communicate with the device. Therfore the
NameOfStation needs to be set by the engineering tool to the device or will be assigned by the
controller according to the topology. For details about allowed characters, see section Name
encoding (page 309).
The following figure shows the sequence of DCP Set NameOfStation if using an engineering tool.

Figure 31: Initial configuration: DCP Set NameOfStation (by engineering tool)
In case, the controller has the topology information of the network, the controller can set the
NameOfStation. The following figure shows the sequence of DCP Set NameOfStation by the
controller.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 32: Initial configuration: DCP Set NameOfStation (by controller)

IP parameters
In the next step, the controller will verify the IP parameters of the device and adapt them according
to its configuration.
The next figure shows the DCP protocol to set IP parameters.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 33: Initial configuration: DCP Set IP

AR establishment
After the IP parameters have been set in the device, the IP stack of the device is active and the
RPC layer accepts incoming requests from the network. The controller will now establish an AR. If
the application registered at the stack previously, several indications will be generated. The
application has to handle these indications properly in order to establish the connection
successfully.

AR establishment: Connect
The very first indication will be the AR Check indication (see section AR Check service (page 117).
This informative indication signifies the beginning of the AR establishment phase.
In the next step, the stack compares the module configuration requested by the controller with the
current module configuration of the stack. Depending on the stack configuration parameters, the
stack will now generate a Check Indication (see section Check Indication service (page 120) for
each used, wrong, unused or missing (sub) module. If desired, the application has the opportunity
to reconfigure the stack. In order to do so, the application should use the Plug/Pull services before
returning the Check Response back to the stack. Additionally, the Check Response provides the
ability to report a substitute (sub) module.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 34: Connection Establishment: Connect

After all Check Indications have been processed, the stack will issue a Connect Request Done
indication (see section Connect Request Done service (page 126) to the application. This
indication signifies the end of the first phase to the application. The application now has the option
to configure the stack. As soon as the application has sent the Connect Request Done response,
the stack will generate the Connect.cnf to the PROFINET Controller.

AR establishment: Write Parameters

The PROFINET Controller will now parameterize the device by writing the parameter records of the
valid (sub-) modules. If parameter records have been specified in the device description file
(GSDML), Write Record indications (see section Write Record service (page 143) will be generated
for each record written by the controller. This data has to be validated and evaluated by the
application.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 35: Connection Establishment: Write Parameter

For advanced start-up: The stack sends a Parameterization Speedup indication to the application
before it has received a ParamEnd control message from the IO-Controller if this AR uses
FastStartUp.
For legacy start-up: As soon as the PROFINET Controller has finished writing the parameters, it
will generate a ParamEnd control message. At first, the stack will check if this AR uses
FastStartUp (FSU). This will be indicated to the application by issuing a Parameterization Speedup
indication with non-zero UUID.
If the application has received a Parameterization Speedup indication with non-zero UUID, the
application must store the UUID and the parameter records into a non-volatile memory in order to
restore them on next power up. Use the UUID value to detect parameter changes in that case.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

AR establishment: Parameter End and Application Ready

Figure 36: Connection Establishment: Parameter End and Application Ready

The stack generates a Parameter End indication (see section Parameter End service (page 128).
At this time, the application has to apply all written parameter data to its internal logic/hardware.
Only if parameters have changed or non-FSU mode is in use. Otherwise, the parameter should
have been restored from non-volatile memory at power on already. When finished, the application
has to generate the Parameter End response. If the application will need some further initialization
time, the application may explicitly request Application Ready by setting fSendApplReady to False
and generating an Set_ApplReady_Req later on (see section Application Ready service (page
131).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 115/323
Note: Before the stack actually generates the Application Ready request to the IO-
Controller, it will also wait for the application to update the provider data. This is
necessary, as the cyclic telegrams sent by the device must contain valid data before
the application ready is issued.

Finally, the AR InData indication (see section AR InData service (page 134) informs the application
about the fact that the first cyclic frame from the IO-Controller has been received after the
Application Ready confirmation. The AR is now established and valid data exchange takes place.

Note: As the stack supports multiple ARs, multiple connection establishment sequences may
occur in the same time. In order to differentiate between these ARs, use the device
handle parameter of the indications.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Service Command code Command code

(REQ or IND) (CNF or RES)
AR Check service (page 117) 0x1F14 0x1F15
Check Indication service (page 120) 0x1F16 0x1F17
Connect Request Done service (page 126) 0x1FD4 0x1FD5
Parameter End service (page 128) 0x1F0E 0x1F0F
Application Ready service (page 131) 0x1F10 0x1F11
AR InData service (page 134) 0x1F28 0x1F29
PNSV4 only: Store Remanent Data service (page 136) 0x1FEA 0x1FEB
PNSV5 only: Store Remament Data service (see 0x2F8E 0x2F8F
reference [8] (on page 13))
Table 54: Connection establishment service overview

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.2 AR Check service

The AR Check Service is used by the protocol stack to indicate that a new AR is going to be
established. The protocol stack will generate it right after receiving and checking the PROFINET
connect request.

6.2.2.1 AR Check indication

This packet contains information about the AR to be established. The stack sends this packet to
the application.
Only evaluate the two last parameters of this packet (tARUUID and usRdhtValule) if usARType
== 0x20.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 290 Packet data length in bytes
ulCmd uint32_t 0x1F14 PNS_IF_AR_CHECK_IND
Data
hDeviceHandle uint32_t The device handle.
usARType uint16_t Connect request’s AR-Type
ulARProperties uint32_t Connect request’s AR-Properties.
ulRemoteIpAddr uint32_t IO-Controller’s IP address.
usRemoteNameOfStationLen uint16_t 1..240 Length of IO-Controller’s NameOfStation.
abRemoteNameOfStation[240] uint8_t IO-Controller’s NameOfStation as ASCII byte-array.
tCmInitiatorObjUUID HIL_UUID_T The ContextManagement Initiator Object UUID used
by IO-Controller for this AR.
tARUUID HIL_UUID_T AR ARUUID
usRdhtValue uint16_t RedundancyDataHoldTimer of the whole AR-Set
Table 55: PNS_IF_AR_CHECK_IND_T - AR Check indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_AR_CHECK_IND_DATA_Ttag
{
uint32_t hDeviceHandle;
uint16_t usARType;
uint32_t ulARProperties;
uint32_t ulRemoteIpAddr;
uint16_t usRemoteNameOfStationLen;
uint8_t abRemoteNameOfStation[PNS_IF_MAX_NAME_OF_STATION];
HIL_UUID_T tCmInitiatorObjUUID;

/** The following fields are not supported by PNSv3 implementation and only valid for
PNSv4 implementation */
/** The following fields shall only be evaluated if usARType == 0x20 (IOCARSR: System
redundancy or dynamic reconfiguration). */
/* AR ARUUID */
HIL_UUID_T tARUUID;
/* RedundancyDataHoldTimer of the whole AR-Set */
uint16_t usRdhtValue;

} __HIL_PACKED_POST PNS_IF_AR_CHECK_IND_DATA_T;
typedef __HIL_PACKED_PRE struct PNS_IF_AR_CHECK_IND_Ttag

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 118/323
{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_AR_CHECK_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_AR_CHECK_IND_T;

usARType

Value AR Type
0x01 IO Controller AR with RT
0x06 IO Supervisor AR
Supervisor DA AR (ulARProperties.DeviceAccess = 1)
Supervisor AR (ulARProperties.DeviceAccess = 0)
0x10 IO Controller AR with IRT
0x20 SystemRedundancy AR
Table 56: AR Types

ulARProperties

Bit Name AR Properties

3 Supervisor Takeover 0: IO-Controller does not allow take over
allowed 1: IO-Controller allowed take over
4 ParameterizationServer 0: External ParameterizationServer is used
1: IO-Controller is ParameterizationServer
8 DeviceAccess 1: IO Supervisor AR is of Type DeviceAccess
30 Startup Mode 0: Legacy Startup is used
1: Advanced Startup is used
all others - Not to be evaluated by the application.
Values: 0 or 1.
Table 57: AR Properties

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.2.2 AR Check response

The application has to return an AR check response after receiving the AR Check Indication.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t 0 Status has to be ok for this service.
ulCmd uint32_t 0x1F15 PNS_IF_AR_CHECK_RES
Data
hDeviceHandle uint32_t The device handle.
Table 58: PNS_IF_AR_CHECK_RSP_T - AR Check response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_AR_CHECK_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.3 Check Indication service

If the PROFINET IO-Controller expects different submodules as configured in the PROFINET IO-
Device stack, the stack sends the Check Indication (page 122) service to the application. The
indication contains all parameters the controller expected along with the current module and
submodule state. If the submodule state is indicated as PNIO_SUBSTATE_WRONG_SUBMODULE the
application may use the submodule state PNIO_SUBSTATE_SUBSTITUTE_SUBMODULE in the
response to tell the stack that the configured submodule is able to perform like the requested
submodule. Alternatively, if the application is designed to adapt to the requested configuration, the
application may reconfigure the stack on check indication.

Note: A Check Indication Service may also be issued after an Extended Plug Submodule
request. In that case, the recently plugged submodule has been associated with a new
AR, which expects another submodule.

Note: A Check Indication Service may also be issued after a submodule AR ownership
change. In that case, a submodule has been associated with an existing AR, which
expects another submodule.

In most applications, the device will not adapt to the controllers configuration, e.g. (modular) I/O
devices, sensors, gateways etc. The sequence for this is shown in the following figure:

Figure 37: Check Service Packet sequence for non-adapting applications

Special applications may require an adaption to the controller expectations. This includes for
example:
 PROFIdrive: Here, the controller selects the desired PROFIdrive telegram type by means of
submodule id.
 Selectable Data Length for Sensors: The maximum length of the presented barcode may be
selected by module/submodule id.
 Configuration of a gateway by adapting to the submodule configuration expected by the
controller.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 121/323
The packet sequence then is
1. Check indication
2. Pull request and confirmation: Pull Module Request and Pull Module Confirmation or
Pull Submodule Request and Pull Submodule Confirmation.
3. Plug request and confirmation: Plug Submodule Request and Plug Submodule Confirmation
or Extended Plug Submodule Request and Extended Plug Submodule Confirmation.
4. Check response
The next figure shows the sequence for adaption:

Figure 38: Check Service Packet sequence for adapting applications

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.3.1 Check Indication

This packet indicates the parameters of a wrong / missing (sub) module to the application. If
enabled by the corresponding startup flags in Service, this indication will also be generated for
unused or correct submodules.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 32 Packet data length in bytes
ulCmd uint32_t 0x1F16 PNS_IF_CHECK_IND
Data
hDeviceHandle uint32_t The device handle.
ulApi uint32_t The API of the wrong submodule.
ulSlot uint32_t The slot of the wrong submodule.
ulSubslot uint32_t The subslot of the wrong submodule.
ulModuleId uint32_t The Module ID the IO-Controller expected
usModuleState uint16_t The Module State suggested by the stack (see Table 60 on page
123).
ulSubmodId uint32_t The Submodule ID the IO-Controller expected.
usSubmodState uint16_t The Submodule state suggested by the stack (see Table 61 on
page 123).
usExpInDataLen uint16_t The length of input data IO-Controller expects for the submodule.
This is only informative for application.
usExpOutDataLen uint16_t The length of output data IO-Controller expects for the submodule.
This is only informative for application.
Table 59: PNS_IF_CHECK_IND_T - Check Indication

Packet structure reference

/** Module state code */
typedef enum PNIO_MODSTATE_Etag /* Module state */
{
PNIO_MODSTATE_NO_MODULE = 0, /**< no module plugged in slot */
PNIO_MODSTATE_WRONG_MODULE, /**< wrong module plugged in slot */
PNIO_MODSTATE_PROPER_MODULE, /**< proper module */
PNIO_MODSTATE_SUBSTITUTE_MODULE, /**< substitute, the wrong module can fulfill
requirements */
PNIO_MODSTATE_UNUSED_MODULE, /**< module not expected by controller */
PNIO_MODSTATE_CORRECT_MODULE = 0xFFFF, /**< correct module was plugged by application
*/
} PNIO_MODSTATE_E;

/** submodule state code */

typedef enum PNIO_SUBSTATE_Etag /* Submodule state */
{
PNIO_SUBSTATE_NO_SUBMODULE = 0, /**< no submodule */
PNIO_SUBSTATE_WRONG_SUBMODULE, /**< Wrong submodule */
PNIO_SUBSTATE_PROPER_SUBMODULE, /**< locked by IO controller */
PNIO_SUBSTATE_RESERVED_1, /**< reserved */
PNIO_SUBSTATE_APPL_READY_PENDING, /**< application ready pending */
PNIO_SUBSTATE_RESERVED_2, /**< reserved */
PNIO_SUBSTATE_RESERVED_3, /**< reserved */
PNIO_SUBSTATE_SUBSTITUTE_SUBMODULE, /**< substitute, the wrong submodule can fulfill
requirements */
PNIO_SUBSTATE_UNUSED_SUBMODULE, /**< submodule not expected by controller */

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 123/323
PNIO_SUBSTATE_CORRECT_SUBMODULE = 0xFFFF, /**< correct submodule was plugged by
application*/
} PNIO_SUBSTATE_E;

typedef __HIL_PACKED_PRE struct PNS_IF_CHECK_IND_IND_DATA_Ttag

{
uint32_t hDeviceHandle;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulModuleId;
uint16_t usModuleState;
uint32_t ulSubmodId;
uint16_t usSubmodState;
uint16_t usExpInDataLen;
uint16_t usExpOutDataLen;
} __HIL_PACKED_POST PNS_IF_CHECK_IND_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_CHECK_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_CHECK_IND_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_CHECK_IND_T;
Definitions used for the field usModuleState for indication:

Definition / (Value) Description

PNIO_MODSTATE_NO_MODULE No module plugged into the slot specified.
(0x0)
PNIO_MODSTATE_WRONG_MODULE A wrong module is plugged into the specified slot.
(0x1)
PNIO_MODSTATE_PROPER_MODULE A proper (the correct) module is plugged into the specified slot but is
(0x2) already used by another IO-Controller and is therefore not
accessible.
PNIO_MODSTATE_UNUSED_MODULE A module is plugged into the specified slot but is not requested/used
(0x4) by the IO-Controller.
Table 60: Values of usModuleState in check indication

Definitions used for the field usSubmodState field for indication:

Definition / (Value) Description

PNIO_SUBSTATE_NO_SUBMODULE No submodule plugged into the slot/subslot specified.
(0x0)
PNIO_SUBSTATE_WRONG_SUBMODULE A wrong submodule is plugged into the specified slot/subslot.
(0x1)
PNIO_SUBSTATE_PROPER_SUBMODULE A proper (the correct) submodule is plugged into the specified
(0x2) slot/subslot but is already used by another IO-Controller. It cannot be
used now.
PNIO_SUBSTATE_APPL_READY_PENDING The correct submodule is plugged into the specified slot/subslot but it
(0x4) is not ready for data exchange yet.
PNIO_SUBSTATE_UNUSED_SUBMODULE A submodule is plugged into the specified slot/subslot but it is not
(0x8) requested/used by the IO-Controller.
Table 61: Values of usSubmodState in check indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.3.2 Check Response

With this response packet, the application influences the ModuleDiffBlock, which the IO-Device
stack sends to IO-Controller.
Possible values for the fields usModuleState and usSubmodState are defined below the
packet description in additional tables.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 28 Packet data length in bytes
ulState uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1F17 PNS_IF_CHECK_RES
Data
hDeviceHandle uint32_t The device handle
ulApi uint32_t The API of the wrong submodule.
ulSlot uint32_t The slot of the wrong submodule.
ulSubslot uint32_t The subslot of the wrong submodule.
ulModuleId uint32_t The ModuleID the IO-Controller expected
usModuleState uint16_t See below The ModuleState (see Table 63 on page 125).
ulSubmodId uint32_t The SubmoduleID the IO-Controller expected.
usSubmodState uint16_t See below The SubmoduleState (see Table 64 on page 125). Only the value
PNIO_SUBSTATE_SUBSTITUTE_MODULE is honored by the
stack. Any other value will lead to default behavior.
Table 62: PNS_IF_CHECK_RSP_T - Check Response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_CHECK_IND_RSP_DATA_Ttag
{
uint32_t hDeviceHandle;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulModuleId;
uint16_t usModuleState;
uint32_t ulSubmodId;
uint16_t usSubmodState;
} __HIL_PACKED_POST PNS_IF_CHECK_IND_RSP_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_CHECK_RSP_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_CHECK_IND_RSP_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_CHECK_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Definitions to use for the field usModuleState field in response:

Definition / (Value) Description
PNIO_MODSTATE_NO_MODULE No module plugged into the slot specified.
(0x0)
PNIO_MODSTATE_WRONG_MODULE A wrong module is plugged into the specified slot.
(0x1)
PNIO_MODSTATE_PROPER_MODULE A proper (the correct) module is already plugged into the specified
(0x2) slot and therefore no configuration adaptation happens.
PNIO_MODSTATE_SUBSTITUTE_MODULE A substitute module is plugged into the specified slot. Substitute
(0x3) modules can offer the same functionality as the originally requested
module.
PNIO_MODSTATE_UNUSED_MODULE A module is plugged into the specified slot but is not requested/used
(0x4) by the IO-Controller.
PNIO_MODSTATE_CORRECT_MODULE A correct module is plugged into the specified slot on adaptation of
(0xffff) the module configuration by application.
Table 63: Values of usModuleState in response packet

Definitions to use for the field usSubmodState field in response:

Definition / (Value) Description
PNIO_SUBSTATE_NO_SUBMODULE No submodule plugged into the slot/subslot specified.
(0x0)
PNIO_SUBSTATE_WRONG_SUBMODULE A wrong submodule is plugged into the specified slot/subslot.
(0x1)
PNIO_SUBSTATE_PROPER_SUBMODULE A proper (the correct) submodule is plugged into the specified
(0x2) slot/subslot and therefore no configuration adaptation happens.
PNIO_SUBSTATE_SUBSTITUTE_SUBMODULE A substitute submodule is plugged into the specified slot/subslot.
(0x7) Substitute submodules can offer the same functionality as the
originally requested submodule.
PNIO_SUBSTATE_UNUSED_SUBMODULE A submodule is plugged into the specified slot/subslot but it is not
(0x8) requested/used by the IO-Controller.
PNIO_MODSTATE_CORRECT_SUBMODULE A correct submodule is plugged into the specified slot/subslot on
(0xFFFF) adaptation of the submodule configuration by application.
Table 64: Values of usSubmodState in response packet

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.4 Connect Request Done service

The stack sends the Connect Request Done indication to the application to indicate that no more
Check Indications will be sent from the stack to the application.

6.2.4.1 Connect Request Done indication

This packet indicates that the Connect Request from the IO-Controller was parsed by stack. The
stack is waiting for the corresponding application generated response. Without this response the
Connect Response on the network is not generated.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1FD4 PNS_IF_CONNECT_REQ_DONE_IND
Data
hDeviceHandle uint32_t The device handle
Table 65: PNS_IF_CONNECTREQ_DONE_IND_T - Connect Request Done indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_CONNECTREQ_DONE_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.4.2 Connect Request Done response

The application has to return this packet after receiving a Connect Request Done indication. The
device handle has to match that of the indication.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1FD5 PNS_IF_CONNECT_REQ_DONE_RES
Data
hDeviceHandle uint32_t The device handle
Table 66: PNS_IF_CONNECTREQ_DONE_RSP_T - Connect Request Done response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_CONNECTREQ_DONE_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.5 Parameter End service

As soon as the IO-Controller has finished parameterizing the IO-Device, it sends the Parameter
End command. The stack indicates this to the application.
1. According to the PROFINET specification, with reception of this indication the application
should first check the parameters against each other. Here, the application must quickly
decide whether applying the parameters will last more than 300 seconds.
2. If for any reason the application requires additional time to get ready, the application shall set
fSendApplicationReady to false and respond to the indication immediately.
3. Next the application should generate the Parameter End response. Finally, the application
shall start configuring its submodules with the parameters from the write indications having
been received. If no write indication was received, nothing has to be done.
4. If the application is ready for cyclic process data exchange and it did not request additional
time, answer with fSendApplicationReady set to true in order to indicate this to the
stack.
If the application requested additional time within step 2:
When later on the application gets ready, it has to use the Application Ready service (page 131) to
indicate this to the stack.

Note: Before the stack will signal Application Ready to the IO-Controller, the application must
provide valid I/O data to the stack. Therefore the application is required to write the I/O
data after returning the Parameter End response with fSendApplicationReady set
to true.

Note: For this service, a timeout is implemented in the stack. If the application does not
answer within the timeout the stack will automatically generate a negative response the
IO-Controller.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.5.1 Parameter End indication

This packet indicates the reception of Parameter End from IO-Controller.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes
ulCmd uint32_t 0x1F0E PNS_IF_PARAM_END_IND
Data
hDeviceHandle uint32_t The device handle
ulApi uint32_t The API of the module whose parameterization is finished.
Only valid if usSubslot != 0.
usSlot uint16_t The slot of the module whose parameterization is finished.
Only valid if usSubslot != 0.
usSubslot uint16_t 0 Parameterization is finished for either
all submodules being part of the connection currently established
(indicated via PNS_IF_AR_CHECK_IND before)
or
all submodules being part of a previous Parameter Begin Indication
(in case of SystemRedundancy).
!= 0 Parameterization is finished for the module specified by ulApi,
usSlot and usSubslot.
Table 67: PNS_IF_PARAM_END_IND_T - Parameter End indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_END_IND_DATA_Ttag
{
uint32_t hDeviceHandle;
uint32_t ulApi; /* valid only if usSlot != 0 */
uint16_t usSlot; /* valid only if usSubslot != 0 */
uint16_t usSubslot; /* 0: for all (sub)modules, != 0: for this specific submodule */
} __HIL_PACKED_POST PNS_IF_PARAM_END_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_END_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PARAM_END_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PARAM_END_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.5.2 Parameter End response

This packet has to be returned to the stack. Depending on fSendApplicationReady the stack
will automatically send the command Application Ready to the IO-Controller.

Note: It is not allowed to send Application ready on the network until the IOPS and IOCS of
all submodules are set to good or a diagnosis has been added for bad submodules.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 8 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F0F PNS_IF_PARAM_END_RES
Data
hDeviceHandle uint32_t Handle to the IO-Device.
fSendApplicationReady uint32_t FALSE (0) The stack shall not automatically send ApplicationReady.
This will be initiated by Application using the Service
described in section Application Ready service (page 131).
TRUE The stack shall automatically send ApplicationReady.
Table 68: PNS_IF_PARAM_END_RSP_T - Parameter End response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_END_RSP_DATA_Ttag
{
uint32_t hDeviceHandle;
uint32_t fSendApplicationReady; /* set to TRUE to send ApplReady automatically */
} __HIL_PACKED_POST PNS_IF_PARAM_END_RSP_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_END_RSP_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PARAM_END_RSP_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PARAM_END_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.6 Application Ready service

With this service, the application shall indicate to the stack, that it is ready for process data
exchange and that the stack shall signal Application Ready to the IO-Controller. This is only
necessary, if the application returned the Parameter End Response with
fSendApplicationReady set to false.

Note: If the application does not signal Application Ready to the Stack/ Controller at all, cyclic
process data cannot be exchanged. Therefore, the Application is required to indicate
Application Ready at some time point (Many Controllers abort the Application Relation
if ApplicationReady is not signaled within a timeout).

Note: If the Application handles the Provider-State on itself, it is important to set up the
Provider States before sending Application Ready. The IO-Controller will evaluate the
Provider States on Application Ready and will ignore all Submodules with Bad Provider
State for Cyclic Process Data Exchange

Note: As Application Ready also signals valid process data to the IO-Controller, the stack is
required to update its internal buffer at least once from the DPM Output Area / Provider
Image. Therefore the Application shall either use xChannelIOWrite (DPM) or the
UpdateProviderData callback function (Linkable Object) to allow the Stack to do so.
Even if the Device has no Input data this shall be done. Calling xChannelIOWrite may
be called with data length zero (Just to toggle the handshake flags). It may happen that
xChannelIOWrite reports an error (COM-Flag not set) which can be ignored.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.6.1 Application Ready request

This request packet has to be sent by application to the stack if Application Ready shall be sent to
the PROFINET IO-Controller.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1F10 PNS_IF_SET_APPL_READY_REQ
Data
hDeviceHandle uint32_t 0 Set this variable to 0.
Table 69: PNS_IF_APPL_READY_REQ_T - Application Ready request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_APPL_READY_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.6.2 Application Ready confirmation

The stack will respond with this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F11 PNS_IF_SET_APPL_READY_CNF
Data
hDeviceHandle uint32_t 0 The device handle.
Table 70: PNS_IF_APPL_READY_CNF_T - Application Ready confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_APPL_READY_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.7 AR InData service

With this service, the stack indicates to the application that the first cyclic frame from the IO-
Controller was received after ApplicationReady was sent by the IO-Device stack.

6.2.7.1 AR InData indication

This packet indicates the receipt of the first cyclic frame to the application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1F28 PNS_IF_AR_INDATA_IND
Data
hDeviceHandle uint32_t The device handle
Table 71: PNS_IF_AR_IN_DATA_IND_T - AR InData indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_AR_IN_DATA_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.7.2 AR InData response

The application has to return this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1F29 PNS_IF_AR_INDATA_RES
Data
hDeviceHandle uint32_t The device handle
Table 72: PNS_IF_AR_IN_DATA_RSP_T - AR InData response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_AR_IN_DATA_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.2.8 Store Remanent Data service

This section is relevant only, if the application is responsible to store remanent data. For a
description of the remanent data handling, see section Remanent data handling (page 60).

For PNSV4:
The stack indicates the presence of remanent data to the application (ulCmd is 0x1FEA). The
application is responsible for storing this data into a permanent storage. After the next power cycle,
the application has to restore all remanent data using the Load Remanent Data service (page 101).

For PNSV5:
A stack component indicates (HIL_STORE_REMAMENT_DATA_IND = 0x2F8E) the presence of
remanent data to the application. The application is responsible for storing this data into a
permanent storage. After the next power cycle, the application has to restore all remanent data
using the Set Remanent Data service (HIL_SET_REMAMENT_DATA_REQ). For a description of this
packet, see reference [8] (on page 13).

For PNSV4 and PNSV5:

This service is tightly coupled with the following services:
1. RPC Parameter End Service, see Parameter End service (page 128).
2. DCP Set Station Name, see Save Station Name service (page 151).
3. DCP Set IP Address, see Save IP Address service (page 153).
4. DCP Reset to Factory, see Reset Factory Settings service (page 157).
The application always must respond. Otherwise, these services will not work correctly.

6.2.8.1 Store Remanent Data indication

This description is relevant for PNSV4 only.
Using this packet the stack indicates the presence of remanent data to the user application.
The packet itself is only defined to contain 1 byte. The correct amount of data is given by the stack
in the packet header’s field ulLen. The application should be able to handle up to 8192 Byte of
remanent data.
In case, large amounts of data are transferred, this data will be divided to multiple response
packets, which have to be evaluated one by another. The handling of packet fragmentation is
described in section “General packet fragmentation” in reference [7].
If the application receives this indication, it has to compare old and new data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 1+n Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1FEA PNS_IF_STORE_REMANENT_DATA_IND
Data
abData[1] uint8_t[] The remanent data to be stored by application. Only the first byte is
shown in the packet definition. The application has to store the
amount of bytes reported by this packet header’s field ulLen
Table 73: PNS_IF_STORE_REMANENT_DATA_IND_T - Store Remanent Data indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 137/323
Packet structure reference
typedef __HIL_PACKED_PRE struct
PNS_IF_STORE_REMANENT_DATA_IND_DATA_Ttag
{
/** this is only the first byte, many others may follow */
uint8_t abData[1];
} __HIL_PACKED_POST PNS_IF_STORE_REMANENT_DATA_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_STORE_REMANENT_DATA_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_STORE_REMANENT_DATA_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_STORE_REMANENT_DATA_IND_T;

6.2.8.2 Store Remanent Data response

This description is relevant for PNSV4 only.
The application has to return this packet on reception of the
PNS_IF_STORE_REMANENT_DATA_IND_T indication.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1FEB PNS_IF_STORE_REMANENT_DATA_RES
Table 74: PNS_IF_STORE_REMANENT_DATA_RES_T - Store Remanent Data response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_STORE_REMANENT_DATA_RES_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3 Acyclic Events indicated by the Stack

This section describes the acyclic events/services that the stack indicates to the application.
Depending on the service (indication packet), the application may have to perform an action and
always has to return a response packet.
Services like APDU Status Changed or Alarm Indication will only appear while cyclic data
exchange is active. Services like Link Status Changed, Error Indication and Start/Stop LED
Blinking are independent of the state of cyclic data exchange.

Note: If the netX COM LEDs are present, these are managed by the protocol stack and this
service is informative in this case. In all other cases the implementation is mandatory
and relevant for certification.

6.3.1 Service overview

The following table lists all packets of acyclic events indicated by the stack.
Service Command code Command code
(REQ or IND) (CNF or RES)
Read Record service (page 139) 0x1F36 0x1F37
Write Record service (page 143) 0x1F3A 0x1F3B
AR Abort Indication service (page 148) 0x1F2A 0x1F2B
Save Station Name service (page 151) 0x1F1A 0x1F1B
Save IP Address service (page 153) 0x1FB8 0x1FB9
Start LED Blinking service (page 155) 0x1F1E 0x1F1F
Stop LED Blinking service (page 156) 0x1F20 0x1F21
Reset Factory Settings service (page 157) 0x1F18 0x1F19
APDU Status Changed service (page 161) 0x1F2E 0x1F2F
Alarm Indication service (page 163) 0x1F30 0x1F31
Error Indication service (page 166) 0x1FDC 0x1FDD
Read I&M service (page 167) 0x1F32 0x1F33
Write I&M service (page 173) 0x1F34 0x1F35
Get Asset service (page 176) 0x1F3E 0x1F3F
Parameterization Speedup Support service (page 183) 0x1FF8 0x1FF9
Event Indication service (page 185) 0x1FFE 0x1FFF
ARset Status service (page 187) 0x1F12 0x1F13
Parameter Begin service (page 189) 0x1F3C 0x1F3D
Dynamic Reconfiguration service (page 193) 0x1F1C 0x1F1D
Table 75: Service overview of acyclic events indicated by the PROFINET IO Device stack

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.2 Read Record service

With the Read Record service, the stack indicates the reception of a Read Record request from the
IO-Controller. The stack provides all parameters to the application, which are necessary to answer
the request such as slot, subslot and index. The application has to return the Read Record
response packet to the stack so that the stack can send the Read response to the PROFINET IO-
Controller.

Note: For this service, the stack uses a timeout. If the application does not answer within the
timeout period, the stack automatically generates a negative response the IO-
Controller.

Note: The LFW target by default supports up to 4 KB of response data payload for read
records. For this, the data must be transferred using packet fragmentation. This also
requires an entry within the tag list.

Due to the limited mailbox size of the Dual-Port Memory, the application has to use fragmentation.
For PNSV4: The handling of packet fragmentation is described in section “General packet
fragmentation” in reference [7]. For PNSV5: The handling of packet fragmentation is described in
section “Communication channel packet fragmentation” in reference [8] and [9].

6.3.2.1 Read Record indication

This packet indicates the reception of a Read Record request by the stack to the application.

Packet Description

Variable Type Value / Range Description

ulLen uint32_t 32 Packet data length in bytes
ulCmd uint32_t 0x1F36 PNS_IF_READ_RECORD_IND
Data
hRecordHandle uint32_t A stack internal identifier, which belongs to this indication.
hDeviceHandle uint32_t The device handle.
ulSequenceNum uint32_t The sequence number used by IO-Controller for this Read Record
Request.
ulApi uint32_t The API the IO-Controller wants to read.
ulSlot uint32_t The slot the IO-Controller wants to read.
ulSubslot uint32_t The subslot the IO-Controller wants to read.
ulIndex uint32_t The index the IO-Controller wants to read.
ulLenToRead uint32_t 1..n The number of bytes the IO-Controller requested. If the stack is
accessed using DPM, n may be up to 1024 Bytes. If the Protocol
Stacks AP Queue is directly programmed, n may be up to 32768.
Table 76: PNS_IF_READ_RECORD_IND_T - Read Record indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 140/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_READ_RECORD_IND_DATA_Ttag
{
uint32_t hRecordHandle;
uint32_t hDeviceHandle;
uint32_t ulSequenceNum;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulIndex;
uint32_t ulLenToRead;
} __HIL_PACKED_POST PNS_IF_READ_RECORD_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_READ_RECORD_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_READ_RECORD_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_READ_RECORD_IND_T;

6.3.2.2 Read Record response

The application has to send this packet as response to a Read Record indication.
The application will not receive any feedback whether the response has reached the IO-Controller
or not. However, if the Read Record response packet received by the stack contains wrong values,
the stack will indicate this to the IO-Controller using a User Error indication.

Note: The data provided by device to the PROFINET network via the read record response
(abRecordData[]) are delivered in big-endian representation. Big-endian means,
that the highest value byte is stored first, i.e. at the lowest memory address (Motorola
format).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 40 + n Packet data length in bytes. n is the value of ulReadLen.
ulCmd uint32_t 0x1F37 PNS_IF_READ_RECORD_RES
Data
hRecordHandle uint32_t A stack internal identifier which belongs to this indication.
hDeviceHandle uint32_t The device handle
ulSequenceNum uint32_t The sequence number passed in the indication.
ulApi uint32_t The API the IO-Controller wants to read.
ulSlot uint32_t The slot the IO-Controller wants to read.
ulSubslot uint32_t The subslot the IO-Controller wants to read.
ulIndex uint32_t The index the IO-Controller wants to read.
ulReadLen uint32_t 0..n The record data length read. N shall be smaller or equal than
value of indication’s ulLenToRead field.
ulPnio uint32_t PROFINET error code, consists of ErrorCode, ErrorDecode,
ErrorCode1 and ErrorCode2. See section “PROFINET Status
Code”.
usAddValue1 uint16_t Additional Value 1.
Value has to be 0 if ulPnio is 0.
In case of error, ulPnio is not 0, this value can be used to report
customer-specific error information.
usAddValue2 uint16_t Additional Value 2.
Value has to be 0 if ulPnio is 0.
In case of error, ulPnio is not 0, this value can be used to report
customer-specific error information.
abRecordData[] uint8_t[] Read record data. The array must not be larger than the value
in indication’s ulLenToRead field.
Table 77: PNS_IF_READ_RECORD_RSP_T - Read Record response

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 142/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_READ_RECORD_RSP_DATA_Ttag
{
uint32_t hRecordHandle;
uint32_t hDeviceHandle;
uint32_t ulSequenceNum;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulIndex;
uint32_t ulReadLen;
/* Profinet error code, consists of ErrCode, ErrDecode, ErrCode1 and ErrCode2 */
uint32_t ulPnio;
uint16_t usAddValue1;
uint16_t usAddValue2;
uint8_t abRecordData[]; /* ATTENTION: in case of LOM the length of abRecordData may be
up to PNS_IF_MAX_RECORD_DATA_LEN bytes (BUT never more than ulLenToRead)*/
} __HIL_PACKED_POST PNS_IF_READ_RECORD_RSP_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_READ_RECORD_RSP_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_READ_RECORD_RSP_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_READ_RECORD_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.3 Write Record service

With the Write Record service, the stack indicates the reception of a Write Record request from the
IO-Controller. The stack provides the application with all parameters contained in the request (such
as slot, subslot, index and the data. It has to handle the data (e.g. send it to configure modules). It
has to return the Write Record response packet to the stack so that the stack can answer the
request from the IO-Controller.
If the application receives the Write Record during connection establishment, the application
should wait for reception of the Parameter End indication instead of trying to configure the
submodule instantly.

Note: The LFW target supports by default up 4 KB of indication data payload for write
records. For this, the data must be transferred using the fragmentation transfer. The
application might pre-calculate the size of the unfragmented packet using the data field
ulLentoWrite which is transferred in the first fragment. This also requires an entry
within the tag list.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.3.1 Write Record indication

Using this packet, the stack indicates the reception of a Write Request to the application. It
contains the data sent by the IO-Controller.

Note: The data received from the PROFINET network via the write record indication
(abRecordData[]) are delivered in big-endian representation. Big-endian means,
that the highest value byte is stored first, i.e. at the lowest memory address (Motorola
format).

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 32 +n Packet data length in bytes. n is the value of ulLenToWrite.
ulCmd uint32_t 0x1F3A PNS_IF_WRITE_RECORD_IND
Data
hRecordHandle uint32_t A stack internal identifier, which belongs to this indication.
hDeviceHandle uint32_t The device handle
ulSequenceNum uint32_t The sequence number used by IO-Controller for this Write Record
Request.
ulApi uint32_t The API the IO-Controller wants to write to.
ulSlot uint32_t The slot the IO-Controller wants to write to.
ulSubslot uint32_t The subslot the IO-Controller wants to write to.
ulIndex uint32_t The index the IO-Controller wants to write to.
ulLenToWrite uint32_t 1..n The length of write record data. If the stack is accessed using
DPM, n may be up to 1024 Bytes.
If the protocol stack’s AP Queue is programmed directly, n may be
up to 32768.
abRecordData[] uint8_t[] The write record data. The actual length of the array depends on
ulLenToWrite field.
Table 78: PNS_IF_WRITE_RECORD_IND_T - Write Record indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 145/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_RECORD_IND_DATA_Ttag
{
/** Stack internal identifier. Do not evaluate */
uint32_t hRecordHandle;
/** The requests associated device handle */
uint32_t hDeviceHandle;
/** The requests sequence number used by the IO controller */
uint32_t ulSequenceNum;
/** The api the record shall be written to */
uint32_t ulApi;
/** The slot the record shall be written to */
uint32_t ulSlot;
/** The subslot the record shall be written to */
uint32_t ulSubslot;
/** The index the record shall be written to */
uint32_t ulIndex;
/** The length of the record data */
uint32_t ulLenToWrite;
/** The records data */
uint8_t abRecordData[]; /* ATTENTION: in case of LOM the length of abRecordData may be
up to PNS_IF_MAX_RECORD_DATA_LEN bytes */
} __HIL_PACKED_POST PNS_IF_WRITE_RECORD_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_RECORD_IND_Ttag

{
/** Packet header */
HIL_PACKET_HEADER_T tHead;
/** Packet data */
PNS_IF_WRITE_RECORD_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_WRITE_RECORD_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.3.2 Write Record response

In order to respond to a Write Record indication, the application has to send this packet to the
stack.
The application will not receive any feedback whether the response has reached the IO-Controller
or not. However, if the Write Record response packet received by the stack contains wrong values,
the stack will indicate this to the IO-Controller using a User Error indication.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 40 Packet data length in bytes
ulSta uint32_t
ulCmd uint32_t 0x1F3B PNS_IF_WRITE_RECORD_RES
Data
hRecordHandle uint32_t A stack internal identifier which belongs to this indication.
hDeviceHandle uint32_t The device handle
ulSequenceNum uint32_t The sequence number passed in the indication.
ulApi uint32_t The API the IO-Controller wants to write to.
ulSlot uint32_t The slot the IO-Controller wants to write to.
ulSubslot uint32_t The subslot the IO-Controller wants to write to.
ulIndex uint32_t The index the IO-Controller wants to write to.
ulWriteLen uint32_t The record data length written.
ulPnio uint32_t PROFINET error code, consists of ErrCode, ErrDecode, ErrCode1
and ErrCode2. See section “PROFINET Status Code”.
usAddValue1 uint16_t 0 Additional Value 1.
Value has to be 0 if ulPnio is 0.
In case of error, ulPnio is not 0, this value can be used to report
customer-specific error information.
usAddValue2 uint16_t 0 Additional Value 2.
Value has to be 0 if ulPnio is 0.
In case of error, ulPnio is not 0, this value can be used to report
customer-specific error information.
Table 79: PNS_IF_WRITE_RECORD_RSP_T - Write Record response

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 147/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_RECORD_RSP_DATA_Ttag
{
/** Stack internal identifier. Use value from indication. */
uint32_t hRecordHandle;
/** The requests associated device handle. Use value from indication. */
uint32_t hDeviceHandle;
/** The requests sequence number used by the IO controller. Use value from indication.
*/
uint32_t ulSequenceNum;
/** The api the record shall be written to. Use value from indication. */
uint32_t ulApi;
/** The slot the record shall be written to. Use value from indication. */
uint32_t ulSlot;
/** The subslot the record shall be written to. Use value from indication. */
uint32_t ulSubslot;
/** The index the record shall be written to. Use value from indication. */
uint32_t ulIndex;
/** The length of the written record data. Use value from indication. */
uint32_t ulWriteLen;
/** The profinet status code. This is the status of the write.
*
* Use the following values:
* - PNIO_S_OK: The write was successfull
* - PNIO_E_IOD_WRITE_ACCESS_INVALIDINDEX: The addressed submodule does not support
this index
*/
uint32_t ulPnio;
/** Additional value for write response */
uint16_t usAddValue1;
/** Additional value for write response */
uint16_t usAddValue2;
} __HIL_PACKED_POST PNS_IF_WRITE_RECORD_RSP_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_RECORD_RSP_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_WRITE_RECORD_RSP_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_WRITE_RECORD_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.4 AR Abort Indication service

With this service, the stack informs the application that a formerly established connection to the
PROFINET IO-Controller no longer exists. Possible reasons are:
 The stack did not receive cyclic frames from IO-Controller
 The IO-Controller closed the connection (RPC Release, RPC Abort, abort alarm)
 The application disallowed communication (Set Bus state OFF)
 The application reconfigured the stack using Channel Init or Configuration Reload

Important: An application should NOT use the receipt of this indication as cause to trigger actions
like „Channel int“, „Pull (sub)module“ or „System reset“. Otherwise certification oft he
device will not be possible.

Note: The application must send a response.

Note: If an AR disconnects it is required to invalidate (set to zero) or apply substitute values

to the consumer process data in most cases. In order to do so, the stack needs write
access to the consumer process data image. Therefore, if the application does not
update the consumer data periodically or does not use the event service, it is required,
that the application allows the stack to update the consumer process data image by
updating from the consumer process data image.

Note: If bit “Generate Check Indications for unused modules” (D13) in ulSystemFlags of Set
Configuration service (page 69) is set and the Shared Device function is used then the
stack sends Check Indications after an AR Abort Indication.

Note: The stack sends an Event Indication with

PNS_IF_IO_EVENT_CONSUMER_UPDATE_REQUIRED = 0x00000002 to the
application after an AR Abort Indication. The application must read the input data once
when receiving this Event Indication.

Note: Typically, the IO data is already marked as invalid (set to 0 if IOxS is not used) by
protocol stack.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.4.1 AR Abort Indication

With this packet, the stack informs the application that the established connection no longer exists.
This is informative for the application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 8 Packet data length in bytes
ulCmd uint32_t 0x1F2A PNS_IF_AR_ABORT_IND
Data
hDeviceHandle uint32_t The device handle.
ulPnio uint32_t PROFINET error code, consists of ErrCode, ErrDecode, ErrCode1
and ErrCode2. See section PROFINET status codes on page 294.
Table 80: PNS_IF_AR_ABORT_IND_IND_T - AR Abort Indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_AR_ABORT_IND_IND_DATA_Ttag
{
uint32_t hDeviceHandle;
/* Profinet error code, consists of ErrCode, ErrDecode, ErrCode1 and ErrCode2 */
uint32_t ulPnio;
} __HIL_PACKED_POST PNS_IF_AR_ABORT_IND_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_AR_ABORT_IND_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_AR_ABORT_IND_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_AR_ABORT_IND_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.4.2 AR Abort Indication response

The application has to return this packet to the stack.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1F2B PNS_IF_AR_ABORT_RES
Data
hDeviceHandle uint32_t The device handle.
Table 81: PNS_IF_AR_ABORT_IND_RSP_T - AR Abort Indication response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_AR_ABORT_IND_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.5 Save Station Name service

With this service, the stack indicates the reception of a DCP Set NameOfStation request to the
application. The stack automatically sets the new NameOfStation.
If the application configured the stack using packets, the application must be able to store the
station name into non-volatile memory. On power-up, the application has to restore the station
name using the Set Configuration Request packet.
The following figure explains the correct application behavior:

Figure 39: Save Station Name: Application state diagram

Note: The application can configure the stack to save the NameOfStation on its own. See bit
D17 in System flags V3. If the application does not use this elegant solution to deal
with the NameOfStation, the following applies:

If the flag bRemanent is not set, the application must delete the permanently stored
Station Name and use an empty Station Name after the next power-up cycle.

Note: The DCP Set Station Name response is sent to the network after the application
responds to the Save Station Name service. The protocol stack will automatically
generate a positive response to the network in case the application does not answer to
the service in time. However, it is required that the application responds to the
indication.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 243 Packet data length in bytes
ulCmd uint32_t 0x1F1A PNS_IF_SAVE_STATION_NAME_IND
Data
usNameLen uint16_t 0..240 Length of the new NameOfStation.
bRemanent uint8_t 0 Do not save the new NameOfStation remanent.
1 Save the NameOfStation remanent.
abNameOfStation[240] uint8_t[] The new NameOfStation as ASCII byte-array.
For the station name, only use lower case characters.
Table 82: PNS_IF_SAVE_STATION_NAME_IND_T - Save Station Name indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_SAVE_STATION_NAME_IND_DATA_Ttag
{
uint16_t usNameLen;
uint8_t bRemanent;
uint8_t abNameOfStation[PNS_IF_MAX_NAME_OF_STATION];
} __HIL_PACKED_POST PNS_IF_SAVE_STATION_NAME_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SAVE_STATION_NAME_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_SAVE_STATION_NAME_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SAVE_STATION_NAME_IND_T;

6.3.5.2 Save Station Name response

The application acknowledges the indication with this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The application has to return SUCCESS_HIL_OK.
ulCmd uint32_t 0x1F1B PNS_IF_SAVE_STATION_NAME_RES
Table 83: PNS_IF_SAVE_STATION_NAME_RSP_T - Save Station Name response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_SAVE_STATION_NAME_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.6 Save IP Address service

With this service, the stack indicates to the application that a DCP Set IP request has been
received. The stack automatically sets the new IP address and informs the application.
If the application configured the stack using packets, the application must be able to store the IP
address parameters into non-volatile memory. On power up, the application has to restore the IP
address parameters using the Set Configuration Request packet.
The following figure explains the correct application behavior.

Figure 40: Save IP Address: Application state diagram

Note: The application can configure the stack to save the IP parameters by itself,
see bit D17 in System flags V3.If the application does not use this elegant solution to
deal with the NameOfStation, the following applies:

If the flag bRemanent is not set the application shall set the permanently stored IP
parameters to 0.0.0.0 and use IP 0.0.0.0 after the next power-up cycle.

Note: The DCP Set IP Address response is sent to the network after the application responds
to the Save IP Address Service. The protocol stack will automatically generate a
positive response to the network in case the application does not answer to the service
in time. However, it is required that the application responds to the indication.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.6.1 Save IP Address indication

This packet indicates the reception of a DCP Set IP request by the stack.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 13 Packet data length in bytes
ulCmd uint32_t 0x1FB8 PNS_IF_SAVE_IP_ADDR_IND
Data
ulIpAddr uint32_t The new IP address.
ulNetMask uint32_t The new network mask.
ulGateway uint32_t The new gateway address.
bRemanent uint8_t 0 Do not save the new IP parameters remanent.
1 Save the IP parameters remanent.
Table 84: PNS_IF_SAVE_IP_ADDR_IND_T - Save IP Address indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_SAVE_IP_ADDR_IND_DATA_Ttag
{
uint32_t ulIpAddr;
uint32_t ulNetMask;
uint32_t ulGateway;
uint8_t bRemanent;
} __HIL_PACKED_POST PNS_IF_SAVE_IP_ADDR_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SAVE_IP_ADDR_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_SAVE_IP_ADDR_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SAVE_IP_ADDR_IND_T;

6.3.6.2 Save IP Address response

The application has to return this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The application has to return SUCCESS_HIL_OK.
ulCmd uint32_t 0x1FB9 PNS_IF_SAVE_IP_ADDR_RSP
Table 85: PNS_IF_SAVE_IP_ADDR_RSP_T - Save IP Address response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_SAVE_IP_ADDR_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.7 Start LED Blinking service

The stack informs the application about the reception of a DCP Set Signal request with this
service. The application should start blinking with an appropriate LED immediately using the
specified frequency.

6.3.7.1 Start LED Blinking indication

With this indication packet the stack informs the application about the reception of a DCP SET
Signal request.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1F1E PNS_IF_START_LED_BLINKING_IND
Data
ulFrequency uint32_t 1 Blinking frequency of the LED (1 Hz).
Table 86: PNS_IF_START_LED_BLINKING_IND_T - Start LED Blinking indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_START_LED_BLINKING_IND_DATA_Ttag
{
uint32_t ulFrequency;
} __HIL_PACKED_POST PNS_IF_START_LED_BLINKING_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_START_LED_BLINKING_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_START_LED_BLINKING_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_START_LED_BLINKING_IND_T;

6.3.7.2 Start LED Blinking response

The application has to return this response packet. If blinking with the LED cannot be
accomplished, the packet must contain a negative status.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The application has to return SUCCESS_HIL_OK.
ulCmd uint32_t 0x1F1F PNS_IF_START_LED_BLINKING_RES
Table 87: PNS_IF_START_LED_BLINKING_RSP_T - Start LED Blinking response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_START_LED_BLINKING_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Note: If the stack is used as LOM and is configured to use LEDs and if a valid Blinking LED-
Name (see section Start LED Blinking service on page 155) is given the stack will
automatically blink with the LED and this indication is only informative.

6.3.8.1 Stop LED Blinking indication

The indication packet is sent from the stack to inform the application to stop blinking with the LED.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulCmd uint32_t 0x1F20 PNS_IF_STOP_LED_BLINKING_IND
Table 88: PNS_IF_STOP_LED_BLINKING_IND_T - Stop LED Blinking indication

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_STOP_LED_BLINKING_IND_T;

6.3.8.2 Stop LED Blinking response

The application shall return this response packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The application has to return SUCCESS_HIL_OK.
ulCmd uint32_t 0x1F21 PNS_IF_STOP_LED_BLINKING_RES
Table 89: PNS_IF_STOP_LED_BLINKING_RSP_T - Stop LED Blinking response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_STOP_LED_BLINKING_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.9 Reset Factory Settings service

The stack indicates to the application, that a “Reset to Factory Settings” request has been received
via DCP. If the application has configured the stack using packets, the application must now reset
some values within the non-volatile memory. On power-up, the reset values must be restored by
means of a Set Configuration request packet.
The PROFINET specification defines different types of “Reset to Factory”. Each type defines which
data the application shall reset. The following figure explains correct application behavior.
As default, the application has to use the following reset values:
Anyway, the host is responsible to process the application parameters.

Note: PROFINET specifies that the reception of a Reset to factory settings Request shall
automatically stop any running cyclic communication. The stack does this automatically
and indicates this to the application by the Abort Indication service.

Note: If the stack is configured using a SYCON.net database, then the stack will
automatically change the IP parameters and NameOfStation stored in the database to
the default values.

Note: If the stack is configured using the Set Configuration service the internally stored
parameters will also be changed by the stack in the way that e.g. after a ChannelInit
the default values will be used.

Note: The DCP Set Reset Factory response is sent to the network after the application
responds to the Reset Factory Settings Service. The protocol stack will automatically
generate a positive response to the network in case the application does not answer to
the service in time. However, it is required that the application responds to the
indication.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.9.1 Reset Factory Settings indication

The indication packet sent by the stack.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 2 Packet data length in bytes
ulCmd uint32_t 0x1F18 PNS_IF_RESET_FACTORY_SETTINGS_IND
Data
usResetCode uint16_t The reset code, see the table.
Table 90: PNS_IF_RESET_FACTORY_SETTINGS_IND_T - Reset Factory Settings indication

Packet structure reference

typedef __HIL_PACKED_PRE struct
{
/** This field has the same coding as the DCP BlockQualifier with option ControlOption
and suboption SuboptionResetToFactory.*/
uint16_t usResetCode;
} __HIL_PACKED_POST PNS_IF_RESET_FACTORY_SETTINGS_IND_DATA_T;

typedef __HIL_PACKED_PRE struct

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_RESET_FACTORY_SETTINGS_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_RESET_FACTORY_SETTINGS_IND_T;
The requested type of reset is indicated to the application in parameter usResetCode (it has the
same coding as the DCP BlockQualifier with option ControlOption and suboption
SuboptionResetToFactory). Parameter usResetCode defines which data the application
shall reset:

Name Value Description

PNS_IF_RESET_FACTORY_SETTI 2 Reset application data in interface
NGS_IF_APPLICATION Reset data, which have been stored permanently in submodules and
modules to factory values.
- Manufacturer specific record data shall be set to factory values.
- All I&M data shall be set also to factory values.
The stack does not support this sub-option. Reserved for future
implementation.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Name Value Description

PNS_IF_RESET_FACTORY_SETTI 4 Reset communication parameter in interface
NGS_IF_COMMUNICATION All parameters active for the interface or the ports and the ARs shall be
set to the default value and reset if permanently stored. This mode is
intended to set the addressed communication interface of a device into
a state, which is almost similar to the “out of the box” state.
In particular these are:
- NameOfStation shall be set to “” (empty string)
- IP suite parameter shall be set to 0.0.0.0
- DHCP parameters (if available) shall be reset
- All PDev parameters shall be set to factory values (The stack resets
these values internally)
- Parameters adjusted by SNMP, like sysContact, sysName, and
sysLocation from MIB-II (The stack resets these values internally)
Observe that all I&M data are not set to factory values!
In case, the application takes care of the remanent data (i.e. uses the
Load Remanent Data service and Store Remanent Data service (page
136) but I&M requests are handled internally by the stack (which means
that flag PNS_IF_SYSTEM_STACK_HANDLE_I_M_ENABLED is set
by the Set Configuration service (page 69), the application should not
remove the remanent data, because the stack preserves I&M data
inside of the remanent data. Else the application should reset
(remove) remanent data.
PNS_IF_RESET_FACTORY_SETTI 6 Reset engineering parameter in interface
NGS_IF_ENGEINEERING Reset engineering parameters, which have been stored permanently in
the IOC or IOD to factory values.
- If a node is able to switch its functionality from IOC to IOD and vice
versa via engineering system, the factory functionality must be
activated.
- An application program loaded by an engineering system shall be
reset (or removed).
- A configuration loaded by an engineering system must be reset (or
removed).
The stack does not support this sub-option, reserved for future
implementation.
PNS_IF_RESET_FACTORY_SETTI 8 Reset all stored data in interface
NGS_IF_ALL Reset all stored data in the IOD or IOC to its factory default values.
This covers all data related to application data (2), communication (4)
and engineering parameters (6).
The stack does not support this sub-option on the network but
uses this code to indicate old DCP-reset service
(SuboptionFactoryReset) to the application.
PNS_IF_RESET_FACTORY_SETTI 16 Reset all stored data in device
NGS_DEVICE_ALL Reset all data stored in the IOD or IOC to its factory values. This
service shall reset the communication parameters of all interfaces of the
device and should reset all parameters of the device.
This mode is intended to set the device into a state, which is similar to
the “out of the box” state.
It includes parameters adjusted by SNMP.
The stack does not support this sub-option, because it supports
only one interface.
PNS_IF_RESET_FACTORY_SETTI 18 Reset and restore data in device
NGS_DEVICE_RESTORE Reset installed software revisions to factory values.
The stack does not support this sub-option.
Table 91: Possible values of the reset code

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Note: GSDML attribute ResetToFactoryModes has following relation to the reset code:

ResetToFactoryModes = usResetCode / 2

For example: usResetCode = 4, then

ResetToFactoryModes = 2.

6.3.9.2 Reset Factory Settings response

The application must return this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t 0 The application has to return SUCCESS_HIL_OK.
ulCmd uint32_t 0x1F19 PNS_IF_RESET_FACTORY_SETTINGS_RES
Table 92: PNS_IF_RESET_FACTORY_SETTINGS_RSP_T - Reset Factory Settings response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_RESET_FACTORY_SETTINGS_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.10 APDU Status Changed service

With this service, the stack indicates to the application that the status field of the cyclic frames
received by the stack and sent by the PROFINET IO-Controller has changed. The new Status is
indicated.

6.3.10.1 APDU Status Changed indication

This packet indicates the APDU status Change to application.
The packet is only indicated if the following conditions are met:
 Data is valid - DataValid flag is set to 1
 AR in state Primary - State flag is set to 1 (Regardless of type of the established AR)
 At least one of the relevant flags “Provider State” or “Station Problem Indicator” is changed
(in comparison to last valid APDU status)

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 8 Packet data length in bytes
ulCmd uint32_t 0x1F2E PNS_IF_APDU_STATUS_IND
Data
hDeviceHandle uint32_t The device handle
ulStatus uint32_t See the table below. A change of the Primary/Backup is not indicated to
the application
Table 93: PNS_IF_APDU_STATUS_CHANGED_IND_T - APDU Status Changed indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_APDU_STATUS_CHANGED_IND_DATA_Ttag
{
uint32_t hDeviceHandle;
uint32_t ulStatus;
} __HIL_PACKED_POST PNS_IF_APDU_STATUS_CHANGED_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_APDU_STATUS_CHANGED_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_APDU_STATUS_CHANGED_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_APDU_STATUS_CHANGED_IND_T;

Bit mask Description

0x01 Bit is cleared: IOCR is in state Backup
Bit is set: IOCR is in state Primary
0x02 Reserved bit 1
0x04 Bit is cleared: Data are invalid
Bit is set: Data are valid
0x08 Reserved bit 2
0x10 Bit is cleared: The provider station is in stop state
Bit is set: The provider station is in run state

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Bit mask Description

0x20 Bit is cleared: The provider station has a problem
Bit is set: The Provider station is fully operational
0x40 Reserved bit 3
0x80 Reserved bit 4
Table 94: APDU status field bits

6.3.10.2 APDU Status Changed response

The application shall return this packet.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t 0 The status has to be okay for this service.
ulCmd uint32_t 0x1F2F PNS_IF_APDU_STATUS_RES
Data
hDeviceHandle uint32_t Handle to the IO-Device.
Table 95: PNS_IF_APDU_STATUS_CHANGED_RSP_T - APDU Status Changed response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_APDU_STATUS_CHANGED_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.11 Alarm Indication service

With this service, the stack indicates the reception of an Alarm PDU from the IO-Controller to the
application.
The application needs to respond to this indication. A positive response will answer the alarm on
the network positively. A negative application response will answer the response on the network
negatively.

6.3.11.1 Alarm Indication

This packet informs the application about the reception of an Alarm PDU from the IO-Controller.
The packet contains all information sent by the IO-Controller.

Important: The data received from the PROFINET network via the alarm indication
(abAlarmData[1024]) are delivered in big-endian representation. Big-endian
means, that the highest value byte is stored first, i.e. at the lowest memory address
(Motorola format).

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 54 + n Packet data length in bytes. n is the value of usLenAlarmData.
ulCmd uint32_t 0x1F30 PNS_IF_ALARM_IND
Data
hDeviceHandle uint32_t The device handle
ulApi uint32_t The API the alarm belongs to.
ulSlot uint32_t The slot the alarm belongs to.
ulSubslot uint32_t The subslot the alarm belongs to.
ulModuleId uint32_t The ModuleID the alarm belongs to.
ulSubmodId uint32_t The SubmoduleID the alarm belongs to.
usAlarmPriority uint16_t The Alarm priority.
usAlarmType uint16_t The alarm type.
usAlarmSequence uint16_t The alarm sequence number.
fDiagChannelAvailable uint32_t
fDiagGenericAvailable uint32_t
fDiagSubmodAvailable uint32_t
fReserved uint32_t 0 Reserved, will be set to zero.
fArDiagnosisState uint32_t
usUserStructId uint16_t The User Structure Identifier.
usAlarmDataLen uint16_t The length of alarm data.
abAlarmData[1024] uint8_t[] Alarm data.
Table 96: PNS_IF_ALARM_IND_T - Alarm Indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 164/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_ALARM_IND_DATA_Ttag
{
uint32_t hDeviceHandle;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulModuleId;
uint32_t ulSubmodId;
uint16_t usAlarmPriority;
uint16_t usAlarmType;
uint16_t usAlarmSequence;
uint32_t fDiagChannelAvailable;
uint32_t fDiagGenericAvailable;
uint32_t fDiagSubmodAvailable;
uint32_t fReserved;
uint32_t fArDiagnosisState;
uint16_t usUserStructId;
uint16_t usAlarmDataLen;
uint8_t abAlarmData[PNS_IF_MAX_ALARM_DATA_LEN];
} __HIL_PACKED_POST PNS_IF_ALARM_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_ALARM_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_ALARM_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_ALARM_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.11.2 Alarm Indication response

The application has to return this packet on reception of the alarm indication
PNS_IF_ALARM_IND_T.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes
ulSta uint32_t In case application sends a positive response (SUCCESS_HIL_OK),
the alarm is positively acknowledged on the network.
In case application sends a negative response
(ERR_HIL_UNKNOWN_COMMAND or
ERR_HIL_NO_APPLICATION_REGISTERED), the alarm is
negatively acknowledged on the network.
ulCmd uint32_t 0x1F31 PNS_IF_ALARM_RES
Data
hDeviceHandle uint32_t The device handle
Table 97: PNS_IF_ALARM_RSP_T - Alarm Indication response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;
typedef PNS_IF_HANDLE_PACKET_T PNS_IF_ALARM_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.12 Error Indication service

With this service, the stack informs the user application about an error having occurred. Two
different situations are possible. Either the application returned an erroneous packet to the stack
(e.g. Read Record Response with to small packet) or a (fatal) error has been detected inside the
stack.

6.3.12.1 Error Indication

Using this packet the stack informs the application about an error.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 8 Packet data length in bytes
ulCmd uint32_t 0x1FDC PNS_IF_USER_ERROR_IND
Data
ulErrorCode uint32_t The error code.
ulCommand uint32_t 0 This is an error indication for internal problems inside the stack.
1 … 232 -1 The command the application made the error.
Table 98: PNS_IF_USER_ERROR_IND_T - Error Indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_USER_ERROR_IND_DATA_Ttag
{
uint32_t ulErrorCode;
uint32_t ulCommand;
} __HIL_PACKED_POST PNS_IF_USER_ERROR_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_USER_ERROR_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_USER_ERROR_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_USER_ERROR_IND_T;

6.3.12.2 Error Indication response

The application shall return the indication packet as Error Indication Response packet back to the
stack.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulCmd uint32_t 0x1FDD PNS_IF_USER_ERROR_RSP
Table 99: PNS_IF_USER_ERROR_RSP_T - Error Indication response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_USER_ERROR_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.13 Read I&M service

If needed, the stack uses this service to obtain I&M information from the user application. I&M0-5
Information records are always stored into the physical (sub)module. For instance, in case of a
modular I/O system, removing a (sub) module from one modular I/O block and plugging it into
another one will result in the same I&M0-5 data when reading the I&M0-5 data from the new
location.

Note: In order to fulfill PROFINET conformance needs, the user has to implement at least
handling of I&M0, I&M1, I&M2, I&M3 and I&M0 Filter data.

In addition, I&M0 shall be readable on every submodule. If I&M1-5 are supported, they
shall be readable on every submodule, even if they are only writable on a specific
device-representing submodule.

Note: In order to fulfill PROFINET conformance needs, the user has to set the flag
PNS_IF_IM0_FILTER_DATA_DEVICE_REF for one submodule when handling the
type PNS_IF_IM_TYPE_IM0FILTER.

6.3.13.1 Read I&M indication

This indication packet is sent by the stack whenever a controller or a supervisor reads out I&M
information in order to obtain the requested I&M data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes. n depends on the parameter type
contained in the packet.
ulCmd uint32_t 0x1F32 PNS_IF_READ_IM_IND
Data
ulApi uint32_t 0-0xFFFFFFFF The API of the (sub) module to read the I&M data for. Ignore on I&M0
Filter data read.
usSlot uint16_t 0-0xFFFF The Slot of the (sub)module to read the I&M data for. Ignore on I&M0
Filter data read.
usSubslot uint16_t 0-0xFFFF The Subslot of the (sub)module to read the I&M data for. Ignore on
I&M0 Filter data read.
bIMType uint8_t 0-5, 255 The I&M record to read. (0-5: I&M0-5, 255: I&M0 Filter Data)
abReserved[3] uint8_t Reserved / padding
Table 100: PNS_IF_READ_IM_IND_T – Read I&M Indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 168/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_READ_IM_IND_DATA_Ttag
{
/** api of the submodule the i&m data shall be read from */
uint32_t ulApi;
/** slot of the submodule the i&m data shall be read from */
uint16_t usSlot;
/** subslot of the submodule the i&m data shall be read from */
uint16_t usSubslot;
/** type of i&m to read */
uint8_t bIMType;
/** unused */
uint8_t abReserved[3];
} __HIL_PACKED_POST PNS_IF_READ_IM_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_READ_IM_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_READ_IM_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_READ_IM_IND_T;

6.3.13.2 Read I&M response

The application must respond to each Read I&M indication using the Read I&M response. The
response must contain the requested I&M data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 + n Packet data length in bytes. n depends on the returned data
ulSta uint32_t Error code. Either SUCCESS_HIL_OK or ERR_HIL_FAIL
ulCmd uint32_t 0x1F33 PNS_IF_READ_IM_RES
Data
ulApi uint32_t 0-0xFFFFFFFF Use value from indication
usSlot uint16_t 0-0xFFFF Use value from indication
usSubslot uint16_t 0-0xFFFF Use value from indication
bIMType uint8_t 0-5, 255 Use value from indication
abReserved[3] uint8_t Reserved
tData union union of different structures. To be filled with the requested I&M
information according bIMType and the related information structure
(See below).
Table 101: PNS_IF_READ_IM_RES_T – Read I&M response

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 169/323
Packet structure reference
typedef union
{
/** Array of submodules describing I&M state of submodules
* ( grow Array as required)*/
PNS_IF_IM0_FILTER_DATA_T atIM0FilterData[1];
/** I&M0 Data */
PNS_IF_IM0_DATA_T tIM0;
/** I&M1 Data */
PNS_IF_IM1_DATA_T tIM1;
/** I&M2 Data */
PNS_IF_IM2_DATA_T tIM2;
/** I&M3 Data */
PNS_IF_IM3_DATA_T tIM3;
/** I&M4 Data */
PNS_IF_IM4_DATA_T tIM4;
/** I&M5 Data */
PNS_IF_IM5_DATA_T tIM5;
} PNS_IF_READ_IM_RES_DATA_ITEMS_T;

typedef __HIL_PACKED_PRE struct PNS_IF_READ_IM_RES_DATA_Ttag

{
/** api of the submodule the i&m data shall be read from */
uint32_t ulApi;
/** slot of the submodule the i&m data shall be read from */
uint16_t usSlot;
/** subslot of the submodule the i&m data shall be read from */
uint16_t usSubslot;
/** type of i&m read */
uint8_t bIMType;
/* unused, set to zero */
uint8_t abReserved[3];
/** union of I&M Data */
PNS_IF_READ_IM_RES_DATA_ITEMS_T tData;
} __HIL_PACKED_POST PNS_IF_READ_IM_RES_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_READ_IM_RES_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_READ_IM_RES_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_READ_IM_RES_T;
Depending on the value of the field tData.bIMType, the correct substructure of the union has to
be filled by the user application. In case of I&M 0-5 the substructures tIM0-tIM5 have to be used,
in case of I&M0 Filter Data the array atIM0FilterData has to be filled with all (sub)modules
which have discrete I&M data (max 128).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
abManufacturerSpecific uint8_t 0 Not evaluated on PROFINET. (For compatibility with PROFIBUS)
[10]
usManufacturerId uint16_t The Vendor ID of the device. Usually similar to the specified in
Set Configuration Request
abOrderId uint8_t[20] The Order ID of the (sub) module. (padded with spaces (0x20))
abSerialNumber uint8_t[16] The Serial number of the (sub) module. (padded with spaces)
usHardwareRevision uint16_t Hardware revision of the (sub) module
tSoftwareRevision.bPrefix uint8_t Character describing the software of the (sub) module. Allowed
values: ‘V’, ‘R’, ‘P’, ‘U’ and ‘T’
tSoftwareRevision.bX uint8_t Function enhancement. (Major version number) of the (sub)
module.
tSoftwareRevision.bY uint8_t Bug fix (Minor version number) of the (sub)module
tSoftwareRevision.bZ uint8_t Internal Change (Build version number) of the (sub)module
usRevisionCounter uint16_t Starting from 0, shall increment on each parameter change.
usProfileId uint16_t The profile of the (sub) module.
usProfileSpecificType uint16_t Additional value depending on profile of the (sub)module
usIMVersion uint16_t The I&M version. (Default value 0x0101)
usIMSupported uint16_t Bit list describing the I&M variants supported by the (sub)module:
0x02 -> I&M1 Supported
0x04 -> I&M2 Supported
0x08 -> I&M3 Supported
0x10 -> I&M4 Supported
0x20 -> I&M5 Supported
Table 102: PNS_IF_IM0_DATA_T – Structure of I&M0 Information

Variable Type Value / Description

Range
abManufacturerSpecific[10] uint8_t 0 Not evaluated on PROFINET. (For compatibility with
PROFIBUS)
abTagFunction[32] uint8_t Function tag of the (sub) module. (padded with spaces)
abTagLocation[22] uint8_t Location tag of the (sub) module. (padded with spaces)
Table 103: PNS_IF_IM1_DATA_T – Structure of I&M1 Information

Variable Type Value / Description

Range
abManufacturerSpecific[10] uint8_t 0 Not evaluated on PROFINET. (For compatibility with
PROFIBUS)
abInstallationDate[16] uint8_t Installation date of the (sub) module. (padded with spaces)
abReserved[38] uint8_t Reserved. Set to zero. Not evaluated by stack.
Table 104: PNS_IF_IM2_DATA_T – Structure of I&M2 Information

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
abManufacturerSpecific[10] uint8_t 0 Not evaluated on PROFINET. (For compatibility with
PROFIBUS)
abDescriptor[54] uint8_t Description text of the (sub) module. (padded with spaces)
Table 105: PNS_IF_IM3_DATA_T – Structure of I&M3 Information

Variable Type Value / Description

Range
abManufacturerSpecific[10] uint8_t 0 Not evaluated on PROFINET (for compatibility with PROFIBUS)
abSignature[54] uint8_t Signature generated by engineering system. (padded with
spaces, default value: ZERO)
Table 106: PNS_IF_IM4_DATA_T – Structure of I&M4 Information

Variable Type Value / Description

Range
abAnnotation uint8_t[64] 0 Manufacturer specific annotation string describing the OEM
part. Padded with spaces (0x20) to 64 byte length.
abOrderId uint8_t[64] Order Id of OEM Part, padded with spaces (0x20) to 64 byte
length.
usVendorId uint16_t PNO VendorId of OEM Part.
abSerialNumber uint8_t[16] Serial number of OEM Part. Padded with spaces (0x20) to 16
byte length.
usHardwareRevision uint16_t Hardware revision of the OEM part.
tSoftwareRevision.bPrefix uint8_t Character describing the software of the OEM part. Allowed
values: ‘V’, ‘R’, ‘P’, ‘U’ and ‘T’
tSoftwareRevision.bX uint8_t Function enhancement. (Major version number) of the OEM
part.
tSoftwareRevision.bY uint8_t Bug fix (Minor version number) of the OEM part.
tSoftwareRevision.bZ uint8_t Internal Change (Build version number) of the OEM part.
Table 107: PNS_IF_IM5_DATA_T – Structure of I&M5 Information

I&M0FilterData is a special record identifying which submodules of an IO-Device carry distinct I&M
data. I&M0FilterData shall also deliver one submodule acting as device representative which
means that this submodule’s I&M data is valid for the whole IO-Device.
The I&M0FilterData response of application may contain one or more submodules in
PNS_IF_READ_IM_RES_DATA_T element atIM0FilterData. The confirmation packet lengths need
to be set according to the amount of submodules contained in the packet.
The application has to order the submodules in the sequence “API, Slot and Subslot”. In case the
application does not use this order sequence, an invalid response coding may be seen on the
network.
I&M0FilterData supports a maximum of 128 submodules.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Range Description

ulApi uint32_t The API of the submodule.
usSlot uint16_t The slot of the submodule
usSubslot uint16_t The subslot of the submodule
ulFlags uint32_t The properties of the submodule. If the submodule has I&M data, the
flag PNS_IF_IM0_FILTER_DATA_HAS_IM_DATA shall be set.
Otherwise, the submodule will be ignored. (=The entry can be
omitted from the PNS_IF_READ_IM_RES_T) The Flag
PNS_IF_IM0_FILTER_DATA_MODULE_REF shall be set if the
submodule I&M data represents the module I&M data. (Hint: Use this
for physical modules with virtual submodules)
PNS_IF_IM0_FILTER_DATA_DEVICE_REF shall be set if the
submodule I&M data represents the device I&M data. (Hint: Use this
for devices which have no pluggable modules)
Table 108: PNS_IF_IM0_FILTER_DATA_T – Structure of I&M0 Filter Information

Note: By default read of I&M4 or I&M5 are not forwarded to application but rejected by
protocol stack with error code “invalid index”. If the application requires to support
I&M4/I&M5, the application has to enable the support using the Set OEM Parameters
service (page 82).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.14 Write I&M service

The stack uses this service to force the user application to write the given I&M information into the
corresponding (sub)module. The I&M information should be stored into the physical (sub)module.

Note: Writing of I&M is only defined for I&M1-4 records.

Writing of I&M1, I&M2 and I&M3 records shall be supported at least for one submodule
by each PROFINET IO Device.

Handling the I&M4 record is optional.

Writing I&M5 is never allowed, but the protocol stack needs to know the proper error
code (Access denied or invalid index). Therefore, in case of write for I&M5 the
indication is generated without write data by the protocol stack. The application has
always to respond using the appropriate error code.

Choosing the proper error code is required to pass certification tests:

If the I&M record object is written for a submodule which implements no own I&M dataset: Either
ERR_PNS_IF_APPL_IM_INVALID_INDEX or ERR_PNS_IF_APPL_IM_ACCESS_DENIED shall be
used. This depends on if the representative I&M submodule implements that record object or not.
If the I&M record object is written for a submodule which implements an own I&M dataset but not
the requested record object, the error code ERR_PNS_IF_APPL_IM_INVALID_INDEX must be
used.

6.3.14.1 Write I&M indication

This indication is sent by the stack whenever a controller or a supervisor writes I&M information in
order to store the given I&M data into the (sub)module.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12, 76 Packet data length in bytes.
ulCmd uint32_t 0x1F34 PNS_IF_WRITE_IM_IND
Data
ulApi uint32_t 0-0xFFFFFFFF The API of the submodule to write the I&M data.
usSlot uint16_t 0-0xFFFF The slot to write the I&M data.
usSubslot uint16_t 1-0xFFFF The subslot to write the I&M data.
bIMType uint8_t 1-5 The I&M record to be written.
abReserved[3] uint8_t 0 Reserved / padding
tData union Union of different structures. It contains the I&M data to be written.
Select the substructure according to the bIMType field. For a
description of the substructures, see section Get Asset response on
page 179.
Table 109: PNS_IF_WRITE_IM_IND_T – Write I&M indication

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 174/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_IM_IND_DATA_Ttag
{
/** api of the submodule the i&m data shall be read from */
uint32_t ulApi;
/** slot of the submodule the i&m data shall be read from */
uint16_t usSlot;
/** subslot of the submodule the i&m data shall be read from */
uint16_t usSubslot;
/** type of i&m to write */
uint8_t bIMType;
/* unused, set to zero */
uint8_t abReserved[3];
/** union of I&M Data */
union {
/** I&M1 Data */
PNS_IF_IM1_DATA_T tIM1;
/** I&M2 Data */
PNS_IF_IM2_DATA_T tIM2;
/** I&M3 Data */
PNS_IF_IM3_DATA_T tIM3;
/** I&M4 Data */
PNS_IF_IM4_DATA_T tIM4;
} tData;
} __HIL_PACKED_POST PNS_IF_WRITE_IM_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_IM_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_WRITE_IM_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_WRITE_IM_IND_T;
Depending on the value of the field tData.bIMType the correct substructure of the union has to
be taken for evaluation at the user application. The I&M data shall be stored in non-volatile
memory of the (sub)module.

Note: When receiving the PNS_IF_RESET_FACTORY_SETTINGS_IND packet with a reset

mode indicating that I&M Data shall be reset, the I&M1-4 data shall be set to default
values. Except for I&M4 signature the default value is a string filled with space
characters (0x20). The default signature is a string filled with zero characters (0x00).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.14.2 Write I&M response

The application has to respond to each Write I&M Indication using the Write I&M Response. Set
the ulSta field of the response header according to success or failure of the write.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes.
ulSta uint32_t Error code.
Either SUCCESS_HIL_OK or if the I&M record object is written for a
submodule which implements no own I&M dataset: Either
use ERR_PNS_IF_APPL_IM_ACCESS_DENIED if the submodule
has its own I&M data and I&M5 is written
use ERR_PNS_IF_APPL_IM_INVALID_INDEX if the submodule has
no own I&M data
use ERR_PNS_IF_APPL_IM_INVALID_INDEX if the submodule has
own I&M data but the object written is not supported by this
submodule
ulCmd uint32_t 0x1F35 PNS_IF_WRITE_IM_RES
Data
ulApi uint32_t 0-0xFFFFFFFF The application has to use the same value as in the indication.
usSlot uint16_t 0-0xFFFF The application has to use the same value as in the indication.
usSubslot uint16_t 1-0xFFFF The application has to use the same value as in the indication.
bIMType uint8_t 1-5 The application has to use the same value as in the indication.
abReserved[3] uint8_t Set to zero
Table 110: PNS_IF_WRITE_IM_RES_T – Write I&M response

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_IM_RES_DATA_Ttag
{
/** api of the submodule the i&m data shall be read from */
uint32_t ulApi;
/** slot of the submodule the i&m data shall be read from */
uint16_t usSlot;
/** subslot of the submodule the i&m data shall be read from */
uint16_t usSubslot;
/** type of i&m written */
uint8_t bIMType;
/* unused, set to zero */
uint8_t abReserved[3];
} __HIL_PACKED_POST PNS_IF_WRITE_IM_RES_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_WRITE_IM_RES_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_WRITE_IM_RES_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_WRITE_IM_RES_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.15 Get Asset service

The stack uses this service to request asset information from the application. This asset
information is used to process a PROFINET read record service for asset record object. As this
record can become very large, the stack will use this service multiple times in order to request all
required information from the application.

Note: See chapter Technical data for limitations.

The following figure shows the stack will use multiple Get Asset indications to retrieve the
information from the application. As soon as no further asset management data is available, the
application has to return the Get Asset response without asset management data content. This will
indicate to the stack that all asset management data has been delivered and the read response
can be generated.

Figure 41: Get Asset service

The following table shows the correlation between the “PROFINET record index” and the first
associated EntryNumber used from the protocol stack in the Get Asset indication.
Record index First EntryNumber requested
(as soon as record index is read)
0xF880 0
0xF881 200
0xF882 400
0xF883 600
0xF884 800
0xF885 1000
0xF886 1200
0xF887 1400
0xF888 1600
0xF889 1800
Table 111: PROFINET record index and first associated EntryNumber

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 177/323
The protocol stack has implemented a fixed mapping so that each PROFINET record index can
deliver up to 200 assets. Even if the application uses assets with a small memory footprint only
(e.g. SoftwareInformationOnly), the protocol stack does not support more than 200 assets per
index.
If the IO-Controller reads record index 0xF881, the application will receive a Get Asset indication
with parameter usEntryNumber set to 200. In case the application does not have so many assets,
the application simply has to answer with packet status “OK” and the packet length set to 0. This
will result in a positive answer on the network indicating that the IO-Device supports this number of
assets in principal but not enough assets are available right now. To generate a negative answer
(index not supported) on the network, the application has to set the packet status to
ERR_HIL_NO_APPLICATION_REGISTERED in the Get Asset response.
Asset information can be read using different access ways, e.g. IO Controller AR, DeviceAccess
AR or ReadImplicit. In rare cases, whereby the protocol stack receives a request to read Asset
information while the protocol stack already handles already another read request for Asset
information in parallel, the protocol stack will react as follows:
 The running request will be finished. Therefore, the protocol stack fetches all assets
belonging to the requested index from the application and prepares the response to the
network.
 All other requests will be queued internally and handled after the running request has been
finished.
 As soon as the running request has been finished, the protocol stack handles the next
request, which leads to a new Get Asset indication to the application.
This implementation makes handling easier for the protocol stack and the application, compared to
an implementation handling multiple requests at the same time.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.15.1 Get Asset indication

This indication is sent by the protocol stack to request asset information from the application. The
service is used multiple times by the protocol to retrieve all information sequentially.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 2 Packet data length in bytes.
ulCmd uint32_t 0x1F3E PNS_IF_GET_ASSET_IND
Data
usEntryNumber uint32_t 0-65534 The index of the first requested asset
Table 112: PNS_IF_GET_ASSET_IND_T – Get Asset indication

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_GET_ASSET_IND_DATA_Ttag
{
/** Number of first requested asset management entry */
uint16_t usEntryNumber;
} __HIL_PACKED_POST PNS_IF_GET_ASSET_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_ASSET_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** Indication data */
PNS_IF_GET_ASSET_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_GET_ASSET_IND_T;

Parameter usEntryNumber
This parameter specifies the number of the first asset to return in the response packet. The data
model used to represent the asset information is a simple list of assets. This field specifies the
index of the first list entry the protocol stack expects in the response. The application is expecting
to deliver up to four asset entries from the asset list starting with the entry at index
usEntryNumber. The index count starts with the first corresponding EntryNumber of the queried
PROFINET record index, see Table 111 (page 176).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.15.2 Get Asset response

The application always must respond the Get Asset Indication with a Get Asset Response packet.
In case, the application has more than 4 assets available to be reported to the stack, the
application must send 4 assets in a response packet. As soon as the application has no more
assets to deliver, the length of the response packet, which is the last response packet, must be set
to zero.
Example: In case, the application has 10 assets, the application has to send 4 assets with the first
response packet, the next 4 assets with the second response packet, the next 2 (last) assets with
the third response packet. Finally, the application has to send 0 assets (ulLen = 0) with the last
(fourth) response packet which terminates the internal handling of the stack asking the application
for more assets.
In case, the stack requests asset 197 (or higher), the application has to send all remaining assets
in one response packet, which is the last response packet and terminates the internal handling of
the stack asking the application for more asset (assets higher than 196). A response packet with 0
assets (ulLen = 0) is not needed.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 0, 336, 672, Packet data length in bytes. Set according number of assets in
1008, 1344 packet.
ulSta uint32_t SUCCESS_HIL_OK for a positive response from the application.
ERR_HIL_UNKNOWN_COMMAND for a negative response from the
application.
ulCmd uint32_t 0x1F3F PNS_IF_GET_ASSET_RSP
Data
atEntries PNS_IF_AS Array of up to four assets.
SET_ENTRY
_T[4]
Table 113: PNS_IF_GET_ASSET_RSP_T – Get Asset response

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 180/323
Structure PNS_IF_ASSET_ENTRY_T
Variable Type Value / Description
Range
usEntryNumber uint16_t 0-65534 Index of this asset.
The value must start with usEntryNumber from the indication
and then increases per entry. The stack uses this value for
internal synchronization.
bEntryType uint8_t 1, Asset contains full information
2, Asset contains only firmware information
3 Asset contains only hardware information
bPadding uint8_t 0 Padding for alignment. Set to zero.
tIM_UniqueIdentifier HIL_UUID_T Unique id of this asset.
tAM_Location struct/union Location of this asset. PROFINET defines two kinds of locations:
a level-based location information and a slot/subslot-based
location.
abIM_Annotation uint8_t[64] Annotation of asset in IM encoding
abIM_OrderID uint8_t[64] IM_orderID is encoded as UTF-8, left justified, and filled up with
blanks if text is shorter than the defined string length.
abAM_HardwareRevision uint8_t[64] Hardware revision encoded as UTF-8. This field shall only set to
non-zero value if field usIM_Hardware_Revision cannot be used.
This field is not used for firmware only information assets.
abIM_Serial_Number uint8_t[16] Serial number associated with asset using I&M encoding rules.
abIM_Software_Revision uint8_t[4] Software revision associated with asset using I&M encoding
rules. (Revision Prefix, Major, Minor, Bugfix) This is the preferred
encoding. This field is not used for hardware only information
assets.
tAM_DeviceIdentification struct Device identification associated with asset
usAM_TypeIdentification uint16_t
usIM_Hardware_Revision uint16_t Hardware revision associated with asset using I&M encoding
rules. This is the preferred encoding. Set to nonzero value if field
abAM_HardwareRevision is not used. This field is not used for
firmware only information assets.
Table 114: PNS_IF_ASSET_ENTRY_T

Note: The detailed description of the coding of all data elements (Table 114) with the initial
combination of the letters "xxAM_" and "xxIM_" lists the PROFINET specification
IEC 61158-5-10 and IEC 61158-6-10. See section “I&M services and asset
management”. The stack uses these elements for data transmission.

Variable Type Value / Description

Range
bStructureId uint8_t 1 Structure Id identifying level-based asset location
abPadding uint8_t[3] 0 Padding for alignment. Set to zero for future compatibility.
ausLevel uint16_t[12] 0 to 0x3FF Level-based asset location. The first unused level and all subsequent
levels must be set to 0x3FF.
Table 115: PNS_IF_ASSET_LOCATION_T: PNS_IF_ASSET_LOCATION_LEVEL_T

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
bStructureId uint8_t 2 Structure Id identifying slot/subslot-based asset location.
abPadding uint8_t[7] 0 Padding for alignment. Set to zero for future compatibility.
usSlotBegin uint16_t 0 to 0xFFFF First slot covered by asset.
usSubslotBegin uint16_t 0 to 0x9FFF First subslot covered by asset.
usSlotEnd uint16_t 0 to 0xFFFF Last slot covered by asset.
usSubslotEnd uint16_t 0 to 0x9FFF Last subslot covered by asset.
Table 116: PNS_IF_ASSET_LOCATION_T: PNS_IF_ASSET_LOCATION_SLOTSUBSLOT_T

Packet structure reference

enum
{
PNS_IF_ASSET_TYPE_FULLINFORMATION = (0x0001),
PNS_IF_ASSET_TYPE_FIRMWAREONLYINFORMATION = (0x0002),
PNS_IF_ASSET_TYPE_HARDWAREONLYINFORMATION = (0x0003),
};

enum
{
PNS_IF_ASSET_LOCATION_STRUCTURE_LEVEL = 0x01,
PNS_IF_ASSET_LOCATION_STRUCTURE_SLOTSUBSLOT = 0x02,
};

typedef __HIL_PACKED_PRE struct __HIL_PACKED_POST PNS_IF_ASSET_LOCATION_LEVEL_Ttag

{
uint8_t bStructureId;
uint8_t abPadding[3];
/** Set to 0x3FF for level and subsequent levels if not used*/
uint16_t ausLevel[12];
} __HIL_PACKED_POST PNS_IF_ASSET_LOCATION_LEVEL_T;

typedef __HIL_PACKED_PRE struct PNS_IF_ASSET_LOCATION_SLOTSUBSLOT_Ttag

{
uint8_t bStructureId;
uint8_t abPadding[7];
uint16_t usSlotBegin;
uint16_t usSubslotBegin;
uint16_t usSlotEnd;
uint16_t usSubslotEnd;
} __HIL_PACKED_POST PNS_IF_ASSET_LOCATION_SLOTSUBSLOT_T;

typedef union PNS_IF_ASSET_LOCATION_Ttag PNS_IF_ASSET_LOCATION_T;

union PNS_IF_ASSET_LOCATION_Ttag
{
PNS_IF_ASSET_LOCATION_LEVEL_T tLevel;
PNS_IF_ASSET_LOCATION_SLOTSUBSLOT_T tSlotSubslot;
};

typedef __HIL_PACKED_PRE struct PNS_IF_ASSET_DEVICEIDENTIFICATION_Ttag

{
/** Reserved for future usage. Set to 0x0000 */
uint16_t usDeviceSubID;
/** Device ID associated with asset */
uint16_t usDeviceID;
/** VendorID associated with asset */
uint16_t usVendorID;
/** Organization associated with asset */
uint16_t usOrganization;
} __HIL_PACKED_POST PNS_IF_ASSET_DEVICEIDENTIFICATION_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

typedef __HIL_PACKED_PRE struct PNS_IF_ASSET_ENTRY_Ttag

{
uint16_t usEntryNumber;
uint8_t bEntryType;
uint8_t bPadding;
HIL_UUID_T tIM_UniqueIdentifier;
PNS_IF_ASSET_LOCATION_T tAM_Location;
uint8_t abIM_Annotation[64];
uint8_t abIM_OrderID[64];
uint8_t abAM_SoftwareRevision[64];
uint8_t abAM_HardwareRevision[64];
uint8_t abIM_Serial_Number[16];
uint8_t abIM_Software_Revision[4];
PNS_IF_ASSET_DEVICEIDENTIFICATION_T tAM_DeviceIdentification;
uint16_t usAM_TypeIdentification;
uint16_t usIM_Hardware_Revision;
} __HIL_PACKED_POST PNS_IF_ASSET_ENTRY_T;

typedef __HIL_PACKED_PRE struct __HIL_PACKED_POST PNS_IF_GET_ASSET_RSP_DATA_Ttag

{
PNS_IF_ASSET_ENTRY_T atEntries[4];
} __HIL_PACKED_POST PNS_IF_GET_ASSET_RSP_DATA_T;

typedef __HIL_PACKED_PRE struct __HIL_PACKED_POST PNS_IF_GET_ASSET_RSP_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** Indication data */
PNS_IF_GET_ASSET_RSP_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_GET_ASSET_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.16 Parameterization Speedup Support service

The stack uses this service to indicate to the user application whether Parameterization Speedup
is enabled. This is the case if the device uses the fast startup mode (FSU). In FSU mode, the
application must store all user record data and the associated parameter UUID (this service) into
non-volatile memory. In case SharedDevice is supported by the device, the application has to store
the speed-up UUID for each submodule individualy. On the next power up, the application must
restore the user record data from the non-volatile memory into the submodules before any AR is
established. Afterwards, when the AR is being established, the application may compare the stored
parameter UUID with the parameter UUID received during last connection establishment to detect
whether an update of the parameters is required. This service allows the application that it can very
early parameterize the submodules and decreases the time until the device becomes ready for
data exchange. If the parameter UUID is zero, the FSU mode is disabled. In this case, no
parameters should be restored from non-volatile memory.
In case a connection is established for a specific submodule and FSU is not longer used for this
submodule, the stack will not indicate this to the application directly. Nevertheless, in this case, the
application has to delete the stored UUID for the submodule and has to set submodule parameters
to default. The application can detect this situation by activating Check Indication service (page
120) for all submodules and by checking the device handle. If a connection is established and the
submodule is part of the AR but the speed-up indication was not generated, then the stored UUID
has to be deleted.

Note: If the application receives a Parameterization speedup support indication containing

the NIL-UUID during connection establishment, the module has to be parameterized in
the regular way without speedup. The same applies, if the received UUID is different to
the configured one. In this case it the PLC has a different configuration.

Note: If the application does not use any user records, no special action is required on this
indication.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.16.1 Parameterization Speedup Support indication

Packet description

Variable Type Value / Range Description

ulLen uint32_t 16 Packet data length in bytes.
ulCmd uint32_t 0x1FF8 PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND
Data
tFSUuid HIL_UUID_ 0-0xFFFFFFFF The UUID send to the application.
T uint32_t ulData1
uint16_t usData2
uint16_t usData3
uint8_t abData4[8]
Table 117: PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_T – Parameterization Speedup Supported indication

Packet structure reference

typedef __HIL_PACKED_PRE struct HIL_UUID_Ttag
{
uint32_t ulData1;
uint16_t usData2;
uint16_t usData3;
uint8_t abData4[8];
} __HIL_PACKED_POST HIL_UUID_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_DATA_Ttag

{
/** received UUID send to application */
HIL_UUID_T tFSUuid;
} __HIL_PACKED_POST PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_T;

6.3.16.2 Parameterization Speedup Supported response

The application must respond.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t SUCCESS_HIL_OK for a positive response from the application.
ERR_HIL_UNKNOWN_COMMAND or
ERR_HIL_NO_APPLICATION_REGISTERED for a negative response
from the application.
ulCmd uint32_t 0x1FF9 PNS_IF_PARAMET_SPEEDUP_SUPPORTED_RSP
Table 118: PNS_IF_PARAMET_SPEEDUP_SUPPORTED_RES_T- Parameterization Speedup Supported response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_PARAMET_SPEEDUP_SUPPORTED_RES_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.17 Event Indication service

Using the Event Indication Service the stack informs the user application about IO data related
events.

6.3.17.1 Event Indication

The protocol stack sends the following indication packet.

Note: If an event indication is pending at the host application, (no event response returned to
firmware yet) new events are not reported using another event indication but counted.
These unreported events will be reported after the event response has been sent to the
firmware. This prevents flooding the host application with events.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 14 Packet data length in bytes.
ulCmd uint32_t 0x1FFE PNS_IF_EVENT_IND
Data
ausEventCnt uint16_t[7] Array of event counters. For each event the amount if occurrence is
counted since the last event indication.
Table 119: Event Indication

Packet structure reference

typedef enum PNS_IF_IO_EVENT_Etag
{
PNS_IF_IO_EVENT_RESERVED = 0x00000000,
PNS_IF_IO_EVENT_NEW_FRAME = 0x00000001,
PNS_IF_IO_EVENT_CONSUMER_UPDATE_REQUIRED = 0x00000002,
PNS_IF_IO_EVENT_PROVIDER_UPDATE_REQUIRED = 0x00000003,
PNS_IF_IO_EVENT_FRAME_SENT = 0x00000004,
PNS_IF_IO_EVENT_CONSUMER_UPDATE_DONE = 0x00000005,
PNS_IF_IO_EVENT_PROVIDER_UPDATE_DONE = 0x00000006,
PNS_IF_IO_EVENT_MAX, /**< Number of defined events **/
} PNS_IF_IO_EVENT_E;

typedef __HIL_PACKED_PRE struct

{
/** For each event the number of events occurred since the last event
* indication. */
uint16_t ausEventCnt[PNS_IF_IO_EVENT_MAX];
} __HIL_PACKED_POST PNS_IF_EVENT_IND_DATA_T;

typedef __HIL_PACKED_PRE struct

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_EVENT_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_EVENT_IND_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Event Number Description

0x00000000 Reserved for legacy implementation.
0x00000001 Reserved for legacy implementation.
0x00000002 PNS_IF_IO_EVENT_CONSUMER_UPDATE_REQUIRED: The Data
within the consumer image shall be updated because it may not be valid
any longer. This occurs for example when the connection is lost.
0x00000003 PNS_IF_IO_EVENT_PROVIDER_UPDATE_REQUIRED: The stack
needs access to the provider data. This happens for example if an
application ready has to be send and the stack needs to refresh the
cyclic data before.
0x00000004 Reserved for legacy implementation.
0x00000005 Reserved for legacy implementation.
0x00000006 Reserved for legacy implementation.
Table 120: PROFINET Device stack events

6.3.17.2 Event Indication response

The application shall return this packet as response to an Event Indication.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes.
ulCmd uint32_t 0x1FFF PNS_IF_EVENT_RSP
Table 121: Event Indication response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_EVENT_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.18 ARset Status service

6.3.18.1 ARset Status indication

This service indicates the current SR-ARset Status to the application. ARset Status indication will
be reported in the following cases:
 An SR-AR is established, released or aborted.
 Switchover is performed

Packet description

Variable Type Value / Range Description

ulLen uint32_t 14 Packet data length in bytes.
ulCmd uint32_t 0x1F12 PNS_IF_AR_SET_STATUS_IND
Data
hARsetHandle uint32_t Handle associated with the SR-ARset
bARsetStatus uint8_t 0-2 SR-ARset status
bARCount uint8_t 0-2 Amount of established SR-ARs
Table 122: ARset Status indication

Packet structure reference

/** SR AR Status used in bStatusFlags */
enum PNS_IF_AR_SET_STATUS_Etag
{
PNS_IF_AR_SET_STATUS_DISCONNECTED = 0, /* no active ar's*/
PNS_IF_AR_SET_STATUS_CONNECTED_BACKUP = 1, /* no primary AR exists */
PNS_IF_AR_SET_STATUS_CONNECTED_PRIMARY = 2, /* primary AR exists */
};

typedef __HIL_PACKED_PRE struct PNS_IF_AR_SET_STATUS_IND_DATA_Ttag

{
/** the handle associated with the SR-AR-set */
uint32_t hARsetHandle;
/* Indicate the SR-AR-set status (see above PNS_IF_AR_SET_STATUS_Etag) */
uint8_t bARsetStatus;
/** amount of active ARs in the AR-set */
uint8_t bARCount;
} __HIL_PACKED_POST PNS_IF_AR_SET_STATUS_IND_DATA_T;

bARsetStatus
This parameter represents the ARset status and can have one of the following values:
Value Description
PNS_IF_AR_SET_STATUS_DISCONNECTED No active SR-ARs
PNS_IF_AR_SET_STATUS_CONNECTED_BACKUP No primary SR-AR exists
PNS_IF_AR_SET_STATUS_CONNECTED_PRIMARY Primary SR-AR exists
Table 123: ARset Status

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.18.2 ARset Status response

The application has to respond.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes.
ulSta uint32_t
ulCmd uint32_t 0x1F3D PNS_IF_AR_SET_STATUS_RSP
Table 124: ARset Status response

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_AR_SET_STATUS_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.19 Parameter Begin service

The stack supports the Parameter Begin (PrmBegin) feature as defined by the PROFINET
specification V2.34.
The IO-Controller can use the Parameter Begin service to change submodules parameters during
operation. The stack uses this service to indicate the start of a Parameter Begin sequence. While
the Parameter Begin indication is received, the parameters of the affected submodules have to be
set to the default values. The Parameter Begin indication lists the affected submodules. During the
Parameter Begin sequence, the IO-Controller can reparameterize the corresponding submodules.
The absence of any parameters for certain submodules means that default parameters have to be
used.
To report the end of reparameterization, the IO-Controller sends a Parameter End indication. The
IO-Device finishes the sequence and sends an application ready.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Figure 42: Parameter Begin sequence

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.19.1 Parameter Begin indication

The stack indicates the start of the Parameter Begin sequence together with the list of affected
submodules.
This service may require packet fragmentation in case the IO Controller requests to change many
submodules.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 8 + (n * 8) Packet data length in bytes.
ulCmd uint32_t 0x1F3C PNS_IF_PARAM_BEGIN_IND
Data
hDeviceHandle uint32_t The handle of the AR or SR-ARset issues the Parameter Begin
service
ulSubmCnt uint32_t 0…n The amount of submodules contained in this packet (specifies how
many elements the array atSubm contains in reality)
atSubm PNS_IF_PAR List of affected submodules (structure definition, see above).
AM_BEGIN_ The packet length determines the number of entries in this list.
SUBM_ELE
M_T[1-n]
Table 125: Parameter Begin indication

Packet structure reference

typedef __HIL_PACKED_PRE struct
{
/** API of the submodule */
uint32_t ulApi;
/** slot the submodules resides */
uint16_t usSlot;
/** subslot the submodules resides */
uint16_t usSubslot;
} __HIL_PACKED_POST PNS_IF_PARAM_BEGIN_SUBMODULE_ELEM_T;

typedef __HIL_PACKED_PRE struct

{
/** the device handle of AR issued the ParamBegin-Service */
uint32_t hDeviceHandle;
/** the amount of submodules contained in atSubm */
uint32_t ulSubmCnt;
/** the submodules that are affected by this ParamBegin sequence */
PNS_IF_PARAM_BEGIN_SUBMODULE_ELEM_T atSubm[];
} __HIL_PACKED_POST PNS_IF_PARAM_BEGIN_IND_DATA_T;

typedef __HIL_PACKED_PRE struct

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PARAM_BEGIN_IND_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PARAM_BEGIN_IND_T;

Variable Type Value / Range Description

ulApi uint32_t API of the submodule
usSlot uint16_t Slot the submodules resides
usSubslot uint16_t Subslot the submodules resides
Table 126: Structure PNS_IF_PARAM_BEGIN_SUBMODULE_ELEM_T
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 192/323

6.3.19.2 Parameter Begin response

The application has to respond.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes.
ulSta uint32_t
ulCmd uint32_t 0x1F3D PNS_IF_PARAM_BEGIN_RES
Data
hDeviceHandle uint32_t Device handle
Table 127: Parameter Begin response

Packet structure reference

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_PARAM_BEGIN_RES_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.3.20 Dynamic Reconfiguration service

The Dynamic Reconfiguration feature is disabled by default. The application has to use OEM
parameter: type 16 (page 94) to enable this feature.

6.3.20.1 Dynamic Reconfiguration indication

This indication contains the same variables as the AR Check indication (page 117).

Packet description

Variable Type Value / Range Description

ulLen uint32_t Packet data length in bytes.
ulCmd uint32_t 0x1F1C PNS_IF_RECONFIG_IND
Data: For a description, see section AR Check indication (page 117).
Table 128: Dynamic Reconfiguration indication

Packet structure reference

typedef PNS_IF_AR_CHECK_IND_T PNS_IF_RECONFIG_IND_T;

6.3.20.2 Dynamic Reconfiguration response

The application has to respond.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes.
ulSta uint32_t 0 Status has to be OK for this service.
ulCmd uint32_t 0x1F1D PNS_IF_RECONFIG_RES
Data
hDeviceHandle uint32_t The device handle.
Table 129: Dynamic Reconfiguration response

Packet structure reference

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_RECONFIG_RSP_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4 Acyclic Events requested by the Application

6.4.1 Service overview

Service Command code Command code

(REQ) (CNF)
Get Diagnosis service (page 195) 0x1FB2 0x1FB3
Get XMAC (EDD) Diagnosis service (page 199) 0x1FE4 0x1FE5
AR Abort Request service (page 201) 0x1FD8 0x1FD9
Plug Module service (page 203) 0x1F04 0x1F05
Plug Submodule service (page 205) 0x1F08 0x1F09
Pull Module service (page 212) 0x1F06 0x1F07
Pull Submodule service (page 214) 0x1F0A 0x1F0B
Get Station Name service (page 217) 0x1F8E 0x1F8F
Get IP Address service (page 218) 0x1FBC 0x1FBD
Add Channel Diagnosis service (page 219) 0x1F46 0x1F47
Add Extended Channel Diagnosis service (page 221) 0x1F54 0x1F55
Add Generic Diagnosis service (page 223) 0x1F58 0x1F59
Remove Diagnosis service (page 227) 0x1FE6 0x1FE7
Set Submodule State service (page 228) 0x1F92 0x1F93
Get Parameter service (page 231) 0x1F64 0x1F65
Add PE Entity service (page 239) 0x1F94 0x1F95
Remove PE Entity service (page 241) 0x1F96 0x1F97
Update PE Entity service (page 243) 0x1F98 0x1F99
Send Alarm service (page 245) 0x1F5C 0x1F5D
Table 130: Acyclic Events requested by the Application - Overview

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.2.1 Get Diagnosis request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 0 Packet data length in bytes
ulCmd uint32_t 0x1FB2 PNS_IF_GET_DIAGNOSIS_REQ
Table 131: PNS_IF_GET_DIAGNOSIS_REQ_T - Get Diagnosis request

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_GET_DIAGNOSIS_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.2.2 Get Diagnosis confirmation

With this packet, the stack provides the collected diagnosis data to the application.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 32 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1FB3 PNS_IF_GET_DIAGNOSIS_CNF
Data
ulPnsState uint32_t Bit mask State of protocol stack. See below.
ulLastRslt uint32_t Error code Last Result
This parameter indicates the error code of the last encountered
error. For values, see section Error codes and status codes on
page 272.
ulLinkState uint32_t 0-3 Link State
See below.
ulConfigState uint32_t 0-8 Configuration State
See below.
ulCommunicationState uint32_t 0-4 Communication State
See below.
ulCommunicationError uint32_t Error code Communication Error
This parameter indicates the current error code of the
communication channel. If the cause of error is resolved, the
communication error field is set to zero again. For values, see
section Error codes and status codes on page 272.
aulLineDelay[2] uint32_t Cable delay for port 0 and port 1.
aulLineDelay[0] stores cable delay for port 0, aulLineDelay[1]
stores cable delay for port 1. The cable delay is the cable signal
propagation delay (without the port tx delay and without the port rx
delay). The unit is ns.
To calculate the cable length, multiply cable delay with the signal
speed. The signal speed depends on the used cable type (copper,
fiber optic, …).
Table 132: PNS_IF_GET_DIAGNOSIS_CNF_T - Get Diagnosis confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_STATUS_Ttag
{
uint32_t ulPnsState;
uint32_t ulLastRslt;
uint32_t ulLinkState;
uint32_t ulConfigState;
uint32_t ulCommunicationState;
uint32_t ulCommunicationError;
uint32_t aulLineDelay[2];
} __HIL_PACKED_POST PNS_IF_STATUS_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_DIAGNOSIS_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_STATUS_T tData;
} __HIL_PACKED_POST PNS_IF_GET_DIAGNOSIS_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Bit Description
D12 A PROFINET Maintenance Demanded Record exists
D11 A PROFINET Maintenance Required Record exists
D10 A PROFINET Diagnosis Record with severity fault exists
D9 Fatal Error occurred
D8 Configuration is locked
D7 Network Communication is enabled
D6 Network Communication is allowed
D5 Module 0 and Submodule 1 are plugged
D4 Module 0 is plugged
D3 At least one API is present
D2 Reserved
D1 PROFINET Stack is started
D0 Device Information is set
Table 133: Meaning of single Bits in ulPnsState

ulLinkState
This parameter denotes the link state. The following values are supported:
Value Meaning
0 No information available
1 Physical link works correctly
2 Low speed of physical link
3 No physical link present
Table 134: Values and their corresponding Meanings of ulLinkState

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Value Meaning
0 Not configured
1 Configured with DBM Files
2 Error during configuration with DBM Files
3 Configured by application
4 Configuration by application is running
5 Error during configuration by Application
6 Configured with Warmstart-Parameters
7 Configuration with Warmstart-Parameters is running
8 Error during Configuration with Warmstart-Parameters
Table 135: Values and their corresponding Meanings of ulLinkState

ulCommunicationState
This parameter denotes the communication state. It contains information regarding the current
network status of the communication channel. Depending on the implementation, all or a subset of
the definitions below is supported.

Allowed value Communication status

0x0000 UNKNOWN

0x0001 OFFLINE

0x0002 STOP

0x0003 IDLE

0x0004 OPERATE

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.3 Get XMAC (EDD) Diagnosis service

The application can request statistic information from the integrated switch.

Note: The information provided with this service is not intended to be used by the application.
This packet is intended for support purposes only, is used to help debugging Ethernet
problems, and analyzed by Hilscher.

6.4.3.1 Get XMAC (EDD) Diagnosis request

This request packet allows access to the statistical information of the switch.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 0 Packet Data Length in bytes
ulCmd uint32_t 0x1FE4 PNS_IF_GET_XMAC_DIAGNOSIS_REQ
Table 136: PNS_IF_GET_XMAC_DIAGNOSIS_REQ_T - Get XMAC (EDD) Diagnosis request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_GET_XMAC_DIAGNOSIS_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
uint8_t abReserved[sizeof(PNS_IF_GET_XMAC_DIAGNOSIS_DATA_T)];
} __HIL_PACKED_POST PNS_IF_GET_XMAC_DIAGNOSIS_REQ_T;

6.4.3.2 Get XMAC (EDD) Diagnosis confirmation

Packet description

Variable Type Value / Description

Range
ulLen uint32_t >4 Packet Data Length in bytes depending on the used
firmware version and hardware variant.
ulSta uint32_t See section Error codes and status codes on page
272.
ulCmd uint32_t 0x00001FE5 PNS_IF_GET_XMAC_DIAGNOSIS_CNF
Data
bMajor uint8_t Version of the used firmware/stack.
bMinor uint8_t
bBuild uint8_t
bRevision uint8_t
aulBuffer uint32_t[] Debug information that can only be decoded by
Hilscher.
Table 137: PNS_IF_GET_XMAC_DIAGNOSIS_CNF_T - Get XMAC (EDD) Diagnosis confirmation

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 200/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_GET_XMAC_DIAGNOSIS_DATA_Ttag
{
uint8_t bMajor;
uint8_t bMinor;
uint8_t bBuild;
uint8_t bRevision;
/* placeholder for real data */
uint32_t aulBuffer[];
} __HIL_PACKED_POST PNS_IF_GET_XMAC_DIAGNOSIS_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_XMAC_DIAGNOSIS_CNF_Ttag

{
PNS_AP_PCK_HEADER_T tHead;
PNS_IF_GET_XMAC_DIAGNOSIS_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_GET_XMAC_DIAGNOSIS_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.4 AR Abort Request service

With this service, the application requests the stack to abort an established AR.

Note: If the device handle refers to an SR-AR Set, all SR-ARs of this set are aborted.

Note: Be aware that in consequence of AR abort, a certification tool will report fails in testing.
This service is intended for usage in special situations only and should not be used in
regular environment: Use this service with care.

6.4.4.1 AR Abort Request

The application has to send this packet to force the stack to abort an established connection.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1FD8 PNS_IF_ABORT_CONNECTION_REQ
Data
hDeviceHandle uint32_t The device handle of the AR to abort.
Table 138: PNS_IF_ABORT_CONNECTION_REQ_T - AR Abort Request

Packet structure reference

typedef __HIL_PACKED_PRE struct
{
uint32_t hDeviceHandle;
/** the error status to report on bus. This field is ignored if the packet is smaller
* than 8 Bytes. Stack versions < 3.5.1.1 also ignore this field */
uint32_t ulPnio;
} __HIL_PACKED_POST PNS_IF_ABORT_CONNECTION_REQ_DATA_T;

/* Request packet */
typedef __HIL_PACKED_PRE struct
{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ABORT_CONNECTION_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_ABORT_CONNECTION_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.4.2 AR Abort Request confirmation

The stack will send this packet back to the application to confirm the abort of the AR.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1FD9 PNS_IF_ABORT_CONNECTION_CNF
Data
hDeviceHandle uint32_t The device handle
Table 139: PNS_IF_ABORT_CONNECTION_CNF_T - AR Abort Request confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_DATA_Ttag
{
/** The device handle */
uint32_t hDeviceHandle;
} __HIL_PACKED_POST PNS_IF_HANDLE_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_HANDLE_PACKET_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_HANDLE_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_HANDLE_PACKET_T;

typedef PNS_IF_HANDLE_PACKET_T PNS_IF_ABORT_CONNECTION_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.5 Plug Module service

With this service, the application can plug additional modules after the Set_Configuration Req
packet (see section Set Configuration service (page 69) has been sent. It is also possible to
(re)plug a module, which has been pulled by the application.
This service is directly confirmed, even if the corresponding action in the protocol stack (e.g.
sending an alarm to IO Controller) is not yet finished.
Plugging a module does not lead to any action visible from the outside (e.g. no alarm is generated
to an IO-Controller). Only plugging submodules is visible from the outside.

6.4.5.1 Plug Module request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 18 Packet data length in bytes
ulCmd uint32_t 0x1F04 PNS_IF_PLUG_MODULE_REQ
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the module.
ulSlot uint32_t The Slot to plug the module to.
ulModuleId uint32_t The ModuleID of the module to be plugged.
usModState uint16_t 0..1 Module state. Informative Only.
Table 140: PNS_IF_PLUG_MODULE_REQ_T - Plug Module request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_MODULE_REQ_DATA_Ttag
{
/** Obsolete field. set to zero */
uint32_t ulReserved;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulModuleId;
uint16_t usModuleState; /* module state: 0 = correct module, 1 = substitute module */
} __HIL_PACKED_POST PNS_IF_PLUG_MODULE_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_MODULE_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PLUG_MODULE_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PLUG_MODULE_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.5.2 Plug Module confirmation

The stack will return this packet to application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 18 Packet data length in bytes (0 in case of error)
ulCmd uint32_t 0x1F05 PNS_IF_PLUG_MODULE_CNF
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the module.
ulSlot uint32_t The Slot to plug the module to.
ulModuleId uint32_t The ModuleID of the module to be plugged.
usModState uint16_t 0..1 The Module state.
Table 141: PNS_IF_PLUG_MODULE_CNF_T - Plug Module confirmation

Packet structure reference

typedef PNS_IF_PLUG_MODULE_REQ_T PNS_IF_PLUG_MODULE_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.6 Plug Submodule service

With this service, the application can plug additional submodules after the stack has been
configured and/or while the device is communicating. With this service, it is also possible to
(re)plug a submodule, which has been pulled by the application.
This service is directly confirmed, even if the corresponding action in the protocol stack (e.g.
sending an alarm to IO Controller) is not yet finished.
If the plugged submodule was expected in a currently active AR, the controller will be notified
about this by means of a plug submodule alarm. The controller will now commission the
submodule by writing its parameters.

Figure 43: Plug Submodule: packet sequence

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 206/323
The stack also supports an extended plug submodule request allowing the application to plug
modules and submodules using one single request, see Extended Plug Submodule request (page
209).

6.4.6.1 Plug Submodule request

Packet description

Variable Type Value / Description

Range
ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 50 Packet data length in bytes
ulCmd uint32_t 0x1F08 PNS_IF_PLUG_SUBMODULE_REQ
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot to plug the submodule to.
ulSubslot uint32_t The Subslot to plug the submodule to.
ulSubmodId uint32_t The SubmoduleID of the submodule to be plugged.
ulProvDataLen uint32_t The provider data length, i.e. the length of the Input data of this
submodule. This length describes the data sent by IO-Device and
received by IO-Controller.
ulConsDataLen uint32_t The consumer data length, i.e. the length of the Output data of
this submodule. This length describes the data sent by IO-
Controller and received by IO-Device.
ulDPMOffsetCons uint32_t Offset in DPM to which consumer data for the submodule shall be
copied.
If the length of data in this direction is 0 or if DPM is not used this
value shall be set to 0xFFFFFFFF.
ulDPMOffsetProv uint32_t Offset in DPM from which provider data for the submodule shall
be taken.
If the length of data in this direction is 0 or if DPM is not used this
value shall be set to 0xFFFFFFFF.
usOffsetIOPSProvider uint16_t Offset of the IO provider state (provider) for this submodule. The
offset is relative to the beginning of the IOPS block in DPM output
area.
Note: If the IOPS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
usOffsetIOPSConsumer uint16_t Offset of the IO provider state (consumer) for this submodule. The
offset is relative to the beginning of the IOPS block in the DPM
input area.
Note: If the IOPS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
usOffsetIOCSProvider uint16_t Offset of the IO consumer state (provider) for this submodule. The
offset is relative to the beginning of IOCS block in DPM output
area.
Note: If the IOCS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
usOffsetIOCSConsumer uint16_t Offset of the IO consumer state (consumer) for this submodule
relative to the beginning of the IOCS block in DPM input area.
Note: If the IOCS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
ulReserved uint32_t 0 Reserved for future use. Set to zero.
usSubmodState uint16_t 0..1 The submodule state:
0 = correct module,
1 = substitute module
Table 142: PNS_IF_PLUG_SUBMODULE_REQ_T - Plug Submodule request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_SUBMODULE_REQ_DATA_Ttag
{
/** Obsolete field. set to zero */
uint32_t ulReserved1;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulSubmodId;
/* provider data is data sent by IO-Device and received by IO-Controller */
uint32_t ulProvDataLen;
/* consumer data is data sent by IO-Controller and received by IO-Device */
uint32_t ulConsDataLen;
/* offset in DPM where Output data (consumed by IO-Device from IO-Controller) is copied
to */
uint32_t ulDPMOffsetCons;
/* offset in DPM where Input data (provided by IO-Device to IO-Controller) is taken
from */
uint32_t ulDPMOffsetProv;
/* offset where to put IOPS provider state for this submodule relative to beginning of
IOPS block in dpm output area to */
uint16_t usOffsetIOPSProvider;
/* offset where to take IOPS consumer state of this submodule relative to beginning of
IOPS block in dpm input area from */
uint16_t usOffsetIOPSConsumer;
/* offset where to put IOCS provider state for this submodule relative to beginning of
IOCS block in dpm output area to */
uint16_t usOffsetIOCSProvider;
/* offset where to take IOCS consumer state of this submodule relative to beginning of
IOCS block in dpm input area from */
uint16_t usOffsetIOCSConsumer;
/* reserved for future use - maybe needed for DPM Area later */
uint32_t ulReserved2;
/* submodule state: 0 = correct submodule, 1 = substitute submodule */
uint16_t usSubmodState;
} __HIL_PACKED_POST PNS_IF_PLUG_SUBMODULE_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_SUBMODULE_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PLUG_SUBMODULE_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PLUG_SUBMODULE_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.6.2 Plug Submodule confirmation

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 50 Packet data length in bytes (0 in case of error)
ulCmd uint32_t 0x1F09 PNS_IF_PLUG_SUBMODULE_CNF
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the module.
ulSlot uint32_t The Slot to plug the submodule to.
ulSubslot uint32_t The Subslot to plug the submodule to.
ulSubmodId uint32_t The SubmoduleID of the submodule to be plugged.
ulProvDataLen uint32_t The provider data length, i.e. the length of the Input data of this
submodule. This length describes the data sent by IO-Device
and received by IO-Controller.
ulConsDataLen uint32_t The consumer data length, i.e. the length of the Output data of
this submodule. This length describes the data sent by IO-
Controller and received by IO-Device.
ulDPMOffsetCons uint32_t Offset in DPM where consumer data for the submodule shall be
copied to.
If the length of data in this direction is 0 or if DPM is not used
this value shall be set to 0xFFFFFFFF.
ulDPMOffsetProv uint32_t Offset in DPM where provider data for the submodule shall be
taken from.
If the length of data in this direction is 0 or if DPM is not used
this value shall be set to 0xFFFFFFFF.
usOffsetIOPSProvider uint16_t Offset of the IO provider state (provider) for this submodule. The
offset is relative to the beginning of the IOPS block in DPM
output area.
usOffsetIOPSConsumer uint16_t Offset of the IO provider state (consumer) for this submodule.
The offset is relative to the beginning of the IOPS block in the
DPM input area.
usOffsetIOCSProvider uint16_t Offset of the IO consumer state (provider) for this submodule.
The offset is relative to the beginning of IOCS block in DPM
output area.
usOffsetIOCSConsumer uint16_t Offset of the IO consumer state (consumer) for this submodule
relative to the beginning of the IOCS block in DPM input area.
ulDPMOffsetIocsOut uint32_t Offset in DPM where IOCS is taken from.
ulReserved uint32_t 0 Reserved for future use. Set to zero.
usSubmodState uint16_t 0..1 The submodule state.
Table 143: PNS_IF_PLUG_SUBMODULE_CNF_T - Plug Submodule confirmation

Packet structure reference

typedef PNS_IF_PLUG_SUBMODULE_REQ_T PNS_IF_PLUG_SUBMODULE_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.6.3 Extended Plug Submodule request

Receiving this packet the stack adds the described submodule and module to its internal
configuration in order to use it for data exchange. The module will be added only if necessary. If
the submodule has been requested by an IO-Controller for data exchange before, the stack will
automatically notify the controller by issuing a plug submodule alarm.

Packet description

Variable Type Value / Description

Range
ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 56 Packet data length in bytes
ulCmd uint32_t 0x1F08 PNS_IF_PLUG_SUBMODULE_REQ (It’s the same command as
standard plug submodule request)
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot to plug the submodule to.
ulSubslot uint32_t The Subslot to plug the submodule to.
ulSubmodId uint32_t The SubmoduleID of the submodule to be plugged.
ulProvDataLen uint32_t The provider data length, i.e. the length of the Input data of this
submodule. This length describes the data sent by IO-Device and
received by IO-Controller.
ulConsDataLen uint32_t The consumer data length, i.e. the length of the Output data of
this submodule. This length describes the data sent by IO-
Controller and received by IO-Device.
ulDPMOffsetCons uint32_t Offset in DPM where consumer data for the submodule shall be
copied to.
If the length of data in this direction is 0 or if DPM is not used this
value shall be set to 0xFFFFFFFF.
ulDPMOffsetProv uint32_t Offset in DPM where provider data for the submodule shall be
taken from.
If the length of data in this direction is 0 or if DPM is not used this
value shall be set to 0xFFFFFFFF.
usOffsetIOPSProvider uint16_t Offset of the IO provider state (provider) for this submodule. The
offset is relative to the beginning of the IOPS block in DPM output
area.
Note: If the IOPS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
usOffsetIOPSConsumer uint16_t Offset of the IO provider state (consumer) for this submodule. The
offset is relative to the beginning of the IOPS block in the DPM
input area.
Note: If the IOPS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
usOffsetIOCSProvider uint16_t Offset of the IO consumer state (provider) for this submodule. The
offset is relative to the beginning of IOCS block in DPM output
area.
Note: If the IOCS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Variable Type Value / Description

Range
usOffsetIOCSConsumer uint16_t Offset of the IO consumer state (consumer) for this submodule
relative to the beginning of the IOCS block in DPM input area.
Note: If the IOCS mode is set to “bitwise mode”, the application
has to ensure that the offset addresses do not overlap. The stack
will not check them for overlapping in this mode.
ulReserved uint32_t 0 Reserved for future use. Set to zero.
usSubmodState uint16_t 0..1 The submodule state. See below
ulModuleId uint32_t 1..0xFFFFFFF The module identifier.
F
usModuleState uint16_t 0..1 The submodule state:
0 = correct module,
1 = substitute module
Table 144: PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_T – Extended Plug Submodule request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_DATA_Ttag
{
/** Obsolete field. set to zero */
uint32_t ulReserved1;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t ulSubmodId;
/* provider data is data sent by IO-Device and received by IO-Controller */
uint32_t ulProvDataLen;
/* consumer data is data sent by IO-Controller and received by IO-Device */
uint32_t ulConsDataLen;
/* offset in DPM where Output data (consumed by IO-Device from IO-Controller) is copied
to */
uint32_t ulDPMOffsetCons;
/* offset in DPM where Input data (provided by IO-Device to IO-Controller) is taken
from */
uint32_t ulDPMOffsetProv;
/* offset where to put IOPS provider state for this submodule relative to beginning of
IOPS block in dpm output area to */
uint16_t usOffsetIOPSProvider;
/* offset where to take IOPS provider state of this submodule relative to beginning of
IOPS block in dpm input area from */
uint16_t usOffsetIOPSConsumer;
/* offset where to put IOCS provider state for this submodule relative to beginning of
IOCS block in dpm output area to */
uint16_t usOffsetIOCSProvider;
/* offset where to take IOCS provider state of this submodule relative to beginning of
IOCS block in dpm input area from */
uint16_t usOffsetIOCSConsumer;
/* reserved for future use - maybe needed for DPM Area later */
uint32_t ulReserved2;
/* submodule state: 0 = correct submodule, 1 = substitute submodule */
uint16_t usSubmodState;
/* Module identifier (new since V3.4 - Submodules can now be plugged without prior
plugging the modules)*/
uint32_t ulModuleId;
/* Module state (new since V3.4 - Submodules can now be plugged without prior plugging
the modules)*/
uint16_t usModuleState;
} __HIL_PACKED_POST PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 211/323
/** packet data */
PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_T;

6.4.6.4 Extended Plug Submodule confirmation

This is the confirmation of the extended plug submodule request.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 56 Packet data length in bytes (0 in case of error)
ulCmd uint32_t 0x1F09 PNS_IF_PLUG_SUBMODULE_CNF (It’s the same command
as standard plug submodule confirmation)
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot the submodule was plugged into.
ulSubslot uint32_t The Subslot the submodule was plugged into
ulSubmodId uint32_t The SubmoduleID of the submodule.
ulProvDataLen uint32_t The provider data length, i.e. the length of the Input data of
this submodule.
ulConsDataLen uint32_t The consumer data length, i.e. the length of the Output data
of this submodule
ulDPMOffsetCons uint32_t Offset in DPM where consumer data for the submodule will
be copied to.
ulDPMOffsetProv uint32_t Offset in DPM where provider data for the submodule will be
taken from.
usOffsetIOPSProvider uint16_t Offset of the IO provider state (provider) for this submodule.
The offset is relative to the beginning of the IOPS block in
DPM output area.
usOffsetIOPSConsumer uint16_t Offset of the IO provider state (consumer) for this submodule.
The offset is relative to the beginning of the IOPS block in the
DPM input area.
usOffsetIOCSProvider uint16_t Offset of the IO consumer state (provider) for this submodule.
The offset is relative to the beginning of IOCS block in DPM
output area.
usOffsetIOCSConsumer uint16_t Offset of the IO consumer state (consumer) for this
submodule relative to the beginning of the IOCS block in
DPM input area.
ulReserved uint32_t 0 Reserved for future use.
usSubmodState uint16_t 0..1 The submodule state
ulModuleId uint32_t 1..0xFFFFFFFF The module identifier.
usModuleState uint16_t 0..1 The module state
Table 145: PNS_IF_PLUG_SUBMODULE_EXTENDED_CNF_T – Extended Plug Submodule confirmation

Packet structure reference

typedef PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_T PNS_IF_PLUG_SUBMODULE_EXTENDED_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.7 Pull Module service

With this service, the application can pull modules. This removes the module and its submodules
from the configuration. The stack will generate a Pull Module Alarm for each AR, which owned any
submodule of this module.
This service is directly confirmed, even if the corresponding action in the protocol stack (e.g.
sending an alarm to IO Controller) is not yet finished.
The following figure shows the packet sequence.

Figure 44: Pull Module: packet sequence

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.7.1 Pull Module request

Receiving this packet forces the stack to automatically send a Pull-alarm to the IO-Controller if a
connection is established.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 12 Packet data length in bytes
ulCmd uint32_t 0x1F06 PNS_IF_PULL_MODULE_REQ
Data
ulReserved uint32_t Reserved. Set to Zero.
ulApi uint32_t The API of the module.
ulSlot uint32_t The Slot to pull the module from.
Table 146: PNS_IF_PULL_MODULE_REQ_T - Pull Module request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PULL_MODULE_REQ_DATA_Ttag
{
/** Obsolete field. set to zero */
uint32_t ulReserved;
uint32_t ulApi;
uint32_t ulSlot;
} __HIL_PACKED_POST PNS_IF_PULL_MODULE_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PULL_MODULE_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PULL_MODULE_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PULL_MODULE_REQ_T;

6.4.7.2 Pull Module confirmation

The stack will return this packet to the application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F07 PNS_IF_PULL_MODULE_CNF
Data
ulReserved uint32_t Reserved. Will be set to Zero.
ulApi uint32_t The API of the module.
ulSlot uint32_t The Slot to pull the module from.
Table 147: PNS_IF_PULL_MODULE_CNF_T – Pull Module confirmation

Packet structure reference

typedef PNS_IF_PULL_MODULE_REQ_T PNS_IF_PULL_MODULE_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.8 Pull Submodule service

With this service, the application can pull submodules. This will remove the submodule from the
stacks configuration. If the submodule is in use by any AR, a Pull Alarm will be generated
automatically.
This service is directly confirmed, even if the corresponding action in the protocol stack (e.g.
sending an alarm to IO Controller) is not yet finished.
The following figure shows the packet sequence.

Figure 45: Pull Submodule: packet sequence

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.8.1 Pull Submodule request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 16 Packet data length in bytes
ulCmd uint32_t 0x1F0A PNS_IF_PULL_SUBMODULE_REQ
Data
ulReserved uint32_t Reserved. Set to zero.
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot to pull the submodule from.
ulSubslot uint32_t The subslot to pull the submodule from.
Table 148: PNS_IF_PULL_SUBMODULE_REQ_T - Pull Submodule request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_PULL_SUBMODULE_REQ_DATA_Ttag
{
/** Obsolete field. set to zero */
uint32_t ulReserved;
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
} __HIL_PACKED_POST PNS_IF_PULL_SUBMODULE_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PULL_SUBMODULE_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_PULL_SUBMODULE_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_PULL_SUBMODULE_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.8.2 Pull Submodule confirmation

The stack will return this packet to the application.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 16 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F0B PNS_IF_PULL_SUBMODULE_CNF
Data
ulReserved uint32_t Reserved. Will be set to Zero.
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot to pull the submodule from.
ulSubslot uint32_t The subslot to pull the submodule from.
Table 149: PNS_IF_PULL_SUBMODULE_CNF_T - Pull Submodule confirmation

Packet structure reference

typedef PNS_IF_PULL_SUBMODULE_REQ_T PNS_IF_PULL_SUBMODULE_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.9 Get Station Name service

With this service, the application can request the current NameOfStation from the stack.

6.4.9.1 Get Station Name request

In order to request the current NameOfStation from the stack, the application has to send the
following request packet to the stack.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 0 Packet data length in bytes
ulCmd uint32_t 0x1F8E PNS_IF_GET_STATION_NAME_REQ
Table 150: PNS_IF_GET_STATION_NAME_REQ_T - Get Station Name request

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_GET_STATION_NAME_REQ_T;

6.4.9.2 Get Station Name confirmation

The protocol stack returns the following confirmation packet. It contains the current
NameOfStation.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 242 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F8F PNS_IF_GET_STATION_NAME_CNF
Data
usNameLen uint16_t 0..240 Length of the current NameOfStation.
abNameOfStation[240] uint8_t The NameOfStation as ASCII byte-array.
For details about allowed characters, see section Name encoding
(page 309).
Table 151: PNS_IF_GET_STATION_NAME_CNF_T - Get Station Name confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_GET_STATION_NAME_CNF_DATA_Ttag
{
uint16_t usNameLen;
uint8_t abNameOfStation[PNS_IF_MAX_NAME_OF_STATION];
} __HIL_PACKED_POST PNS_IF_GET_STATION_NAME_CNF_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_STATION_NAME_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_GET_STATION_NAME_CNF_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_GET_STATION_NAME_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 218/323
6.4.10 Get IP Address service
With this service, the application can request the current IP-parameters (IP address, network
mask, gateway address) from the stack.

6.4.10.1 Get IP Address request

In order to request the current IP-parameters from the stack, the application has to send the
following request packet to the stack:

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 0 Packet data length in bytes
ulCmd uint32_t 0x1FBC PNS_IF_GET_IP_ADDR_REQ
Table 152: PNS_IF_GET_IP_ADDR_REQ_T - Get IP Address request

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_GET_IP_ADDR_REQ_T;

6.4.10.2 Get IP Address confirmation

The protocol stack returns the following confirmation packet. It contains the current IP parameters.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes
ulSta uint32_t 0 Status has to be okay for this service.
ulCmd uint32_t 0x1FBD PNS_IF_GET_IP_ADDR_CNF
Data
ulIpAddr uint32_t The IP address.
ulNetMask uint32_t The network mask.
ulGateway uint32_t The gateway address.
Table 153: PNS_IF_GET_IP_ADDR_CNF_T - Get IP Address confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_GET_IP_ADDR_CNF_DATA_Ttag
{
uint32_t ulIpAddr;
uint32_t ulNetMask;
uint32_t ulGateway;
} __HIL_PACKED_POST PNS_IF_GET_IP_ADDR_CNF_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_IP_ADDR_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_GET_IP_ADDR_CNF_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_GET_IP_ADDR_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.11 Add Channel Diagnosis service

With this service, the user application can add a diagnosis data record to a submodule.
Inside the confirmation packet, the stack sends a unique record handle to the application. The
application has to store this handle, as it is needed to remove the diagnosis record later on.

6.4.11.1 Add Channel Diagnosis request

Using this packet the user application can add diagnosis data to a submodule.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 22 Packet data length in bytes
ulCmd uint32_t 0x1F46 PNS_IF_ADD_CHANNEL_DIAG_REQ
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t 0 Not used inside this request. Will be used for confirmation by the
stack. Set to zero.
usChannelNum uint16_t Channel Number for which the diagnosis data shall be added.
Supported are Manufacturer specific Channel Numbers in the
range of 0x0000-0x7FFF and the Channel number for the
submodule itself 0x8000
usChannelProp uint16_t Channel properties. See Table 214 (page 305)
usChannelErrType uint16_t Channel error type. See Table 218 (page 307)
Table 154: PNS_IF_ADD_CHANNEL_DIAG_REQ_T - Add Channel Diagnosis request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_CHANNEL_DIAG_Ttag
{
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t hDiagHandle;
uint16_t usChannelNum;
uint16_t usChannelProp;
uint16_t usChannelErrType;
} __HIL_PACKED_POST PNS_IF_ADD_CHANNEL_DIAG_T;

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_CHANNEL_DIAG_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ADD_CHANNEL_DIAG_T tData;
} __HIL_PACKED_POST PNS_IF_ADD_CHANNEL_DIAG_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.11.2 Add Channel Diagnosis confirmation

With this packet, the stack informs the application about the success of adding diagnosis data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 22 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F47 PNS_IF_ADD_CHANNEL_DIAG_CNF
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t A unique handle representing this diagnostic record inside the
stack. The application shall store it as it is has to be used to be
able to remove the record later on.
usChannelNum uint16_t Channel Number for which the diagnosis data shall be added.
Supported are Manufacturer specific Channel Numbers in the
range of 0x0000-0x7FFF and the Channel number for the
submodule itself 0x8000
usChannelProp uint16_t Channel properties, see Table 214 (page 305).
usChannelErrType uint16_t Channel error type, see Table 218 (page 307)
Table 155: PNS_IF_ADD_CHANNEL_DIAG_CNF_T - Add Channel Diagnosis confirmation

Packet structure reference

typedef PNS_IF_ADD_CHANNEL_DIAG_REQ_T PNS_IF_ADD_CHANNEL_DIAG_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.12 Add Extended Channel Diagnosis service

With this service, the user application can add an extended diagnosis data record to a submodule.
Inside the confirmation packet, the stack sends a unique record handle to the application. The
application has to store this handle, as it is needed to remove the diagnosis record later on.

6.4.12.1 Add Extended Channel Diagnosis request

The user application can add extended diagnosis data to a submodule using this packet.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 30 PNS_IF_ADD_EXT_DIAG_REQ_T - Packet data length in
bytes
ulCmd uint32_t 0x1F54 PNS_IF_ADD_EXTENDED_DIAG_REQ
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t 0 Not used inside this request. Will be used for confirmation by
the stack. Set to zero.
usChannelNum uint16_t Channel Number for which the diagnosis data shall be added.
Supported are Manufacturer specific Channel Numbers in the
range of 0x0000-0x7FFF and the Channel number for the
submodule itself 0x8000
usChannelProp uint16_t Channel properties, See Table 214 (page 305)
usChannelErrType uint16_t Channel error type, See Table 218 (page 307)
usReserved uint16_t Reserved
ulExtChannelAddValue uint32_t Additional Value. Can be used to transfer additional
information regarding the diagnosis. (E.g. Temperature) Can
be displayed by engineering software using format strings
defined in GSDML.
usExtChannelErrType uint16_t 1 ... 0x7FFF Extended channel error type, see Table 219 (page 307).
Table 156: PNS_IF_ADD_EXTENDED_DIAG_REQ_T - Add Extended Channel Diagnosis request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 222/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_ADD_EXTENDED_DIAG_Ttag
{
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t hDiagHandle;
uint16_t usChannelNum;
uint16_t usChannelProp;
uint16_t usChannelErrType;
uint16_t usReserved;
uint32_t ulExtChannelAddValue;
uint16_t usExtChannelErrType;
} __HIL_PACKED_POST PNS_IF_ADD_EXTENDED_DIAG_T;

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_EXTENDED_DIAG_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ADD_EXTENDED_DIAG_T tData;
} __HIL_PACKED_POST PNS_IF_ADD_EXTENDED_DIAG_REQ_T;

6.4.12.2 Add Extended Channel Diagnosis confirmation

With this packet, the stack informs the application about the success of adding extended diagnosis
data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 30 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F55 PNS_IF_ADD_EXTENDED_DIAG_CNF
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t A unique handle representing this diagnostic record inside the
stack. Application shall store it as it is has to be used to be
able to remove the record later on.
usChannelNum uint16_t Channel Number for which the diagnosis data shall be added.
Supported are Manufacturer specific Channel Numbers in the
range of 0x0000-0x7FFF and the Channel number for the
submodule itself 0x8000.
usChannelProp uint16_t Channel properties, see Table 214 (page 305)
usChannelErrType uint16_t Channel error type, see Table 218 (page 307)
usReserved uint16_t Reserved
ulExtChannelAddValue uint32_t 0 Currently not supported, set to zero.
usExtChannelErrType uint16_t Extended channel error type, see see Table 219 (page 307).
Table 157: PNS_IF_ADD_EXTENDED_DIAG_CNF_T - Add Extended Channel Diagnosis confirmation

Packet structure reference

typedef PNS_IF_ADD_EXTENDED_DIAG_REQ_T PNS_IF_ADD_EXTENDED_DIAG_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.13 Add Generic Diagnosis service

Note 1: Usage of this service is not recommended. Generic diagnosis cannot be handled
automatically by Engineering systems. The PI Diagnosis Guideline recommends not
using this service.
It should be used in justified exceptions to this rule only.

Note 2: Generic Diagnoses contain application-specific amount of user data. Thus the memory
must be allocated dynamically at runtime and cannot be predicted. In turn the
successful creation of a generic diagnosis entry depends on the following runtime
properties:
- Available dynamic memory
- Memory Fragmentation due to runtime memory allocation
They should be used in justified exceptions to this rule only.

Note 3: In case the application uses the Add Generic Diagnosis service on a Submodule with
an existing generic diagnosis which has the same usUserStructId as the service
request, then the existing Diagnosis record will be updated with new diagnosis data
instead of creating a new record.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.13.1 Add Generic Channel Diagnosis request

Using this packet the user application can add generic diagnosis data to a submodule.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 26 + n PNS_IF_ADD_GENERIC_DIAG_REQ - Packet data length in bytes
+ usDiagDataLen
ulCmd uint32_t 0x1F58 PNS_IF_ADD_GENERIC_DIAG_REQ
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t 0 Use zero. Not used for the request.
Will be used for confirmation by the stack.
usChannelNum uint16_t 0x8000 Channel Number for which the diagnosis data has to be added.
Supported are manufacturer-specific Channel Numbers in the range
of 0x0000-0x7FFF and the Channel number for the submodule itself
0x8000.
Note: The PROFINET specification requires that usChannelNum
has to be set to 0x8000 if 0 <= usUserStructId < 0x8000.
usChannelProp uint16_t 0 Channel properties, see Table 214 (page 305).
Note: The PROFINET specification requires that usChannelProp
has to be set to 0x0000 if 0 <= usUserStructId < 0x8000.
usUserStructId uint16_t 0 - 0x7FFF Manufacturer specific.
usReserved uint16_t 0 Reserved
usDiagDataLen uint16_t The length of the diagnosis data
1 … 172 Length supported by any IO-Controller.
173 … 1024 Length allowed by the specification but not supported by any IO-
Controller.
See parameter description below.
abDiagData[1024] uint8_t Diagnosis Data
Table 158: PNS_IF_ADD_GENERIC_DIAG_REQ_T - Add Generic Channel Diagnosis request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 225/323
Packet structure reference
typedef __HIL_PACKED_PRE struct PNS_IF_ADD_GENERIC_DIAG_REQ_DATA_Ttag
{
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t hDiagHandle;
uint16_t usChannelNum;
uint16_t usChannelProp;
uint16_t usUserStructId;
uint16_t usReserved;
uint16_t usDiagDataLen;
uint8_t abDiagData[PNS_IF_MAX_ALARM_DATA_LEN]; /* ATTENTION: Recommended not to use
more than 172 byte of data for compatibility reasons */
} __HIL_PACKED_POST PNS_IF_ADD_GENERIC_DIAG_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ADD_GENERIC_DIAG_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_ADD_GENERIC_DIAG_REQ_T;

usDiagDataLen

Note: The PROFINET specification guarantees a total diagnosis data length of 200 byte to be
exchangeable between IO-Device and IO-Controller. IO-Controllers may support more
than 200 byte but the IO-Device cannot rely on it. For this reason, we highly
recommend to you not to generate any diagnosis data that exceeds 200 bytes.

The 200 bytes include 28 bytes for submodule and protocol-related parameters. This means that
the pure application data including the User Structure Identifier is limited to 174 byte in this case.
Note that the User Structure Identifier is part of the 28 bytes and that it is already included in the
PNS_IF_ADD_GENERIC_DIAG_REQ_DATA_T structure and therefore should not be used with
diagnosis data length of more than 172 bytes.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.13.2 Add Generic Channel Diagnosis confirmation

With this packet the stack informs the application about the success of adding generic diagnosis
data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 22 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F59 PNS_IF_ADD_GENERIC_DIAG_CNF
Data
ulApi uint32_t The API of the submodule.
ulSlot uint32_t The Slot of the submodule.
ulSubslot uint32_t The Subslot of the submodule.
hDiagHandle uint32_t A unique handle representing this diagnostic record inside the
stack. Application shall store it as it is has to be used to be able to
remove the record later on.
usChannelNum uint16_t 0x8000 Channel number for which the diagnosis data has to be added.
Supported are Manufacturer specific Channel Numbers in the range
of 0x0000-0x7FFF and the Channel number for the submodule itself
0x8000.
usChannelProp uint16_t Channel properties, see Table 214 (page 305).
usUserStructId uint16_t 0 - 0x7FFF Manufacturer specific.
Table 159: PNS_IF_ADD_GENERIC_DIAG_CNF_T - Add Generic Channel Diagnosis confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_GENERIC_DIAG_CNF_DATA_Ttag
{
uint32_t ulApi;
uint32_t ulSlot;
uint32_t ulSubslot;
uint32_t hDiagHandle;
uint16_t usChannelNum;
uint16_t usChannelProp;
uint16_t usUserStructId;
} __HIL_PACKED_POST PNS_IF_ADD_GENERIC_DIAG_CNF_DATA_T;

typedef __HIL_PACKED_PRE struct

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ADD_GENERIC_DIAG_CNF_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_ADD_GENERIC_DIAG_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.14 Remove Diagnosis service

With this service, the user application can remove previously added diagnosis data from a
submodule. This is reported to the IO-Controller with a “diagnosis disappears” alarm automatically
if necessary.

6.4.14.1 Remove Diagnosis request

Using this packet the user application can remove diagnosis data from a submodule.

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 4 Packet data length in bytes
ulCmd uint32_t 0x1FE6 PNS_IF_REMOVE_DIAG_REQ
Data
hDiagHandle uint32_t The unique diagnosis handle given to application by the stack while
adding the diagnosis record.
Table 160: PNS_IF_REMOVE_DIAG_REQ_T - Remove Diagnosis request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_REMOVE_DIAG_REQ_DATA_Ttag
{
uint32_t hDiagHandle;
} __HIL_PACKED_POST PNS_IF_REMOVE_DIAG_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_REMOVE_DIAG_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_REMOVE_DIAG_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_REMOVE_DIAG_REQ_T;

6.4.14.2 Remove Diagnosis confirmation

With this packet, the stack informs the application about the success of removing diagnosis data.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1FE7 PNS_IF_REMOVE_DIAG_CNF
Data
hDiagHandle uint32_t The unique diagnosis handle given to application by the stack while
adding the diagnosis record.
Table 161: PNS_IF_REMOVE_DIAG_CNF_T - Remove Diagnosis confirmation

Packet structure reference

typedef PNS_IF_REMOVE_DIAG_REQ_T PNS_IF_REMOVE_DIAG_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 228/323
6.4.15 Set Submodule State service
With this service, the application has the possibility to change the submodule state. This is useful
in e.g. gateway applications. Using this service the user application is able to influence the
occurrence of a submodule in the ModuleDiffBlock.

Note: This service is only usable for the user application if the user application handles IOxS,
as well. If IOxS is not handled by the application, the stack will not allow the usage of
this service.

A possible use case for this service is the following scenario:

A gateway application requires some parameter records to configure the underlying network. The
content of the records is expected by the underlying network to work properly. Missing or invalid
parameters disallow using some (or all) of the nodes of the underlying network.
To be able to receive the parameter records the application is required to adapt the local
PROFINET submodule configuration during Connection establishment by evaluating Check
Indication (page 122) and using the Extended Plug Submodule request (page 209). After the
parameters have been received via Write Record indication (page 144) and the application
received the Parameter End indication (page 129), it configures and parameterizes the underlying
network. If an error occurs in this phase, it can be indicated to the IO-Controller by setting the
submodule state of the erroneous submodules to “ApplicationReady pending”. In addition, the
application might generate a specific diagnosis to indicate the problem on an additional level. The
IOPS of the affected submodules needs to be set to “bad”. Afterwards, the application has to send
ApplicationReady using the Application Ready request (page 132).

Note: The submodule state is bound to the submodule and is only changed by the user
application. Thus if the state is set to “ApplicationReady pending” and the AR is
terminated and reestablished afterwards, the submodule will be reported with
“ApplicationReady pending” by the protocol stack.

6.4.15.1 Set Submodule State request

To set the Submodule State the following packet shall be used.
Only these states are supported: “ApplicationReady pending”, “Submodule ordinated locked” and
“okay”.
It is possible to set the state of multiple submodules at the same time to the state
“ApplicationReady pending”. However, it is not possible to set multiple submodules at the same
time to the state “okay”. Setting the submodule state “okay” needs to be done in a single request
for each submodule whose state is now “okay”.

Note: The request packet has a limited size, depending on maximal DPM packet length. The
maximal count of configured submodules is limited to 98. If more submodules are
configured, the error code ERR_HIL_FAIL in ulSta will be returned.

Note: A submodule in the state “ApplicationReady pending” shall have its IOPS set to “bad”.
In consequence if the submodule state changes back to “good” the IOPS needs to be
changed to “good” by the application. This will automatically trigger generation of a
ReturnOfSubmodule Alarm by the protocol stack.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 16 + n Packet data length in bytes
ulCmd uint32_t 0x1F92 PNS_IF_SET_SUBM_STATE_REQ
Data
ulSubmCnt uint32_t 1…129 The amount of submodules contained in the packet.
ulApi uint32_t The API of the first submodule.
usSlot uint16_t The slot of the first submodule.
usSubslot uint16_t The subslot of the first submodule.
usSubmState uint16_t The new submodule state (see below)
usModuleState uint16_t Reserved for future use. Set to 0.
Table 162: PNS_IF_SET_SUBM_STATE_REQ–T - Set Submodule State request

Valu Name
e
0 PNS_IF_SET_SUBM_STATE_SUBM_OKAY The submodule state is okay, it is
ready
for valid data exchange.
1 PNS_IF_SET_SUBM_STATE_SUBM_SUPERO The submodule is locked by
RD_LOCKED application
2 PNS_IF_SET_SUBM_STATE_SUBM_APPL_R The submodule is not ready for
EADY_PENDING valid
data exchange
Table 163: Values of usSubmState

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 230/323
Packet structure reference
/* the submodule is locked by application */
/* not yet supported by the stack, for future use */
#define PNS_IF_SET_SUBM_STATE_SUBM_SUPERORD_LOCKED (1)
/* the submodule is not yet ready for data exchange but not locked */
#define PNS_IF_SET_SUBM_STATE_SUBM_APPL_READY_PENDING (2)
/* the submodule is no longer locked */
#define PNS_IF_SET_SUBM_STATE_SUBM_OKAY (0)

typedef __HIL_PACKED_PRE struct PNS_IF_SET_SUBM_STATE_SUBMBLOCK_Ttag

{
/* the API the submodule belongs to */
uint32_t ulApi;
/* the slot the submodule resides */
uint16_t usSlot;
/* the subslot the submodule resides */
uint16_t usSubslot;
/* the submodule state (see above) */
uint16_t usSubmState;
/* the module state, reserved for future use! */
uint16_t usModuleState;
} __HIL_PACKED_POST PNS_IF_SET_SUBM_STATE_SUBMBLOCK_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_SUBM_STATE_DATA_REQ_Ttag

{
/* amount of submodules contained in this packet */
uint32_t ulSubmCnt;
/* the first of ulSubmCnt submodule datasets */
PNS_IF_SET_SUBM_STATE_SUBMBLOCK_T atSubm[98];
} __HIL_PACKED_POST PNS_IF_SET_SUBM_STATE_DATA_REQ_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SET_SUBM_STATE_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_SET_SUBM_STATE_DATA_REQ_T tData;
} __HIL_PACKED_POST PNS_IF_SET_SUBM_STATE_REQ_T;

6.4.15.2 Set Submodule State confirmation

The stack will return this packet to the application.

Packet description

ariable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F93 PNS_IF_SET_SUBM_STATE_CNF
Table 164: PNS_IF_SET_SUBM_STATE_CNF–T - Set Submodule State confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_SET_SUBM_STATE_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.16 Get Parameter service

The application can use this service to retrieve runtime parameters from the protocol stack.

Note: The protocol stack ignores the submodule reference parameters for global parameters.

6.4.16.1 Get Parameter request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 2 or 12 Packet data length in bytes: 2 for generic parameters, 12 for
submodule specific parameters
ulCmd uint32_t 0x1F64 PNS_IF_GET_PARAM_REQ
Data PNS_IF_PARAM_COMMON_T
usPrmType uint16_t 1 ... 7 Parameters to be retrieved, see table below.
usPadding uint16_t 0 Set usPadding to zero for future compatibility.

ulApi uint32_t API of the submodule

usSlot uint16_t Slot of the submodule
usSubslot uint16_t Subslot of the submodule
Table 165: PNS_IF_GET_PARAM_REQ_T - Get Parameter request

Packet structure reference

enum PNS_IF_PARAM_Etag
{
PNS_IF_PARAM_MRP = 1,
PNS_IF_PARAM_SUBMODULE_CYCLE = 2,
PNS_IF_PARAM_ETHERNET = 3,
PNS_IF_PARAM_DIAGNOSIS = 4, /* only useable for port- and interface submodules */
PNS_IF_PARAM_IM0_DATA = 5,
PNS_IF_PARAM_IM5_DATA = 6,
PNS_IF_PARAM_PORT_STATISTIC = 7, /* only useable for port-submodules */
};

typedef enum PNS_IF_PARAM_Etag PNS_IF_PARAM_E;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_COMMON_Ttag

{
/** mandatory */
uint16_t usPrmType;
/** following parameters are optional */
uint16_t usPadding;
/** api of the associated submodule */
uint32_t ulApi;
/** slot of the associated submodule */
uint16_t usSlot;
/** subslot of the associated submodule */
uint16_t usSubslot;
} __HIL_PACKED_POST PNS_IF_PARAM_COMMON_T;

typedef __HIL_PACKED_PRE struct PNS_IF_GET_PARAM_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_PARAM_COMMON_T tData;
} __HIL_PACKED_POST PNS_IF_GET_PARAM_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

The following values are valid for usPrmType:

Symbolic name Value Description
PNS_IF_PARAM_MRP 1 Media Redundancy Parameters (Global Parameter)
PNS_IF_PARAM_SUBMODULE_CYCLE 2 Submodule Process Data Cycle (Output)
PNS_IF_PARAM_ETHERNET 3 Port submodule-related Ethernet parameters
PNS_IF_PARAM_DIAGNOSIS 4 Delivers all PDEV diagnosis entries. The application can use this
service to read diagnosis entries generated by the protocol stack.
Thus, all diagnoses generated by the protocol stack for submodules
whose subslot is in the range 0x8000 to 0x8002 will be returned. In
other words: Diagnoses generated by the application for these
submodules will not be returned.
PNS_IF_PARAM_IM0_DATA 5 The values the protocol stack will deliver for I&M0 if handling of I&M
by protocol stack is enabled.
PNS_IF_PARAM_IM5_DATA 6 The values the protocol stack will deliver form I&M5 if handling of
I&M by protocol stack is enabled.
PNS_IF_PARAM_PORT_STATISTIC 7 Lists the current switch statistic counters including a validity mask of
the given port submodule.
Table 166: PNS_IF_PARAM_E - Valid parameter options

6.4.16.2 Get Parameter confirmation

The stack will return this packet in answer to the Get Parameter Request. In case of success, this
packet contains the requested information.

Packet description

Variable Type Value / Description

Range
ulLen uint32_t >2 Packet data length in bytes. Depends on the
requested information. 0 in case of error.
ulSta uint32_t See section Error codes and status codes on
page 272.
ulCmd uint32_t 0x1F65 PNS_IF_GET_PARAM_CNF
Data, union PNS_IF_PARAM_T
tMrp PNS_IF_PARAM_MRP_T MRP parameter
tSubmoduleCycle PNS_IF_PARAM_SUBMODULE_CYCLE_T Submodule cycle parameter
tEthernetPrm PNS_IF_PARAM_ETHERNET_T Port-submodule Ethernet parameter
tDiagnosisData PNS_IF_DIAGNOSIS_T PDev pending diagnosis
tIM0Data PNS_IF_IM0_DATA_T I&M0 data implemented in the protocol stack.
tIM5Data PNS_IF_IM5_DATA_T I&M5 data implemented in protocol stack.
tPortStatistic PNS_IF_PARAM_PORT_STATISTIC_DAT Port-submodule: switch statistic counters
A_T
Table 167: PNS_IF_GET_PARAM_CNF_T - Get Parameter confirmation

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 233/323
Packet structure reference
/** MRP was disabled by protocol stack itself */
#define PNS_IF_MRP_STATE_DISABLED (0)
/** MRP was enabled by protocol with default values.
* That happens if no explicit MRP parameterization took place */
#define PNS_IF_MRP_STATE_ENABLED_DEFAULT (1)
/** MRP was enabled explicitly by parameterization
* The controller enabled MRP explicitly by means of MRP parameter record */
#define PNS_IF_MRP_STATE_ENABLED_PRM (2)
/** MRP was disabled explicitly by parameterization
* The controller disabled MRP explicitly by means of MRP parameter record */
#define PNS_IF_MRP_STATE_DISABLED_PRM (3)

#define PNS_IF_MRP_ROLE_NONE (0)

#define PNS_IF_MRP_ROLE_MRP_CLIENT (1)
#define PNS_IF_MRP_ROLE_MRP_MANAGER (2)

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_MRP_Ttag

{
uint16_t usPrmType;
uint8_t bState;
uint8_t bRole;
HIL_UUID_T tUUID;
uint8_t szDomainName[PNS_IF_MAX_NAME_OF_STATION];
} __HIL_PACKED_POST PNS_IF_PARAM_MRP_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_SUBMODULE_CYCLE_Ttag

{
uint16_t usPrmType;

uint16_t usPadding;
/** api of the associated submodule */
uint32_t ulApi;
/** slot of the associated submodule */
uint16_t usSlot;
/** subslot of the associated submodule */
uint16_t usSubslot;
/** update interval of this submodules process data in nanoseconds */
uint32_t ulUpdateInterval;
/** send base clock for the associated iocr */
uint16_t usSendClock;
/** send clock reduction for the associated iocr */
uint16_t usReductionRatio;
/** missing frames until timeout of the associated iocr */
uint16_t usDataHoldFactor;
} __HIL_PACKED_POST PNS_IF_PARAM_SUBMODULE_CYCLE_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_ETHERNET_Ttag

{
uint16_t usPrmType;
/* real Mutype */
uint16_t usMauType;
/* measured power budget in dB */
uint32_t ulPowerBudget;
/* measured cable delay in ns */
uint32_t ulCableDelay;
} __HIL_PACKED_POST PNS_IF_PARAM_ETHERNET_T;

typedef __HIL_PACKED_PRE struct PNS_IF_DIAGNOSIS_ENTRY_Ttag

{
/* subslot the diagnosis alarm belongs to */
uint16_t usSubslot;
/* Channel properties */
uint16_t usChannelProp;
/* Channel error type */
uint16_t usChannelErrType;
/* Channel extended error type */
uint16_t usExtChannelErrType;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 234/323
} __HIL_PACKED_POST PNS_IF_DIAGNOSIS_ENTRY_T;

#define MAX_DIAGNOSIS_ENTRIES_CNT 32

typedef __HIL_PACKED_PRE struct PNS_IF_DIAGNOSIS_Ttag

{
uint16_t usPrmType;
/* The amount of diagnosis entries contained in the confirmation */
uint16_t usDiagnosisCnt;
/** Diagnosis data, shall contain usDiagnosisCnt entries */
PNS_IF_DIAGNOSIS_ENTRY_T atDiagnosis[MAX_DIAGNOSIS_ENTRIES_CNT];
} __HIL_PACKED_POST PNS_IF_DIAGNOSIS_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_IM0_DATA_Ttag

{
uint16_t usPrmType;
uint16_t usPadding;
PNS_IF_IM0_DATA_T tIM0Data;
} __HIL_PACKED_POST PNS_IF_PARAM_IM0_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_IM5_DATA_Ttag

{
uint16_t usPrmType;
uint16_t usPadding;
PNS_IF_IM5_DATA_T tIM5Data;
} __HIL_PACKED_POST PNS_IF_PARAM_IM5_DATA_T;

#define PNS_IF_VALID_MASK_PORT_STATISTIC_INOCTETS (0x0001)

#define PNS_IF_VALID_MASK_PORT_STATISTIC_OUTOCTETS (0x0002)
#define PNS_IF_VALID_MASK_PORT_STATISTIC_INDISCARDS (0x0004)
#define PNS_IF_VALID_MASK_PORT_STATISTIC_OUTDISCARDS (0x0008)
#define PNS_IF_VALID_MASK_PORT_STATISTIC_INERRORS (0x0010)
#define PNS_IF_VALID_MASK_PORT_STATISTIC_OUTERRORS (0x0020)

typedef __HIL_PACKED_PRE struct PNS_IF_PARAM_PORT_STATISTIC_DATA_Ttag

{
uint16_t usPrmType;
uint16_t usPadding;
uint32_t ulValidMask; /* indicator which of the fields in this structure contain valid
data */
uint32_t ulInOctets; /* number of octets received by the port */
uint32_t ulOutOctets; /* number of octets sent by the port */
uint32_t ulInDiscards; /* number of frames discarded or dropped due to low resources on
reception */
uint32_t ulOutDiscards; /* number of frames discarded before sending */
uint32_t ulInErrors; /* number of frames received with detected error */
uint32_t ulOutErrors; /* number of frames sent with detected error */
} __HIL_PACKED_POST PNS_IF_PARAM_PORT_STATISTIC_DATA_T;

typedef union PNS_IF_PARAM_Ttag PNS_IF_PARAM_T;

union PNS_IF_PARAM_Ttag
{
PNS_IF_PARAM_COMMON_T tCommon;
PNS_IF_PARAM_MRP_T tMrp;
PNS_IF_PARAM_SUBMODULE_CYCLE_T tSubmoduleCycle;
PNS_IF_PARAM_ETHERNET_T tEthernetPrm;
PNS_IF_DIAGNOSIS_T tDiagnosisData;
PNS_IF_PARAM_IM0_DATA_T tIM0Prm;
PNS_IF_PARAM_IM5_DATA_T tIM5Prm;
PNS_IF_PARAM_PORT_STATISTIC_DATA_T tPortStatistic;
};

typedef __HIL_PACKED_PRE struct PNS_IF_GET_PARAM_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_PARAM_T tData;
} __HIL_PACKED_POST PNS_IF_GET_PARAM_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Media Redundancy Parameters (usPrmType = 1)

Coding of tMrp
Variable Type Value / Description
Range
usPrmType uint16_t 1 Mrp parameter option value
bState uint8_t 0-3 Mrp state, see Table 169 (page 235).
bRole uint8_t 0-1 Mrp Role of the Device, see Table 170 (page 235).
tUUID HIL_UUID_T Mrp UUID
szDomainName uint8_t[240] Mrp Domain Name. String Length is Packet Length minus 20.
For details about allowed characters, see section Name encoding (page
309).
Table 168: PNS_IF_PARAM_MRP_T - MRP parameter

The following values are valid for bState

Symbolic Name Numerical Description
Value
MRP_STATE_DISABLED 0 MRP was disabled by the protocol stack
MRP_STATE_ENABLED_DEFAULT 1 MRP was enabled by the protocol stack using default MRP
parameters. (No parameter was written by controller / Factory
Reset)
MRP_STATE_ENABLED_PRM 2 MRP was enabled on behalf of Controller. (The corresponding
parameter was set with MRP enabled)
MRP_STATE_DISABLED_PRM 3 MRP was disabled on behalf of Controller. (The corresponding
parameter was et with MRP disabled)
Table 169: PNS_IF_PARAM_MRP_STATE_E - Valid values for MRP state

The following values are valid for bRole

Symbolic Name Numerical Description
Value
MRP_ROLE_NONE 0 MRP is disabled
MRP_ROLE_MRP_CLIENT 1 MRP is configured for Client Mode.
Table 170: PNS_IF_PARAM_MRP_ROLE_E - Valid values for MRP Role

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 236/323
Submodule Process Data Cycle (usPrmType = 2)
Coding of tSubmoduleCycle
Variable Type Value / Description
Range
usPrmType uint16_t 2 Submodule cycle option value
usPadding uint16_t Ignore for future compatibility
ulApi uint32_t API of the submodule
usSlot uint16_t Slot of the submodule
usSubslot uint16_t Subslot of the submodule
ulUpdateInterval uint32_t Output process data update interval in nanoseconds
usSendClock uint16_t PROFINET Send Clock
usReductionRatio uint16_t PROFINET Reduction Ratio
usDataHoldFactor uint16_t Output process data watchdog factor: The output process data timeout is
usDataHoldFactor x ulUpdateInterval.
Table 171: PNS_IF_PARAM_SUBMODULE_CYCLE_T - Submodule cycle parameter

Ethernet Parameters (usPrmType = 3)

Coding of tEthernetPrm
Variable Type Value / Description
Range
usPrmType uint16_t 3 Ethernet parameter option value
usMauType uint16_t Real MAU type
ulPowerBudget uint32_t Measured power budget in dB
ulCableDelay uint32_t Measured cable delay in ns
Table 172: PNS_IF_PARAM_ETHERNET_T - Submodule cycle parameter

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 237/323
Diagnosis (usPrmType = 4)
Coding of tDiagnosisData
Variable Type Value / Description
Range
usPrmType uint16_t 4 Diagnosis option value
usDiagnosisCnt uint16_t 0..32 Number of diagnosis entries contained in the confirmation
atDiagnosis[32] PNS_IF_DIAGNOSIS Diagnosis data, see Table 174.
_ENTRY_T
Table 173: PNS_IF_DIAGNOSIS_T - Diagnosis data

Coding of atDiagnosis
Variable Type Value / Description
Range
usSubslot uint16_t Subslot the diagnosis alarm belongs to
usChannelProp uint16_t Diagnosis channel properties, see Table 214 (page 305).
usChannelErrType uint16_t Diagnosis error type, see Table 218 on page 307,
usExtChannelErrType uint16_t Diagnosis extended error type, see Table 219 on page 307.
Table 174: PNS_IF_DIAGNOSIS_ENTRY_T - Diagnosis entry

I&M0 Parameters (usPrmType = 5)

Coding of tIM0Prm
Variable Type Value / Range Description
usPrmType uint16_t 5 Submodule cycle option value
usPadding uint16_t Ignore for future compatibility
tIM0Data PNS_IF_IM0_DATA_T See Read I&M response on page 168.
Table 175: PNS_IF_PARAM_IM0_DATA_T - Stack I&M0 record content

I&M5 Parameters (usPrmType = 6)

Coding of tIM5Prm
Variable Type Value / Range Description
usPrmType uint16_t 6 Submodule cycle option value
usPadding uint16_t Ignore for future compatibility
tIM5Data PNS_IF_IM5_DATA_T See Read I&M response on page 168.
Table 176: PNS_IF_PARAM_IM5_DATA_T – Stack I&M5 record content

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 238/323
Switch statistic counters (usPrmType = 7)
Coding of tPortStatistic
Variable Type Value / Description
Range
usPrmType uint16_t 7 PNS_IF_PARAM_PORT_STATISTIC
usPadding uint16_t 0 -
ulValidMask uint32_t 0..0x3F Bit field indicating which elements of this structure contain valid data.
ulInOctets uint32_t Number of octets received by this port.
ulOutOctets uint32_t Number of octets sent by this port.
ulInDiscards uint32_t Number of frames that the switch
did not forward to higher sublayer due to resource constraints
discarded after receipt due to port state
ulOutDiscards uint32_t Number of valid frames that were discarded.
ulInErrors uint32_t Number of received erroneous frames.
ulOutErrors uint32_t Number of frames that could not be transmitted due to an error.
Table 177: PNS_IF_PARAM_PORT_STATISTIC_DATA_T – Port statistics data

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.17 Add PE Entity service

The Add PE Entity service is part of the PE ASE implementation of the PROFINET Device stack.
The application has to use this service to add a PE entity to the PE ASE. The implementation
supports one PE entity per submodule.
The protocol stack will validate the parameters of the request packet and add the entity if the
addressed submodule
 exists, and
 is plugged, and
 has no PE entity yet.
The entities’ operational mode will be initialized to the value “Ready to operate” (0xFF). The
protocol stack will internally generate the PROFINET alarms associated with this operation.

Note: By default, all PE entity services are deactivated. In order to activate the PE entity
services, use the Set OEM Parameters service (page 82) with ulParamType set to 10.

6.4.17.1 Add PE Entity request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 8 Packet data length in bytes
ulCmd uint32_t 0x1F94 PNS_IF_ADD_PE_ENTITY_REQ
Data
ulApi uint32_t The API of the submodule associated with the the PE entity.
usSlot uint16_t The slot of the submodule associated with the PE entity.
usSubslot uint16_t The subslot of the submodule associated with the PE entity.
Table 178: PNS_IF_ADD_PE_ENTITY_REQ–T – Add PE Entity request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_PE_ENTITY_REQ_DATA_Ttag
{
uint32_t ulAPI;
uint16_t usSlot;
uint16_t usSubslot;
} __HIL_PACKED_POST PNS_IF_ADD_PE_ENTITY_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_ADD_PE_ENTITY_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_ADD_PE_ENTITY_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_ADD_PE_ENTITY_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.17.2 Add PE Entity confirmation

The protocol stack returns this packet to the application in order to confirm adding a PE entity.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F95 PNS_IF_ADD_PE_ENTITY_CNF
Table 179: PNS_IF_ADD_PE_ENTITY_CNF–T – Add PE Entity confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_ADD_PE_ENTITY_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.18 Remove PE Entity service

The Remove PE Entity service is part of the PE ASE implementation of the PROFINET Device
Stack. The application has to use this service to remove a PE entity from the PE ASE.
The protocol stack will validate the parameters of the packet and removes the PE entity if the
addressed submodule
 is plugged, and
 independent whether the submodule has an PE entity or not.

Note: By default, all PE entity services are deactivated. In order to activate the PE entity
services, use the Set OEM Parameters service (page 82) with ulParamType set to 10.

This service exists for symmetric reasons only and thus this service is not intended to be used as
there is no real use case for it.

6.4.18.1 Remove PE Entity request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 8 Packet data length in bytes
ulCmd uint32_t 0x1F96 PNS_IF_REMOVE_PE_ENTITY_REQ
Data
ulApi uint32_t The API of the submodule associated with the PE entity.
usSlot uint16_t The Slot of the submodule associated with the PE entity.
usSubslot uint16_t The subslot of the submodule associated with the PE entity.
Table 180: PNS_IF_REMOVE_PE_ENTITY_REQ–T – Remove PE Entity request

Packet structure reference

typedef PNS_IF_ADD_PE_ENTITY_REQ_DATA_T PNS_IF_REMOVE_PE_ENTITY_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_REMOVE_PE_ENTITY_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_REMOVE_PE_ENTITY_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_REMOVE_PE_ENTITY_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.18.2 Remove PE Entity confirmation

The protocol stack returns this packet to the application in order to confirm removing a PE entity.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F97 PNS_IF_REMOVE_PE_ENTITY_CNF
Table 181: PNS_IF_REMOVE_PE_ENTITY_CNF–T – Remove PE Entity confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_REMOVE_PE_ENTITY_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.19 Update PE Entity service

The Update PE Entity service is part of the PE ASE implementation of the PROFINET stack. The
application has to use this service to update the operational mode of a PE entity within the PE
ASE. The protocol stack will internally generate the PROFINET alarms associated with this
operation.
The protocol stack will validate the parameters of the packet and updates the operational mode if
the addressed submodule
 is plugged, and
 uses an PE entity.

Note: By default, all PE entity services are deactivated. In order to activate the PE entity
services, use the Set OEM Parameters service (page 82) with ulParamType set to 10.

6.4.19.1 Update PE Entity request

Packet description

Variable Type Value / Range Description

ulDest uint32_t 0x00000020 HIL_PACKET_DEST_DEFAULT_CHANNEL
ulLen uint32_t 9 Packet data length in bytes
ulCmd uint32_t 0x1F98 PNS_IF_UPDATE_PE_ENTITY_REQ
Data
ulApi uint32_t The API of the submodule associated with the PE entity.
usSlot uint16_t The slot of the submodule associated with the PE entity.
usSubslot uint16_t The subslot of the submodule associated with the PE entity.
bOperationalMode uint8_t 0 … 0xFF The current operational mode of the PE entity as defined by
PROFIenergy specification.
Table 182: PNS_IF_UPDATE_PE_ENTITY_REQ–T – Update PE Entity request

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_UPDATE_PE_ENTITY_REQ_DATA_Ttag
{
uint32_t ulAPI;
uint16_t usSlot;
uint16_t usSubslot;
uint8_t bOperationalMode;
} __HIL_PACKED_POST PNS_IF_UPDATE_PE_ENTITY_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_UPDATE_PE_ENTITY_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
PNS_IF_UPDATE_PE_ENTITY_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_UPDATE_PE_ENTITY_REQ_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.19.2 Update PE Entity confirmation

The protocol stack returns this packet to the application in order to confirm updating a PE entity.
The confirmation is be returned independently of associated PROFINET alarm processing, e.g.
before the required alarms have been issued.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet data length in bytes
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F99 PNS_IF_UPDATE_PE_ENTITY_CNF
Table 183: PNS_IF_UPDATE_PE_ENTITY_CNF–T – Update PE Entity confirmation

Packet structure reference

typedef HIL_EMPTY_PACKET_T PNS_IF_UPDATE_PE_ENTITY_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

6.4.20 Send Alarm service

The application can use this service to send a user specific alarm.

6.4.20.1 Send Alarm request

This packet causes the stack to send a user specific Alarm to the IO-Controller.

Packet description

Variable Type Value / Description

Range
ulDest uint32_t 0x0000002 HIL_PACKET_DEST_DEFAULT_CHANNEL
0
ulLen uint32_t 22 + n Packet data length in bytes.
n is the value of usLenAlarmData.
ulCmd uint32_t 0x1F5C PNS_IF_SEND_ALARM_REQ
Data
ulApi uint32_t The API the alarm belongs to.
ulSlot uint32_t The Slot the alarm belongs to.
ulSubslot uint32_t The Subslot the alarm belongs to.
hAlarmHandle uint32_t A user specific alarm handle. The application is free
to choose any value.
usAlarmType uint16_t Alarm type to generate see below
usUserStructId uint16_t 0x0000 .. The application always has to provide a User
0x7FFF, Structure Identifier. The PROFINET specification
0x8320 allows an application not to provide a User Structure
Identifier, which is not supported by the stack.
usAlarmDataLen uint16_t The length of the alarm data
1 … 172 Length supported by any IO-Controller.
173 … 1024 Length allowed by the specification but not
supported by any IO-Controller.
See parameter description below.
tAlarmData PNS_IF_ALARM_DATA_T The alarm data.
Table 184: PNS_IF_SEND_ALARM_REQ_T Send Alarm request

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 246/323
Packet structure reference
typedef enum {
PNS_IF_ALARM_TYPE_PROCESS = 0x0002,
PNS_IF_ALARM_TYPE_STATUS = 0x0005,
PNS_IF_ALARM_TYPE_UPDATE = 0x0006,
PNS_IF_ALARM_TYPE_ISO_PROBLEM = 0x0010,
PNS_IF_ALARM_TYPE_UPLOAD_RETRIEVAL = 0x001E,
PNS_IF_ALARM_TYPE_MANUF_SPEC_START = 0x0020,
PNS_IF_ALARM_TYPE_MANUF_SPEC_END = 0x007F,
} PNS_IF_ALARM_TYPE_E;

typedef enum {
PNS_IF_ALARM_USER_STRUCTURE_ID_MANUF_SPEC_STAR = 0x0000,
PNS_IF_ALARM_USER_STRUCTURE_ID_MANUF_SPEC_END = 0x7FFF,
} PNS_IF_ALARM_USER_STRUCTURE_ID_E;

/** Structure definition of Record data objects.

* These data are commissioning parameters which shall be permanently stored at the IO
Controller or IO Supervisor.
* Record data objects which are part of the GSDML file and conveyed from the engineering
system shall not be part of Upload and retrieval records */
typedef __HIL_PACKED_PRE struct PNS_IF_UPLOAD_RETRIEVAL_RECORD_DATA_Ttag
{
uint32_t ulRecordIndex;
uint32_t ulRecordLength;
}__HIL_PACKED_POST PNS_IF_UPLOAD_RETRIEVAL_RECORD_DATA_T;

/* Upload & Retrieval sub-Alarm type */

typedef enum PNS_IF_ALARM_UPLOADT_RETRIEVAL_SUBTYPE_Etag
{
PNS_IF_ALARM_UPLOAD_SELECTED_RECORDS = 0x0001,
PNS_IF_ALARM_RETRIEVAL_SELECTED_RECORDS = 0x0002,
PNS_IF_ALARM_RETRIEVAL_ALL_RECORDS = 0x0003,
} PNS_IF_ALARM_UPLOADT_RETRIEVAL_SUBTYPE_E;

/** Structure definition of Upload & Retrieval alarm item data .*/
typedef __HIL_PACKED_PRE struct PNS_IF_UPLOAD_RETRIEVAL_DATA_Ttag
{
/** Alarm subtype see \ref PNS_IF_ALARM_UPLOADT_RETRIEVAL_SUBTYPE_Etag*/
uint8_t bAlarmSubtype;
/** This part of Upload & Retrieval alarm data has a dynamic structure.
* It shall contain device specific records data.
* The Length of this structure will be derived from usAlarmDataLen */
PNS_IF_UPLOAD_RETRIEVAL_RECORD_DATA_T tRecords[];
}__HIL_PACKED_POST PNS_IF_UPLOAD_RETRIEVAL_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_PROCESS_ALARM_CHANNEL_DATA_Ttag

{
/* Channel number issuing the process alarm */
uint16_t usChannelNum;
/* Channel properties */
uint16_t usChannelProp;
/* Reason for process alarm */
uint16_t usReason;
/* Extended Reason for process alarm */
uint16_t usExtReason;
/* Additional Value */
uint8_t abReasonAddValue[128]; /* hint: no additional reason is coded with length 4 and
value 00:00:00:00 */
} __HIL_PACKED_POST PNS_IF_PROCESS_ALARM_CHANNEL_DATA_T;

/* alarm data */
typedef union PNS_IF_ALARM_DATA_Ttag
{
uint8_t abManufacturerData[PNS_IF_MAX_ALARM_DATA_LEN]; /* ATTENTION: Recommended not to
use more than 172 byte of data for compatibility reasons */
PNS_IF_UPLOAD_RETRIEVAL_DATA_T tUploadRetrieval;
PNS_IF_PROCESS_ALARM_CHANNEL_DATA_T tProcessAlarmChannelData; /* only used for USI
0x8320 */

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 247/323
}PNS_IF_ALARM_DATA_T;

/* Request packet */
typedef __HIL_PACKED_PRE struct PNS_IF_SEND_ALARM_REQ_DATA_Ttag
{
/* API of the submodule that issues the alarm */
uint32_t ulApi;
/* Slot of the submodule that issues the alarm */
uint32_t ulSlot;
/* Subslot of the submodule that issues the alarm */
uint32_t ulSubslot;
/* AlarmHandle freely chosen by application for identification purpose */
uint32_t hAlarmHandle;
/* AlarmType to generate, see PNS_IF_USER_ALARMTYPES_E */
uint16_t usAlarmType;
/* User structure identifier of the alarm will only be used in case
* of manufacturer specific alarm type */
uint16_t usUserStructId;
/* length of the alarm data (thus length of content in abAlarmData) */
uint16_t usAlarmDataLen;
/* alarm data */
PNS_IF_ALARM_DATA_T tAlarmData;
} __HIL_PACKED_POST PNS_IF_SEND_ALARM_REQ_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SEND_ALARM_REQ_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_SEND_ALARM_REQ_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SEND_ALARM_REQ_T;
Valid values for usAlarmType:

Symbolic Name Numerical Description

Value
PNS_IF_ALARM_TYPE_PROCESS 0x0002 Process alarm notification
PNS_IF_ALARM_TYPE_STATUS 0x0005 status change notification
PNS_IF_ALARM_TYPE_UPDATE 0x0006 Change of parameter notification
PNS_IF_ALARM_TYPE_ISO_PROBLEM 0x0010 Isochronous Mode Problem Notification
PNS_IF_ALARM_TYPE_UPLOAD_RETRIEV 0x001E Alarm notification for upload and storage of device
AL specific record data objects
PNS_IF_ALARM_TYPE_MANUF_SPEC 0x0020 - manufacturer specific alarm types
0x007F
Reserved other Reserved for future usage
Table 185: Valid values for Alarm Type

Valid values for usUserStructId:

Symbolic Name Numerical Value Description
PNS_IF_ALARM_USER_STRUCTURE_ID_M 0x0000 – 0x7FFF Manufacturer-specific structure
ANUF_SPEC
- 0x8320 Process Alarm with channel coding.
Only if usAlarmType =
PNS_IF_ALARM_TYPE_PROCESS.
other Reserved usUserStructId will in case of upload and
retrieval alarm type automatically assigned by
the stack.
Table 186: Valid values for User Structure Identifier

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Note: The PROFINET specification guarantees a total alarm length of 200 byte to be
exchangeable between IO-Device and IO-Controller. IO-Controllers may support more
than 200 byte but the IO-Device cannot rely on it. For this reason, we highly
recommend to you not to generate any alarm that exceeds 200 bytes.

The 200 bytes include 28 bytes for submodule and protocol-related parameters. This means that
the pure application data including the User Structure Identifier is limited to 174 byte in this case.
Note that the User Structure Identifier is part of the 28 bytes and that it is already included in the
PNS_IF_SEND_PROCESS_ALARM_REQ_DATA_T structure and therefore should not be used with
alarm data length of more than 172 bytes.

tAlarmData

Variable Type Value / Description

Range
abManufacturerData uint8_t[1024] 1-3 Manufacturer-specific alarm data
tUploadRetrieval PNS_IF_UPLOAD_R Upload and retrieval alarm data.
ETRIEVAL_DATA_T Must be used in conjunction with usAlarmType =
PNS_IF_ALARM_TYPE_UPLOAD_RETRIEVAL
tProcessAlarmChan PNS_IF_PROCESS_ Process Alarm with channel coding.
nelData ALARM_CHANNEL_ Must be used in conjunction with
DATA_T usAlarmType = PNS_IF_ALARM_TYPE_PROCESS and
usUserStructId = 0x8320
Table 187: Alarm data definition

abManufacturerData
This parameter can be used to report optional manufacturer data. It shall only be used in
conjunction with following alarm types:
 Process alarm
 Status alarm
 Update alarm
 Isochronous mode problem alarm
 Manufacturer specific alarm

tUploadRetrieval
This parameter shall only be used if the alarm type is set to “Upload and Retrieval alarm”.
With this parameter, the application indicates the existence of device specific record objects that
shall be stored outside of IO Device or retrieval request of already stored record objects.

Variable Type Value / Range Description

bAlarmSubtype uint8_t 1-3 Alarm subtype of upload and retrieval
notification
tUploadRetrievalData PNS_IF_UPLOAD_RETRIEVAL The number of entries in the list is
_RECORD_DATA_T[1-127] determined by the packet length.
Table 188: Upload and Retrieval structure definition

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 249/323
Valid values are for bAlarmSubtype:
Symbolic Name Numerical Description
Value
PNS_IF_ALARM_UPLOAD_SLECTED_RECORDS 1 Shall be used to indicate the existence of
record data object, which shall be stored
outside of IO Device.
PNS_IF_ALARM_RETRIEVAL_SLECTED_RECORDS 2 Shall be used to send a retrieval request for
specifc record objects
PNS_IF_ALARM_RETRIEVAL_ALL_RECORDS 3 Shall be used to send a retrieval request for all
stored record objects
Table 189: Valid value for Upload and Retrieval Alarm Subtype

Variable Type Value / Range Description

ulRecordIndex uint32_t 0x00000000 - Index of record data object that shall be uploaded or retrieval
0x0000FFFF
ulRecordLength uint32_t 0x00000001- Length of record data object that shall be uploaded or retrieval
0xFFFFFFFF
Table 190: Upload and Retrieval Record Data Description

Process Alarm with channel coding

To send a Process Alarm with channel coding, the application has to use usAlarmType =
PNS_IF_ALARM_TYPE_PROCESS and usUserStructId = 0x8320. This coding allows the OEM to
describe the alarm content in the GSDML file.

Variable Type Value / Range Description

usChannelNum uint16_t See section Add Channel Channel number issuing the process alarm.
Diagnosis service (page 219).
usChannelProp uint16_t See section Add Channel Channel properties
Diagnosis service (page 219).
usReason uint16_t For values, see table below. Reason for process alarm.
usExtReason uint16_t For values, see table below. Extended Reason for process alarm.
abReasonAddValue[128] uint8_t For length and values, see table Reason additional values
below.
Table 191: Channel coding structure definition

Value for usReason:

Value Description Text
0x0000 Reserved Unknown reason
0x0001 Internal gate opening (Gate start) Counter or way measurement starts
Internal gate opening (Gate start)
0x0002 Internal gate closing (Gate stop) Counter or way measurement stops
Internal gate closing (Gate stop)
0x0003 Overflow (High counting limit Counter or way measurement register Overflow (High counting
violated) limit violated)
0x0004 Underflow (Low counting limit Counter or way measurement register Underflow (Low counting
violated) limit violated)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Value Description Text

0x0005 Compare event for DQ0 has Compare of counter or way measurement register with a
occured parameterized value “DQ0” (or “first digital output”) shows hit
(Compare event for “first digital output” has occurred)
0x0006 Compare event for DQ1 has Compare of counter or way measurement register with a
occured parameterized value “DQ1” (or “second digital output”) shows hit
(Compare event for “second digital output” has occurred)
0x0007 Zero pass Counter or way measurement signed register hits or passes
zero (Zero pass)
0x0008 New capture value available New capture value available
0x0009 Synchronization of the counter by Counter or way measurement register value is set by an external
an external signal signal (Synchronization of the counter by an external signal)
0x000A Direction reversal Counter or way measurement register changes counting
direction (Direction reversal)
0x000B – 0x000F Reserved Unknown reason
0x0010 Rising edge The digital channel detects a rising edge (Rising edge)
0x0012 Falling edge The digital channel detects a falling edge (Falling edge)
0x0013 Upper user limit 1 exceeded The parameterized compare value 1 for the channel is exceeded
(Upper user limit 1 exceeded)
0x0014 Lower user limit 1 undershot The parameterized compare value 1 for the channel is
undershot (Lower user limit 1 undershot)
0x0015 Upper user limit 2 exceeded The parameterized compare value 2 for the channel is exceeded
(Upper user limit 2 exceeded)
0x0016 Lower user limit 2 undershot The parameterized compare value 2 for the channel is
undershot (Lower user limit 2 undershot)
0x0017 Upper user limit 3 exceeded The parameterized compare value 3 for the channel is exceeded
(Upper user limit 3 exceeded)
0x0018 Lower user limit 3 undershot The parameterized compare value 3 for the channel is
undershot (Lower user limit 3 undershot)
0x0019 Upper user limit 4 exceeded The parameterized compare value 4 for the channel is exceeded
Upper user limit 4 exceeded
0x001A Lower user limit 4 undershot The parameterized compare value 4 for the channel is
undershot (Lower user limit 4 undershot)
0x001B – 0x00FF Reserved Unknown reason
0x0100 – 0x7FFF Manufacturer specific Manufacturer specific reason
0x8000 – 0x8FFF Reserved Reserved
0x9000 – 0x9FFF Reserved for profiles Profile specific reason
0xA000 – 0xFFFF Reserved Reserved
Table 192: Values for usReason

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Application interface 251/323
Value for usExtReason:
Value Description Text
0x0000 Unspecified Unspecified
0x0001 – 0x7FFF Manufacturer specific Manufacturer specific reason detail
0x8000 – 0x8FFF Reserved Reserved
0x9000 – 0x9FFF Reserved for profiles Profile specific reason detail
0xA000 – 0xFFFF Reserved Reserved
Table 193: Values for usExtReason

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Length Value Description

0x04 0x00, 0x00, 0x00, 0x00 No additional information
Independent from usReason and usExtReason.
other Definition depending on usReason and usExtReason
0x05 – 0x80 0x00 .. 0xFF (for each Definition depending on usReason and usExtReason
byte)
other - Reserved
Table 194: Length and values for abReasonAddValue

6.4.20.2 Send Alarm confirmation

This packet is returned to the application by the stack after the controller confirmed the alarm. The
reaction of the IO-Controller is reported to the application within the confirmation.

Packet description

Variable Type Value / Range Description

ulLen uint32_t 12 Packet data length in bytes (0 in case of error)
ulSta uint32_t See section Error codes and status codes on page 272.
ulCmd uint32_t 0x1F5D PNS_IF_SEND_ALARM_CNF
Data
ulReserved uint32_t Reserved
hAlarmHandle uint32_t The user specific alarm handle.
ulPnio uint32_t PROFINET error code consists of ErrCode, ErrDecode, ErrCode1
and ErrCode2. See section PROFINET status codes on page 294.
Table 195: PNS_IF_SEND_ALARM_CNF_T - Send Alarm confirmation

Packet structure reference

typedef __HIL_PACKED_PRE struct PNS_IF_SEND_ALARM_CNF_DATA_Ttag
{
uint32_t ulReserved ;
uint32_t hAlarmHandle;
/* Profinet error code, consists of ErrCode, ErrDecode, ErrCode1 and ErrCode2 */
uint32_t ulPnio;
} __HIL_PACKED_POST PNS_IF_SEND_ALARM_CNF_DATA_T;

typedef __HIL_PACKED_PRE struct PNS_IF_SEND_ALARM_CNF_Ttag

{
/** packet header */
HIL_PACKET_HEADER_T tHead;
/** packet data */
PNS_IF_SEND_ALARM_CNF_DATA_T tData;
} __HIL_PACKED_POST PNS_IF_SEND_ALARM_CNF_T;

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

7 Linkable Object Module (LOM)

Accessing the protocol stack is only possible with access via DPM of loadable firmware.
Linkable Object Module is not available for PROFINET IO Device.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8 PROFINET Certification
Before any PROFINET device appears on the market it has to pass PROFINET certification tests
to prove the conformance according to one of the defined PROFINET conformance classes (A, B
or C).
To achieve conformance class A (without SNMP) or B (with SNMP) the PROFINET Real Time
(RT) protocol behavior and the behavior on network load have to be tested on the device.
If a PROFINET device shall conform to conformance class C, it has to fulfill some additional
requirements including PROFINET Isochronous Real Time (IRT). This chapter explains common
requirements to a PROFINET device for all types of the certification tests.
For detailed information about PROFINET Certification please also refer to reference [3].

8.1 RT tests (Conformance class A, B and C)

8.1.1 Description
The common PROFINET RT certification tests have to be passed by all IO Device
implementations. These test cases cover the following functionality
 basic state machine behavior
 different parts of protocol (coding)
 reaction of device on erroneous configurations and situations
 acyclic services
 cyclic data and data-status (IOXS)

8.1.2 General requirements for RT tests

In order to execute all test cases the examiner in the certification laboratory should have a
possibility to trigger alarms (diagnosis or process alarms) on a device. For example additional push
button causes an alarm, “magic” sequence of push buttons, deliberate shorting of outputs and so
on. This is required if the device generates alarm / diagnosis at runtime. If no alarm and no
diagnosis are generated at runtime, these tests can be skipped.
It is recommended (but not required) to have a possibility to change input values on a device. For
example set some inputs of an IO-Device to “HI-level”, change measurement values if it is a sensor
and so on.
A small informal paper describing how to trigger alarms and change IO Data needs to be given to
the certification laboratory together with the device.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8.1.3 Common checks before certification (GSDML)

The device has to be consistent with its own GSDML file. The “DeviceID” and “VendorID” in the
GSDML shall be the same that was used in Set Configuration service (page 69) for fields
“PNS_IF_DEVICE_PARAMETER_T::ulVendorId” and “PNS_IF_DEVICE_PARAMETER_T::
ulDeviceId”, or used in data base (if the stack configured with data base), or used in tag list (if
according tag was enabled in firmware). The vendor name shall also be correct:

Figure 46: Vendor and device identification in the GSDML file

In addition it is required that the OrderNumber, HardwareRelease and SoftwareRelease from the
GSDML file match the configuration of the PROFINET IO-Device. The values are contained in
PNS_IF_DEVICE_PARAMETER_T.
If a new product is created based on Hilscher GmbH reference GSDML files, it is highly
recommended to remove all non-matching DAPs from the new GSDML file. Otherwise it may lead
to confusion why a new product already has several DAPs inside the GSDML file.

8.1.4 Basic application behavior

If the application respects section Requirements to the application (page 58), no additional
requirements for certification apply. If section is not respected, certification may fail due to
insufficient application behavior.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8.2 IRT tests (Conformance class C only)

8.2.1 Description
The common PROFINET IRT certification tests have to be passed by all IO Device
implementations. These test cases cover the following functionality
 basic IRT-related state machine behavior
 synchronization related tests
 different parts of protocol (coding)
 reaction of the device on erroneous configurations and situations
 cyclic data and data status (IOXS)

8.2.2 General requirements for IRT tests

There are no special additional requirements besides those from the RT tests.

8.2.3 Hardware requirements for IRT tests

To evaluate the synchronization capability of the device it is required to offer an external
synchronization pin to the examiner in the certification laboratory. The synchronization jitter of this
pin needs to be verified. This pin shall be present for the device used during certification test. If this
pin is not available at the devices used in the field, this is accepted.

8.2.4 Software requirements for IRT tests

Regarding application handling nothing special needs to be taken in account. So for certification no
additional software requirements exist compared to the ones defined for RT tests.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8.2.5 GSDML requirements for IRT tests

The GSDML file needs to contain the required IRT related keywords. Please refer to Hilscher
reference GSDML files for details. The following listing will just briefly name the required keywords,
there may be more keywords required by GSDML checker tool.
 InterfaceSubmoduleItem
 SupportedRT_Classes="RT_CLASS_1;RT_CLASS_3"
 RT_Class3Properties
 ForwardingMode="Relative"
 MaxBridgeDelay="5500"
 MaxNumberIR_FrameData="256"
 StartupMode="Advanced;Legacy"
 SynchronisationMode
 MaxLocalJitter="50"
 SupportedRole="SyncSlave"
 SupportedSyncProtocols="PTCP"
 T_PLL_MAX="1000"
 RT_Class3TimingProperties
 ReductionRatio="1 2 4 8 16"
 SendClock="8 16 32 64 128"

netX 90
 PortSubmoduleItem
 MaxPortRxDelay="220"
 MaxPortTxDelay="116"

netX 4000
 PortSubmoduleItem
 MaxPortRxDelay="340"
 MaxPortTxDelay="92"

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8.3 Network load tests

8.3.1 Description
Starting with certification for PROFINET specification V2.3 (expressed in GSDML file of the IO-
Device by using PNIO_Version=”V2.31”) it is mandatory to execute special network load tests
during certification.
These tests verify the correct behavior of the PROFINET IO device during different network loads.
The following classes of network load are defined:
 network load class I
 network load class II
 network load class III
The device has to pass at least the tests for “network load class I” to fulfill the certification
requirements.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

8.4 How to handle I&M Data

In order to fulfill PROFINET conformance needs, any PROFINET IO device should be able to
handle the I&M0, I&M1, I&M2, I&M3 and I&M0 Filter data.

8.4.1 Overview
Identification & Maintenance (I&M) is an integral part of each PROFINET Device implementation. It
provides standarized information about a device and its parts. The I&M Information is accessible
through PROFINET Record Objects and is always bound to a submodule belonging to the item to
be described. An item means here the PROFINET Device itself or a part of this device e.g. a
plugable module for modular devices. Submodules can provide own I&M objects or share the I&M
objects of other submodules. The I&M objects can be grouped into three kinds of information as
described as follows.

I&M0
I&M0 is a read only information which describes the associated item. The following fields are
defined:

Field Description Usage Hints

Vendor ID The PNO vendor ID of the associated item. This is the vendor ID of the manufacturer of the item and
E.g. the vendor of the device or the vendor of not the vendor ID of the PROFINET protocol vendor. Do
a pluggable module/submodule. not use the Hilscher vendor ID.
Order ID The order ID of the associated item. Order ID as defined by the manufacturer of the item. Must
be equal to any order ID markings on the item itself.
Serial Number The serial number of the associated item. Must be an unique serial number associated with the
item. Must be equal to any serial number markings on the
item itself.
Hardware The revision of the hardware of the item. Must be equal to any hardware revision markings on the
Revision item itself.
Software The software revision of the item. This is the software version of the whole item including
Revision the PROFINET Protocol implementation and the
Application. This version is managed by the manufacturer
of the item. It must be changed whenever a part of the
software within the item (including the PROFINET
Protocol implementation if it is part of the item) changes.
This is not the version number of the PROFINET Protocol
implementation. Do not use the Hilscher Version of the
PROFINET Protocol implementation.
Revision Counts the changes of I&M1 to I&M4 objects -
Counter
Profile ID The Profile of the item if applicable.- -
Profile Specific
Type
Supported I&M Bitmask defining which I&M objects are -
objects supported by this item.
Table 196: Fields of I&M0

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
PROFINET Certification 260/323
I&M1 to I&M4
The I&M1 to I&M4 objects provide a non-volatile storage for PROFINET engineering related
information. This information is typically generated by the engineering software and stored within
the objects at engineering time. The information must be stored by the device in non-volatile
memory. The objects must be stored physically within the associated item. This means in
particular, if a plugable module is removed from one backplane and plugged into another
backplane, it must deliver the same I&M1 to I&M4 information as stored before.

I&M5
Finally, the I&M5 record provides information about the PROFINET protocol implementation itself.
It is quite similar to I&M0 but describes the PROFINET protocol implementation instead. Thus it is
typically handled by the PROFINET Protocol implementation itself.

I&M0 filter
Addtionally to these submodule specific I&M objects, each PROFINET device must support the
global I&M Filter Data object, the so called "I&M0FilterData". This is a read-only object which is
used to determine which submodules are associated with dedicated I&M objects.
For certification it is required that at exactly one is marked as “device representative” in I&M0 Filter
Data object.

8.4.2 Structure and access paths of I&M objects

The following figure shows the structural organization of I&M Records within a device and the
access paths:

Figure 47: Structural organization of I&M records within a Device and the access paths
Structural organization of I&M Records within a Device and the Access Paths
According to I&M a submodule can be characterized as follows:
 Module Representative: The submodule is a representative for the module. This means
that the submodule provides the I&M information of the superordinate module.
 Device Representative: The submodule is a representative for the device. In this case the
submodule provides the I&M information of the superordinate device. Exactly one submodule
of the device must have this property. Typical the DAP submodule is chosen for this purpose.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
PROFINET Certification 261/323
 Default: The submodule only represents itself or does not have any I&M information at all. In
the latter case only I&M Read Access is allowed and the Read will deliver the I&M
information of the Module Representative or the Device Representative.
When reading the I&M objects of a submodule the following order is used to deliver the requested
data:
1. If the submodule provides an own I&M0 object, the I&M read access will deliver the
submodule's I&M objects
2. If the submodule has no own I&M0 object and the superordinate module has a module
representative, the module representative's I&M objects will be delivered.
3. If the submodule has no own I&M0 object and the superordinate module has no
representativ the device representatives's I&M objects will be delivered.
In contrast to this, writing I&M1 to I&M4 objects is only possible on the submodules associated with
the I&M objects itself.
Finally, the I&M0 Filter Data object contains the information which submodules are associated with
their own I&M data, which submodules represent their superordinate module and which submodule
represents the whole device. This object is global and a read-only object and it is not associated
with any submodule.

8.4.3 Usage of I&M: Stack or application

The PROFINET IO-Device stack provided by Hilscher supports two modes of operation with I&M:
 the stack handles I&M requests or
 the application handles I&M requests.
For simple applications, the stack provides I&M0 to I&M5 objects within the DAP submodule. In
this case, the I&M is fully handled by the stack without any interaction with the application.
If a more complex I&M structure is required, the stack can forward I&M requests to the application.
In this case, the application must handle all I&M objects.
The application must handle the I&M data
 in case the configuration contains a submodule with API != 0 or
 in case a submodule with API != 0 is plugged during runtime (PlugSubmodule service).
Bit D8 of the system flags sets the mode, see section Set Configuration service on page 69.

Mode “Stack handles I&M requests”: If the stack is configured to handle the I&M (internally), the
following parameters will be used within the I&M0 object:
Parameter Source of value
Vendor ID Vendor ID in Set Configuration service or configuration database.
Can be overwritten by tag list if configuration database is used.
Order ID Order ID in Set Configuration service or configuration database.
Serial Number The serial number is used from the Device Data Provider (read from the Flash Device Label
during startup). If required, the application can change the serial number using Device Data
Provider services.
Hardware Revision Hardware revision in Set Configuration Service. If a configuration database is used the
hardware revision from Security Memory / Flash device label is used. This is the hardware
revision of the Hilscher communication module if applicable.
Software Revision Software revision in Set Configuration Service. If a Configuration Database is used the
PROFINET Protocol implementations software revision will be used.
Revision Counter Internally stored and incremented with each change of I&M1 to I&M4.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Parameter Source of value

Profile ID The default value '0x00' (Manufacturer-specific) will be used.
Profile Specific Type The default value '0x05' (Generic Device) will be used.
Supported I&M objects Defaults to I&M0 to I&M5.
Can be changed to a desired value using Set OEM Parameters service.
Table 197: Parameters of the I&M0 object

Mode “Application handles I&M requests”: If the mode ”Application handles I&M requests“ is
set, all I&M requests will be forwarded via PROFINET to the application using the ”I&M Read“ and
”I&M Write“ service. The application must store the data of I&M write services permanently, so that
the I&M1 to I&M4 objects and the I&M0 revision counter can be recovered after a power cycle. I&M
0-3 is supported on the DAP submodule (Slot 0, subslot 1) by default.
The application must fill the I&M0 Filter data structure with a list of the submodules that are
associated with dedicated I&M data. Exactly one of these submodules must be characterized as
device representative. Characterization as a module representative is optional and sensible only if
the module has more than one submodule. Then the stack will internally create up to three lists
based on the information provided by the application.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

9 Resource and feature configuration via tag list

Loadable firmware supports the feature to configure firmware parameters. During startup of the
firmware, it reads the configuration parameters from the tag list of the firmware.
The firmware reads the tag list parameters
 to customize the resource allocation, and
 to configure features.
For devices with low memory designs e.g. no external SDRAM at netX, the settings of these
parameters allows you different application use cases.

9.1 PROFINET IO-Device V4 tag list

Note: Despite the allowed parameter value ranges in the tables of this section, additional
limitations arise from the available RAM memory. The full parameter value range might
not be available for all devices and firmware.

9.1.1 LED tag list parameter

Tag list parameters to adjust the LED behavior to the hardware.

Tag list Parameter / Tag Value Description

LED: Identifier COM0_GREEN Identifier name (Fixed value).
COM0_GREEN
Ressource Type PIO (Default), GPIO The type of I/O (PIO, GPIO) used to control this LED
Pin Number 0 (default), 1, 2, 3, … The number of the pin the LED is connected to.
Max.
Max. value depends on
hardware
Polarity normal (default), inverted The polarity of the LED: Normal or inverted.
LED: Identifier COM0_RED Identifier name (Fixed value).
COM0_RED
Ressource Type PIO (Default), GPIO The type of I/O (PIO, GPIO) used to control this LED
Pin Number 0, 1 (default), 2, 3, … The number of the pin the LED is connected to.
Max.
Max. value depends on
hardware
Polarity normal (default), inverted The polarity of the LED: Normal or inverted.
LED: Identifier COM1_GREEN Identifier name (Fixed value).
COM1_GREEN
Ressource Type PIO (Default), GPIO The type of I/O (PIO, GPIO) used to control this LED
Pin Number 0, 1, 2 (default), 3, … The number of the pin the LED is connected to.
Max.
Max. value depends on
hardware
Polarity normal (default), inverted The polarity of the LED: Normal or inverted.
LED: Identifier COM1_RED Identifier name (Fixed value).

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Tag list Parameter / Tag Value Description

COM1_RED Ressource Type PIO (Default), GPIO The type of I/O (PIO, GPIO) used to control this LED
Pin Number 0, 1, 2, 3 (default), … The number of the pin the LED is connected to.
Max.
Max. value depends on
hardware
Polarity normal (default), inverted The polarity of the LED: Normal or inverted.
Table 198: LED tag list parameter (PNSV4)

9.1.2 PROFINET Product Information tag list parameter

Tag list parameters to adjust the LED behavior to the hardware.

Tag list Parameter / Tag Value Description

PROFINET Vendor ID 1 to 65279 (0xFEFF). Vendor identification number of the manufacturer,
Product Default: 0x011E for which has been assigned to the vendor by the
Information Hilscher products. PROFIBUS Nutzerorganisation e. V.
(deactivated by
default) Device ID 1 to 65535 (0xFFFF) This is a fixed and unique identification number for
every product. The value is assigned by the
manufacturer/vendor.
Table 199: PROFINET Product Information tag list parameter (PNSV4)

9.1.3 Common tag list parameter

Tag list Parameter / Tag Value Description

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Tag list Parameter / Tag Value Description

Passive The firmware starts and sets the Device Data Provider mode
to “passive”. As long as the DDP mode is passive, the
application can change device-specific data (e.g. MAC
addresses) using the Device Data Provider Set service.
LWIP netident Enable netident Checked The support of the netIdent protocol is enabled.
behaviour
Unchecked The support of the netIdent protocol is disabled.
Phy enable Phy enable timeout 0 … 300 0 (default): The firmware does not enable the PHYs and waits
timeout after after startup to be configured. The PHYs will be enabled as soon as the
firmware startup firmware is configured.
1 … 300: Time the PHYs are disabled after firmware startup
(unit seconds). Afterwards the firmware activates the PHYs
with default settings. If the firmware gets a PHY configuration
before the timeout elapses, the firmware configures and
enables the PHYs. If the firmware gets a PHY configuration
after the timeout elapses, the PHYs will be reparametrized
(possible link loss).
LWIP ports for IP Port 0 0 … 65535 0 (default): LWIP stack does not receive Multicast frames as
0.0.0.0 long as the “LWIP stack” is not configured.
Port 1 0 … 65535
1 … 65535: IP Port to receive Multicast frames as long as the
“LWIP stack” is not configured.
Socket API Number of Socket API 1 …8 The number of Socket API services that are be handled in
Quantity Services at DPM level default: 4 parallel at DPM mailbox level.
Structure
Number of Sockets for 1 … 64 The number of IP sockets of integrated IP stack that the
Socket API usage default: 8 application wants to use in parallel.

Table 200: Tag list parameter (PNSV5)

9.1.4 PROFINET tag list parameter

Parameter Value range Description

Number of configurable 1 … 1000 Maximum number of I/O submodules available for the application
submodule This number does not include the DAP and PDEV submodules as these
are always available.
The tag list parameter "Number of configurable submodules" defines the
total number of usable submodules. If the application uses max. 2 APIs,
the "Number of configurable submodules" can be used. Each further API
reduces the total number of usable submodules by 1.
Example
32 submodules and 2 APIs: No reduction of submodules, i.e. total number
is 32.
32 submodules and 4 APIs: Reduction of 2 submodules, i.e. total number
is 30.
Minimum size of a RPC 4 … 64 Minimum allocation size for each RPC buffer in KByte
buffer By default, the stack calculates the required RPC buffer size depending
on other parameters and the requirements of the PROFINET specification.
In case, an application implements large and application-specific record
objects which includes the Asset Management feature, this setting
enlarges the buffer size to hold these objects.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Parameter Value range Description

Number of additional IO 0…7 Number of additional IO connections
connections This parameter relates to the Shared Device feature. If set to 0, Shared
Device is not supported.
The value of this parameter has an influence on the GSDML file provided
with the product. The GSDML parameter "NumberOfAR" needs to be set
to the value of this parameter plus 1.
Special handling for firmware including System Redundancy:
Setting this parameter to 0 still allows using S2 redundancy with 2
redundant IO-Controllers. Shared Device with 2 non-redundant IO-
Controllers is not supported in this case. This represents an IO-Device
supporting S2 redundancy but without Shared Device. In this special case,
the GSDML parameter "NumberOfAR" needs to be set to value 2.
Setting this parameter to 1 (or higher) activates Shared Device plus S2
redundancy in the firmware. In this case, the default rule for GSDML
parameter "NumberOfAR" applies and needs to be set to this value plus 1.
Number of parallel Read 1…8 Maximum number of parallel Read Implicit Requests
Implicit Requests In addition to IO connections, an IO Device supports reading record
objects via the network used by commissioning, monitoring and
maintenance tools to retrieve information from an IO Device. This
parameter configures the maximum number of supported Read Implicit
Requests at a time.
Number of parallel DA ARs 0, 1 Number of parallel Device Access ARs
Enables the Device Access feature and allows a commissioning tools for
example read and write access to record objects.
0 - Device Access disabled
1 - Device Access enabled
GSDML: The value of this parameter has an influence on the GSDML file
of the device.
Number of available 0 … 1000 Number of available diagnosis buffers entries the application requires at
diagnosis buffers most
Devices have implemened a diagnosis database which contains
information about problems or errors e.g. short circuit on one output. Each
entry in this database is associated with a particular submodule. One
submodule can have multiple entries.
Table 201: Tag list parameter (PNSV5)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

9.2 PROFINET IO-Device V5 tag list

9.2.1 Common tag list parameter

Tag list Parameter / Tag Value Description

Remanent Data Remanent Data stored Disabled Communication firmware stores remanent data (default).
Responsibility by Host
Enabled Application stores remanent data. For a description, see
section Remanent data handling on page 60.
Ethernet NDIS Enable NDIS Support Disabled NDIS support is disabled (default).
Support
Enabled NDIS support is enabled.
servX TCP Port Webserver TCP Port 0 … 65535 Configures the port number for the web server.
Number Number 80 = default port number,
0 = web server is deactivated,
If changed, use a valid port number.
UART UART number 0 UART/serial port 0 (not changeable).
Diagnostics
Interface Enable Unchecked Interface is disabled.
Checked Interface is enabled.
This interface is not usable for the APP CPU.
DDP Mode after DDP mode after Active The firmware starts and sets the Device Data Provider mode
firmware startup firmware startup to “active” (default). The firmware will use the device-specific
data from the Device Data Provider. The application cannot
change device-specific data.
Passive The firmware starts and sets the Device Data Provider mode
to “passive”. As long as the DDP mode is passive, the
application can change device-specific data (e.g. MAC
addresses) using the Device Data Provider Set service.
LWIP netident Enable netident Checked The support of the netIdent protocol is enabled.
behaviour
Unchecked The support of the netIdent protocol is disabled.
Phy enable Phy enable timeout 0 … 300 0 (default): The firmware does not enable the PHYs and waits
timeout after after startup to be configured. The PHYs will be enabled as soon as the
firmware startup firmware is configured.
1 … 300: Time the PHYs are disabled after firmware startup
(unit seconds). Afterwards the firmware activates the PHYs
with default settings. If the firmware gets a PHY configuration
before the timeout elapses, the firmware configures and
enables the PHYs. If the firmware gets a PHY configuration
after the timeout elapses, the PHYs will be reparametrized
(possible link loss).
LWIP ports for IP Port 0 0 … 65535 0 (default): LWIP stack does not receive Multicast frames as
0.0.0.0 long as the “LWIP stack” is not configured.
Port 1 0 … 65535
1 … 65535: IP Port to receive Multicast frames as long as the
“LWIP stack” is not configured.
Table 202: Tag list parameter (PNSV5)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Resource and feature configuration via tag list 268/323
9.2.2 PROFINET tag list parameter
Parameter Value range Description
Number of configurable 1 … 1000 Maximum number of I/O submodules available for the application
submodule This number does not include the DAP and PDEV submodules as these
are always available.
The tag list parameter "Number of configurable submodules" defines the
total number of usable submodules. If the application uses max. 2 APIs,
the "Number of configurable submodules" can be used. Each further API
reduces the total number of usable submodules by 1.
Example
32 submodules and 2 APIs: No reduction of submodules, i.e. total number
is 32.
32 submodules and 4 APIs: Reduction of 2 submodules, i.e. total number
is 30.
Minimum size of a RPC 4 … 64 Minimum allocation size for each RPC buffer in KByte
buffer By default, the stack calculates the required RPC buffer size depending
on other parameters and the requirements of the PROFINET specification.
In case, an application implements large and application-specific record
objects which includes the Asset Management feature, this setting
enlarges the buffer size to hold these objects.
Number of additional IO 0…7 Number of additional IO connections
connections This parameter relates to the Shared Device feature. If set to 0, Shared
Device is not supported.
The value of this parameter has an influence on the GSDML file provided
with the product. The GSDML parameter "NumberOfAR" needs to be set
to the value of this parameter plus 1.
Special handling for firmware including System Redundancy:
Setting this parameter to 0 still allows using S2 redundancy with 2
redundant IO-Controllers. Shared Device with 2 non-redundant IO-
Controllers is not supported in this case. This represents an IO-Device
supporting S2 redundancy but without Shared Device. In this special case,
the GSDML parameter "NumberOfAR" needs to be set to value 2.
Setting this parameter to 1 (or higher) activates Shared Device plus S2
redundancy in the firmware. In this case, the default rule for GSDML
parameter "NumberOfAR" applies and needs to be set to this value plus 1.
Number of parallel Read 1…8 Maximum number of parallel Read Implicit Requests
Implicit Requests In addition to IO connections, an IO Device supports reading record
objects via the network used by commissioning, monitoring and
maintenance tools to retrieve information from an IO Device. This
parameter configures the maximum number of supported Read Implicit
Requests at a time.
Number of parallel DA ARs 0, 1 Number of parallel Device Access ARs
Enables the Device Access feature and allows a commissioning tools for
example read and write access to record objects.
0 - Device Access disabled
1 - Device Access enabled
GSDML: The value of this parameter has an influence on the GSDML file
of the device.
Number of available 0 … 1000 Number of available diagnosis buffers entries the application requires at
diagnosis buffers most
Devices have implemened a diagnosis database which contains
information about problems or errors e.g. short circuit on one output. Each
entry in this database is associated with a particular submodule. One
submodule can have multiple entries.
Table 203: Tag list parameter (PNSV5)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Resource and feature configuration via tag list 269/323
Note: Despite the allowed parameter value ranges in the table above, additional limitations
arise from the available RAM memory. The full parameter value range might not be
available for all devices and firmware.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

10 GSDML file adaption for System Redundancy

This section describes the GSDML file adaption in case the System Redundancy and/or Dynamic
Reconfiguration features are used.

10.1 Parameter Begin

The keyword PrmBeginPrmEndSequenceSupported had to be defined to enable the PrmBegin
sequence.

Note: The keyword PrmBeginPrmEndSequenceSupported has to be present and set to

True if System Redundancy is enabled.

10.2 System Redundancy

To enable the System Redundancy feature, the GSDML file has to contain the following keywords:

Element Description Allowed values

DeviceType The type of redundant device. S2
MaxSwitchOverTime The time needed by IO Device Application to acknowledge [100 – 60000] ms
primary request including provider data update time, see Default : 1000 ms
[Switch to primary]
NumberOfAR To support System Redundancy, the device must support at 2
least two ARs. The value for NumberOfAR depends on the
tag list parameter “Number of additional IO connections”, see
section PROFINET tag list parameter on page 268.
NumberOfAR_Sets The maximum number of SR-AR sets. 1
RT_InputOnBackupAR_Supported Whether the device is able to send valid input data via the True
Backup SR-AR.
DataInvalidOnBackupAR_Supporte Whether the device accepts invalid output data via the True, False
d Backup SR-AR. Default : True
S2MaxInputOnBackupDelay The maximum time needed to report the real input data and [100-3000] ms
status data on the Backup SR-AR. Default : 100 ms
Available only if DataInvalidOnBackupAR_Supported = True
Table 204: Keywords

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

10.3 Dynamic Reconfiguration

In order to enable the Dynamic Reconfiguration feature, the GSDML file must define the keyword
CiR_Supported.
The keyword PDEV_CombinedObjectSupported must always be defined and set to True. COC
(Combined Object Container) record will be used to parameterize PDEV parameters at one go
within the scope of the Dynamic Reconfiguration.

Note: By default, all manufacturer-specific parameters defined in the GSDML file can be
changed during the Dynamic Reconfiguration sequence. However, if a change of
parameters leads to an I/O bump, the GSDML keyword ChangeableWithBump has to
be present and set to True.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11 Error codes and status codes

11.1 Common status codes

Hexadecimal value Definition and description

0x00000000 SUCCESS_HIL_OK
Operation succeeded.
0xC0000001 ERR_HIL_FAIL
Common error, detailed error information optionally present in the data area of packet.
0xC0000002 ERR_HIL_UNEXPECTED
Unexpected failure.
0xC0000003 ERR_HIL_OUTOFMEMORY
Ran out of memory.
0xC0000004 ERR_HIL_UNKNOWN_COMMAND
Unknown Command in Packet received.
0xC0000005 ERR_HIL_UNKNOWN_DESTINATION
Unknown Destination in Packet received.
0xC0000006 ERR_HIL_UNKNOWN_DESTINATION_ID
Unknown Destination Id in Packet received.
0xC0000007 ERR_HIL_INVALID_PACKET_LEN
Packet length is invalid.
0xC0000008 ERR_HIL_INVALID_EXTENSION
Invalid Extension in Packet received.
0xC0000009 ERR_HIL_INVALID_PARAMETER
Invalid Parameter in Packet found.
0xC000000A ERR_HIL_INVALID_ALIGNMENT
Invalid alignment.
0xC000000C ERR_HIL_WATCHDOG_TIMEOUT
Watchdog error occurred.
0xC000000D ERR_HIL_INVALID_LIST_TYPE
List type is invalid.
0xC000000E ERR_HIL_UNKNOWN_HANDLE
Handle is unknown.
0xC000000F ERR_HIL_PACKET_OUT_OF_SEQ
A packet index has been not in the expected sequence.
0xC0000010 ERR_HIL_PACKET_OUT_OF_MEMORY
The amount of fragmented data contained the packet sequence has been too large.
0xC0000011 ERR_HIL_QUE_PACKETDONE
The packet done function has failed.
0xC0000012 ERR_HIL_QUE_SENDPACKET
The sending of a packet has failed.
0xC0000013 ERR_HIL_POOL_PACKET_GET
The request of a packet from packet pool has failed.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0000014 ERR_HIL_POOL_PACKET_RELEASE
The release of a packet-to-packet pool has failed.
0xC0000015 ERR_HIL_POOL_GET_LOAD
The get packet pool load function has failed.
0xC0000016 ERR_HIL_QUE_GET_LOAD
The get queue load function has failed.
0xC0000017 ERR_HIL_QUE_WAITFORPACKET
The waiting for a packet from queue has failed.
0xC0000018 ERR_HIL_QUE_POSTPACKET
The posting of a packet has failed.
0xC0000019 ERR_HIL_QUE_PEEKPACKET
Peeking a packet from queue has failed.
0xC000001A ERR_HIL_REQUEST_RUNNING
Request is already running.
0xC000001B ERR_HIL_CREATE_TIMER
Creating a timer failed.
0xC000001C ERR_HIL_BUFFER_TOO_SHORT
Supplied buffer too short for the data.
0xC000001D ERR_HIL_NAME_ALREADY_EXIST
Supplied name already exists.
0xC000001E ERR_HIL_PACKET_FRAGMENTATION_TIMEOUT
The packet fragmentation has timed out.
0xC0000100 ERR_HIL_INIT_FAULT
General initialization fault.
0xC0000101 ERR_HIL_DATABASE_ACCESS_FAILED
Database access failure.
0xC0000102 ERR_HIL_CIR_MASTER_PARAMETER_FAILED
Master parameter cannot activated at state operate.
0xC0000103 ERR_HIL_CIR_SLAVE_PARAMTER_FAILED
Slave parameter cannot activated at state operate.
0xC0000119 ERR_HIL_NOT_CONFIGURED
Configuration not available
0xC0000120 ERR_HIL_CONFIGURATION_FAULT
General configuration fault.
0xC0000121 ERR_HIL_INCONSISTENT_DATA_SET
Inconsistent configuration data.
0xC0000122 ERR_HIL_DATA_SET_MISMATCH
Configuration data set mismatch.
0xC0000123 ERR_HIL_INSUFFICIENT_LICENSE
Insufficient license.
0xC0000124 ERR_HIL_PARAMETER_ERROR
Parameter error.
0xC0000125 ERR_HIL_INVALID_NETWORK_ADDRESS
Network address invalid.
0xC0000126 ERR_HIL_NO_SECURITY_MEMORY
Security memory chip missing or broken.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0000127 ERR_HIL_NO_MAC_ADDRESS_AVAILABLE
No MAC address available.
0xC0000128 ERR_HIL_INVALID_DDP_CONTENT
DeviceDataProvider contains invalid data.
0xC0000129 ERR_HIL_FIRMWARE_STARTUP_ERROR
Firmware startup failed. Check System logbook for details.
0xC000012A ERR_HIL_COMM_CHANNEL_STARTUP_ERROR
Communication Channel startup failed. Check Communication Channel logbook for details.
0xC000012B ERR_HIL_FIRMWARE_SPECIFIC_STARTUP_FAILED
An error occurred while starting firmware or protocol specific functionality.
0xC000012C ERR_HIL_INVALID_TAGLIST_CONTENT
While evaluating the firmware taglist an invalid taglist parameter was detected.
0xC000012D ERR_HIL_OPERATION_NOT_POSSIBLE_IN_CURRENT_STATE
The requested operation can not be executed in current state.
0xC000012E ERR_HIL_REMANENT_DATA_MISSING
The requested operation can not be executed because remanent data was not set correctly.
0xC000012F ERR_HIL_INVALID_DDP_OEM_SERIALNUMBER_CODING
The content of DDPs OEM field SerialNumber can not be converted for usage with current protocol
stack.
0xC0000130 ERR_HIL_INVALID_DDP_OEM_ORDERNUMBER_CODING
The content of DDPs OEM field OrderNumber can not be converted for usage with current protocol
stack.
0xC0000131 ERR_HIL_INVALID_DDP_OEM_HARDWAREREVISION_CODING
The content of DDPs OEM field HardwareRevision can not be converted for usage with current
protocol stack.
0xC0000132 ERR_HIL_INVALID_DDP_OEM_PRODUCTIONDATE_CODING
The content of DDPs OEM field ProductionDate can not be converted for usage with current
protocol stack.
0xC0000140 ERR_HIL_NETWORK_FAULT
General communication fault.
0xC0000141 ERR_HIL_CONNECTION_CLOSED
Connection closed.
0xC0000142 ERR_HIL_CONNECTION_TIMEOUT
Connection timeout.
0xC0000143 ERR_HIL_LONELY_NETWORK
Lonely network.
0xC0000144 ERR_HIL_DUPLICATE_NODE
Duplicate network address.
0xC0000145 ERR_HIL_CABLE_DISCONNECT
Cable disconnected.
0xC0000180 ERR_HIL_BUS_OFF
Bus Off flag is set.
0xC0000181 ERR_HIL_CONFIG_LOCK
Changing configuration is not allowed.
0xC0000182 ERR_HIL_APPLICATION_NOT_READY
Application is not at ready state.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0000183 ERR_HIL_RESET_IN_PROCESS
Application is performing a reset.
0xC0000200 ERR_HIL_WATCHDOG_TIME_INVALID
Watchdog time is out of range.
0xC0000201 ERR_HIL_APPLICATION_ALREADY_REGISTERED
Application is already registered.
0xC0000202 ERR_HIL_NO_APPLICATION_REGISTERED
No application registered.
0xC0000203 ERR_HIL_INVALID_COMPONENT_ID
Invalid component identifier.
0xC0000204 ERR_HIL_INVALID_DATA_LENGTH
Invalid data length.
0xC0000205 ERR_HIL_DATA_ALREADY_SET
The data was already set.
0xC0000206 ERR_HIL_NO_LOGBOOK_AVAILABLE
Logbook not available.
0xC0001000 ERR_HIL_INVALID_HANDLE
No description available - ERR_HIL_INVALID_HANDLE.
0xC0001001 ERR_HIL_UNKNOWN_DEVICE
No description available - ERR_HIL_UNKNOWN_DEVICE.
0xC0001002 ERR_HIL_RESOURCE_IN_USE
No description available - ERR_HIL_RESOURCE_IN_USE.
0xC0001003 ERR_HIL_NO_MORE_RESOURCES
No description available - ERR_HIL_NO_MORE_RESOURCES.
0xC0001004 ERR_HIL_DRV_OPEN_FAILED
No description available - ERR_HIL_DRV_OPEN_FAILED.
0xC0001005 ERR_HIL_DRV_INITIALIZATION_FAILED
No description available - ERR_HIL_DRV_INITIALIZATION_FAILED.
0xC0001006 ERR_HIL_DRV_NOT_INITIALIZED
No description available - ERR_HIL_DRV_NOT_INITIALIZED.
0xC0001007 ERR_HIL_DRV_ALREADY_INITIALIZED
No description available - ERR_HIL_DRV_ALREADY_INITIALIZED.
0xC0001008 ERR_HIL_CRC
No description available - ERR_HIL_CRC.
0xC0001010 ERR_HIL_DRV_INVALID_RESOURCE
No description available - ERR_HIL_DRV_INVALID_RESOURCE.
0xC0001011 ERR_HIL_DRV_INVALID_MEM_RESOURCE
No description available - ERR_HIL_DRV_INVALID_MEM_RESOURCE.
0xC0001012 ERR_HIL_DRV_INVALID_MEM_SIZE
No description available - ERR_HIL_DRV_INVALID_MEM_SIZE.
0xC0001013 ERR_HIL_DRV_INVALID_PHYS_MEM_BASE
No description available - ERR_HIL_DRV_INVALID_PHYS_MEM_BASE.
0xC0001014 ERR_HIL_DRV_INVALID_PHYS_MEM_SIZE
No description available - ERR_HIL_DRV_INVALID_PHYS_MEM_SIZE.
0xC0001015 ERR_HIL_DRV_UNDEFINED_HANDLER
No description available - ERR_HIL_DRV_UNDEFINED_HANDLER.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0001020 ERR_HIL_DRV_ILLEGAL_VECTOR_ID
No description available - ERR_HIL_DRV_ILLEGAL_VECTOR_ID.
0xC0001021 ERR_HIL_DRV_ILLEGAL_IRQ_MASK
No description available - ERR_HIL_DRV_ILLEGAL_IRQ_MASK.
0xC0001022 ERR_HIL_DRV_ILLEGAL_SUBIRQ_MASK
No description available - ERR_HIL_DRV_ILLEGAL_SUBIRQ_MASK.
0xC0001023 ERR_HIL_DRV_STATE_INVALID
Driver is in invalid state.
0xC0001100 ERR_HIL_DPM_CHANNEL_UNKNOWN
No description available - ERR_HIL_DPM_CHANNEL_UNKNOWN.
0xC0001101 ERR_HIL_DPM_CHANNEL_INVALID
No description available - ERR_HIL_DPM_CHANNEL_INVALID.
0xC0001102 ERR_HIL_DPM_CHANNEL_NOT_INITIALIZED
No description available - ERR_HIL_DPM_CHANNEL_NOT_INITIALIZED.
0xC0001103 ERR_HIL_DPM_CHANNEL_ALREADY_INITIALIZED
No description available - ERR_HIL_DPM_CHANNEL_ALREADY_INITIALIZED.
0xC0001120 ERR_HIL_DPM_CHANNEL_LAYOUT_UNKNOWN
No description available - ERR_HIL_DPM_CHANNEL_LAYOUT_UNKNOWN.
0xC0001121 ERR_HIL_DPM_CHANNEL_SIZE_INVALID
No description available - ERR_HIL_DPM_CHANNEL_SIZE_INVALID.
0xC0001122 ERR_HIL_DPM_CHANNEL_SIZE_EXCEEDED
No description available - ERR_HIL_DPM_CHANNEL_SIZE_EXCEEDED.
0xC0001123 ERR_HIL_DPM_CHANNEL_TOO_MANY_BLOCKS
No description available - ERR_HIL_DPM_CHANNEL_TOO_MANY_BLOCKS.
0xC0001130 ERR_HIL_DPM_BLOCK_UNKNOWN
No description available - ERR_HIL_DPM_BLOCK_UNKNOWN.
0xC0001131 ERR_HIL_DPM_BLOCK_SIZE_EXCEEDED
No description available - ERR_HIL_DPM_BLOCK_SIZE_EXCEEDED.
0xC0001132 ERR_HIL_DPM_BLOCK_CREATION_FAILED
No description available - ERR_HIL_DPM_BLOCK_CREATION_FAILED.
0xC0001133 ERR_HIL_DPM_BLOCK_OFFSET_INVALID
No description available - ERR_HIL_DPM_BLOCK_OFFSET_INVALID.
0xC0001140 ERR_HIL_DPM_CHANNEL_HOST_MBX_FULL
No description available - ERR_HIL_DPM_CHANNEL_HOST_MBX_FULL.
0xC0001141 ERR_HIL_DPM_CHANNEL_SEGMENT_LIMIT
No description available - ERR_HIL_DPM_CHANNEL_SEGMENT_LIMIT.
0xC0001142 ERR_HIL_DPM_CHANNEL_SEGMENT_UNUSED
No description available - ERR_HIL_DPM_CHANNEL_SEGMENT_UNUSED.
0xC0001143 ERR_HIL_NAME_INVALID
No description available - ERR_HIL_NAME_INVALID.
0xC0001144 ERR_HIL_UNEXPECTED_BLOCK_SIZE
No description available - ERR_HIL_UNEXPECTED_BLOCK_SIZE.
0xC0001145 ERR_HIL_COMPONENT_BUSY
The component is busy and cannot handle the requested service.
0xC0001150 ERR_HIL_INVALID_HEADER
Invalid (file) header. E.g. wrong CRC/MD5/Cookie.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0001151 ERR_HIL_INCOMPATIBLE
Firmware does not match device.
0xC0001152 ERR_HIL_NOT_AVAILABLE
Update file or destination (XIP-Area) not found.
0xC0001153 ERR_HIL_READ
Failed to read from file/area.
0xC0001154 ERR_HIL_WRITE
Failed to write from file/area.
0xC0001155 ERR_HIL_IDENTICAL
Update firmware and installed firmware are identical.
0xC0001156 ERR_HIL_INSTALLATION
Error during installation of firmware.
0xC0001157 ERR_HIL_VERIFICATION
Error during verification of firmware.
0xC0001158 ERR_HIL_INVALIDATION
Error during invalidation of firmware files.
0xC0001160 ERR_HIL_FORMAT
Volume is not formatted.
0xC0001161 ERR_HIL_VOLUME
(De-)Initialization of volume failed.
0xC0001162 ERR_HIL_VOLUME_DRV
(De-)Initialization of volume driver failed.
0xC0001163 ERR_HIL_VOLUME_INVALID
The volume is invalid.
0xC0001164 ERR_HIL_VOLUME_EXCEEDED
Number of supported volumes exceeded.
0xC0001165 ERR_HIL_VOLUME_MOUNT
The volume is mounted (in use).
0xC0001166 ERR_HIL_ERASE
Failed to erase file/directory/flash.
0xC0001167 ERR_HIL_OPEN
Failed to open file/directory.
0xC0001168 ERR_HIL_CLOSE
Failed to close file/directory.
0xC0001169 ERR_HIL_CREATE
Failed to create file/directory.
0xC0001170 ERR_HIL_MODIFY
Failed to modify file/directory.
0xC0001171 ERR_HIL_FS_NOT_AVAILABLE
File system not available.
0xC0001172 ERR_HIL_FILE_NOT_FOUND
File not available.
0xC0001173 ERR_HIL_DIAG_NO_INFO
No diagnostic information available.
0xC0001174 ERR_HIL_QUEUE_UNKNOWN
Queue is not available.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0001175 ERR_HIL_NAME_UNKNOWN
Name is unknown / not available.
0xC0001176 ERR_HIL_UPDATE_ERROR
Failed to update firmware.
0xC0001177 ERR_HIL_DDP_STATE_INVALID
DDP is in wrong state.
0xC0001178 ERR_HIL_MANUFACTURER_INVALID
Manufacturer in file header does not match target.
0xC0001179 ERR_HIL_DEVICE_CLASS_INVALID
Device class in file header does not match target.
0xC000117A ERR_HIL_HW_COMPATIBILITY_INVALID
Hardware compatibility index in file header does not match target.
0xC000117B ERR_HIL_HW_OPTIONS_INVALID
Hardware options in file header does not match target.
0x0000F005 SUCCESS_HIL_FRAGMENTED
Fragment accepted.
0xC000F006 ERR_HIL_RESET_REQUIRED
Reset required.
0xC000F007 ERR_HIL_EVALUATION_TIME_EXPIRED
Evaluation time expired. Reset required.
0xC000DEAD ERR_HIL_FIRMWARE_CRASHED
The firmware has crashed and the exception handler is running.
Table 205: Common status codes

11.2 PROFINET core

Hexadecimal value Definition and description

0xC1120001 ERR_PROFINET_CORE_TAGLIST_INVALID_MIN_RPC_BUFFER_SIZE
Taglist parameter Minimum size of each RPC Buffer is invalid.
0xC1120002 ERR_PROFINET_CORE_TAGLIST_INVALID_ADDITIONAL_AR_NUMBER
Taglist parameter Number of additional IO Connections is invalid.
0xC1120003 ERR_PROFINET_CORE_TAGLIST_INVALID_IMPLICIT_AR_NUMBER
Taglist parameter Number of parallel Read Implicit Requests is invalid.
0xC1120004 ERR_PROFINET_CORE_TAGLIST_INVALID_DAAR_NUMBER
Taglist parameter Number of parallel DeviceAccess ARs is invalid.
0xC1120005 ERR_PROFINET_CORE_TAGLIST_INVALID_SUBMODULE_NUMBER
Taglist parameter Number of configurable submodules is invalid.
0xC1120006 ERR_PROFINET_CORE_TAGLIST_INVALID_ARSET_NUMBER
Taglist parameter Number of parallel ARSets is invalid.
0xC1120007 ERR_PROFINET_CORE_TAGLIST_INVALID_DIAGNOSIS_BUFFERS_NUMBER
Taglist parameter Number of available diagnosis buffers is invalid.
Table 206: PROFINET core

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.3 PROFINET IO-Device Interface Task

Hexadecimal value Definition and description

0xC0300001 ERR_PNS_IF_COMMAND_INVALID
Invalid command.
0xC0300002 ERR_PNS_IF_OS_INIT_FAILED
Initialization of PNS Operating system adaption failed.
0xC0300003 ERR_PNS_IF_SET_INIT_IP_FAILED
Initialization of PNS IP address failed.
0xC0300004 ERR_PNS_IF_PNIO_SETUP_FAILED
PROFINET IO-Device Setup failed.
0xC0300005 ERR_PNS_IF_DEVICE_INFO_ALREADY_SET
Device information set already.
0xC0300006 ERR_PNS_IF_SET_DEVICE_INFO_FAILED
Setting of device information failed.
0xC0300007 ERR_PNS_IF_NO_DEVICE_SETUP
PROFINET IO-Device stack is not initialized. Send PNS_IF_SET_DEVICEINFO_REQ before
PNS_IF_OPEN_DEVICE_REQ.
0xC0300008 ERR_PNS_IF_DEVICE_OPEN_FAILED
Opening a device instance failed.
0xC0300009 ERR_PNS_IF_NO_DEVICE_INSTANCE
No device instance open.
0xC030000A ERR_PNS_IF_PLUG_MODULE_FAILED
Plugging a module failed.
0xC030000B ERR_PNS_IF_PLUG_SUBMODULE_FAILED
Plugging a submodule failed.
0xC030000C ERR_PNS_IF_DEVICE_START_FAILED
Start of PROFINET IO-Device failed.
0xC030000D ERR_PNS_IF_EDD_ENABLE_FAILED
Start of network communication failed.
0xC030000E ERR_PNS_IF_ALLOC_MNGMNT_BUFFER_FAILED
Allocation of a device instance management buffer failed.
0xC030000F ERR_PNS_IF_DEVICE_HANDLE_NULL
Given device handle is NULL.
0xC0300010 ERR_PNS_IF_SET_APPL_READY_FAILED
Command PNS_IF_SET_APPL_READY_REQ failed.
0xC0300011 ERR_PNS_IF_SET_DEVSTATE_FAILED
Command PNS_IF_SET_DEVSTATE_REQ failed.
0xC0300012 ERR_PNS_IF_PULL_SUBMODULE_FAILED
Pulling the submodule failed.
0xC0300013 ERR_PNS_IF_PULL_MODULE_FAILED
Pulling the module failed.
0xC0300014 ERR_PNS_IF_WRONG_DEST_ID
Destination ID in command invalid.
0xC0300015 ERR_PNS_IF_DEVICE_HANDLE_INVALID
Device Handle in command invalid.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300016 ERR_PNS_IF_CALLBACK_TIMEOUT
PNS stack callback timeout.
0xC0300017 ERR_PNS_IF_PACKET_POOL_EMPTY
PNS_IF packet pool empty.
0xC0300018 ERR_PNS_IF_ADD_API_FAILED
Command PNS_IF_ADD_API_REQ failed.
0xC0300019 ERR_PNS_IF_SET_SUB_STATE_FAILED
Setting submodule state failed.
0xC030001A ERR_PNS_IF_NO_NW_DBM_ERROR
No network configuration DBM-file.
0xC030001B ERR_PNS_IF_NW_SETUP_TABLE_ERROR
Error during reading the "SETUP" table of the network configuration DBM-file .
0xC030001C ERR_PNS_IF_CFG_SETUP_TABLE_ERROR
Error during reading the "SETUP" table of the config.xxx DBM-file .
0xC030001D ERR_PNS_IF_NO_CFG_DBM_ERROR
No config.xxx DBM-file.
0xC030001E ERR_PNS_IF_DBM_DATASET_ERROR
Error getting dataset pointer.
0xC030001F ERR_PNS_IF_SETUPEX_TABLE_ERROR
Error getting dataset pointer(SETUP_EX table).
0xC0300020 ERR_PNS_IF_AP_TABLE_ERROR
Error getting either dataset pointer or number of datasets(AP table).
0xC0300021 ERR_PNS_IF_MODULES_TABLE_ERROR
Error getting either dataset pointer or number of datasets(MODULE table).
0xC0300022 ERR_PNS_IF_SUBMODULES_TABLE_ERROR
Error getting either dataset pointer or number of datasets(SUBMODULE table).
0xC0300023 ERR_PNS_IF_PNIO_SETUP_ERROR
Error setting up PNIO configuration(PNIO_setup()).
0xC0300024 ERR_PNS_IF_MODULES_GET_REC
Error getting record of "MODULES" linked table.
0xC0300025 ERR_PNS_IF_SUBMODULES_GET_REC
Error getting record of "SUBMODULES" linked table.
0xC0300026 ERR_PNS_IF_PNIOD_MODULE_ID_TABLE_ERROR
Error accessing "PNIOD_MODULE_ID" table or table record error.
0xC0300027 ERR_PNS_IF_SIGNALS_TABLE_ERROR
Error accessing "SIGNALS" table or table record error.
0xC0300028 ERR_PNS_IF_MODULES_IO_TABLE_ERROR
Error accessing "MODULES_IO" table or table record error.
0xC0300029 ERR_PNS_IF_CHANNEL_SETTING_TABLE_ERROR
Error accessing "CHANNEL_SETTING" table or table record error.
0xC030002A ERR_PNS_IF_WRITE_DBM
Error writing DBM-file.
0xC030002B ERR_PNS_IF_DPM_CONFIG
No basic DPM configuration.
0xC030002C ERR_PNS_IF_WATCHDOG
Application did not trigger the watchdog.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC030002D ERR_PNS_IF_SIGNALS_SUBMODULES
Data length in "SIGNALS" table does not correspond to that in "SUBMODULES" table.
0xC030002E ERR_PNS_IF_READ_DPM_SUBAREA
Failed to read DPM subarea.
0xC030002F ERR_PNS_IF_MOD_0_SUB_1
Error configuring Module 0 Submodule 1.
0xC0300030 ERR_PNS_IF_SIGNALS_LENGTH
Length of I/O signals is bigger than the size of DPM subarea.
0xC0300031 ERR_PNS_IF_SUB_TRANSFER_DIRECTION
A submodule cannot have input and outputs at the same time.
0xC0300032 ERR_PNS_IF_FORMAT_PNVOLUME
Error while formatting PNVOLUME.
0xC0300033 ERR_PNS_IF_MOUNT_PNVOLUME
Error while mounting PNVOLUME.
0xC0300034 ERR_PNS_IF_INIT_REMOTE
Error during initialization of the remote resources of the stack.
0xC0300035 ERR_PNS_IF_WARMSTART_CONFIG_REDUNDANT
Warmstart parameters are redundant. The stack was configured with DBM or packets.
0xC0300036 ERR_PNS_IF_WARMSTART_PARAMETER
Incorrect warmstart parameter(s).
0xC0300037 ERR_PNS_IF_SET_APPL_STATE_READY
PNIO_set_appl_state_ready() returns error.
0xC0300038 ERR_PNS_IF_SET_DEV_STATE
PNIO_set_dev_state() returns error.
0xC0300039 ERR_PNS_IF_PROCESS_ALARM_SEND
PNIO_process_alarm_send() returns error.
0xC030003a ERR_PNS_IF_RET_OF_SUB_ALARM_SEND
PNIO_ret_of_sub_alarm_send() returns error.
0xC030003b ERR_PNS_IF_DIAG_ALARM_SEND
PNIO_diag_alarm_send() returns error.
0xC030003c ERR_PNS_IF_DIAG_GENERIC_ADD
PNIO_diag_generic_add() returns error.
0xC030003d ERR_PNS_IF_DIAG_GENERIC_REMOVE
PNIO_diag_generic_remove() returns error.
0xC030003e ERR_PNS_IF_DIAG_CHANNEL_ADD
PNIO_diag_channel_add() returns error.
0xC030003f ERR_PNS_IF_DIAG_CHANNEL_REMOVE
PNIO_diag_channel_remove() returns error.
0xC0300040 ERR_PNS_IF_EXT_DIAG_CHANNEL_ADD
PNIO_ext_diag_channel_add() returns error.
0xC0300041 ERR_PNS_IF_EXT_DIAG_CHANNEL_REMOVE
PNIO_ext_diag_channel_remove() returns error.
0xC0300042 ERR_PNS_IF_STATION_NAME_LEN
Parameter station name length is incorrect.
0xC0300043 ERR_PNS_IF_STATION_NAME
Parameter station name is incorrect.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300044 ERR_PNS_IF_STATION_TYPE_LEN
Parameter station type length is incorrect.
0xC0300045 ERR_PNS_IF_DEVICE_TYPE
Parameter device type is incorrect.
0xC0300046 ERR_PNS_IF_ORDER_ID
Parameter order id is incorrect.
0xC0300047 ERR_PNS_IF_INPUT_STATUS
Parameter input data status bytes length is incorrect.
0xC0300048 ERR_PNS_IF_OUTPUT_STATUS
Parameter output data status bytes length is incorrect.
0xC0300049 ERR_PNS_IF_WATCHDOG_PARAMETER
Parameter watchdog timing is incorrect(must be >= 10).
0xC030004a ERR_PNS_IF_OUT_UPDATE
Parameter output data update timing is incorrect.
0xC030004b ERR_PNS_IF_IN_UPDATE
Parameter input data update timing is incorrect.
0xC030004c ERR_PNS_IF_IN_SIZE
Parameter input memory area size is incorrect.
0xC030004d ERR_PNS_IF_OUT_SIZE
Parameter output memory area size is incorrect.
0xC030004e ERR_PNS_IF_GLOBAL_RESOURCES
Unable to allocate memory for global access to local resources.
0xC030004f ERR_PNS_IF_DYNAMIC_CFG_PCK
Unable to allocate memory for dynamic configuration packet.
0xC0300050 ERR_PNS_IF_DEVICE_STOP
Unable to stop device.
0xC0300051 ERR_PNS_IF_DEVICE_ID
Parameter device id is incorrect.
0xC0300052 ERR_PNS_IF_VENDOR_ID
Parameter vendor id is incorrect.
0xC0300053 ERR_PNS_IF_SYS_START
Parameter system start is incorrect.
0xC0300054 ERR_PNS_IF_DYN_CFG_IO_LENGTH
The length of IO data expected by the controller exceeds the limit specified in warmstart
parameters.
0xC0300055 ERR_PNS_IF_DYN_CFG_MOD_NUM
The count of the IO modules expected by the controller exceeds the supported by the stack count.
0xC0300056 ERR_PNS_IF_ACCESS_LOCAL_RSC
No global access to local resources.
0xC0300057 ERR_PNS_IF_PULL_PLUG
Plugging and pulling modules during creation of communication is not allowed.
0xC0300058 ERR_PNS_IF_AR_NUM
Maximum number of ARs is 1.
0xC0300059 ERR_PNS_IF_API_NUM
Only API = 0 is supported.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC030005a ERR_PNS_IF_ALREADY_OPEN
Device is already opened.
0xC030005b ERR_PNS_IF_API_ADDED
Application is already added.
0xC030005c ERR_PNS_IF_CONFIG_MODE
Configuration modes should not be mixed( DBM-files,application,warmstart message).
0xC030005d ERR_PNS_IF_UNK_LED_MODE
Unknown LED mode.
0xC030005e ERR_PNS_IF_PHYSICAL_LINK
Physical link rate is less than 100 Mbit.
0xC030005f ERR_PNS_IF_MAX_SLOT_SUBSLOT
Number of slots or subslots too big.
0xC0300060 ERR_PNS_IF_AR_REASON_MEM
AR error. Out of memory.
0xC0300061 ERR_PNS_IF_AR_REASON_FRAME
AR error. Add provider or consumer failed.
0xC0300062 ERR_PNS_IF_AR_REASON_MISS
AR error. Consumer missing.
0xC0300063 ERR_PNS_IF_AR_REASON_TIMER
AR error. CMI timeout.
0xC0300064 ERR_PNS_IF_AR_REASON_ALARM
AR error. Alarm open failed.
0xC0300065 ERR_PNS_IF_AR_REASON_ALSND
AR error. Alarm send confirmation failed.
0xC0300066 ERR_PNS_IF_AR_REASON_ALACK
AR error. Alarm acknowledge send confirmation failed.
0xC0300067 ERR_PNS_IF_AR_REASON_ALLEN
AR error. Alarm data too long.
0xC0300068 ERR_PNS_IF_AR_REASON_ASRT
AR error. Alarm indication error.
0xC0300069 ERR_PNS_IF_AR_REASON_RPC
AR error. RPC client call confirmation failed.
0xC030006A ERR_PNS_IF_AR_REASON_ABORT
AR error. Abort request.
0xC030006B ERR_PNS_IF_AR_REASON_RERUN
AR error. Re-Run.
0xC030006C ERR_PNS_IF_AR_REASON_REL
AR error. Release indication received.
0xC030006D ERR_PNS_IF_AR_REASON_PAS
AR error. Device deactivated.
0xC030006E ERR_PNS_IF_AR_REASON_RMV
AR error. Device/ar removed.
0xC030006F ERR_PNS_IF_AR_REASON_PROT
AR error. Protocol violation.
0xC0300070 ERR_PNS_IF_AR_REASON_NARE
AR error. NARE error.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300071 ERR_PNS_IF_AR_REASON_BIND
AR error. RPC-Bind error.
0xC0300072 ERR_PNS_IF_AR_REASON_CONNECT
AR error. RPC-Connect error.
0xC0300073 ERR_PNS_IF_AR_REASON_READ
AR error. RPC-Read error.
0xC0300074 ERR_PNS_IF_AR_REASON_WRITE
AR error. RPC-Write error.
0xC0300075 ERR_PNS_IF_AR_REASON_CONTROL
AR error. RPC-Control error.
0xC0300076 ERR_PNS_IF_AR_REASON_UNKNOWN
AR error. Unknown.
0xC0300077 ERR_PNS_IF_INIT_WATCHDOG
Watchdog initialization failed.
0xC0300078 ERR_PNS_IF_NO_PHYSICAL_LINK
The Device is not connected to a network.
0xC0300079 ERR_PNS_IF_DPM_CYCLIC_IO_RW
Failed to copy from DPM or to DPM the cyclic IO data.
0xC030007A ERR_PNS_IF_SUBMODULE
Submodule number is wrong.
0xC030007B ERR_PNS_IF_MODULE
Module number is wrong.
0xC030007C ERR_PNS_IF_NO_AR
The AR was closed or the AR handle is not valid.
0xC030007D ERR_PNS_IF_WRITE_REC_RES_TIMEOUT
Timeout while waiting for response to write_record_indication.
0xC030007E ERR_PNS_IF_UNREGISTERED_SENDER
The sender of the request in not registered with request PNS_IF_REGISTER_AP_REQ.
0xC030007F ERR_PNS_IF_RECORD_HANDLE_INVALID
Unknown record handle.
0xC0300080 ERR_PNS_IF_REGISTER_AP
Another instance is registered at the moment.
0xC0300081 ERR_PNS_IF_UNREGISTER_AP
One instance cannot unregister another one.
0xC0300082 ERR_PNS_IF_CONFIG_DIFFER
The Must-configuration differs from the Is-configuration.
0xC0300083 ERR_PNS_IF_NO_COMMUNICATION
No communication processing.
0xC0300084 ERR_PNS_IF_BAD_PARAMETER
At least one parameter in a packet was wrong or/and did not meet the requirements.
0xC0300085 ERR_PNS_IF_AREA_OVERFLOW
Input or Output data requires more space than available.
0xC0300086 ERR_PNS_IF_WRM_PCK_SAVE
Saving Warmstart Configuration for later use was not successful.
0xC0300087 ERR_PNS_IF_AR_REASON_PULLPLUG
AR error. Pull and Plug are forbidden after check.rsp and before in-data.ind.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300088 ERR_PNS_IF_AR_REASON_AP_RMV
AR error. AP has been removed.
0xC0300089 ERR_PNS_IF_AR_REASON_LNK_DWN
AR error. Link "down".
0xC030008A ERR_PNS_IF_AR_REASON_MMAC
AR error. Could not register multicast-MAC.
0xC030008B ERR_PNS_IF_AR_REASON_SYNC
AR error. Not synchronized (Cannot start companion-AR).
0xC030008C ERR_PNS_IF_AR_REASON_TOPO
AR error. Wrong topology(Cannot start companion-AR).
0xC030008D ERR_PNS_IF_AR_REASON_DCP_NAME
AR error. DCP. Station Name changed.
0xC030008E ERR_PNS_IF_AR_REASON_DCP_RESET
AR error. DCP. Reset to factory-settings.
0xC030008F ERR_PNS_IF_AR_REASON_PRM
AR error. Cannot start companion-AR because a 0x8ipp submodule in the first AR /has appl-
ready-pending/ is locked/ is wrong or pulled/ .
0xC0300090 ERR_PNS_IF_PACKET_MNGMNT
Packet management error.
0xC0300091 ERR_PNS_IF_WRONG_API_NUM
Invalid parameter API.
0xC0300092 ERR_PNS_IF_WRONG_MODULE_ID
Invalid parameter ModuleIdentifier (a module with different ModuleIdentifier is already plugged).
0xC0300093 ERR_PNS_IF_WRONG_MODULE_NUM
Obsolete, no longer used.
0xC0300094 ERR_PNS_IF_UNS_AREA
Obsolete, no longer used.
0xC0300095 ERR_PNS_IF_WRONG_SUB_ID
Obsolete, no longer used.
0xC0300096 ERR_PNS_IF_WRONG_SUBMODULE_NUM
Obsolete, no longer used.
0xC0300097 ERR_PNS_IF_DEVICE_STOP_FAILED
Obsolete, no longer used.
0xC0300098 ERR_PNS_IF_EDD_DISABLE_FAILED
Obsolete, no longer used.
0xC0300099 ERR_PNS_IF_WRITE_IN
Obsolete, no longer used.
0xC030009A ERR_PNS_IF_READ_OUT
Obsolete, no longer used.
0xC030009B ERR_PNS_IF_PNIO_STATUS
Obsolete, no longer used.
0xC030009C ERR_PNS_IF_WRONG_MODULE_ADDRESS
Obsolete, no longer used.
0xC030009D ERR_PNS_IF_UNK_DEVICE_STATE
Obsolete, no longer used.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC030009E ERR_PNS_IF_ALARM_DATA_LEN
Invalid alarm data length.
0xC030009F ERR_PNS_IF_UNK_SUBMODULE_STATE
Obsolete, no longer used.
0xC03000A0 ERR_PNS_IF_BAD_DIAG_HANDLE
Invalid parameter Diagnosis handle.
0xC03000A1 ERR_PNS_IF_UNS_STRUCT_ID
Obsolete, no longer used.
0xC03000A2 ERR_PNS_IF_UNK_ALARM_STATE
Obsolete, no longer used.
0xC03000A3 ERR_PNS_IF_DIAG_DATA_LEN
Obsolete, no longer used.
0xC03000A4 ERR_PNS_IF_BAD_CHANNEL_ERR_TYPE
Obsolete, no longer used.
0xC03000A5 ERR_PNS_IF_BAD_CHANNEL_PROP
Obsolete, no longer used.
0xC03000A6 ERR_PNS_IF_BAD_CHANNEL_NUM
Obsolete, no longer used.
0xC03000A7 ERR_PNS_IF_RCX_RESTART
Obsolete, no longer used.
0xC03000A8 ERR_PNS_IF_CFG_MNGMNT
Obsolete, no longer used.
0xC03000A9 ERR_PNS_IF_UNK_INTERN_REQ
Obsolete, no longer used.
0xC03000AA ERR_PNS_IF_CFG_STORE
Obsolete, no longer used.
0xC03000AB ERR_PNS_IF_CFG_DELETE_FAILED
An internal error occurred while deleting the configuration.
0xC03000AC ERR_PNS_IF_READ_CFG
Obsolete, no longer used.
0xC03000AD ERR_PNS_IF_ACCESS_SYS_VOLUME
Obsolete, no longer used.
0xC03000AE ERR_PNS_IF_ACCESS_BCKUP_VOLUME
Obsolete, no longer used.
0xC03000AF ERR_PNS_IF_CFG_BAD_LEN
Obsolete, no longer used.
0xC03000B0 ERR_PNS_IF_WRM_CFG_MNGMNT
Obsolete, no longer used.
0xC03000B1 ERR_PNS_IF_RESET_FACTORY_IND
No registered application. Reset_to_factory_settings Indication failed.
0xC03000B2 ERR_PNS_IF_MODULE_ALREADY_PLUGGED
A module was already plugged to the slot.
0xC03000B3 ERR_PNS_IF_OSINIT
Failed to init the OS adaptation layer.
0xC03000B4 ERR_PNS_IF_OSSOCKINIT
Failed to init the TCPIP adaptation layer.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC03000B5 ERR_PNS_IF_INVALID_NETMASK
Invalid subnetwork mask.
0xC03000B6 ERR_PNS_IF_INVALID_IP_ADDR
Invalid IP address.
0xC03000B7 ERR_PNS_IF_STA_STARTUP_PARAMETER
Erroneous Task start-up parameters.
0xC03000B8 ERR_PNS_IF_INIT_LOCAL
Failed to initialize the Task local resources.
0xC03000B9 ERR_PNS_IF_APP_CONFIG_INCOMPLETE
The configuration per packets is incomplete.
0xC03000BA ERR_PNS_IF_INIT_EDD
EDD Initialization failed.
0xC03000BB ERR_PNS_IF_DPM_NOT_ENABLED
DPM is not enabled.
0xC03000BC ERR_PNS_IF_READ_LINK_STATUS
Reading Link Status failed.
0xC03000BD ERR_PNS_IF_INVALID_GATEWAY
Invalid gateway address (not reachable with configured netmask).
0xC0300100 ERR_PNS_IF_PACKET_SEND_FAILED
Error while sending a packet to another task.
0xC0300101 ERR_PNS_IF_RESOURCE_OUT_OF_MEMORY
Insufficient memory to handle the request.
0xC0300102 ERR_PNS_IF_NO_APPLICATION_REGISTERED
No application to send the indication to is registered.
0xC0300103 ERR_PNS_IF_INVALID_SOURCE_ID
The host-application returned a packet with invalid (changed) SourceID.
0xC0300104 ERR_PNS_IF_PACKET_BUFFER_FULL
The buffer used to store packets exchanged between host-application and stack is full.
0xC0300105 ERR_PNS_IF_PULL_NO_MODULE
Pulling the (sub)module failed because no module is plugged into the slot specified.
0xC0300106 ERR_PNS_IF_PULL_NO_SUBMODULE
Pulling the submodule failed because no submodule is plugged into the subslot specified.
0xC0300107 ERR_PNS_IF_PACKET_BUFFER_RESTORE_ERROR
The packet buffer storing packets exchanged between host-application and stack returned an
invalid packet.
0xC0300108 ERR_PNS_IF_DIAG_NO_MODULE
Diagnosis data not accepted because no module is plugged into the slot specified.
0xC0300109 ERR_PNS_IF_DIAG_NO_SUBMODULE
Diagnosis data not accepted because no submodule is plugged into the subslot specified.
0xC030010A ERR_PNS_IF_CYCLIC_EXCHANGE_ACTIVE
The services requested are not available while cyclic communication is running.
0xC030010B ERR_PNS_IF_FATAL_ERROR_CLB_ALREADY_REGISTERED
This fatal error callback function could not be registered because there is already a function
registered.
0xC030010C ERR_PNS_IF_ERROR_STACK_WARMSTART_CONFIGURATION
The stack did not accept the warmstart parameters.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC030010D ERR_PNS_IF_ERROR_STACK_MODULE_CONFIGURATION
The stack did not accept the module configuration packet.
0xC030010E ERR_PNS_IF_CHECK_IND_FOR_UNEXPECTED_MODULE
The stack sent a Check Indication for an unexpected module. This module was not part of the CR
Info Indication.
0xC030010F ERR_PNS_IF_CHECK_IND_FOR_UNEXPECTED_SUBMODULE
The stack sent a Check Indication for an unexpected submodule. This submodule was not part of
the CR Info Indication.
0xC0300110 ERR_PNS_DIAG_BUFFER_FULL
No more diagnosis records can be added to the stack because the maximum amount is already
reached.
0xC0300111 ERR_PNS_IF_CHECK_IND_FOR_UNEXPECTED_API
The stack sent a Check Indication for an unexpected API. This API was not part of the CR Info
Indication.
0xC0300112 ERR_PNS_IF_DPM_ACCESS_WITH_INVALID_OFFSET
The DPM shall be accessed with an invalid data offset.
0xC0300113 ERR_PNS_IF_DUPLICATE_INPUT_CR_INFO
The stack indicated to CR Info Indications with type input.
0xC0300114 ERR_PNS_IF_DUPLICATE_OUTPUT_CR_INFO
The stack indicated to CR Info Indications with type output.
0xC0300115 ERR_PNS_IF_FAULTY_CR_INFO_IND_RECEIVED
The stack indicated a faulty CR Info Indications.
0xC0300116 ERR_PNS_IF_CONFIG_RELOAD_RUNNING
The request cannot be executed because configuration reload or ChannelInit is running.
0xC0300117 ERR_PNS_IF_NO_MAC_ADDRESS_SET
There is no valid chassis MAC address set Without MAC address the stack will not work.
0xC0300118 ERR_PNS_IF_SET_PORT_MAC_NOT_POSSIBLE
The Port MAC addresses have to be set before sending Set-Configuration Request to the stack.
0xC030011A ERR_PNS_IF_INVALID_MODULE_CONFIGURATION
Evaluating the module configuration failed.
0xC030011B ERR_PNS_IF_CONF_IO_LEN_TO_BIG
The sum of IO-data length exceeds the maximum allowed value.
0xC030011C ERR_PNS_IF_NO_MODULE_CONFIGURED
The module configuration does not contain at least one module.
0xC030011D ERR_PNS_IF_INVALID_SW_REV_PREFIX
The value of bSwRevisionPrefix is invalid.
0xC030011E ERR_PNS_IF_RESERVED_VALUE_NOT_ZERO
The value of usReserved it not zero.
0xC030011F ERR_PNS_IF_IDENTIFY_CMDEV_QUEUE_FAILED
Identifying the stack message queue CMDEV failed.
0xC0300120 ERR_PNS_IF_CREATE_SYNC_QUEUE_FAILED
Creating the sync message queue failed.
0xC0300121 ERR_PNS_IF_CREATE_ALARM_LOW_QUEUE_FAILED
Creating the low alarm message queue failed.
0xC0300122 ERR_PNS_IF_CREATE_ALARM_HIGH_QUEUE_FAILED
Creating the high alarm message queue failed.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300123 ERR_PNS_IF_CFG_PACKET_TO_SMALL
While evaluating SetConfiguration packet the packet length was found smaller than amount of
configured modules needs.
0xC0300124 ERR_PNS_IF_FATAL_ERROR_OCCURRED
A fatal error occurred prior to this request. Therefore this request cannot be fulfilled.
0xC0300125 ERR_PNS_IF_SUBMODULE_NOT_IN_CYCLIC_EXCHANGE
The request cannot be executed because the submodule is not in cyclic data exchange.
0xC0300126 ERR_PNS_IF_SERVICE_NOT_AVAILABLE_THROUGH_DPM
This service is not available through DPM.
0xC0300127 ERR_PNS_IF_INVALID_PARAMETER_VERSION
The version of parameters is invalid (most likely too old).
0xC0300128 ERR_PNS_IF_DATABASE_USAGE_IS_FORBIDDEN
The usage of database is forbidden by startup parameters of task.
0xC0300129 ERR_PNS_IF_RECORD_LENGTH_TOO_BIG
The amount of record data is too big.
0xC030012A ERR_PNS_IF_IDENTIFY_LLDP_QUEUE_FAILED
Identifying the stack message queue LLDP failed.
0xC030012B ERR_PNS_IF_INVALID_TOTAL_PACKET_LENGTH
SetConfiguration Requests total packet length is invalid.
0xC030012C ERR_PNS_IF_APPLICATION_TIMEOUT
The application needed too much time to respond to an indication.
0xC030012D ERR_PNS_IF_PACKET_BUFFER_INVALID_PACKET
The packet buffer storing packets exchanged between host-application and stack returned a faulty
packet.
0xC030012E ERR_PNS_IF_NO_IO_IMAGE_CONFIGURATION_AVAILABLE
The request cannot be handled until a valid IO Image configuration is available.
0xC030012F ERR_PNS_IF_IO_IMAGE_ALREADY_CONFIGURED
A valid IO Image configuration is already available.
0xC0300130 ERR_PNS_IF_INVALID_PDEV_SUBSLOT
A submodule may only be plugged into a PDEV-subslot which does not exceed the number of
supported interfaces and port numbers.
0xC0300131 ERR_PNS_IF_NO_DAP_PRESENT
The module configuration does not contain a Device Access Point DAP-submodule in slot 0
subslot 1.
0xC0300132 ERR_PNS_IF_PLUG_SUBMOD_OUTPUT_SIZE_EXCEEDED
Output size of the submodule exceeded. Configured value of ulCompleteOutputSize is smaller
than the Output size of all plugged input modules. Upgrade ulCompleteOutputSize.
0xC0300133 ERR_PNS_IF_PLUG_SUBMOD_INPUT_SIZE_EXCEEDED
Input size of the submodule exceeded. Configured value of ulCompleteInputSize is smaller than
the Input size of all plugged input modules. Upgrade ulCompleteInputSize.
0xC0300134 ERR_PNS_IF_PLUG_SUBMOD_NO_MODULE_ATTACHED_TO_ADD_TO
No module attached to add the submodule to.
0xC0300135 ERR_PNS_IF_PLUG_SUBMOD_ALREADY_PLUGGED_THIS_SUBMOD
Submodule already plugged.
0xC0300136 ERR_PNS_IF_SETIOXS_INVALID_PROV_IMAGE
Invalid IOXS provider image.
0xC0300137 ERR_PNS_IF_SETIOXS_INVALID_CONS_IMAGE
Invalid IOXS consumer image.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300138 ERR_PNS_IF_INVALID_IOPS_MODE
Invalid IOPS mode.
0xC0300139 ERR_PNS_IF_INVALID_IOCS_MODE
Invalid IOCS mode.
0xC030013A ERR_PNS_IF_INVALID_API
Invalid API.
0xC030013B ERR_PNS_IF_INVALID_SLOT
Invalid slot.
0xC030013C ERR_PNS_IF_INVALID_SUBSLOT
Invalid subslot.
0xC030013D ERR_PNS_IF_INVALID_CHANNEL_NUMBER
Invalid channel number.
0xC030013E ERR_PNS_IF_INVALID_CHANNEL_PROPERTIES
Invalid channel properties.
0xC030013F ERR_PNS_IF_CHANNEL_ERRORTYPE_NOT_ALLOWED
Invalid channel error type not allowed.
0xC0300140 ERR_PNS_IF_EXT_CHANNEL_ERRORTYPE_NOT_ALLOWED
Invalid channel EXT error type not allowed.
0xC0300141 ERR_PNS_IF_INVALID_USER_STRUCT_IDENTIFIER
Invalid user struct identifier.
0xC0300142 ERR_PNS_IF_INVALID_SUBMODULE
Invalid submodule.
0xC0300143 ERR_PNS_IF_INVALID_IM_TYPE
Invalid IM type.
0xC0300144 ERR_PNS_IF_IDENTIFY_FODMI_QUEUE_FAILED
Failed to identify the FODMI Queue.
0xC0300145 ERR_PNS_IF_DPM_MAILBOX_OVERFLOW
The DPM Receive Mailbox Queue run out of space. Most likely the host did not fetch the packets.
0xC0300146 ERR_PNS_IF_APPL_IM_ACCESS_DENIED
The application denied read/write access to I&M record object.
0xC0300147 ERR_PNS_IF_APPL_IM_INVALID_INDEX
The application does not implement the requested I&M record object.
0xC0300148 ERR_PNS_IF_TAGLIST_INVALID_SUBMODULE_NUMBER
Invalid number of max supported submodules.
0xC0300149 ERR_PNS_IF_TAGLIST_INVALID_ADDITIONAL_AR_NUMBER
Invalid number of max supported additional IO ARs.
0xC030014A ERR_PNS_IF_TAGLIST_INVALID_IMPLICIT_AR_NUMBER
Invalid number of max supported implicit IO ARs.
0xC030014B ERR_PNS_IF_TAGLIST_INVALID_DAAR_NUMBER
Invalid number of max supported Device Access ARs.
0xC030014C ERR_PNS_IF_TAGLIST_INVALID_MIN_RPC_BUFFER_SIZE
Invalid RPC buffer size.
0xC030014D ERR_PNS_IF_TAGLIST_INVALID_DIAGNOSIS_ENTRIES_NUM
Invalid number of max supported diagnosis entries .
0xC030014E ERR_PNS_IF_TAGLIST_INVALID_ARSET_NUM
Invalid number of max supported AR sets.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC030014F ERR_PNS_IF_PE_ENTITY_EXISTS
A PE Entity was already added to this submodule.
0xC0300150 ERR_PNS_IF_NO_PE_ENTITY
The submodule does not have a PE Entity.
0xC0300A00 ERR_PNS_IF_CM_AR_REASON_NONE
None. Unused.
0xC0300A03 ERR_PNS_IF_CM_AR_REASON_MEM
AR Out of memory.
0xC0300A04 ERR_PNS_IF_CM_AR_REASON_FRAME
AR add provider or consumer failed.
0xC0300A05 ERR_PNS_IF_CM_AR_REASON_MISS
AR consumer DHT/WDT expired.
0xC0300A06 ERR_PNS_IF_CM_AR_REASON_TIMER
AR cmi timeout.
0xC0300A07 ERR_PNS_IF_CM_AR_REASON_ALARM
AR alarm-open failed.
0xC0300A08 ERR_PNS_IF_CM_AR_REASON_ALSND
AR alarm-send.cnf(-).
0xC0300A09 ERR_PNS_IF_CM_AR_REASON_ALACK
AR alarm-ack-send.cnf(-).
0xC0300A0A ERR_PNS_IF_CM_AR_REASON_ALLEN
AR alarm data too long.
0xC0300A0B ERR_PNS_IF_CM_AR_REASON_ASRT
AR alarm.ind(err).
0xC0300A0C ERR_PNS_IF_CM_AR_REASON_RPC
AR rpc-client call.cnf(-).
0xC0300A0D ERR_PNS_IF_CM_AR_REASON_ABORT
AR abort.req.
0xC0300A0E ERR_PNS_IF_CM_AR_REASON_RERUN
AR re-run aborts existing AR.
0xC0300A0F ERR_PNS_IF_CM_AR_REASON_REL
AR release.ind received.
0xC0300A10 ERR_PNS_IF_CM_AR_REASON_PAS
AR device deactivated.
0xC0300A11 ERR_PNS_IF_CM_AR_REASON_RMV
AR removed.
0xC0300A12 ERR_PNS_IF_CM_AR_REASON_PROT
AR protocol violation.
0xC0300A13 ERR_PNS_IF_CM_AR_REASON_NARE
AR name resolution error.
0xC0300A14 ERR_PNS_IF_CM_AR_REASON_BIND
AR RPC-Bind error.
0xC0300A15 ERR_PNS_IF_CM_AR_REASON_CONNECT
AR RPC-Connect error.
0xC0300A16 ERR_PNS_IF_CM_AR_REASON_READ
AR RPC-Read error.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC0300A17 ERR_PNS_IF_CM_AR_REASON_WRITE
AR RPC-Write error.
0xC0300A18 ERR_PNS_IF_CM_AR_REASON_CONTROL
AR RPC-Control error.
0xC0300A19 ERR_PNS_IF_CM_AR_REASON_PULLPLUG
AR forbidden pull or plug after check.rsp and before in-data.ind.
0xC0300A1A ERR_PNS_IF_CM_AR_REASON_AP_RMV
AR AP removed.
0xC0300A1B ERR_PNS_IF_CM_AR_REASON_LNK_DWN
AR link down.
0xC0300A1C ERR_PNS_IF_CM_AR_REASON_MMAC
AR could not register multicast-mac address.
0xC0300A1D ERR_PNS_IF_CM_AR_REASON_SYNC
Not synchronized (cannot start companion-ar).
0xC0300A1E ERR_PNS_IF_CM_AR_REASON_TOPO
Wrong topology (cannot start companion-ar).
0xC0300A1F ERR_PNS_IF_CM_AR_REASON_DCP_NAME
DCP, station-name changed.
0xC0300A20 ERR_PNS_IF_CM_AR_REASON_DCP_RESET
DCP, reset to factory-settings.
0xC0300A21 ERR_PNS_IF_CM_AR_REASON_PRM
0x8ipp submodule in the first AR has either an appl-ready-pending (erroneous parameterization)
or is locked (no parameterization) or is wrong or pulled (no parameterization).
0xC0300A22 ERR_PNS_IF_CM_AR_REASON_IRDATA
No irdata record yet.
0xC0300A23 ERR_PNS_IF_CM_AR_REASON_PDEV
Ownership of PDEV.
0xC0300AFF ERR_PNS_IF_CM_AR_REASON_MAX
Max. Unused.
Table 207: PROFINET IO-Device interface task

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.4 Socket API

Hexadecimal value Definition and description

0xC0C90001 ERR_SOCK_UNSUPPORTED_SOCKET
Unsupported socket domain, type and protocol combination.
0xC0C90002 ERR_SOCK_INVALID_SOCKET_HANDLE
Invalid socket handle.
0xC0C90003 ERR_SOCK_SOCKET_CLOSED
Socket was closed.
0xC0C90004 ERR_SOCK_INVALID_OP
The command is invalid for the particular socket.
0xC0C90005 ERR_SOCK_INVALID_ADDRESS_FAMILY
An invalid address family was used for this socket
0xC0C90006 ERR_SOCK_IN_USE
The specified address is already in use.
0xC0C90007 ERR_SOCK_HUP
The remote side closed the connection
0xC0C90008 ERR_SOCK_WOULDBLOCK
The operation would block
0xC0C90009 ERR_SOCK_ROUTE
No IP route to destination address.
0xC0C9000A ERR_SOCK_IS_CONNECTED
IP socket already connected.
0xC0C9000B ERR_SOCK_CONNECTION_ABORTED
TCP connection aborted.
0xC0C9000C ERR_SOCK_CONNECTION_RESET
TCP connection reset.
0xC0C9000D ERR_SOCK_CONNECTION_CLOSED
TCP connection closed.
0xC0C9000E ERR_SOCK_NOT_CONNECTED
IP Socket not connected.
0xC0C9000F ERR_SOCK_NETWORK_INTERFACE
Low-level network interface error.
Table 208: Socket API error codes

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.5 PROFINET status codes

The PROFINET status code is used by the PROFINET protocol to indicate success or failure. This
chapter shall give a short introduction to this topic, as the status helps to solve problems and is
used in some services as well (The according field is often named ulPnio). These services
include:
 Read Record service (page 139)
 Write Record service (page 143)
 AR Abort Indication service (page 148)
 AR Abort Request service (page 201)
The status code is an unsigned 32-bit integer value which can be structured into four fields as
shown in the following figure.

Figure 48: Structure of the PROFINET status code

The fields define a hierarchy on the error codes. The ordering is as follows: ErrorCode,
ErrorDecode, ErrorCode1 and ErrorCode2. The meaning of lower order fields depends on the
values of the higher order fields. The special value 0x00000000 means no error or success.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.5.1 The ErrorCode field

This field defines the domain, in which the error occured. The following table shows the valid
values:

Value Meaning/Use Description

0x20 - 0x3F Manufacturer specific: for Log To be used when the application generates a log book entry.
Book Meaning of the values is manufacturer specific (Defined by
manufacturer of the device.)
0x81 PNIO: for all errors not covered Used for all errors not covered by the other domains
elsewhere
0xCF RTA error: used in RTA error Used in alarm error telegrams (Low Level)
PDUs
0xDA AlarmAck: used in RTA data Used in alarm data telegrams (High Level)
PDUs
0xDB IODConnectRes: RPC Connect Used to indicate errors occurred when handling a Connect
Response request.
0xDC IODReleaseRes: RPC Release Used to indicate errors occurred when handling a Release
Response request.
0xDD IODControlRes: RPC Control Used to indicate errors occurred when handling a Control request.
Response
0xDE IODReadRes: RPC Read Used to indicate errors occurred when handling a Read request.
Response
0xDF IODWriteRes: RPC Write Used to indicate error occurred when handling a Write response
Response
Table 209: Coding of PNIO status ErrorCode (Excluding reserved values)

11.5.2 The ErrorDecode field

This field defines the context, under which the error occurred.

Value Meaning/Use Description

0x80 PNIORW: Application errors of the Used in the context of Read and Write services handled by either
services Read and Write the PROFINET Device stack or by the Application
0x81 PNIO: Other Services Used in context with any other services.
0x82 Manufacturer Specific: LogBook Used in context with LogBook entries generated by the stack or by
Entries the application.
Table 210: Coding of PNIO status ErrorDecode (Excluding reserved values)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.5.3 The ErrorCode1 and ErrorCode2 fields

The ErrorCode1 and ErrorCode2 fields finally specify the error. The meaning of the both fields
depends on the value of the ErrorDecode Field.

11.5.3.1 ErrorCode1 and ErrorCode2 for ErrorDecode = PNIORW

If the field ErrorDecode is set to the value PNIORW, the field ErrorCode2 shall be encoded user
specific and the ErrorCode1 field is split into an ErrorClass Nibble and an ErrorDecode nibble as
shown in the following table.

Note: As the ErrorCode2 field can be freely chosen in this case, the application may use it to
provide more detailed information about the error (e.g. why writing the record into the
module was not possible, which value of the parameter was wrong…)

ErrorClass (Bit 7 – 4) Meaning ErrorDecode (Bit 3- 0) Meaning

0xA Application 0x0 Read Error
0x1 Write Error
0x2 Module Failure
0x7 Busy
0x8 Version Conflict
0x9 Feature Not Supported
0xA-0xF User Specific
0xB Access 0x0 Invalid Index
0x1 Write Length Error
0x2 Invalid Slot/Subslot
0x3 Type Conflict
0x4 Invalid Area/Api
0x5 State Conflict
0x6 Access Denied
0x7 Invalid Range
0x8 Invalid Parameter
0x9 Invalid Type
0xA Backup
0xB-0xF User specific
0xC Resource 0x0 Read Constrain Conflict
0x1 Write Constrain Conflict
0x2 Resource Busy
0x3 Resource Unavailable
0x8-0xF User specific
0xD-0xF User Specific 0x0-0xF User specific
Table 211: Coding of ErrorCode1 for ErrorDecode = PNIORW (Excluding reserved values)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.5.3.2 ErrorCode1 and ErrorCode2 for ErrorDecode = PNIO

The meaning of ErrorCode1 and ErrorCode2 for ErrorDecode = PNIO is shown in the following
table. This kind of PROFINET status codes should only be used in conjunction with the AR Abort
Request service on page 201 (see end of table).
Coding of ErrorCode1 and ErrorCode 2 for ErrorDecode = PNIO:
ErrCode1 Description ErrCode2 Description / Use
0x01 Connect Parameter Error. Faulty 0x00-0x0D Error in one of the Block Parameters
ARBlockReq
0x02 Connect Parameter Error. Faulty 0x00-0x1C Error in one of the Block Parameters
IOCRBlockReq
0x03 Connect Parameter Error. Faulty 0x00-0x10 Error in one of the Block Parameters
ExpectedSubmoduleBlockReq
0x04 Connect Parameter Error. Faulty 0x00-0x0F Error in one of the Block Parameters
AlarmCRBlockReq
0x05 Connect Parameter Error. Faulty 0x00-0x08 Error in one of the Block Parameters
PrmServerBlockReq
0x06 Connect Parameter Error. Faulty 0x00-0x08 Error in one of the Block Parameters
MCRBlockReq
0x07 Connect Parameter Error. Faulty 0x00-0x04 Error in one of the Block Parameters
ARRPCBlockReq
0x08 Read Write Record Parameter 0x00-0x0C Error in one of the Block Parameters
Error. Faulty Record
0x09 Connect Parameter Error Faulty 0x00-0x05 Error in one of the Block Parameters
IRInfoBlock
0x0A Connect Parameter Error Faulty 0x00-0x05 Error in one of the Block Parameters
SRInfoBlock
0x0B Connect Parameter Error Faulty 0x00-0x05 Error in one of the Block Parameters
ARFSUBlock
0x14 IODControl Parameter Error. 0x00-0x09 Error in one of the Block Parameters
Faulty ControlBlockConnect
0x15 IODControl Parameter Error. 0x00-0x09 Error in one of the Block Parameters
Faulty ControlBlockPlug
0x16 IOXControl Parameter Error. 0x00-0x07 Error in one of the Block Parameters
Faulty ControlBlock after a
connection establishment
0x17 IOXControl Parameter Error. 0x00-0x07 Error in one of the Block Parameters
Faulty ControlBlock a plug alarm
0x18 IODControl Parameter Error Faulty 0x00-0x09 Error in one of the Block Parameters
ControlBlockPrmBegin
0x19 IODControl Parameter Error Faulty 0x00-0x07 Error in one of the Block Parameters
SubmoduleListBlock
0x28 Release Parameter Error. Faulty 0x00-0x07 Error in one of the Block Parameters
ReleaseBlock
0x32 Response Parameter Error. Faulty 0x00-0x08 Error in one of the Block Parameters
ARBlockRes
0x33 Response Parameter Error. Faulty 0x00-0x06 Error in one of the Block Parameters
IOCRBlockRes
0x34 Response Parameter Error. Faulty 0x00-0x06 Error in one of the Block Parameters
AlarmCRBlockRes

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

ErrCode1 Description ErrCode2 Description / Use

0x35 Response Parameter Error. Faulty 0x00-0x0D Error in one of the Block Parameters
ModuleDiffBlock
0x36 Response Parameter Error. Faulty 0x00-0x04 Error in one of the Block Parameters
ARRPCBlockRes
0x37 Response Parameter Error Faulty 0x00-0x05 Error in one of the Block Parameters
ARServerBlockRes
0x3C AlarmAck Error Codes 0x00 Alarm Type Not Supported
0x01 Wrong Submodule State
0x3D CMDEV 0x00 State conflict
0x01 Resource
0x02-0xFF State machine specific
0x3E CMCTL 0x00 State conflict
0x01 Timeout
0x02 No data send
0x3F CTLDINA 0x00 No DCP active
0x01 DNS Unknown_RealStationName
0x02 DCP No_RealStationName
0x03 DCP Multiple_RealStationName
0x04 DCP No_StationName
0x05 No_IP_Addr
0x06 DCP_Set_Error
0x40 CMRPC 0x00 ArgsLength invalid
0x01 Unknown Blocks
0x02 IOCR Missing
0x03 Wrong AlarmCRBlock count
0x04 Out of AR Resources
0x05 AR UUID Unknown
0x06 State conflict
0x07 Out of Provider, Consumer or Alarm Resources
0x08 Out of memory
0x09 PDev already owned
0x0A ARset State conflict during connection
establishment
0x0B ARset Parameter conflict during connection
establishment
0x41 ALPMI 0x00 Invalid state
0x01 Wrong ACK-PDU
0x42 ALPMR 0x00 Invalid state
0x01 Wrong Notification PDU
0x43 LMPM 0x00–0xFF Ethernet Switch Errors
0x44 MAC 0x00-0xFF

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

ErrCode1 Description ErrCode2 Description / Use

0x45 RPC 0x01 CLRPC_ERR_REJECTED: EPM or Server
rejected the call.
0x02 CLRPC_ERR_FAULTED: Server had fault while
executing the call
0x03 CLRPC_ERR_TIMEOUT: EPM or Server did not
respond
0x04 CLRPC_ERR_IN_ARGS; Broadcast or maybe
“ndr_data” too large
0x05 CLRPC_ERR_OUT_ARGS: Server sent back
more than “alloc_len”
0x06 CLRPC_ERR_DECODE: Result of EPM Lookup
could not be decoded
0x07 CLRPC_ERR_PNIO_OUT_ARGS: Out-args not
“PN IO signature”, too short or inconsistent
0x08 CLRPC_ERR_PNIO_APP_TIMEOUT: RPC call
was terminated after RPC application timeout
0x46 APMR 0x00 Invalid state
0x01 LMPM signaled an error
0x47 APMS 0x00 Invalid state
0x01 LMPM signaled an error
0x02 Timeout
0x48 CPM 0x00 Invalid state
0x49 PPM 0x00 Invalid state
0x4A DCPUCS 0x00 Invalid state
0x01 LMPM signaled an error
0x02 Timeout
0x4B DCPUCR 0x00 Invalid state
0x01 LMPM signaled an error
0x4C DCPMCS 0x00 Invalid state
0x01 LMPM signaled an error
0x4D DCPMCR 0x00 Invalid state
0x01 LMPM signaled an error
0x4E FSPM 0x00-0xFF FAL Service Protocol Machine error
0x64 CTLSM 0x00 Invalid state
0x01 CTLSM signaled error
0x65 CTLRDI 0x00 Invalid state
0x01 CTLRDI signaled an error
0x66 CTLRDR 0x00 Invalid state
0x01 CTLRDR signaled an error
0x67 CTLWRI 0x00 Invalid state
0x01 CTLWRI signaled an error
0x68 CTLWRR 0x00 Invalid State

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

ErrCode1 Description ErrCode2 Description / Use

0x01 CTLWRR signaled an error
0x69 CTLIO 0x00 Invalid state
0x01 CTLIO signaled an error
0x6A CTLSU 0x00 Invalid state
0x01 AR add provider or consumer failed
0x02 AR alarm-open failed
0x03 AR alarm-ack-send
0x04 AR alarm-send
0x05 AR alarm-ind
0x6B CTLRPC 0x00 Invalid state
0x01 CTLRPC signaled an error
0x6C CTLPBE 0x00 Invalid state
0x01 CTLPBE signaled an error
0xC8 CMSM 0x00 Invalid state
0x01 CMSM signaled an error
0xCA CMRDR 0x00 Invalid state
0x01 CMRDR signaled an error
0xCC CMWRR 0x00 Invalid state
0x01 AR is not in state Primary. (Write not allowed)
0x02 CMWRR signaled an error
0xCD CMIO 0x00 Invalid state
0x01 CMIO signaled an error
0xCE CMSU 0x00 Invalid state
0x01 AR add provider or consumer failed
0x02 AR alarm-open failed
0x03 AR alarm-send
0x04 AR alam-ack-send
0x05 AR alarm-ind
0xD0 CMINA 0x00 Invalid state
0x01 CMINA signaled an error
0xD1 CMPBE 0x00 Invalid state
0x01 CMPBE signaled an error
0xD2 CMDMC 0x00 Invalid state
0x01 CMDMC signaled an error
0xFD Used by RTA for protocol error 0x00 Reserved
(RTA_ERR_CLS_PROTOCOL)
0x01 error within the coordination of sequence
numbers (RTA_ERR_CODE_SEQ)
0x02 instance closed (RTA_ERR_ABORT)
0x03 AR out of memory (RTA_ERR_ABORT)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

ErrCode1 Description ErrCode2 Description / Use

0x04 AR add provider or consumer failed
(RTA_ERR_ABORT)
0x05 AR consumer DHT / WDT expired
(RTA_ERR_ABORT)
0x06 AR cmi timeout (RTA_ERR_ABORT)
0x07 AR alarm-open failed (RTA_ERR_ABORT)
0x08 AR alarm-send.cnf(-) (RTA_ERR_ABORT)
0x09 AR alarm-ack- send.cnf(-) (RTA_ERR_ABORT)
0x0A AR alarm data too long (RTA_ERR_ABORT)
0x0B AR alarm.ind(err) (RTA_ERR_ABORT)
0x0C AR rpc-client call.cnf(-) (RTA_ERR_ABORT)
0x0D AR abort.req (RTA_ERR_ABORT)
0x0E AR re-run aborts existing (RTA_ERR_ABORT)
0x0F AR release.ind received (RTA_ERR_ABORT)
0xFD (continued) Used by RTA for protocol error 0x10 AR device deactivated (RTA_ERR_ABORT)
(RTA_ERR_CLS_PROTOCOL)
0x11 AR removed (RTA_ERR_ABORT)
0x12 AR protocol violation (RTA_ERR_ABORT)
0x13 AR name resolution error (RTA_ERR_ABORT)
0x14 AR RPC-Bind error (RTA_ERR_ABORT)
0x15 AR RPC-Connect error (RTA_ERR_ABORT)
0x16 AR RPC-Read error (RTA_ERR_ABORT)
0x17 AR RPC-Write error (RTA_ERR_ABORT)
0x18 AR RPC-Control error (RTA_ERR_ABORT)
0x19 AR forbidden pull or plug after check.rsp and
before indata.ind (RTA_ERR_ABORT)
0x1A AR AP removed (RTA_ERR_ABORT)
0x1B AR link down (RTA_ERR_ABORT)
0x1C AR could not register multicast-mac address
(RTA_ERR_ABORT)
0x1D not synchronized (cannot start companion-ar)
(RTA_ERR_ABORT)
0x1E wrong topology (cannot start companion-ar)
(RTA_ERR_ABORT)
0x1F dcp, station-name changed
(RTA_ERR_ABORT)
0xFD (continued) Used by RTA for protocol error 0x20 dcp, reset to factory-settings
(RTA_ERR_CLS_PROTOCOL) (RTA_ERR_ABORT)
0x21 cannot start companion-AR because a 0x8ipp
submodule in the first AR... (RTA_ERR_ABORT)
0x22 no irdata record yet (RTA_ERR_ABORT)
0x23 PDEV (RTA_ERROR_ABORT)
0x24 PDEV, no port offers required speed / duplexity
(RTA_ERR_ABORT)

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

ErrCode1 Description ErrCode2 Description / Use

0x25 IP-suite [of the IOC] changed by means of DCP
set(IPParameter) or local engineering
(RTA_ERR_ABORT)
0x26 IOCARSR RDHT expired
(RTA_ERROR_ABORT)
0xC9 AR removed by reason of watchdog timeout in
the Application task (RTA_ERROR_ABORT)
0xCA AR removed by reason of pool underflow in the
Application task (RTA_ERROR_ABORT)
0xCB AR removed by reason of unsuccessful packet
sending (Queue) inside OS in the Application
task (RTA_ERROR_ABORT)
0xCC AR removed by reason of unsuccessful memory
allocation in the Application task
(RTA_ERROR_ABORT)
0xFF User specific 0x00-0xFE User specific
0xFF Recommended for “User abort” without further
detail
Table 212: Coding of ErrorCode1 for ErrorDecode = PNIO (Excluding reserved values)

11.5.3.3 ErrorCode1 and ErrorCode2 for ErrorDecode is manufacturer specific

If ErrorDecode is set to manufacturer specific, the values of the fields ErrorCode1 and ErrorCode2
could be freely chosen.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

11.6 Generic AP

Hexadecimal value Definition and description

0xC1090001 ERR_GAP_INVALID_COMPONENT_ID
Invalid component identifier.
0xC1090002 ERR_GAP_SET_REMANENT_DATA_NOT_ALLOWED
Setting remanent data is not allowed.
0xC1090003 ERR_GAP_INVALID_WORKER
Invalid worker.
0xC1090004 ERR_GAP_LOGBOOK_CREATE_FAIL
The Logbook could not be created.
0xC1090005 ERR_GAP_POOL_CREATE_FAIL
The service pool could not be created.
0xC1090006 ERR_GAP_QUEUE_CREATE_FAIL
The GAP queue could not be created.
0xC1090007 ERR_GAP_MUTEX_INIT_FAIL
The initialization of a mutex failed.
0xC1090008 ERR_GAP_TIMER_INIT_FAIL
The initialization of a PS Timer failed.
0xC1090009 ERR_GAP_COMPMGR_REGISTER_FAIL
Generic AP could not register at Component Manager.
0xC109000A ERR_GAP_COMPMGR_DIAG_REGISTER_FAIL
Generic AP could not register the diagnostic callback at Component Manager.
0xC109000B ERR_GAP_WATCHDOG_INIT_FAIL
The DPM watchdog initialization failed.
0xC109000C ERR_GAP_SET_CHANNEL_QUEUE_FAIL
The DPM channel queue could not be registered.
0xC109000D ERR_GAP_GET_CHANNEL_QUEUE_FAIL
The DPM channel queue could not be retrieved.
0xC109000E ERR_GAP_REMANENT_FILE_CREATE_FAIL
The remanent data file could not be created.
0xC109000F ERR_GAP_COMPONENT_INIT_FAIL
The component initialization failed.
0xC1090010 ERR_GAP_COMPONENT_START_FAIL
The component could not be started.
0xC1090011 ERR_GAP_REMANENT_DATA_NOT_ENOUGH_MEMORY
Not enough memory for remanent data.
0xC1090012 ERR_GAP_FRAGMENT_FORWARD_INIT_FAIL
The fragment forwarding initialization failed.
0xC1090013 ERR_GAP_DPM_CHANNEL_START_FAIL
The DPM channel could not be started.
0xC1090014 ERR_GAP_RESOURCE_ALLOCATION_FAIL
Failed to allocate Generic AP resources.
0xC1090015 ERR_GAP_CONFIG_VERSION_INVALID
Invalid Generic AP configuration version.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Hexadecimal value Definition and description

0xC1090016 ERR_GAP_CONFIG_DPM_COMM_CHANNEL_INVALID
Invalid DPM communication channel.
0xC1090017 ERR_GAP_CONFIG_DPM_CHANNEL_FW_INFO_INVALID
Invalid firmware information for the related DPM communication channel.
0xC1090018 ERR_GAP_REMANENT_FILE_READ_FAIL
The remanent data file could not be read.
0xC1090019 ERR_GAP_REMANENT_FILE_WRITE_FAIL
The remanent data file could not be written.
0xC109001A ERR_GAP_REMANENT_DATA_DELETE_FAIL
The remanent data could not be deleted.
0x8109001B WARN_GAP_SET_REMANENT_DATA_DENIED
The component did not accept the remanent data.
0x8109001C WARN_GAP_SERVICE_DENIED
The component did not accept the service.
0xC109001D ERR_GAP_NO_RESPONSE_HANDLER
No response service handler could be found.
0x8109001E WARN_GAP_SERVICE_RETRY
The forwarding of a service to the component or application has failed and will be repeated.
0xC109001F ERR_GAP_QUEUE_INVALID_SERVICE_LEN
Queue service length is invalid.
0xC1090020 ERR_GAP_DPM_INVALID_SERVICE_LEN
DPM service length is invalid.
0x81090021 WARN_GAP_NO_REMANENT_DATA
Remanent data does not exist.
0xC1090022 ERR_GAP_QUEUE_JOB
Service job queued failed.
Table 213: Generic AP

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

12 Coding of Diagnosis
The following tables represent diagnosis specific object and structure defined in PROFINET
specification (IEC 61158-6-10).

Coding of Channel Properties

Bit No Description
D0 - D7 Data type of this channel, see Table 215 on page 305.
D8 Accumulative. It should be set if the diagnosis is accumulated from several channels
D9 – D10 Maintenance, see Table 216 on page 305.
D11 – D12 Specifier. It will be handled by the Stack and shall not be set by application.
D13 - D15 Direction, see Table 217 on page 306.
Table 214: Coding of the field Channel Properties

Coding of Channel Properties.Data type

Value (Hexadecimal) Description

0x00 Should be used if ChannelNumber is 0x8000 or If none of the below defined types are
appropriate
0x01 1 Bit
0x02 2 Bits
0x03 4 Bits
0x04 8 Bits
0x05 16 Bits
0x06 32 Bits
0x07 64 Bits
0x07 – 0xFF Reserved
Table 215: Coding of the field data type in field Channel Properties

Coding of Channel Properties.Maintenance

Value (Hexadecimal) Description

0x00 Diagnosis
0x01 Maintenance Required
0x02 Maintenance Demanded
0x03 Qualified Diagnosis
Table 216: Coding of the field Maintenance in field Channel Properties

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Coding of Diagnosis 306/323
Coding of Channel Properties.Direction
Value (Hexadecimal) Description
0x00 Manufacturer specific
0x01 Input
0x02 Output
0x03 Input / Output
0x04 – 0xFF Reserved
Table 217: Coding of the field Direction in field Channel Properties

Coding of Channel error type

Value (Hexadecimal) Description

0x0000 Reserved
0x0001 Short circuit
0x0002 Undervoltage
0x0003 Overvoltage
0x0004 Overload
0x0005 Overtemperature
0x0006 Line break
0x0007 Upper limit value exceeded
0x0008 Lower limit value exceeded
0x0009 Error
0x000A Simulation active
0x000B – 0x000E Reserved
0x000F Manufacturer specific, recommended for “parameterization missing”
0x0010 Manufacturer specific, recommended for “parameterization fault”
0x0011 Manufacturer specific, recommended for “power supply fault”
0x0012 Manufacturer specific, recommended for “fuse blown / open”
0x0013 Manufacturer specific, recommended for “communication fault”
0x0014 Manufacturer specific, recommended for “ground fault”
0x0015 Manufacturer specific, recommended for “reference point lost”
0x0016 Manufacturer specific, recommended for “process event lost / sampling error”
0x0017 Manufacturer specific, recommended for “threshold warning”
0x0018 Manufacturer specific, recommended for “output disabled”
0x0019 Manufacturer specific, recommended for “safety event”
0x001A Manufacturer specific, recommended for “external fault”
0x001B - 0x001E Manufacturer specific
0x001F Manufacturer specific, recommended for “temporary fault”
0x0020 - 0x00FF Reserved for common profiles (assigned by PROFIBUS International)
0x0100 - 0x7FFF Manufacturer specific
0x8000 Data transmission impossible

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Value (Hexadecimal) Description

0x8001 Remote mismatch
0x8002 Media redundancy mismatch
0x8003 Sync mismatch
0x8004 Isochronous mode mismatch
0x8005 Multicast CR mismatch
0x8006 Reserved
0x8007 Fiber optic mismatch
0x8008 Network component function mismatch
0x8009 Time mismatch
0x800A Dynamic frame packing function mismatch
0x800B Media redundancy with planned duplication mismatch
0x800C System redundancy mismatch
0x800D Multiple interface mismatch
0x800E Nested diagnosis indication
0x800F - 0x8FFF Reserved
0x9000 - 0x9FFF Reserved for profiles
0xA000 - 0xFFFF Reserved
Table 218: Coding of Channel error type

Note: values 0x8000 – 0x800E will be triggered by the Stack internally and shall not be set by
application

Coding of Extended channel error type

The value of this field depends on the field Channel error type. The values shall be set according to
following tables:
Value (hexadecimal) Description Usage
0x0000 Reserved
0x0001 - 0x7FFF Manufacturer specific Alarm / Diagnosis
0x8000 Accumulative info Alarm / Diagnosis
0x8001 - 0x8FFF Reserved
0x9000 - 0x9FFF Profile specific error codes Alarm / Diagnosis
0xA000 - 0xFFFF Reserved
Table 219: Coding of Extended channel error type for Channel Error Type 1 - 0x7FFF

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Coding of Diagnosis 308/323
In conjunction with profile specific error types the extended channel error type will be set according
to following tabels:
Coding usExtChannelErrType in conjunction with Data transmission impossible error type
Value Description
0x8000 Link State Mismatch – Link down
0x8001 MAUType Mismatch
0x8003 Line delay mismatch
Table 220: Coding usExtChannelErrType in conjunction with Data transmission impossible error type

Coding of Extended error Type in conjunction with Remote Mismatch error type
Value Description
0x8000 Peer Chassis ID mismatch
0x8001 Peer Port ID mismatch
0x8002 RT Class 3 mismatch
0x8003 Peer MAUType mismatch
0x8004 Peer MRP-Domain ID mismatch
0x8005 No peer detected
0x8007 Peer CableDelay mismatch
0x8008 Peer PTCP mismatch
Other Reserved
Table 221: Coding of Extended error Type in conjunction with Remote Mismatch error type

Coding of Extended error Type in conjunction with Sync Mismatch error type
Value Description
0x8000 No Sync Message Received
0x8001 Jitter out of Boundary”
Other Reserved
Table 222: Coding of Extended error Type in conjunction with Sync Mismatch error type

Coding of Extended error Type in conjunction with Fiber optic mismatch error type
Value Description
0x8000 Power budget mismatch
Other Reserved
Table 223: Coding of Extended error Type in conjunction with Fiber optic mismatch error type

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13 Appendix

13.1 Name encoding

The name is an OctetString with 1 to 240 octets. A name can contain one or more labels separated
by a dot [.].
The definition of IETF RFC 5890 and the following syntax applies:
 1 or more labels, separated by [.]
 Total length is 1 to 240
 Label length is 1 to 63
 Labels consist of [a-z0-9-]
 Labels do not start with [-]
 Labels do not end with [-]
 Labels do not use multiple concatenated [-] except for IETF RFC 5890
 The first label does not have the form “port-xyz” or “port-xyz-abcde” with a, b, c, d, e, x, y, z =
0..9, to avoid wrong similarity with the field AliasNameValue
 Station names do not have the form a.b.c.d with a, b, c, d = 0...999

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13.2 SNMP MIBs and local OIDs

The following tables list the OIDs (Object identifier) generally supported by the SNMP instance of
PROFINET IO-Device firmware and its firmware components.

Note: This section is informative only.

The following limitations apply regarding the lists:

 The meaning of the OID number is for reference only. It may be wrong, only the OID number
itself is binding.
 The content reported back for a specific OID may not be valid in all situations (e.g.
depending on the capabilities of the switch).
 Some firmware may only support a subset of these OIDs (e.g. single port firmware which
does not support some PROFINET features).
 The tables list local OIDs only. All “remote tables” containing information about connected
neighbors are not listed.
 OIDs present for each individual port are only listed once.

Object identifier of LLDP

Object identifier (OID) Object

1.0.8802.1.1.2.1.1.1 lldpMessageTxInterval
1.0.8802.1.1.2.1.1.2 lldpMessageTxHoldMultiplier
1.0.8802.1.1.2.1.1.3 lldpReinitDelay
1.0.8802.1.1.2.1.1.4 lldpTxDelay
1.0.8802.1.1.2.1.1.5 lldpNotificationInterval
1.0.8802.1.1.2.1.1.6.1.2 lldpPortConfigAdminStatus
1.0.8802.1.1.2.1.1.6.1.3 lldpPortConfigNotificationEnable
1.0.8802.1.1.2.1.1.6.1.4 lldpPortConfigTLVsTxEnable
1.0.8802.1.1.2.1.1.7.1.1.1 lldpConfigManAddrPortsTxEnable
1.0.8802.1.1.2.1.2.1 lldpStatsRemTablesLastChangeTime
1.0.8802.1.1.2.1.2.2 lldpStatsRemTablesInserts
1.0.8802.1.1.2.1.2.3 lldpStatsRemTablesDeletes
1.0.8802.1.1.2.1.2.4 lldpStatsRemTablesDrops
1.0.8802.1.1.2.1.2.5 lldpStatsRemTablesAgeouts
1.0.8802.1.1.2.1.2.6.1.2 lldpStatsTxPortFramesTotal
1.0.8802.1.1.2.1.2.7.1.2 lldpStatsRxPortFramesDiscardedTotal
1.0.8802.1.1.2.1.2.7.1.3 lldpStatsRxPortFramesErrors
1.0.8802.1.1.2.1.2.7.1.4 lldpStatsRxPortFramesTotal
1.0.8802.1.1.2.1.2.7.1.5 lldpStatsRxPortTLVsDiscardedTotal
1.0.8802.1.1.2.1.2.7.1.6 lldpStatsRxPortTLVsUnrecognizedTotal
1.0.8802.1.1.2.1.2.7.1.7 lldpStatsRxPortAgeoutsTotal
1.0.8802.1.1.2.1.3.1 lldpLocChassisIdSubtype
1.0.8802.1.1.2.1.3.2 lldpLocChassisId
1.0.8802.1.1.2.1.3.3 lldpLocSysName
1.0.8802.1.1.2.1.3.4 lldpLocSysDesc

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Object identifier (OID) Object

1.0.8802.1.1.2.1.3.5 lldpLocSysCapSupported
1.0.8802.1.1.2.1.3.6 lldpLocSysCapEnabled
1.0.8802.1.1.2.1.3.7.1.2 lldpLocPortIdSubtype
1.0.8802.1.1.2.1.3.7.1.3 lldpLocPortId
1.0.8802.1.1.2.1.3.7.1.4 lldpLocPortDesc
1.0.8802.1.1.2.1.3.8.1.3 lldpLocManAddrLen
1.0.8802.1.1.2.1.3.8.1.4 lldpLocManAddrIfSubtype
1.0.8802.1.1.2.1.3.8.1.5 lldpLocManAddrIfId
1.0.8802.1.1.2.1.3.8.1.6 lldpLocManAddrOID
Table 224: Object identifier of LLDP

Object identifier of PNO

Object identifier (OID) Object

1.0.8802.1.1.2.1.5.3791.1.1.1.1.1 lldpXPnoConfigSPDTxEnable
1.0.8802.1.1.2.1.5.3791.1.1.1.1.2 lldpXPnoConfigPortStatusTxEnable
1.0.8802.1.1.2.1.5.3791.1.1.1.1.3 lldpXPnoConfigAliasTxEnable
1.0.8802.1.1.2.1.5.3791.1.1.1.1.4 lldpXPnoConfigMrpTxEnable
1.0.8802.1.1.2.1.5.3791.1.1.1.1.5 lldpXPnoConfigPtcpTxEnable
1.0.8802.1.1.2.1.5.3791.1.2.1.1.1 lldpXPnoLocLPDValue
1.0.8802.1.1.2.1.5.3791.1.2.1.1.2 lldpXPnoLocPortTxDValue
1.0.8802.1.1.2.1.5.3791.1.2.1.1.3 lldpXPnoLocPortRxDValue
1.0.8802.1.1.2.1.5.3791.1.2.1.1.4 lldpXPnoLocPortStatusRT2
1.0.8802.1.1.2.1.5.3791.1.2.1.1.5 lldpXPnoLocPortStatusRT3
1.0.8802.1.1.2.1.5.3791.1.2.1.1.6 lldpXPnoLocPortNoS
1.0.8802.1.1.2.1.5.3791.1.2.1.1.7 lldpXPnoLocPortMrpUuId
1.0.8802.1.1.2.1.5.3791.1.2.1.1.8 lldpXPnoLocPortMrrtStatus
1.0.8802.1.1.2.1.5.3791.1.2.1.1.9 lldpXPnoLocPortPtcpMaster
1.0.8802.1.1.2.1.5.3791.1.2.1.1.10 lldpXPnoLocPortPtcpSubdomainUUID
1.0.8802.1.1.2.1.5.3791.1.2.1.1.11 lldpXPnoLocPortPtcpIRDataUUID
1.0.8802.1.1.2.1.5.3791.1.2.1.1.12 lldpXPnoLocPortModeRT3
1.0.8802.1.1.2.1.5.3791.1.2.1.1.13 lldpXPnoLocPortPeriodLength
1.0.8802.1.1.2.1.5.3791.1.2.1.1.14 lldpXPnoLocPortPeriodValidity
1.0.8802.1.1.2.1.5.3791.1.2.1.1.15 lldpXPnoLocPortRedOffset
1.0.8802.1.1.2.1.5.3791.1.2.1.1.16 lldpXPnoLocPortRedValidity
1.0.8802.1.1.2.1.5.3791.1.2.1.1.17 lldpXPnoLocPortOrangeOffset
1.0.8802.1.1.2.1.5.3791.1.2.1.1.18 lldpXPnoLocPortOrangeValidity
1.0.8802.1.1.2.1.5.3791.1.2.1.1.19 lldpXPnoLocPortGreenOffset
1.0.8802.1.1.2.1.5.3791.1.2.1.1.20 lldpXPnoLocPortGreenValidity
1.0.8802.1.1.2.1.5.3791.1.2.1.1.21 lldpXPnoLocPortStatusRT3OptimizationSupported
1.0.8802.1.1.2.1.5.3791.1.2.1.1.22 lldpXPnoLocPortStatusRT3PreambleShorteningSupported
1.0.8802.1.1.2.1.5.3791.1.2.1.1.23 lldpXPnoLocPortStatusRT3PreambleShortening
1.0.8802.1.1.2.1.5.3791.1.2.1.1.24 lldpXPnoLocPortStatusRT3FragmentationSupported

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Object identifier (OID) Object

1.0.8802.1.1.2.1.5.3791.1.2.1.1.25 lldpXPnoLocPortStatusRT3Fragmentation
Table 225: Object identifier of PNO

Object identifier of LLDP 802.3 extension

Object identifier (OID) Object

1.0.8802.1.1.2.1.5.4623.1.3.1.1.1 lldpXdot3RemPortAutoNegSupported
1.0.8802.1.1.2.1.5.4623.1.3.1.1.2 lldpXdot3RemPortAutoNegEnabled
1.0.8802.1.1.2.1.5.4623.1.3.1.1.3 lldpXdot3RemPortAutoNegAdvertisedCap
1.0.8802.1.1.2.1.5.4623.1.3.1.1.4 lldpXdot3RemPortOperMauType
Table 226: Object identifier of LLDP 802.3 extension

Object identifier of the System and Interface MIB

Object identifier (OID) Object

1.3.6.1.2.1.1.1 sysDescr
1.3.6.1.2.1.1.2 sysObjectID
1.3.6.1.2.1.1.3 sysUpTime
1.3.6.1.2.1.1.4 sysContact
1.3.6.1.2.1.1.5 sysName
1.3.6.1.2.1.1.6 sysLocation
1.3.6.1.2.1.1.7 sysServices
1.3.6.1.2.1.2.2.1.1 ifIndex
1.3.6.1.2.1.2.2.1.2 ifDescr
1.3.6.1.2.1.2.2.1.3 ifType
1.3.6.1.2.1.2.2.1.4 ifMtu
1.3.6.1.2.1.2.2.1.5 ifSpeed
1.3.6.1.2.1.2.2.1.6 ifPhysAddress
1.3.6.1.2.1.2.2.1.7 ifAdminStatus
1.3.6.1.2.1.2.2.1.8 ifOperStatus
1.3.6.1.2.1.2.2.1.9 ifLastChange
1.3.6.1.2.1.2.2.1.10 ifInOctets
1.3.6.1.2.1.2.2.1.13 ifInDiscards
1.3.6.1.2.1.2.2.1.14 ifInErrors
1.3.6.1.2.1.2.2.1.16 ifOutOctets
1.3.6.1.2.1.2.2.1.19 ifOutDiscards
1.3.6.1.2.1.2.2.1.20 ifOutErrors
Table 227: Object identifier of the System and Interface MIB

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13.3 Legal notes

Copyright
© Hilscher Gesellschaft für Systemautomation mbH
All rights reserved.
The images, photographs and texts in the accompanying materials (in the form of a user's manual,
operator's manual, Statement of Work document and all other document types, support texts,
documentation, etc.) are protected by German and international copyright and by international
trade and protective provisions. Without the prior written consent, you do not have permission to
duplicate them either in full or in part using technical or mechanical methods (print, photocopy or
any other method), to edit them using electronic systems or to transfer them. You are not permitted
to make changes to copyright notices, markings, trademarks or ownership declarations.
Illustrations are provided without taking the patent situation into account. Any company names and
product designations provided in this document may be brands or trademarks by the
corresponding owner and may be protected under trademark, brand or patent law. Any form of
further use shall require the express consent from the relevant owner of the rights.

Important notes
Utmost care was/is given in the preparation of the documentation at hand consisting of a user's
manual, operating manual and any other document type and accompanying texts. However, errors
cannot be ruled out. Therefore, we cannot assume any guarantee or legal responsibility for
erroneous information or liability of any kind. You are hereby made aware that descriptions found
in the user's manual, the accompanying texts and the documentation neither represent a
guarantee nor any indication on proper use as stipulated in the agreement or a promised attribute.
It cannot be ruled out that the user's manual, the accompanying texts and the documentation do
not completely match the described attributes, standards or any other data for the delivered
product. A warranty or guarantee with respect to the correctness or accuracy of the information is
not assumed.
We reserve the right to modify our products and the specifications for such as well as the
corresponding documentation in the form of a user's manual, operating manual and/or any other
document types and accompanying texts at any time and without notice without being required to
notify of said modification. Changes shall be taken into account in future manuals and do not
represent an obligation of any kind, in particular there shall be no right to have delivered
documents revised. The manual delivered with the product shall apply.
Under no circumstances shall Hilscher Gesellschaft für Systemautomation mbH be liable for direct,
indirect, ancillary or subsequent damage, or for any loss of income, which may arise after use of
the information contained herein.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

Liability disclaimer
The hardware and/or software was created and tested by Hilscher Gesellschaft für
Systemautomation mbH with utmost care and is made available as is. No warranty can be
assumed for the performance or flawlessness of the hardware and/or software under all application
conditions and scenarios and the work results achieved by the user when using the hardware
and/or software. Liability for any damage that may have occurred as a result of using the hardware
and/or software or the corresponding documents shall be limited to an event involving willful intent
or a grossly negligent violation of a fundamental contractual obligation. However, the right to assert
damages due to a violation of a fundamental contractual obligation shall be limited to contract-
typical foreseeable damage.
It is hereby expressly agreed upon in particular that any use or utilization of the hardware and/or
software in connection with
 Flight control systems in aviation and aerospace;
 Nuclear fission processes in nuclear power plants;
 Medical devices used for life support and
 Vehicle control systems used in passenger transport
shall be excluded. Use of the hardware and/or software in any of the following areas is strictly
prohibited:
 For military purposes or in weaponry;
 For designing, engineering, maintaining or operating nuclear systems;
 In flight safety systems, aviation and flight telecommunications systems;
 In life-support systems;
 In systems in which any malfunction in the hardware and/or software may result in physical
injuries or fatalities.
You are hereby made aware that the hardware and/or software was not created for use in
hazardous environments, which require fail-safe control mechanisms. Use of the hardware and/or
software in this kind of environment shall be at your own risk; any liability for damage or loss due to
impermissible use shall be excluded.

Warranty
Hilscher Gesellschaft für Systemautomation mbH hereby guarantees that the software shall run
without errors in accordance with the requirements listed in the specifications and that there were
no defects on the date of acceptance. The warranty period shall be 12 months commencing as of
the date of acceptance or purchase (with express declaration or implied, by customer's conclusive
behavior, e.g. putting into operation permanently).
The warranty obligation for equipment (hardware) we produce is 36 months, calculated as of the
date of delivery ex works. The aforementioned provisions shall not apply if longer warranty periods
are mandatory by law pursuant to Section 438 (1.2) BGB, Section 479 (1) BGB and Section 634a
(1) BGB [Bürgerliches Gesetzbuch; German Civil Code] If, despite of all due care taken, the
delivered product should have a defect, which already existed at the time of the transfer of risk, it
shall be at our discretion to either repair the product or to deliver a replacement product, subject to
timely notification of defect.
The warranty obligation shall not apply if the notification of defect is not asserted promptly, if the
purchaser or third party has tampered with the products, if the defect is the result of natural wear,
was caused by unfavorable operating conditions or is due to violations against our operating
regulations or against rules of good electrical engineering practice, or if our request to return the
defective object is not promptly complied with.
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Appendix 315/323
Costs of support, maintenance, customization and product care
Please be advised that any subsequent improvement shall only be free of charge if a defect is
found. Any form of technical support, maintenance and customization is not a warranty service, but
instead shall be charged extra.

Additional guarantees
Although the hardware and software was developed and tested in-depth with greatest care,
Hilscher Gesellschaft für Systemautomation mbH shall not assume any guarantee for the suitability
thereof for any purpose that was not confirmed in writing. No guarantee can be granted whereby
the hardware and software satisfies your requirements, or the use of the hardware and/or software
is uninterruptable or the hardware and/or software is fault-free.
It cannot be guaranteed that patents and/or ownership privileges have not been infringed upon or
violated or that the products are free from third-party influence. No additional guarantees or
promises shall be made as to whether the product is market current, free from deficiency in title, or
can be integrated or is usable for specific purposes, unless such guarantees or promises are
required under existing law and cannot be restricted.

Confidentiality
The customer hereby expressly acknowledges that this document contains trade secrets,
information protected by copyright and other patent and ownership privileges as well as any related
rights of Hilscher Gesellschaft für Systemautomation mbH. The customer agrees to treat as
confidential all of the information made available to customer by Hilscher Gesellschaft für
Systemautomation mbH and rights, which were disclosed by Hilscher Gesellschaft für
Systemautomation mbH and that were made accessible as well as the terms and conditions of this
agreement itself.
The parties hereby agree to one another that the information that each party receives from the
other party respectively is and shall remain the intellectual property of said other party, unless
provided for otherwise in a contractual agreement.
The customer must not allow any third party to become knowledgeable of this expertise and shall
only provide knowledge thereof to authorized users as appropriate and necessary. Companies
associated with the customer shall not be deemed third parties. The customer must obligate
authorized users to confidentiality. The customer should only use the confidential information in
connection with the performances specified in this agreement.
The customer must not use this confidential information to his own advantage or for his own
purposes or rather to the advantage or for the purpose of a third party, nor must it be used for
commercial purposes and this confidential information must only be used to the extent provided for
in this agreement or otherwise to the extent as expressly authorized by the disclosing party in
written form. The customer has the right, subject to the obligation to confidentiality, to disclose the
terms and conditions of this agreement directly to his legal and financial consultants as would be
required for the customer's normal business operation.

Export provisions
The delivered product (including technical data) is subject to the legal export and/or import laws as
well as any associated regulations of various countries, especially such laws applicable in
Germany and in the United States. The products / hardware / software must not be exported into
such countries for which export is prohibited under US American export control laws and its
supplementary provisions. You hereby agree to strictly follow the regulations and to yourself be
responsible for observing them. You are hereby made aware that you may be required to obtain
governmental approval to export, reexport or import the product.
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Appendix 316/323

13.4 Third party software licenses

lwIP IP stack
This software package uses the lwIP software for IP stack functionality. The following licensing
conditions apply for this component:
Copyright (c) 2001-2004 Swedish Institute of Computer Science.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
4. Redistributions of source code must retain the above copyright notice, this list of conditions
and the following disclaimer.
5. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
6. The name of the author may not be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

SNMP
For SNMP functionality the PROFINET IO RT/IRT Device Protocol stack uses third party software
that is licensed under the following licensing conditions:
/***********************************************************
Copyright 1988, 1989 by Carnegie Mellon University
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of CMU not be
used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
***********************************************************/

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13.5 List of tables

Table 1: List of revisions ..................................................................................................................................................... 7
Table 2: Technical data ..................................................................................................................................................... 10
Table 3: Availability of PROFINET IO-Device stack V4 ..................................................................................................... 10
Table 4: Availability of PROFINET IO-Device stack V5 ..................................................................................................... 11
Table 5: Technical data (additional features) .................................................................................................................... 11
Table 6: Naming convention of input / output data ............................................................................................................ 14
Table 7: Overview of loadable firmware (NXLFW-PNS and NXLFW-PNS SR) ................................................................. 15
Table 8: IOPS - DataState – mode Bitwise ....................................................................................................................... 17
Table 9: IOPS - DataState – mode Bytewise .................................................................................................................... 18
Table 10: Ethernet MAC addresses .................................................................................................................................. 21
Table 11: Basic Device Data in the Flash Device Label .................................................................................................... 24
Table 12: OEM identification in the Flash Device Label .................................................................................................... 24
Table 13: Communication state......................................................................................................................................... 25
Table 14: Smalles possible Cycle Time depending using multiple ARs ............................................................................ 27
Table 15: Description of the Isochronus processes ........................................................................................................... 48
Table 16: Isochronous mode specific GSDML parameters ............................................................................................... 49
Table 17: Structure of Isochrone Mode Data Record ........................................................................................................ 50
Table 18: The individual steps of the ouput process within the isochronous application ................................................... 52
Table 19: The individual steps of the input process within the isochronous application .................................................... 53
Table 20: Trigger Event configuration ............................................................................................................................... 54
Table 21: Default configuration of trigger events ............................................................................................................... 54
Table 22 netX Synchronozation pins ................................................................................................................................. 56
Table 23: Example of the configuration of trigger events .................................................................................................. 56
Table 24: Overview: Configuring the IO-Device stack service........................................................................................... 63
Table 25: PNS_IF_SET_CONFIGURATION_REQ_T - Set Configuration request ........................................................... 70
Table 26: Structure tDeviceParameters ............................................................................................................................ 74
Table 27: System flags ...................................................................................................................................................... 76
Table 28: Structure PNS_IF_API_STRUCT_T .................................................................................................................. 77
Table 29: Structure PNS_IF_SUBMODULE_STRUCT_T ................................................................................................. 78
Table 30: PNS_IF_SET_CONFIGURATION_CNF_T – Set Configuration confirmation ................................................... 79
Table 31: OEM Parameters and their related actions ....................................................................................................... 83
Table 32: PNS_IF_SET_OEM_PARAMETERS_REQ_T - Set OEM Parameters Request ............................................... 85
Table 33: PNS_IF_SET_OEM_PARAMETERS_TYPE_3_T - Set OEM Parameter type 3 .............................................. 89
Table 34: PNS_IF_SET_OEM_PARAMETERS_TYPE_5_T – Set OEM Parameter type 5 .............................................. 90
Table 35: Coding of ulIMFlag ............................................................................................................................................ 90
Table 36: PNS_IF_SET_OEM_PARAMETERS_TYPE_6_T - Set OEM Parameter type 6 .............................................. 91
Table 37: PNS_IF_OEM_PARAMETERS_TYPE_8_T - Set OEM Parameter type 8 ....................................................... 92
Table 38: PNS_IF_OEM_PARAMETERS_TYPE_9_T - Set OEM Parameter type 9 ....................................................... 92
Table 39: PNS_IF_OEM_PARAMETERS_TYPE_10_T - Set OEM Parameter type 10 ................................................... 93
Table 40: PNS_IF_OEM_PARAMETERS_TYPE_11_T - Set OEM Parameter type 11 ................................................... 93
Table 41: PNS_IF_OEM_PARAMETERS_TYPE_12_T - Set OEM Parameter type 12 ................................................... 93
Table 42: PNS_IF_OEM_PARAMETERS_TYPE_13_T - Set OEM Parameter type 13 ................................................... 94
Table 43: PNS_IF_OEM_PARAMETERS_TYPE_16_T - Set OEM Parameter type 16 ................................................... 94
Table 44: PNS_IF_OEM_PARAMETERS_TYPE_18_T - Set OEM Parameter type 18 ................................................... 95
Table 45: PNS_IF_IM_SWVERSION_T ............................................................................................................................ 95
Table 46: PNS_IF_OEM_PARAMETERS_TYPE_19_T - Set OEM Parameter type 19 ................................................... 96
Table 47: PNS_IF_SET_OEM_PARAMETERS_CNF_T - Set OEM Parameters confirmation ......................................... 97
Table 48: PNS_IF_SET_IOXS_CONFIG_REQ_T – Set IOXS Config request ................................................................. 99
Table 49: PNS_IF_SET_IOXS_CONFIG_CNF_T – Set IOXS Config confirmation ........................................................ 100
Table 50: PNS_IF_LOAD_REMANENT_DATA_REQ_T - Load Remanent Data request .............................................. 101
Table 51: PNS_IF_LOAD_REMANENT_DATA_CNF_T - Load Remanent Data confirmation ....................................... 102
Table 52: Values Set Trigger Type service supported by the PROFINET IO-Device stack ............................................ 103
Table 53: PNS_IF_SET_CONFIGURATION_REQ_T - Set Configuration request ......................................................... 106
Table 54: Connection establishment service overview .................................................................................................... 116
Table 55: PNS_IF_AR_CHECK_IND_T - AR Check indication....................................................................................... 117
Table 56: AR Types ........................................................................................................................................................ 118
Table 57: AR Properties .................................................................................................................................................. 118
Table 58: PNS_IF_AR_CHECK_RSP_T - AR Check response ...................................................................................... 119
Table 59: PNS_IF_CHECK_IND_T - Check Indication ................................................................................................... 122
Table 60: Values of usModuleState in check indication .................................................................................................. 123
Table 61: Values of usSubmodState in check indication ................................................................................................. 123
Table 62: PNS_IF_CHECK_RSP_T - Check Response ................................................................................................. 124
Table 63: Values of usModuleState in response packet ................................................................................................. 125
Table 64: Values of usSubmodState in response packet ................................................................................................ 125
Table 65: PNS_IF_CONNECTREQ_DONE_IND_T - Connect Request Done indication ............................................... 126
Table 66: PNS_IF_CONNECTREQ_DONE_RSP_T - Connect Request Done response .............................................. 127
Table 67: PNS_IF_PARAM_END_IND_T - Parameter End indication ............................................................................ 129
PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API
DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Appendix 319/323
Table 68: PNS_IF_PARAM_END_RSP_T - Parameter End response ........................................................................... 130
Table 69: PNS_IF_APPL_READY_REQ_T - Application Ready request ....................................................................... 132
Table 70: PNS_IF_APPL_READY_CNF_T - Application Ready confirmation ................................................................ 133
Table 71: PNS_IF_AR_IN_DATA_IND_T - AR InData indication.................................................................................... 134
Table 72: PNS_IF_AR_IN_DATA_RSP_T - AR InData response ................................................................................... 135
Table 73: PNS_IF_STORE_REMANENT_DATA_IND_T - Store Remanent Data indication .......................................... 136
Table 74: PNS_IF_STORE_REMANENT_DATA_RES_T - Store Remanent Data response ......................................... 137
Table 75: Service overview of acyclic events indicated by the PROFINET IO Device stack ........................................... 138
Table 76: PNS_IF_READ_RECORD_IND_T - Read Record indication .......................................................................... 139
Table 77: PNS_IF_READ_RECORD_RSP_T - Read Record response ......................................................................... 141
Table 78: PNS_IF_WRITE_RECORD_IND_T - Write Record indication ........................................................................ 144
Table 79: PNS_IF_WRITE_RECORD_RSP_T - Write Record response ....................................................................... 146
Table 80: PNS_IF_AR_ABORT_IND_IND_T - AR Abort Indication ................................................................................ 149
Table 81: PNS_IF_AR_ABORT_IND_RSP_T - AR Abort Indication response ............................................................... 150
Table 82: PNS_IF_SAVE_STATION_NAME_IND_T - Save Station Name indication .................................................... 152
Table 83: PNS_IF_SAVE_STATION_NAME_RSP_T - Save Station Name response ................................................... 152
Table 84: PNS_IF_SAVE_IP_ADDR_IND_T - Save IP Address indication..................................................................... 154
Table 85: PNS_IF_SAVE_IP_ADDR_RSP_T - Save IP Address response .................................................................... 154
Table 86: PNS_IF_START_LED_BLINKING_IND_T - Start LED Blinking indication ...................................................... 155
Table 87: PNS_IF_START_LED_BLINKING_RSP_T - Start LED Blinking response ..................................................... 155
Table 88: PNS_IF_STOP_LED_BLINKING_IND_T - Stop LED Blinking indication ........................................................ 156
Table 89: PNS_IF_STOP_LED_BLINKING_RSP_T - Stop LED Blinking response ....................................................... 156
Table 90: PNS_IF_RESET_FACTORY_SETTINGS_IND_T - Reset Factory Settings indication ................................... 158
Table 91: Possible values of the reset code .................................................................................................................... 159
Table 92: PNS_IF_RESET_FACTORY_SETTINGS_RSP_T - Reset Factory Settings response .................................. 160
Table 93: PNS_IF_APDU_STATUS_CHANGED_IND_T - APDU Status Changed indication ........................................ 161
Table 94: APDU status field bits...................................................................................................................................... 162
Table 95: PNS_IF_APDU_STATUS_CHANGED_RSP_T - APDU Status Changed response ....................................... 162
Table 96: PNS_IF_ALARM_IND_T - Alarm Indication .................................................................................................... 163
Table 97: PNS_IF_ALARM_RSP_T - Alarm Indication response ................................................................................... 165
Table 98: PNS_IF_USER_ERROR_IND_T - Error Indication ......................................................................................... 166
Table 99: PNS_IF_USER_ERROR_RSP_T - Error Indication response ........................................................................ 166
Table 100: PNS_IF_READ_IM_IND_T – Read I&M Indication ....................................................................................... 167
Table 101: PNS_IF_READ_IM_RES_T – Read I&M response ....................................................................................... 168
Table 102: PNS_IF_IM0_DATA_T – Structure of I&M0 Information ............................................................................... 170
Table 103: PNS_IF_IM1_DATA_T – Structure of I&M1 Information ............................................................................... 170
Table 104: PNS_IF_IM2_DATA_T – Structure of I&M2 Information ............................................................................... 170
Table 105: PNS_IF_IM3_DATA_T – Structure of I&M3 Information ............................................................................... 171
Table 106: PNS_IF_IM4_DATA_T – Structure of I&M4 Information ............................................................................... 171
Table 107: PNS_IF_IM5_DATA_T – Structure of I&M5 Information ............................................................................... 171
Table 108: PNS_IF_IM0_FILTER_DATA_T – Structure of I&M0 Filter Information ........................................................ 172
Table 109: PNS_IF_WRITE_IM_IND_T – Write I&M indication ...................................................................................... 173
Table 110: PNS_IF_WRITE_IM_RES_T – Write I&M response ..................................................................................... 175
Table 111: PROFINET record index and first associated EntryNumber .......................................................................... 176
Table 112: PNS_IF_GET_ASSET_IND_T – Get Asset indication................................................................................... 178
Table 113: PNS_IF_GET_ASSET_RSP_T – Get Asset response .................................................................................. 179
Table 114: PNS_IF_ASSET_ENTRY_T .......................................................................................................................... 180
Table 115: PNS_IF_ASSET_LOCATION_T: PNS_IF_ASSET_LOCATION_LEVEL_T .................................................. 180
Table 116: PNS_IF_ASSET_LOCATION_T: PNS_IF_ASSET_LOCATION_SLOTSUBSLOT_T ................................... 181
Table 117: PNS_IF_PARAMET_SPEEDUP_SUPPORTED_IND_T – Parameterization Speedup Supported indication184
Table 118: PNS_IF_PARAMET_SPEEDUP_SUPPORTED_RES_T- Parameterization Speedup Supported response 184
Table 119: Event Indication ............................................................................................................................................. 185
Table 120: PROFINET Device stack events ................................................................................................................... 186
Table 121: Event Indication response ............................................................................................................................. 186
Table 122: ARset Status indication ................................................................................................................................. 187
Table 123: ARset Status ................................................................................................................................................. 187
Table 124: ARset Status response .................................................................................................................................. 188
Table 125: Parameter Begin indication ........................................................................................................................... 191
Table 126: Structure PNS_IF_PARAM_BEGIN_SUBMODULE_ELEM_T ...................................................................... 191
Table 127: Parameter Begin response ............................................................................................................................ 192
Table 128: Dynamic Reconfiguration indication .............................................................................................................. 193
Table 129: Dynamic Reconfiguration response............................................................................................................... 193
Table 130: Acyclic Events requested by the Application - Overview ............................................................................... 194
Table 131: PNS_IF_GET_DIAGNOSIS_REQ_T - Get Diagnosis request ...................................................................... 195
Table 132: PNS_IF_GET_DIAGNOSIS_CNF_T - Get Diagnosis confirmation ............................................................... 196
Table 133: Meaning of single Bits in ulPnsState ............................................................................................................. 197
Table 134: Values and their corresponding Meanings of ulLinkState .............................................................................. 197
Table 135: Values and their corresponding Meanings of ulLinkState .............................................................................. 198
Table 136: PNS_IF_GET_XMAC_DIAGNOSIS_REQ_T - Get XMAC (EDD) Diagnosis request.................................... 199

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Appendix 320/323
Table 137: PNS_IF_GET_XMAC_DIAGNOSIS_CNF_T - Get XMAC (EDD) Diagnosis confirmation ............................ 199
Table 138: PNS_IF_ABORT_CONNECTION_REQ_T - AR Abort Request.................................................................... 201
Table 139: PNS_IF_ABORT_CONNECTION_CNF_T - AR Abort Request confirmation ............................................... 202
Table 140: PNS_IF_PLUG_MODULE_REQ_T - Plug Module request ........................................................................... 203
Table 141: PNS_IF_PLUG_MODULE_CNF_T - Plug Module confirmation .................................................................... 204
Table 142: PNS_IF_PLUG_SUBMODULE_REQ_T - Plug Submodule request ............................................................. 207
Table 143: PNS_IF_PLUG_SUBMODULE_CNF_T - Plug Submodule confirmation ...................................................... 208
Table 144: PNS_IF_PLUG_SUBMODULE_EXTENDED_REQ_T – Extended Plug Submodule request ....................... 210
Table 145: PNS_IF_PLUG_SUBMODULE_EXTENDED_CNF_T – Extended Plug Submodule confirmation ................ 211
Table 146: PNS_IF_PULL_MODULE_REQ_T - Pull Module request ............................................................................. 213
Table 147: PNS_IF_PULL_MODULE_CNF_T – Pull Module confirmation ..................................................................... 213
Table 148: PNS_IF_PULL_SUBMODULE_REQ_T - Pull Submodule request ............................................................... 215
Table 149: PNS_IF_PULL_SUBMODULE_CNF_T - Pull Submodule confirmation ........................................................ 216
Table 150: PNS_IF_GET_STATION_NAME_REQ_T - Get Station Name request ........................................................ 217
Table 151: PNS_IF_GET_STATION_NAME_CNF_T - Get Station Name confirmation ................................................. 217
Table 152: PNS_IF_GET_IP_ADDR_REQ_T - Get IP Address request ......................................................................... 218
Table 153: PNS_IF_GET_IP_ADDR_CNF_T - Get IP Address confirmation.................................................................. 218
Table 154: PNS_IF_ADD_CHANNEL_DIAG_REQ_T - Add Channel Diagnosis request ............................................... 219
Table 155: PNS_IF_ADD_CHANNEL_DIAG_CNF_T - Add Channel Diagnosis confirmation ........................................ 220
Table 156: PNS_IF_ADD_EXTENDED_DIAG_REQ_T - Add Extended Channel Diagnosis request ............................. 221
Table 157: PNS_IF_ADD_EXTENDED_DIAG_CNF_T - Add Extended Channel Diagnosis confirmation ..................... 222
Table 158: PNS_IF_ADD_GENERIC_DIAG_REQ_T - Add Generic Channel Diagnosis request .................................. 224
Table 159: PNS_IF_ADD_GENERIC_DIAG_CNF_T - Add Generic Channel Diagnosis confirmation ........................... 226
Table 160: PNS_IF_REMOVE_DIAG_REQ_T - Remove Diagnosis request ................................................................. 227
Table 161: PNS_IF_REMOVE_DIAG_CNF_T - Remove Diagnosis confirmation .......................................................... 227
Table 162: PNS_IF_SET_SUBM_STATE_REQ–T - Set Submodule State request ....................................................... 229
Table 163: Values of usSubmState ................................................................................................................................. 229
Table 164: PNS_IF_SET_SUBM_STATE_CNF–T - Set Submodule State confirmation ................................................ 230
Table 165: PNS_IF_GET_PARAM_REQ_T - Get Parameter request ............................................................................ 231
Table 166: PNS_IF_PARAM_E - Valid parameter options .............................................................................................. 232
Table 167: PNS_IF_GET_PARAM_CNF_T - Get Parameter confirmation ..................................................................... 232
Table 168: PNS_IF_PARAM_MRP_T - MRP parameter ................................................................................................ 235
Table 169: PNS_IF_PARAM_MRP_STATE_E - Valid values for MRP state .................................................................. 235
Table 170: PNS_IF_PARAM_MRP_ROLE_E - Valid values for MRP Role .................................................................... 235
Table 171: PNS_IF_PARAM_SUBMODULE_CYCLE_T - Submodule cycle parameter ................................................. 236
Table 172: PNS_IF_PARAM_ETHERNET_T - Submodule cycle parameter .................................................................. 236
Table 173: PNS_IF_DIAGNOSIS_T - Diagnosis data ..................................................................................................... 237
Table 174: PNS_IF_DIAGNOSIS_ENTRY_T - Diagnosis entry ...................................................................................... 237
Table 175: PNS_IF_PARAM_IM0_DATA_T - Stack I&M0 record content ...................................................................... 237
Table 176: PNS_IF_PARAM_IM5_DATA_T – Stack I&M5 record content ..................................................................... 237
Table 177: PNS_IF_PARAM_PORT_STATISTIC_DATA_T – Port statistics data .......................................................... 238
Table 178: PNS_IF_ADD_PE_ENTITY_REQ–T – Add PE Entity request ...................................................................... 239
Table 179: PNS_IF_ADD_PE_ENTITY_CNF–T – Add PE Entity confirmation ............................................................... 240
Table 180: PNS_IF_REMOVE_PE_ENTITY_REQ–T – Remove PE Entity request ....................................................... 241
Table 181: PNS_IF_REMOVE_PE_ENTITY_CNF–T – Remove PE Entity confirmation ................................................ 242
Table 182: PNS_IF_UPDATE_PE_ENTITY_REQ–T – Update PE Entity request .......................................................... 243
Table 183: PNS_IF_UPDATE_PE_ENTITY_CNF–T – Update PE Entity confirmation................................................... 244
Table 184: PNS_IF_SEND_ALARM_REQ_T Send Alarm request ................................................................................. 245
Table 185: Valid values for Alarm Type .......................................................................................................................... 247
Table 186: Valid values for User Structure Identifier ....................................................................................................... 247
Table 187: Alarm data definition...................................................................................................................................... 248
Table 188: Upload and Retrieval structure definition ....................................................................................................... 248
Table 189: Valid value for Upload and Retrieval Alarm Subtype ..................................................................................... 249
Table 190: Upload and Retrieval Record Data Description ............................................................................................. 249
Table 191: Channel coding structure definition ............................................................................................................... 249
Table 192: Values for usReason ..................................................................................................................................... 250
Table 193: Values for usExtReason ................................................................................................................................ 251
Table 194: Length and values for abReasonAddValue ................................................................................................... 252
Table 195: PNS_IF_SEND_ALARM_CNF_T - Send Alarm confirmation ........................................................................ 252
Table 196: Fields of I&M0 ............................................................................................................................................... 259
Table 197: Parameters of the I&M0 object ...................................................................................................................... 262
Table 198: LED tag list parameter (PNSV4).................................................................................................................... 264
Table 199: PROFINET Product Information tag list parameter (PNSV4) ........................................................................ 264
Table 200: Tag list parameter (PNSV5) .......................................................................................................................... 265
Table 201: Tag list parameter (PNSV5) .......................................................................................................................... 266
Table 202: Tag list parameter (PNSV5) .......................................................................................................................... 267
Table 203: Tag list parameter (PNSV5) .......................................................................................................................... 268
Table 204: Keywords ...................................................................................................................................................... 270
Table 205: Common status codes ................................................................................................................................... 278

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

DOC171101API05EN | Revision 5 | English | 2021-10 | Released | Public © Hilscher, 2006‑2021
Appendix 321/323
Table 206: PROFINET core ............................................................................................................................................ 278
Table 207: PROFINET IO-Device interface task ............................................................................................................. 292
Table 208: Socket API error codes ................................................................................................................................. 293
Table 209: Coding of PNIO status ErrorCode (Excluding reserved values) .................................................................... 295
Table 210: Coding of PNIO status ErrorDecode (Excluding reserved values) ................................................................ 295
Table 211: Coding of ErrorCode1 for ErrorDecode = PNIORW (Excluding reserved values) ......................................... 296
Table 212: Coding of ErrorCode1 for ErrorDecode = PNIO (Excluding reserved values) ............................................... 302
Table 213: Generic AP .................................................................................................................................................... 304
Table 214: Coding of the field Channel Properties .......................................................................................................... 305
Table 215: Coding of the field data type in field Channel Properties ............................................................................... 305
Table 216: Coding of the field Maintenance in field Channel Properties ......................................................................... 305
Table 217: Coding of the field Direction in field Channel Properties ............................................................................... 306
Table 218: Coding of Channel error type ........................................................................................................................ 307
Table 219: Coding of Extended channel error type for Channel Error Type 1 - 0x7FFF ................................................. 307
Table 220: Coding usExtChannelErrType in conjunction with Data transmission impossible error type ......................... 308
Table 221: Coding of Extended error Type in conjunction with Remote Mismatch error type ......................................... 308
Table 222: Coding of Extended error Type in conjunction with Sync Mismatch error type .............................................. 308
Table 223: Coding of Extended error Type in conjunction with Fiber optic mismatch error type ..................................... 308
Table 224: Object identifier of LLDP ............................................................................................................................... 311
Table 225: Object identifier of PNO ................................................................................................................................. 312
Table 226: Object identifier of LLDP 802.3 extension ..................................................................................................... 312
Table 227: Object identifier of the System and Interface MIB ......................................................................................... 312

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13.6 List of figures

Figure 1: Firmware structure ............................................................................................................................................. 19
Figure 2: System Redundancy .......................................................................................................................................... 31
Figure 3: Application interface ........................................................................................................................................... 32
Figure 4: System Redundancy sequence ......................................................................................................................... 33
Figure 5: Switch to primary................................................................................................................................................ 34
Figure 6: Switch to Backup................................................................................................................................................ 35
Figure 7: PrimaryFault ....................................................................................................................................................... 36
Figure 8: Redundancy Data Hold Time ............................................................................................................................. 38
Figure 9: Dynamic Reconfiguration – Init state.................................................................................................................. 40
Figure 10: Dynamic Reconfiguration – Step 1 ................................................................................................................... 40
Figure 11: Dynamic Reconfiguration – Step 2 ................................................................................................................... 41
Figure 12: Dynamic Reconfiguration – Step 3 ................................................................................................................... 42
Figure 13: Dynamic Reconfiguration – Step 4.1 ................................................................................................................ 43
Figure 14: Dynamic Reconfiguration – Step 4.2 ................................................................................................................ 44
Figure 15: Dynamic Reconfiguration – Step 4.3 ................................................................................................................ 45
Figure 16: Dynamic Reconfiguration – Step 5 ................................................................................................................... 46
Figure 17: Dynamic Reconfiguration – Step 6 ................................................................................................................... 46
Figure 18 Isochronous application processes ................................................................................................................... 47
Figure 19: Isochronous Output Process ............................................................................................................................ 52
Figure 20 Isochronous Input Process ................................................................................................................................ 53
Figure 21: Configuration sequence of Trigger Events ....................................................................................................... 55
Figure 22: Hardware synchronization using xC-Trigger events ......................................................................................... 56
Figure 23: Provider process data structure ....................................................................................................................... 65
Figure 24: Consumer process data structure .................................................................................................................... 66
Figure 25: IO-Device configuration sequence ................................................................................................................... 68
Figure 26: Register Application service packet sequence ................................................................................................. 80
Figure 27: DPM input trigger event ................................................................................................................................. 104
Figure 28: DPM Output trigger event .............................................................................................................................. 104
Figure 29: DPM Sync trigger event ................................................................................................................................. 105
Figure 30: Configure trigger events ................................................................................................................................. 108
Figure 31: Initial configuration: DCP Set NameOfStation (by engineering tool) .............................................................. 109
Figure 32: Initial configuration: DCP Set NameOfStation (by controller) ......................................................................... 110
Figure 33: Initial configuration: DCP Set IP ..................................................................................................................... 111
Figure 34: Connection Establishment: Connect .............................................................................................................. 112
Figure 35: Connection Establishment: Write Parameter ................................................................................................. 113
Figure 36: Connection Establishment: Parameter End and Application Ready ............................................................... 114
Figure 37: Check Service Packet sequence for non-adapting applications ..................................................................... 120
Figure 38: Check Service Packet sequence for adapting applications ............................................................................ 121
Figure 39: Save Station Name: Application state diagram .............................................................................................. 151
Figure 40: Save IP Address: Application state diagram .................................................................................................. 153
Figure 41: Get Asset service ........................................................................................................................................... 176
Figure 42: Parameter Begin sequence ............................................................................................................................ 190
Figure 43: Plug Submodule: packet sequence ................................................................................................................ 205
Figure 44: Pull Module: packet sequence ....................................................................................................................... 212
Figure 45: Pull Submodule: packet sequence ................................................................................................................. 214
Figure 46: Vendor and device identification in the GSDML file ....................................................................................... 255
Figure 47: Structural organization of I&M records within a Device and the access paths ............................................... 260
Figure 48: Structure of the PROFINET status code ........................................................................................................ 294

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

13.7 Contacts

Headquarters

Germany
Hilscher Gesellschaft für
Systemautomation mbH
Rheinstrasse 15
65795 Hattersheim
Phone: +49 (0) 6190 9907-0
Fax: +49 (0) 6190 9907-50
E-Mail: info@hilscher.com
Support
Phone: +49 (0) 6190 9907-99
E-Mail: de.support@hilscher.com

Subsidiaries

China Japan
Hilscher Systemautomation (Shanghai) Co. Ltd. Hilscher Japan KK
200010 Shanghai Tokyo, 160-0022
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: info@hilscher.cn E-Mail: info@hilscher.jp
Support Support
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: cn.support@hilscher.com E-Mail: jp.support@hilscher.com

France Korea
Hilscher France S.a.r.l. Hilscher Korea Inc.
69800 Saint Priest Seongnam, Gyeonggi, 463-400
Phone: +33 (0) 4 72 37 98 40 Phone: +82 (0) 31-789-3715
E-Mail: info@hilscher.fr E-Mail: info@hilscher.kr
Support
Phone: +33 (0) 4 72 37 98 40 Switzerland
E-Mail: fr.support@hilscher.com Hilscher Swiss GmbH
4500 Solothurn
India Phone: +41 (0) 32 623 6633
Hilscher India Pvt. Ltd. E-Mail: info@hilscher.ch
Pune, Delhi, Mumbai Support
Phone: +91 8888 750 777 Phone: +49 (0) 6190 9907-99
E-Mail: info@hilscher.in E-Mail: ch.support@hilscher.com

Italy USA
Hilscher Italia S.r.l. Hilscher North America, Inc.
20090 Vimodrone (MI) Lisle, IL 60532
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: info@hilscher.it E-Mail: info@hilscher.us
Support Support
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: it.support@hilscher.com E-Mail: us.support@hilscher.com

PROFINET IO-Device V4.6.0 / V5.4.0 | Protocol API

CTC User Manual Edition 11.0
100% (2)
CTC User Manual Edition 11.0
743 pages
Ccna Brush Up Notes
100% (6)
Ccna Brush Up Notes
215 pages
FXD User Manual - EN-2020-3-6-300dpi
71% (7)
FXD User Manual - EN-2020-3-6-300dpi
58 pages
KL 310
No ratings yet
KL 310
4 pages
Lacie Network Space Family User Manual
No ratings yet
Lacie Network Space Family User Manual
173 pages
CifX ComX NetJACK Configuration by NetX Configuration Tool OI 06 en
No ratings yet
CifX ComX NetJACK Configuration by NetX Configuration Tool OI 06 en
190 pages
25869132
No ratings yet
25869132
60 pages
RFID
No ratings yet
RFID
232 pages
El600x El602xen PDF
No ratings yet
El600x El602xen PDF
207 pages
EtherCAT_Master_DTM_OI_07_EN
No ratings yet
EtherCAT_Master_DTM_OI_07_EN
168 pages
VCSCF Desciption
No ratings yet
VCSCF Desciption
92 pages
Phoenix Contact Inliner Couple
No ratings yet
Phoenix Contact Inliner Couple
148 pages
Ecomat 100 Mobile Cr0301
No ratings yet
Ecomat 100 Mobile Cr0301
213 pages
CC2540 and CC2541 Bluetooth Low Energy Software Developers PDF
No ratings yet
CC2540 and CC2541 Bluetooth Low Energy Software Developers PDF
154 pages
OpenScape Contact Center AgileEnterprise V11 IVR API Integration Guide Issue 1
No ratings yet
OpenScape Contact Center AgileEnterprise V11 IVR API Integration Guide Issue 1
75 pages
En Device Center User Manual
No ratings yet
En Device Center User Manual
91 pages
Manual Master
No ratings yet
Manual Master
147 pages
Atm Srs
No ratings yet
Atm Srs
12 pages
Fiche utilisation topspin (analyseur RMN et autres spectres)
No ratings yet
Fiche utilisation topspin (analyseur RMN et autres spectres)
106 pages
KST ConveyorTech 80 en NT
No ratings yet
KST ConveyorTech 80 en NT
132 pages
CANopen_Master_DTM_OI_14_EN
No ratings yet
CANopen_Master_DTM_OI_14_EN
157 pages
Eurotech Manual
No ratings yet
Eurotech Manual
77 pages
cap505_icEN
No ratings yet
cap505_icEN
98 pages
7391000UK
No ratings yet
7391000UK
233 pages
3HAC078375 AM IoT Gateway-En
No ratings yet
3HAC078375 AM IoT Gateway-En
166 pages
Cdhde Ethercat Fw2.1.x Rev.0.0.1-En
No ratings yet
Cdhde Ethercat Fw2.1.x Rev.0.0.1-En
255 pages
ROBOTICS. Application Manual PROFINET Controller - Device
No ratings yet
ROBOTICS. Application Manual PROFINET Controller - Device
88 pages
Hb140e Cpu 315-4ne23 18-01
No ratings yet
Hb140e Cpu 315-4ne23 18-01
211 pages
Mipi RFFE Specification v1-10
No ratings yet
Mipi RFFE Specification v1-10
90 pages
Sercos Slave DTM OI 05 EN
No ratings yet
Sercos Slave DTM OI 05 EN
189 pages
DVG 6001G User Manual v1.0
100% (1)
DVG 6001G User Manual v1.0
55 pages
XS/SC26-2 Safety Controller: Instruction Manual
No ratings yet
XS/SC26-2 Safety Controller: Instruction Manual
124 pages
R67070.0002 6 HB CANopen-Schnittstelle Kuebler en
No ratings yet
R67070.0002 6 HB CANopen-Schnittstelle Kuebler en
140 pages
Programming Manual CR0411 PDF
No ratings yet
Programming Manual CR0411 PDF
242 pages
KUKA.ForceTorqueControl_40_en
No ratings yet
KUKA.ForceTorqueControl_40_en
95 pages
KST UserTech 40 en
No ratings yet
KST UserTech 40 en
92 pages
Iso-iec 8473-1 Protocol for Connection Less Mode Network Service
No ratings yet
Iso-iec 8473-1 Protocol for Connection Less Mode Network Service
64 pages
TH Scope U v3 70-1 en
No ratings yet
TH Scope U v3 70-1 en
66 pages
Hb300e Im 053-1ec00 16-49 01
No ratings yet
Hb300e Im 053-1ec00 16-49 01
68 pages
NetX Studio CDT - NetX 90 Development GS 08 en
No ratings yet
NetX Studio CDT - NetX 90 Development GS 08 en
220 pages
3HAC032104-En (Robot Studio Manual)
No ratings yet
3HAC032104-En (Robot Studio Manual)
594 pages
ITEM 8 VCTA-A410(En_Edit)_英文版
No ratings yet
ITEM 8 VCTA-A410(En_Edit)_英文版
86 pages
Visual OPC Server NET Developer Guide
No ratings yet
Visual OPC Server NET Developer Guide
94 pages
PROFINET_IO_Controller_DTM_OI_13_EN
100% (1)
PROFINET_IO_Controller_DTM_OI_13_EN
193 pages
Ether Net IP
No ratings yet
Ether Net IP
91 pages
5G Core Network Product Information
No ratings yet
5G Core Network Product Information
49 pages
P-Tile Avalon Streaming IP For PCI Express User Guide
No ratings yet
P-Tile Avalon Streaming IP For PCI Express User Guide
222 pages
Riscv Platform Spec
No ratings yet
Riscv Platform Spec
28 pages
Wago Pfc200mane
No ratings yet
Wago Pfc200mane
460 pages
KST ConveyorTech 50 en
No ratings yet
KST ConveyorTech 50 en
57 pages
CodeMeter AdminManual En
No ratings yet
CodeMeter AdminManual En
119 pages
Rollmax Digital Signal Processor DSP2 (Version B) User's Manual
No ratings yet
Rollmax Digital Signal Processor DSP2 (Version B) User's Manual
235 pages
Io-Link To Ethernet/Ip and Modbus TCP Gateway: User Manual
No ratings yet
Io-Link To Ethernet/Ip and Modbus TCP Gateway: User Manual
94 pages
TF8040 TC3 Building Automation En
No ratings yet
TF8040 TC3 Building Automation En
689 pages
Slio Pulse Input - Hb300e_fm_054-1da00!18!07
No ratings yet
Slio Pulse Input - Hb300e_fm_054-1da00!18!07
144 pages
OpenScape Voice V9, SIP To SP Interface Manual
No ratings yet
OpenScape Voice V9, SIP To SP Interface Manual
155 pages
ConveyorTech KR C2
No ratings yet
ConveyorTech KR C2
73 pages
3HAC050969 en
No ratings yet
3HAC050969 en
78 pages
Festo CMMT PN Lib EN
100% (2)
Festo CMMT PN Lib EN
41 pages
Infineon-AN228680 - Secure - System - Configuration - in - TRAVEO - TM - T2G - family-ApplicationNotes-v07 - 00-EN 1
No ratings yet
Infineon-AN228680 - Secure - System - Configuration - in - TRAVEO - TM - T2G - family-ApplicationNotes-v07 - 00-EN 1
90 pages
S60 Smartphone Quality Assurance: A Guide for Mobile Engineers and Developers
From Everand
S60 Smartphone Quality Assurance: A Guide for Mobile Engineers and Developers
Saila Laitinen
No ratings yet
Antenna Arraying Techniques in the Deep Space Network
From Everand
Antenna Arraying Techniques in the Deep Space Network
David H. Rogstad
No ratings yet
Internet Technologies Handbook: Optimizing the IP Network
From Everand
Internet Technologies Handbook: Optimizing the IP Network
Mark A. Miller
No ratings yet
LTBT Aie Supervisor
No ratings yet
LTBT Aie Supervisor
2 pages
Siemens S7-200 Communication Settings
No ratings yet
Siemens S7-200 Communication Settings
14 pages
Bashrc - SFTP Gives An Error Received Message Too Long and What Is The Reason - Unix & Linux Stack Exchange
No ratings yet
Bashrc - SFTP Gives An Error Received Message Too Long and What Is The Reason - Unix & Linux Stack Exchange
8 pages
latestlog (2)
No ratings yet
latestlog (2)
10 pages
CLF-C02 Exam Guide Slides
No ratings yet
CLF-C02 Exam Guide Slides
1,113 pages
Homework 9
No ratings yet
Homework 9
3 pages
Embedded Systems
No ratings yet
Embedded Systems
19 pages
System Health Check Training 19 March 2015: By: Aslaily Abd Manan
No ratings yet
System Health Check Training 19 March 2015: By: Aslaily Abd Manan
17 pages
SFTP Setup
100% (1)
SFTP Setup
3 pages
Veeam v10/11 Integration
No ratings yet
Veeam v10/11 Integration
99 pages
Arista Design Guide DCI With VXLAN
100% (1)
Arista Design Guide DCI With VXLAN
34 pages
(1Z0-1042) Oracle Cloud Platform Application Integration 2019 Associate
67% (3)
(1Z0-1042) Oracle Cloud Platform Application Integration 2019 Associate
14 pages
SAP SUM (Software Update Manager) Upgrade Phases
No ratings yet
SAP SUM (Software Update Manager) Upgrade Phases
16 pages
Motherboard AIMB-272man
No ratings yet
Motherboard AIMB-272man
114 pages
Lab2 DMS and SCT Guide
No ratings yet
Lab2 DMS and SCT Guide
12 pages
Debug 1214
No ratings yet
Debug 1214
3 pages
Oscam Sky
No ratings yet
Oscam Sky
2 pages
Short Notes On Software and Hardware
No ratings yet
Short Notes On Software and Hardware
2 pages
Exp8 MCN
No ratings yet
Exp8 MCN
3 pages
7th Standard
No ratings yet
7th Standard
89 pages
Hardware Pendukung Teramedik - Klinik Kijang
No ratings yet
Hardware Pendukung Teramedik - Klinik Kijang
8 pages
Splunk Queiries
No ratings yet
Splunk Queiries
1 page
NC Explorer Instruction Manual
No ratings yet
NC Explorer Instruction Manual
58 pages
WWW - Manaresults.co - In: Computer Networks
No ratings yet
WWW - Manaresults.co - In: Computer Networks
1 page
RTI Control Processor Comparison
No ratings yet
RTI Control Processor Comparison
1 page
XP Installation 34 Minute Hiccup
No ratings yet
XP Installation 34 Minute Hiccup
1 page
TCP V2
No ratings yet
TCP V2
386 pages