TIA Byte Reihenfolge mit TRCV

[Stefan_POL]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich lese hier schon eine ganze Weile mit und habe schon viele nützliche Antworten auf meine Fragen bekommen. Auf diese hier leider noch nicht.

Mein Projekt soll unter anderem zyklisch Daten von einem Sensor über TCP/IP auslesen. Das Datenpaket ist 3 Byte groß und die einzelnen Bytes werden immer in der gleichen Reihenfolge gesendet. Über Wireshark kann ich das schön mitlesen. Mit der TRCV-Funktion werden die Pakete eingelesen und in ein Array of Bytes in einen DB geschrieben. Mein Problem an der Stelle ist, jedes Mal, wenn ich das Lesen aktiviere (also das zyklische Senden der Datenabfrage über TSEND und das Setzen von EN_R von TRCV auf TRUE), verschiebt es im DB die jeweiligen Bytes um eine Zeile. Somit ist die logische Zuordnung der jeweiligen Bytes dahin. Wie bekommt man das gelöst, dass die TRCV-Funktion die Byte-Reihenfolge nicht durcheinander wirft?

Danke und Gruß
Stefan

 

[PN/DP]

Verschiebt sich das einmalig um 1 Byte oder "rollen" die 3 Bytes bei jedem Empfangstelegramm durch?
Ist es sicher, daß der Sender nicht auch mal 1 Byte mehr sendet? Gibt er vielleicht zusätzlich noch ein ACK- oder Ende-Zeichen?
Hast Du vielleicht einen Link zum Sensor-Handbuch, wo das Protokoll beschrieben ist?
Was für eine Verbindung ist das? TCP-, ISO-on-TCP- ...?
Warum läßt Du den EN_R nicht dauerhaft auf TRUE?

Du müsstest dem TRCV sagen, daß er genau 3 Bytes von der Schnittstelle abholen soll.
Hast Du mal ein Bild vom Aufruf des TRCV-Bausteins, möglichst vom online Beobachten?

Der Vollständigkeit halber: welche CPU und welche TIA-Version verwendest du?

Harald

 

[Stefan_POL]

Zuviel Werbung?
-> Hier kostenlos registrieren

TIA v14 mit S7-314C-2 PN/DP

