# TCP/IP Telegrammaustausch mit PC variable Telegrammlänge



## 3DA (16 Juni 2009)

Hallo Ihr, die Ahnung habt,


hab schon mehrmals eine Kommunikation realisiert, bei der meine SPS (CPU315-2DP mit CP343-1 Lean) mit einem PC über TCP-Verbindung Telegramme austauscht. Da waren die Telegramme aber immer gleich lang und ich konnt sie schön nacheinander in den gleichen Datenbereich im DB kopieren.

Jetzt stellt sich aber der PC Fuzie quer und will die Telegrammlängen nicht mehr anpassen. D.h. es kommen jetzt Telegramme mit Längen zwischen 10 Byte und 37 Byte bei mir an.

Prinzipiell ist das Telegramm so aufgebaut: Header mit 8 Byte--> Seperator--> Information--> CR LF (Jedes Zeichen 1 Byte)

Bsp.:

I N H E A D E R > 1 - 0 0 - 1 1 CR LF (insg. 18 Byte)

Mein Problem ist jetzt, dass der Receive-Baustein FC6 einen gewissen Datenbereich für die empfangenen Daten verlangt, der ja logischer Weise so groß sein muss, dass das längste Telegramm darin gespeichert werden kann. Kommt aber ein Telegramm, dass kürzer ist, verschiebt es die Zeichen um die Bytes im DB wie das Telegramm kürzer ist. D.h. meine Bytes im DB in denen ich die Informationen erwarte sind nicht mehr da, wo ich sie erwarte. 

Gibt es eine Möglichkeit (so ne Art Schieberegister) die Zeichen des Telegramms vom Header an zu lesen und dann in einen weiteren DB zu kopieren, indem die Telegrammzeichen dann wieder an der Stelle sind, wo ich sie erwarte?


Vielen Dank im Voraus für Eure Bemühungen!!


Gruß 

3DA


----------



## Lars Weiß (16 Juni 2009)

Prinzipiell ist es möglich Telegramme mit variabler Länge zu empfangen, wenn in dem Telegramm vom PC (am Besten im Header), die Anzahl der noch folgenden Bytes stehen.
In der S7 machst du 2 AG-Recieve aufrufe die du gegeneinander verriegelst. Mit dem ersten empfängst du den Header mit fester Länger, mit der Längeninformation baust du dir einen Any-Pointer zusammen den du dann an den zweiten AG-Recieve anlegst. So kannst du dann den Rest des Telegramms empfangen.


----------



## Jan (16 Juni 2009)

Hallo,

mir würden da spontan zwei Dinge einfallen.

1. Die Zahl die die Anzahl der Bytes angibt, als Variable anlegen (wenn möglich und wenn die Anzahl der Bytes, die kommen bekannt ist).

2. Den Bereich mit 37 Bytes anlegen. Dann alle Bytes abfragen, ob sie ungleich 0 sind (geht nur, wenn kein Zeichen 0000 0000 hat), ist das erste Byte = 0, dann "schiebe" alle Bytes um ein Byte (auf die Reihenfolge achten, damit man sich nicht seine Bytes überschreibt). Ist das erste und das zweite Byte = 0, dann schiebe alle Bytes um zwei Byte, u.s.w..

Ich hoffe Du kannst etwas mit dem Ansatz anfangen.

Gruß Jan


----------



## Jan (16 Juni 2009)

Da war Lars Weiß schneller (und genauer).


----------



## 3DA (16 Juni 2009)

Geb ich dir vollkommen recht.

Aber leider ist das Telegramm schon fest vorgegeben und der PC Progger ändert nichts mehr an seiner Version mit der Begründung das schon andere SPS Programmierer dieses Problem gelöst haben, die ich natürlich auch nicht fragen kann, weil die von der Konkurrenz sind.

Gibt's ne Möglichkeit den Speicherbereich anhand der "LEN" Telegrammlängen Information variabel zu verändern? oder kommt die Längen Info erst nachdem das Telegramm schon gespeichert ist?

Könnte man vielleicht auch eventuell nach den 8 Zeichen (die ja bekannt sind) im DB suchen und ab da im neuen DB von Adresse 0 an speichern?


----------



## Jan (16 Juni 2009)

Was für 8 zeichen meinst du?


