Also noch mal zur Klarheit:
Eine SPS "erkennt" natürlich angeschlossene Slaves. Aber diese müssen nicht nur in der Konfiguration angelegt werden (Vergabe des Namens und der IP, Festlegen der Zyklusparameter, etc.), sondern natürlich muss man auf der SPS dann ein Programm schreiben, welches auch Daten mit dem Slave austauscht. Das ist in der Regel bei einem bestehenden System immer lästig, denn man will eigentlich bestehende Steuerungsprogramme ungern anfassen und auf der SPS rumprogrammieren, wenn man eigentlich "nur" bestimmte Prozessvariablen von der SPS abfragen möchte oder zur SPS senden möchte.
Schnelle zyklisch arbeitende Slaves (wie unsere modulare Gateways) werden bei einer SPS eingesetzt, um die lokalen IOs durch remote IOs zu ergänzen. Dabei sollen dann ja möglichst auch die remote IOs mit einer festen und möglichst kurzen Zykluszeit die Daten mit dem Steuerungsprogramm auf der SPS austauschen.
Wenn man aber z.B. eine Scada-Lösung einsetzt, die in wesentlich langsameren Abständen Daten zum "auffrischen" des Bildes von der SPS abruft oder nur dann Daten sendet, wenn der User auf dem Bildschirm Eingaben tätigt, dann sind solche Slaves eigentlich nicht die optimale Lösung. In diesem Fall sollte man besser unsere RevPi7 Lösung einsetzen, die mit der "normalen" Ethernetschnittstelle arbeitet und über diese Schnittstelle mit der Steuerung verbunden wird. Anders als die Slave-Kommunikation benötigt diese Lösung keinerlei Eingriffe in die bestehende SPS Programmierung.
Für die Master-Slave-Kommunikation benötigts Du keinerlei IP. Die SPS findet den Slave eigenständig wenn Du unter TIA Portal die Gerätesuche startest. du kannst dann einen Gerätenamen vergaben und unter diesem wird dann der Slave eingebunden und konfiguriert. Aber wie gesagt, damit ist die Sache nicht getan. Es würden zunächst einmal gar keine Daten ausgetauscht. Dafür musst Du z.B. unter FUB einen entsprechenden Funktionsblock für die Slave-Kommunikation einfügen und diesem dann Daten zuweisen. nur so kommt es dann auch zu einem zyklischen Datenaustausch. Azyklischer Datenaustausch über sogenannte Records ist dann nochmal ein wenig komplizierter zu programmieren.
Hier mal ein Zitat aus der original Siemens Doku zu dem Thema:
Die IP Adressen der PROFINET IO Devices werden von STEP 7 erzeugt und erst im Anlauf der CPU den PROFINET IO Devices vom PROFINET IO Controller automatisch zugewiesen. Die IP Adressen aller PROFINET IO Devices, die an einem PROFINET IO Controller angeschlossen sind, haben immer dieselbe Subnetzmaske; ausgehend von der IP Adresse des PROFINET IO Controllers werden für PROFINET IO Devices IP Adressen automatisch in aufsteigender Reihenfolge vergeben.
Du siehst also, Dein S7 Experte erwartet etwas, was ein Slave nicht leisten kann: Der Salve hat in der Regel keine Möglichkeiten feste IPs anzunehmen. Er bekommt seine IP durch die SPS einmalig im Rahmen der Konfiguration zugewiesen. Ich werde daher das Gefühl nicht los, dass da dringend mal ein Profinet Experte bei Eurem Projekt Beratung leisten sollte. Oder geht halt den einfacheren Weg über Revpi7, falls nur wenige Werte pro Sekunde in die Cloud sollen etc.
