Sensorentprellung

Zuviel Werbung?
-> Hier kostenlos registrieren
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 ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :rolleyes:
 
Entschuldigung, war wohl schon zu später Stunde.
Natürlich müsste es so heissen:

Code:
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
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich würde es so machen ... ist nicht so spektakulär ... aber es funzt ...
Code:
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 ...
 
da is vor 53 stunden 13 minuten auch schon einer draufgekommen ... [/streiche]bis auf den einen tippfehler :rolleyes:[streiche] [ergänze]die großen tippfehler ... alsofast drauf gekommen [/ergänze] ...danke larry
 
Zuletzt bearbeitet:
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
Code:
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.
 
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.
 
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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!
 
Zurück
Oben