Die Verbindung ist TCP (also 16#11 beim Parameter Connection Type), ISO-on-TCP funktioniert nicht. Der Sender schickt mir nur die 3 Byte, die die gewünschte Information (z.B. Temperatur) enthalten, keine sonstigen Zeichen wie CR oder ACK. EN_R ist, sobald ich die Funktion aktiviere dauerhaft auf TRUE. Meinst Du ich solle EN_R permanent auf TRUE belassen, auch wenn ich keine Daten abfrage?

Es ist so, dass das die Reihenfolge der 3 Bytes beim ersten Mal Empfangen irgendwie ist. Aber danach konsistent. Es rollt also nichts durch, die Verschiebung der Bytereihenfolge findet nur einmalig am Anfang statt. Ich beobachte den Datenverkehr mit Wireshark und das zeigt mir, dass immer nur 3 Bytes gesendet werden. Sollte also ok sein.

LEN ist auf bereits 3 gesetzt.

Das mit dem Handbuch ist so eine Sache. Online ist es nicht verfügbar und ich darf es aus rechtlichen Gründen vermutlich auch nicht online stellen. Ich bin mir auch nicht sicher ob in dem Fall eine Protokollbeschreibung was bringen würde, ich bekomme ja lediglich 3 Byte geschickt.

 

[Zombie]

Kann TIA (können die neuen SPSen) eigentlich ungerade Anzahl Bytes schreiben?

Ich hatte gerade erst ein Problem bei dem ich empfangene Daten von 210 Byte in einen DB mit einer UDT schreiben wollte, in der Arrays der Länge 3 drin vorkamen.
Das nach den drei Byte kommende Byte, das erste Byte der nächsten UDT war dann verschoben, es tauchte nach dem eigentlichen Endezeichen der empfagenen Daten auf.

Meine Lösung war ein Array der Länge 1..210Byte zu deklarieren, und die Bytes einzeln in die Struktur zu kopieren, denn in dem Array of Byte waren alle Bytes in der richtigen Reihenfolge.

 

[Stefan_POL]

Guten Morgen allerseits,

ich glaube die Lösung gefunden zu haben. Obwohl sie mir wenig einleuchtet. Ich habe den Parameter LEN des TRCV-Bausteins auf den Wert 0 gesetzt. Jetzt gibt es keine Verschiebung der Byte-Reihenfolge mehr. Zumindest bis jetzt. Ich hätte gedacht LEN einen Wert zuzuweisen wäre dazu da gewesen um genau die Effekte, die ich beobachtet habe, nicht zu bekommen. Danke für euren Input.

Gruß
Stefan

 

[König172]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen allerseits,

ich glaube die Lösung gefunden zu haben. Obwohl sie mir wenig einleuchtet. Ich habe den Parameter LEN des TRCV-Bausteins auf den Wert 0 gesetzt. Jetzt gibt es keine Verschiebung der Byte-Reihenfolge mehr. Zumindest bis jetzt. Ich hätte gedacht LEN einen Wert zuzuweisen wäre dazu da gewesen um genau die Effekte, die ich beobachtet habe, nicht zu bekommen. Danke für euren Input.

Gruß
Stefan

Aus der Hilfe: Länge des Empfangsbereichs in Bytes (ausgeblendet).Wenn Sie einen Speicherbereich mit optimiertem Zugriff am Parameter DATA verwenden, muss der Parameter LEN den Wert "0" haben.

• Ist LEN = 0, werden die empfangenen Daten in dem am Parameter DATA angegebenen Empfangsbereich gespeichert. Die Anzahl der empfangenen Bytes werden am Parameter RCVD_LEN angezeigt.
  Bei LEN = 0 (Voreinstellung des Parameters LEN) wird die Länge der zu empfangenden Daten über den Parameter DATA festgelegt. Es wird empfohlen, dass der Empfangsbereich (Parameter DATA) dieselbe Größe hat wie die von TSEND übertragenen Daten.
  Falls LEN den Wert 0 hat und die gesendeten Daten in Segmenten übertragen werden, die kleiner sind als der Empfangsbereich DATA, dann gilt das Folgende. Es wird empfohlen, EN_R so lange gesetzt zu halten, bis die zugehörige TSEND-Anweisung alle Daten gesendet hat. Solange die Größe der von TSEND gesendeten Daten ungleich der Größe des Empfangsbereichs DATA ist, zeigt STATUS den Wert 7002. EN_R muss gesetzt sein, bis die Anzahl der empfangenen Daten gleich der Größe des Empfangsbereichs DATA ist. Wenn Sie EN_R pulsen, müssen Sie dies so lange tun, bis BUSY=0 bzw. ERROR <> 0.
  Die Daten im Empfangsbereich DATA sind erst dann gültig, wenn BUSY den Wert 0 annimmt.
  
• Ist die am Parameter LEN angegebene Länge größer als die Länge der am Parameter DATA empfangenen Daten, wird der Fehlercode 8088 am Parameter STATUS ausgegeben (siehe im Folgenden Beschreibung des Parameters STATUS).
  
• Wird über den Parameter DATA eine Struktur (Struct) referenziert, kann LEN kürzer sein als die Struktur. In diesem Fall werden nur die Daten bis zur Länge des Parameters LEN übertragen.
  
• Verweist der Parameter DATA auf einen Datenbaustein mit optimiertem Zugriff, muss der Parameter LEN auf "0" gesetzt werden.
  
• Wird über den Parameter DATA ein Datentyp STRING referenziert, muss die am Parameter LEN angegebene Länge 0 oder >=2 sein (LEN = 1 ist nicht erlaubt).
  
• Wird über den Parameter DATA ein Datentyp WSTRING referenziert, muss die am Parameter LEN angegebene Länge 0 oder >=5 sein.

 

[Ingmar64]

@Zombie:
Klingt wie eine Vermischung von optimierten und nicht optimierten Bausteinen. Meiner Erfahrung nach geht ein BLK_MOV zwischen optimierten und nicht optimierten (z.B. Sende-/Empfangspuffer) schief, weil bei den optimierten die Reihenfolge neu gewürftelt wird.

 

[Zombie]

Ist alles optimiert. Im Empfangspuffer war eine UDT hinterlegt. Es sollten schlicht die empfangenen Daten gleich in die UDT geschrieben werden, was dazu führte dass die Daten komplett verkehrt ankamen.

 

[Ingmar64]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das kann optimiert nicht funktionieren. Bei optimierten Zugriff ist davon auszugehen, daß die Reihenfolge der Daten im Speicher NICHT der Reihenfolge der Definition entspricht. Sondern es geht wohl immer DWORDs, WORDS, BYTEs, BITs. Ein neuer Abschnittstyp beginnt immer an einer Wortgrenze, Bytes und Bits werden zusammengeschoben.
Meine Sende- und Empfangspuffer (Array[0..n] of Byte) liegen immer im nicht optimierten Baustein, dann läßt sich auch mit AT ganz einfach die Struktur über das Array legen und alles ist gut.