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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: TCP Kommunikation zu Laser

  1. #1
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    161
    Danke
    41
    Erhielt 16 Danke für 8 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,
    ich habe momentan mit der Kommunikation zu einem KBA Laser zu tun, die noch etwas Probleme macht.

    CPU: 1214C
    TIA Portal V13 Updt. 4

    Folgendes soll gemacht werden, an den Laser soll ein Zähler geschickt werden, ist kein Sendeauftrag
    Aktiv wird der Aktuelle Zähler stand gelesen. Dafür gibt es 2 Telegramme die ich Verschicke, eines zum
    Zähler schreiben (SPS sendet 17 Byte, Laser antwortet 9 Byte), eines zum Zähler lesen (SPS sendet 9 Byte, Laser antwortet 17 Byte).

    Die Kommunikation Wird über TCON, TSEND, TRCV und TDISCON. An den LEN eingängen stehen nullen damit
    die Bausteine mit der Variablen Telegrammlänge klar kommen.

    Die Ganze Kommunikation hatte soweit auch schon mal funktioniert, nur bekomme ich nun aus irgend einem
    Grund die Antwort Telegramm in 17 Byte länge (Laser sendet Zähler) rotiert. Soll heißen, normal sollte die Antwort so aussehen:

    |0x02|0x0E|0x92 0x00|0x03 0x00 0x00 0x00|0x00 0x00 0x00 0x00|0x00 0x00 0x00|0x00|0x03|


    Stattdessen bekomme ich aber:
    |0x00 0x00|0x00 0x00 0x00|0x00|0x03|0x02|0x0E|0x92 0x00|0x03 0x00 0x00 0x00|0x00 0x00|


    Bei der 9 Byte Antwort rotieren die Bytes permanent durch den bereich.


    Ich bin Ratlos warum ich auf einmal dieses verhalten habe. Hatte schon mal jemand so ein verhalten bei einer Kommunmikation?



    Gruß

    Florian
    Zitieren Zitieren TCP Kommunikation zu Laser  

  2. #2
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    Es sieht so aus als wenn dein Eingabepuffer ein Ringpuffer ist - was bei serieller Kommunikation schon sinnvoll ist

    Ist dir klar das deine serielle Schnittstelle nicht immer alle Daten am Stück sendet - also nicht immer einer 17 Byte Block - sondern auch mal problemlos kleinere Happen mit 1-n Bytes
    bis deine 17 Bytes voll sind? geht du damit richtig um?

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

    plc_typ (11.12.2014)

  4. #3
    Avatar von plc_typ
    plc_typ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    161
    Danke
    41
    Erhielt 16 Danke für 8 Beiträge

    Standard

    Das die Daten nicht am Stück kommen können war mir nicht bewusst.

    Das 17 Byte Telegramm- Problem habe ich auch gelöst, ich suche in einer schleife den Telegramm Anfang und kopiere die Bereiche dann in der richtigen Reihenfolge um.
    Bei dem 9 Byte Block bin ich allerdings ratlos.

    Gruß
    Geändert von plc_typ (11.12.2014 um 06:33 Uhr) Grund: Rechtschreibfehler

  5. #4
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    sollte es ein Ringpuffer sein muss du irgendwo eine Anfang/Ende Kennung bekommen - die der Anfang oder das Ende deines Arrays kann auch dazwischen sein also z.B. von [15-2] also [15,16,17,0,1,2] usw.

    Beispiel:

    Code:
    |0x00 0x00|0x00 0x00 0x00|0x00|0x03|0x02|0x0E|0x92 0x00|0x03 0x00 0x00 0x00|0x00 0x00|
                                   ENDE ANFANG -> laeuft so bis ENDE durch

    kannst du mal die Protokoll-Doku fuer die 9 und 17 bytes hier einstellen - oder die relevanten Teile?
    häng dich mal mit http://www.hw-group.com/products/hercules/index_en.html (Freeware RS232-Tool) an den Laser und kommunizier mal von Hand - nur
    damit sicher ist das alles funktioniert
    Geändert von LowLevelMahn (11.12.2014 um 07:52 Uhr)

  6. Folgender Benutzer sagt Danke zu LowLevelMahn für den nützlichen Beitrag:

    plc_typ (11.12.2014)

  7. #5
    Avatar von plc_typ
    plc_typ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    161
    Danke
    41
    Erhielt 16 Danke für 8 Beiträge

    Standard

    Ok, habe die Kommunikation nun in Betrieb.

    Ich warte bei den Rotierenden Bytes darauf bis sie in der richtigen Reihenfolge sind, dann kopiere ich sie um. Das Tool hat mir auch geholfen um die Kommunikation zu
    testen, sehr Hilfreich!
    Ich verstehe nur nicht warum dieses verhalten anfangs nicht da war. als ich mit der Kommunikation begann waren die Telegramme Fix, dann ging es los mit sporadischen
    ausfällen.

    Danke für die Hilfe!

  8. #6
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    Ok, habe die Kommunikation nun in Betrieb.
    Ich warte bei den Rotierenden Bytes darauf bis sie in der richtigen Reihenfolge sind, dann kopiere ich sie um
    Hört sich aber stark nach Bastellösung an - so schwer ist serielle Kommunikation aber nicht d.h. du machst irgendwas falsch oder verarbeitest einfach falsch
    - und korrigierst das dann bis es wieder richtig ist - das kann dir später im Betrieb trotzdem in die Suppe spucken (Laser wieder mal ausgefallen usw. - alle paar Wochen)

    Ich verstehe nur nicht warum dieses verhalten anfangs nicht da war
    Kabel, PC, SPS gewechselt?, andere Schnittstellen-Einstellungen? kann alles dazu führen das du eher die wahre Natur der seriellen Kommunikation sehen kannst

    der Puffer muss einfach gross genug sein z.B. 100 Bytes oder so - dann gibt auch nicht so schnell einen Ring
    im Normalfall wartest du bis du die vollen 9, oder 17 Bytes empfangen hast - oder auf eine Ende-Kennung (falls im Prokotoll vorhanden) - das wars

  9. #7
    Avatar von plc_typ
    plc_typ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    161
    Danke
    41
    Erhielt 16 Danke für 8 Beiträge

    Standard

    Wie könnte ich es denn besser lösen?
    Momentan Schreibt mein TRCV auf einen 17 Byte langen Array, da das längste Telegramm welches ich erwarte eben die 17 Byte hat.

    In diesem Puffer Check ich dann nach Anfangs- (0x02) Endkennung (0x03) und der Auftragskennung (0x92), wenn all diese Bytes an der richtigen stelle
    sind kopiere ich die Daten in einen Puffer und setze ein Bit das sie Gültig sind.

  10. #8
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    soweit ich weiss heisst LEN=0 das er sofort beim Empfang von Daten zurueck kommt - mit RCV_LEN steht dann die wirklich gelesene Laenge (die <=17 sein kann) - wenn die noch nicht bei 17 ist muss du weiter auf Daten warten
    bei jedem Receive-Aufruf wird (soweit ich weiss) wieder bei 0 in den Puffer geschrieben d.h. folgendes kann passieren

    du Fragst den Laser und wartest dabei auf Antwort

    1. Receive:

    0x02 0x0E 0x92 0x00 0x03 0x00

    2. Receive:


    0x00 0x00 0x00 0x00 0x00 0x00 0x00

    3. Receive:


    0x00 0x00 0x00 0x03

    jetzt haben wie die 17 Bytes zusammen - es koennen auch mehr oder weniger Pakete sein (völlig Random)

    da ich deinen Ablauf nicht kennen und du auch keine Doku von dem Protokoll hier einstellst kann ich nur vermuten das du dir deinen Puffer ueberschreibst

    du koenntest deine LEN auch einfach auf 17 Stellen - du weisst ja welchen Befehl du an den Laser gesendet hast - und damit auch wie lange die Antwort wird oder (ohne Doku kann ichs aber nicht genau sagen)

  11. #9
    Avatar von plc_typ
    plc_typ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    161
    Danke
    41
    Erhielt 16 Danke für 8 Beiträge

  12. #10
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    wenn jemand was schreibt musst du den Inhalt bestätigen (weil schon getestet) oder sagen das er unverständlich ist - aber einfach nur auf Teile zu reagieren bringt nicht wirklich viel

    Überschreibst du dir deinen Puffer - wenn keine Ahnung dann musst du es testen

    bringt es was die LEN auf 17 zu stellen? - nur Testweise
    Geändert von LowLevelMahn (11.12.2014 um 15:13 Uhr)

Ähnliche Themen

  1. TCP/IP ASCII Kommunikation
    Von basstscho im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 18.05.2012, 21:35
  2. TCP-Kommunikation S7-PC
    Von jochenmueller77 im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 03.12.2010, 11:36
  3. Kommunikation TCP/IP --> Verbindungstabelle?
    Von steven im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 15.02.2008, 12:02
  4. TCP/IP Kommunikation unterbrechen
    Von BiBi im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 30.07.2007, 13:50
  5. S7 telegramme tcp kommunikation
    Von michdan im Forum Hochsprachen - OPC
    Antworten: 7
    Letzter Beitrag: 25.06.2007, 18:54

Lesezeichen

Berechtigungen

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