Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 8 von 8

Thema: TRCV - Problem 2 Endekennungen in einem Paket

  1. #1
    Registriert seit
    12.04.2011
    Beiträge
    10
    Danke
    15
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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?
    Zitieren Zitieren TRCV - Problem 2 Endekennungen in einem Paket  

  2. #2
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    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
    Zitieren Zitieren Trcv --> rcvd_len  

  3. Folgender Benutzer sagt Danke zu SoftMachine für den nützlichen Beitrag:

    floh041183 (06.05.2011)

  4. #3
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    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

  5. Folgender Benutzer sagt Danke zu SoftMachine für den nützlichen Beitrag:

    floh041183 (06.05.2011)

  6. #4
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Daumen hoch

    Zitat Zitat von floh041183 Beitrag anzeigen

    Wie löse ich das Problem?
    Hier nochmal für die Auswertung der Empfangslänge im vorhergehenden Lin k das entsprechende Netzwerk

    Gruss
    Angehängte Grafiken Angehängte Grafiken
    Zitieren Zitieren Auswertung Empfangsdatenlänge  

  7. Folgende 2 Benutzer sagen Danke zu SoftMachine für den nützlichen Beitrag:

    floh041183 (06.05.2011),S_Everz (07.05.2011)

  8. #5
    floh041183 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    12.04.2011
    Beiträge
    10
    Danke
    15
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  9. #6
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.220
    Danke
    533
    Erhielt 2.696 Danke für 1.948 Beiträge

    Standard

    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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  10. Folgende 2 Benutzer sagen Danke zu Ralle für den nützlichen Beitrag:

    floh041183 (06.05.2011),S_Everz (07.05.2011)

  11. #7
    floh041183 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    12.04.2011
    Beiträge
    10
    Danke
    15
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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...

  12. #8
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    1) weitere Messwerte

    Zitat Zitat von floh041183 Beitrag anzeigen
    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
    Zitat Zitat von floh041183 Beitrag anzeigen
    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
    Zitieren Zitieren Auswertung und weitere Messwerte  

  13. Folgende 2 Benutzer sagen Danke zu SoftMachine für den nützlichen Beitrag:

    floh041183 (09.05.2011),S_Everz (07.05.2011)

Ähnliche Themen

  1. Suche Hilfe bei einem Problem
    Von würgi im Forum Simatic
    Antworten: 12
    Letzter Beitrag: 25.10.2010, 23:06
  2. Antworten: 4
    Letzter Beitrag: 24.08.2009, 09:06
  3. Problem bei Werteveränderung in einem DB
    Von dominik_Thesis im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 01.12.2008, 14:24
  4. Problem mit einem Profibusteilnehmer
    Von bernd67 im Forum Feldbusse
    Antworten: 1
    Letzter Beitrag: 20.09.2007, 13:29
  5. Problem mit einem CP342-5DA02
    Von Anonymous im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 24.02.2005, 13:47

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •