Introduction

This application note, gives an overview about how to start troubleshooting when commissioning a PROFINET network.

It shows the most common issues, when configuring a PROFINET IO Controller or IO Device, as well as the physical aspects.

PROFINET IO Controller-specific diagnosis

This topic shows how to identify communication issues, using the diagnosis in Sycon.net and by analyzing Wireshark traces.

For more information about how to capture a PROFINET Wireshark trace, please follow this link:

Capturing PROFINET with Wireshark

The Diagnosis in Sycon.net can be opened by right-clicking to the IO Controller → Connect → open diagnosis

General diagnosis

The general diagnosis shows the current communication state, as well as "Communication error" Codes.

The definition of all error codes can be found here:

Hilscher status and error codes

This screenshot shows a fully working communication:

Name of Station

When using PROFINET, the identification of the IO Devices is made by the "Name of station".

Concerning the "Name of station", the Controller sets the IP-address for further communication via the protocol DCP.

When configuring an IO Controller in Sycon.net, the "Name of station" of each IO Device is defined in the "Device Table":

The IP-address is defined in the "IP Address Table":

The following steps occur during the establishment of a PROFINET communication:

1. Ident Reqest → The IO Controller searches for the IO Device using the NameOfStation.
2. Ident OK → The IO Device confirms that it has the NameOfStation, the IO Controller is searching for.
3. Set Request → The IO Controller sets an IP-address of the IO Device with the matching NameOfStation
4. Set OK → the IO Device confirms that the IP-address is set.
5. Connection → Now that every IO Device is reachable via the IP-address, defined by the IO Controller, the connection can be established.

If the Name of station of the IO Device does not fit the IO Controller's configuration, the following diagnosis is shown in Sycon.net:

In a Wireshark trace, a non responded Ident Request can be seen:

DAP Configuration

A GSDML file may contain multiple IO Devices or Firmware Versions. Each device, or Firmware version, is represented by one Device Access Point (DAP).

If the Device Access Point does not match the IO Device, the connection will fail.

If the DAP does not match the current device, Sycon.net will indicate, that a slave diagnosis available:

A wrong DAP can also indicate that a wrong GSDML file is used.

To check for the right GSDML file, the AutomaticNetworkScan can be used.

Wireshark analysis (ModuleDiffBlock)

If the DAP does not fit the current device, it will show a "ModuleDiffBlock" in the IO Devices "Connect response" telegram.

The ModuleDiffBlock shows which module does not match the expected configuration:

The "Connect request", shows the expected configuration for each Slot.

In this example, when opening the detailed information in the "ExpectedSubmoduleBlockReq" for Slot 0x0, a difference between the Ident numbers in the ModuleDIffBlock and the ExpectedSubmoduleBlockReq can be seen:

Module configuration

The definition of the module configuration for the IO Controller, always needs to match with the actual configuration of the IO Device.

Otherwise, it will end in a diagnostic state of the IO Device or even with a nonworking communication.

In the following example, the module configuration does not fit the connected IO Device.

The Input and Output modules have been swapped.

The IO Device reports a diagnosis:

Wireshark analysis (ModuleDiffBlock)

If the module configuration does not match the IO Devices configuration, it will show a "ModuleDiffBlock" in the IO Devices "Connect response" telegram.

The ModuleDiffBlock shows, which module does not match the expected configuration:

When opening the detailed information in the "ExpectedSubmoduleBlockReq" for Slot 0x1 and Slot 0x2, a difference between the Identifier information in the ModuleDiffBlock and the ExpectedSubmoduleBlockReq can be detected:

Automatic Network Scan

In case a manual configuration does not result in a working communication, an automatic configuration using the "Network Scan" can be used.

It can also be used to find out, if any Slave is available on the bus or if the imported GSDML file fits to the connected device.

To start the network scan, please right-click to the IO Controller in Sycon.net and select "Network Scan...".

Please note that an "empty" configuration needs to be loaded to the device. If there has not been any configuration downloaded until now, first right click → Download.

Check for GSDML File

If any PROFINET IO Device is reachable on the network, it will be listed in the upcoming window.

A fitting GSDML file (if the correct one is imported to Sycon.net), will automatically be assigned to the device, by comparing the Device Type ID (marked yellow):

