IO-Link Kommunikation per S7comm

Wenn man aber in den IO_LINK_DEVICE reinschaut, dann sieht man zumindest in den STAT-Variablen in der Struct "read.header" den Aufbau des Datenteils das auch übers Netzwerk geht. Glücklicherweise mit Kommentar :smile: Leider fehlt hier die SCL-Quelle, müsste man sich anfertigen wenn das weiterhilft.
Zum Vergrößern anklicken....

Ich habe diesbezüglich schon mehrfach gefragt, auch eigens einen Thread dafür aufgemacht, woher die Datenstruktur kommt, die wir dort in dem Header sehen. Eine sinnstiftende & vernunftbehaftete Antwort habe ich bis heute nicht erhalten.

Faceman schrieb:
Plonk......
Zum Vergrößern anklicken....
Es müsste eigentlich mal Sanktionen geben für sinnfreie Antworten, die nichts zu dem Thema beitragen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Draco Malfoy schrieb:
Ich habe diesbezüglich schon mehrfach gefragt, auch eigens einen Thread dafür aufgemacht, woher die Datenstruktur kommt, die wir dort in dem Header sehen. Eine sinnstiftende & vernunftbehaftete Antwort habe ich bis heute nicht erhalten.
Zum Vergrößern anklicken....

Die Datenstruktur ist in dem Dokument zur IO-Link Integration in Profibus / Profinet die auch in deinem Thread verlinkt wurde dokumentiert. Habe ich hier in #27 nochmal verlinkt. Da ist einmal der Aufbau der Struktur beschrieben, und auch wie die Parameter eines Programm-FBs auf die Strukturen abgebildet werden.
 
Anfrage / Antwort zu dem Lesen von Index/Subindex sieht demnach so aus:
IOL-Anfrage-Antwort.jpg

Zur Anfrage gibt es noch eine Antwort der SPS (evtl. zur Bestätigung der Anfrage), und vor den eigentlichen Daten gibt es noch eine Anfrage (evtl. um mitzuteilen wie groß der Buffer für die Antwort ist). Diese haben aber so wie es aussieht nichts mehr mit dem IOL Call zu tun.
Wenn in CAP = 255 steht dann gibt es auch noch eine Besonderheit dass damit so wie ich es verstehe I&M Datensätze gelesen werden, und manche Telegramme passen überhaupt nicht ins Schema. Manchmal steht bei Länge eine 8 wenn aber überhaupt nichts mehr folgt. Und was genau die ersten 2+2+2 Bytes bedeuten ist mir auch nicht ganz klar.
Ich weiß nicht wie man dahinter kommen kann. Bei dem was das PCT macht passiert zu viel gleichzeitig. Man müsste einzelne Funktionen auslösen die nur eine Anfrage/Antwort haben, und dich gleich mehrere 100 davon.
 
Ok, in den PN Nutzdaten steckt also das gleiche wie bei S7comm im IOL-Payload.
Der Ablauf ist auch identisch, also
1. WriteRequest mit dem anzufordernden Index/Subindex
2. WriteResponse
3. ReadRequest mit Angabe der Record-Länge
4. ReadResponse mit den angefragten Daten

Nur bei dem Transport über S7comm haben WriteResponse und ReadResponse die gleichen Daten, bei WriteResponse mit einer Längenangabe von 8 obwohl keine Daten mehr folgen. Eigentlich gehört hier ein Fehlercode rein.

Aber wenn du sagst, PCT macht das auch bei Profinet nicht über die CPU, dann wäre deine Variante ja exklusiv nur für Profibus verwendbar, ob da der Aufwand lohnt da Profibus ja doch nicht ganz aktuell ist.

Aber man könnte ja einfach mal probieren, ob es über S7comm reicht nur diese 2 Telegramme zu schicken, ohne die ganzen Abfragen vorher von denen wir nicht wissen was die auf sich haben.
 
