TIA Open User Communication / UDP / Empfangsbuffer

fabianfischer

Level-1
Beiträge
54
Reaktionspunkte
38
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

weiß jemand wie sich eine programmierte UDP Open User Communication verhält, wenn mehrere vollständige UDP Telegramme parallel zu einem Zyklus hintereinander an der integrierten PN Schnittstelle einer SIMATIC 1500 (FW 2.5 / TIA V15) eintreffen?

Vorweg, dass TRCV_C bzw. TRCV asynchron arbeiten, sowie der generelle Umgang mit den Funktionen, ist bekannt.

Steht dann im folgenden Programm Zyklus die Nutzdaten des ersten oder letzten empfangenen Telegramms im deklarierten Datenbereich zur Verfügung?

Was passiert mit den übrigen Telegrammen, werden diese verworfen oder in einem internen FIFO Buffer gehalten und mit jedem neuen Zyklus die Nutzdaten eines Telegramms in den deklarierten Datenbereich geschrieben bis der FIFO abgearbeitet ist?

Wenn es so ein Buffer existiert, wie groß ist er, was passiert, wenn er überläuft?

Oder werden alternativ die Nutzdaten aus mehreren vollständig empfangenen Telegrammen an einander gefügt und in den Datenbereich beim folgenden Zyklus geschrieben, vorausgesetzt der Datenbereich ist groß genug deklariert?

Hintergrund meiner Fragen ist, dass ich momentan eruiere ob es technisch möglich ist mit einer SIMATIC in einer Multicast Gruppe kleine (20 Byte), jedoch viele und schnell aufeinander folgende Telegramme zu empfangen und zu verarbeiten.

Im OUC- und SIMATIC-Systemhandbuch habe ich leider keine Antwort auf meine Fragen erhalten,
Auf die reale Hardware zwecks Erprobung kann ich erst wieder in 14 Tagen zugreifen.

Danke im Voraus.
 
Zuletzt bearbeitet:
TRCV ist doch für TCP-Kommunikation. D.h. es wird eine Verbindung aufgebaut und gehalten bis sie abgebaut wird. Weiter wird jedes Paket vom Empfänger an den Sender bestätigt.
Beim Aufbauen wird bei Aufruf von TCon eine ID angegeben, auf die sich die gesamte weitere Kommunikation (TRCV, TSEND) bezieht. Damit ist eine eindeutige Zuordnung gewährleistet.
Ich vermute mal, daß es bei UDP genauso läuft, denn wenn ich die Hilfe richtig verstehe, muß ja auch da die Verbindung entweder projektiert oder zur Laufzeit mit TCon aufgebaut werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TCON, TRCV, TURCV und Co. sind schon seit V14 legacy.

TRCV_C beinhaltet alle erwähnten Funktionen und ist für UDP sowie TCP einzusetzen. Die Spezifizierung der Verbindungsart z.B. UDP erfolgt über den Parameter CONNECT.

Wie eine UDP oder TCP Verbindung aufgebaut und im User Programm Verwendung findet ist mir klar.

Meine Frage bezieht sich auf den internen Ethernet Buffer der 1500er und vor allem, wie er organisiert ist und mit vielen schnellen UDP Paketen umgeht.
 
Habe bisher nur TCP usw. verwendet, auch die LCom-Bibliothek von Siemens verwendet sie. Aber ok.
Ich weiß nicht so recht, wonach Du eigentlich fragst. Die Verbindungen werden über die ID unterschieden, Du bekommst immer nur die Pakete für die ID eingelesen, für die Du TRcv aufrufst. Da wird nichts vermischt. Gut, ich habe mit UDP noch nichts gemacht aber bei TCP ist es so. Ich habe eine Anlage mit einer 1515, da laufen 8 TCP-Verbindungen gleichzeitig (jeweils Pakete bis zu 3000 byte). Das funktioniert problemlos.
Die Erfahrung zeigt aber auch, daß die Übertragung zwar schneller wird, wenn ich nur ein TCP-Paket (< ca. 1400 Byte) übertrage, mit kleineren Paketen wird aber nichts mehr schneller.
Die Übertragungszeiten innerhalb der CPU hängen also wohl hauptsächlich von anderen Dingen ab, als der Datengröße.
Deshalb schätze ich, daß Du ca. 10 Übertragungen je Partner und Sekunde schaffen wirst. Mehr geht nur über integrierte Mechanismen a la Profinet.
 
Wie du richtig schreibst wird eine TCP aufgebaut und gehalten und demensprechend kann die Problematik, welche ich bezüglich der UDP Kommunikation habe nicht auftreten, da die Daten koordiniert in einem Stream an das User Programm übergeben werden.

UDP Kommunikation ist hingegen verbindungslos und es können nur einzelnen Telegramme an das User Programm übergeben werden.

Konkret möchte ich wissen, was die CPU tut, wenn z.B. innerhalb einer Millisekunde 2 UDP Telegramme an sie gerichtet werden, während der Programmzyklus im 10 MS Takt läuft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für TRCV_C kann ich nichts klares finden, wie mehrere "Verbindungen" bei UDP gehandelt werden. Bei TURCV sollte das über die Verbindungs-ID funktionieren. Also mit jeder ID aufrufen und dann hat man alles was bis dahin für diese ID eingetrudelt ist.
Erfordert aber sicher entweder ein projektierte Verbindungen oder die Herstellung der Verbindung mit TCON.
 
. . . und dann hat man alles was bis dahin für diese ID eingetrudelt ist.
. . . und der TE möchte wissen, WO man alles hat und WIE die Ablage der empfangenen Daten "organisiert" ist, damit er den Inhalt des EmpfangsPuffers auswerten kann, glaube ich.
Er will die Daten 1-mal je Zyklus (10 ms) auswerten und rechnet damit, dass während dieser 10 ms ca. 20 Telegramme den EmpfangsPuffer zugeschüttet haben.
 
Zuletzt bearbeitet:
Ich habe keine Erfahrung mit S7-1500, ich meine aber, daß da ein interner Empfangspuffer ist, aus dem TRCV immer die angeforderte Menge Bytes holt. Sind noch nicht genug Bytes empfangen, dann wird TRCV nichts liefern. Sobald mindestens die angeforderte Anzahl Bytes in dem Empfangspuffer liegen dann wird TRCV diese Bytes abholen/liefern und NDR melden. Wenn man nun damit rechnet, daß zwischen den TRCV-Aufrufen mehr Bytes empfangen worden sein könnten als man mit einem Auftrag abholt, dann kann man bestimmt den TRCV direkt gleich nochmal aufrufen um weitere Bytes zu holen.

PS: Irgendwie war da noch eine Spezialität wenn man TRCV mit LEN=0 aufruft. Das mal bitte in der TIA-Hilfe nachlesen.

Harald
 
Mit LEN=0 wird für die jeweilige ID abgeholt, was im Puffer ist und in den Zielbereich paßt, das können auch mehrere Nachrichten sein, das können (leider) nach meiner Erfahrung (300er) auch einige ganze und ein Bruchstück sein, das nächste Bruchstück kommt dann beim nächsten Mal.
Die Puffergröße schien bei meinen Versuchen äquvalent zur Datengröße bei Put/Get zu sein, also bei 300er CP 64Byte, bei den 300er PN-CPU 160Byte. Bei den 1500er ist der Bereich um etliches größer, irgendwo hatte ich was gefunden.
Nach meinen Erfahrungen scheinen diese Puffer je Verbindung zur Verfügung zu stehen.
Achja hier in der Hilfe USEND/URCV: SFB8/9 160Byte, FB8/9 440Byte aufgeteilt in 4*100Byte. (was immer letzteres praktisch bedeuten mag)
10ms Zykluszeit bedeuten erfahrungsgemäß NICHT, daß Du alle 10ms den Empfangspuffer auslesen kannst. Bedingt durch die Asynchronität wirst Du nur alle 2-3 Zyklen neue Daten signalisiert bekommen.
Für 10 Verbindungen die Empfangspuffer auslesen wird aber vermutlich die Zykluszeit auch auf deutlich über 10ms in Richtung 20ms treiben.

Also nochmal zusammengefasst:
Die Daten werden nach ID sortiert gehandelt und vom Anwenderprogramm ausgelesen
Die CPU packt alle ankommenden Pakete nacheinander in den internen Puffer (je ID)
Man kann alle in einem Moment pro ID zur Verfügung stehenden Daten im Block abholen
Was nicht in den internen Puffer paßt wird verworfen (irgendwo gab es auch eine Einstellung die auf Überschreiben umstellt (?))

Ich vermute, daß Dein Vorhaben aufgrund der Puffergröße nicht funktioniert. Es werden viele Pakete verloren gehen.
 
Ich habe heute folgendes Feedback von Siemens erhalten, was ich euch nich vorenthalten möchte.

Die 1500er verfügt, wie schon angenommen über einen Telegram Buffer, welcher als FIFO organisiert ist. Dem entsprechend werden mehrere Pakete die in schneller Folge eintreffen, in der Empfangs-Reihenfolge gespeichert. Mit einem der nächsten User Programm Zyklen (OUC läuft bekanntermaßen asynchron), wird immer das erste eingetroffene Telegramm per TRCV_C in den deklarierten Empfangs-Datenbereich geschrieben. In den deklarierten Empfangsbereich werden immer nur Nutzdaten aus einem Telegramm geschrieben.

Die Größe des Buffers lässt sich nicht deklarieren, da er, als eine geteilte Ressource, für die anderen Kommunikationsverbindung wie z.B. PROFINET ebenfalls genutzt wird. Wenn der Buffer voll läuft werden keine neuen Telegramme angenommen.

Dementsprechend ist mein Vorhaben realisierbar, viele schnelle, auf einander folgende Pakete zu empfangen und zu verarbeiten. Es muss nur darauf geachtet werden, dass es zwischendurch auch entsprechend lange Paket Pausen gibt um den Buffer abzuarbeiten, was bei der angedachten Aufgabe jedoch gegeben ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
. . . Dem entsprechend werden mehrere Pakete die in schneller Folge eintreffen, in der Empfangs-Reihenfolge gespeichert. Mit einem der nächsten User Programm Zyklen . . . , wird immer das erste eingetroffene Telegramm per TRCV_C in den deklarierten Empfangs-Datenbereich geschrieben. . . .
Ja, wenn das so ist, dann muss man doch hoffen, dass nach jedem empfangenen Telegramm keine weiteren Telegramme entgegengenommen werden (weil Buffer wegen Überfüllung vorübergehend geschlossen) bis nach knapp 10 ms der nächste, langerwartete TRCV_C-Aufruf ein wenig Erleichterung schafft. :ROFLMAO:

Für mich liest sich das leider so, dass mindestens 40 TRCV_C-Aufrufe pro 10-ms-Zyklus erfolgen müssen, wenn bis zu 20 Telegramme pro 10 ms auflaufen können und lückenlos entgegengenommen werden sollen.
Da kann man nur hoffen, dass mit "TelegrammLänge 0" tatsächlich mehrere Telegramme je Abfrage abgeholt werden können!
 
Da kann man nur hoffen, dass mit "TelegrammLänge 0" tatsächlich mehrere Telegramme je Abfrage abgeholt werden können!

Der Parameter LEN = 0 hat nichts mit der Anzahl oder der Summe der Nutzdaten über mehrere empfangene Telegramme zu tun.

Den Parameter LEN setzt man auf 0, wenn man als Empfangsdatenbereich einen optimierten Datenbereich verwendet. LEN ist dann intern maximal so groß wie der optimierte Datenbereich. In der Regel muss man aber mit Fremdsystemen über Frames mit festen Byte Positionen kommunizieren, dass schließt sich mit optimierten Datenbausteinen aus.

Egal ob LEN = 0, bei optimierten Datenbereichen oder = 25 für einen definierten Byte Frame, im Datenbereich werden immer nur die Nutzdaten aus einem Telegramm hinterlegt.

Etwas anderes macht auch keinen Sinn, da TRCV_C nach der erfolgreichen Übergabe (NDR = true) der Nutzdaten an den deklarierten Datenbereich auch über ADDR die Remote Adressdaten bereitstellt, denn nicht immer ist der Remote Partner fest spezifiziert.

Bei meiner Multicast Applikation treffen ja nicht kontinuierlich je Millisekunde 2 Pakete ein, dem entsprechend habe ich da kein Buffer Problem.

Des Weiteren ist die 1500er bezüglich OUC extrem performant da die Kommunikation nicht den eigentlichen Zyklus beeinflusst, dementsprechend ist bei reiner OUC Kommunikation mit z.B. einer 1516 selbst bei einer mittleren zweistelligen Verbindungsanzahl eine Zykluszeit weit unter 10 ms realisierbar.
 
Das Abholen der Daten findet im Zyklus statt und beeinflusst dadurch die Zykluszeit. Und wie Heinileini geschrieben, ob 40 TRCV_C Aufrufe pro Zyklus nicht die Zykluszeit nach oben treiben.
Wie geschrieben verwende ich LCom von Siemens (intern TCon, TSend, TRCV) da steigt die Zykluszeit deutlich an, ca. 1-2 ms je Verbindung und es werden max. 2 Telegramme im Zyklus übertragen.
Aber teste es und berichte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
[...] wird immer das erste eingetroffene Telegramm per TRCV_C in den deklarierten Empfangs-Datenbereich geschrieben. In den deklarierten Empfangsbereich werden immer nur Nutzdaten aus einem Telegramm geschrieben.
Wie bereits geschrieben habe ich mit der S7-1500 und UDP keine Erfahrung, doch diese Aussage scheint mir falsch zu sein. Bei TCP holt TRCV nicht Telegramme aus dem Puffer sondern eine angegeben Anzahl Bytes. Die können auch aus mehreren Telegrammen stammen (besonders wenn die angegebene Abhol-Größe nicht der Telegrammgröße entspricht). Ich glaube, auch bei UDP musst Du nicht mit 20 Aufrufen je 20 Byte abholen - Du kannst auch in einem Aufruf 400 Bytes abholen - die stammen dann aus 20 Telegrammen. Das macht man allerdings normalerweise nicht, weil TRCV erst dann Daten liefert, wenn mindestens die angegebene Menge Daten empfangen wurde - hier also erst mindestens 20 Telegramme empfangen wurden.
Sollte TRCV tatsächlich bei UDP nur einzelne kommplette Telegramme liefern, dann kannst Du TRCV sicher auch im selben Zyklus gleich mehrmals nacheinander aufrufen und so mehrere Telegramme in einem Zyklus abholen.

Eventuell gibt es eine Möglichkeit abzufragen wieviele Bytes im Empfangspuffer der Verbindung vorhanden sind, ich kenne die aber nicht.

Harald
 
Wie bereits geschrieben habe ich mit der S7-1500 und UDP keine Erfahrung, doch diese Aussage scheint mir falsch zu sein. Bei TCP holt TRCV nicht Telegramme aus dem Puffer sondern eine angegeben Anzahl Bytes. Die können auch aus mehreren Telegrammen stammen (besonders wenn die angegebene Abhol-Größe nicht der Telegrammgröße entspricht). Ich glaube, auch bei UDP musst Du nicht mit 20 Aufrufen je 20 Byte abholen - Du kannst auch in einem Aufruf 400 Bytes abholen - die stammen dann aus 20 Telegrammen. Das macht man allerdings normalerweise nicht, weil TRCV erst dann Daten liefert, wenn mindestens die angegebene Menge Daten empfangen wurde - hier also erst mindestens 20 Telegramme empfangen wurden.

Meine Aussage ist zu einhundert Prozent korrekt!

Ich möchte das hier aber nicht einfach stehen lassen, da es vielleicht noch andere Leser gibt, die an der Funktionsweise interessiert sind.

Folgendes Beispiel.

Mit zwei Paket Sender Instanzen werden zwei unterschiedliche UDP Pakete (Inhalt und Länge) im Intervall von 100 ms an den Port 2000 einer 1516 gesendet.

Den freilaufenden Zyklus der CPU habe ich mit mehreren WAITs künstlich auf ca. 160 ms verzögert, um mehrere Pakete in der Totzeit zu empfangen.

PaketSender1.PNG
PaketSender2.PNG

