TIA Mit TURCV UDP Nachrichten empfangen die länger sind als 2048 Byte?

BenWolf

Level-1
Beiträge
36
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich bekomme UDP-Nachrichten zugesendet die aus mehreren Fragmenten bestehen (In meinem Fall 2). Zusammen bilden diese Fragmente eine Datenlänge von 2085 Byte's (1472 + 613).
Wenn ich im Baustein LEN auf 0 lasse (So ist es empfohlen) dann bekomme ich den Error 8085 -> [Parameter LEN ist größer als der größte zulässige Wert, oder Sie haben einen der Parameter LEN oder DATA gegenüber dem Erstaufruf geändert] <- Es wird also scheinbar die Gesamtlänge betrachtet.
Wenn ich LEN auf zB 2048 stelle bekomme ich den Error 80C9 -> [Bei RFC1006 / UDP: Die empfangenen Daten sind länger als erwartet (Größe des Empfangspuffers überschritten).] <-
Kann ich die Fragmente ggf auch Einzeln empfangen, oder den Empfangspuffer vergrößern?
Die Daten die gesendet werden kann ich leider nicht beeinflussen.

MfG Ben
 
DONE ist nur einen Zyklus lang TRUE. Häng mal ein CTU dran.

DONE wird wirklich nicht TRUE^^
Ich bekomme nur eine Fehlermeldung 80C9 (Die kommt ja auch nur zyklisch)

Das Problem scheint: Die UDP-Nachricht ist länger als 2048 Byte. Sie besteht allerdings aus 2 Fragmenten, die beide kleiner sind. Ich dachte es gibt vllt eine Möglichkeit die Fragmente einzeln auszulesen, oder ggf eine ganz andere Möglichkeit.

Hast du dir denn schon mal Nachrichten gesendet die länger waren als die 2048 Byte? Wenn das grundsätzlich gehen würde (egal wie) dann mache ich ja vllt woanders einen Fehler
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aus der Hilfe:
Empfang von mehr als 1472 Bytes
Ab Firmware-Stand V2.5 der S7-1500-CPUs können Sie bei Datenübertragung über UDP nicht mehr bis zu 1472 Bytes, sondern bis zu 2048 Bytes empfangen.
Falls Ihre empfangende Baugruppe allerdings max. 1472 Bytes unterstützt und Ihre sendende Baugruppe mehr als 1472 Bytes überträgt, liefert TURCV im Parameter STATUS den Wert W#16#8085 oder W#16#80C9.

Vielleicht hilft hier ein FW-Update...
 
Du kannst z.B. LEN = 100 machen und mit dem DONE den Index eines Arrays weiterschalten.
Ich bekomme ja gar kein DONE.
Hast Du das denn mal ausprobiert?

Dem TURCV sagt man nicht wie lang die Nachricht ist, sondern wieviele Bytes man aus dem Empfangspuffer abholen will (was im Idealfall die Länge der Nachricht ist, aber nicht so sein muß). Und immer wenn mindestens so viele Bytes empfangen wurden liefert TURCV diese Anzahl Bytes. Die weiteren Bytes der Nachricht (und ggf. der nächsten Nachricht) holt man mit weiteren Aufrufen von TURCV ab. Um alle 2085 Bytes der Nachricht aus dem Empfangspuffer abzuholen, könntest Du 3 * je 695 Bytes abholen und in einem Byte-Array wieder zu 2085 Bytes zusammensetzen. PS: wenn Deine Schnittstelle generell fähig ist, Nachrichten mit 2085 Bytes Länge zu empfangen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn ich

Empfang von mehr als 1472 Bytes
Ab Firmware-Stand V2.5 der S7-1500-CPUs können Sie bei Datenübertragung über UDP nicht mehr bis zu 1472 Bytes, sondern bis zu 2048 Bytes empfangen.
Falls Ihre empfangende Baugruppe allerdings max. 1472 Bytes unterstützt und Ihre sendende Baugruppe mehr als 1472 Bytes überträgt, liefert TURCV im Parameter STATUS den Wert W#16#8085 oder W#16#80C9.

richtig verstehe, gehen doch nur 2048 bytes
 
