Kommunikaton 314-2DP <> CP343-1 Advanced IT <> IO-Devices <> S7-1200

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kommunikaton 314-2DP <> CP343-1 Advanced IT <> IO-Devices <> S7-1200

Nabend die Damen und Herren

Ich bin dabei beim KD eine zusätzliche Anlage in einem Fremdprojekt einzubinden, vorliegen habe ich aktuell die 314-2DP. Diese ist aktuell mit dem CP343-1 Advanced IT verbunden, welcher wiederrum der PNIO-Controller ist.
Eine 1200er kommuniziert mit mehreren Barcodescannern und ist deren PNIO-Controller.
In der 1200er gibt es NUR den OB1, welcher die Daten der Scanner einliest, im SCL-Code umstrukturiert und in einem DB ablegt.
Die 314 holt per GET über den CP343 die Daten aus dem DB der 1200er, geschrieben wird nichts.

Ich muss nun noch eine Verbindung zu einer anderen 1200er (ganz andere Maschine) via PN/PN-Koppler aufbauen, daher überlege ich ob ich das nicht alles sortiere und ein wenig umstricke:

- Barcodescanner werden am CP343 als PNIO-Devices angemeldet
- PN/PN wird am CP343 als PNIO-Device angemeldet
(Datenbereiche der Barcodescanner sowie PN/PN-Koppler werden mit wenig Reserve aneinandergereiht)
- per PNIO-Send/Receive hole ich mit der 314er die Daten aus den IO-Devices mit einem Schwung, lager diese in einem DB ab und sortiere dann auf die anderen DBs um bzw. die Daten der Scanner laufen nochmal durch den SCL-Code, diesmal auf der 314er.
- die alte 1200er kann ich dann komplett aus dem System nehmen

Die Struktur hierhin zu ändern wäre doch eigentlich der eleganteste Weg oder spricht da etwas gegen?
Ich würde hierdurch die Anzahl der Verbindungen reduzieren, die 1200er die nichts macht als PNIO-Controller und Datensammler zu spielen entfernen können und kann mit dem Einsatz von einem PNIO-Send/Receive alle Daten der Devices lesen und schreiben.

 

[MSB]

Hier gilt es imho erst mal zu ergründen, warum sich wer den "Aufwand" mit der 1200er gemacht hat.

Vorteile der jetzigen Lösung:
- zwischen 1200er und 300er vergleichsweise wenig Traffic (Firmennetz?)
- Die 1200er kann relativ einfach erweitert werden, ohne nötigen Stop der Anlage (ändern der HW-Konfig)
- die 1200er ist in Kommunikationssichtweise, das modernere Konzept, und spottbillig

Also so ganz pauschal würde ich mir jetzt keine Antwort zutrauen.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey, die IB meines Kopplers und Integration der neuen Anlage ist durch, bin aber nicht mehr dazu gekommen die anderen Dinge zu erledigen, nur einmal reinschnuppern. Deinen Beitrag habe ich heute morgen aber schon gelesen, war nur zu stressig heute, der Koppler wollte nicht wie ich mir das vorgestellt hab (3h für nen ollen Koppler grr).

Also das mit dem Ergründen des Aufwands wird womöglich schwieriger, ich sehe da irgendwie keinen Sinn.
Habe mir den OB1 heute angeschaut, es wird wirklich lediglich in NW1 von Scanner1 abgeholt, die Zeichenfolge in array[1..10] of char umgewandelt und in einem DB abgelegt. Das gleiche für den zweiten Scanner gibt es dann in NW2. Das wars auch schon.

Das mit dem Traffic: Die 314 holt in zwei Get-Aufrufen aus einem DB jeweils einen array ab. Wenn ich die Scanner an den CP projektiere, dann brauch ich nur einen Aufruf von pnio-receive, die CPU wäre also weniger belastet, da nur eine Verbindung, die ich nun ohnehin schon aufbaue, genutzt würde.
Ein Firmennetz hängt nicht an der Anlage, lediglich eine Fernwartungseinheit die ich heute installiert habe, aber die geht direkt ins Internet.

