Step 7 Daten in Ethernet-Verbindung springen

M

Micha1982

Level-1
Beiträge
11
Reaktionspunkte
0
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
 
Zuletzt bearbeitet:
Micha1982 schrieb:
Ja, das ist auch so. 47 Byte und gleicher Aufbau sprich Reihenfolge der verschiedenen Datentypen.
Zum Vergrößern anklicken....
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schon mal Danke an alle für eure Antworten!

PN/DP schrieb:
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
Zum Vergrößern anklicken....

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.
 
Micha1982 schrieb:
Am Empfangsbaustein sehe ich ja auch an LEN, dass 48 Byte ankommen.
Zum Vergrößern anklicken....
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. ;)
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
Das ist eher sehr unwahrscheinlich.

Harald
 
Ich würde auch stark vermuten, dass der PC mehr als 48 Byte sendet.
Sendet er z.Bsp. 50 Byte, dann werden 2 Byte wieder an den Anfang des Empfangsbereiches geschrieben. Der nächste Empfang geht dann beim 3. Byte los, 4 Byte am Anfang werden überschrieben und so weiter fort. Je nachdem, wie schnell das insgesamt geht sieht das dann wie wildes Springen aus. Oder noch schlimmer, es kommen mal 50 mal 53 Byte, dann "springt" es noch wilder. ;-)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
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.
Zum Vergrößern anklicken....

Ah, ok.

PN/DP schrieb:
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?
Zum Vergrößern anklicken....

AG_RECV.jpgAG_SEND.jpg
IDB sind nicht beteiligt, lediglich globale DB´s aus denen der Sendebaustein die Daten entnimmt, bzw. der Empfangsbaustein die Daten schreibt.
Ich habe auch nochmal mit dem FC10(AG_CNTRL) die Verbindungen überprüft, sind aber beide in Ordnung.

PN/DP schrieb:
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
Zum Vergrößern anklicken....

Aber sowas mache ich doch nicht in Step7, oder? Wie gesagt, ich lese da zu 50% Bahnhof, sorry. :(

PN/DP schrieb:
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).
Zum Vergrößern anklicken....

Beim TDC geht das leider nicht.
 
Zuletzt bearbeitet:
Ralle schrieb:
Ich würde auch stark vermuten, dass der PC mehr als 48 Byte sendet.
Zum Vergrößern anklicken....

Ist kein PC, sondern ebenfalls ein Automatisierung, die über CFC projektiert wird.

Ralle schrieb:
Sendet er z.Bsp. 50 Byte, dann werden 2 Byte wieder an den Anfang des Empfangsbereiches geschrieben. Der nächste Empfang geht dann beim 3. Byte los, 4 Byte am Anfang werden überschrieben und so weiter fort. Je nachdem, wie schnell das insgesamt geht sieht das dann wie wildes Springen aus. Oder noch schlimmer, es kommen mal 50 mal 53 Byte, dann "springt" es noch wilder. :wink:
Zum Vergrößern anklicken....

Klingt plausibel, allerdings haben wir die Datenlänge schon mehrfach auf beiden Seiten überprüft. Werde das aber morgen noch einmal machen. Die TDC-Seite habe nicht ich persönlich überprüft.
 
Man könnte den Datenverkehr mitschneiden, z.B. mit Wireshark.

Auf der S7-300 könntest Du zum Test in der Verbindungsprojektierung die Partner-IP/-Port zur IP/Port eines Test-Computers ändern, auf dem ein Terminal wie z.B. HyperTerm läuft.

Auf jeden Fall mache zuerst mal den Test mit konstanten Telegrammen.


Micha1982 schrieb:
PN/DP schrieb:
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
Zum Vergrößern anklicken....
Aber sowas mache ich doch nicht in Step7, oder?
Zum Vergrößern anklicken....
Doch! Die Anwendung (Datenendpunkt) muß die Integrität der empfangenen Daten prüfen. Der CP leitet nur den TCP-Datenstrom zur Anwendung.

