# S_VIMP S7-300 und 400 sporadische Fehler



## mikeautomatix (19 November 2008)

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 (24 November 2008)

*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 (14 Oktober 2009)

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 (14 Oktober 2009)

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 (14 Oktober 2009)

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 (14 Oktober 2009)

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


----------



## Astralavista (14 Oktober 2009)

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 (14 Oktober 2009)

*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 (14 Oktober 2009)

mikeautomatix schrieb:


> 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 (15 Oktober 2009)

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 (15 Oktober 2009)

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 (15 Oktober 2009)

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 (15 Oktober 2009)

Larry Laffer schrieb:


> 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 ...
> ...


 
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 (15 Oktober 2009)

*nee..*



mikeautomatix schrieb:


> 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 (15 Oktober 2009)

Jochen Kühner schrieb:


> 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 (16 Oktober 2009)

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 (16 Oktober 2009)

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 (16 Oktober 2009)

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 (16 Oktober 2009)

mikeautomatix schrieb:


> ... 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 (16 Oktober 2009)

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.


----------



## mikeautomatix (16 Oktober 2009)

Hab ich jetzt noch vergessen zu erwähnen:



Earny schrieb:


> 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.
> 
> Earny


 
M43.0 wird im Programm nur zwei mal schreibend bearbeitet. Einmal wird er gesetzt, um die Funktionen anzustoßen und zurück gesetzt wird er nur mit dem S_VIMP (T36) selbst. Es ist auch kein "überlappender" Zugriff oder eine indirekte Adressierung auf irgendwelche Merkerbereiche vorhanden.

thanks

mikeautomatix


----------



## Earny (16 Oktober 2009)

und in die Speicherbereiche MB43, MW42, MW43, MD40, MD41, MD42 und MD43 wird auch nicht geschrieben?

Gruß
earny


----------



## mikeautomatix (16 Oktober 2009)

Earny schrieb:


> und in die Speicherbereiche MB43, MW42, MW43, MD40, MD41, MD42 und MD43 wird auch nicht geschrieben?


 
Nein. Das meinte ich ja mit "kein überlappender Zugriff".

Ich weiß dass das ganze ziemlich merkwürdig klingt. Aber warum ist der Fehler dann an keiner Anlage mehr aufgetreten, wenn wir die Möglichkeit hatten den S_VIMP zu entfernen? Klar ist das noch kein Beweis, so selten wie der Fehler bisher aufgetreten ist. Aber glaub mir, ich schreib so einen Schwachsinn nicht "just for fun". Wir finden tatsächlich keinen anderen Fehler! 

Merkwürdig vielleicht auch, dass es eine einzige Serie (8 Stück) der Anlagen gibt, die schon mit am längsten laufen (ca. 8 Jahre) bei denen der Fehler nicht einmal aufgetaucht ist. Die laufen mit 316-2DP aus 2001. Wahrscheinlich nur Zufall?!?

Komisch ist das doch, dass nur mein wirklich sehr erfahrener Kollege (der hat schon mit den Vorgängern von Step5 gearbeitet und ist auch heute noch voll im Geschäft - was selten ist) sagt, er kenne das Problem.

trotzdem danke an die, die sich hier Gedanken machen


----------



## kpeter (19 Oktober 2009)

hallöchen

mal eine frage kann es sein das du denn reset auch programiert hast


----------



## mikeautomatix (19 Oktober 2009)

kpeter schrieb:


> hallöchen
> 
> mal eine frage kann es sein das du denn reset auch programiert hast


 
Nein, das verwende ich eigentlich Grundsätzlich nicht. Trotzdem Dank für den Hinweis.

mikeautomatix


----------



## superkato (11 August 2011)

ich hab jetzt neulich das problem gehabt das ich  2 werte (ein AI druckwert und denn sollwert 8.2) mit einem CMPR <  vergleiche und obwohl das keine =1 liefert bzw. die bedingung nicht erfüllt ist,  startet der v_imp auf einmal los und zähl von 20s runter auf 0 und starter wieder.

als würde das cmpr < Glied ab und zu triggern bzw. eine Flanke senden obwohl der Wert noch lange nich kleiner 8.2 ist.

merkwürdig!


----------



## Paule (11 August 2011)

superkato schrieb:


> ich hab jetzt neulich das problem gehabt das ich 2 werte (ein AI druckwert und denn sollwert 8.2) mit einem CMPR < vergleiche und obwohl das keine =1 liefert bzw. die bedingung nicht erfüllt ist, startet der v_imp auf einmal los und zähl von 20s runter auf 0 und starter wieder.
> 
> als würde das cmpr < Glied ab und zu triggern bzw. eine Flanke senden obwohl der Wert noch lange nich kleiner 8.2 ist.


Hallo superkato,
bist du sicher dass dein Analogeingang nicht mal ein Zyklus kurz "flackert"?
Speicher dir doch mal den niedrigsten Istwert, vielleicht fällt er ja wirklich ein Zyklus unter 8.2

```
U #Start_Auswertung
     FP #Start
     SPBN EIN
     L AI 
     T #Minwert
 
EIN: L #Minwert
     L AI
     <R
     SPB OK
     T #Minwert
OK: NOP 0
```


----------



## superkato (11 August 2011)

Hi,
das kann sein  aber was macht man denn wenn dies so ist?

Es handelt sich ja um einen Behälterdruck der gemessen wird, dieser kann ja nicht plötzlich wenn 8.713156 angezeigt wird auf unter 8.2 sinken. Also nehm ich mal an das der wirklich "flackert" vom Drucksensor bzw. Zyklus her....

