S_VIMP S7-300 und 400 sporadische Fehler

[mikeautomatix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich habe bei S7-300 und S7-400 das Problem, dass ganz sporadisch Timer vom Typ S_VIMP - sprich Zeiten als verlängerter Impuls - nicht ablaufen. Das heißt trotz einer positiven Flanke am Starteingang läuft der Timer nicht an und der Ausgang wird nicht gesetzt.
Es liegt in der Natur der Sache, dass dieser Fehler schwer zu finden bzw. kaum nachvollziehbar ist, wenn man nicht zufällig online an der Steuerung hängt.
Laut Aussagen von einigen unserer „älteren“ Programmierer, ist das ein bekanntes Problem bei Siemens, das schon seit S5-Zeiten bestehen soll. Mir ist das Problem auch schon seit Jahren bekannt. Deshalb vermeide ich die Verwendung von S_VIMP seit dieser Zeit.
Da ich aber noch ältere Anlage laufen habe, bei denen das Problem immer noch sporadisch auftritt, würde mich interessieren, ob jemand schon mal ähnliche Erfahrungen gemacht hat oder etwas „offizielles“ von Siemens dazu gehört oder gelesen hat.

mikeautomatix

 

[mikeautomatix]

S_VIMP-Timer kennt wirklich keiner das Problem

Hallo, jetzt muss ich noch mal nachhacken! Kennt wirklich niemand das Problem mit den sporadischen Ausfällen bei den S_VIMP-Timern bei Siemens S7-300 und 400?

mikeautomatix

 

[mikeautomatix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann, oder will hier niemand etwas zum Thema sagen? Klingt das etwa zu abwegig? Ich konnte den Fehler mit den S_VIMP-Timern jedenfalls vor einigen Jahren schon mal eindeutig nachweisen!

Leider muss ich mich immer wieder mit dem Thema herumschlagen, weil es bei Kunden teilweise erst nach Jahren zu Ausfällen wegen der Problematik kommt.

mikeautomatix

 

[Earny]

hätte da nur eine einzige Idee, dass in dem Projekt die Timer-Nummer des VIMP-Timers, der nicht richtig arbeitet, ein zweites mal für einen anderen Timer vergeben wurde.
Vermutlich hast Du das aber bereits ausgeschlossen.

Gruß
Earny

 

[Blockmove]

Bist du dir sicher, dass der Timer nicht anläuft?
Ich kenn aus S5_Zeiten eigentlich nur dass Problem, dass der Timer während des Zyklus auf Null geht. Daher von Siemens die Empfehlung mit Timer direkt auf einen Merker. Und diesen Merker dann im Programm verwenden.

Ob es bei S7 noch Probleme gibt, kann ich dir nicht sagen. Ich hab - glaub ich - in 12 Jahren S7 noch keinen einzigen V_IMP programmiert. Bei mir kommen meist die entsprechenden SFB zum Einsatz.

Gruß
Dieter

 

[Bernard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe diese Erfahrung noch ncht gemacht,würde aber den V_IMP gegen SF3 tauschen.

 

[Astralavista]

Also ich konnte das noch nicht beobachten. War immer alles Ok mit den Timern.
Und das auch auf Maschinen die über 10 Jahre gelaufen sind.

 

[Jochen Kühner]

noch nie gehört...

hab ich noch nie was von gehört, aber man kann doch jede zeit über merker und flanken auch mit einer se realisieren, programmiers doch einfach mal um!

 

[MW]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann, oder will hier niemand etwas zum Thema sagen? Klingt das etwa zu abwegig? Ich konnte den Fehler mit den S_VIMP-Timern jedenfalls vor einigen Jahren schon mal eindeutig nachweisen!

Leider muss ich mich immer wieder mit dem Thema herumschlagen, weil es bei Kunden teilweise erst nach Jahren zu Ausfällen wegen der Problematik kommt.

ich verwende den S_Vimp öfter, habe aber dieses Phänomen noch nie bemerkt, passiert das bei dir bei verschiedenen CPU-Typen ? (ältere/neuere,300er/400er)

 

[mikeautomatix]

Hallo,
danke, dass sich hier mal jemand für das Thema interessiert.

Die doppelte Verwendung der betroffenen Timer habe ich ausgeschlossen. Diese Art von Flüchtigkeitsfehlern habe ich natürlich als erstes untersucht.

Verwendet habe ich den S_VIMP (in ebenfalls 12 Jahren Berufspraxis) vielleicht in vier oder fünf Fällen. Wie bereits erwähnt, verwende ich den Timer, aufgrund der beschriebenen Erfahrungen auch schon seit Jahren nicht mehr (bei neuen Programmen). Leider habe ich ihn aber einmal in einem Programm verwendet, das in einer Art Serienmaschine im Einsatz ist. Es handelt sich um ca. 60 Anlagen, auf die ich nicht so ohne weiteres Zugriff habe. Einfach umprogrammieren ist deshalb nicht. Die Anlagen sind über den halben Globus verteilt und teilweise erlauben die Betreiber keine Programmänderungen, ohne eine plausible Erklärung dafür. Die Kunden möchten aber eine einigermaßen schlüssige Erklärung haben, wenn nach Jahren plötzlich ein durch den Timer verursachtes Problem auftritt. Nach dieser Erklärung suche ich. Deshalb habe ich das Thema hier aufgemacht.

Es ist wirklich sehr dubios. Ich habe hier in der Nähe zum Beispiel zwei Maschinen laufen, die vor etwa 3 Jahren in Betrieb gegangen sind, und ebenfalls zu der angesprochenen Serie gehören. Nahezu baugleich. Der Programmteil mit dem Timer ist völlig identisch. Kürzlich trat an einer plötzlich der Fehler auf. Drei mal in einer Woche. Die andere lief einwandfrei. Hier habe ich Zugriff und habe den Timer durch eine S_EVERZ ersetzt. Seit dem ist wieder alles ok. Hier kann ich es allerdings nicht zweifelsfrei belegen, dafür ist der Programmteil etwas zu komplex.

Eindeutig war der Fall aber ein einer anderen Anlage, die mit einer 414-2DP aus 1998 läuft. Hier trat der Fehler allerdings nur einmal auf. Deshalb habe ich das damals nicht so ernst genommen und den S_VIMP anschließend noch hin und wieder verwendet. Leider!

Beobachtet hatten wir das Phänomen an folgenden CPU-Typen: 414-2DP (Bj. 1998), 315-2DP (Bj. 2003, 2004 und 2006) und 317-2DP (Bj. 2008).

Lustiger weise erzählt mir ein einziger Kollege immer, er kenne das Problem schon ewig. Der hat schon viele viele Jahre mehr auf dem Programmierer-Buckel als ich. Angeblich gäbe es das Problem schon seit S5-Zeiten. Leider ist er der einzige, der das sagt!

 

[online]

Habe sowas bei der S7 noch nicht bemerkt, habe allerdings bei der S5 einen Stundenwechselimpuls, der sporadisch alle paar Monate mal nicht ausgeführt wird.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
mir drängen sich hier Parallelen zu diesem Thread auf ...
Kann es sein, dass die Laufzeit des Timers ggf. kleiner als die SPS-Zykluszeit ist ?
Eine andere Sache hätte ich da auch noch : es kommt immer wieder gut, wenn ein Timer eventuell hin und wieder übersprungen / nicht bearbeitet wird ...

Gruß
LL

 

[mikeautomatix]

Hallo,
mir drängen sich hier Parallelen zu diesem Thread auf ...
Kann es sein, dass die Laufzeit des Timers ggf. kleiner als die SPS-Zykluszeit ist ?
Eine andere Sache hätte ich da auch noch : es kommt immer wieder gut, wenn ein Timer eventuell hin und wieder übersprungen / nicht bearbeitet wird ...

Gruß
LL

Danke für den Hinweis Larry Laffer,

war mir jetzt gar nicht mal so sicher, ob das nicht sein könnte. Habe nun extra noch mal die betreffenden Programme durchgeschaut. Aber die Timer sind alle mit Zeiten zwischen 1 und 15 Sekunden beschaltet. Die Zykluszeiten liegen alle so zwischen 70 und 150 ms, die damals betroffene 414-2DP liegt sogar bei nur ca. 20 ms und die Zyklusüberwachungszeit ist auf Werte zwischen 450 und 600 ms eingestellt. Also eigentlich nicht möglich.

mikeautomatix

 

[Jochen Kühner]

nee..

Danke für den Hinweis Larry Laffer,

war mir jetzt gar nicht mal so sicher, ob das nicht sein könnte. Habe nun extra noch mal die betreffenden Programme durchgeschaut. Aber die Timer sind alle mit Zeiten zwischen 1 und 15 Sekunden beschaltet. Die Zykluszeiten liegen alle so zwischen 70 und 150 ms, die damals betroffene 414-2DP liegt sogar bei nur ca. 20 ms und die Zyklusüberwachungszeit ist auf Werte zwischen 450 und 600 ms eingestellt. Also eigentlich nicht möglich.

mikeautomatix

aber der timer kann ja trotzdem mitten im zyklus ablaufen, wenn du den timer mehrmals verwendest und nicht auf einen merker umlegst!

bsp:

bla
bla
l s5t#4s
sa t40
bla
bla
bla
u t40
bla
bla
bla
u t40

hier kann es sein, das t40 beim ersten u noch true ist und beim 2ten false, wenn die zeit dazwischen abgelaufen ist (wenn ich das richtig verstanden habe)!

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

hier kann es sein, das t40 beim ersten u noch true ist und beim 2ten false, wenn die zeit dazwischen abgelaufen ist (wenn ich das richtig verstanden habe)!

Genau das konnte bei der S5 das Problem sein.
Dort betraf es - wenn ich es noch richtig im Kopf hab - die Ausschaltverzögerung, den verlängerten Impuls. Beim normalen Impuls bin ich nicht mehr ganz sicher.

Gruß
Dieter

 

[mikeautomatix]

Hallo,

danke für die interessanten Kommentare.

Leider kann das Ablaufen des Timers mitten im OB1-Zyklus hier nicht die Erklärung sein. Es geht schon rein darum, dass der SV-Timer überhaupt nicht Abläuft. Sprich der Ausgang überhaupt nicht auf high wechselt. Beispiel aus dem Problem-Programm:

U M 43.0
L S5T#1S
SV T 36

UN T 36
L S5T#30S
SE T 6

UN T 36
L S5T#30S
SE T 7

Hier wechseln trotz sichergestelltem 0-1-Wechsel vom M43.0 die Ausgänge von T6 und T7 nicht von high nach low wechseln, sondern high bleiben. Das ist das, was ich aus dem Maschinenverhalten ermitteln konnte. Bitte keine Diskussion, warum das hier so gemacht ist. Darum geht’s nicht. Es geht rein um das Verhalten der CPU! T36 löst im Programm noch andere Funktionen aus, die aber für den Ablauf nicht relevant sind. Meiner Ansicht nach kann ich nur schlussfolgern, dass T 36 nicht angelaufen sein kann.

mikeautomatix

 

[Earny]

in PLCSim funktioniert die Sache. Ich glaube nicht an die Hardware-Fehler-Theorie. Das Problem liegt erfahrungsgemäß meistens zwischen den Ohren.
Wie Larry sagt, könnte der Programmteil übersprungen werden.
Hast Du mal überprüft, ob kein zweiter T36 im Programm existiert und ob kein unerwünschter Schreibzugriff auf den M43.0 existiert, der ihn dauerhaft oder gelegentlich (noch schlimmer) auf 0 hält.

Gruß
Earny

 

[pjoddi]

Zuviel Werbung?
-> Hier kostenlos registrieren

rein theoretisch besteht natürlich auch noch die Möglichkeit, das der M43.0, wo immer er erzeugt wird, ständig, d.h. in Abständen < 1s hin und her flattert, was dazu führt, das die Zeit von T36 ständig nachtriggern würde, so das er niemals abläuft, sondern auf 1 bleibt, was wiederum T6 und T7 zu dem beschiebenen Verhalten zwingen würde...

 

[Larry Laffer]

... Hier wechseln trotz sichergestelltem 0-1-Wechsel vom M43.0 die Ausgänge von T6 und T7 nicht von high nach low wechseln, sondern high bleiben. Das ist das, was ich aus dem Maschinenverhalten ermitteln konnte.

Wie hast du das sicher gestellt ?
Mach dir doch mal den Spaß und bau dir ein paar Debug-Hilfen ein. Such dir ein Merkerbyte, das frei ist, und setze entsprechend der Zwischen-Ergebnisse daraus einzelne Bits und beobachte die mal.
Also z.B. :
UN M43.0 setzt M400.0
U M43.0 setzt M400.1
U T36 setzt M400.2

vielleicht hilft das ja weiter.

Gruß
LL

 

[mikeautomatix]

Zitat:
Zitat von Earny http://www.sps-forum.de/showthread.php?p=222398#post222398
Wie Larry sagt, könnte der Programmteil übersprungen werden.
Hast Du mal überprüft, ob kein zweiter T36 im Programm existiert und ob kein unerwünschter Schreibzugriff auf den M43.0 existiert, der ihn dauerhaft oder gelegentlich (noch schlimmer) auf 0 hält.

Sprung ist keiner drin. Zumindest um keinen der betroffenen Variablen und Programteile.
Zitat:
Zitat von pjoddi http://www.sps-forum.de/showthread.php?p=222399#post222399
rein theoretisch besteht natürlich auch noch die Möglichkeit, das der M43.0, wo immer er erzeugt wird, ständig, d.h. in Abständen < 1s hin und her flattert, was dazu führt, das die Zeit von T36 ständig nachtriggern würde, so das er niemals abläuft, sondern auf 1 bleibt, was wiederum T6 und T7 zu dem beschiebenen Verhalten zwingen würde...

Dann würden ja T6 und T7 niemals ablaufen. Dann würde die Anlage nach ca 15 Minuten komplett stehen bleiben und Fehler melden. (Ist jetzt zu umfangreich zur genaueren Erläuterung)
Zitat:
Zitat von Larry Laffer http://www.sps-forum.de/showthread.php?p=222405#post222405
Wie hast du das sicher gestellt ?
Mach dir doch mal den Spaß und bau dir ein paar Debug-Hilfen ein. Such dir ein Merkerbyte, das frei ist, und setze entsprechend der Zwischen-Ergebnisse daraus einzelne Bits und beobachte die mal.
Also z.B. :
UN M43.0 setzt M400.0
U M43.0 setzt M400.1
U T36 setzt M400.2

Das M43.0 auf high gewechselt hat ist sicher, da andere Funktionen die M43.0 auslöst auch in dem Störfall abgelaufen sind.

Auf jeden Fall eine Gute Idee mit diesen Hilfsmerkern, mach ich auch manchmal. Aber mir fehlt derzeit leider der Zugriff und dann müsste ich ja genau den Fall erwischen, bei dem es mal nicht geht. Denn wie geschildert handelt es sich ja um eine sehr sporadisch auftretendes Problem. Die letzte Anlage an der ich das Problem hatte läuft seit ca. 3 Jahren. 2 1/2 Jahre ohne Probleme. Der Timer wird dabei im Schnitt ca. vier mal pro Stunde angestoßen. Auf diese Anlagen hätte ich eventuell (mit viel überedungskunst beim Kunden) Zugriff aber hier habe ich den S_VIMP nun bereits durch eine S_EVERZ ersetzt. Bei einer Anderen Serie dieses Anlagentyps (ca 13 Stück) waren die Ausfälle ebenfalls sehr sporadisch vorhanden, bis hier mein Kollege zufällig vor Ort war und den S_VIMP rausschmeissen konnte und durfte. Seitdem (ca. 1 1/2 Jahre) ist das Problem nicht mehr aufgetreten. Ich und mein alter, erfahrener Kollege haben ja schon 2 Jahre gebraucht, damit wir den Kunden das Problem überhaupt abgenommen haben. Erst nachdem wir es wirklich von fast jedem Einsatzort der Anlagen mal gehört haben, haben wir intensiv nach dem Fehler gesucht. Tage lang. Bis uns dann das mit dem S_VIMP wieder eingefallen ist.

Mein Programmauszug ist ja auch nur ein Beispiel, wo S_VIMP nicht funktioniert hat. Bei der 414-2DP wars ein völlig anderer Anwendungsfall. Hier hats den ersten Ausfall nach ca 2 Jahren gegeben. Und hier wird der Timer etwa einmal pro Tag angestoßen.