Ableitung der Aktualisierungszeit für eine PROFINET IO aus einer Wireshark-Messung

[svkers]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich sitze gerade über einer Wireshark-Aufzeichnung einer PROFINET-Anlage und versuche aus dieser die Aktualisierungszeiten der SPS-IO-Kommunikationen abzuleiten.
Mein aktueller Kenntnisstand war der, dass dieser aus den CycleCounter zwei unmittelbarer PNIO-Frames nach folgender Formel errechnet werden kann:

Aktualisierungszeit = (CycleCounter von Frame 2 - CycleCounter von Frame 1) * 31.25us

In der aktuellen Wireshark-Aufzeichnung funktioniert dieser Ansatz leider nicht, sondern ergibt seltsame Werte (z.B. 48750us). Aus dem dazugehörigen STEP7-Projekt weiß ich, dass der Aktualisierungszyklus aber 8ms ist, was ich auch anhand der von Wireshark aufgezeichneten Timestamps der Pakete ableiten kann. Bei den Frames handelt es sich um RTC1(legacy) mit FrameId=0xc010 und DataStatus=0x1f (Frame: Valid and Primary, Provider: Problem and Run).

Woran liegt das? Hat jemand eine Idee? Kann das an dem DataStatus (Problem and Run) liegen?

Vielen Dank für Eure Hilfen!
Viele Grüße,
sk

 

[Thomas_v2.1]

Vom Prinzip her passt das mit dem Cycle Counter.
Aber du darfst nicht zwei aufeinanderfolgende Telegramme in Wireshark dazu verwenden, sondern zwei aufeinanderfolgende von der gleichen Quelle zum gleichen Ziel. Du kannst das z.B. mit einem passenden Filter auf die Quell- oder Ziel Mac-Adresse machen, wie "eth.src == a:b:c:e:f:g".

Wenn du Baugruppe in Run ist sollten die Telegramme in dem Zyklus hereinkommen. Problem deutet auf einen Fehler im Device hin, mal den Baugruppenzustand im Simatic Manager angeschaut, oder ist das nicht mit Step7 programmiert?

 

[svkers]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Thomas,

vielen Dank für Deine Antwort. Meine Beschreibung war ein bisschen schwammig formuliert. Ich meinte natürlich zwei aufeinanderfolgende Telegramme desselben IO-Flows (gleiche Quelle und gleiches Ziel).

Die Messung wurde aufgenommen, als in der Anlage nicht produziert wurde. Ich vermute, dass daher der PN-Status Problem rührt. Die Anlage ist in STEP7 programmiert, aber ich habe darauf leider keinen Zugriff.

Allerdings ist mir noch aufgefallen, dass alle aufgezeichneten PROFINET IO-Telegramme (RTC1) kein VLAN-Tag enthalten. Bisher war ich der festen Überzeugung, dass RT-Telegramme immer ein VLAN-Tag (Id=0, Prio=6) enthalten. Woran kann das liegen? Hat dies evtl. Auswirkungen auf die Berechnung der Aktualisierungszeit basierend auf CycleCounter?