Was meinst Du eigentlich mit "Fragmente"? Sind es in Wahrheit 2 Nachrichten (Pakete)? Dann muß Deine PN-Schnittstelle auch keine UDP-Nachrichten > 2048 Byte können. Welche CPU hast Du eigentlich?

Warum wird bei Deiner Anwendung UDP verwendet? Bei UDP gibt es keine Garantie, daß ein einmal gesendetes Paket auch ankommt, daß Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder daß ein Paket nur einmal beim Empfänger ankommt. Deine Anwendung muß mit allen Problem-Fällen klarkommen. Deine Anwendung muß erkennen können, zu welchem "Fragment" die abgeholte Bytefolge gehört. Sind in den Nachrichten Header- und Steuerbytes und evtl. Nachrichtennummern enthalten, anhand denen Dein Programm die korrekte Position der abgeholten Bytefolgen in den ursprünglichen Fragmenten und ggf. die Zugehörigkeit zum selben Nachrichtenpaar erkennen kann?

Ich schätze, Du müßtest zunächst 613 Byte mit TURCV aus dem Empfangspuffer abholen, dann anhand des Inhalts der 613 Bytes feststellen, ob die von dem 613-Byte-Fragment oder von dem 1472-Byte-Fragment stammen, und bei letzterem noch die restlichen 859 Bytes des 1472-Byte-Fragments abholen. Danach wieder 613 Bytes abholen usw. usf. ...

Harald
 
Was meinst Du eigentlich mit "Fragmente"? Sind es in Wahrheit 2 Nachrichten (Pakete)? Dann muß Deine PN-Schnittstelle auch keine UDP-Nachrichten > 2048 Byte können. Welche CPU hast Du eigentlich?

Warum wird bei Deiner Anwendung UDP verwendet? Bei UDP gibt es keine Garantie, daß ein einmal gesendetes Paket auch ankommt, daß Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder daß ein Paket nur einmal beim Empfänger ankommt. Deine Anwendung muß mit allen Problem-Fällen klarkommen. Deine Anwendung muß erkennen können, zu welchem "Fragment" die abgeholte Bytefolge gehört. Sind in den Nachrichten Header- und Steuerbytes und evtl. Nachrichtennummern enthalten, anhand denen Dein Programm die korrekte Position der abgeholten Bytefolgen in den ursprünglichen Fragmenten und ggf. die Zugehörigkeit zum selben Nachrichtenpaar erkennen kann?

Ich schätze, Du müßtest zunächst 613 Byte mit TURCV aus dem Empfangspuffer abholen, dann anhand des Inhalts der 613 Bytes feststellen, ob die von dem 613-Byte-Fragment oder von dem 1472-Byte-Fragment stammen, und bei letzterem noch die restlichen 859 Bytes des 1472-Byte-Fragments abholen. Danach wieder 613 Bytes abholen usw. usf. ...

Harald

Der Ethernet 2 Frame kann maximal, mit Header, 1518 Byte groß sein. Im Internet Protokoll IPv4 kann ich die enthaltenen Daten in Fragmente teilen um die Nachricht geteilt abzusenden. Die einzelnen Fragmente werden dann aber, scheinbar, automatisch zusammengesetzt.

In der Vermittlungsschicht, nach dem ISO-Modell, werden ja erst Fragmente erzeugt. Diese müssen dort auch wieder zusammengefasst werden bevor Sie an die Transportschicht übergehen.
In der Transportschicht haben wir dann ja nur noch eine Nachricht die entschlüsselt wird.

UDP macht in der Anwendung schon Sinn. Die Daten werden im Echtzeittakt übertragen.

Wie gesagt: Die Nachricht wird schon vorher wieder zusammengesetzt und der TURCV Baustein kann diese Nachricht nicht in den internen Puffer speichern, weil Sie zu groß ist. Ich habe zu keinem Zeitpunkt die Möglichkeit die Daten rauszuspeichern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was soll den jetzt der Schwachsinn!

Es wird also nur ein Telegramm mit gesammter Länge gesendet, oder?
Wie das übers Kabel kommt ist irrelevant!
Der Empfäner baut das selbständig zu einem vollständigen Telegramm zusammen. Ist das zu lang, GEHT DAS NICHT...
 
Zurück
Oben