# Sensorentprellung



## arcis (13 Mai 2008)

Das leidige Thema Sensorprellen mal wieder.

Also, wie werden Sensoren beim Übergang von 0 -> 1 UND von  1 -> 0 am zweckmässigsten per Software entprellt.


----------



## marlob (13 Mai 2008)

Stichwort Einschaltverzögerung


----------



## marlob (13 Mai 2008)

Hier mal ein Beitrag aus diesem Forum
* 	DI's entprellen*
Wenn du nach entprellen suchst, dann kommen noch mehr Beiträge


----------



## arcis (13 Mai 2008)

*+*

Ich mache jetzt mal einen Voschlag in AWL:

U   E 1.0
L S5T#100MS
SE T 100

U T 100
L S5T#100MS
SA T 101

U T 101
= M 1.0           //  = Sensor E 1.0 entprellt

So vielleicht für E 1.0 von 0->1 und von 1->0?


----------



## vierlagig (13 Mai 2008)

schön wäre, wenn die lösung lesbar wäre - stichwort 
	
	



```
-tags

aber mal ne fachliche frage: wozu zwei zeiten :confused: ... [edit] ok, es funktioniert natürlich aber mich würde halt interessieren, was du damit erreichen möchtest[/edit]
```


----------



## arcis (13 Mai 2008)

*+*



> aber mal ne fachliche frage: wozu zwei zeiten


Es geht nicht nur um ein Einschaltprellen, sondern auch um ein Ausschaltprellen.

Bei entprellten Sensoren muss damit gerechnet werden, dass der Softwarezustand (M 1.0) bei "heftiger" Entprellung, also bei langen Einschalt- und/oder Ausschaltverzögerungen,  mit dem Hardwarezustand (E 1.0) nicht mehr übereinstimmt. Was z.B. bei sich schnell bewegenden Teilen schon zu Situationen führen kann, die man sich vorher überlegen sollte.


----------



## marlob (13 Mai 2008)

Vielleicht so

```
*
      U     E      1.0 // beim Einschalten
      L     S5T#100MS
      SE    T      1
      U     T      1
      =     M      1.0

      UN    E      1.0 // beim Ausschalten
      L     S5T#100MS
      SE    T      2
      U     T      2
      =     M      1.1
```


----------



## vierlagig (13 Mai 2008)

ist es ein "unkontrolliertes" prellen? also ist es möglich, dass der sensor zustände meldet, die gar nicht vorhanden sind oder geht es nur darum ein sicheres signal zu haben, auch wenn der sensor einen moment braucht um eine eindeutige eins zu melden?

im zweiten fall würde IMHO die ausschaltverzögerung ausreichen ...


----------



## arcis (13 Mai 2008)

*+*



> Vielleicht so



Geht so auch. SE war auch schon immer meine Lieblingszeitoperation, mit der man im Prinzip alles machen kann. Das andere Zeugs ist nur Schnickschnack, bei dem ich jedesmal nachschauen muss, wie es funktioniert.



> ...oder geht es nur darum ein sicheres signal zu haben, auch wenn der sensor einen moment braucht um eine eindeutige eins zu melden?



Es geht um ein sicheres Sensorsignal bei 0->1 und bei 1->0. Dazu, bin ich der Meinung,  braucht man zwei Zeiten.


----------



## vierlagig (13 Mai 2008)

arcis schrieb:


> Es geht um ein sicheres Sensorsignal bei 0->1 und bei 1->0. Dazu, bin ich der Meinung,  braucht man zwei Zeiten.



also nur mit ausschaltverzögerung würde es doch so aussehen, oder


```
|     _         _   _   _           _   __________
   I  |____| |_______| |_| |_| |_________| |_|          |_____
      |    : :       : : : : : :         : : :          :
      |    : :       : : : : : :         : : :          :
      |    :_:___    :_:_:_:_:_:___      :_:_:__________:___
   Q  |____|     |___|             |_____|                  |_
      |       <t>               <t>                      <t>
      |___________________________________________________________
                                                                 t
```


----------



## arcis (13 Mai 2008)

*+*



> also nur mit ausschaltverzögerung würde es doch so aussehen, oder


http://www.sps-lehrgang.de/zeitfunktion-sa/

Stimmt. Aber hier kriege ich bereits die ersten oder irgendwelche Prellimpulse als entprelltes Signal. Unter Entprellen verstehe ich ,dass das entprellte Softwaresignal (M1.0) erst dann zur Verfügung steht, wenn das Signal am Eingang (E 1.0) "zuverlässig" ansteht. Das ist imo mit einer SA nicht zu erreichen.


----------



## lorenz2512 (13 Mai 2008)

