Step 7 Übertragungsverschiebungen von einer CPU zur andern

[benjamin0079]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe eine S7 417-4 mit einem CP443-1 und schicke 80 Byte über eine TCP verbindung an eine S7 414-3 mit einem CP443-1.
Gesendet wird mit dem FC5 AG_SEND und empfangen mit dem FC6 AG_RECV.
Das funktioniert nun schon seit Jahren problemlos. Da ich 9 weitere wörter benötige habe ich die Datenbausteine angepasst und die
Sende- und Empfangslänge auf 98 Byte angepasst und alle geänderten Bausteine übertragen.
Jetzt zum Problem: Mein erstes Byte fing nun mitten im Datenbaustein an. Wenn ich einen zu kurzen Sende- Oder Empfangsbereich
angebe verschiebt sich die Startadresse im Ziel Datenbaustein. Man kann ja immer nur einen programmstand nach dem anderen
übertragen und ich kann mir nicht erklären wie es dazu kommt und wie man es wieder in den Griff bekommt das nun das erste
Byte wieder am anfag des Datenbausteins geschrieben wird. Selbst das rückgängig machen aller änderungen haben nicht geholfen,
das erste Byte wird nach jeder änderung der Sende- oder Empfangslänge an einer andern Stelle geschrieben.

 

[borromeus]

Hast Du schon einen Neustart der CPU's probiert?

Und hast Du Länge und den Puffer angepasst?

 

[benjamin0079]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Länge und den Puffer habe ich angepasst und zig mal überprüft, habe auch einen Kollegen drüberschauen lassen, vier Augen sehen ja mehr als zwei.
Einen Neustart hab ich nicht probiert und kann ich auch nicht so ohne weiteres da beide Anlagen im Betrieb sind.

 

[spqr76]

Hallo ,
CP unter Spezialdiagnose einmal stoppen und starten . Erst dann werden die neuen Datenlängen übernommen.

 

[benjamin0079]

Danke, das werd ich probieren.
Reicht es dann den Empänger CP zu starten?

 

[spqr76]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo ,
wenn du auf beiden Seiten Änderungen vorgenommen hast dann beide Neustarten.

 

[benjamin0079]

Hängt das Problem vielleicht mit der Verbindung (TCP) zusammen, ich kann mich errinern das ich bei einer ISO-Verbindung schon die
Länge und diverses geändet habe ohne irgendtetwas neu zu starten.
Ich würde halt auch gern wissen warum es so ist.

 

[Thomas_v2.1]

Bei einer TCP-Übertragung gibt es im Gegensatz zu ISO keine Längenkennung der Daten. TCP ist ein Datenstrom.
Wenn du selber keine Längen- oder Anfangs/Endekennung eingebaut hast, dann passiert es dass wenn du auf einer Seite anfängst die Länge z.B. von 100 auf 104 Bytes änderst, und die Genenstelle weiterhin 100 Bytes liest, die "überschüssigen" 4 Bytes dann im Puffer landen. Beim nächsten Lesen von 100 Bytes hast du dann die 4 Bytes Versatz. Das bekommst du erst wieder gelöst, indem die internen Puffer komplett zurückgesetzt werden (oder Verbindung trennen und neu aufbauen, z.B. Netzwerkkabel ziehen).

 

[benjamin0079]

Zuviel Werbung?
-> Hier kostenlos registrieren

Super! Vielen Dank, das erklärt mir mein Problem.

 

[PN/DP]

Du kommunizierst mit 2 S7. Warum benutzt Du da überhaupt eine TCP-Verbindung? Bei TCP-Verbindungen muß man sich selbst einen Telegrammrahmen basteln und der Empfänger muß sich auf den Rahmen "aufsynchronisieren" können (mehr oder weniger Bytes aus dem Empfangspuffer des CP abholen). Nur weil eine TCP-Verbindung meist "auf Anhieb" funktioniert, heißt es nicht, daß da irgendeine Synchronisation automatisch stattfinden würde. TCP ist ein (unstrukturierter) Stream. Empfehlung: benutze eine ISO-on-TCP-Verbindung oder eine S7-Verbindung mit BSEND/BRCV.
Nachtrag: wird bei Deiner TCP-Verbindung irgendwie die Empfangsdatenintegrität geprüft?

Harald

 

[Thomas_v2.1]

Du kommunizierst mit 2 S7. Warum benutzt Du da überhaupt eine TCP-Verbindung? Bei TCP-Verbindungen muß man sich selbst einen Telegrammrahmen basteln und der Empfänger muß sich auf den Rahmen "aufsynchronisieren" können (mehr oder weniger Bytes aus dem Empfangspuffer des CP abholen).

Da muss nichts. Ein TCP-Datenaustausch mit fester Datenlänge funktioniert zuverlässig. Ein TCP-Telegramm kommt entweder vollständig und korrekt an, oder es wird verworfen. Wenn ein Teilnehmer sich nicht an die vereinbarten Kommunikationsdetails (in dem Fall fixe Länge) hält, dann gehts in die Hose. Das geht aber auch bei Iso-On-TCP in die Hose, wenn ich mich nicht an eine Vereinbarung halte.

 

[benjamin0079]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Harald,

das ganze lief mal über eine ISO-Transportverbindung und musste auf bestehen der IT umgestellt werden.
Ich hab gestern auch schon mal nach Alternativen geschaut, die ISO TCP-Verbindung werd ich mir noch mal genauer anschauen und beim nächsten Anlagenstillstand das ganze umsetzen.
Zu deinem Nachtrag, nein die Datenintegrität wird nicht geprüft. Das ganze läuft auch schon seit zwei Jahren mit fast 20 Verbindungen ohne Probleme.