1.

Obtaining diagnostic data

This section explains how to obtain diagnostic data from the network so
engineers at NDC can help resolve any issues that may arise.

1.1 Setting up Network Connection

The following is a representation of a typical network found onsite.

Device Device Device

Switch Siemens
PLC

Device Device ,5*DXJH

Our intention is to tap into all traffic that the Siemens PLC can see.

This is achieved by mirroring all traffic at the Ethernet port on the Siemens
PLC.

Below a representation of a managed switch can be seen.

Managed Switch

1 2 3 4 5 6 7 8

Refer to the managed switch manual to configure the switch so that all traffic
on Port 2 is mirrored onto Port 1. (Highlighted in Orange)

Page 1
 Managed Switch

1 2 3 4 5 6 7 8

PC running Siemens
Wireshark PLC

Disconnect the PLC from the network and connect it to port 2 of the managed
switch.

Connect the PC running WireShark to Port 1.

Now all traffic on Port 2 (PLC) will be mirrored on Port 1 (Wireshark PC).

Managed Switch
Device Device Device

1 2 3 4 5 6 7 8

Switch

PC running Siemens Device Device ,5*DXJH

Wireshark PLC

Now complete the network by connecting the rest of the network to the
managed switch, Ports 3-8 can be used for this purpose.

Page 2
1.2 Collecting Wireshark Data

Download and install wireshark from http://www.wireshark.org/download.html

Run and select Capture / Interfaces…

The following should appear, click start on the adapter that is connected to the
Managed Switch.

Page 3
You should see something like the following after capture has stopped.

Page 4
1.3 Analyzing PROFINET Protocol

Filters can be applied to the wireshark capture, typing pndcp into the filter text
box and pressing apply will filter all capture data to only show profinet io dcp
packets.

1. The controller will attempt to look for the PROFINET device using the
name given by the S7 project (Filter pndcp)
2. Try looking for Name of Station “xlyh” (No. Packet 158148)
3. The response can be seen in packet 158229

Trouble Shoot, if response packet cannot be found, this can indicate that
no gauge can be found, check S7 project and the Gauge both have the
correct device name.
If multiple responses to the packet can be seen then two Devices are
using the same name. Make sure that every device has a unique device
name.

Page 5
The response contains the IP address of the Gauge, this information is
used later by the PLC to check if the PLC needs to send the gauge a
request for it to change its IP address.

After a predetermined time, the PLC will send a broadcast message on the
network requesting a reply to who current has the ip address of “xlyh”
which has been setup in the Simantic S7 project. (10.155.26.44)

This can be checked by enabling adding arp to the filter.

(Filter pndcp or arp)

Packet number 174097 shows that the PLC is requesting who has
10.155.26.44.
Packet number 174102 shows that the Gauge is responding to the request
and stating that it is at IP address 10.155.26.44.

Troubleshoot, If there are 2 responses to an ARP request, there is an

IP conflict.
If no ARP response is seen, the siemens PLC will send a pndcp setip
request and change the device named “xlyh” to the correct IP.

Page 6
Start of IP Hand Shake

We can now filter by IP address of the gauge (Filter ip.addr eq

10.155.26.44)

If all 6 PNIO-CM messages are not OK, there likely are problems

Possible Problems
Odd PROFINET Controller Name, Refer to Instructions on Changing the
Profinet IO Line.docx

PLC Firmware is not PROFINET compliant

Page 7
 CMInitiatorUDPRTPort should be 0x8892 or in the range 0xC000 –
0xFFFF
To rectify, use the at least gaugecode 1v3v8 which is more tolerant to non
PROFINET compliant controllers.

By applying data filter of the MAC Address of the Gauge, we can see all data
except broadcast data.

The example below shows filters the data by source and destination Mac
Adress.

The image above shows the data is valid and is running OK, All data sent and
received from the PLC states (Valid, Primary, Ok, Run)

Anything else shows a problem.

Page 8