Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 9 von 9

Thema: Verwendung TCP/IP native oder ISOonTCP?

  1. #1
    Matze2 Gast

    Standard Verwendung TCP/IP native oder ISOonTCP?


    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

  2. #2
    centipede ist offline Erfahrener Benutzer
    Registriert seit
    30.04.2005
    Beiträge
    670
    Danke
    28
    Erhielt 109 Danke für 101 Beiträge

    Standard

    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

  3. #3
    Avatar von Maxl
    Maxl ist offline Erfahrener Benutzer
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    95
    Erhielt 175 Danke für 132 Beiträge

    Standard

    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

  4. #4
    bimota ist offline Benutzer
    Registriert seit
    12.04.2005
    Beiträge
    27
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

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

  5. #5
    Anonymous Gast

    Standard kleine Ergänzung

    Zitat Zitat von bimota
    ..., 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

  6. #6
    bimota ist offline Benutzer
    Registriert seit
    12.04.2005
    Beiträge
    27
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard Re: kleine Ergänzung

    Zitat Zitat von Gast
    Zitat Zitat von bimota
    ..., 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.

  7. #7
    yetibrain Gast

    Standard 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

  8. #8
    Avatar von Rainer Hönle
    Rainer Hönle ist offline Erfahrener Benutzer
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.043
    Danke
    564
    Erhielt 876 Danke für 703 Beiträge

    Standard

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

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  9. #9
    bimota ist offline Benutzer
    Registriert seit
    12.04.2005
    Beiträge
    27
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

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

    Zitat Zitat von yetibrain
    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).

Ähnliche Themen

  1. Verwendung von NPN oder PNP Sensoren?
    Von olitheis im Forum VDE - IEC - DIN
    Antworten: 1
    Letzter Beitrag: 26.01.2011, 12:47
  2. Antworten: 6
    Letzter Beitrag: 19.07.2010, 11:05
  3. das native 1200 Protokoll?
    Von LowLevelMahn im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 16.06.2010, 17:44
  4. Kommunikation ISOonTCP (RFC1006)
    Von Gaudi im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 24.03.2007, 16:06
  5. ShowIt® - Die GLT mit native BACnet-Anbindung
    Von Anonymous im Forum Werbung und Produktneuheiten
    Antworten: 0
    Letzter Beitrag: 10.03.2004, 11:16

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •