CPU-Stop bei Zykluszeitüberschreitung

PeterK

Level-1
Beiträge
10
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Vielleicht hat jemand eine Idee.

Wir betreuen eine Anlage in Spanien, läuft ohne größere Probleme seit 3Jahren. Beim kürzlichen Balearenunwetter gab es einen Stromausfall und nach Wiederinbetriebnahme gibt es ein Problem mit der Zykluszeitüberschreitung.
Zum Aufbau - eingesetzt ist eine 315-2DP alle Antriebe werden über FU`s von SEW betrieben. Die FU`s hängen am Profibus. Eine Besonderheit besteht darin, das immer 2 FU`s über S-Bus verbunden sind die erste Steuert einen Bandantrieb und fungiert gleichzeitig als Gateway für den 2. FU der für eine Lüfter zuständig ist. Es existieren 7 identisch aufgebaute Stationen. Bei der Station 3 tritt jetzt nach ca 2min nach Einschalten und Hochlaufen des Lüfters eine Zykluszeitüberschreitung
von 620ms auf und die CPU geht in Stop. Ein Austausch der FU bzw ein Starten ohne Motorankopplung brachten kein Erfolg. Mir ist der Zusammenhang unklar, weil ja der FU nicht direkt am Profibus angekoppelt ist sondern wie gesagt nur mittelbar über diese S-Bus Verbindung. Solange dieser FU keine Freigabe erhält läuft das übrige System Fehlerfrei und die Zykluszeiten pendeln um die 20ms.

Ich freue mich über jeden noch so kleinen Hinweis.

Im vorraus schon mal einen großen Dank

PeterK
 
Zykluszeitüberschreitungen treten am häufigsten auf, weil ein Programm aus einer Schleife nicht mehr herauskommt, oder eine falsche Sprungmarke angesprungen wird. Zuerst würde ich mal nachsehen, wo genau das Programm stehenbleibt. Das muß nicht direkt die fehlerhafte Stelle sein, kann aber immerhin innerhalb des fehlerhaften Programmabschnittes sein, z.Bsp. bei einem Sprung, der immer wieder einige Zeilen nach oben führt. Ursache kann dann z.Bsp. eine Fehlermeldung/Warnmeldung sein, deren Auswertung zu einem oben beschreibenen Deathlock führt. Ein Fehler bei den SEW kann natürlich vorhanden sein, der dürfte aber nie zu einer Zykluszeitüberschreitung führen. In PC-Programmen sieht man manchmal, daß auf eine Antwort in einer Schleife gewartet wird. Sowas verbietet sich bei einer SPS, auch das könnte hier jemand so programmiert haben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo.
wenn das Prob erst seit dem Neuanlauf besteht könnte auch eine alte Software in der CPU schuld sein.Ist noch eine aktuelle Datensicherung vorhanden mit der man das Prog was läuft vergleichen kann?
Thomas
 
Hallo,

Danke nochmal für eure Hinweise.

Soviel ich weis, sind keine Schleifen direkt programmiert und das Programm ist seit der Inbetriebnahme nicht verändert worden. Ich werde mich am Montag wieder einloggen und eure Hinweise noch einmal abchecken. Mich stört vorallem der Umstand das bei Lüfter "Aus" alles normal läuft obwohl die Kommunikation mit den FU`s ja auch hier schon besteht. Beim starten wird nun lediglich ein Freigabe-Bit gesetzt und der sollte auf den anstehenden Sollwert hochlaufen. Zurück wird der Istwert und die Strombelastung gemeldet. Alle Stationen sind identisch programmiert. Beim starten läuft Lüfter seine Anfahrrampe hoch und kurz vor erreichen des Sollwertes kommt diese verdammte Zykluszeitüberschreitung. Gibt es einen OB der so einen Fehler abfangen kann?

mfg
PeterK
 
ja den OB gibt es. Nr.? OB80 glaube ich. Wenn der Programmiert ist geht die CPU nicht in Stop(sie macht was in OB 80 steht[wenn leer, dann macht sie mit normalem Prog weiter] in S7 Hilfe genauere Infos). also vorsicht!!!! Sie kann dann auch auf Eingänge nicht mehr reagieren und die Ausgänge bleiben wie sie sind in dem Zyklus.
Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim starten läuft Lüfter seine Anfahrrampe hoch und kurz vor erreichen des Sollwertes kommt diese verdammte Zykluszeitüberschreitung. Gibt es einen OB der so einen Fehler abfangen kann?

mfg
PeterK

Wird die Rampe von der SPS berechnet?

OB80

Beschreibung

Das Betriebssystem der CPU ruft den OB 80 auf, wenn bei der Bearbeitung eines OB einer der folgenden Fehler auftritt: Überschreiten der Zykluszeit, Quittierungsfehler bei der Bearbeitung eines OB, Vorstellen der Uhrzeit (Uhrzeitsprung) zum Starten eines OB, Wiedereintritt in RUN nach CiR. Tritt beispielsweise ein Startereignis für einen Weckalarm-OB auf, bevor die vorherige Bearbeitung desselben OB beendet ist, dann ruft das Betriebssystem den OB 80 auf.

