Step 7 Telegramme_Wireshark

[haso67]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo SPS-Team

, ich hätte eine kurze frage unzwar habe ich Messungen mit Wireshark durchgeführt was auch ok war aber eins habe ich nicht verstanden.

Die telegramme

"8879","8.867621000","Siemens-_87:21:d4","ControlT_03:61:17","PNIO","60","RTC1(legacy), ID:0xc000, Len: 40, Cycle:57472 (Valid,Primary,Ok,Run)"


0000 00 0d 1e 03 61 17 28 63 36 87 21 d4 88 92 c0 00
0010 80 80 80 80 00 83 80 00 00 12 5c 80 80 80 80 80
0020 00 00 00 00 80 00 00 80 80 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 e0 80 35 00




"8880","8.867947000","ControlT_03:61:17","Siemens-_87:21:d4","PNIO","60","RTC1(legacy), ID:0xc000, Len: 40, Cycle:47042 (Valid,Primary,Ok,Run)"


0000 28 63 36 87 21 d4 00 0d 1e 03 61 17 88 92 c0 00
0010 80 80 80 80 80 80 00 00 00 00 80 00 00 00 00 80
0020 00 83 80 02 2f 80 80 80 ff ff ff f6 80 00 00 00
0030 00 00 00 00 00 00 00 00 b7 c2 35 00

Meine frage wäre die Hex zahl 80 was die zu bedeuten hat , es ist wie eine Trennung .Immer was da zwischen liegt ist der Richtige wert Sei es Steuerwort , der Strom oder drehmoment

 

[LowLevelMahn]

Offene Fragen:
Wer ist das SPS-Team?
Was ist das für ein Gerät?
Was für eine Kommunikation vom Gerät hast du mit Wireshark geloggt (nicht gemessen)

 

[haso67]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit TEAM mein ich jeden hier der angemeldet ist .

Hab ne s7-1500 mit Profinet an einem Umrichter von CT mit Switch angeschlossen . Gleichzeit lese ich mit Wireshark die Daten zwischen SPS und Umrichter.

 

[centipede]

Warum verheimlichst du uns dein bereits gesammeltes Wissen über den Telegrammaufbau?
Woher soll hier jemand wissen, wie deine Daten aufgebaut sind?

 

[Thomas_v2.1]

Ab 0010 sind die eigentlichen IO Nutzdaten. Die Daten lassen sich nur interpretieren wenn man den Aufbau der Nutzdaten kennt, entweder über die GDSML-Datei oder Anhand des Connect/Write-Frames wenn der Slave seine Konfigurationsdaten vom Controller bekommt.

Ich habe aber auch noch nicht versucht die Nutzdaten zu interpretieren.

 

[haso67]

Zuviel Werbung?
-> Hier kostenlos registrieren

wieso verheimlichen ???

0010 80 80 80 80 00 83 80 00 00 12 5c 80 80 80 80 80

0020 00 00 00 00 80 00 00 80 80 00 00 00 00 00 00 00

00 83 = Steuerwort also drive enable
00 00 12 5c = Drehmoment 12 5c HEX =47.00 %
Die anderen sind Parameter nicht beschrieben sind . Meine Frage wäre die Zahl 80HEx was die zu bedeuten hat ,ist das wie eine trennung oder so ?

 

[Thomas_v2.1]

Und woher kennst du die Bedeutung der Werte?
Zeig doch mal die GSD-Datei und die Konfiguration deines Slaves, vielleicht lässt sich daraus zurückschließen was dort übertragen wird.

 

[haso67]

weil ich die wichtigen Parameter ausgesucht und adressiert habe also reihenfolge habe ich selbst bestimmt . Die Werte hab ich über S7 vorgegeben und mit Wireshark gemessen wie lange es dauert bis die Werte auf dem Umrichter ankommen . Die GSD ist hier wenig hilfreich.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum meinst du dass die GSD wenig hilfreich ist?

