TIA IP-Adresse auslesen (ET 200 SP CPU 1510)

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo in die Runde!
Ich diskutiere ein Programm, das ich auf mehreren Steuerungen im gleichen Netz laufen lassen möchte.
In Abhängigleit von einem einzigen Parameter in einem globalen Datenbaustein soll die Steuerung ihre aktuelle IP auslesen und im Bedarfsfall ändern.
Das geht auch mit der Bibliothek LPNDR und T_CONFIG soweit problemlos, ich frage mich nur gerade, ob das Auslesen auch mit weniger Ballast geht. Wegen einer 4-Byte-breiten IP-Adresse bekomme ich eine ganze Reihe von Arrays mitgeliefert, von denen ich nichts benötige.

?

 

[PN/DP]

Gute Idee, wenn danach außer Dir niemand mehr die Steuerung im Netz wiederfindet

Die SPS könnte sich in einem DWORD in einem DB merken, welche IP sie sich zuletzt gegeben hat. Dann braucht sie keine überflüssigen Daten ignorieren.

Harald

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gute Idee, wenn danach außer Dir niemand mehr die Steuerung im Netz wiederfindet

Mehrere Steuerungn mit einem zu > 90% identischem Code und nur am Ende hochgezählter IP sollen immer auf dem gleichen Stand bleiben. Da ziehe ich ein Programm für alle Steuerungen vor.

 

[PN/DP]

1) Wozu muß die Steuerung wissen, welche IP sie gerade hat?
2) Wozu muß sie nach dem Laden ihre eigene IP ändern? Du kannst doch das Programm vom TIA auf eine frei wählbare Zugangsadresse laden, die nicht mit der in Gerätekonfig projektierten IP übereinstimmt? die IP in der Gerätekonfig ändern, Hardware übersetzen und dann auf die projektierte IP laden?

Die < 10% nicht identischer Code sind was? Wie verhinderst Du/stellst Du sicher, daß bei Zugriff von TIA die 10% nicht von TIA "ausgebügelt" werden?

 

[Ludewig]

Diese Diskussion beantwortet jetzt meine Frage nicht wirklich.

Es sei nur gesagt:
Die Steuerungen sind von außen nicht erreichbar. Die Person, die Programmupdates nachladen müsste, kennt das Programm nicht und soll auch nicht gezwungen sein, mehrere individuelle Hardwarekonfigurationen für das gleiche Programm herzustellen und dann zu laden. Der Gedanke ist, einen einzelnen Parameter in einem DB festzulegen, der nur beim Hochlauf oder bei einer Änderung dafür sorgt, dass die Steuerung die richtige IP hat und die richtigen Verbindungen aufbaut (programmierte Iso-on-TCP-Verbindungen).

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese Diskussion beantwortet jetzt meine Frage nicht wirklich.

Das ist normal hier...

Im übrigen wird es nicht kürzer gehen...

 

[Ludewig]

Danke @ NBerger.
Das erinnert mich an die Profinetabfrage, wo ich auch ein Array für alle Adressen im Subnetz anlegen muss, um nachher zwei Geräte auszulesen.

Noch ein kurzer Nachtrag: Der individuelle Code < 10% ist natürlich in jeder Steuerung vorhanden, wird halt nur in Abhängigkeit vom Parameter "Anlagenkennung" aktiv oder nicht.

 

[JesperMP]

Die Steuerungen sind von außen nicht erreichbar. Die Person, die Programmupdates nachladen müsste, kennt das Programm nicht und soll auch nicht gezwungen sein, mehrere individuelle Hardwarekonfigurationen für das gleiche Programm herzustellen und dann zu laden.

und

Der individuelle Code < 10% ist natürlich in jeder Steuerung vorhanden, wird halt nur in Abhängigkeit vom Parameter "Anlagenkennung" aktiv oder nicht.

Das man Programmteile flexibel aktiviert bzw. deaktivert abhängig von die installierte Optionen ist ganz normal. Aber pro Machine soll man eine individuelle Backup haben, wo die Optionen dokumentiert sind, und die 'Taufung' zu sehen ist. Sonnst hat man Kaos. Ich wurde definitiv nicht die CPU seine eigene IP auslesen um 'dynamisch' die Optionen zu steuern.

Der Gedanke ist, einen einzelnen Parameter in einem DB festzulegen, der nur beim Hochlauf oder bei einer Änderung dafür sorgt, dass die Steuerung die richtige IP hat und die richtigen Verbindungen aufbaut (programmierte Iso-on-TCP-Verbindungen).

Das kannst du mittels den genannte T-CONFIG und die Bausteine für 'Open User Communication'.

Aber die Verknüpfung zwischen IP und Optionen wurde ich nicht machen.
Wenn du eine Supportanfrage bekommst für eine bestehende Maschine sollst du ganz schnell das richtige Programm mit die korrekte Optionen öffnen können. Es soll nicht zuerst notwendig sein die IP zu suchen um zu erkennen, um welche Maschine es handelt und welche Optionen sind aktiv.
D.h. sämtliche Maschinen hat eine eigene Programm und Backup, erkennt durch der Maschinen-Nummer; egal das es um Serienmaschinen handelt.

 

[R4m80]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus,

Falls noch gesucht:
Ich habe mir in der Vergangenheit mal genau den Teil aus der Bibliothek rausgesucht, der nur IP, Subnet, Gateway, MAC und Schnittstellennamen ausliest.

