Verwendung TCP/IP native oder ISOonTCP?

[Matze2]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

wer kennt sich mit TCP-Verbindungen in der S7-Welt aus. Was ist der Unterschied zwischen TCP/IP native und ISOonTCP(RFC1006). Wann
setzt man welche Verbindung am besten ein.
Meine Anwendung: es soll ein erhöhter Telegrammverkehr zwischen SPS und MFR(PC) über Ethernet stattfinden, um eine Materialverfolgung zu realisieren (Telegrammlänge konstant 240 Byte). Welche Vor- und Nachteile haben die jeweiligen Verbindungen.

Wer hat da Erfahrungswerte bzw. kennt weiterführende Literatur?

Danke

 

[centipede]

Hallo,

ISOonTCP nimmt man eigentlich nur noch her, wenn auch noch alte S5en im Netz sind. Die können kein "echtes" TCP/IP.
Wenn du nur S7 oder ähnliches sowie Rechner im Netz hast verwende normales TCP/IP.
Der Unterschied ist, dass sich im RFC1006 ein ISO Telegramm als Nutzdaten verpackt in einem TCP/IP Frame befindet. Es besitz ansonsten die gleichen Eigenschaften wie TCP/IP, ist also ebenso Routingfähig und basiert auf IP Adressen.
Es ist auch noch fraglich wie lange RFC1006 noch unterstützt wird.
Ich hoffe ich konnte etwas helfen.

Gruß Tom

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Empfehlung von Siemens ist:

- Kommunikation zwischen S7 und S5 --> ISO Transportverbindung
- Kommunikation zwischen S7 und S7 --> ISOonTCP
- Kommunikation zwischen S7 und PC --> ISOonTCP

Grundsätzlich erzeugen ISO-Transport und ISOonTCP keinen so hohen Datenverkehr im Ethernet, da es keine Broadcasts usw. gibt.

Ich habe letztes Jahr mal die beiden Protokolle auf Geschwindigkeit getestet.
Testbaufbau: 2 S7-317 mit CP343-1, Kommunikation über normles Firmennetzwerk (100MBit, Full-Duplex), Paketgröße 180 Byte

Paketlaufzeit bei ISO-Transport zwischen 15 und 20 ms
Paketlaufzeit bei TCP/IP zwischen 80 und 100 ms

 

[bimota]

Wenn die Datenübertragung im Pollingverfahren z.B. mit dem Fetch/Write-Protokoll erfolgen soll, dann kann eine reine TCP-Verbindung verwendet werden, da das FW-Telegramm die Paketintegrität gewährleistet.

Wenn die Datenübertragung über die SEND/RECEIVE-Schnittstelle (SPS sendet aktiv die Daten mit dem Baustein AG_SEND) erfolgen soll, dann ist es wesentlich besser RFC1006 oder UDP als Transportprotokoll zu verwenden, da TCP streamorientiert* ist und die gesendeten Daten nicht als ein Paket liefert. RFC1006 oder UDP dagegen liefern jeden Datenblock der mit einem AG_SEND-Aufruf von der SPS gesendet wurde als einen Datenblock beim Lesen auf dem PC.

*TCP ist streamorientiert, d.h. ein Datenstrom ohne definierten Anfang und Ende; ein Leseaufruf auf dem PC liefert immer nur soviele Daten, wie gerade im Empfangspuffer sind (u.U. weniger oder mehr als ein Datenblock, der von der SPS gesendet wurde).

 

[Anonymous]

kleine Ergänzung

..., dann ist es wesentlich besser RFC1006 oder UDP als Transportprotokoll zu verwenden, da TCP streamorientiert* ist und die gesendeten Daten nicht als ein Paket liefert. RFC1006 oder UDP dagegen liefern jeden Datenblock der mit einem AG_SEND-Aufruf von der SPS gesendet wurde als einen Datenblock beim Lesen auf dem PC.

*TCP ist streamorientiert, d.h. ein Datenstrom ohne definierten Anfang und Ende; ein Leseaufruf auf dem PC liefert immer nur soviele Daten, wie gerade im Empfangspuffer sind (u.U. weniger oder mehr als ein Datenblock, der von der SPS gesendet wurde).

Ich bin kein SPS-Spezialist, komme aber aus dem Netzwerk-Bereich. Ein kleiner Einwurf sei mir erlaubt:

Bimota hat Recht, was das Framing (also den Erhalt der Telegrammgrenzen) angeht: UDP transportiert Telegramme, TCP einen Datenstrom.

Der wesentliche andere Unterschied zwischen UDP und TCP ist aber, dass UDP eine unsichere Verbindung darstellt. Telegramme können verlorengehen, und sie können in der falschen Reihenfolge beim Empfänger ankommen. Das könnte geschehen, wenn sie zwischendurch geroutet werden und sich etwa das Routing ändert. Wenn Sender und Empfänger im gleichen Netzwerksegment stehen, ist das eher unwahrscheinlich. Dennoch sollte man diese Risiken bedenken. Wenn man ihnen begegnen will, muss man wieder Sequenznummern o.ä. einführen, die TCP schon selber mitbringt.

Gruß
Stefan

 

[bimota]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: kleine Ergänzung

