Raspberry Pi als Profinet Slave

Roxas189

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

momentan bearbeite ich ein Projekt in der Uni bei dem ich mittels einer SPS einen Roboterarm steuern und automatisieren soll.
Mein Problem hierbei ist die Schnittstelle zwischen der SPS und dem Arm. Diese würde ich gerne über einen Raspberry PI und Codesys realisieren. Den Pi würde ich gerne als Profinet Slave an die SPS anbinden.
Ich habe es nun geschafft, den Pi in meinem Codesys einzubinden allerdings weiß ich nun nicht wie ich weiter machen soll. Ich lese öfter was von einer GSDML Datei die ich installieren muss. Ich weiß aber weder wo ich diese herbekommen, noch wie ich sie installieren muss. Kann mir da einer sagen wie das funktioniert ?
Außerdem muss ich die Daten die mir die SPS an den Raspberry schickt später so weiterverarbeiten, dass ich eine Python Script damit ausführen kann. Hier habe ich leider noch keine Ahnung wie sich das umsetzen lässt. Falls jemand eine Idee hat würde ich diese gerne erfahren.

Wie ihr sicherlich schon rausgefunden habt bin ich absoluter Anfänger was dieses Thema angeht. ich würde mich schon sehr freuen, wenn ihr mir einfach ein paar hilfreiche Links zukommen lassen könntet.