hallo,
die s7-200 hat eingabefilter bis 12ms, die s7-300 hat baugruppen mit bis 20ms eingabefilter, ich glaube 100ms kann man nicht mehr als prellen bezeichnen. oder hast du mechanisch ein teil was irgendwo gegenfährt und abprallt?


----------



## arcis (13 Mai 2008)

*+*

Wir haben halbdurchsichtige, flache, instabile Plastikteile die gekrümmt sein können und dann beim Transport entsprechend vibrieren. Ich gebe zu, die Sensorik, die wir einsetzen, ist nicht ideal. Aber jetzt ist sie schon mal drin und wir versuchen per Software das rauszuholen, was machbar ist.


----------



## TommyG (13 Mai 2008)

Armes Schwein...

'du kannst doch die Siemens, kannst Du mir mal eben den Motor wieder ganz programmieren....??'

Nur gut, dass es in Grenen funzt..., das Überlisten der Peripherie..

Greetz, Tom


----------



## Markus (13 Mai 2008)

sehe das auch so wie 4l, ich entprelle auch NUR mit EINER ausschaltverzögerung.

sobald ein signal vom sensor kommt, wird das verwendet -es muss nur so kurz sein dass die sps es erkennt. was danach, also während der laufzeit der SA passiert, ist ja egal - die SA hat es abgefangen...

Se macht nur Sinn wenn fehlsignale ausgebledent werden sollen, aber nicht beim entprellen...


----------



## vierlagig (13 Mai 2008)

lass mal markus, soll doch jeder seine ressourcen verschwenden dürfen, wie er will


----------



## no-strada-mus (14 Mai 2008)

Hallo arcis,
hatte mal so was ähnliches mit Schaltrollen, die sowohl beim Ein- als auch beim Ausschalten ca. 1,5s nachgefedert haben.
habe das soweit ich mich erinnern kann in etwa so gelöst:


```
U E1.0
L S5T#200ms
SA T1
U T1
= M1.0
 
U E1.0
L S5T#200ms
SE T2
U T2
= M2.0
 
U M1.0
FP M1.1
S M2.0     //entprelltes Signal
 
U M1.0
FN M2.1
R M2.0     //entprelltes Signal
```
 
MfG no-strada-mus


----------



## moeins (15 Mai 2008)

Markus schrieb:


> Se macht nur Sinn wenn fehlsignale ausgebledent werden sollen, aber nicht beim entprellen...


Gerade bei z.B. Füllstandsmeldern ist eine Entprellung im Einschaltvorgang sehr wichtig, wenn die Flüssigkeit im Tank hin- und her schwappt.
Ich bin grundsätzlich für die no-strada-mus Lösung, allerdings gleich als FC konzipiert.


----------



## Markus (15 Mai 2008)

moeins schrieb:


> Gerade bei z.B. Füllstandsmeldern ist eine Entprellung im Einschaltvorgang sehr wichtig, wenn die Flüssigkeit im Tank hin- und her schwappt.


 
das ist richtig, aber von entprellen redet man (zumindest erscheint mir diese definition logisch) wenn ein eingangssignal z.b. in kurzen abständen mehrere flanken bringt bevor es stabil ist.


was du meinst sind störsignale, diese *filtert* man an besten über eine SE, um also nur siganlen eine "daseinsberechtigung" zu geben die lange genug anstehen um als plausibel zu gelten.




> Ich bin grundsätzlich für die no-strada-mus Lösung, allerdings gleich als FC konzipiert.


 
wenn ihr zwei hübschen mir den code von ihm jetz noch erklärt, dann wäre ich euch sehr dankbar.

was passiert da mit M2.0 ?
ich habe eine vermutung wie das "richtig" aussehen sollte, aber wenn die zutrifft macht das ganze nicht wirklich sinn...

wenn eine SA der SE überlagert wird (die SA setzt ja schliesslich das bit --> also kein filter), was wollt ihr dann mit der nachgeschalteten SE noch bewirken?
eizige logische möglichkeit: einen impuls mit einer definierten länge formen, aber das geht auch einfacher...


aber in erster linie wäre es nett wenn das mit M2.0 mal jemand richtig stellen würde, ich hoffe doch das ist ein tippfehler...

wenn mir jemand den supergenialen trick dahinter verrät, und er mir gefällt, dann nehme ich alles zurück. aber ansonsten halte ich nicht viel davon bits mit "S+R" und "=" zu verknüpfen...


----------



## Markus (15 Mai 2008)

noch was...

@moeins
das hast du das gelesen?




Markus schrieb:


> Se macht nur Sinn wenn fehlsignale ausgebledent werden sollen, aber nicht beim entprellen...


