Step 7 Offene TCP/IP Kommunikation zwischen S7 300 und S7 1500

_Ansgar

Level-1
Beiträge
12
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich muss von einer S7 1500 ein Byte abholen. Die 1500er ist mit TIA v13 projektiert und die 300er mit Simatic Manager V5.6.

Leider habe ich keine CPs die mir die Kommunikation erleichtern würde daher muss ich die Offene TCP/IP Kommunikation über die PN Schnittstelle nutzen. Die offene Kommunikation zwischen zwei mit dem Simatic Manager projektierten Station habe ich geschafft. Nun muss ich aber von der 300er auf die 1500er zugreifen.

Hat jemand eventuell ein Beispiel oder noch ein paar PDFs zu dem Thema.

Beste Grüße
 
Die Linkliste kenne ich natürlich bereits. Leider finde ich dort keine Lösung für mein Problem
Was genau ist denn Dein Problem?

Wie die S7-300-Seite programmiert wird weißt Du ja schon. Und wie OUC in der S7-1500 programmiert wird, findest Du in der genannten Linkliste im zweiten Link unter "Kommunikation mit S7-1500": ISO-on-TCP, TCP, UDP - Open User Communication mit TCON
Da findest Du die Programmierung einer aktiven und einer passiven S7-1500.

Leider habe ich keine CPs die mir die Kommunikation erleichtern würde
Warum meinst Du daß ein CP die Kommunikation erleichtern würde? Bei OUC über die PN-Schnittstelle der CPU kommt im Grunde nur der Aufruf von TCON dazu.

Wäre vielleicht eine (Master-Slave) iDevice-Kommunikation via Profinet denkbar/sinnvoll? Da bräuchtest Du wahrscheinlich gar keine Bausteine programmieren (*), sondern müßtest einfach nur das Transfer-Byte projektieren.
(*) was für eine S7-300 CPU/CP/PN-Schnittstelle hast Du?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen,

vielen Dank für die Antworten :)

Wieso MUSST du auf die 1500er zugreifen? Mach doch da auch ne offene zweiseitige Kommunikation wie bei den zwei anderen Stationen.

Ich möchte auf die 1500er zugreifen, da diese von jemand anderem programmiert wurde und ich möglichst wenig in seinem Projekt ändern will/darf, wegen der Gewährleistung.

@ PN/DP : Für mich ist das heutige Ziel das der TCON Aufruf funktioniert. Im Moment suchen sich beide Teilnehmer (Status 7002), können sich aber nicht sehen. Ich denke es liegt an den Parametern, aber neuer Tag neues Glück. Ich bin noch in der Vorbereitung, daher kann ich leider noch nicht genau sagen welche Steuerung tatsächlich Vorort ist. Ich suche eine Kommunikationsmöglichkeit, die grundsätzlich funktioniert.
 
Zuletzt bearbeitet:
Also Prinzipiell, wäre doch die einfachste Variante, wenn er PUT/GET erlaubt und du mit PUT und GET direkt die Daten aus der CPU holst.
Dazu muss auf der 1500 ein nicht Optimierter Baustein angelegt sein und du verwendest in deiner 300er CPU eine einseitige S7 Verbindung.

Damit hat der Programmierer von der 1500 nur den Aufwand den Datenpunkt bereit zu stellen.

Warum eigentlich unbedingt eine OUC? Die S7 Kommunikation funktioniert genauso zwischen 300 und 1500.
 
Moin,

also es funktioniert jetzt alles :) Der Kunde ist König daher die Art der Verbindung. Es gibt bestimmt einige elegantere Varianten die möglich sind.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

also es funktioniert jetzt alles :) Der Kunde ist König daher die Art der Verbindung. Es gibt bestimmt einige elegantere Varianten die möglich sind.

Das stimmt nicht alles was sich der Kunde wünscht ist immer sinnvoll.
Und die Dokumentation von Siemens dazu lässt auch manche Wünsche offen besonders wenn man die MTU überschreitet bei aktivem ADHOC oder so Scherzen ;)
 
Das stimmt nicht alles was sich der Kunde wünscht ist immer sinnvoll.
Und die Dokumentation von Siemens dazu lässt auch manche Wünsche offen besonders wenn man die MTU überschreitet bei aktivem ADHOC oder so Scherzen ;)
An sich wäre für diese Anwendung eine S7 Verbindung wünschenswert. Wenn der Kunde TCP/IP wünscht, S7 ist nur ein Protokoll welches auf TCP/IP aufsetzt, also auch TCP/IP.

Wenn er allerdings Open User Com vorschreibt kommt vieles zum Tragen.
Ich habe damit vor einiger Zeit herum gespielt bei Kommunikation mit Labview Komponenten.

Wenn das Telegramm eine feste Länge hat und die MTU nicht überschreitet ist es ganz simpel denn jedes Paket enthält dann alle Daten und die kleinste Einheit ist ein Paket. Sprich es kann nichts verloren gehen oder ähnliches.



Wenn man die MTU überschreitet ist die Dokumentation von Siemens sehr dürftig und unterschiedlich ausgebaut je nach Handbuch.

Paket größer als MTU aber mit fixer Länge. In dem Fall muss man sicherstellen dass das die Pakete in der richtigen Reihenfolge ankommen und auch gelesen werden. Z.b. bei einem Fehler muss alles verworfen werden und wieder mit dem ersten Paket begonnen werden.

Paket größer als MTU ihnen feste Länge.
Es wird unter anderem beschrieben das wenn ADHOC verwendet wird im ersten Doppelwort die Telegrammlänge stehen soll. Nur wie nutzt man diese effektiv den die Bausteine von Siemens tun es nicht soweit ich weiß.
Aber das Problem hierbei ist hat man das erste Paket und das erste Doppelwort etc.


Bei meinem Anwendungsfall konnten sich verschiedene Geräte verbinden. Jeder Typ hatte eine andere Länge aber diese war dann konstant. Daher habe ich nur für das Initial Telegramm ADHOC verwendet und ab dem zweiten Aufruf eine feste Länge.
Und wenn ein Problem aufgetreten ist würde die Verbindung resetet und neu aufgebaut da es sich um keine Zeitkritische Kommunikation handelte.

Ein weiteres Problem ist der TCP/IP Server bekommt nicht zwingend mit dass keinen Client mehr vorhanden ist. Solange der Server nicht versucht zu senden über eine Verbindung ohne Client oder er ein Verbindung abgebaut vom Client erhält.
Relativ viel Logik und auch Handling muss bei Open User selbst gestaltet werden.

Aber wie gesagt wie ist der Kundenwunsch. Wenn er Open User vordert na gut. Wenn er nur eine Verbindung auf TCP/IP will kann auch eine S7 Kommunikation genutzt werden.


Gesendet von meinem Redmi Note 5 mit Tapatalk
 
Zuletzt bearbeitet:
Zurück
Oben