Den Roboterarm um den es geht ist der Dobot Magician ( https://www.dobot.de/produkte/dobot...uz9eNANHyzQ_uciR7L9sJFyfA8mhnTBhoC5v8QAvD_BwE )als SPS kommt eine S7 zum Einsatz.

Ich danke schon im Voraus für jegliche Hilfe
 
Also ich hab noch nicht ganz verstanden, wie genau du die ganzen Teile miteinander verbinden willst.

S7-300 oder S7-1500, welche Befehle an den Roboter schicken kann, HMI zur Bedienung?
Raspberry, der was genau macht??? - Befehle von der S7 entgegennehmen und an den Roboter weitergeben?
Der Roboter, welcher über einen eigenen Prozessor verfügt, welcher mittels API Befehle entgegennehmen kann.
Soll der Raspi die API-Befehle mittels Phyton an den Roboter schicken?

In welches Codesys hast du den Raspi eingebunden?

Ein paar genauere Infos über den geplanten Aufbau wären hier hilfreich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Welche S7 das genau ist kann ich dir leider nicht sagen. Die SPS steht in der Uni und ich bin im Homeoffice. Es sollte aber wahrscheinlich eine 1500 sein.

Der Roboterarm wird über die Pydobot ( https://github.com/luismesas/pydobot ) Bibliothek auf dem Raspi gesteuert. Diese kann denn Arm bereits in vollem Umfang steuern und funktioniert wie gewünscht.
Das Ziel ist die SPS und den Pi irgendwie zu verbinden. Ich dachte dabei an Profinet.
Von der SPS sollen jetzt lediglich Signale geschickt werden, die dafür sorgen, dass verschiedene Teile des Phyton Scripts ausgeführt werden.
Beispiel: Die SPS schickt eine Bitfolge "100" an den Raspi, der führt dann sein Script so aus, dass der Arm 90° nach links schwenkt, etwas greift und dann wieder 120° nach rechts schwenkt und das gegriffene Teil abstellt.

Auf dem Pi ist gerade v3.5.16.20 installiert.

Ich hoffe, dass ich es nun etwas besser beschrieben habe. Und danke schon mal für die schnelle Rückmeldung
 
Wenn du es einfach haben willst, dann lässt du auf dem Pi einen Modbus TCP Slave laufen (gibt es auch komplett in Python), und schreibst dann von der SPS entsprechende Werte in die Register.
Dann benötigst du kein Codesys auf dem Pi und musst dich auch nicht um die Profinet GSDML kümmern. Die Echtzeitfähigkeit von Profinet wirst du vermutlich nicht benötigen.

Wenn du auch den Umgang mit Profinet usw. erlernen möchtest, dann ist der Weg mit Codesys Runtime und Profinet natürlich sinnvoll.
 
Für Python gibt es Snap7 (https://pypi.org/project/python-snap7/).
Damit kann man vom Raspi aus Daten aus der SPS lesen und auch schreiben. Das Ganze einfach per Netzwerk. (TCP/IP). Wirklich einfach, es gibt auch Beispiele im Netz, ich hatte das in ein paar Stunden am Laufen.
Es reicht also, in der SPS die entsprechenden Kommandos in einem Datenbaustein abzulegen, der Raspi liest das aus und steuert den Roboter.
Ich würde auf jeden Fall noch ein Handshake implementieren, so dass die SPS weiß, dass ein Kommando angenommen wurde und auch gemeldet bekommt, dass das Kommando beendet ist.
 
Zuletzt bearbeitet:
prinzipiell kannst du das schon auch mit CODESYS und dem PI machen,
als Profinet Device betreiben (oder aber eben Controller) - geht so:
Hier gibt’s ein Besipielprojekt:
(alles bitte aktualsieren - rechtslick im Gerätebaum auf SPS und Profinet usw)

https://forge.codesys.com/forge/talk/Runtime/thread/04361f89ec/?limit=25#718f
Wenn du den Pi als Device verwendest musst du im CODESYS Geräterepository den CODESYS Profinet Device Controller Exportieren und daraus die GSDXML verwenden und deiner Siemesn SPS "füttern".


Grüße
 
Erstmal danke für die vielen Antworten

Ich habe das ganze nun über Snap7 probiert. Die Bibliothek kompiliert auch ohne Fehler auf dem PI.
Heute konnte ich es dann endlich mal an der SPS testen und da wurde mir immer die Fehlermeldung geschmissen, dass die Verbindung verweigert wurde(' TCP : connection refused'). Ich habe den PI sowohl im gleichen Subnetz wie die SPS betrieben als auch an der SPS selber. Immer über eine LAN-Verbindung.
Eine suche über das TIA-Portal nach dem PI war leider erfolglos. Dieser wurde nie im Netz erkannt.

Meine Frage ist nun ob ich den PI von der SPS-Seite aus ins Programm einbinden muss oder ob es reicht das Python-Skript auf dem PI auszuführen oder ob es evtl. noch eine weitere Möglichkeit gibt, die ich bis jetzt übersehen habe.

Falls es hilft: Ich hatte mich bis jetzt meist an diese Anleitung gehalten ( https://simplyautomationized.blogspot.com/2014/12/raspberry-pi-getting-data-from-s7-1200.html )
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hm... also ich denke am einfachsten gehts wenn du den PI zum CODESYS PN Slave machst und auf Siemens Seite diesen Slave über die Prozessdaten bedienst.
Die GSDML die du auf Controllerseite brauchst kannst du über das Device Repository exportieren und dann auf Siemens Seite verwenden.
Grüße
 
Das mit Snap7 würde ich auch vergessen, dazu musst du in der 1200er auch noch ein paar Vorbereitungen treffen, wie Put/Get erlauben, Datenbausteine nicht optimiert machen. Außerdem finde ich die Datenrichtung "verkehrt", dein Gerät sollte für meinen Geschmack passiv sein.

Meiner Meinung nach entweder Modbus-TCP (das einfachste, geht von Codesys und von der S7 1200/1500 out of the box), oder halt Profinet Slave.
 
Zuletzt bearbeitet:
Das mit Snap7 würde ich auch vergessen, dazu musst du in der 1200er auch noch ein paar Vorbereitungen treffen, wie Put/Get erlauben, Datenbausteine nicht optimiert machen. Außerdem finde ich die Datenrichtung "verkehrt", dein Gerät sollte für meinen Geschmack passiv sein.

Meiner Meinung nach entweder Modbus-TCP (das einfachste, geht von Codesys und von der S7 1200/1500 out of the box), oder halt Profinet Slave.

Soweit ich ihn verstanden habe, wird der Roboter über python gesteuert. Da finde ich den Umweg über Codesys zu schwierig. Dann lieber die Modbus Kommunikation direkt ins python Skript mit einbauen. Wenn man "neuere" Kommunikationsmittel vorzieht könnte man bei einer s7-1500 soweit ich weiß SPS seitig auch einen OPC Ua Client aufbauen. Profinet
würde ich mal Mangels frei verfügbarer Stacks und vermutlich nicht gebrauchter Echtzeitfähigkeit ausschließen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Soweit ich ihn verstanden habe, wird der Roboter über python gesteuert. Da finde ich den Umweg über Codesys zu schwierig. Dann lieber die Modbus Kommunikation direkt ins python Skript mit einbauen. Wenn man "neuere" Kommunikationsmittel vorzieht könnte man bei einer s7-1500 soweit ich weiß SPS seitig auch einen OPC Ua Client aufbauen. Profinet
würde ich mal Mangels frei verfügbarer Stacks und vermutlich nicht gebrauchter Echtzeitfähigkeit ausschließen.

Ja, hatte ich beim ersten mal von mir auch schon so geschrieben. Warum auch immer hatte ich da jetzt rausgelesen er will das in Codesys haben.

Also Modbus-Server auf dem Raspberry in Python z.B. mit dem Modul pymodbus starten, MB_CLIENT Funktion aus der Bibliothek in der 1200 oder 1500 aufrufen und Register lesen / schreiben und ab gehts.
 
Also angefangen hat es damit, dass ich es über Codesys machen wollte. Wie testor aber schon geschrieben hat wird der Roboter über ein Python-Skript gesteuert. Daher fand ich die Idee recht elegant einfach eine weitere Libary in mein bereits bestehendes Skript einzubinden um somit die Abfrage der SPS und die Steuerung des Roboters in einem Skript gemeinsam in einem Skript zu haben.

Den Weg über Codesys würde ich nach euren Tipps nun ausschließen. Da ich mir sonst noch Gedanken machen muss, wie ich die Daten von Codesys an das Skript übergebe.

Die Idee mit dem Modbus-Server hört sich, so wie ihr es schreibt, recht einfach an. Habt ihr da evtl. nen hilfreichen Link, wo ich mich etwas in das Thema reinlesen kann ?
Wie gesagt bin kompletter Neuling was das Thema SPS angeht und leider auch nach langer Internet Suche immer noch auf eure Hilfe angewiesen.

In dem Sinne vielen Dank für die Antworten:)
 
Bei pymodbus gibts es hier ein kleines Beispiel:

https://pymodbus.readthedocs.io/en/latest/source/example/synchronous_server.html

Wenn du das startest, dann kannst du ab Halteregister (hr) Adresse 0 z.B. den Wert 17 lesen (100 mal).

Es gibt unter Linux und Windows diverse Testprogramme für Modbus, für Windows z.B. Modbus Master.

Auf der S7 Seite muss die MB_CLIENT Funktion aus der Kommunikationsbibliothek aufgerufen werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei pymodbus gibts es hier ein kleines Beispiel:

https://pymodbus.readthedocs.io/en/latest/source/example/synchronous_server.html

Wenn du das startest, dann kannst du ab Halteregister (hr) Adresse 0 z.B. den Wert 17 lesen (100 mal).

Es gibt unter Linux und Windows diverse Testprogramme für Modbus, für Windows z.B. Modbus Master.

Auf der S7 Seite muss die MB_CLIENT Funktion aus der Kommunikationsbibliothek aufgerufen werden.

Aber ist daran einfacher, als Snap7? Du mußt genauso Vorbereitungen treffen und bist nicht unabhängig von den Einstellungen in der S7.

PS: Wenn Siemens die neuen DB "optimiert" nennt dann ist das kein Qualitätsmerkmal sondern eher ein Marketinggag. Im Zusammenhang mit einer Kommunikation, die ich Bits beinhaltet ist es garantiert nicht sicher, ob die optimierten Bausteine hier tatsächlich schneller sind.
 
Aber ist daran einfacher, als Snap7? Du mußt genauso Vorbereitungen treffen und bist nicht unabhängig von den Einstellungen in der S7.

Snap7 ist prinzipiell auch einigermaßen einfach zu verwenden, ja.

Aber es ist meiner Ansicht nach sinnvoller, dass ein Gerät das eine Dienstleistung für eine SPS anbietet, nicht von sich aus versucht in eine feste SPS in einen Datenbereich zu schreiben. Ich würde das zumindest nicht wollen. Snap7 bietet zwar auch an als Server zu arbeiten und so zu tun als wäre es eine S7 SPS, auf die du mit Put/Get oder Bsend/Brecv Daten-Zugriff bekommen kannst, aber das halte ich auch für abwegig. Modbus-TCP Slave ist das was einem Profinet-IO Device von der Funktionsweise ungefähr nahe kommt. Und nur wegen dem Profinet Krams mir da noch eine Codesys-Runtime mit Lizenz draufpacken zu müssen, und dann die Daten wieder aus Codesys zu transferieren um sie dann in Python weiterzuverarbeiten scheint mir für die Aufgabe zu kompliziert und auch unnötig (außer es ist die Aufgabenstellung).
 
Snap7 ist prinzipiell auch einigermaßen einfach zu verwenden, ja.

Aber es ist meiner Ansicht nach sinnvoller, dass ein Gerät das eine Dienstleistung für eine SPS anbietet, nicht von sich aus versucht in eine feste SPS in einen Datenbereich zu schreiben. Ich würde das zumindest nicht wollen. Snap7 bietet zwar auch an als Server zu arbeiten und so zu tun als wäre es eine S7 SPS, auf die du mit Put/Get oder Bsend/Brecv Daten-Zugriff bekommen kannst, aber das halte ich auch für abwegig. Modbus-TCP Slave ist das was einem Profinet-IO Device von der Funktionsweise ungefähr nahe kommt. Und nur wegen dem Profinet Krams mir da noch eine Codesys-Runtime mit Lizenz draufpacken zu müssen, und dann die Daten wieder aus Codesys zu transferieren um sie dann in Python weiterzuverarbeiten scheint mir für die Aufgabe zu kompliziert und auch unnötig (außer es ist die Aufgabenstellung).

Das kann man sicher so oder so betrachten, geht auf jeden Fall beides.
Der Raspi muß ja ohnehin eine Python-Schleife (main) laufen lassen, wenn er den Roboter steuern soll.
Also kann er in dieser Schleife auch die Daten aus der SPS lesen bzw. in die SPS schreiben.
Wie schon geschrieben, ein kleines Protokoll gehört da ohnehin dazu, so dass die SPS jeweils weiß, die Daten wurden vom Raspi gelesen und akzeptiert, der Raspi muß das ebenfalls so handhaben.
Das ist aber ein rel. simples Handshake, nicht weiter schlimm.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Prinzipiell ist mir die Lösung mit Snap7 lieber. Da brauche ich nur ein paar Zeilen mehr in mein Python-Skript schreiben und es funktioniert..... theoretisch.

Was mich wieder zur eigentlichen Frage bringt, was ich falsch gemacht habe, sodass mir die Verbindung verweigert wird. Wenn ich es aus eurer Diskussion richtig rausgelesen habe übernimmt der PI die Hauptarbeit in der Kommunikation. Also keine Einstellung seitens der SPS nötig, richtig ?

Könnte es evtl. am Netzwerk liegen, dass mir die Verbindung verweigert wird ? Dann verstehe ich aber nicht, warum das auch passiert wenn ich den PI direkt an die SPS klemme
 
Prinzipiell ist mir die Lösung mit Snap7 lieber. Da brauche ich nur ein paar Zeilen mehr in mein Python-Skript schreiben und es funktioniert..... theoretisch.

Was mich wieder zur eigentlichen Frage bringt, was ich falsch gemacht habe, sodass mir die Verbindung verweigert wird. Wenn ich es aus eurer Diskussion richtig rausgelesen habe übernimmt der PI die Hauptarbeit in der Kommunikation. Also keine Einstellung seitens der SPS nötig, richtig ?

Du musst in der SPS Put/Get Kommunikation freigeben, und bei den Datenbausteinen auf die du zugreifen willst muss die Option "optimiert" abgewählt werden, ohne dieses siehst du auch keine Adressoffsets. Beides ist nicht Voreinstellung.
 
Für Python gibt es Snap7 (https://pypi.org/project/python-snap7/).
Damit kann man vom Raspi aus Daten aus der SPS lesen und auch schreiben. Das Ganze einfach per Netzwerk. (TCP/IP). Wirklich einfach, es gibt auch Beispiele im Netz, ich hatte das in ein paar Stunden am Laufen.
Es reicht also, in der SPS die entsprechenden Kommandos in einem Datenbaustein abzulegen, der Raspi liest das aus und steuert den Roboter.
Ich würde auf jeden Fall noch ein Handshake implementieren, so dass die SPS weiß, dass ein Kommando angenommen wurde und auch gemeldet bekommt, dass das Kommando beendet ist.
Hallo Ralle,
ich habe Datenaustausch (lesen und schreiben) zwischen SPS-DB und Raspi (mit snap7) erreicht. Was ich noch tun ist, das Programm zu überwachen. Weil Lese- oder Schreibprogramme lange Zeit laufen müssen. Meine Idee ist, einen Zähler zu demselben DB hinzuzufügen. Der Zähler zählt jedes erfolgreiche Schreiben von Daten. Dann vergleiche ich Alt_Value und Aktuell_Value in FC. Ist das das Handshake was du sagst? Oder was ist Handshake? Ich freue mich auf deine Antwort.
 
Zurück
Oben