----------



## Perfektionist (15 Mai 2008)

moeins schrieb:


> Gerade bei z.B. Füllstandsmeldern ist eine Entprellung im Einschaltvorgang sehr wichtig, wenn die Flüssigkeit im Tank hin- und her schwappt.
> Ich bin grundsätzlich für die no-strada-mus Lösung, allerdings gleich als FC konzipiert.


ich versuche mir gerade vorzustellen, wie ich wohl eine Tankbefüllung programmieren würde, die mir sicher stellt, dass der Tank auch nicht überläuft. Und eine Warnung, dass der Tankinhalt bald aufgebraucht sein könnte ...


----------



## vierlagig (15 Mai 2008)

Markus schrieb:


> wenn ihr zwei hübschen mir den code von ihm jetz noch erklärt, dann wäre ich euch sehr dankbar.



dem schließe ich mich an und gebe zu bedenken, dass M 2.0 nicht entprellt ist, sondern eine positive Flanke am Eingang erkennt und einen Zyklus lang 1 ist


----------



## vierlagig (15 Mai 2008)

Perfektionist schrieb:


> ich versuche mir gerade vorzustellen, wie ich wohl eine Tankbefüllung programmieren würde, die mir sicher stellt, dass der Tank auch nicht überläuft. Und eine Warnung, dass der Tankinhalt bald aufgebraucht sein könnte ...



das geht nur mit schätzen und vielleicht-verknüpfungen, besonders wenn es ein bewegter tank ist


----------



## no-strada-mus (15 Mai 2008)

Entschuldigung, war wohl schon zu später Stunde.
Natürlich  müsste es so heissen:


```
U E1.0
L S5T#200ms
SA T1
U T1
= M1.0
 
U E1.0
L S5T#200ms
SE T2
U T2
= M2.0
 
U M1.0
FP M1.1
S M3.0     //entprelltes Signal
 
U M2.0
FN M2.1
R M3.0     //entprelltes Signal
```
 
MfG no-strada-mus


----------



## Markus (15 Mai 2008)

dein bit M3.0 wird TRUE sobald ein Impuls auf den eingang kommt, das schaffst du auch mit nur einer zeit, also mit der SA allein.

Wenn dein eingang <200ms TRUE ist, dann wird dein M3.0 niewieder zurückgesetzt...

wozu soll das gut sein?


----------



## Larry Laffer (15 Mai 2008)

ich würde es so machen ... ist nicht so spektakulär ... aber es funzt ...

```
U E1.0
L S5T#200ms
SE T1
U T1
S M1.0
 
UN E1.0
L S5T#200ms
SE T2
U T2
R M1.0
```
Vielleicht hat das aber schon mal vorher einer gebracht ... so toll ist das ja nun auch wieder nicht ...


----------



## vierlagig (15 Mai 2008)

da is vor 53 stunden 13 minuten auch schon *einer* draufgekommen ... [/streiche]bis auf den einen tippfehler [streiche] [ergänze]die großen tippfehler ... alsofast drauf gekommen [/ergänze] ...danke larry


----------



## no-strada-mus (15 Mai 2008)

Zitat von arcis:


> Es geht nicht nur um ein Einschaltprellen, sondern auch um ein Ausschaltprellen.
> 
> Bei entprellten Sensoren muss damit gerechnet werden, dass der Softwarezustand (M 1.0) bei "heftiger" Entprellung, also bei langen Einschalt- und/oder Ausschaltverzögerungen, mit dem Hardwarezustand (E 1.0) nicht mehr übereinstimmt. Was z.B. bei sich schnell bewegenden Teilen schon zu Situationen führen kann, die man sich vorher überlegen sollte.


 
deshalb der "Aufwand"

wenn man in meinem Beispiel die letzten drei Zeilen wie folgt ändern würde

```
U M2.0
O M1.0
FN M2.1
R M3.0
```
dann wäre auch das Rücksetzen bei kurzem Eingangssignal gewährleistet, dann allerdings mit Ausschaltverzögerung.


----------



## vierlagig (15 Mai 2008)

fehlt noch die lösung für das problem hier:



Markus schrieb:


> dein bit M3.0 wird TRUE sobald ein Impuls auf den eingang kommt, das schaffst du auch mit nur einer zeit, also mit der SA allein.


----------



## moeins (16 Mai 2008)

Markus schrieb:


> das ist richtig, aber von entprellen redet man (zumindest erscheint mir diese definition logisch) wenn ein eingangssignal z.b. in kurzen abständen mehrere flanken bringt bevor es stabil ist.
> 
> 
> was du meinst sind störsignale, diese *filtert* man an besten über eine SE, um also nur siganlen eine "daseinsberechtigung" zu geben die lange genug anstehen um als plausibel zu gelten.