Thomas_v2.1 schrieb:
Ok, in den PN Nutzdaten steckt also das gleiche wie bei S7comm im IOL-Payload.
Der Ablauf ist auch identisch, also
1. WriteRequest mit dem anzufordernden Index/Subindex
2. WriteResponse
3. ReadRequest mit Angabe der Record-Länge
4. ReadResponse mit den angefragten Daten

Nur bei dem Transport über S7comm haben WriteResponse und ReadResponse die gleichen Daten, bei WriteResponse mit einer Längenangabe von 8 obwohl keine Daten mehr folgen. Eigentlich gehört hier ein Fehlercode rein.
Zum Vergrößern anklicken....
Kannst du/wir versuchen das nachzubauen? Im 1. Schritt z.B. mit deinem Python Script?

Thomas_v2.1 schrieb:
Aber wenn du sagst, PCT macht das auch bei Profinet nicht über die CPU, dann wäre deine Variante ja exklusiv nur für Profibus verwendbar, ob da der Aufwand lohnt da Profibus ja doch nicht ganz aktuell ist.
Zum Vergrößern anklicken....
Profibus ist zwar alt, dafür aber für alle Steuerungen verfügbar. Was Siemens schon an dem ProfiNet rumgedoktert hat spricht auch nicht gerade für eine durchdachte Umsetzung, wobei in Zukunft alles in Richtung Netzwerk gehen wird.
Ob das PCT nicht über die PLC kommunizieren kann oder die Programmieren halt gleich den einfacheren Weg über TCP/IP gegangen sind ist damit ja noch nicht bewiesen.

Thomas_v2.1 schrieb:
Aber man könnte ja einfach mal probieren, ob es über S7comm reicht nur diese 2 Telegramme zu schicken, ohne die ganzen Abfragen vorher von denen wir nicht wissen was die auf sich haben.
Zum Vergrößern anklicken....
Das hört sich doch gut an.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe die meiner Meinung nach dafür notwendigen Funktionen einmal nachgebildet. Kannst ja mal probieren ob dafür alle notwendig sind, oder ob z.B. nur die beiden sendIolReadStep1() und sendIolReadStep2() ausreichend sind, alles andere dann mit # auskommentieren. Die Antworten werden nicht ausgewertet sondern nur gedumpt, am Besten auch mal mit Wireshark mitloggen.

Wenn es funktioniert könnte man ja mal ein paar fehlerhafte Telegramme senden und prüfen wie dazu die Antworten aussehen. Da gibt es auch eine feste Struktur mit entsprechenden Fehlercodes.
 

Anhänge

Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, das scheint die Adresse zu sein. Leider sind dort noch etliche weitere unbekannte Felder dabei, und die ersten 6 Bytes unterscheiden sich auch nicht einmal von den ganzen anderen Paketen, bis auf dass hier wo sonst der Slot eingetragen wird, hier eine 0 steht. Also wenn Slot==0 dann ist das komplett anders aufgebaut.
 
Vermutlich ist das eine "Context ASE" aus der Profibus Spezifikation. Leider ist diese nicht frei verfügbar, und die besteht aus zudem mehreren Teildokumenten mit teilweise jeweils über 1000 Seiten. Das ist sehr zeitraubend sich da durchzuwühlen.
 
1. Siehst du einen Weg wie man das mit ProfiNet testen kann?

2. Eine andere Möglichkeit der Verbindung für den RDREC?

3. Die PN Übertragung die ich aufgezeichnet habe hatte ja die PNIO-CM IOWrite und IORead Request. Kann man die Einfach so schicken oder ist da auch ein Verbindungsaufbau erforderlich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Thomas_v2.1 schrieb:
Vermutlich ist das eine "Context ASE" aus der Profibus Spezifikation. Leider ist diese nicht frei verfügbar, und die besteht aus zudem mehreren Teildokumenten mit teilweise jeweils über 1000 Seiten. Das ist sehr zeitraubend sich da durchzuwühlen.
Zum Vergrößern anklicken....