----------



## 3DA (16 Juni 2009)

Sorry... die 8 Zeichen des Headers meine ich...

man könnte vllt. nach den 8 zusammenhängenden Zeichen suchen und dann von da an 37 Bytes in einen neuen DB von Adresse 0 an Speichern. Dann hätte ich alle Zeichen an der richtigen Stelle und was dann hinten raus steht... who cares...

Noch ne Frage:

Wie kann ich 37 Bytes byteweise verschieben? mit SHL_L gehen doch nur 4 oder?


Danke schon mal..


----------



## Ralle (16 Juni 2009)

Ich würde dem Heini eine Reinhauen, ehrlich! Wenn Dummheit und Ignoranz quitschen würden ...  Hatten "Die Anderen" das auch mit einer S7 gelöst, da kenn ich erstmal keinen anderen Weg, als den von Lars.


----------



## Jan (16 Juni 2009)

Schieben würde ich step by step mit MOVE.
Über den genauen Programmaufbau müste man sich dann mal genauer gedanken machen.
Aber ich denke, wenn deine Idee funktioniert, ist das wesentlich einfacher, schneller und weniger aufwendig als das schieben.


----------



## Lars Weiß (16 Juni 2009)

Hm, wie wäre es denn mit zwei mal AG-Recieve die sich beim empfangen abwechseln ? Jeweils mit verschiedenen Empfangsbereichen.


----------



## Jan (16 Juni 2009)

Müste man dann nicht für jede Länge von 8 bis 37 einen eigenen Receive-Baustein haben?


----------



## Ralle (16 Juni 2009)

Lars Weiß schrieb:


> Hm, wie wäre es denn mit zwei mal AG-Recieve die sich beim empfangen abwechseln ? Jeweils mit verschiedenen Empfangsbereichen.



Aber was genau soll das bringen, über die Längenangabe leert man doch eigentlich erst den Buffer korrekt, oder? Also braucht man die vorher, beim Aufruf!


----------



## Lars Weiß (16 Juni 2009)

Ralle schrieb:


> Aber was genau soll das bringen, über die Längenangabe leert man doch eigentlich erst den Buffer korrekt, oder? Also braucht man die vorher, beim Aufruf!



Ich denke mal laut: 2 mal AG-Recieve mit Empfangspuffer a 100Byte. Ein Telegramm mit 10 Byte wird empfangen. Mit NDR schalte ich auf den zweiten AG-Recieve um. Ein neues Telegramm kommt. Wo wird dieses im Empdangspuffer hingeschrieben. An den Anfang ? Oder ab Byte 11 ?


----------



## 3DA (16 Juni 2009)

Naja mit dem PC Progger, dass hat politische Gründe warum der sich so quer stellt...

Aber die Move geschichte wird halt extrem aufwendig und vorallem zeitaufwändig!!

@Lars: Was meist du mit zwei AG_RECV mit verschd. Speicherbereich?

Was hätte das für einen Vorteil?

Danke schon mal...


----------



## 3DA (16 Juni 2009)

Ahhh... jetzt kapier ich was du meinst...


Quasi 2 AG die abwechselnd die Telegramme empfangen in 2 verschd. DB z.B. und das nächste Telegramm kommt in den AG nr. 2.

Wenn AG nr. 1 ausgewertet mach ich dessen DB wieder platt und das 3. Telegramm kommt wieder von Adresse 0 an im AG Nr.1.

Meinst du das so?

Geniale Idee...


----------



## Lars Weiß (16 Juni 2009)

Hab keine Ahnung ob das funzt ... aber als denkanstoss ...


----------



## 3DA (16 Juni 2009)

Ich werd's gleich morgen mal versuchen, ob das so funktioniert.

Genial wär's. Dann würde die Ganze Register-Schieberei einfach wegfallen.

Respekt... wirklich genial Kombiniert ;-)

Ich geb euch Bescheid morgen, ob's funzt...


Danke mal...

Schönen abend wünsch ich...


----------



## 3DA (17 Juni 2009)

Moin...

