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

Ergebnis 1 bis 4 von 4

Thema: Ethernet 8192 Byte, Segmentierung kontrollieren, FB Send, Recv

  1. #1
    Registriert seit
    08.03.2011
    Beiträge
    9
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen.
    Ich stehe zur Zeit vor einem Problem.
    Folgende Situation.
    Ich kommunizieren mit einem PC(Client) mit einer S7-317 (Server).
    Das hat bis jetzt auch gut funktioniert.
    Allerdings habe ich bis jetzt immer maximal 1460 Byte übertragen, so dass ich am PC, wie SPS nur ein Datenpacket erhalten habe.
    Da ich jetzt aber die Kommunikation beschleunigen wollte, und es laut Dokumentation möglich ist 8192 Byte zu verarbeiten, wollte ich dies erweitern.
    --Einschub
    Bevor jetzt jemand frägt, warum das dann schneller sein soll. Meine Erklärung:
    Die Bausteine FB 65, 66 usw. werden zyklisch aufgerufen, und in einer Schrittkette wird Senden und Empfangen durchgearbeitet. Dies dauert halt ein paar SPS Zyklen. Wobei hier die Datenmänge fast egal ist, da die Bausteine assynchron arbeiten.
    Ok so viel dazu.
    --Einschub ende
    Jetzt zu meinem Problem
    Wenn ich von PC aus, sagen wir mal 5000 Byte anfordere, sendet die SPS zu erst 1460 Byte, diese kann ich bei mir im OnRead (ClientSocket) abfragen. Daraufhin bekomme ich ein zweites Empfangsereignis mit den Restlichen 3540 Byte.
    Mit ist schon einmal schleierhaft, wie ich mehr als 1460 Byte übertragen kann. Die MTU von Ethernet liegt doch bei 1518 Byte mit 18 Byte Frame 20 Byte TCP Header und 20 Byte IP Header. Mir ist klar das im Ersten Datenpacket ausgemacht wird auf welche Größe man sich einigt, aber die muss doch auch noch in den Ethernetframe passen???
    Meiner Meinung nach sollte ich eingentlich für alle vielfachen von 1460 Byte ein Ereignis bekommen.
    Ich habe die Verbindung mit einem Sniffertool (Wireshark) angeschaut und hier wurde meine Vermutung bestätigt.
    Es sind immer 1460 Byte Pakete, die dann zu einem 1460 und Rest zusammengesetzt werden müssen.
    Bsp.: 6000Byte senden, 1460Byte + 4540Byte erhalten.

    Das war jetzt lesen aus SPS.
    Nur angenommen ich möchte 5000 Byte in die SPS schreiben, habe ich ein ähnliches Problem.
    Ich sende die Daten mit dem PC raus.
    Dieser macht den gleichen Mist. Erst 1460 Byte in den Empfangspuffer de SPS kopieren und dann mit dem nächsten Empfang die daten im Puffer natürlich überschreiben, ohne das die SPS die Daten umkopieren konnte.

    Und um den Wahnsinn perfekt zu machen, funktioniert es manchmal und manchmal nicht. Soll heißen bis 2000 Byte bekomme ich meist nur ein Empfangsereignis und darüber meistens 2. Und beim schreiben in die SPS funktioniert es bei 20 * 5000 Byte und beim 21 mal gehts wieder in die hose.

    So nach dieser sehr langen Erklärung:
    Gibt es eine Möglichkeit die Segmentierung in dem TCP IP Protokoll zu überwachen zu steuern oder Einfluss daruaf zu nehmen?
    Wie habt ihr das Problem gelöst?
    Kann ich sicher sein, das eine Mindestdatenmänge immer ankommt? Also ich schicke natürlich auch immer mindestens 16 Byte, wiel dies mein indievidueller Header ist, bei dem Zeil DB Länge Datentyp und so weiter drin steht.

    Danke für eure Hilfe
    Zitieren Zitieren Ethernet 8192 Byte, Segmentierung kontrollieren, FB Send, Recv  

  2. #2
    Registriert seit
    29.03.2004
    Beiträge
    5.793
    Danke
    144
    Erhielt 1.706 Danke für 1.238 Beiträge

    Standard

    Ich würde mich mit den TCP Details gar nicht abgeben. TCP ist immer ein Datenstrom, darum musst du bei deinen darin verpackten Daten dafür sorgen dass die Daten aus diesem Strom passend ausgewertet werden können. Auf Windows Seite hat der TCP-Stack auch noch einen internen Datenpuffer. Wenn die Daten schneller reinkommen als du sie in deinem Programm ausliest, können auch mehrere Pakete im Puffer landen. Der Vorteil von TCP ist doch gerade dass man sich mit den Details der Segmentierung nicht abgeben muss, weil es der entsprechende Protokoll-Stack übernimmt.

    Wenn du in deinem Protokoll die Länge der übertragenen Daten in einem Header mitsendest, weiß die Gegenstelle doch eigentlich wie viele Daten noch kommen.
    Man angenommen du möchtest von PC aus 5000 Bytes an die SPS schicken.
    Du schickst ein Telegramm bei dem du der SPS mitteilst dass jetzt 5000 Bytes an Daten kommen.
    Die SPS kopiert solange alle Empfangs-Pakete in einen weiteren Datenpuffer bis die 5000 Bytes vollständig empfangen wurden. Das kann eben auch mehrere Receive-Aufrufe bedeuten. Wenn die 5000 Bytes komplett empfangen wurden, kann es an die Auswertung der Daten gehen.

    Damit man sich auf SPS Seite mit dem ganzen Krams nicht rumärgern muss, kann man auch ein fertiges Protokoll wie Iso-On-TCP bei einer Siemens S7 verwenden. Dort werden die zu übertragenden Daten eben in ein weiteres Paket mit entsprechenden Kopf-Informationen mit den Längenangaben eingepackt.

  3. #3
    Registriert seit
    27.12.2009
    Beiträge
    93
    Danke
    4
    Erhielt 20 Danke für 18 Beiträge

    Standard

    Hallo,

    ich hab schon sehr viel mit TCP übertragen. Bei mir warens aber max 2bis4kByte. Senden mit FBSend zu PC war kein Problem; zu Lean-CP's muß die Länge (bei Rec-Baustein) beachtet werden.
    Beim Empfang mußt Du aufpassen: Entweder Du weißt vorher beim Aufruf von FBRec vieviele Bytes zu empfangen sind (Ich nenne das Hellseher-Methode, ich erklär das weiter unten)
    oder du empfängst mit dem FBRec immer eine bestimmte Anzahl von Bytes (Nicht benötigte kannst Du ja mit "0" auffüllen) -> Auffüll-Methode.

    Nun zur Hellseher Methode.
    Als erstes wird ein kurzes Mitteilungs-Protokoll gesendet (Länge vereinbaren), in diesem wird die tatsächliche Länge des "richtigen" Empfangsstrings mitgeteilt.
    Dann erfolgt der Empfang des Stringgs mit der richtigen Länge.
    Dann kann wieder auf den Empfang des Mitteilungs-Protokoll eingestellt werden.

    Ich habe bisher immer die Auffüll-Methode verwendet. Hier braucht man nichts sychronisieren.

    Ach ja nochwas: Bei der CP343 kann man nur die empfangen Bytes nur sehen, wenn der vereinbarte Empfangspuffer voll ist.
    Bei VIPA-CPU's oder eventuell bei IT-CP's könnte es möglich sein, Teilstrings zu empfangen.
    Ich nutzte diese Möglichkeit jedoch nie, um so viel wie möglich auf die Lean-CP übertragen zu können.

    Ich wünsche Dir weiterhin viel Erfolg!

    S7-Programmer

  4. #4
    Registriert seit
    29.04.2012
    Beiträge
    195
    Danke
    13
    Erhielt 42 Danke für 37 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    So hilfreich Wireshark auch ist, da lässt sich eine Menge falsch interpretieren.
    Gehen wir mal davon aus, dass sich die MTU nich einfach ändern kann - vermute ich du siehst ein Mischung aus:
    http://wiki.wireshark.org/CaptureSetup/Offloading und
    http://de.wikipedia.org/wiki/TCP_segmentation_offload

    Wireshark captures packets before they are sent to the network adapter.

    Mit einer intelligenten Netzwerkkarte kann der Computer die vollen 64 Kilobyte in einem Stück an die Netzwerkkarte übergeben und die Netzwerkkarte ihrerseits teilt das große Paket dann in kleinere Pakete à 1448 Byte auf.

Ähnliche Themen

  1. AG Send, AG Recv
    Von Deep Blue im Forum Simatic
    Antworten: 15
    Letzter Beitrag: 01.05.2015, 16:28
  2. IF 'steigende Flanke' THEN 'send Byte'
    Von sablitos im Forum CODESYS und IEC61131
    Antworten: 11
    Letzter Beitrag: 02.08.2011, 13:54
  3. T_Send/RECV oder PNIO_Send/RECV
    Von Zizou im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 12.12.2008, 16:18
  4. Ethernet:Welcher Baustein-Send-Recive ?
    Von Outrider im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 10.09.2008, 21:50
  5. Kommunikation S7<--> PC über Ethernet mit Send/Receive
    Von MW im Forum Hochsprachen - OPC
    Antworten: 34
    Letzter Beitrag: 13.07.2007, 23:21

Stichworte

Lesezeichen

Berechtigungen

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