..., dann ist es wesentlich besser RFC1006 oder UDP als Transportprotokoll zu verwenden, da TCP streamorientiert* ist und die gesendeten Daten nicht als ein Paket liefert. RFC1006 oder UDP dagegen liefern jeden Datenblock der mit einem AG_SEND-Aufruf von der SPS gesendet wurde als einen Datenblock beim Lesen auf dem PC.

*TCP ist streamorientiert, d.h. ein Datenstrom ohne definierten Anfang und Ende; ein Leseaufruf auf dem PC liefert immer nur soviele Daten, wie gerade im Empfangspuffer sind (u.U. weniger oder mehr als ein Datenblock, der von der SPS gesendet wurde).

Ich bin kein SPS-Spezialist, komme aber aus dem Netzwerk-Bereich. Ein kleiner Einwurf sei mir erlaubt:


Bimota hat Recht, was das Framing (also den Erhalt der Telegrammgrenzen) angeht: UDP transportiert Telegramme, TCP einen Datenstrom.

Der wesentliche andere Unterschied zwischen UDP und TCP ist aber, dass UDP eine unsichere Verbindung darstellt. Telegramme können verlorengehen, und sie können in der falschen Reihenfolge beim Empfänger ankommen. Das könnte geschehen, wenn sie zwischendurch geroutet werden und sich etwa das Routing ändert. Wenn Sender und Empfänger im gleichen Netzwerksegment stehen, ist das eher unwahrscheinlich. Dennoch sollte man diese Risiken bedenken. Wenn man ihnen begegnen will, muss man wieder Sequenznummern o.ä. einführen, die TCP schon selber mitbringt.

Gruß
Stefan

Danke.
Der sichere Weg ist ISO-On-TCP (RFC1006) zu verwenden, hier ist die Fehlerkorrektur von TCP mit der Paketierung des RFC1006 kombiniert.
RFC1006 ist jedoch PC-seitig etwas aufwendiger zu implementieren als UDP, das schon im WIN-API oder in Linux vorhanden mit drin ist.

Die beste Lösung wäre:
Daten von der Steuerung zum PC per UDP (mit eingebauten Sequenznummern) zu senden. Das Paket gleichzeitig auf der SPS in einem Ringpuffer (der der PC-Anwendung bekannt ist) speichern.

Die PC-Anwendung erkennt dann fehlende Pakete anhand diese Sequenznummern und holt sich diese per aktivem Polling (z.B. Fetch-Aufruf über eine TCP-Fetch-Verbindung) aus dem Ringpuffer.

 

[yetibrain]

mit Winsock per TCP/IP auf eine CP connecten

Hallo Forum,

kann man sich denn per TCP/IP auf eine CP connecten? Wenn das geht, was muss man dann für Befehle abschicken um eine Antwort zu erhalten bzw. was für ein Protokoll versteht die CP? Ich möchte z. B. wissen was für Bausteine, Eingänge und Ausgänge in einer SPS sind. Habe gehört daß Siemens das Protokoll nicht offenlegt. Stimmt das? Danke für jeden Tipp.

yetibrain

 

[Rainer Hönle]

Neben verschiedenen gewerblichen Lösungen (unter anderem natürlich auch von uns :wink gibt es eine Open Source Lösung von Zottel. Siehe hierzu unter:
http://www.sps-forum.de/phpBB2/viewtopic.php?t=5669

 

[bimota]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: mit Winsock per TCP/IP auf eine CP connecten

Hallo Forum,

kann man sich denn per TCP/IP auf eine CP connecten? Wenn das geht, was muss man dann für Befehle abschicken um eine Antwort zu erhalten bzw. was für ein Protokoll versteht die CP? Ich möchte z. B. wissen was für Bausteine, Eingänge und Ausgänge in einer SPS sind. Habe gehört daß Siemens das Protokoll nicht offenlegt. Stimmt das? Danke für jeden Tipp.

yetibrain

Hallo,
wenn der CP (z.B. Cp-343, 443) TCP kann (steht in den Eigenschaftenseiten im Simatic-Manager zum entsprechenden CP), dann ist das kein Problem.

Es gibt aber verschiedene Wege zum Ziel:

1. S7-Verbindung (S7-Funktionen) zum Pollen der Daten aus DB's und anderen Operanden -> nicht offengelegt, deshalb am besten eine Bibliothek verwenden, wie sie hier im Forum öfter mal im Gespräch sind
Auf der S7 muss dabei nichts projektiert werden. Über diese Verbindung können nicht nur Daten gelesen und geschrieben werden, sondern auch Systemdaten und Programme.

2. Fetch/Write zum Pollen der Daten aus DB's und anderen Operanden -> Dokumentation des Protokolls steht im Anhang der Dokumentation des verwendeten Ethernet-CP.
Dazu muss auf der S7 im NetPro-Fenster je eine Fetch und eine Write-Verbindung als TCP-Verbindung projektiert werden.
Dieses Protokoll lässt sich einfach selbst implementieren.

3. Verwendung der SEND/RECEIVE-Schnittstelle wahlweise mit RFC1006-Protokoll (bei Siemens ISO-On-TCP) oder mit UDP.
Hierbei muss die SPS jedoch die Daten aktiv per AG_SEND/AG_LSEND-Aufruf senden. Hat aber den Vorteil, dass das Polling entfällt und dadurch weinger redundante Daten das Netzwerk fluten.
Dazu muss ebenfalls eine Verbindung im NetPro projektiert werden (UDP oder RFC1006).