Wurde der OB 80 nicht programmiert, dann wechselt die CPU in den Betriebszustand STOP.

Sie können den Zeitfehler-OB mit Hilfe der SFCs 39 bis 42 sperren bzw. verzögern und wieder freigeben.

HinweisWenn der OB 80 in demselben Zyklus zweimal aufgrund der Zykluszeitüberschreitung aufgerufen wird, geht die CPU in STOP. Sie können dies durch Aufruf der SFC 43 "RE_TRIGR" an geeigneter Stelle verhindern.

Aber trotzdem wird ja der Zyklus enorm verlängert, die Maschine reagiert auf andere Ereinisse gar nicht mehr, schaltet also unter Umständen Ausgänge viel zu spät ab!
 
Ob80

Hallo
Der OB80 verhindert zwar, dass die SPS in den Stop geht, wenn die Zykluszeit (Standard 150ms) überschritten wird, falls aber im gleichen Zyklus die Zykluszeit nochmals überschritten wird (300ms), geht die SPS trotzdem in den Stop-Zustand. Die Zykluszeit müsste in deinem Fall nachgetriggert werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo
Der OB80 verhindert zwar, dass die SPS in den Stop geht, wenn die Zykluszeit (Standard 150ms) überschritten wird, falls aber im gleichen Zyklus die Zykluszeit nochmals überschritten wird (300ms), geht die SPS trotzdem in den Stop-Zustand. Die Zykluszeit müsste in deinem Fall nachgetriggert werden.

Aber letztlich würde das nicht wirklich was bringen, ich geh mal wirklich von einem Programmfehler aus, den es zu finden gilt, statt zu versuchen, mit OB80 und Trick17 die SPS im Run zu halten.
 
Hallo,

habe soeben nochmal auf der Anlage nachgeschaut

- OB80 ist vorhanden aber nicht programmiert
- das Hochlaufen ist nicht programmiert sondern eine Rampe im FU
- der Fehlerspeicher ist schon überschrieben mit verschiedenen anderen
Meldungen (offensichtlich haben die Kollegen vor Ort am Profibus ge-
arbeitet)
- einen Baustein vergleich habe ich durchgeführt, brachte aber auch keine
Abweichung.

Nun muß ich sehen was der Montag bringt nochmal vielen Dank an Euch

mfg
PeterK
 
Kann es sein, das einer deiner SEW-Umrichter bei dem Stromausfall schaden genommen hat? Weil wenn am Programm nix geändert wurde, warum sollte es jetzt auf einmal eine längere Zykluszeit haben?

Ich frage, weil wir seit einiger Zeit auch Probleme mit SEWs haben, die nach einem Stromausfall plötzlich nicht mehr Laufen oder Probleme machen.


Edit: Sorry, hab eben erst richtig gelesen, das du den Umrichter schon getauscht hast.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich kann die Meinung von Ralle an dieser Stelle nur teilen.
Das reine Übertragen von ein paar Worten auf den Profibus kann nicht zu einer Zykluszeit-Überschreitung führen. Ich würde im Programm auch mal nachsehen, was mit dem fraglichen Bit noch so angesteuert wird.
Gibt es irgendwelche Schleifen-Bearbeitung ? Mal unabhängig, wofür die zuständig sind ... Vielleicht gibt es doch einen Zusammenhang ...
Es scheint sich hierbei ja auch um einen Wiederholungstäter zu handeln, denn das blosse Vorhandensein des OB80 würde eine einmalige Zykluszeit-Überschreitung ja schon abfangen ...
 
Hallo,

