TRCV - Problem 2 Endekennungen in einem Paket

[floh041183]

Zuviel Werbung?
-> Hier kostenlos registrieren

Allgemein:
Ich hab einen Vision-Sensor via Ethernet an einer 319-3 PN/DP.
Ich hab eine Offene Kommunikation (nicht in NetPro) mit TCONN, TSEND, TRCV und einem FC97 für die TCP-Einstellungen.

Die Kommunikation klappt, und ich kann dem Sensor auch Befehle schicken auf die er auch antwortet.
Die länge der empfangenen STRINGS ist unterschiedlich, weshalb ich beim TRCV LEN=0 eingestellt hab, dann sieht er anhand der Endekennung, wann das Datenpaket zu Ende ist.

Mein Problem ist, das der Sensor bei dem Befehl, wo die Messwerte drin stehen wiefolgt antwortet:

OK&\0InspektionsName&Messwert1&Messwert2&...\0

Wie man sieht stehen in dem Paket zwei Endekennungen.

Wenn der TRCV den Wert in einen DB-Bereich schreibt, dann wandern die BYTES, weil er im ersten Durchlauf das OK& abholt und beim zweiten Durchlauf den Rest.

Durch dieses wandern kann ich die BYTES leider nicht fest zuordnen.


Wie löse ich das Problem?

 

[SoftMachine]

Trcv --> rcvd_len

Hallo,
habe mit der offenen Komunikation mittles UDP-Telegrammen und TURCV/TUSEND gearbeitet.

Bei TCP gibt doch der TRCV über RCVD_LEN die tatsächlich empfangene Datenlänge aus.
Damit kannst du doch arbeiten und auch die nach dem ersten Endezeichen folgenden Daten auswerten ? ! ?

Gruss

 

[SoftMachine]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
habe mit der offenen Komunikation mittles UDP-Telegrammen und TURCV/TUSEND gearbeitet.

Bei TCP gibt doch der TRCV über RCVD_LEN die tatsächlich empfangene Datenlänge aus.
Damit kannst du doch arbeiten und auch die nach dem ersten Endezeichen folgenden Daten auswerten ? ! ?

Gruss

Hallo,
hier noch ein Link dazu:
http://support.automation.siemens.com/WW/llisapi.dll/29737950?func=ll&objId=29737950&objAction=csView&nodeid0=37217116&lang=de&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&load=content&csQuery0=TRCV&subtype=130000

Dort wird die empfangene Datenlänge im Datenbaustein abgelegt und kann ausgewertet werden, so dass du nicht nur auf das Endezeichen schauen musst...

Gruss

 

[SoftMachine]

Auswertung Empfangsdatenlänge

Wie löse ich das Problem?

Hier nochmal für die Auswertung der Empfangslänge im vorhergehenden Lin k das entsprechende Netzwerk

Gruss

 

[floh041183]

Danke erstmal für deine Hinweise.
Mein Programm ist genau das Beispielprogramm von deinem Link (TCP-Version)

Ich hab mir mal genau die Werte in dem RCV_LEN angeschaut und stelle fest, das er mir mal 106BYTE schickt, genau die Gesamtlänge, die ich brauche, dann im nächsten oder übernächsten Zyklus schickt er mir nur 102 BYTE (106-OK&\0) und dann wieder mal nur 4 BYTE.

Getaktet hab ich das Ganze mit 1Hz, der holt also jede Sekunde die Messwerte ab. Die Erfassungszeit der Kamera beträgt so zwischen 300-400ms, laut dem Hersteller-Konfigurationstool.

Was kann das sein? Der schickt ja zwischendurch immer mal die richtige Datenlänge...

MfG

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Woher weißt du, dass "/0" als Endekennung vom Siemens-CP erkannt/genutzt wird? Vielleicht schickt sein Vision-Sensor zwei Pakete kurz hintereinander.
bei seriellen CP kann man ja die Endekennung auf Zeichenverzugszeit einstellen, wie genau erkennt der Ethernet-CP denn die Länge?

Wenn dein Vision-Sensor insgesamt 106 Byte sendet, dann kannst du die Länge am T_RCV-Baustien auch einmal fest auf 106 Byte stellen.

Ansonsten bleibt nur die Auswertung der empfangenen Länge und Reaktion auf die 3 Möglichen Fälle, das sind ja nicht all zu viele.

 

[floh041183]

hallo Ralle,
also das \0 soll eine Binäre Null sein, ich dachte immer, dass bei Zeichenketten nur immer nur soviele Daten gelesen werden, bis die erste "binäre Null" kommt. Ich dachte das sei ein einheitliches Zeichen, diese Endekennung.