also hab das mal mit den 2 AG_RECV Bausteinen probiert. Jeder Baustein hat seinen eigenen DB mit 40 Byte. Sobald ich NDR -> neues Telegramm erhalten habe, sperr ich den AG_RECV und lösch den DB des anderen AG_RECV. So geht es jetzt immer von Telegramm hin und her. Aber
trotzdem sind die Telegramme immer verschoben. Jedesmal anders und ich weiß nicht warum?

Hat da jemand eine Lösung??


Danke schon mal...


----------



## Lars Weiß (17 Juni 2009)

Tja, dann wirds wohl nicht anders gehen wie in meinem erste Beitrag beschrieben...


----------



## Grubba (17 Juni 2009)

Weiß es jetzt zwar nicht genau (und kanns jetzt auch gerade nicht testen), aber ich denke das NDR erst dann kommt, wenn der Empfangspuffer komplett gefüllt ist. Lege ich also einen Puffer von 100 Byte an, würde NDR erst dann True werden, wenn mind. 100 Byte empfangen worden sind. 

EDIT:

hier stand mal was, was garantiert nicht funktioniert hätte


----------



## Lars Weiß (17 Juni 2009)

Eine Idee hätte ich noch:

Empfange das Telegramm in deine 40Byte. Dann suchst du in den 40Byte nach dem Startzeichen von dem Telegramm und schaufelst es Byte für Byte dahin wo du es brauchst bzw. weiter auswerten willst. Dann bügelst du die 40 Byte mit Nullen und kannst ein neues Telegramm empfangen und auswerten ...


----------



## Rainer Hönle (17 Juni 2009)

Nur eine Frage am Rande: Die Siemens füllt den Puffer nicht von vorne, wenn ich sage ich möchte 100 Zeichen empfangen und bekommen nur 50? Stehen die dann wirklich irgendwo in diesem Puffer?


----------



## 3DA (17 Juni 2009)

Hallo Grubba,


wieso nicht funktioniert hätte?

Das könnte doch funktionieren, nur 1 Byte als Speicher anzugeben und dann Byteweise das Telegramm zu empfangen bis ich den Telegrammabschluss erhalten habe oder?!


----------



## Rainer Hönle (17 Juni 2009)

3DA schrieb:


> Hallo Grubba,
> 
> 
> wieso nicht funktioniert hätte?
> ...


Das geht minimal auf den Datendurchsatz. Bei einer Zykluszeit von 10 ms und imer entsprechendem Flankenwechsel kommt man so doch schon auf berauschende 50 Bytes/s.


----------



## Grubba (17 Juni 2009)

Hatte noch im Hinterkopf, dass man die Empfangsdatenlänge und die Länge des Empfangsdatenfach getrennt vorgeben kann, aber dem ist ja nicht so.

Trägst Du nun 1 Byte als Empfangspuffer ein und der Partner sendet z.B. 10 Bytes, wird der FB 10 Zyklen lang NDR True liefern, und bei jedem Aufruf 1 Byte abholen. Dabei bügelt er aber jedesmal das erste Byte im Empfangs-DB mit dem aktuellen Empfangsbyte über. 

Deshalb wirds so wohl nicht gehen...


----------



## Grubba (17 Juni 2009)

So, auf ein letztes...

Habe überlesen, das Du ja eine Endekennung des Telegramms bekommst. Wenn Du jetzt wirklich immer nur 1 Byte ausliest, könnte es so evtl. doch so gehen:

- Ziel DB anlegen, mit genug Bytes für maximales Telegramm
- AnyPointer basteln, der nach jedem NDR die Zieladresse in Deinem Ziel-DB um 1 erhöht, (aber immer noch 1 Byte gross) 
- Nach Empfang der Endekennung Pointer wieder auf 1. Byte im Ziel-DB zurücksetzen.

Ist ähnlich wie der letzte Vorschlag von Lars, dass Problem sehe ich darin, das der Siemens FB die aktuellen Empfangsdaten da ablegt, wo die alten Empfangsdaten aufhören. Wenn die Sende und Empfangslänge übereinstimmen - wunderbar. Ansonsten gibts immer einen Versatz von Empfang zu Empfang. Bei Empfangslänge von 1 hast Du dieses Problem halt nicht.


----------



## Lipperlandstern (17 Juni 2009)

Irgendwo in den tiefen des Siemens-Supportes habe ich mal was über genau dieses Problem gelesen. Dort wurde auch ein Lösungsansatz incl. Programmbaustein vorgestellt.