Über die GSD und deine Konfiguration (Module) bekommt der Slave doch überhaupt erst übermittelt, welche Daten er in die Telegramme hineinpacken soll.

 

[haso67]

wollen sie jetzt das ich ihnen die GSDML datei schicke ?

 

[Thomas_v2.1]

Du könntest zumindest mal auflisten, was für ein Gerät du hast und welche Konfiguration der Module du getätigt hast.
Ich habe das auch noch nicht gemacht, aber ohne diese Informationen wird dir niemand sagen können was dort für Daten übermittelt werden.

 

[haso67]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bild mit Parameter Write/Read werden.

 

[olliew]

Meine frage wäre die Hex zahl 80 was die zu bedeuten hat , es ist wie eine Trennung .Immer was da zwischen liegt ist der Richtige wert Sei es Steuerwort , der Strom oder drehmoment

Diese "Trennungen" sind IOProviderStatus. Alle Modul-E/A-Daten haben zusätzlich ein ProviderStatus sowie dann im gegenübergestellte Richtung dann ein ConsumerStatus.

Ab 0010 die I/O-Daten, die erste 80 Bytes sind die IOPS/IOCS zum Gerät mit sein PROFINET Ports (Slot 0, Subslot 8000h, 8001h und 8002h).

IOPS/IOCS kann 00h (=Bad), 60h (=Idle) oder 80h (=Good) sein. Kurz nach Verbindungsaufbau werden die Stati auf 00h stehen um dann nach einige Telegramme in 80h zu wechseln.

GSDML nutzt da nicht, da jeder PROFINET Controller (SPS/Robi) die E/A-Daten anders einteilen kann. Da hilft nur das Telegramm vom Verbindungsaufbau, da steht drin was wohin kommt.

 

[haso67]

Olliew danke dir das hat mich jetzt auf jeden Fall weitergebracht .

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

GSDML nutzt da nicht, da jeder PROFINET Controller (SPS/Robi) die E/A-Daten anders einteilen kann. Da hilft nur das Telegramm vom Verbindungsaufbau, da steht drin was wohin kommt.

Kann ich nicht alleine aus der Konfiguration des Gerätes (d.h. welches Modul steckt auf welchem Slot) darauf schließen an welcher Stelle die Daten im Telegramm wieder auftauchen?

Und wenn ich nur das Telegramm vom Verbindungsaufbau habe, könnte ich dann anhand einer vorliegenden GSDML auf die aktuelle Konfiguration im Controller schließen?

Ich denke nur etwas darüber nach ob es möglich ist den PN-Dissector von Wireshark in irgendeiner Art und Weise zu erweitern um auch die IO-Daten zerlegen zu können. Aber das wäre ja nichteinmal mit einer kompletten Bibliothek von allen GDSML-Dateien möglich.

 

[olliew]

Kann ich nicht alleine aus der Konfiguration des Gerätes (d.h. welches Modul steckt auf welchem Slot) darauf schließen an welcher Stelle die Daten im Telegramm wieder auftauchen?

Leider nicht :-|

Beispiel ein 16-fach Eingangsmodul: Das Device verschickt 2 Bytes mit die E-Daten + IOPS-Byte. Der Controller quittiert dies mit ein IOCS-Byte.
Beispiel ein 16-fach Ausgangsmodul: Der Controller verschickt 2 Bytes mit die A-Daten + IOPS-Byte. Das Device quittiert dies mit ein IOCS-Byte.

Bei ein modulares Device entscheidet der Controller über die Reihenfolge im PROFINET Telegramm. Z.B. zuerst die Päkchen mit Daten und danach die IOCS-Bytes. Oder die Module der Reihe nach. Oder sonst wie (OK, das habe ich noch nicht gesehen in der Praxis )

Und wenn ich nur das Telegramm vom Verbindungsaufbau habe, könnte ich dann anhand einer vorliegenden GSDML auf die aktuelle Konfiguration im Controller schließen?