Der Empfangsbaustein TRCV_C ist folgender maßen parametriert.

TRCV_C.jpg

Wie zu erkennen ist, habe ich den Parameter LEN auf 10 deklariert, dass bedeutet aus einem empfangenen UDP Paket werden immer nur die ersten 10 Bytes Nutzdaten in DATA geschrieben. Die tatsächliche Anzahl der Nutzdaten kann jedoch deutlich größer sein. Pakete mit Nutzdaten größer 10 Bytes werden natürlich auch empfangen, jedoch werden nur Nutzdaten bis zum 9 Byte an DATA übergeben. Wichtig an dieser Stelle ist auch noch einmal zu erwähnen, dass die Nutzdaten bereits ein Extrakt aus dem UDP Paket sind. Ein UDP Paket mit 10 Byte Nutzdaten ist natürlich mit Header größer. DATA ist meinem Beispiel ein nicht optimierter DB um die Byte Reihenfolge in Bezug zum empfangenen Paket beizubehalten, DATA könnte auch ein ARRAY of Byte sein.

In den nachfolgenden Screenshots kann man nun erkennen, dass die Nutzdaten aus den zwei unterschiedlichen UDP Paketen, die ich an die Steuerung sende, nicht aneinander gehängt werden sondern überschrieben werden.

Live1.PNG

Live2.PNG

Ein anderes Verhalten würde auch kein Sinn ergeben, da wie ich schon geschrieben habe über InOut ADDR zu jedem empfangenen Paket der Remote Partner ausgegeben wird. Ein vollständig empfangendes Paket wird immer mit NDR = true signalisiert.

Dieses Verhalten ist bei einer Programmierten TCP Verbindung identisch.

Es werden weder bei einer UDP noch bei einer TCP Verbindung Daten aus unterschiedlichen Paketen aneinander gefügt.

Das bedeutet aber nicht, dass z.B. ein TCP Paket nur aus einem Telegramm bestehen muss, um eine Übertragung per IP zu gewährleisten, werden die TCP Pakete in mehrere Telegramme segmentiert.

Für den Test kam TIA V15 + PLCSIM Advanced V2.0 zum Einsatz, Paket Sender ist Freeware.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Abholen der Daten findet im Zyklus statt und beeinflusst dadurch die Zykluszeit. Und wie Heinileini geschrieben, ob 40 TRCV_C Aufrufe pro Zyklus nicht die Zykluszeit nach oben treiben.
Wie geschrieben verwende ich LCom von Siemens (intern TCon, TSend, TRCV) da steigt die Zykluszeit deutlich an, ca. 1-2 ms je Verbindung und es werden max. 2 Telegramme im Zyklus übertragen.
Aber teste es und berichte.

Ja die Zykluszeit wird durch OUC beeinflusst, jedoch nur maginal, durch das auslesen und umkopieren.

Ich wollte nur Aussagen, dass die Kommunikation parallel zum User Programm stattfindet.

Ich habe gerade zum Testen 20 Verbindungen mit ein paar Bytes zum Empfangen initiert und die Zykluszeit bei einer 1516 liegt von 0 Verbindungen aufsteigend zu 20 bei ca. 2 ms, die Werte decken sich auch aus meiner Erfahrung, wo deutlich mehr OUC Verbindungen parallel laufen.

Was in der LCom Lib passiert kann ich nicht sagen, demensprechend ist es möglich das je Instanziierung die Zykluszeit deutlich steigt.
 
@Harald
Die 1500 verhält sich anders als die 300/400/1200.
Das haben wir bei der Migration unserer Kommunikationsbausteine auch erfahren.

@Fabian
Die Zeiten für die Kommunikation sind auch stark unterschiedlich zwischen den kleinen und großen 1500 Steuerungen.
 
Wenn wirklich weitere eintreffende Pakete die im internen Puffer vorhandenen Pakete, die noch nicht im Anwendungsprogramm abgeholt wurden überschreiben würden, wäre das für mich der Super-GAU. dann wäre ja keine sinnvolle Kommunikation mehr möglich. Noch dazu, wenn Pakete eines anderen Absenders überschrieben würden.
 
Zurück
Oben