Erweiterung - es ist eine 1211er, außer ET-Stationen ist die Erweiterung dann ja nicht wirklich machbar. Das die 1211 die 314er jemals ersetzen sollte kann ich mir nicht vorstellen, die 314er ist in 90% der Bausteine im AWL programmiert worden.

Ausfallsicherheit - CPU-Stop bei Erweiterung - Ja, könnte man meinen, aber ein Stop der 314er ist bei der Anlage kein Problem. Sie kann jederzeit mal eine Minute Auszeit machen, die Wiederanlaufzeit der Anlage liegt bei unter 10 Sekunden, keine Motoren die hochfahren müssen oder sonstwas.

Ja, eine 1200er ist moderner, auch billiger, aber irgendwie sehe ich keinen Sinn in der CPU, außer Ressourcenverbrauch. Ich werde in einem der zukünftigen Arbeiten das Netz aufräumen, ist ja schnell gemacht, wurde heute auch so schon kurzfristig besprochen als ich fragte warum die da überhaupt ist. Eine Antwort hatte der Elektriker nicht. Ist aber halb so wild, dann haben die Azubis später eine 1211er zum Spielen, bringt wohl mehr.

 

[MSB]

Das mit dem Traffic: Die 314 holt in zwei Get-Aufrufen aus einem DB jeweils einen array ab. Wenn ich die Scanner an den CP projektiere, dann brauch ich nur einen Aufruf von pnio-receive, die CPU wäre also weniger belastet, da nur eine Verbindung, die ich nun ohnehin schon aufbaue, genutzt würde.

Wie hoch die CPU belastet ist, hat aber nichts mit dem Traffic Einwand zu tun.
Bei PN hast du Dauertraffic im PN Sendetakt, also völlig azyklisch zur CPU. Bei der Get Variante nur 1x pro REQ, und das ist zudem nicht QoS priorisiert. Aber gut, wenn das ein autarkes Netz ist, dann ist der Punkt relativ egal.

Auch der HW Einwand hat nix mit EA-Baugruppen zu tun, sondern eher mit dem hinzufügen von weiteren Scannern ...

 

[escride1]

Wenn das REQ des Get so eingestellt ist, das er bei erfolgter Abholung sofort wieder ein REQ bekommt, ist das dann nicht genau gleich zum PNIO-Revieve der sein req intern enthält? Wo könnte ich eine Dokumentation über das Verhalten finden was den Traffic angeht?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn das REQ des Get so eingestellt ist, das er bei erfolgter Abholung sofort wieder ein REQ bekommt, ist das dann nicht genau gleich zum PNIO-Revieve der sein req intern enthält? Wo könnte ich eine Dokumentation über das Verhalten finden was den Traffic angeht?

Gewährleistet ist nur bei Profinet IO, dass im eingestellten Aktualisierungszyklus z.B. alle 2ms die eingestellte Datenmenge übertragen wird.

Ob der Put/Get-Aufruf überhaupt nach einem Zyklus fertig meldet ist nicht gewährleistet. Wenn der Get wie bei dir direkt neu aufgerufen wird und der Get nicht zwei Mal im Zyklus aufgerufen wird um für die notwendige Flanke zu sorgen, dann dauert die Übertragung im kürzesten Fall 2x Zykluszeit. Bei 10ms Zykluszeit dementsprechend frühestens alle 20ms neue Daten. Bei Profinet IO kannst du es genau berechnen wie viele Bytes z.B. pro Minute übertragen werden. Bei der Get-Variante mit der S7-Kommunikation kannst du nur eine Obergrenze anhand der Zykluszeit berechnen.

Bei der S7-Kommunikation ist der Overhead mit IP+TCP+S7 bei so kurzem Telegrammen mit 10 Bytes wesentlich höher als bei Profinet IO. Bei PN-IO wird das zumindest auf die Mindestgröße von 40 Bytes aufgeblasen, das hast du bei IP+TCP schon alleine für die Header der beiden Protokollstapel. Dafür kannst du PN-IO eben auch nicht routen.