Ja. Anhand DAP Identkode und dann Modulkode+Submodulkode lässt sich das entsprechende Modul in die GSDML Datei finden.

Ich denke nur etwas darüber nach ob es möglich ist den PN-Dissector von Wireshark in irgendeiner Art und Weise zu erweitern um auch die IO-Daten zerlegen zu können. Aber das wäre ja nichteinmal mit einer kompletten Bibliothek von allen GDSML-Dateien möglich.

Yop. Mit die GSDML Dateien alleine ist es nicht getan.

 

[Thomas_v2.1]

Yop. Mit die GSDML Dateien alleine ist es nicht getan.

Ich habe kürzlich von einem Gerät gelesen, das man (angeblich) einfach ins Profinet-Netzwerk hängen können soll, und dieses dann Prozesswerte abgreift und zur Anzeige bringt. Jetzt finde ich den Link nicht wieder, es stand in einem dieser Werbeblätter für Automatisierungstechnik.

Nur wie soll das funktionieren, ohne dass ich dieses Gerät parametrieren muss, bzw. zumindest die GDSML-Datei importieren welche der Controller verwendet? Prinzipiell ist das nicht viel anderes als Wireshark, also ein Sniffer am Netzwerk.
Wenn das Gerät bei Hochlauf schon am Bus hängt bekommt es die Konfigurationsübertragung zu den Devices mit. Aber nicht wie diese zu interpretieren sind.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese "Trennungen" sind IOProviderStatus. Alle Modul-E/A-Daten haben zusätzlich ein ProviderStatus sowie dann im gegenübergestellte Richtung dann ein ConsumerStatus.

Ab 0010 die I/O-Daten, die erste 80 Bytes sind die IOPS/IOCS zum Gerät mit sein PROFINET Ports (Slot 0, Subslot 8000h, 8001h und 8002h).

IOPS/IOCS kann 00h (=Bad), 60h (=Idle) oder 80h (=Good) sein. Kurz nach Verbindungsaufbau werden die Stati auf 00h stehen um dann nach einige Telegramme in 80h zu wechseln.

Ich habe gerade mal in den Wireshark Quellen im Profinet-Teil nachgeschaut. Es war dort mal eine Erkennung des IOxS vorhanden, aber da dieses nicht immer vorhanden ist und es nur aus dem Kontext (Verbindungsaufbau) erschlossen werden kann, hat man sich dazu entschieden die Erkennung zu entfernen, eben damit nichts falsch angezeigt wird.
Im Kommentar steht zur Erkennung: "this will be tricky :-("

 

[olliew]

Mit A.I. kann einiges gemacht werden


Über denn Hochlauf bekommst du eigentlich alles mit. Im ConnectRequest steht genau welche Module/Submodule erwartet werden, also Identkodes und E/A-Länge. Und dann noch die Beschreibung der Input- und Outputframes. Das reicht aus um dann die folgende IO-Frames auseinanderzunehmen.

2 Beispiele für InputCR Beschreibung, Device -> Controller.
Device Aufbau Slot 1: 2 Eingangsbytes + IOPS, Slot 2: keine Daten (benötigt dann aber trotzdem 1 Byte IOPS), Slot 3: 4 Ausgangsbytes (1 Byte IOCS in InputCR).




Ich könnt mal suchen in mein .PCAP Fundus, vielleicht gibt es noch mehr Mechanismen.

 

[Thomas_v2.1]

Es hat gerade netterweise jemand viel Aufwand bei Wireshark in den Profinet-Teil hineingesteckt (Danke).
Es lässt sich jetzt ein Pfad angeben in der GSD-Dateien abgelegt sind, und es wird dann geprüft ob dort eine zugehörige GSD-Datei liegt. So bekommt man zumindest das IOPS-Feld und den eigentlichen Datenteil aufgeschlüsselt. Ich hab's nur gerade an einer Verbindung zwischen ET200S und S71200 getestet, sieht schonmal nicht schlecht aus.