Step 7 CP343-1 lean

[JuPi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe ein Netz mit 7 CPU's die jeweils über einen CP343-1 lean miteinander verbunden sind. 1 CPU ist der "Chef". Diese kommuniziert mit allen anderen CP über TCP Verbindungen. 5 dieser Verbindungen funtkionieren tadellos. Ein Verbindung hat irgendwie einen Treffer weg. Es werden 100 Byte daten in beide Richtungen ausgetauscht. Diese kommen auch richtig an den beiden CP's an (mit Wireshark kontrolliert). In den Empfangsdaten einer Station verschieben sich in jedem 32.ten Byte die Daten um 2 Bit. Hat jemand von euch das schon mal gehabt.

 

[tyrael89]

Guten Morgen,

Hast du deine Hardwarekonfiguration überprüft? Hast du deine Kommuikationsbausteine geprüft? Senden und Empfangen?
gibt es dort vllt Programmteile die Dinge überschreiben?

 

[JuPi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja. Hab ich alles gemacht. So ca. 297 mal. Ich bin ja schon an dem Punkt, wo ich den Wald vor lauter Bäumen nicht mehr sehe. Kann man irgendwo sehen, welche Daten der CP über den Rückwandbus in die CPU schickt?

 

[PN/DP]

In den Empfangsdaten einer Station verschieben sich in jedem 32.ten Byte die Daten um 2 Bit.

Bist du sicher "2 Bit"? Sowas habe ich noch nie erlebt. Kann das ein Fehler in der Verarbeitung der Daten im SPS-Programm sein?
Was für Verbindungen sind das? TCP oder ISO-on-TCP?
Wäre es nicht einfacher und sicherer, anstatt eigenem TCP-Protokoll PROFINET IO zu verwenden?

 

[tyrael89]

Du hast die Informationen im DB statisch drin stehen ohne eine Veränderung? Und genau diese kommen mit einem Fehler auf der Ziel CPU in dem eignen DB fehlerhaft an?

 

[JuPi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im ersten Wort verschiebt sich der Empfang um 2 Bit. Totsicher. Dann passt wieder alles bis ins Wort 17. Hier das gleiche, wieder 2 Bit. Geht dann so weiter bis meine 100 Byte übertragen sind.
Im zweiten Wort bis zum 16. Wort ist alles gut. Ich habe mir helfen könne in dem ich die Daten die ich übertrage halt dann in den Bytes reinschreibe die gut sind und die kaputt übertragen werden nicht benutzte. Aber es triggert mich.
P.S. Ist nicht die erste Kommunikation die ich über TCP einrichte. Aber sowas hab ich in 20 Jahren auch noch nicht gesehen.

Support von Siemens ist kontakiert. Erste Anwort war, ich soll mal das MPI Kabel abziehen, das zum Panel geht, vielleicht liegt es daran.

 

[JuPi]

@tyrael89 : Jawoll. Ich schicke auf byte 0 eine 1 los. Die kommt über das Ethernetkabel auch am Ziel CP so an (mit Wireshark geprüft) und im DB in der Zielstation steht da plötzlich eine 4. Verrückte Welt.

 

[JuPi]

Konsistenz usw können wir alles ausschließen

 

[tyrael89]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hört sich auf jeden Fall sehr interessant an, deswegen vllt auch der Ansatz das ganze zu versuchen zu isolieren.

Ggf vll auch nochmal alles neu zu übertragen und die Verbindung damit zwingen neu zu starten?

Ist der Ziel DB und empfnags DB gleich aufgebaut im Nutzdaten Bereich?

 

[PN/DP]

Welche Bausteinversion haben deine FC AG_SEND und AG_RECV? V4.2 und V4.7 wären aktuell. Sind die FC aus der Bausteinfamilie CP_300?
Hast bei der betreffenden Station mal testweise den CP getauscht?

 

[renno]

Gelöscht

 

[JuPi]

Zuviel Werbung?
-> Hier kostenlos registrieren

AG_Send ist 4.2, AG_Recv ist 4.7.
Die Bautein sind aus dem CP Container, ja. Ist so ein Fehler der immer wieder mal passiert

Hab schon den CP getauscht durch einen anderen und auch die CPU? Da die alle über den Rückwandbuss miteinander sprechen habe ich auch alle Verbinder hinten mal getauscht.

 

[JuPi]

Nein, keine Strings

 

[Blockmove]

Die Verbindungsanzahl in den CPU-Einstellungen der Master-CPU passt?
Ich vermute mal, dass der Hinweis der Siemens Hotline auch in die Richtung ging.
Die CPUs haben eine begrenzte Anzahl an gleichzeitigen Verbindungen.

Eine andere Möglichkeit ist noch das Thema Firmware und Bausteinversionen das @PN/DP angesprochen hat.

 

[JuPi]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der Zentrale habe ich eine 317-2DP. Die hat 32 Verbindungsresouren. Das komische ist ja, dass die Daten richtig am CP ankommen.

Zentrale --> Außenstation --> 100 Byte, in jedem 32. Byte 2 Bit Verschiebung
Außenstation --> Zentrale --> 100 Byte, passt alles.

 

[Blockmove]

In der Zentrale habe ich eine 317-2DP. Die hat 32 Verbindungsresouren. Das komische ist ja, dass die Daten richtig am CP ankommen.

Und was ist in der CPU eingestellt?

 

[JuPi]

Verbindungs-Ressourcen reserviert für
PG Kommunikation 1
OP Kommunikation 1
S7-Basis Kommunikation 12
S7 Kommunikaiton 1 (bereits projektiert)

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn sich die Verbindungen in NetPro projektieren lassen, dann sollte auch die Anzahl gleichzeitiger Verbindungen kein Problem sein. Außerdem sollten das keine CPU Ressourcen sein, sondern Verbindungen des CP.

Ich denke, der Hinweis vom Siemens Support bezieht sich wohl eher darauf, dass bei S7-300 der MPI vom Rückwandbus mit dem externen MPI der CPU verbunden ist und durch Geräte am externen MPI der Rückwandbus-MPI gestört werden kann. (da könnte man den internen MPI-Verkehr mitsniffern)
Wobei ich gerade nicht weiß, ob AG_SEND/AG_RECV überhaupt per MPI mit dem CP 343-1 kommunizieren, es wäre auch denkbar, dass da mit normalem Peripherie-Transfer gearbeitet wird.

 

[JuPi]

Der Siemens Mann hat gesagt, dass es über den Rückwand-Bus geht. Und MPI ist nicht anderes als der "verlängerte" Rückwandbus. Deshalb sollte ich es mal abziehn. Hab aber nix verändert.

 

[PN/DP]

Verbindungs-Ressourcen reserviert für
(...)
(...)
S7-Basis Kommunikation 12

Wird da wirklich auch S7-Basis Kommunikation verwendet (XPUT, XGET, ...)? Oft sind da unnötig viele Verbindungen reserviert für S7-Basis Kommunikation, die überhaupt nicht verwendet wird.