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

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 22

Thema: Daten in Ethernet-Verbindung springen

  1. #1
    Registriert seit
    09.09.2015
    Beiträge
    11
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen,
    Ich habe ein Problem mit einer TCP/IP Verbindung zwischen einer S7 315-DP und einem Simatic-TDC. Ich habe mit einem Kollegen die Verbindung eingerichtet und diese steht auch, d.h. keine CP meldet einen Fehler.

    Wir haben das Telegramm parametriert, sprich auf beiden Seiten kommen erst 3 REAL-Werte, danach 3 DINT usw. Wenn ich jetzt auf einer Seite einen Wert z.B. auf den ersten REAL schreibe, kommt auf der anderen Seite zwar etwas an, allerdings springen die Werte im kompletten Datenbereich hin und her. Normalerweise müssten auf der anderen Seite auch im ersten REAL-Wert der geschriebene Wert erscheinen.
    Hat jemand eine Idee, was die Ursache dafür ist?
    Bin für jede Hilfe dankbar.

    Gruß Micha
    Geändert von Micha1982 (09.09.2015 um 15:31 Uhr)
    Zitieren Zitieren Daten in Ethernet-Verbindung springen  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Beim Empfänger muß die gleiche Telegrammlänge wie beim Sender parametriert werden (an den SEND- und RECEIVE-Bausteinen).

    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:

    Micha1982 (10.09.2015)

  4. #3
    Micha1982 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    09.09.2015
    Beiträge
    11
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ja, das ist auch so. 47 Byte und gleicher Aufbau sprich Reihenfolge der verschiedenen Datentypen.
    Geändert von Micha1982 (10.09.2015 um 13:19 Uhr)

  5. #4
    Registriert seit
    09.09.2015
    Beiträge
    9
    Danke
    6
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Kann es vielleicht sein das du beim senden das done nicht abwartest und so zwei Packete abgesetzt werden die als eines auf der anderen Seite erkannt werden?

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

    Micha1982 (10.09.2015)

  7. #5
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von Micha1982 Beitrag anzeigen
    Ja, das ist auch so. 47 Byte und gleicher Aufbau sprich Reihenfolge der verschiedenen Datentypen.
    Der Sender sendet sicher immer genau 47 Byte? Falls der Sender mit AG_SEND sendet: die Telegrammlänge muß am Eingang LEN angegeben werden.

    Du empfängst mit der 315 und einem CP343-1?
    Der am AG_RECV an RECV angegebene ANY hat eine Zugriffsbreite von 47 Byte (z.B. "P#DB1.DBX0.0 BYTE 47")? Die Zugriffsbreite = Puffergröße muß exakt der Telegrammlänge entsprechen.

    Bei TCP werden die Empfangsdaten als Stream behandelt und der CP liefert immer die mit dem ANY angegebene Anzahl Bytes aus seinem Empfangspuffer, und wartet dafür ggf. solange, bis mindestens soviele Byte empfangen wurden. Dabei findet keine Synchronisation auf den Telegrammanfang statt, die Daten können aus verschiedenen Telegrammen stammen.

    Es ist dringend zu empfehlen, in die Telegramme Strukturzeichen (z.B. STX, ETX) und eine CRC-Prüfsumme einzubauen, damit das Empfangsprogramm sich ggf. auf den Telegrammanfang im Stream synchronisieren kann (z.B. durch Variation der Anzahl der mit AG_RECV vom CP abgeforderten Bytes) oder das emfangene Telegramm aus mehreren im RECV-Buffer verschoben liegenden Empfangsdaten-Teilen rekonstruieren kann.

    Besser: das ISO-on-TCP-Protokoll benutzen (wenn der Partner das auch kann). ISO-on-TCP ist paketorientiert und der CP synchronisiert auf die Telegrammanfänge.

    Welche Eigenschaften, Vorteile und Besonderheiten bietet das TCP-Protokoll?
    Welche Eigenschaften, Vorteile und Besonderheiten bietet das ISO-on-TCP-Protokoll?

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

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

    Micha1982 (10.09.2015)

  9. #6
    Registriert seit
    22.01.2009
    Beiträge
    288
    Danke
    61
    Erhielt 32 Danke für 25 Beiträge

    Standard

    Hallo,
    habt Ihr nach der Inbetriebnahme die Telegrammlänge mal verändert?
    Wenn ja, bitte beide Teilnehmer einmal neu starten, sonst wird diese Änderung nicht übernommen.

    Gruß
    Klaus

  10. Folgender Benutzer sagt Danke zu Klärmolch für den nützlichen Beitrag:

    Micha1982 (10.09.2015)

  11. #7
    Micha1982 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    09.09.2015
    Beiträge
    11
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zitat Zitat von IAmDonaldDuck Beitrag anzeigen
    Kann es vielleicht sein das du beim senden das done nicht abwartest und so zwei Packete abgesetzt werden die als eines auf der anderen Seite erkannt werden?
    Laut Beschreibung des FC5, wird kein neuer Auftrag angenommen, solange Done noch auf Null ist. D.H. es interessiert ihn ja nicht, ob an ACT eine Eins oder Null ansteht.

  12. #8
    Micha1982 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    09.09.2015
    Beiträge
    11
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zitat Zitat von Klärmolch Beitrag anzeigen
    Hallo,
    habt Ihr nach der Inbetriebnahme die Telegrammlänge mal verändert?
    Wenn ja, bitte beide Teilnehmer einmal neu starten, sonst wird diese Änderung nicht übernommen.

    Gruß
    Klaus

    Nein, ist von Anfang an auf 48 Byte.

  13. #9
    Micha1982 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    09.09.2015
    Beiträge
    11
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Schon mal Danke an alle für eure Antworten!

    Zitat Zitat von PN/DP Beitrag anzeigen
    Der Sender sendet sicher immer genau 47 Byte? Falls der Sender mit AG_SEND sendet: die Telegrammlänge muß am Eingang LEN angegeben werden.

    Du empfängst mit der 315 und einem CP343-1?
    Der am AG_RECV an RECV angegebene ANY hat eine Zugriffsbreite von 47 Byte (z.B. "P#DB1.DBX0.0 BYTE 47")? Die Zugriffsbreite = Puffergröße muß exakt der Telegrammlänge entsprechen.

    Bei TCP werden die Empfangsdaten als Stream behandelt und der CP liefert immer die mit dem ANY angegebene Anzahl Bytes aus seinem Empfangspuffer, und wartet dafür ggf. solange, bis mindestens soviele Byte empfangen wurden. Dabei findet keine Synchronisation auf den Telegrammanfang statt, die Daten können aus verschiedenen Telegrammen stammen.

    Es ist dringend zu empfehlen, in die Telegramme Strukturzeichen (z.B. STX, ETX) und eine CRC-Prüfsumme einzubauen, damit das Empfangsprogramm sich ggf. auf den Telegrammanfang im Stream synchronisieren kann (z.B. durch Variation der Anzahl der mit AG_RECV vom CP abgeforderten Bytes) oder das emfangene Telegramm aus mehreren im RECV-Buffer verschoben liegenden Empfangsdaten-Teilen rekonstruieren kann.

    Besser: das ISO-on-TCP-Protokoll benutzen (wenn der Partner das auch kann). ISO-on-TCP ist paketorientiert und der CP synchronisiert auf die Telegrammanfänge.

    Welche Eigenschaften, Vorteile und Besonderheiten bietet das TCP-Protokoll?
    Welche Eigenschaften, Vorteile und Besonderheiten bietet das ISO-on-TCP-Protokoll?

    Harald
    1. Ja, ich sende immer genau 48 Byte(siehe Edit oben).

    2. Ja, ich sende und empfange mit der 315 und dem CP343-1.

    3. Die Zugriffsbreite am Anypointer und auch am LEN-Anschluss sind 48 Byte. Am Empfangsbaustein sehe ich ja auch an LEN, dass 48 Byte ankommen. Weder der Sende- noch der Empfangsbaustein melden einen Fehler.

    4. Das mit den Strukturzeichen geht mir leider zu tief rein. Da bin ich zu unerfahren/unwissend.

    5. Ein anderes Protokoll geht leider auch nicht, da das Simatic-TDC eine Walzstraße steuert und nur im Stillstand neu geladen werden kann.

    Ein anderer Ansatz, die beiden Steuerungen hängen in unterschiedlichen Netzen, d.h. da hängt ein Router zwischen, könnte es sein, dass dort meine Daten durcheinander geworfen werden? Das Problem haben wir nämlich auf beiden Seiten.

  14. #10
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Micha1982 Beitrag anzeigen
    Am Empfangsbaustein sehe ich ja auch an LEN, dass 48 Byte ankommen.
    Das hat nichts mit der Länge des empfangenen Telegramms zu tun, sondern sagt lediglich, daß aus dem Empfangspuffer des CP 48 Byte in den RECV-Puffer kopiert wurden.

    Die ANY-Pointer an AG_SEND.SEND und AG_RECV.RECV sind das Konstanten (P#DB...) oder werden die zusammengebastelt oder über Bausteinparameter übergeben? AG_SEND.LEN ist eine Konstante (48)? Sind ggf. beteiligte IDB aktuell und Baustein-konsistent?
    Packt der Sender die Daten immer richtig in das Sendetelegramm oder sind da vielleicht Bugs (z.B. Fehler bei indirekter Adressierung)? Ruft der Sender vielleicht mehrere AG_SEND-Instanzen auf? Könnt Ihr zum Test mal fortlaufend ein konstantes Telegramm senden?

    Wenn immer 48 Byte von 48 Byte langen Telegrammen geholten werden, dann kann die Lage der Telegramm-Bytes in dem RECV-Buffer nicht "springen" (sprich: mal am Anfang und mal an anderer Stelle des RECV-Buffers liegen). Oder haben wir Dich falsch verstanden?

    Magst Du vielleicht etwas Code von den Bausteinaufrufen AG_SEND/AG_RECV zeigen?


    4. Das mit den Strukturzeichen geht mir leider zu tief rein. Da bin ich zu unerfahren/unwissend.
    Strukturzeichen: Du solltest das Datentelegramm mit einem Telegrammrahmen strukturieren, d.h. am Telegrammanfang und am Telegrammende markante Steuerzeichen (Flags) zufügen, welche idealerweise in dem Telegramm nie vorkommen. Da Du vermutlich Werte direkt in der vorliegenden binären Codierung sendest, können alle möglichen Zeichen vorkommen und man benötigt noch eine Prüfsumme um Verwechslungen mit dem Telegrammrahmen zu vermeiden. Der Empfänger muß prüfen, ob der Telegrammrahmen und die CRC korrekt sind - nur dann dürfen die Nutzdaten ausgewertet werden.
    Telegrammaufbau/struktur z.B.: STX <Daten> <CRC> ETX


    5. Ein anderes Protokoll geht leider auch nicht, da das Simatic-TDC eine Walzstraße steuert und nur im Stillstand neu geladen werden kann.
    Simatic-TDC kenne ich nicht, doch bei der S7-300 kann die Verbindungsprojektierung ohne CPU-STOP in RUN geladen werden (NetPro: Zielsystem > Laden im aktuellen Projekt > Verbindungen und Netzübergänge).


    die beiden Steuerungen hängen in unterschiedlichen Netzen, d.h. da hängt ein Router zwischen, könnte es sein, dass dort meine Daten durcheinander geworfen werden? Das Problem haben wir nämlich auf beiden Seiten.
    Das ist eher sehr unwahrscheinlich.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

Ähnliche Themen

  1. [OMRON] Daten auslesen via Ethernet
    Von tooony im Forum Sonstige Steuerungen
    Antworten: 4
    Letzter Beitrag: 11.11.2013, 10:01
  2. S7-1200 Daten via Ethernet auslesen.
    Von Darion im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 01.10.2012, 14:24
  3. Daten per Ethernet zw. 2 Steurungen übertragen.
    Von Jochen Kühner im Forum Simatic
    Antworten: 15
    Letzter Beitrag: 29.09.2006, 11:44
  4. Daten von S7 zu Office -> Ethernet
    Von M-Arens im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 03.05.2006, 12:21
  5. SPS-Daten via Ethernet in Access
    Von dborn im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 11.08.2004, 13:12

Lesezeichen

Berechtigungen

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