Hast du da schon mal gesucht ?


----------



## 3DA (17 Juni 2009)

Nein noch nicht... hast du zufällig noch die Beitrags-ID?

Wenn's da wirklich was von Siemens gäbe, würde ich ja direkt von

meinem Glauben abfallen ;-)


----------



## Lipperlandstern (17 Juni 2009)

ID: 19033929

ID: 8707570

ID: 16825843


Vielleicht hilft es ja weiter.........


----------



## Flinn (17 Juni 2009)

Grubba schrieb:


> Weiß es jetzt zwar nicht genau (und kanns jetzt auch gerade nicht testen), aber ich denke das NDR erst dann kommt, wenn der Empfangspuffer komplett gefüllt ist. Lege ich also einen Puffer von 100 Byte an, würde NDR erst dann True werden, wenn mind. 100 Byte empfangen worden sind.


 
Hallo Grubba,
ganz genauso ist es. Der CP sammelt erst, nach Erreichen der 100 Byte (obiges Beispiel) kommt das NDR.

Achtung! Jetzt kommt ein neuer Aspekt:
Der CP empfängt auch noch Daten und puffert diese zwischen, wenn die CPU in Stop ist! Nach CPU Anlauf können also unschöne Effekte passieren! Dieses ist mir zumindest bei einer S7-400 schon einmal passiert. 

Zur Problemlösung:
Ich würde auch ein AG_Receive mit LEN = 1 Byte machen und einen eigenen Puffer im DB füllen. Ist zwar der Nutzdatenanteil kleiner, aber was soll's.

Gruß
Flinn


----------



## 3DA (17 Juni 2009)

Hallo Flinn,


danke mal für deinen Post.

Aber wie kann man den Puffer des AG_RECV selber kreieren?

Wie würdest du das ganze Progammtechnisch aufbauen?


Danke schon mal für deine Hilfe!


----------



## Flinn (17 Juni 2009)

Grubba schrieb:


> So, auf ein letztes...
> 
> Habe überlesen, das Du ja eine Endekennung des Telegramms bekommst. Wenn Du jetzt wirklich immer nur 1 Byte ausliest, könnte es so evtl. doch so gehen:
> 
> ...


 
Hi 3DA,
ich würde das so machen, wie Grubba schon angedacht hat, siehe oben.
Mit jedem NDR das empfangene Byte in ein DB kopieren, hierbei die DBB-Ziel-Adresse jeweils um ein Byte inkrementieren. Anschließend mit einer Schleife die Anfangskennung suchen (durch byteweisen Vergleich der Headerdaten). Wenn Anfangskennung gefunden, Anfangsposition merken. Jetzt Endekennung suchen. Wenn gefunden, dann Endeposition merken. Dann Anypointer zusammenbauen (mit Länge = Endeadresse - Anfangsadresse) und Quelldaten auf einen Arbeits-DB kopieren und weiterverarbeiten. Jetzt Pointer wieder auf Byteadresse Null setzen.

Viel geschrieben, ist aber im Prinzip genau das, was Grubba meinte.

Sendet das PC-Programm eigentlich zyklisch in gewissen Zeitabständen?
Was soll bei ungültigen Telegrammen passieren? Verwerfen?
Quittierst du Telegramme zurück? Dann könnte der PC nochmals senden.

Gruß
Flinn


----------



## 3DA (18 Juni 2009)

Hallo,


also der Ansatz mit dem Byteweise auslesen scheint sehr gut zu sein.

Hab das mal so probiert. Mein Problem ist jetzt nur, bei RECV 

P#DB6.DBX2.0 BYTE 8 funktioniert das wunderbar. Aber wenn ich dort nur 

1 Byte angebe, geht der AG_RECV Baustein gleich auf ERROR=1.

Fehlercode=16#8184. und das PC programm kann auch garnicht mehr 

verbinden.

Noch ne Frage: Wie würde ihr den Any-Pointer programmieren, um das 

aus dem Empfangs- in einen ArbeitsDB zu kopieren? Kenn mich leider

mit AnyPointern nicht so recht aus...

Noch zum PC Programm:

Es schickt ca. 7 verschiedene Telegramme mit teilweise verschiedenen

