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

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

Thema: Cp343-1

  1. #1
    Registriert seit
    06.01.2005
    Ort
    im schönen Lipperland
    Beiträge
    4.678
    Danke
    549
    Erhielt 1.202 Danke für 776 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ich hab da mal wieder eine Frage an die Kommunikationsexperten.

    Ich habe eine CP343-1. Dieser soll über den FC5/FC6 Datenblöcke von 2048 Byte senden bzw. empfangen. Das Senden funktioniert ohne Fehlermeldung des Bausteines bzw. der Baustein meldet DONE.

    Jetzt behauptet der Empfänger das nur 2045 Byte ankommen. Ich kann das auf die schnelle nicht kontrollieren. Der CP343-1 ist in Belgien , der Empfänger in Österreich.

    Wenn ich das nächste Mal vor Ort bin werde ich mal meinen Laptop direkt an den CP hängen und mal schauen was da rauskommt.


    Aber würde es eine Erklärung für das "verschwinden" von 3 Bytes geben ? Wird an jeder Grenze ein Byte abgezogen ?


    Der Empfang von 2048 Byte klappt übrigens problemlos.
    Früher gab es Peitschen .... heute Terminkalender
    Zitieren Zitieren Cp343-1  

  2. #2
    Registriert seit
    23.06.2009
    Ort
    Sassnitz
    Beiträge
    12.770
    Danke
    1.042
    Erhielt 3.758 Danke für 3.035 Beiträge

    Standard

    Am AG_SEND: Ist der ANY-Pointer an SEND zu kurz? Ist an LEN tatsächlich 2048 angegeben?
    Woher weiß der Empfänger, daß es nur 2045 Byte sind? Verschiebt sich die Nachricht im Empfangspuffer oder meldet AG_RECV LEN=2045? Hat der überhaupt einen CP oder was ist das für ein Empfänger? Was für eine Verbindung ist das, TCP-, ISO-on-TCP-, ...?
    Ist/sind das halbwegs aktuelle CP343-1?

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Lipperlandstern (05.12.2018)

  4. #3
    Avatar von Lipperlandstern
    Lipperlandstern ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.01.2005
    Ort
    im schönen Lipperland
    Beiträge
    4.678
    Danke
    549
    Erhielt 1.202 Danke für 776 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Am AG_SEND: Ist der ANY-Pointer an SEND zu kurz? Ist an LEN tatsächlich 2048 angegeben?
    Woher weiß der Empfänger, daß es nur 2045 Byte sind? Verschiebt sich die Nachricht im Empfangspuffer oder meldet AG_RECV LEN=2045? Hat der überhaupt einen CP oder was ist das für ein Empfänger? Was für eine Verbindung ist das, TCP-, ISO-on-TCP-, ...?
    Ist/sind das halbwegs aktuelle CP343-1?

    Harald

    Any-Pointer und LEN sind 2048. Das habe ich zig Mal kontrolliert. Der Empfänger ist ein Datenbank. Also vermutlich irgendein PC. Auf die Länge sind sie mit Wireshark gekommen.

    Verbindung ist TCP und der CP ist neu.
    Früher gab es Peitschen .... heute Terminkalender

  5. #4
    Registriert seit
    29.03.2004
    Beiträge
    6.315
    Danke
    155
    Erhielt 1.886 Danke für 1.362 Beiträge

    Standard

    Bei TCP ist es nicht gesagt, dass die 2048 Bytes auch am Stück gelesen werden können. Wenn ihr eine feste Byteanzahl ausgemacht hat, muss er solange lesen bis er die Anzahl empfangen hat, und dann die Daten selber richtig hintereinander zusammensetzen. Das ist das "Problem" was bei TCP meistens überhaupt nicht beachtet wird, darum macht Iso-On-TCP so eine Kommunikation wesentlich einfacher.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

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

    Lipperlandstern (05.12.2018)

  7. #5
    Registriert seit
    20.06.2003
    Ort
    Sauerland.NRW.Deutschland
    Beiträge
    5.090
    Danke
    91
    Erhielt 853 Danke für 581 Beiträge

    Standard

    Soweit ich weiss werden pro tcp-paket maximal 1460 bytes übertragen.
    .
    mfg Volker .......... .. alles wird gut ..

    =>Meine Homepage .. direkt zum Download

    Meine Definition von TIA: Total Inakzeptable Applikation

  8. #6
    Avatar von Lipperlandstern
    Lipperlandstern ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.01.2005
    Ort
    im schönen Lipperland
    Beiträge
    4.678
    Danke
    549
    Erhielt 1.202 Danke für 776 Beiträge

    Standard

    Zitat Zitat von volker Beitrag anzeigen
    Soweit ich weiss werden pro tcp-paket maximal 1460 bytes übertragen.
    Wenn das so ist wären es ja nur 2 Pakete. Da sollten beim zusammensetzen keine 3 Bytes verschwinden.
    Früher gab es Peitschen .... heute Terminkalender

  9. #7
    Registriert seit
    20.06.2003
    Ort
    Sauerland.NRW.Deutschland
    Beiträge
    5.090
    Danke
    91
    Erhielt 853 Danke für 581 Beiträge

    Standard

    nein. verschwinden dürften die 3 bytes natürlich nicht. eigentlich sorgt das tcp-protokoll dafür das alle daten ankommen.
    Zitat Zitat von https://de.wikipedia.org/wiki/Transmission_Control_Protocol
    Beispiel einer TCP-/IP-Datenübertragung

    Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, sofern beide Seiten die TCP-Option SACK (Selective ACK) unterstützen. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer.
    https://de.wikipedia.org/wiki/Datei:Tcp_transfer.png
    .
    mfg Volker .......... .. alles wird gut ..

    =>Meine Homepage .. direkt zum Download

    Meine Definition von TIA: Total Inakzeptable Applikation

  10. #8
    Registriert seit
    29.03.2004
    Beiträge
    6.315
    Danke
    155
    Erhielt 1.886 Danke für 1.362 Beiträge

    Standard

    Wobei sich gerade bei einer VPN-Strecke (was ich hier mal vermute) die MTU unterwegs noch ändern kann, was dann zu einer Fragmentierung der Pakete führt.

    Beim AG_SEND für einen Ethernet-CP sagen dir die Statusausgänge der Funktion übrigens nicht, dass die Daten beim Empfänger angekommen sind, sondern nur dass die Daten zum Senden an den CP erfolgreich übergeben wurden. Ich hatte das bei einem CP für die 400er mal getestet: selbst wenn ich meinen eigenen Server nachdem schon mal Daten ausgetauscht wurden beendet habe, hat AG_SEND das Senden erfolgreich bestätigt. Im Hintergrund versucht der CP entsprechend nach Ablauf von Timeouts die Daten doch noch loszuwerden. Wenn das nach einer Anzahl Versuche (Retry-Limit, üblicherweise 3) nicht klappt, dann wird intern die Verbindung als abgebaut gekennzeichnet und versucht diese neu aufzubauen. Wenn du bei einem Ethernet-CP die Verbindung nur alle paar Minuten benutzt und nur sendest, dann bekommst du davon im SPS-Programm nichts mit. Du musst die dann die Spezialdiagnose des CPs ansehen, dort gibt es Zähler für erfolgreich/fehlerhaft gesendete Daten und einen eigenen Diagnosepuffer.

    Ich würde aber wenn möglich erstmal selber mit einer lokalen eigenen Anwendung als TCP-Server, ob dort wenigstens definitiv die gesendete Anzahl ankommt. Das mit den 3 Bytes ist schon seltsam.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  11. Folgender Benutzer sagt Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    DeltaMikeAir (06.12.2018)

  12. #9
    Registriert seit
    13.12.2008
    Beiträge
    27
    Danke
    0
    Erhielt 5 Danke für 5 Beiträge

    Standard

    Zitat Zitat von Lipperlandstern Beitrag anzeigen
    Verbindung ist TCP und der CP ist neu.
    aktuelle Bausteinrevisionen verwendet?
    mindestens
    AG_SEND V4.1 aktuell V4.2
    AG_RECV V4.6 aktuell V4.7

  13. Folgender Benutzer sagt Danke zu Strömling für den nützlichen Beitrag:

    Lipperlandstern (08.12.2018)

  14. #10
    Avatar von Lipperlandstern
    Lipperlandstern ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.01.2005
    Ort
    im schönen Lipperland
    Beiträge
    4.678
    Danke
    549
    Erhielt 1.202 Danke für 776 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Strömling Beitrag anzeigen
    aktuelle Bausteinrevisionen verwendet?
    mindestens
    AG_SEND V4.1 aktuell V4.2
    AG_RECV V4.6 aktuell V4.7

    Die Versionen sind aktuell. Ich vermute sehr stark das der Empfänger sind irgendwo verzählt hat. Ich werde mir bei nächster Gelegenheit einen TCP-Server direkt an den CP hängen und mal schauen was da rauskommt.
    Früher gab es Peitschen .... heute Terminkalender

Ähnliche Themen

  1. cp343-1 lean
    Von Markus Hoffmann im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 09.02.2017, 21:41
  2. Step 7 CP343-1 Advanced
    Von Thomas2012 im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 11.06.2013, 14:52
  3. CP343-1 LEAN vs. CP343-1 "normal"
    Von vladi im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 28.01.2008, 11:38
  4. CP343-1 Drigend
    Von titinparma im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 28.11.2007, 15:17
  5. Cp343-1
    Von untitle im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 07.03.2006, 17:41

Lesezeichen

Berechtigungen

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