Step 7 PUT/GET - Problem

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Liebe Freunde,
ich hatte heute an einer Anlage eine Störung, die ich bis jetzt nicht mal annähernd verstehe.

Ausgangspunkt:
Es gibt 3 Stk. exakt gleiche 315-2DP Steuerungen für je eine Verdichtersteuerung.
Jede davon hat 2 Stk. CP 343-1EX30- einen für die Ankopplung an S7-400#1 (PCS7) einen für die Ankopplung an S7-400#2 (PCS7).

Die Kommunikation erfolgt mittels je 2 DBs (Senden/Empfangen).

Alle 3 CP343-1 für S7-400#1 hängen an Switch1 (Scalance 204-2 mit LWL), alle 3 CP341 für S7-400#2 hängen an Switch2
Vom Switch1 geht es mittels CU-Patchkabel zu einem anderen Switch (Bestandteil eines LWL-Ringes Anlage1), Switch2 ist mittels LWL an einen vierten Switch angeschlossen der mittels Cu-Patch Kabel ebenfalls Bestandteil eines anderen LWL- Ringes ist- Anlage2.

Die drei Verdichtersteuerungen sind in dieser Art seit 1,5Jahren in Betrieb und absolut sorgenfrei.

Durch Unachtsamkeit haben wir kurz die Versorgungsspannung der beiden Switche 1+2 ausgeschaltet.

Das Ergebnis war:
Alle 3 Steuerungen konnten mit S7-400#1 weiterkommunizieren, und keine mehr mit S7-400#2.
Nicht kommunizieren heisst: Die Daten, die eigentlich alle 2 Sekunden geputted und gegetted werden kamen nur mehr im ~40-60s Takt an (PUT und GET).

An den PUT-Bausteinen war Error stets 0, aber Status sehr oft W#16B.
Laut Handbuch heisst das:
Warnung:
- Neuer Auftrag ist unwirksam, da vorangegangener Auftrag noch nicht
abgeschlossen ist.
- Der Auftrag wird bereits in einer Prioritätsklasse mit niedrigerer Priorität
bearbeitet.

Wir haben probiert (leider alles mühsam weil Anlagen nur schwer abschaltbar sind):
CU-Patch Kabel am CP abziehen anstecken
CP stoppen/starten mit PG
CP Spannung aus/ein (läuft nicht mehr an)
CPU stoppen/starten

alles ohne Erfolg, die Verbindungen in NETPRO bleiben immer aufgebaut.

Nur Spannung aus und ein löst das Problem- und zwar konkret für die eine Steuerung die neu aus/eingeschaltet wird- eine nach der anderen- dann geht wieder alles wie eh und je.

Der Fehler ist reproduzierbar (wenn mich die Maschinisten jemals wieder dort hin lassen)- ich habe es einmal getestet am anderen Ende der LWL-Strecke habe ich den anderen Switch neugestartet- Ergebnis war das gleiche.

Die Datenmenge ist pro Steuerung 60 Byte- also marginal.

Hat wer eine phantastische Idee was uns da heute einen Streich gespielt hat (und wieder spielen wird- wenn Switch ausfällt)

Gruß
Karl

 

[Thomas_v2.1]

Wie werden die Put/Get-Bausteine angestoßen? Werden die Status-Ausgänge Error/Done dafür ausgewertet?
Eine feste Flanke z.B. 2s Trigger ohne Auswertung der Statusbits könnte zu solchen Problemen führen.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, werden nicht... ursprünglich dachte ich, dass bei 2s das nicht notwendig ist, Trigger ist 2s.
Warum meinst Du dass das zu #1 geht, zu #2 aber nicht? Du schreibst das ja nicht ohne Grund wie ich Dich kenne.
;-)

 

[Thomas_v2.1]

Die Bausteindokumentation gibt das so vor, dass er nur angestoßen werden darf wenn der vorige Auftrag beendet wurde. Daran würde ich mich erstmal halten. Wie das intern funktioniert weiß ich auch nicht, so wie es aussieht fängt die CPU bzw. der CP ein mehrfaches antriggern nicht ab.

Ich habe das bei jemand anderem schonmal nur mit einem Trigger gesehen, und da gab es auch ähnliche Probleme. Ich habe gesagt, werte die Statusbits aus, und dann war es stabil.

 

[Thomas_v2.1]

Ich habe noch nicht geprüft, wann die Put oder Get Funktion Erfolg meldet. Ob es reicht wenn die Daten erfolgreich an den CP übergeben wurden, oder ob auf Protokollebene ein Antworttelegramm des Partners eingetroffen sein muss der diesen mit Erfolg oder Fehler bestätigt. Ich nehme an zweites, denn wenn auf einen nicht vorhandenen Datenbereich zugegriffen werden soll, dann gibt es schließlich auch einen Fehler am Ausgang.
Und dann gibst du mit der festen 2s Flanke dem Baustein einen neuen Auftrag, obwohl er den alten noch nicht abgeschlossen hat. D.h. kein Erfolg, kein Fehler, und noch kein Timeout abgelaufen der kennzeichnet, dass die Verbindung abgebrochen ist.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke Tom!

Nun, wir werden das ausprobieren, ich glaube nicht sehr fest daran, dass etwas das 14 Mio mal funktioniert (1,5 Jahre alle 2s) auf einmal durch einen Switch-Ausfall aufhört, und sich nicht wieder einrenkt.

 

[Blockmove]

Ich kenn dieses Verhalten beim CP343 auch.
Der CP hat einen internen Auftragspuffer und wenn der voll ist , dann tritt dieses Verhalten auf.
Es gibt keine Garantie, dass sich das wieder fängt wenn die Verbindung wieder steht.
Deshalb immer die Statusanzeigen auswerten
Gruß
Dieter

 

[Stoni34]

Hallo Karl,
wir hatten bei uns im Oktober letzten Jahres ein ähnliches Problem an einer unseren Anlagen.
Dort haben wir auch über Put und Get über die Ethernetschnittstelle der CPU und einem nachgeschalteten Scalance X204-2 kommuniziert.
Auch bei uns lief 1,5 Jahre alles ohne Probleme, bis es zu ersten Problemen kam.
Erst einmal und dann später mehrmals, bis gar nichts mehr ging.
Bei uns lag es auch nicht an der Programmierung der Put/ Get Funktion, sondern am Scalance.
Der hatte Verbindungsabbrüche auf dem Lichtwellenleiter, die wir erst über das Web Based Management System des Scalance herausfinden konnten.
Dort mussten wir, nach Rücksprache mit dem Siemens Support, unter Statistics Packet Error den Wert CRC auslesen, der Telegramme mit richtiger Länge aber fehlerhafter Prüfsumme anzeigt.
Wenn ordnungsgemäß funktioniert sollte dort keine, bzw. eine kleine Zahl stehen.
Bei uns stand eine sehr hohe Zahl drin. Nach Auskunft vom Siemens Support lässt das auf eine fehlerhafte LWL Verbindung schließen.
In unserem Fall war dann der Scalance defekt. Nach Tausch des selben funktionierte wieder alles einwandfrei.
Vielleicht hilft das Dir bei deinem Problem.
Markus

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Rückmeldung, nachdem ich das nun umgebaut habe:
es ist genauso wie Thomas und Dieter das vorhergesagt haben.
Neuer Anstoss erst nach "Done" oder "Error".

Nochmals besten Dank.