shit... das er das s_vimp Glied anregt ist richtig nervig! wenn ich einen Nullmerker drann haue dann passiert nichts. 
Gibts da eine Lösung? evtl. Aktualisierungsrate niedriger?


----------



## Paule (11 August 2011)

superkato schrieb:


> Gibts da eine Lösung? evtl. Aktualisierungsrate niedriger?


Da fallen mir spontan zwei Möglichkeiten ein:
1. Eine Mittelwertbildung
2. Du schaust ob der Wert plausibel ist. Sprich fällt der Wert von einem auf den nächsten Zyklus um mehr als (?) 1 bar dann diesen Wert ignorieren.
Interessant wäre auf welchen Wert er denn fällt wenn er flackert, sprich Auswertung.


----------



## superkato (11 August 2011)

ja ich werde mir das morgen mal anschauen... schade das siemens keine eigene glättung bzw mittelwertbildung integriert hat.

trivialerweise tritt das problem nur sporadisch auf. paar tage gehts gut und dann wieder nicht. ... könnte ja sogar sein das dass kabel ein fehler hat.


----------



## Paule (11 August 2011)

superkato schrieb:


> trivialerweise tritt das problem nur sporadisch auf. paar tage gehts gut und dann wieder nicht. ... könnte ja sogar sein das dass kabel ein fehler hat.


Oder ein EMV Problem.
Neue Maschine aufgestellt oder Umrichter nachgerüstet?


----------



## superkato (11 August 2011)

Paule schrieb:


> Oder ein EMV Problem.
> Neue Maschine aufgestellt oder Umrichter nachgerüstet?



nur einen weiteren Drucktransmitter nachgerüstet aber mit geschirmten Kabel...

Hmm ich vermute schon das der Monteur evtl. was falsch gemacht hat aber sicher bin ich mir nicht , ich denk eine Mittelwertbildung über 4-5Werte wäre sinnvoll. Es darf nur nich zu lang dauern, da der Druck sich ja verändert.


----------



## Paule (11 August 2011)

superkato schrieb:


> Es darf nur nich zu lang dauern, da der Druck sich ja verändert.


Das sehe ich auch so, darum würde ich eine Mittelwertbildung als zweite Option nehmen und lieber einen Zyklus den falschen Wert ignorieren.


----------



## superkato (11 August 2011)

dann schaue ich mal morgen nach um was es sich für ein wert handelt. 

Hättest du da schon etwas code bereit um das zu realisieren?


----------



## Paule (11 August 2011)

superkato schrieb:


> dann schaue ich mal morgen nach um was es sich für ein wert handelt.
> 
> Hättest du da schon etwas code bereit um das zu realisieren?


Zum den fehlerhaften Code ausblenden?
Nein, aber das bekommen wir dann schon hin.


----------



## volker (11 August 2011)

abhängig davon wie zeitkritsch deine anwendung ist, würde es auch eine kurze time-se (z.b. 100ms) zwischen vergleicher und v_imp tun


----------



## superkato (11 August 2011)

ich hab hier mal das besagte netzwerk als bild eingefügt. 
100ms sind unkritisch, erst eine Sekunde wären kritisch.



beschreibung:
Druckwert wird verglichen (in dem fall >R) -> Verlängerter impuls von 15sec damit falls der druck wieder absingt und hochsteigt nicht nochmal der Schaltpunkt ausgelöst wird-> dann ein s_impuls von 1sec der mir wiederum nur kurz meine Funktion (Funktion zum aktivieren/deaktivieren eines Kompressors) mit einer positivien flanke antriggert (m1.0, m2.2).


----------



## OHGN (11 August 2011)

Einfach den kritischen Wert mit einem Tiefpassfilter etwas glätten:


```
FUNCTION FC 230 : VOID
TITLE =Pegel filtern
//Filterkonstante (Wertebereich 0-100%)
//0,001 -> maximale Dämpfung 
//100,0 -> keine Dämpfung
AUTHOR : Ne
VERSION : 0.1


VAR_INPUT
  FK : REAL ;    //Filterkonstante in %
  Roh : REAL ;    //Rohwert
END_VAR
VAR_IN_OUT
  GF_Wert : REAL ;    //Gefilteter Wert
END_VAR
VAR_TEMP
  ZE1 : REAL ;    
END_VAR
BEGIN
NETWORK
TITLE =


      L     1.000000e+002; 
      L     #FK; //Filterkonstante
      -R    ; 
      L     1.000000e+002; 
      /R    ; 
      L     #GF_Wert; //gefilterter Wert(Altwert)
      *R    ; 
      T     #ZE1; 
      L     #FK; //Filterkonstante
      L     1.000000e+002; 
      /R    ; 
      L     #Roh; //Rohwert
      *R    ; 
      L     #ZE1; 
      +R    ; 
      T     #GF_Wert; //gefilterter Wert (Neuwert)

END_FUNCTION
```


----------



## volker (11 August 2011)

so kann man den vergleicher auf einfache weise entprellen


----------



## superkato (11 August 2011)

so ich hab mir das heute mal angeschaut und musste feststellen das es kein flackern gab also das "phenomen" ist nicht aufgetreten.
Die Anlage läuft stabil und falls das flackern auftreten sollte habe ich eine veriegelung drin, die blödsinn verhindert.

danke für den tipp mit dem entprellen, ich schau mir das mal genauer an und evtl. bau ichs ein.


----------

