Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

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

  1. #1
    Registriert seit
    07.12.2011
    Beiträge
    25
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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
    Zitieren Zitieren Ableitung der Aktualisierungszeit für eine PROFINET IO aus einer Wireshark-Messung  

  2. #2
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    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?

  3. #3
    svkers ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.12.2011
    Beiträge
    25
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Geändert von svkers (10.06.2015 um 10:49 Uhr)

  4. #4
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    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.

  5. #5
    Registriert seit
    28.03.2012
    Ort
    Hessen
    Beiträge
    116
    Danke
    4
    Erhielt 20 Danke für 18 Beiträge

    Standard

    Zitat Zitat von svkers Beitrag anzeigen
    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.

    Zitat Zitat von svkers Beitrag anzeigen
    Btw: Gibt es eine gute Fachliteratur zu PROFINET und seinen Protokollen (Funktionsablauf, Frameaufbau, ...)?
    Das Buch von Hr. Popp: http://www.profibus.com/nc/download/...finet/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).
    Kaum macht man es richtig, schon funktioniert es.

  6. #6
    svkers ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.12.2011
    Beiträge
    25
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard

    @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?

  7. #7
    Registriert seit
    28.03.2012
    Ort
    Hessen
    Beiträge
    116
    Danke
    4
    Erhielt 20 Danke für 18 Beiträge

    Standard

    Zitat Zitat von svkers Beitrag anzeigen
    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.


    Zitat Zitat von svkers Beitrag anzeigen
    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: 2015-06-10 13_38_37-_ProfiTAP [Wireshark 1.12.2 (v1.12.2-0-g898fa22 from master-1.12)].jpg
    Zykluszeit ist 2 msec.


    PS: ich versuch immer ein möglichst aktueller Wireshark einzusetzen.
    Kaum macht man es richtig, schon funktioniert es.

  8. #8
    Registriert seit
    16.03.2006
    Ort
    Franken
    Beiträge
    3.793
    Danke
    30
    Erhielt 916 Danke für 797 Beiträge

    Standard

    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

  9. #9
    svkers ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.12.2011
    Beiträge
    25
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.

  10. #10
    svkers ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.12.2011
    Beiträge
    25
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. Antworten: 10
    Letzter Beitrag: 24.02.2017, 09:29
  2. Antworten: 2
    Letzter Beitrag: 05.12.2014, 07:54
  3. Antworten: 2
    Letzter Beitrag: 14.02.2014, 10:28
  4. Wireshark S7Comm Dissector - Aktuelle Wireshark Version...
    Von Jochen Kühner im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 14.10.2012, 22:54
  5. Profinet und Aktualisierungszeit
    Von snowbda im Forum Feldbusse
    Antworten: 7
    Letzter Beitrag: 29.03.2009, 11:25

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •