IO-Link Kommunikation per S7comm

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab den Teil mit der DP-Adresse mal 1 zu 1 nachgebaut und es scheint zu funktionieren.

Zum ProfiNet Teil:
Ich hab ja die PLC->ET200 ProfiNet Kommunikation aufgezeichnet und für den PLC IOL Leseauftrag vier Pakete detektiert (2x Request und 2x Response). Erste einen schreib und anschließend den Leseauftrag.
Ich möchte jetzt nicht tausende von Seiten lesen um das komplette PN zu verstehen. Mir reichen ja zunächst diese beiden Telegramme. Hast du noch einen Tipp auf was zu achten ist? Sonst bau ich die halt mal 1 zu 1 nach.
 
Ich habe mit Profinet selber noch nicht solche Versuche angestellt. Aber die Funktionen die du dort aufgezeichnet hast scheinen ohne vorherigen Aufbau einer Beziehung möglich zu sein, also probieren.

Bezüglich des Datensatz-Routings scheint der Teil in der SPS sehr empfindlich auf fehlerhafte Telegramme zu reagieren. Ich habe gestern versucht ein paar fehlerhafte Antworten zu generieren in dem ich nur einzelne Byte-Werte anpasse. Ich hatte fast jedes Mal den Christbaum an der SPS am leuchten (alle LED blinken), und SPS nicht mehr erreichbar. Zurücksetzen war nur über Spannung aus-ein möglich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mit Profinet selber noch nicht solche Versuche angestellt. Aber die Funktionen die du dort aufgezeichnet hast scheinen ohne vorherigen Aufbau einer Beziehung möglich zu sein, also probieren.
Hab nun 1 zu 1 das Telegramm nachgebaut. Hat jedoch nicht zum Erfolg geführt.
Aufzeichnung + Python Dummy
Anhang anzeigen py-iol-pn.zip
Anhang anzeigen pn_20200601.zip

Aufzeichnung S7-PCT PN Kommunikation
Anhang anzeigen S7-PCT-172.30.1.81-ST1-P4_20200601.zip


Bezüglich des Datensatz-Routings scheint der Teil in der SPS sehr empfindlich auf fehlerhafte Telegramme zu reagieren. Ich habe gestern versucht ein paar fehlerhafte Antworten zu generieren in dem ich nur einzelne Byte-Werte anpasse. Ich hatte fast jedes Mal den Christbaum an der SPS am leuchten (alle LED blinken), und SPS nicht mehr erreichbar. Zurücksetzen war nur über Spannung aus-ein möglich.
Hab mit deinem Python Script + Virenscanner die SPS so abgeschossen, dass nur ein Urlöschen geholfen hat.
 
Ich vermute der ConnectRequest sowie das Auswerten der ConnectResponse gehören auch noch dazu.
Und am Ende deines Datenaustausches noch der ReleaseRequest um das auch sauber wieder abzubauen.

Ein PROFINET write request geht nicht ohne Verbindung, also Ja, ConnectRequest und ReleaseRequest werden benötigt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein PROFINET write request geht nicht ohne Verbindung, also Ja, ConnectRequest und ReleaseRequest werden benötigt.

Ist das eigentlich so vorgesehen, dass sich jeder über diesen Kanal mit einem Device verbinden kann und beliebige Daten auslesen und evtl. auch schreiben kann? Für einen PG zur Projektierung, Inbetriebnahme und Diagnose ist klar, dass es notwendig ist. Aber es scheint ja auch relativ einfach zu sein, damit zyklisch "azyklische" Daten auszulesen. Die Frage ist nur, wie viele Ressourcen stellt das Device dafür zur Verfügung.
 
Ja, das ist vorgesehen. Das Device 'limitiert' jedoch die Anzahl gleichzeitige Verbindungen. Aus dem Grund ist es auch Gut eine Verbindung sauber zu beenden ;)

Im übrigen sind diese Art "Verbindungen ohne IO" optional (in GSDML nachsehen: DeviceAccessSupported), sind aber durchaus praktisch für Diagnose usw..
 
Ich wollte grad mal mit TIA einen IO-Link Aufbau machen.
Da ich nicht wusste wie aus TIA V15 heraus das S7-PCT gestartet werden kann hab ich ein wenig gegoogelt und hab bei Siemens einen interessanten Beitrag gefunden (englisch)
How do you parameterize IO-Link master and devices across gateways with the S7 Port Configuration Tool (S7-PCT)?
Beitrags ID: 87611392
Abbbildung 9, 10, 11
Mit S7 300/400 CPUs ist scheinbar der Zugriff mit S7-PCT auf PN-Devices nur direkt möglich, Außnahme IM_CPUs.
Leider hab ich keine solche alte S7-classik IM-CPU. Ich hab nur eine CPU1510SP-1 PN, da werd ich mal das IO-Link Modul dran hängen und dann mit S7-PCT online gehen.
Mal schaun ob ich da "indirekt" dran komme, evtl. über S7-Routing. So dass S7-PCT die S7-Kommunikation nehmen muss.

mfG. Klaus Loy
 
Zuviel Werbung?
-> Hier kostenlos registrieren
jetzt hab ich mich mal mit S7_PCT über die CPU1510SP-1 PN CPU an das IO-Link Modul dran gehängt, da läuft dann halt dummerweise die S7-1500 er Kommunikation. Dann hab ich versucht, vor die 1500er eine 300er mit CP343-1EX30, zwecks Routing dran zu hängen. Dann mit S7_PCT über Routing auf das IO-Link Modul durch verbunden, läuft wieder die 1500er Kommunikation mit langen Routing SAPs (Aufzeichnung liegt vor und könnte ich hoch laden).
OK, d.h. S7-PCT kann prinzipiell über Routing sich verbinden. Alao hab ich statt der 1500er wieder eine 300er mit ET200SP-PN-Device, mit IO-Link projektiert.
Alles mit TIA, dann wollte ich S7_PCT über Routing an den IO-Link welcher über PN an der 300er hängt dran gehen. Device Tool starten frägt er mich nach dem zugangsweg, ist aber nur Direkt über PN, ohne Routing auswählbar. D.h. S7_PCT lässt sich nicht dazu bringen, mit einem IO-Link Master über "klassische" S7 Kommunikation zu verbinden. Es geht nur direkz über Profinet, oder nur mit einer ET200SP 1500er oder vieleicht mit einer ET200SP_300er CPU falls es sowas gibt.

mfG. Klaus Loy
 
Was möchtest du denn noch herausfinden?
Wie die IOL-Master Abfragen über Profinet-IO ablaufen ist geklärt, lässt sich relativ einfach nachbilden.

Das Datensatz-Routing von Ethernet auf Profibus ist so wie es aussieht nur auf Profibus und nicht auf Profinet möglich. Hier ist zwar klar wie die Nutzdaten für IO-Link verpackt werden, aber nicht wie Siemens das Datensatz-Routing realisiert hat. Das Datensatz-Routing wird sonst so wie es aussieht nur noch von Simatic PDM verwendet, und das scheint mir nicht sonderlich verbreitet zu sein. Wenn ich das verfügbar hätte, dann wäre das mein Tool der Wahl um weitere Nachforschungen anzustellen. Ich habe das nur vor längerer Zeit mal verwendet um ein paar Sitrans über HART zu parametrieren. Muss ich mal sehen ob ich das noch auf einer VM verfügbar habe.
 
Ok, für mich war es interessant, aber wenn es für PN halt nicht geht dann ist es halt so.
Ich denk aber dass die CPUs das sehr wohl könnten, aber es im Tool halt nicht realisiert ist.
Es ist auch eigenartig, dass das IO-Link "Zeug" bei TIA so lose angekoppelt ist, mit einem externen Tool.
Ich dachte immer bei TIA wäre das alles voll integriert.

Für mich kann diese Diskussion hier enden.

mfG. Klaus Loy
 
Das nutzt aber keinen Routing-TSAP, sondern den normalen TSAP für die S7comm-plus Kommunikation.
Bei S7comm-plus ist ja alles "objektifiziert", so auch die Abfrage der Diagnosedaten.

Es wird erst eine Variable geschrieben, mit dem angefragten IO-Link Datensatz. Aufbau ist soweit identisch mit dem auch über S7comm bekannten Aufbau.
Dann erfolgt eine Bestätigung ohne Daten.
Dann erfolgt eine Abfrage, und in der Antwort sind dann die Daten enthalten.

iol-s7comm-plus.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sorry Thomas,
da hab ich dir die falsche Aufzeichnung geschickt, es ging definitiv über Routing, ich hatte die Netze physikalisch getrennt.
Aufzeichnung hab icj leider nicht mehr, könnte ich aber bei Interesse nochmal machen.

mfG Klaus Loy
 
da hab ich dir die falsche Aufzeichnung geschickt, es ging definitiv über Routing, ich hatte die Netze physikalisch getrennt.
Aufzeichnung hab icj leider nicht mehr, könnte ich aber bei Interesse nochmal machen.
Wie ist die Aufzeichnung denn entstanden? Mit PCT per Ethernet auf einer 1500er CPU und dann über Profibus oder Profinet weiter?
 
Guten Morgen,
Routing weg war wie folgt:
S7_PCT --> S7-300 Routing Knoten --> 1500 PN Port (S7-comm) --> PN-Device (UDP)

Aufzeichnung lief am PC, auf dem S7_PCT lief.
Einen ET200SP DP-Slave habe ich leider nicht.

DEn weg über den Routing Knoten habe ich gewählt um PCT zur "S7-comm" zu zwingen, ansonsten wäre es direkt über UDP an das PN-Device gegangen.

mfG. Klaus Loy
 
Aufzeichnung wurde nochmal gemacht.
Erster Vorgang: S7_PCT Online über Routing, siehe Bild, dann Laden der Konfiguration aus IO-Master in "PG", Wireshark: S7_PCT_Laden_in_PG.pcapng
Zweiter Vorgang: S7_PCT Online über Routing, Laden von "PG" in IO-Master, Wireshark: S7_PCT_Laden_in_Baugruppe.pcapng
Routing_Adressen.PNG
Hier ein ZipFile mit TIA-Projekt und den beiden Wireshark Aufzeichnungen.
Anhang anzeigen CPU_1510SP_over_Routing.zip

mfG. Klaus Loy
 
Zurück
Oben