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

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

Thema: TCP/IP 343 LEAN Übertragene Daten nicht in der Richtigen abfolge

  1. #1
    Registriert seit
    19.02.2010
    Beiträge
    33
    Danke
    6
    Erhielt 3 Danke für 2 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ich habe die Komunikation zwischen dem LMS 100 von Sick und der CPU 315 2dp mit CP343-Lean am laufen. Senden und Empfangen von Telegrammen Funktioniert.
    Ich habe jetzt nur das Problem das die Daten sich in der Datenbank mit jedem Senden und Empfangen verschieben.
    Ich nutze zur zeit das Beispiel von der Siemens Seite mit FC5 und FC6 und dem FB200
    http://support.automation.siemens.co...odeid=29512338

    Aussehn sollte es so im DB201
    Siehe 2ter Beitrag



    Bei den Kurzen Telegrammen ist das nicht so ein grosses Problem.Könnte mir ja die 02 und 03 im DB heraussuchen.02 Steht hier für Start des Telegrammes 03 für Ende des Telegramms.
    Aber ich bekomme auch Daten mit einer Länge von ca 3000 Byte übertragen und da möchte ich in der DB gerne bei Adresse 0.0 B#16#02 stehn haben.
    Hat jemand eine Idee woran es liegt das sich die Daten verschieben in der DB.
    Was mich auch wundert ist das ich bei RECV im FC6 nicht nur einen Datenbereich von 16 Byte (Beispiel oben) zur verfügung stellen muss sondern das es ehr 20 Byte sein müssen damit der FC6 keinen Fehler 80B1H Zielbereich ungültig ausgibt.

    Braucht ihr noch weitere Infos um mir Helfen zu können?
    Geändert von Björn (16.03.2010 um 11:23 Uhr)
    Zitieren Zitieren TCP/IP 343 LEAN Übertragene Daten nicht in der Richtigen abfolge  

  2. #2
    Björn ist offline Benutzer
    Themenstarter
    Registriert seit
    19.02.2010
    Beiträge
    33
    Danke
    6
    Erhielt 3 Danke für 2 Beiträge

    Standard

    Hm irgentwie klappt das mit der Datenbank als Tabelle nicht
    So sollte es aussehn:
    0,0 B # 16 # 2
    1,0 B # 16 # 73
    2,0 B # 16 # 52
    3,0 B # 16 # 41
    4,0 B # 16 # 20
    5,0 B # 16 # 4C
    6,0 B # 16 # 43
    7,0 B # 16 # 4D
    8,0 B # 16 # 73
    9,0 B # 16 # 74
    10,0 B # 16 # 61
    11,0 B # 16 # 74
    12,0 B # 16 # 65
    13,0 B # 16 # 20
    14,0 B # 16 # 30
    15,0 B # 16 # 3

    Beispiel wie es zum Teil Aussieht
    0,0 B # 16 # 4C
    1,0 B # 16 # 43
    2,0 B # 16 # 4D
    3,0 B # 16 # 73
    4,0 B # 16 # 74
    5,0 B # 16 # 61
    6,0 B # 16 # 74
    7,0 B # 16 # 65
    8,0 B # 16 # 20
    9,0 B # 16 # 30
    10,0 B # 16 # 30
    11,0 B # 16 # 3
    12,0 B # 16 # 2
    13,0 B # 16 # 73
    14,0 B # 16 # 52
    15,0 B # 16 # 20

  3. #3
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.263
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    Ist schon eine ganze Weile her, ich glaube mich zu erinnern, daß es mit der am Receive-FC angegebenen Länge zusammenhängt. Es wird immer dort weitergeschrieben, wo das letzte Telegramm aufhörte, wenn die Länge noch nicht erreicht war. Ist die Länge erreicht, dann wird wieder am Anfang des Receive-Datenbereiches weitergemacht. Weißt du die ankommende Telegrammlänge im voraus?
    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

  4. #4
    Registriert seit
    27.08.2003
    Ort
    Schweitenkirchen
    Beiträge
    472
    Danke
    101
    Erhielt 73 Danke für 59 Beiträge

    Standard

    Ist in der CP der Haken für mehr als 240Byte Telegrammlänge gesetzt?

    Es gibt auch noch die Long Recv und Long Send Bausteine in der Bibliothek (FC50/60 Lrecv Lsend).

    Gruss Andi
    Wenn ich einen meiner Finger in eines deiner Nasenlöcher stecke, haben wir beide nen Finger in der Nase

  5. #5
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    It hatte eine ähnliches Problem, aber zwar mit TCON, TSEND usw. über den integrierte PN Schnittstelle.

    Es wurde erst behoben indem das den Telegram-Länge genau angepasst wurde mit die Nutzdaten, UND nach eine Firmware Update auf den CPU.
    Jesper M. Pedersen

  6. #6
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Bei fester RECEIVE-Länge OHNE zusätzliche Massnahmen kann eine
    Verlust von Zeichen nur über eine Checksumme erkannt werden.
    Weiterhin entsteht dabei aber eine dauerhafter Telegrammversatz.
    Dieser kann nur mit den RESET, also dem Ablöschen des Buffers
    mittels Reset-Eingang bekoben werden.


    Da gibt es aber zwei Möglichkeiten:

    1. zu Empfangene Länge auf 1 setzen

    Nachteil 12 Zeichen brauchen leider 12 SPS-Zyklen bis sie im Empfangs-DB sind.


    2. UDP mit Zeichenverzugszeit verwenden, Dann erhält man immer die Info wie lang der empfange Datenstrom war.
    Daher ist auch kein Aufsynchronisieren nötig.

    Nachteil: UPD-Pakete sind in Switchen in der Prio leider ganz unten und können verlohren gehen.

    Gruß

  7. #7
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von JesperMP Beitrag anzeigen
    It hatte eine ähnliches Problem, aber zwar mit TCON, TSEND usw. über den integrierte PN Schnittstelle.
    Bei PN kann man bei TCP die erwartete Länge auf NULL setzen.
    Dann gibt es keinen Versatz mehr in den Daten, sondern bei
    Telegrammverlust ist dann die empfangene Länge entsprechend
    kürzer, was man dann maskieren kann.
    Geändert von IBFS (16.03.2010 um 11:49 Uhr)

  8. Folgender Benutzer sagt Danke zu IBFS für den nützlichen Beitrag:

    JesperMP (16.03.2010)

  9. #8
    Björn ist offline Benutzer
    Themenstarter
    Registriert seit
    19.02.2010
    Beiträge
    33
    Danke
    6
    Erhielt 3 Danke für 2 Beiträge

    Standard

    Danke für die Schnellen Antworten.
    Das Problem ist das ich nicht immer weiss wie Lang die Datenblöcke sind.
    Bei den Kurzen Telegrammen zur Konfiguration weiss ich die Länge.
    Aber wenn ich die bei RECV einstelle habe ich immer einen Fehler.
    Kann es sein das immer noch der IP Header dazu kommt.Sind zum teile 3000 Byte aber auch schon mal 2899 Byte je nach dem was der LMS an Entferungen misst gibt er für die Entferung mal 3 Hexwerte und mal 4 Hexwerte raus.

  10. #9
    Björn ist offline Benutzer
    Themenstarter
    Registriert seit
    19.02.2010
    Beiträge
    33
    Danke
    6
    Erhielt 3 Danke für 2 Beiträge

    Standard

    Ich wollte auch UDP nutzen aber der Sickscanner unterstützt das leider noch nicht. Kommt wohl erst noch mit dem nächsten Firmwareupdate.

  11. #10
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von IBFS Beitrag anzeigen
    Bei PN kann man bei TCP die erwartete Länge auf NULL setzen.
    Dann gibt es keinen Versatz mehr in den Daten, sondern bei
    Telegrammverlust ist dann die empfangene Länge entsprechend
    kürzer, was man dann manskieren kann.
    Also, mit RCV_LEN erkennt man wie vile Bytes empfangen sind, und das muss man vergleichen mit was man erwarten ?

    Aus der online Hilfe:
    TCP / Ad-hoc mode
    The ad-hoc mode exists only with the TCP protocol variant. You set the ad-hoc mode by assigning 0 to the LEN parameter.
    The receive area is identical to the area formed by DATA. A maximum of 1472 bytes are received.
    Immediately after receiving a block of data, FB64 enters the data in the receive area and sets NDR to 1.
    Jesper M. Pedersen

Ähnliche Themen

  1. Antworten: 11
    Letzter Beitrag: 20.12.2010, 11:05
  2. Antworten: 4
    Letzter Beitrag: 09.10.2007, 15:11
  3. Auswahl der richtigen CPU
    Von dpd80 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 30.11.2006, 18:50
  4. SPS Frage zur richtigen anwenden
    Von Michael180877 im Forum Programmierstrategien
    Antworten: 3
    Letzter Beitrag: 02.06.2006, 08:42
  5. Antworten: 2
    Letzter Beitrag: 27.10.2005, 14:35

Lesezeichen

Berechtigungen

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