Ok. Die SPS-Eingänge bringen ja schon eine Entprellung von ~3-5ms mit. Ist vielleicht auch eine Definitionssache ab welcher Verzugszeit man von Entprellung oder Filterung spricht.

Ich hatte schon die Überlegung ganz auf die Timer zu verzichten und einfach mit dem Systemtakt (OB oder Taktmerker) ein INT hochzuzählen, bei einem bestimmt Wert den Merker zu setzen und wenn das Eingangssignal verschwindet herunterzählen und bei 0 wieder rücksetzen.
Spart man sich den ganzen Timerkram.


----------



## Markus (16 Mai 2008)

moeins schrieb:


> Ok. Die SPS-Eingänge bringen ja schon eine Entprellung von ~3-5ms mit. Ist vielleicht auch eine Definitionssache ab welcher Verzugszeit man von Entprellung oder Filterung spricht.


 
ENTPRELLEN:
wenn ein signal beim Wechsel zwischen o und 1 nicht "sauber schaltet, sondern erst etwas prellt (mechanische kontakte von relais, tastern,...) dann will man das entprellen weil man zb. im programm flanken von diesem signal auswertet. bei einem prellenden signal kommen bei jedem signalwechsel mehrere flanken.

interessant ist nur die erste siganlflanke, die ist sofort da wenn man eine SA nimmt. den weiteren flanken ist die SA überlagert.


FILTERN:
wenn ein sensor peaks bringt die nicht als plausibel gelten, dann werden diese ausgefiltert. dein beispiel mit dem schwappenden füllstand ist da sehr gut. aber auch bei analogen messungen verwendet man filter um kurze messpitzen auszublenden.

ein digitales signal filtert man am einfachsten über eine SE, gültig ist ein signal nur wenn es länger TRUE ist als die zeit der SE. alles andere kommt nicht durch.




> Ich hatte schon die Überlegung ganz auf die Timer zu verzichten und einfach mit dem Systemtakt (OB oder Taktmerker) ein INT hochzuzählen, bei einem bestimmt Wert den Merker zu setzen und wenn das Eingangssignal verschwindet herunterzählen und bei 0 wieder rücksetzen.


das habe ich früher auch oft gemacht.
vorteil: du hast beliebig viele timer und sie sind instanzierbar (FBs)
Nachteil: maximale genauigkeit 100ms + sps zyklus

und der code wird sehr aufgeblasen wenn du nicht gerade eine extra FC dafür schreibst.



inzwischen verwende ich nur noch die IEC timer (zähler):

Vorwärtszählen mit dem SFB 0 "CTU"
Rückwärtszählen mit dem SFB 1 "CTD"
Vorwärts- und Rückwärtszählen mit dem SFB 2 "CTUD"
Erzeugen eines Impulses mit dem SFB 3 "TP"
Erzeugen einer Einschaltverzögerung mit dem SFB 4 "TON"
Erzeugen einer Ausschaltverzögerung mit dem SFB 5 "TOF"

schau dir die sfbs mal an, die lassen sich einfach als multiinstanzen in den fbs aufrufen oder eben mit einen eigenen idb

die sind genauer und noch komfortabler, abgesehen voll IEC 61131-3 konform. und ebenfalls unbegrenzt vorhanden.

und im gegensatz zu dem s7 timer und counter müll gehen zb die counter bis 32787 (s7 counter 999) und die timer können auch wesentlich mehr (einige tage).




> Spart man sich den ganzen Timerkram.


 
im prinzip sind alles timer, nur eben verschieden arten.

die definitiv beste lösung sind die IEC timer.

weitere vorteil von dem IEC kram, wenn du damit arbeitest fällt dir eventuell später der umstieg/einstieg in ein ICE system wie beckhoff oder codesys leichter...


----------



## moeins (16 Mai 2008)

Markus schrieb:


> das habe ich früher auch oft gemacht.
> vorteil: du hast beliebig viele timer und sie sind instanzierbar (FBs)
> Nachteil: maximale genauigkeit 100ms + sps zyklus
> 
> und der code wird sehr aufgeblasen wenn du nicht gerade eine extra FC dafür schreibst.


Ja das ist sinnvoll. Ich mache für solche Sachen generell immer FCs.




> die definitiv beste lösung sind die IEC timer.
> 
> weitere vorteil von dem IEC kram, wenn du damit arbeitest fällt dir eventuell später der umstieg/einstieg in ein ICE system wie beckhoff oder codesys leichter...


Vielen Dank, ich werde es mir mal anschauen!


----------