Längen. Header sind aber im 8 Zeichen. Und die Telegramme mit gleichem

Header sind auch immer gleich lang bzw. weiß ich den Header, weiß

ich auch die Länge des Telegramms. Würde das die Sache vereinfachen?


Danke mal im Voraus...


Gruß


----------



## 3DA (18 Juni 2009)

bzw. Fehlermeldung 16#80b1 wenn ein Telegramm vom PC kommt.

Dieses Phänomen ist erst weg, wenn ich min. 8 Byte RECV angebe.

Weiß jemand warum das so ist/sein kann?


----------



## Grubba (18 Juni 2009)

Hab gerade noch mal bei Siemens nachgesehen. Da steht, das nicht alle CPs das Byteweise abholen aus dem Empfangspuffer erlauben. Evtl. hast Du so ein Teil erwischt



> Es schickt ca. 7 verschiedene Telegramme mit teilweise verschiedenen
> Längen. Header sind aber im 8 Zeichen. Und die Telegramme mit gleichem
> Header sind auch immer gleich lang bzw. weiß ich den Header, weiß
> ich auch die Länge des Telegramms. Würde das die Sache vereinfachen?



Na logisch !

Die Länge Deines Headers ist ja anscheinend immer 8 Byte lang. Den holst Du Dir mit einem Empfangsauftrag ab. (ab 8 Bytes scheint das mit Deinem CP ja zu funktionieren)
Daraus ermittelst Du dann die Länge des Telegramms. Dann rufst Du noch einmal den Receive-FB auf und trägst als die Empfangslänge die Restlänge des Telegramms ein (Den Header hast Du ja schon abgeholt) Dieser Auftrag holt dann den Rest des Telegramms ab. Fertig


----------



## 3DA (19 Juni 2009)

Hallo Grubba,


hab das mal so probiert, mit den 2 AG_RECV Bausteinen. Bringt er aber immer Fehlermeldung. Wie du schon gesagt hast, kann es sein, dass das nicht mit jedem CP geht?

Hab ne 343-1 Lean --> also die Sparversion quasi...


Weiß jemand ob das mit der Karte überhaupt geht? 

Weil wenn ich ein 27 Byte Telegramm zur SPS schicke und mit dem ersten AG_RECV nur 8 Byte abfrage, geht dieses direkt auf Fehler und speichert die 8 Bytes auch nicht in den angegebenen Datenbereich?!


Grüße


----------



## Grubba (19 Juni 2009)

Du hast doch geschrieben:


> Hab das mal so probiert. Mein Problem ist jetzt nur, bei RECV
> P#DB6.DBX2.0 BYTE 8 funktioniert das wunderbar.


 
Also geht das doch mit den 8 Byte ?


----------



## 3DA (19 Juni 2009)

Ja richtig. Aber da hatte ich nur 1 AG_RECV verwendet, der die Daten dann im 8 Byte Rhytmus abgeholt hat.

Jetzt mit dem 2ten AG_RECV holt der erste vom Telgramm garnichts mehr ab, obwohl der 2te noch garnicht aktiv geschaltet ist.(habe die 2 AG_RECV gegeneinander verriegelt)

Hab sonst aber auch nichts verändert.

An was könnte das liegen? Die ID und LADDR etc. müssen ja bei den beiden AG_RECV gleich sein oder? Habe lediglich die Parameter RECV ERROR STATUS und LEN mit anderen Variablen gefüttert?!


----------



## Ralle (19 Juni 2009)

Versuchs mal mit einem AG_RECV und mach die LEN Variablel. Vielleicht paßt bei der Verriegelung etwas nicht und in deinem Fall müßte es eigentlich auch mit einem AG_RECV funktionieren.

PS: Ich denke, bei dem Umschalten zwischen 2 Bausteinen, muß man sehr vorsichtig zu werke gehen. NDR ist einen Zyklus da. Umschalten darf man wahrscheinlich erst, wenn der Baustein, sein NDR auch wieder zurückgesetzt hat, also frühestens einen Zyklus später.


----------



## 3DA (19 Juni 2009)

Noch ne Frage am Rande...

