TCP/IP Telegrammaustausch mit PC variable Telegrammlänge

[Grubba]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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ß]

----------

 

[Ralle]

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.

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

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

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??!

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ß]

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?

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]

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ß]

Zuviel Werbung?
-> Hier kostenlos registrieren

jupp. Macht die ganze Sache einfacher.

 

[Ma_su]

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ß]

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

 

[maninthedark]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.