Grade auf einer 1516F-3 PN/DP FW: V2.6.1 TIA Portal V17 notdürftig getestet.

Möglicherweise gehts besser oder sauberer, aber ich bin heute nicht mehr soviel, mir das genauer anzusehen.

Viel Spaß damit.

 

[PN/DP]

Diese Diskussion beantwortet jetzt meine Frage nicht wirklich.

Klar, daß Du über Deine vermeintlich supertolle Idee nicht diskutieren willst. Ich frag mich nur immer noch, wozu die SPS überhaupt erst ihre eigene IP-Adresse abfragen muß, sie braucht doch nur "den einzigen Parameter" abfragen und seine IP entsprechend einstellen. Darf die das nicht bei jedem Anlauf machen?

PS: wie lange hält eigentlich so eine mit T_CONFIG eingestellte IP-Adresse? Überlebt die ein Power-Aus/Ein?

 

[Ludewig]

@ R4m80
Man sagt ja jetzt: You made my day!
Hinweis: Um die Quelle in TIA V16 zu importieren, musste ich folgende Zeile abändern:
#name_length := BYTE_TO_USINT (#Data_Record.Data[0]);
Hier meckert der Compiler an, dass er keine implizite Typkonvertierung machen wolle.
Danach funktionierte Dein Baustein auf Anhieb.

@PN/DP
Im Augenblick untersuche ich ein Konzept. Und zu diesem gehört, dass neue Steuerungen mit einer nicht benutzten IP hochlaufen und dann per Parameteränderung ihre finale IP und ihre Verbindungen einrichten, mehr ist das noch nicht.
Die Haltbarkeit ist konfigurierbar:

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe dieses Projekt mittlerweile etwas vertieft. Beteiligt ist folgende Hardware:
CPU 1513-1 PN (6ES7 513-1AL02-0AB0)
CP 1543-1 (6GK7 543-1AX00-0XE0)
Feststellung 1: Die CPU lässt eine permanente (Mode 1) und eine temporäre Speicherung (Mode 2) der Adressdaten zu, der CP aber nur eine temporäre.
Da TIA bei dieser Konfiguration keine IP-Adresse kennt, muss man alle kompatiblen Geräte suchen, um sich zu vebinden.

Feststellung 2: In Kombination mit einem Basic Panel stellt sich folgendes Problem: Ein solches Panel erlaubt die Einstellung der Netzwerkdaten in seinen Einstellungen, nicht jedoch die Auswahl einer HMI-Verbindung. Da ist mir die Logik von Siemens nicht richtig klar. Einerseits kann ich das Basic Panel in TIA so konfigurieren, dass Netzwerk und Profinetname nur am Gerät eingestellt werden, aber eine Verbindung kann ich am Gerät nicht konfigurieren?!

 

[R4m80]

Servus,

Ich habe jetzt leider kein V16 zur Hand und habe das jetzt kurz mit V17 probiert.

Zu Feststellung 1, kannst du auch direkt nach der IP-Adresse suchen.
Das ist auch hilfreich, wenn PG und SPS/HMI nicht im selben Subnetz sind oder sogar durch NAT getrennt sind.


Zu Feststellung 2:
Ich konnte ohne Probleme eine HMI-Verbindung zur SPS anlegen.



Auch zur CP war das ohne weiteres möglich.



Oder habe ich hier was falsch verstanden?

 

[PN/DP]

Feststellung 2: In Kombination mit einem Basic Panel stellt sich folgendes Problem: Ein solches Panel erlaubt die Einstellung der Netzwerkdaten in seinen Einstellungen, nicht jedoch die Auswahl einer HMI-Verbindung. Da ist mir die Logik von Siemens nicht richtig klar. Einerseits kann ich das Basic Panel in TIA so konfigurieren, dass Netzwerk und Profinetname nur am Gerät eingestellt werden, aber eine Verbindung kann ich am Gerät nicht konfigurieren?!

Auch deshalb läßt man Steuerungen nicht ihre eigene IP ändern, weil sonst das HMI-Panel nicht weiß, mit welcher Steuerung es kommunizieren soll.

Allerdings: Siemens hat auch das nachgebessert. Basic Panels "2nd Generation" können die IP-Adresse der Ziel-Steuerung in der projektierten HMI-Verbindung ändern, allerdings nur für S7-1200/1500. siehe Service & Commissioning > Edit Connections
Ich weiß aber nicht, ob eine solche Änderung einen nachfolgenden Transfer des HMI-Projektes auf das Panel überlebt. Ein Beitriebssystem-Update (Laden Panel-Image) sicher nicht.

PS: Ändern der eigenen IP-Adresse und des eigenen Profinetnamens des HMI-Panels hat nichts damit zu tun, ob auch die in der HMI-Verbindung projektierte Steuerung auch noch im Netzwerk umherspringt (die eigene IP ändert).

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zu 1. Diese Möglichkeit kannte ich bereits. Danke dennoch!

Zu 2.

Allerdings: Siemens hat auch das nachgebessert. Basic Panels "2nd Generation" können die IP-Adresse der Steuerung in der projektierten HMI-Verbindung ändern, allerdings nur für S7-1200/1500. siehe Service & Commissioning > Edit Connections
Ich weiß aber nicht, ob eine solche Änderung einen nachfolgenden Transfer des HMI-Projektes auf das Panel überlebt.

Das ist die Antwort auf meine Frage. Diese Einstellmöglichkeit habe ich für meine Versuche vermisst.