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...