TIA String über Open-User-Communication empfangen

robert_m6789

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen.

Ich brauche dringend Hilfe Beim Empfang eines Strings über eine Open-User-Communication.

Programmiert wird im TIA-Portal V15 mit einer S7 1200

Für die Kommunikation nutze ich den TRCV_C Baustein.
Die verbindung zu einem PC besteht auch schon und ich empfange auch Daten. Leider Sind diese ziemlich durcheinander
Nachfolgend die Angabe wie der String aussieht.
String Ausgabe.png
Beispiel-String: „20180608;130257;27;3c:4b:89:12:77:6f;83.67;10.67;2.50;\n“


Empfangen wird aber:

1. Empfang '.37;+0001.20;$L20181106;083655;609;00:00:00:00:32:8'
2. Empfang '8;+0019.03;+0002.39;+0001.20;$L20181106;083722;946;00:00:'
3. Empfang ':00:32:88;+0021.82;+0006.88;+0001.20;$L20181106;0'

usw...

Das heißt die Daten die empfangen werden passen ja, sind irgendwie immer verschoben. woran liegt das:confused:

Hier noch mein Baustein
Baustein.PNG
 
Aktiviere mal den ADHOC-Eingang. Nach Deiner Protokollbeschreibung schwankt vermutlich die Länge der TCP-Nachrichten. Näheres zum Empfang von Nachrichten mit dynamischer Länge lies mal die TIA-Hilfe zum TRCV_C

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auch muss man beachten das TRCV_C ein byte array ausgibt, das gilt es dann entsprechend zu wandeln, dabei ist auch zu beachten das der String 2 Byte header daten enthält die dein Partner (PC) nicht liefert so wie es dargestellt ist...

Bastian
 
Immerhin werden bei den empfangen DatenSätzen die vorlaufenden Nullen nicht unterdrückt, so dass - im Gegensatz zum Beispiel - wohl nicht mit einer variablen TelegrammLänge zu rechnen ist.
Mich stört nur, dass die Koordinaten mit Vorzeichen, aber nur 4 VorkommaStellen ankommen, statt der erwarteten 5 VorkommaStellen (laut Beschreibung).
Versuch's mal mit den TelegrammLängen 54 (excl. LF) bzw. 55 (incl. LF).

PS:
. . . dabei ist auch zu beachten das der String 2 Byte header daten enthält die dein Partner (PC) nicht liefert so wie es dargestellt ist...
Das komplette Telegramm sieht aus wie 1 String ohne "HeaderDaten". Die Siemensschen LängenBytes im Telegramm mit zu übertragen, wäre eher unüblich, selbst wenn der Partner auch Siemens heissen sollte.

PPS:
Woher kommt die Darstellung $L für das LineFeed?
 
Zuletzt bearbeitet:
Wie groß ist Dein Empfangspuffer "Input PES".Static_2 ? Es sieht aus als ob der zu klein wäre. Damit ein ganzes Datenpaket reinpasst muß der Empfangspuffer (mindestens) 66 Byte groß sein. Der Empfangspuffer sollte als "ARRAY [0..65] OF CHAR" deklariert sein (nicht als STRING, weil es kein S7-STRING ist).

Wurden bei den 3 Empfangsdaten wirklich so unterschiedlich große Pakete empfangen??
( 1. Empfang: 50 Zeichen, 2. Empfang: 56 Zeichen, 3. Empfang: 48 Zeichen )

Zwischen dem Ende vom 2. Empfang und dem Anfang vom 3. Empfang fehlen 2 Zeichen ('00') - haben die wirklich gefehlt oder sind die beim Forums-Beitrag schreiben verloren gegangen?

Der Aufbau der empfangenen Datenpakete entspricht zwar nicht ganz der Beschreibung, ist so aber günstiger für den Empfang mit S7-SPS. Anscheinend sind alle Datenpakete genau 66 Byte lang. Du könntest bei TRCV_C auch bei LEN 66 angeben.


@Heinileini
'$L' ist die Siemens-/Beckhoff-/Codesys-/1131-Schreibweise für die C-Schreibweise '\n'
'$L' = '$0A' = B#16#0A = 0x0A = '\n'

STRING/CHAR-Konstanten

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
. . . Damit ein ganzes Datenpaket reinpasst muß der Empfangspuffer (mindestens) 66 Byte groß sein. Der Empfangspuffer sollte als "ARRAY [0..65] OF CHAR" deklariert sein (nicht als STRING, weil es kein S7-STRING ist).
Du hast Recht, Harald! 66 Byte natürlich. Wie schreibt doch Sven Rothenspieler immer in seinem Nachspann … :oops:

Gruss, Heinileini
 
Ich weiss ja, dass es niemanden interessiert und dass es kein Beitrag zum Thema dieses Thread darstellt und Sven möge mir verzeihen, wenn ich hiermit seinen Spruch kaputt mache:
Ich gehöre zu der 3. Art Menschen - die, die zu bequem sind, selbst zu zählen, deshalb Excel für sich zählen lassen und dann im Eifer des Gefechts auch noch an der falschen Stelle das vermeintliche Ergebnis ablesen! :ROFLMAO:
 
Hatte fast das gleiche Problem vor ein paar WOchen auch schon mal.

Ich habe versucht ein Telegramm vom RCV in eine UDT schreiben zu lassen.
Erst als ich es in ein Array of Byte habe schreiben lassen, kamen die Daten in der richtigen Reihenfolge an, vorher kam das Ende vor dem Anfang.
Habe dann noch einen Baustein geschrieben, der mir das Array of Byte in die UDT mappt.
 
Zurück
Oben