Wenn man die unbekannten Parameter einfach mal so übernimmt und ich mach ein paar Tests? Eventuell muss man gar nicht verstehen was die genau bedeuten.

Wenn sich herausstellt, dass das ganze für einen typischen Aufbau mit ProfiBus und ProfiNet funktioniert, kann man das ganze ja mit Vorbehalt einsetzten.
 
Mit Profinet würde ich persönlich selber niemals anfangen so etwas selber zu entwickeln. Das ist sehr komplex gestaltet und umständlich dokumentiert. Und die Protokolldokumentationen musst du wie bei Profibus kaufen, am besten gleich noch Profibus dazu, weil das teilweise aufeinander aufbaut. Gelegentlich findest du die Entwürfe (Draft) der IEC Normen im Netz, da weiß man aber nie ob das immer noch so ist. Ich habe für Wireshark mich mal um einen Bug im Profinet-Teil gekümmert, alleine das Finden der Stellen in den Normen ist schon sehr aufwändig.

Du kannst natürlich auch ohne zu wissen wie das funktioniert das eine Telegramm mit einbauen und dort an der einen Position die Profibusadresse einsetzen. Dann wird es bei deinen aktuellen Gegebenheiten funktionieren, aber ob es in einer anderen Konstellation funktioniert ist fraglich.

Unter https://www.felser.ch gibt es ein paar Drafts der Normen zum Download, du brauchst mindestens die IEC 61158 Part 5 und vermutlich auch Part 6. So ungefähr ist die Variante mit Slot = 0 auch in dem IO-Link Integration Dokument erwähnt, zumindest liefert das ein paar Stichworte mit denen man in die anderen Dokumente gehen kann. Kannst dir das ja mal ansehen, dann weißt du so ungefähr was dich bei Profinet erwarten würde.
 
Noch ein interessantes Ergebnis:

Ich habe hier eine IM151-8 PN/DP CPU komplett ohne Baugruppen.

Wenn ich mich zu dieser mit TSAP 0x01, 0x02 verbinde und dann diese IOL-Telegramme schicke, bekomme ich im Parameterteil schon den Fehlercode 0x8104 zurück (This service is not implemented on the module or a frame error was reported). D.h. der angesprochene Programmteil weiß mit diesen Telegrammen nichts anzufangen.

Wenn ich mich zu dieser mit TSAP 0xf4, 0x02 verbinde und dann diese IOL-Telegramme schicke, bekomme ich im Parameterteil keinen Fehlercode mehr, sondern im Datenteil ein paar Daten, mit vermutlich einem Fehlercode auf unterlagerter Ebene (beispielsweise weil die DP Adresse 3 die ich ansprechen will nicht vorhanden ist).

Ich vermute darum einmal, dass ich mit dem TSAP 0xf4 als Verbindungsressource eine bestimmte Funktion ansprechen kann. Vielleicht ist es das von klaly verlinkte "Datensatz Routing" was z.B. auch von Simatic PDM verwendet wird (habe ich leider nicht zum Testen).
 

Similar threads

O
TIA V17: Wie konfiguriere ich die Signalsäule (8WD4613-5HH47) am IO-Link Master (6ES7148-6JG00-0BB0) GELÖST
2
Antworten
35
Aufrufe
6K
Mrtain
Mrtain
F
TIA E&H Dosimass an CM IO-Link Master
Antworten
0
Aufrufe
597
Freakazoid
F
L
IO Link Master FEN20-4IOL mit Sensor PT1A-1004-IOL-H1141
Antworten
4
Aufrufe
1K
olliew
olliew
R
SICK IO-Link Master Pin 4 und Pin 2 verwenden
Antworten
1
Aufrufe
1K
ReiniDerWemser
R
K
Hilfe beim Anschluss eines IFM JN2200 Drehwinkelgebers an PFC200 über IO-Link (e!COCKPIT, 750-657)
Antworten
9
Aufrufe
2K
Tobsucht
T
Zurück
Oben