wenn ich anstatt eines CP-343-1 Lean eine CPU315-2PN/DP einsetze und mit TSEND bzw. TRECV arbeite, würde das das empfangen von variablen Telegrammlängen vielleicht vereinfachen?

Habe leider mit TSEND/TRECV null Erfahrung.

Kann da jemand mehr dazu sagen?


----------



## Grubba (19 Juni 2009)

Wenn jetzt nicht mal mehr der erste Aufruf was abholt, muss der 2. Aufruf ja doch irgendwie vonstatten gehen. Bist Du ganz sicher, das der nicht doch noch aufgerufen wird? Du musst die Aufrufe ja überspringen, ein Enable hat der FC ja nicht.

Eine andere Möglichkeit wäre es, den FC generell nur einmal im Prog zu verwenden und pro Durchlauf mit geänderten Parametern zu versehen.

Poste doch mal was Du hast, vielleicht sieht man dann, woran es hapert.


----------



## 3DA (19 Juni 2009)

Sorry muss meine Aussage nochmal korrigieren:


Hab jetzt nochmal nur 1 AG_RECV verwendet und dabei folgendes raus gefunden.

Ich verwende zum testen ein Programm ähnlich wie der HyperTerminal namens Hercules.

Mit dem kann man sich über IP und Socket verbinden und Telegramme senden/empfangen. Mit diesem Prog funktioniert das wunderbar, ein 30 Byte Telegramm zu senden und dann mit dem AG_RECV 8-Byteweise abzuholen. Verwende ich aber das Programm, mit dem ich dann im endeffekt kommunizieren muss, geht der AG_RECV auf Störung, sobald der Datenbereich kleiner als das zu empfangene Telgramm ist. Sprich: es kommt ein 30 Byte Telegramm und ich kann alle Speicherbereich über 30 Byte angeben--> es funktioniert, aber sobald ich 29 Byte oder kleiner nehm, geht er auf Störung mit Fehlermeldung 16#80b1?!

Keine Ahnung warum... an was könnte das liegen?


----------



## Grubba (19 Juni 2009)

Kann ich mir so auch nicht erklären. Vielleicht sendet das Testprogramm nur einmal per Mausklick, das Originalprog zyklisch ?

Hier mal ein Link. Derjenige hatte das gleiche Problem wie Du:

http://www.automation.siemens.com/forum/guests/PostShow.aspx?PostID=38736&Language=de&PageIndex=1

Ansonsten wirklich mal Deinen Code reinstellen.


----------



## 3DA (19 Juni 2009)

Also das eignetliche Prog sendet nur 1 Telegramm, und das in einem Zeitabstand von vielleicht 3-4 sec. also völlig zeitunkritisch. Mein AG_RECV Aufruf sieht folgendermaßen aus:

 CALL  "TCP_RECEIVE" (FC6)
       ID    :=2
       LADDR :=W#16#100
       RECV  :=P#DB6.DBX2.0 BYTE 8
       NDR   :=#RecvNewData
       ERROR :=#RecvError
       STATUS:=#RecvStatus
       LEN   :=#RecvLength
      NOP   0

Wie gesagt, ich kapier halt nicht, wieso der Speicherbereich zu klein Fehler kommt, weil der doch auf den Speicher des Bausteins selber bezogen ist oder? Und der müsst doch > 200 Byte sein und mein Telegramm hat maximal 30 Byte. 

Hilft dir der Bausteinaufruf was? Weil alles andere hab ich mittlerweile schon rausgeworfen.


----------



## Grubba (19 Juni 2009)

Tja, wenn ich noch nen CP hätte würd ichs ja selber mal testen...

So, meine letzten Versuche vor Feierabend:

-Dein Empfangs-DB ist aber auch 8 Byte oder größer ? 

-Unter Netpro die Verbindung auch als TCP-Verbindung projektiert ? (nicht evtl. Iso on TCP?)


----------



## 3DA (19 Juni 2009)

Also der Empfangs-DB ist größer als 8 Byte.

Ja TCP Verbindung ist richtig eingestellt, sonst würde es ja bei einer größeren RECV auch nicht funktionieren.

Ist das ein Problem, wenn der DB größer ist, als der angegebene Bereich?!


Wie Feierabend??!


----------



## Lars Weiß (19 Juni 2009)

----------


----------



## Ralle (19 Juni 2009)