Noch eine kurze Anmerkung: Die Messung wurde mit dem ProfiShark 100M (http://www.profitap.com/profishark-100m/) aufgezeichnet. Dieser TAP ist per USB an den Aufzeichnungsrechner angeschlossen.

Btw: Gibt es eine gute Fachliteratur zu PROFINET und seinen Protokollen (Funktionsablauf, Frameaufbau, ...)?

Vielen Dank!

Viele Grüße,
sk

 

[Thomas_v2.1]

Es gibt das Profinet Handbuch von Felser online: http://www.profinet.felser.ch/

Wenn erlaubt kannst du das Logfile oder zumindest einen Ausschnitt davon ja mal hier anhängen.

 

[olliew]

Die Messung wurde aufgenommen, als in der Anlage nicht produziert wurde. Ich vermute, dass daher der PN-Status Problem rührt.

Der Status 'Problem' bedeutet i.d.R. das Diagnose anliegt. Könnte z.B. fehlender 24V Lastversorgung sein.

Btw: Gibt es eine gute Fachliteratur zu PROFINET und seinen Protokollen (Funktionsablauf, Frameaufbau, ...)?

Das Buch von Hr. Popp: http://www.profibus.com/nc/download...dustrial-communication-with-profinet/display/


'Fehlender' VLAN-Tag könnte durch den TAP verursacht werden, darf aber die CycleCounter nicht beeinflussen.
Bei 8 msec Aktualisierungszeit müsste der CycleCounter sich um 32 * 8 = 256 erhöhen.
Etwas Suspekt finde ich aber DataStatus 0x3F. Bit 3 ist laut Spezifikation reserviert (=0).

 

[svkers]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas: Leider kann ich keinen Ausschnitt aus der Messung hier posten. Danke für den Link.

@olliew: Danke für den Hinweis auf das Buch von Manfred Popp. Das habe ich in der Tat gestern bestellt.

Dass der VLAN-Tag durch den TAP entfernt wurde, war auch meine erste Vermutung, allerdings sollte dies ja keine Auswirkung auf den Rest des Telegramms haben.
Hat von Euch jemand bereits Erfahrungen mit dem genannten TAP (PROFITAP v1, Aggregations-TAP/USB-Anschluss an das Notebook) sammeln dürfen?

 

[olliew]

Dass der VLAN-Tag durch den TAP entfernt wurde, war auch meine erste Vermutung, allerdings sollte dies ja keine Auswirkung auf den Rest des Telegramms haben.

Gerade kurz kontrolliert, VLAN wird auch bei mir herausgeschnitten. Beim Switch mit Port-Mirroring ist es drinne.

Hat von Euch jemand bereits Erfahrungen mit dem genannten TAP (PROFITAP v1, Aggregations-TAP/USB-Anschluss an das Notebook) sammeln dürfen?

Ab und zu benutze ich dieser TAP http://www.procentec.de/profitap/ , dürfte der gleiche sein mit ein anderen Aufkleber.

Sieht dann so aus:
Zykluszeit ist 2 msec.


PS: ich versuch immer ein möglichst aktueller Wireshark einzusetzen.

 

[ChristophD]

Hi,

ja das Gerät hatten wir auch mal im Einsatz aber Aufgrund der schon von dir festgestellten Unzulänglichkeiten (Cycle Counter falsch, Status nicht korrekt) und der Tatsache das dieser TAP nicht mit schnellen Takten (125µs - 1ms) funktioniert und Telegramme komplett verloren gehen in der Aufzeichnung wieder ausgemustert.

Gruß
Christoph

 

[svkers]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zunächst einmal Danke, dass Du Dir den Aufwand gemacht hast und es nachgemessen hast.
Das erklärt dann zunächst mal, warum das VLAN-Tag fehlt. In Deiner Aufzeichnung passt aber der Rest, d.h. CycleCounter, Pn-Status im Telegramm sind ok. Dies ist bei mir leider nicht der Fall

Ich habe die neueste Wireshark-Version unter Win 7 x64 installiert.

 

[svkers]

Hi Christoph,

das bestätigt meine schlimmste Vermutung: der TAP hat die Aufzeichnung zerstört.
Weißt Du, ob es nachträglich eine Möglichkeit gibt, die Aufzeichnung zu retten? Ich meine, hat nur der Wireshark ein Problem mit der Darstellung oder ist tatsächlich in diesem Fall die Datei "defect"?

Danke & Gruß,
sk

 

[ChristophD]

Hi,

wenn ich mich noch recht erinnere gab es ein externes Tool welches die Daten aufbereitet hat und CycleCount und Status "repariert" hat.
Ist aber schon zulange her mit dem Teil das ich da noch auf den Namen komme.

Gruß
Christoph

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Möglich das die TAPs nur gleich aussehen, aber sich dann doch leicht unterschiedlich verhalten (siehe Post von ChristophD).
CycleCounter Probleme habe ich bis jetzt nicht beobachtet. Fehlender Telegramme aber schon.

 

[svkers]

Danke für Deine Rückmeldung. Falls Dir der Name des Tools, Hersteller, Hinweis dazu, etc. doch noch einfallen sollte, bitte kurz posten. Das würde mir und evtl. anderen auch sehr helfen.

Gruß,
sk

 

[ChristophD]

Hi,

wenn ich mich recht entsinne war das Tool auf der beiliegenden CD mit drauf, ich schau mal ob das Teil noch irgendwo hier rumliegt.
gefunden:
Das Tool nennt sich "ProfiTAP - NanoSec Converter" und liegt auf der CD /USB Stick die dem TAP beiliegen.

Gruß
Christoph

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Koppelt dieser Tap eigentlich auch die Frame Check Sequence mit aus? Ich verwende bisher immer einen Switch mit Mirror Port, da bekommt man diese Wert nie zu Gesicht. Gerade zur Fehlersuche aufgrund von Störungen wäre es hilfreich auch Pakete zu Gesicht zu bekommen die eine fehlerhafte Prüfsumme besitzen. Spätestens am nächsten Switch fliegen solche Pakete nämlich raus.

Dass so ein Tap an den Nutzdaten rumfummelt, macht so ein Gerät absolut untauglich. Und wenn es ein Programm dafür gibt um daran was zu korrigieren muss da was dran sein. Für mich steht Procentec damit auf der schwarzen Liste.

 

[svkers]

Hallo Zusammen,

ich habe die Lösung gefunden: Der TAP funktioniert einwandfrei. Alle Messungen sind in Ordnung.

Nun aber Schritt für Schritt:

• Der TAP hängt am Ende jeden Telegramms noch folgende Bytes dran: CRC32 (4 Byte), Nanosekundenzeitstempel (8 Byte). Diese 12 Byte werden von Wireshark als Daten des Frames behandelt, da der TAP die Paketlänge entsprechend um 12 Byte vergrößert hat.
• Unter Verwendung des Tools "NanoSec Converter v1.1" der Firma Comcraft/ProfiTap (http://www.profitap.com) kann die Wireshark-Aufzeichnung entsprechend des vom TAP generierten Nanosekundenzeitstempel aktualisiert werden, d.h. der Nanosekundenzeitstempel ist danach korrekt in Wireshark zu sehen, die 8 Bytes für den vom TAP angehängten Zeitstempel werden entsprechend von der Paketlänge abgezogen.
• Um nun noch die 4 Byte für den CRC32 zu entfernen, kann man editcap (Wireshark-Tool) wie folgt verwenden: "C:\Program Files\Wireshark\editcap.exe" ns.input.pcap -L -C -4 output.pcap

Danach kann man die nachbearbeitete Wireshark-Aufzeichnung (output.pcap) schön in Wireshark ansehen und alles passt: PROFINET CycleCounter, TransferStatus, DataStatus, ...

Nochmal Danke für Eure Unterstützung!

Viele Grüße,
sk

 

[Marco Freihöfer]

Ich kann euch hier unseren PROFINET Messqadapter (PNMA II) empfehlen. Passiv, rückwirkunsfrei. Es gibt keine Verzögerung beim weiterleiten der Telegramme.

Wenn es Dir daraum geht die Performance Deiner PROFINET Anlage zu bewerten, dann empfehle ich Dir ein anderes Tool als Wireshark. Die Zeitfenster die Du hiermit
analysieren kannst sind sehr klein und der Aufwand zum ableiten der Aktualisierungsraten, bzw. deren Delay (Jitter) sehr hoch.

Es gibt professionelle Tools für eine einfach zu verstehende und vor allen Dingen automatisierte Analyse des Netzwerkes. Beispielsweise den PROFINET-INspektor.

 

[Andrew Scalon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Inspektor hab ich hier auch... als set mit dem fluke...
Muss nur noch lernen, damit umzugehen xD

 

[Thomas_v2.1]

Es lassen sich auch die Ausgaben von tshark (Kommandozeilenversion von Wireshark, ist dabei) mit ein paar Skripten weiter statisch analysieren.

Kleines Beispiel in Python was die Zeitdifferenzen zwischen den Unterschied zwischen Aktualisierungszeit aus den PN-Cyclecounter und dem Aufzeichnungszeitpunkt ausgibt:

# -*- coding: iso-8859-15 -*-
# Version: Python 3.4
import subprocess

path_to_tshark = "c:/Program Files/Wireshark/tshark.exe"
# Ziel Mac-Adresse nach der gefiltert wird
mac_dst_filter = "00:1b:1b:23:eb:3b"
# Wireshark Capture Datei
capture_file = "S71200_ET200SCPU_Aktualisierung2ms_Zyklen30_AbziehenKabelAmDevice.pcapng"

class Entry:
    frame_number = 0
    time_delta_displayed = 0.0
    cycle_counter = 0

filter_args = "eth.type==0x8892 && ((pn_rt.frame_id >= 0x8000 && pn_rt.frame_id <= 0xbbff) || (pn_rt.frame_id >= 0xc000 && pn_rt.frame_id <= 0xf7ff)) && eth.dst==" + mac_dst_filter

out = subprocess.check_output([path_to_tshark, "-r", capture_file, "-Y", filter_args, "-T", "fields", "-e", "frame.number", "-e", "frame.time_delta_displayed", "-e", "pn_rt.cycle_counter"])
output = out.decode('ascii')
values = []
lines = output.split('\r')
for line in lines:
    if len(line) > 2:   # tshark hängt eine Leerzeile am Ende an
        line = line.replace('\n','')
        vals = line.split("\t")
        v = Entry()
        v.frame_number = int(vals[0])
        v.time_delta_displayed = float(vals[1])
        v.cycle_counter = int(vals[2])
        values.append(v)

for i in range(1, len(values)):
    meas_tdiff_us = values[i].time_delta_displayed * 1000000.0
    c1 = values[i].cycle_counter
    c2 = values[i - 1].cycle_counter
    if c1 - c2 < 0:
        cdiff = 65536 - c2 + c1
    else:
        cdiff = c1 - c2
    
    calc_tdiff_us = 31.25 * cdiff
    tdiff = meas_tdiff_us - calc_tdiff_us
    print("Frame-No.:{0:6d}  Soll: {1:d} Ticks / {2:.2f} µs  Gemessen: {3:.2f} µs  Differenz: {4:+.2f} µs".format(values[i].frame_number, cdiff, calc_tdiff_us, meas_tdiff_us, tdiff))

Es wird aber damit aber nicht erkannt wenn nach einer Störung die Kommunikation neu aufgenommen wird, für eine schnelle Übersicht reicht das aber.

 

[Marco Freihöfer]

Hallo Andrew,

falls Du beim Verständnis, einrichten oder Umgang mit unseren Produkten Hilfe benötigst, ruf doch einfach mal bei unserem Support durch.
Da gibt es schnelle und unkomplizierte Hilfe. Du kannst auch gerne nach mir fragen, vielleicht bin ich zufällig im Haus.