Harald
 
Mit "konstantes Telegramm" meine ich ein Telegramm, dessen Inhalt nicht vom SPS-Programm verändert wird, auf dessen Speicherplatz das SPS-Programm nicht schreibt (um Programmierfehler auszuschließen).

- die Adresse des Sendedatenbereichs an AG_SEND.SEND als Konstante angeben, z.B. "P#DB63.DBX0.0 BYTE 48"
- mit der Variablentabelle den einzelnen Bytes des Sendedatenbereichs Werte zuweisen (*)
- Empfangsdatenbereich im Empfänger mit Variablentabelle beobachten

(*) z.B.: DB63.DBD0 = DW#16#01020304 ... DB63.DBD44 = DW#16#45464748

Harald
 
Schon mal Danke für deine Tipps.

PN/DP schrieb:
Mit "konstantes Telegramm" meine ich ein Telegramm, dessen Inhalt nicht vom SPS-Programm verändert wird, auf dessen Speicherplatz das SPS-Programm nicht schreibt (um Programmierfehler auszuschließen).

- die Adresse des Sendedatenbereichs an AG_SEND.SEND als Konstante angeben, z.B. "P#DB63.DBX0.0 BYTE 48"
- mit der Variablentabelle den einzelnen Bytes des Sendedatenbereichs Werte zuweisen (*)
- Empfangsdatenbereich im Empfänger mit Variablentabelle beobachten

(*) z.B.: DB63.DBD0 = DW#16#01020304 ... DB63.DBD44 = DW#16#45464748

Harald
Zum Vergrößern anklicken....


Genau das mach ich im Moment auch erst. Ich habe jetzt Kontakt mit dem Siemens Support aufgenommen.

Sein erster Tipp war eine neuere CPU zu verwenden, da meine nicht für den Betrieb mit dem CP343-1 freigegeben ist.

Ich habe jetzt eine CPU 318 eingebaut(vorher war es 315), leider besteht der Fehler immernoch. Mal schauen, was jetzt noch vom Support kommt.

Halt euch auf dem laufenden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Micha1982 schrieb:
Sein erster Tipp war eine neuere CPU zu verwenden, da meine nicht für den Betrieb mit dem CP343-1 freigegeben ist.
Zum Vergrößern anklicken....
Na dann klär uns doch mal auf, mit was für uralten Geräten Du operierst, vielleicht hat jemand von uns Deine Kombination.
- 6ES7 315-.............. Firmware V....
- 6GK7 343-.............. Firmware V....

Harald
 
Hi,

dieser Effekt ist bekannt, habe ich auch schon öfters erlebt.
Prüfe zunächst ob deine Send/Rec Bausteine aus der 300er-Familie stammen, nicht
das diese für die 400er CPU's gelten. (Baustein re. Maustaste Eigenschaften, dort erkennt man dies)

Dann die Parametrierung auf beiden Seiten überprüfen.
Auf beiden Seiten Netpro Zielsystem markierte Station laden und anschließend nochmal Verbindungen
und Netzübergänge laden (ganz wichtig). Dann CP's stoppen und starten und CPU's stoppen und starten.
Dann geht's wetten?;)
Gruß
Move
 

Similar threads

S
TIA S7-Get Verbindung per Programm ändern
Antworten
3
Aufrufe
557
Wincctia
W
F
Codesys 3.5 keine Verbindung zur Steuerung
Antworten
19
Aufrufe
3K
Thruser
T
Korniman
Gleitender Mittelwert für Batteriemessung mit ESP32 über OpenPLC realisieren
Antworten
6
Aufrufe
1K
Cassandra
Cassandra
S
TIA ET200S Fehler aber keine SF an
2 3
Antworten
45
Aufrufe
5K
PN/DP
PN/DP
E
TIA V18 - Siemens V90 verliert Ethernet-Einstellungen
Antworten
15
Aufrufe
2K
Eraser
E
Zurück
Oben