Since a GSDML File can contain information about several Firmware versions, the current Version within the GSDML can be selected in the section "DTM Device".

If no fitting GSDML file is available, the window shows the following:

In this case, please check the used GSDML file. GSDML-Files for each PROFINET IO Device are provided by the manufacturer.

Module Configuration

After clicking "Create Devices", the Module configuration of the IO Device can be read out automatically, by accepting the upcoming window:

If the upload has been succeeded, the following message appears in the Output Window:

When opening the IO Device configuration, the uploaded modul configuration will be shown under "Modules".

Some devices do not send clearly recognizable configuration data.

In this case, the module configuration needs to be set manually.

The IO Monitor is used to send and receive IO Data, to check the current communication.

It does only work if a communication is already successfully established.

Please note, that when using the Firmware V3, the Statusbytes IOCS and IOPS are no longer handled automatically.

The following Application note describes the background and handling in detail:

PROFINET IO Controller V3 - IOCS / IOPS [EN]

Process Image Monitor

The Process Image Monitor allows seeing the incoming and outgoing data from a specific IO Device and Slot.

PROFINET switch diagnosis

The PROFINET switch diagnosis provides information about received and sent data within Port 1 and 2 of the Ethernet Port.

It can be used to identify issues caused by discarded packets.

Logbook

PROFINET provides information about any PROFINET related alarm and error, by providing logbook entries.

Sycon.net displays some "most recent logbook entries", in the IO Controller diagnosis, which may help analyze upcoming issues during communication.

PROFINET Device-specific configurations

Parameter settings

Some slave need special parameter settings, which can be changed in the "Parameter" area, for each slot.

A typical example is when configuring a Siemens ET 200SP Device, where the potential group needs to be set (dark or light one):

PROFINET IO Device-specific diagnosis

This topic shows how to identify communication issues using the diagnosis is Sycon.net and by analyzing Wireshark traces.

For more information about how to capture a PROFINET Wireshark trace, please follow this link:

Capturing PROFINET with Wireshark

The Diagnosis in Sycon.net can be opened by "rights click to the IO Device → Connect → open diagnosis"

General diagnosis

The general diagnosis shows the current communication state, as well as "Communication error" codes.

The definition of all error codes can be found here:

Hilscher status and error codes

This screenshot shows a fully working communication:

Name of Station

The IP-address of the PROFINET IO Device is set by the IO Controller using the protocol DCP.

For the first identification of the IO Device, the IO Controller searches for a Device with the NameOfStation, defined in the Controller's configuration.

Therefore, the NameOfStation of the IO Device needs to be set correctly, according to the Controller's configuration.

The current NameOfStation of a device can be checked and changed using the Ethernet Device Configuration Tool (https://hilscher.atlassian.net/wiki/display/ETHDEVCFG/).

To be able to find all devices in the PROFINET Network using the Ethernet Device Configuration Tool, the PROFINET network needs to be connected to a network adapter on the corresponding PC.

The NameOfStation is visible after a scan ("Search Device") in the column "Device Name", as shown below:

If no devices can be found, please check the following Application Note:

Ethernet Device Configuration Tool - cannot find device [EN]

Select DAP and DTM

Since the Configuration DTM as well as the DAP (Device Access Point) can vary between different Firmware versions, it is important to select the correct DTM for configuration of a Stand-alone-Slave.

Please always select the correct version (according to the Firmware version) from the device catalog.

This screenshot gives an overview to the available DTMs for CIFX cards:

If this does not match the currently used Firmware, it may cause configuration issues or show a "ModuleDiffBlock" when trying to establish a communication to an IO Controller

→ also see DAPConfiguration

Module Configuration

The Module Configuration of the PROFINET IO Device, always need to be equal to the IO Controller's configuration.

Please take a look at the following topic, to find out more about the possible diagnosis, when having a different configuration: Moduleconfiguration

Several Diagnostics

IP Information

The IP Information diagnosis provides information about the current IP settings.

Since the IP-Address needs to be set by the IO Controller (depending on the configured NameOfStation), this information can be used to find out if the IO Controller has been able to find the device and set an IP-address.

Extended Diagnosis Information

The Extended Diagnosis can be used to see, if an Ident Request has been addressed to the IO Device, and how often this happened.

In a working communication, The Ident Request counter should count up each time the Communication has been disconnected and connected again.

The "DCP SET Request Received" only counts up once, when the IO Controller sets the IP-address to the IO Device.

The IP-address still persists, even if the communication is disconnected and connected again. It only needs to be set again after a restart of the IO Device.

Cabling

PROFINET uses 100BaseTX technology, supporting up to 100 Mb/s.

It uses two shielded copper cable pairs, which are twisted in pairs (STP = Shielded Twisted Pair).

Only shielded cables and connecting elements are permitted.

The Cable must meet at least the requirements of Cat 5 according to IEC 11801.

ISO/IEC 11801-5: Cabling for high-performance networks used by data centers

The complete transmission path must meet the requirements of class D according to IEC 11801.

Class D: Link/channel up to 100 MHz, with Category 5e cable / connector

The maximum cable length, from one PROFINET member to the other, shall not exceed 100 m.

The cabling shall uniformly meet AWG 22 (American Wire Gauge)

Cable Types

There are several types of PROFINET cables available, for different working environments:

TYP A

Fixed installation, no movement after installation

TYP B

Flexible, random movement or vibration

TYP C

Special applications: highly flexible, permanent movement (e.g. drag chain)

Optical Fiber

Galvanic isolation, immunity to extreme EMC requirements, long transmission distances without amplifiers (several kilometers).

Connectors

PROFINET does provide the following connection options:

IP 20

Contact protection, not protected against water and moisture.

IP 65 / 67

Dustproof, protection against water jets (nozzle) from any angle / dustproof, protection against temporary immersion

PROFINET Functionalities

Shared Device

With Shared Device, several IO Controllers can access I/O Modules of an IO Device.

Consequently, the device needs to support this feature.

One indication for a Device to support Shared Device, is the following entry in the GSDML File:

The maximum number of Application Relations for an IO Device, is shown in the following Entry:

This means, in the exemplary entry shown above, only 2 Controller can communicate to a Shared Device on side.

When using a shared device, each module can only be owned by one IO Controller.

This also applies to the DAP. In other words: The "full access" to the available Slots (or modules) of an IO Device needs to be split to each IO Controller.

Example

In this example, an IO Device with DAP and 4 IO slots is used together with 2 CIFX Cards working as PROFINET IO Controller.

It shows how the configuration needs to be set, using Sycon.net.

The first IO Controller obtains Slot 0 (DAP), Slot 1 and Slot 3.

The second IO Controller obtains Slot 2 and 4.

MRP - Media Redundancy Protocol

This protocol allows a ring topology for media redundancy.

MRP prevents broadcast storms in a ring topology and ensures a recovery time of up to 10ms in case a device failure or connection issue inside the ring network.

If one wire breaks, MRP can route to a second road.

To use MRP, all devices in a PROFINET network need to support at least MRP-Client.

Whether a Device supports MRP, can be identified in the GSDML file. If MRP Client is supported, the following entry should be present:

One (mostly the IO Controller), needs to support the MRP-Manager function.

In the IO Controller configuration, a fixed topology must be defined as well as the MRP Role.

Example

The following example shows the Configuration of MRP in Sycon.net with a CIFX Card as IO Controller, using the Topology view.

The Topology View can be opened with a right click to the IO Controller DTM → Topology Editor.

In this screenshot, a fixed topology has been defined for the Ring-network as well as the MRP Role of the IO Controller:

The MRP role, needs to be defined for each IO Device:

IRT - Isochronous-Real-Time

IRT makes isochronous communication possible.

The difference to real-time communication is essentially the determinism, which means that there is a high compliance of a bus cycle.

Data exchange cycles are usually in the range from a few hundred microseconds to a millisecond, the beginning of a bus cycle can differ by a maximum of 1 µs.

These properties are often required in motion control applications.

IRT is only supported by Hilscher IO Controller Firmware, using Stack version V3 and later.

When using such Firmware, the Statusbytes IOCS and IOPS are no longer handled automatically by the stack.

For further details, please take a look at the following Application Note:

PROFINET IO Controller V3 - IOCS / IOPS [EN]