TIA Kommunikation S7 315-2DP als PN-Slave und S7 1511-1PN

[Slimer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag in die Runde,
ich bin nicht sicher, ob ich einen neuen Thread aufmachen muss, da hier schon ähnliche Themen behandelt wurden, aber meine Aufgabe ist dann doch in verschiedenen Teilen zu abweichend:

Vorhanden:
S7-315-2DP, Originalprogramm nur als Download (nur Absolut / ohne Symbolik o. Kommentare) da es den Hersteller nicht mehr gibt, Bedienung über ein PC mit Zugriff auf die SPS via MPI (auch hier kein Eingriff möglich weil nicht WinCC o.Ä. und passwortgeschützt). Auch die Umstellung / und Migrieren ins TIA ist nicht geplant.



Die Aufgabe:
Bei laufenden 24/7 Betrieb auf aktuelle PLC und HMI umstellen.

Im Allgemeinem haben wir hierfür min. 1-2 Wochen Stillstand, aber hier ist eine Unterbrechung nicht machbar. Nur einmal pro Woche kann für ca. 1h die Anlage / PLC abgeschaltet werden...
Ich habe als ersten Step den Lean nachgerüstet und möchte nun mit einer 1511er und einem TP1500 ein neues Programm aufsetzen und sukzessiv die verschiedenen Anlagenteile unter meine Kontrolle bringen. Hochdynamisches ist nichts dabei.
Mein Ansatz ist, sämtlichen Input-Profibusverkehr am Anfang vom OB1 über den Lean zur 1500er zu Mappen und dann den Output-Profibusverkehr am Ende des OB1 aus der 1500er zu (über-)schreiben bzw. an den noch nicht neu erstellten Programmteilen 1:1 durch zuschalten. Ein überwachtes Livebit würde beim Ausfall der 1500er die Überschreibung der DP-Ausgänge unterbrechen. So würde das alte Programm immer erst einmal weiter arbeiten.

Den Lean würde ich hierfür gern mit 240Bytes in beide Richtungen als PN-Slave an der 1500er betreiben. Leider habe ich bis jetzt nur 16 Bytes (siehe Bild) als Auswahl. Ich würde auch den Lean als I-Device einrichten, habe aber aus den Kommentaren hier Bedenken heraus gelesen.
Steht etwas gegen die Einrichtung mit 240 Bytes als reiner PN-Slave oder als I-Device? Wichtig ist natürlich die Stabilität und auch eine gewisse Aktualisierungszeit möglichst weit unter 100ms. Dies ist das Mindeste was benötigt wird um alle Prozesse sauber zu erfassen und anzusteuern.

Bin für eure Ideen sehr Dankbar...

 

[PN/DP]

Den Lean würde ich hierfür gern mit 240Bytes in beide Richtungen als PN-Slave an der 1500er betreiben. Leider habe ich bis jetzt nur 16 Bytes (siehe Bild) als Auswahl.

??? Dein Bild/Anhang funktioniert nicht

Steht etwas gegen die Einrichtung mit 240 Bytes als reiner PN-Slave oder als I-Device?

Nö. Der CP 343-1 LEAN kann bis zu je 512 E- oder A-Bytes in max 32 Submodulen mit je max 240 Bytes (techn. Daten)

 

[Slimer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo PN/DP,

Hab das Bild noch einmal neu eingefügt... Jetzt lesbar?

Das der Lean 240Byte in beide Richtungen kann, ist mir bekannt, aber wie füge ich diesen dann auch mit 240 Byte ein. Geht das nur über den Weg als I-Device oder gibt es hierfür auch ein Modul.
Ich habe nur die Auswahl von 16 Bytes:

 

[PN/DP]

Das sind nicht die Transferbereiche, sondern die E/A-Adressen der CP-Baugruppe im Adressraum der CPU. (wie z.B. eine normale Analog-Karte)
Die Transferbereiche werden an der Schnittstelle X1 ("PN-IO") des CP343-1 projektiert.
Siehe
SIMATIC NET CP 343-1 im SIMATIC Manager als PROFINET I-Device projektieren
Wie werden die Kommunikationsbausteine FC11 "PNIO_SEND" und FC12 "PNIO_RECV" für das PROFINET IO-Device programmiert?

 

[Slimer]

Hatte es schon vermutet..

Also ist der richtige Weg jetzt die 240 Bytes im/als I-Device anzulegen und dann die GSD zu Exportieren?

Der Weg über die FC11 bzw. FC12 wird dann nicht benötigt, wenn ich das richtig verstanden habe?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Transferbereiche werden im Adressraum des CP projektiert. FC11 und FC12 werden immer benötigt, um die Transferdaten zwischen CP und CPU zu kopieren.
Das GSD exportieren kann man machen, damit man die Transferbereiche im (TIA-)Projekt des Profinet Controllers nicht nochmal manuell eingeben muss.

 

[Onkel Dagobert]

.. Mein Ansatz ist, sämtlichen Input-Profibusverkehr am Anfang vom OB1 über den Lean zur 1500er zu Mappen und dann den Output-Profibusverkehr am Ende des OB1 aus der 1500er zu (über-)schreiben ..

Denke beim Hijacking auch an Schreibzugriffe auf Peripherieadressen. Unter Umständen können diese auch indirekt adressiert erfolgen. Diese Schreibzugriffe musst du an Ort und Stelle im Programm übernehmen oder an dortiger Stelle verhindern.

 

[Slimer]

Die Transferbereiche werden im Adressraum des CP projektiert. FC11 und FC12 werden immer benötigt, um die Transferdaten zwischen CP und CPU zu kopieren.
Das GSD exportieren kann man machen, damit man die Transferbereiche im (TIA-)Projekt des Profinet Controllers nicht nochmal manuell eingeben muss.

Hallo PN/DP,
deine Anregungen haben mich auf die richtige Fährte gebracht. Den Reiter I-Device hatte ich aus anderen Projekten in Erinnerung, war aber diesmal, wie verflixt, einfach nicht zu finden...... bis ich bemerkt hab, dass die V2.2 des Leans diese noch nicht unterstützt... Also Firmwareupdate 2.2 --> 2.4 --> 3.0 und dann sollte es gehen..

Denke beim Hijacking auch an Schreibzugriffe auf Peripherieadressen. Unter Umständen können diese auch indirekt adressiert erfolgen. Diese Schreibzugriffe musst du an Ort und Stelle im Programm übernehmen oder an dortiger Stelle verhindern.

Hallo Onkel Dagobert,
dein Hinweis ist richtig. Dies muss ich noch prüfen. Ansonsten sind in diesem Projekt zwar 2 SEW Gateways mit je 8 Umrichtern und zwei Geber verbaut, aber, wie schon geschrieben, nix mit hoher Dynamik oder Datenbausteinkopplung. Auch keine Achsen sondern nur Asyncroner mit Geschwindigkeitsvorgabe. Einzig das Positionieren von zwei Linearachsen ist evtl. besser, wenn ich diese (vorerst) noch am Ende des 300er - OB1 behandele, falls es aus zeitlichen Gründen sonst zu einem Überschwingen kommen könnte. Später kommt ja die Ansteuerung des Profibusses als CP an die 1500er und die 315 geht in Rente...

 

[Slimer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend in die Runde,

jetzt habe ich das Problem wieder auf den Tisch bekommen. Da SPS und Lean veraltet waren und wir immer an irgend welchen Stellen auf Grenzen stießen, haben wir einiges erneuert. Nach dem alles eingerichtet war, hab ich eine GSD erstellt und im TIA bzw. der 1500er eingelesen. Leider wollen die 1500 und der Lean nicht kommunizieren. Auf der Seite des Leans kommt immer folgende Fehlermeldung:

Unter Onlinezugänge sind beide Teilnehmer mit den richtigen Namen und IP-Nummern zu sehen...

TIA ist für mich täglich Brot, aber 300<->1500 will einfach nicht... Habt Ihr eine Idee? --> Vielen Dank im Voraus...



Hier die Übersicht der der Einstellungen...

Die Transferbereiche sind je 100Byte:

 

[striezel]

Wie sind "PN_IO".in und "PN_IO".Out definiert?
Ich vermute da passt der Zugriffsbereich nicht und die 100 Byte passen nicht rein.
Versuche es mal absolut mit dem richtigen Zugriffsbereich für send und recv, also zB. "P#db777.dbx0.0 Byte 100" und "P#db777.dbx100.0 Byte 100"

 

[Slimer]

Ich denke die Bereiche (je 50 Int IN und 50 Int OUT) sollten passen...:


Mich wundert, dass die Beiden beim Profinet schon keine Verbindung aufgebaut bekommen... Zumindest blinken bei Beiden die Bus-LEDs und in der Onlineansicht im TIA erscheint der LEAN als nicht erreichbar. Unter verfügbare Teilnehmer ist er aber da.... Hab auch die Namen und die IPs schon zig Mal geprüft...

 

[Slimer]

Zuviel Werbung?
-> Hier kostenlos registrieren

...müssten denn die beiden Bausteine auch schon "grün" werden, wenn noch keine Verbindung besteht?

 

[PN/DP]

Ich denke die Bereiche (je 50 Int IN und 50 Int OUT) sollten passen...:
Anhang anzeigen 80681

siehe die Hilfe zu den Bausteinen
STATUS 16#8184 Systemfehler bzw. unzulässiger Parametertyp.
(ich meine, die 4 von der Fehlernummer 8184 bedeutet, Fehler beim Parameter 4 : SEND)
Für den ANY-VARTYPE an SEND und RECV ist nur BYTE zugelassen, also BYTE-Arrays oder (beliebige) STRUCTs.

Wie sind "PNIO".OUT und "PNIO".IN deklariert? Eine einfache "faule" Deklaration als ARRAY[...] OF INT wäre unzulässig.

...müssten denn die beiden Bausteine auch schon "grün" werden, wenn noch keine Verbindung besteht?

Baustein "grün" würde bedeuten, dass nach der Bearbeitung des Bausteins das ENO = TRUE ist.
In der Baustein-Beschreibung von PNIO_SEND und PNIO_RECV gibt es keinen Hinweis, ob der ENO-Mechanismus überhaupt verwendet wird. Oder ob ENO/BIE zur Signalisierung von Fehlern verwendet wird. Es kann durchaus sein, dass die Bausteine niemals oder relativ unkontrolliert "grün" werden. Aufklärung schafft wohl nur, wenn man in die Bausteine hineinschaut.

 

[Slimer]

Hallo PN/DP,
ich hab mich tatsächlich etwas unklar ausgedrückt. Mit grün meinte ich "ohne Fehler"...
Die Deklaration der IO/OUT Bereiche sollte so passen.

Ich vermute die Probleme mehr in Richtung der 1500 bzw. auf der TIA-Seite. Wenn ich auf Teilnehmer bearbeiten, auf Suchen oder auf eine andere Übersicht gehe, sehe ich live den 300er Lean mit der angedachten IP-Adresse und dem richtigen PN-Name. In der Geräteübersicht ist der Lean aber nicht erreichbar... Sollte die Master/Slave-Beziehung nicht auch schon nur durch die richtige Einrichtung der Adressen und PN-Namen als erreichbar angezeigt werden?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich hab mich tatsächlich etwas unklar ausgedrückt. Mit grün meinte ich "ohne Fehler"...

ich habe so verstanden, dass die Box des Bausteins grün dargestellt wird. Es ist in der Baustein-Beschreibung nicht dokumentiert, was das bedeuten würde, also dass/ob das "Fehler/kein Fehler" bedeutet

Die Deklaration der IO/OUT Bereiche sollte so passen.
Anhang anzeigen 80687

ja, passt so

Dein Baustein PNIO_SEND zeigt aber den Fehler-Status 16#8184 Systemfehler bzw. unzulässiger Parametertyp
Ist der DB901 in die CPU geladen?

Was der Diagnosepuffer-Eintrag mit Ereignis-ID 16# F9C1:9C23 (Ursache: PROFINET IO-Reason 11) bedeutet, weiß ich nicht.
Kann man in der Spezialdiagnose des CP343-1 vielleicht mehr sehen?

Sind die IP-Adressen CP343-1 und S7-1500 im selben Netz?
Die S7-1500 soll der Profinet Controller sein und der CP343-1 das Profinet I-Device? Ist das auch so parametriert und in die jeweiligen CPUs geladen?
Soll vielleicht der Profinet Controller (die S7-1500?) die PN-Schnittstelle des I-Device konfigurieren? Im CP343-1 ist das aber abgewählt?
Ist die PN-Schnittstelle des CP343-1 auf 100 MBit/s eingestellt?
Ist eine Topologie projektiert? Ist im CP343-1 beim Port "Beliebiger Partner" eingestellt?

 

[Slimer]

Guten Abend PN/DP, danke für deine Anmerkungen. War leider außer Landes und kann mich erst jetzt wieder dieser Aufgabe annehmen.

Dein Baustein PNIO_SEND zeigt aber den Fehler-Status 16#8184 Systemfehler bzw. unzulässiger Parametertyp
Ist der DB901 in die CPU geladen?

DB ist geladen und auch online sichtbar

Hier der "normale" Lean-Diagnosepuffer:

Kann man in der Spezialdiagnose des CP343-1 vielleicht mehr sehen?

obwohl der Lean im TIA erreichbar ist...

Hab auch die I-Deviceeinstellungen noch einmal geprüft:





Irgendetwas stört die 1500 und diese baut darauf hin die Verbindung ab...



Könnte es an der Uhrzeit im LEAN liegen, weil evtl. die Zertifikate nicht stimmen? Ich denke nicht, weil ein einfacher Device m.E. auch kein Zertifikatsaustausch macht...

 

[Slimer]

Konnte es bei der Erstellung der GSD ein Fehler geben..? Gibt es eine Möglichkeit den LEAN im TIA ohne GSD bzw. mit so einer Art Dummy zu arbeiten?

 

[Slimer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was der Diagnosepuffer-Eintrag mit Ereignis-ID 16# F9C1:9C23 (Ursache: PROFINET IO-Reason 11) bedeutet, weiß ich nicht.
Kann man in der Spezialdiagnose des CP343-1 vielleicht mehr sehen?

Hallo PN/DP,

heute konnte ich endlich mal wieder an die alte 300er und diesmal auch die Spezialdiagnose starten:



Ein Grund für den wiederkehrenden Verbindungsabbau kann ich hieraus nicht erkennen. Mich wundert hierbei evtl. nur etwas die Uhrzeit... Die 300er, an welcher der Lean hängt hat eine aktuelle Zeit und der Lean selber nicht.... Dürfte aber auf der Ebene Profinet keine Rolle spielen (denke ich).
Wie schon geschrieben: unter den erreichbaren Teilnehmern ist der Lean "sauber" mit IP und Name erkenn- und diagnostizierbar. Auch die 300 hat keine Fehler, nur die 1500 und der Lean melden natürlich Busfehler. Es gibt doch nicht so viel Ein- bzw Verstellmöglichkeiten...

Gibt es (erst einmal) eine andere (einfache) Möglichkeit DBs mit der 1500er aus der 300er zu lesen, ohne die Konfig zu ändern (SPS läuft nun wieder für mehrere Wochen durch) ?

Vielen Dank

Ps.: Evtl. sind hier Informationen erkennbar:

 

[PN/DP]

Ein Grund für den wiederkehrenden Verbindungsabbau kann ich hieraus nicht erkennen.

ich auch nicht

Mich wundert hierbei evtl. nur etwas die Uhrzeit... Die 300er, an welcher der Lean hängt hat eine aktuelle Zeit und der Lean selber nicht....

Damit auch CPs die aktuelle Uhrzeit verwenden, muss in der CPU die Uhrzeit-Sync. "im AS: Als Master" aktiviert werden.

Der CP343-1 könnte zusätzlich "[x] Uhrzeitsynchronisation im NTP-Verfahren einschalten" und "[x] Uhrzeit an Station weiterleiten" machen.
Die CPU muss dann bei Uhrzeit-Sync. "auf MPI: Als Slave" eingestellt werden. Dann wird die Uhr der CPU mit dem NTP-Server synchronisiert.

nur die 1500 und der Lean melden natürlich Busfehler. Es gibt doch nicht so viel Ein- bzw Verstellmöglichkeiten...

Kann man beim CP343-1 LEAN den PROFINET Sendetakt auf 2ms oder 4ms heruntersetzen? Oder kann das im PROFINET Controller projektiert werden?
Wieviele PN-Geräte mit 2-Port-Switch sind zwischen der S7-1500 und dem CP343-1 LEAN? Vielleicht mal eine direkte Netzwerkkabel-Verbindung ausprobieren. Oder ein sternförmiges Netz mit einem (einfachen) Mehrport-Switch probieren (z.B. Scalance XB00..)

Gibt es (erst einmal) eine andere (einfache) Möglichkeit DBs mit der 1500er aus der 300er zu lesen, ohne die Konfig zu ändern (SPS läuft nun wieder für mehrere Wochen durch) ?

z.B. S7-Kommunikation mit PUT/GET von der S7-1500 aus und der CP343-1 LEAN als passiver Server, oder "open" TCP-Kommunikation mit Send/Receive
Was alles geht siehe das Kompendium CPU-CPU Kommunikation mit SIMATIC Controllern

 

[Onkel Dagobert]

Hab' ich's überlesen?
Wie sind eigentlich "#tmp_iocs_in" und "#tmp_iocs_out" deklariert?