ich hab leider kein CP, sondern eine intigrierte ethernetschnittstelle.
CPU 319-3 PN/DP FW 2.7.2

Kann man irgendwo einstellen, was die CPU als Endekennung erkennen soll?
Wo kann man diese Zeichenverzugszeit einstellen?

Naja, dass das 106 BYTE sind weiß ich nur, weil ich das vorher mit einem TCP/IP -Tester getestet hab, da funktioniert das auch ohne Probleme.
Kommt alles in einem Paket.
Der wartet wahrscheinlich eine gewisse Zeit, und macht dann das Paket zu, alles was danach kommt, ist ein extra Packet.

Die Sache ist die, wenn ich in dem Konfigurationstool jetzt auf andere Sachen teste, dann ändert sich wieder die Datenlänge.

Im Moment teste ich nur auf Lageerkennung(Winkel).
Wenn ich jetzt noch auf Helligkeit, Kontrast, Kanten, Muster, Position, Breite etc. untersuche, dann kommen noch einige BYTEs dazu, und ich müsste jedes Mal, wenn ich die Konfiguration ändere auch die Länge im SPS-Programm ändern...

 

[SoftMachine]

Auswertung und weitere Messwerte

1) weitere Messwerte

Die Sache ist die, wenn ich in dem Konfigurationstool jetzt auf andere Sachen teste, dann ändert sich wieder die Datenlänge.
Im Moment teste ich nur auf Lageerkennung(Winkel).
Wenn ich jetzt noch auf Helligkeit, Kontrast, Kanten, Muster, Position, Breite etc. untersuche, dann kommen noch einige BYTEs dazu, und ich müsste jedes Mal, wenn ich die Konfiguration ändere auch die Länge im SPS-Programm ändern...

Also, am TRCV gibst du mit LEN die Länge des Empfangsbereichs an in dem Datenbereich, den du mit DATA vorgegeben hast. Dieser Datenbereich darf auch grösser sein als die Telegrammlänge.
LEN kannst du also auch z.B. mit 200 belegen, der über DATA angegebene Datenbereich muss dann aber auch mindestens diese Länge haben !
Dann kannst du mit dem Konfig-Tool am Sensor weitere Messwerte parametrieren, die hängt der einfach mit der vorgegebenen Reihenfolge ans Telegramm dran.
so z.B. --> OK&\0 InspektionsName& Messwert1& Messwert2& Messwert3& ... Messwert25& ...\0
Dem TRCV ist das egal, der empfängt einfach nur das, was kommt und legt es im Datenbereich ab.

2) Telegrammauswertung

Ich hab mir mal genau die Werte in dem RCV_LEN angeschaut und stelle fest, das er mir mal 106BYTE schickt, genau die Gesamtlänge, die ich brauche, dann im nächsten oder übernächsten Zyklus schickt er mir nur 102 BYTE (106-OK&\0) und dann wieder mal nur 4 BYTE.
Getaktet hab ich das Ganze mit 1Hz, der holt also jede Sekunde die Messwerte ab. Die Erfassungszeit der Kamera beträgt so zwischen 300-400ms, laut dem Hersteller-Konfigurationstool.
Was kann das sein? Der schickt ja zwischendurch immer mal die richtige Datenlänge...

Nehme an, der Sensor schickt neben Messwerten auch andere Telegramme... (OK&\0)
Wenn du zyklisch jede Sekunde auf den Emfangsdatenbereich zugreifst, kann sich das mit einem laufenden Empfang überschneiden.
Du musst also zunächst den NDR vom TRCV auswerten. Der sagt dir, ob überhaupt was empfangen wurde.
Bei NDR = "1" holst du die Daten aus dem Empfangsbereich, und zwar in der Länge, wie es der RCVD_LEN
angibt und kopierst sie in einen anderen Datenbereich um (NDR siehe Grafik Beitrag #4).

Dort kannst du die umkopierten Daten auswerten, in dem du erstmal prüfst, ob es ein einzelnes Messwerttelegramm (InspektionsName&...) oder ein anderes ist (OK&\0...).
Wenn ein Telegram "OK&\0InspektionsName&Messwert1&Messwert2&...\0" empfangen wurde, erkennst du an der Länge in RCVD_LEN, das nach dem "OK&\" noch die Messwerte folgen müssen, d.h. du wertest das Telegramm erst ab Byte 5 aus.

Ein reines Messwerttelegramm (InspektionsName&...) wertest du ab dem ersten Byte in der Reihenfolge/Struktur aus, wie es dem Sensor parametriert wurde.

Wurde nur "OK&\0" empfangen, machst du gar nichts und wartest auf deas nächste NDR = "1".


Viel Erfolg !!
Gruss