TIA PUT / GET oder I-DEVICE Kommunikation?

[SPS'ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Ich habe 2 CPU's: S7-1515F 2-PN und eine 1510SP-1PN, welche Daten austauschen sollen. Die CPU's sind in getrennten Projekten und sollen nur über eine definierte Schnittstelle miteinander Kommunizieren. In dieser Schnittstelle werden Startbefehle von der 1515F gesendet und es werden Istwerte von der 1510SP empfangen.

Hier gibt es nun 2 Möglichkeiten:

Entweder..

die Verbindung über PUT/GET mit der 1515F als aktiver Partner. Dies habe ich so noch nicht gemacht und überlege noch, wie der dauerhafte Zyklische Austausch am besten zu programmieren ist. Ich möchte die Kommunikation nicht einmalig anstoßen, sondern dauerhaft ausführen. Außerdem muss ich mögliche Fehler abfangen.

oder...

die Verbindung über Profinet, wobei die 1515F der IO-Controller und die 1510SP der IO-Device wäre. Diese Verbindung sieht für mich auf den ersten Blick einfacher aus, da das Gerät als Profinet Teilnehmer gehandhabt wird und man schon eine Menge von z.B. einem Frequenzumrichter adaptieren kann.

Nun frage ich was wohl die bessere Lösung ist. Könnt ihr mir eure Erfahrungen mitteilen?


Edit:

Folgende Datenmengen sollen ausgetauscht werden:

Von 1515F zu 1510SP: 5 Bool, 5 Real => Steuerbefehle und Sollwerte

Von 1510SP zu 1515F: 10 Bool, 30 Real, 5 Word => Zustände und Istwerte

 

[Mrtain]

Ich würde zu iDevice tendieren.
Put/Get soll man laut Siemens nicht mehr verwenden.

 

[SPS'ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde zu iDevice tendieren.
Put/Get soll man laut Siemens nicht mehr verwenden.

Ok, das man das gar nicht mehr verwenden sollte wusste ich nicht mal.

Eine weitere Idee wäre noch OPC-UA Kommunikation. Wobei ich hier Angst hätte vor evtl. Zertifikatsfehlern oder ähnlichem. OPC-UA habe ich noch nicht in der Anlagensteuerung verwendet sondern lediglich für Rezepte oder ähnliche Daten.

 

[Larry Laffer]

Mein Ansatz wäre auch IDevice - du definierst im Grunde den Austauschblock und übergibst das Ganze als GSDML-File an die andere Steuerung.
Was genau willst du denn alles austauschen ?

 

[Mrtain]

Ok, das man das gar nicht mehr verwenden sollte wusste ich nicht mal.

Eine weitere Idee wäre noch OPC-UA Kommunikation. Wobei ich hier Angst hätte vor evtl. Zertifikatsfehlern oder ähnlichem. OPC-UA habe ich noch nicht in der Anlagensteuerung verwendet sondern lediglich für Rezepte oder ähnliche Daten.

Es ist eine Empfehlung, wenn auch eine berechtigte.
Für OPC UA werden allerdings ggf. Lizenzen fällig.

 

[SPS'ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Ansatz wäre auch IDevice - du definierst im Grunde den Austauschblock und übergibst das Ganze als GSDML-File an die andere Steuerung.
Was genau willst du denn alles austauschen ?

Diese Daten möchte ich austauschen:

Von 1515F zu 1510SP: 5 Bool, 5 Real => Steuerbefehle und Sollwerte

Von 1510SP zu 1515F: 10 Bool, 30 Real, 5 Word => Zustände und Istwerte

 

[Blockmove]

Ich bin kein großer Freund von iDevice bei 2 getrennten Projekten. Normalerweise hast du dann ein gemeinsames Profinet.
Wie wär es mit nem PN-PN-Koppler? Damit hast du ne saubere Trennung der Netze und hast nen schnellen unproblematischen Datenaustausch.

 

[Onkel Dagobert]

Das verpönte PUT/GET ist aus meiner Sicht die unkomplizierteste Lösung. Und so würde ich es auch umsetzen.
Bei größeren Datenmengen eine Open User Communication. Und nur bei zeitkritischen Datenaustausch würde ich Profinet (iDevice) verwenden. Aber wenn es für dich einfacher ist, spricht auch nichts gegen Profinet bzw. iDevice.

In dem verlinkten Funktionshandbuch werden im Kapitel 9 die verschiedenen Kommunikationsmöglichkeiten kurz und knapp vorgestellt. Da kann man sich mal schnell einen kleinen Überblich verschaffen. Dort wird für die Kommunikation zwischen S7-1500 Steuerungen die offene User Kommunikation empfohlen.

... Außerdem muss ich mögliche Fehler abfangen...

Es genügt eigentlich, die Rückmeldungen "DONE" der beiden Kommunikationsbausteine PUT und GET wie einen Watchdog zu überwachen. Bei Profinet (iDevice) musst du aber eben so einen Kommunikationsausfall erkennen, um darauf reagieren zu können.

... da das Gerät als Profinet Teilnehmer gehandhabt wird und man schon eine Menge von z.B. einem Frequenzumrichter adaptieren kann...

Wie meinst du das?

 

[SPS'ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin kein großer von Freund von iDevice bei 2 getrennten Projekten. Normalerweise hast du dann ein gemeinsames Profinet.
Wie wär es mit nem PN-PN-Koppler? Damit hast du ne saubere Trennung der Netze und hast nen schnellen unproblematischen Datenaustausch.

PN Koppler wäre auch eine gute Alternative.

Gibt es eine Möglichkeit, direkt von Datenbausteinen in die Transferbereiche zu kopieren?

 

[Blockmove]

PN Koppler wäre auch eine gute Alternative.

Gibt es eine Möglichkeit, direkt von Datenbausteinen in die Transferbereiche zu kopieren?

Du kannst dir z.B. ne UDT mit der Struktur deiner Schnittstellensignale anlegen.
Damit legst du dir dann einen Datenbereich im DB an und definierst in der Symboltabelle den entsprechenden E/A-Bereich damit.
Dann kannst du mit ner einfachen Zuweisung in SCL oder mit nem Move-Befehl die Daten rüberschieben.

 

[DeaD_EyE]

Vor der Entscheidung stand ich letztens auch. PUT/GET vs. iDevice. Ich habe PUT/GET verwendet, obwohl ich alle 5 Stationen in einem Projekt hatte.

Damit habe ich einen Ringbuffer realisiert. Wenn man PUT/GET verwendet, kann man nur nicht optimierte Bereiche lesen und schreiben. Ein DB darf dann nicht optimiert sein. Das schöne ist, dass man nach dem Übersetzen des DBs die feste Struktur hat und genau sieht, wie viele Bytes übertragen werden müssen.

Im Prinzip hat die Station via PUT den gesamten Inhalt des DBs zur nächsten Station kopiert.
In der Datenstruktur war ein Bool, der immer auf True steht. Die empfangende Station prüft zyklisch, ob der Bool True ist. Falls ja, wird er auf False gesetzt und der DB in den Ringbuffer kopiert.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Prinzip kann eine S7-SPS nichts dagegen tun, dass andere Netzwerkteilnehmer absichtlich oder unabsichtlich kreuz und quer in ihrem Speicher rumschmieren, wenn die PUT/GET-Kommunikation freigegeben ist.

 

[JesperMP]

Diese Daten möchte ich austauschen:
Von 1515F zu 1510SP: 5 Bool, 5 Real => Steuerbefehle und Sollwerte
Von 1510SP zu 1515F: 10 Bool, 30 Real, 5 Word => Zustände und Istwerte

Für solche Daten wurde ich nach echten Profinet tendieren.
Entweder I-Device wenn die Netzwerke nicht getrennt werden müssen, oder PN/PN-Koppler wenn sie getrennt werden müssen.

Ich bin kein großer Freund von iDevice bei 2 getrennten Projekten. Normalerweise hast du dann ein gemeinsames Profinet.

Ist unproblematisch auch bei getrennten Projekten.
Man muss die Gerätenamen und IP Addressen koordinieren. Das ist triviell.

 

[Blockmove]

Ist unproblematisch auch bei getrennten Projekten.
Man muss die Gerätenamen und IP Addressen koordinieren. Das ist triviell.

Solange das Alles in deiner Hand ist. Wenn du aber Anlagenteile von weiteren Lieferanten kommen, kann es nervig sein.
Daher lieber nen PN/PN-Koppler zur sauberen Trennung.
Macht auch die Diagnose leichter ... Wenn er rot leuchtet -> Fehler.

 

[ThomasLevering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde I-Device nehmen.
Wenn es S7-Verbindung sein muss, dann nehmen wir jetzt immer USEND. (Gut 900byte) Da kann das Put/Get in der Cpu aus bleiben. Höchste Sicherheitseinstellung geht dann noch. Mit BSEND gab es zustände die nur durch Cpu Spannungfrei machen gelöst werden konnte