Grubba schrieb:


> Kann ich mir so auch nicht erklären. Vielleicht sendet das Testprogramm nur einmal per Mausklick, das Originalprog zyklisch ?
> 
> Hier mal ein Link. Derjenige hatte das gleiche Problem wie Du:
> 
> ...



Besonders der Hinweis, mit der Umschaltung zu warten, solange der Auftrag noch läuft, wäre wichtig. (letzter Post im Beitrag!)


----------



## Ralle (19 Juni 2009)

3DA schrieb:


> Also der Empfangs-DB ist größer als 8 Byte.
> 
> Ja TCP Verbindung ist richtig eingestellt, sonst würde es ja bei einer größeren RECV auch nicht funktionieren.
> 
> ...



Glaub ich nicht, hab ich auch immer größer.

PS: Es ist dir aber sicher klar, daß du den Any

RECV :=P#DB6.DBX2.0 BYTE 8

dynamisch erzeugen mußt, da ja die Byteanzahl, (also LEN) genau dort festgelegt wird!

Byte 8 für den Kopf
Byte xx, dann für die unterschielich langen Resttelegramme.


----------



## Lars Weiß (31 August 2009)

3DA schrieb:


> Noch ne Frage am Rande...
> 
> wenn ich anstatt eines CP-343-1 Lean eine CPU315-2PN/DP einsetze und mit TSEND bzw. TRECV arbeite, würde das das empfangen von variablen Telegrammlängen vielleicht vereinfachen?
> 
> ...



Das Thema hat zwar schon etwas Staub angesetzt, aber mir ist grad eben aufgefallen das die Profinet-Cpu´s mit ihren Bausteinen für die offene TCP-Kommunikation den Datenempfang über TCP mit verschiedenen Telegrammlängen beherschen.

Am T-Recieve muss für den Parameter LEN = 0 angegeben werden.


----------



## 3DA (31 August 2009)

Hallo!


Danke für den Tipp, hab's auch letzten Endes so gemacht. Läuft wunderbar!!

Ein hoch auf die Profinet-CPU ;-)


Grüße

3DA


----------



## Lars Weiß (31 August 2009)

jupp. Macht die ganze Sache einfacher.


----------



## Ma_su (31 August 2009)

Hallo, 
ich habe da dann nochmal eine frage zu dem Thema mit den PN-CPU´s. 

Wenn ich das richtig verstehe bedeutet dies das wenn ich die abzufragende Telegrammlänge auf Null setze. Bekomme ich das empfangene Telegramm zurück egal in welcher länge es gesendet wurde, mit Rückmedlung der Telegrammlänge?

Habe ich das so richtig verstanden oder ist das wunschdenken von mir?

Gruß Marc


----------



## Lars Weiß (31 August 2009)

Das hast du richtig verstanden. Siemens empfiehlt sogar eine 0 einzusetzen. Dein Empfangspuffer muss nur gross genug sein.


----------



## maninthedark (3 Februar 2015)

Hallo Kollegen,

vielen Dank für diesen Beitrag! Er hat mir heute sehr viel geholfen, dafür wollte ich mich bedanken! Sehr schön wenn es immer wieder Leute gibt die sich damit befassen.

Ich hatte nämlich genau die geschilderte Problematik. Hatte es zuerst mit FC 5/e über einen CP realisieren wollen. Durch die unterschiedliche Telegrammlänge die ich aber von dem PC als Partner zurüch bekomme hat dies nicht funktioniert. Da ich sowieso eine PN-CPU in meinem Aufbau habe, musste ich nur das Netz umparametrieren. 
Jetzt läuft die Kommunikation über PN-CPU bestens.


----------



## Beckx-net (3 Februar 2015)

Um diesen Beitrag abzuschließen:
Variable Telegramme können auch mit CP-Modulen empfangen werden. siehe -->
https://support.automation.siemens....QYuNYn6yXL98Bj0ZDk89fk6upLT4sUg==&caller=view

Der beschriebene Baustein ließt den Buffer der CP-Baugruppe byteweise aus. Es wird aber eine definierte Ende-Kennung im Telegramm benötigt. Ich würde die Lösung mit PN-CPU (T-Kommunikationsbausteine) aber favorisieren.


----------