Ich verstehe, das mit der Schleifenbildung und den damit verbundenen Abstürzen schon, ist mir bei einer Inbetriebnahme mal passiert. Aber wenn so eine Anlage schon 3 Jahre läuft, wo soll denn dann plötzlich eine solche Schleife entstehen. Mein Verdacht richtet sich eigentlich gegen die FU`s von SEW. Wir haben die Dinger bei uns als Standart und da habe ich schon einige Ausfälle gehabt. Ausgetausch wurde die 2.FU (Lüfter), also diejenige die am S-Bus der 1.FU (Rollenantrieb) in dieser Station hängt. Diese 1.FU hägt am Profibus und fungiert ja als Gateway für die 2.FU. Könnte es sein das nun die erste (obwohl sie für sich problemlos läuft) doch im Zusammenspiel mit der 2. FU den Fehler verursacht?
Wenn der Lüfter eingeschaltet wird (Einschaltbit=1) vergehen ca 2min bis zum Absturz ohne das hier weitere Programmteile bearbeitet werden. In den 2min werde ja doch einige Zyklen bearbeitet (Schnitt 20ms) und dann erst kommt der Ausfall. So gut Ferndiagnosen auch sein mögen, ersetzen sie doch nicht Möglichkeiten vor Ort.
Wer hat eigentlich noch so seine Erfahrungen mit SEW gemacht?

mfg
PeterK
 
So gut Ferndiagnosen auch sein mögen, ersetzen sie doch nicht Möglichkeiten vor Ort.

Kein Einwand.

Was deine FU's angeht, so ist doch aber der UFP 20 (oder so ähnlich - SEW ist schon ein paar Tage her bei mir) dein Profibus-Teilnehmer. Nach meiner Meinung nimmt der die Daten schon vom Bus. Auch wenn der FU-2 von ihm "gestört" sein sollte.

Das mit dem Schleifen-Programmteil war nur so eine Idee. Das muss nicht so sein. Allerdings spricht deine Aussage :
Wenn der Lüfter eingeschaltet wird (Einschaltbit=1) vergehen ca 2min bis zum Absturz
... auch nicht unbedingt dagegen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Funktion einer UFP übernimmt hier die 1. FU. Das Durchschleifen wird durch ein kleines IPOS-Programm in dieser FU realisiert. Ist aber nicht von mir. Hier hat uns ein Techniker von SEW unterstützt. Vorteil war natürlich die Einsparung von 7 UFP`s. Nachteil in den jeweils 1. FU`s läuft ein zusätzliches von mir nicht beeinflußbares IPOS-Programm. Im großen und ganzen ist diese Möglichkeit ja nicht schlecht und hat auch so ihre Vorteile zB. Master-Slave-Betrieb von 2 Walzen um die synchronität zu gewährleisten. Mir ist es aber in der Regel lieber, ich kann alles selbst beeinflussen.

mfg
PeterK
 
Hallo Peter

Ich hab gerade etwas ganz ähnliches ...

Wenn ich dich recht verstehe, handelt es sich bei den FUs um MoviTracs? und als Gateway eine DFP21?
Wenn dem so ist, dann sind dem Bus die dahinterliegenden FUs eigentlich egal, weil der Gateway auf den SBus pro Device immer 3 PDW sendet, bzw empfängt. Gibt es dieses Gerät nicht, wird es verworfen.
Ich glaube kaum, dass du via SBus den ProfiBus zum erliegen bringst. Zudem sollte der Profibus ja ein TimeOut haben, welches deutlich kleiner ist weder das der CPU (wenn ich mich nicht irre ;) )

Ich frage mich, warum du dazu nen IPOS-Programm brauchst?

Gruss Reto
 
... da ist also ein OB80, welcher nicht programmiert ist. Setze doch in dem ein Bit welches als Meldung ausgegeben wird und schau mal, ob im normalen nicht abstürzenden Betrieb der OB mal aufgerufen wird und nur zu ganz ungünstigen Umständen die Zykluszeit so lang wird, das die CPU in Stop geht. Wenn die Situation so reproduzierbar ist, wie geschrieben wurde, dann "einfach" mal zu nem günstigen Zeitpunkt tun und genau nachschauen was gemeldet wird.
Ich "Tippe" auf einen Programmbug aber:
Ich kenne eine Anlage, da wurden die unmöglichsten Fehler (Datenbaustein weg/plötzlich endende Programmbausteine in der CPU) der CPU (S5/115) durch Einstreuungen eines Danfos FU (defekte Ausgangsstufe 2m entfernt von CPU) hervorgerufen.
In einer anderen Anlage (s5) wurde durch Korossion (schlechte Luft) auf dem Rückwandbus so manche Daten verstümmelt.

Wie ein Autohersteller schon in seiner Werbung verkündete:"Nichts ist unmöglich..."
Thomas
 
Hallo PeterK.,

Könntest Du den Fehler noch mal erzwingen, danach den Diagnosepuffer Auslesen und posten?

Könnte wichtige Hinweise beinhalten.
Ich ärgere mich auch regelmäßig mit SEW 'rum...

Griele Füße dtsclipper
 
Hallo,

Also zur Zeit sind vor Ort Techniker im Einsatz. Bis jetzt haben sie allerdings auch nur herausgefunden, das die Anlage nur nach dem beschriebenen hochlaufen des Lüfters in Stop geht. In der Diagnose wird der Aufruf des OB80 angezeigt und die schon beschriebene Zykluszeitüberschreitung. Man hat die Hardwarekonfiguration aktualisiert und zur Zeit schaut man gerade nach der eingestellten Zykluszeit. Die steht aber schon bei 300ms.
Mit SEW habe ich auch schon gesprochen, die können sich einen defekt der Profibusschnittstelle vorstellen und empfehlen diese zu wechseln. übrigens bei älteren Movitrive`s war ein IPOS-Prog zum umsetzen auf S-Bus noch notwendig. Seit einem Jahr geht das jetzt auch hardwaremäßig und man kann wohl bis 24PW übertragen. Auf den Rückruf der Simens-hotline warte ich noch.

mfg
PeterK
 
Zurück
Oben