Entprellen von Reedkontakten, Zähler

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe noch keinen Wasserzähler gesehen, der Pulse in kHz ausgibt
das größte Problem ist da meist nur die "Kürze" des Pulses

 

[the_muck]

ohne besondere Massnahmen direkt an normale Digitaleingänge angeschlossen

So habe ich es auch gemacht . Aber damit ist es eben nicht so "sicher" wie mit schnellen Zählern/Interrupts. Vorteil bei der Wasseruhr ist aber das High/Low ja relativ lange anliegt. Ich wäre sensortechnisch auch lieber in die vollen gegangen aber geht halt nicht immer .

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ohne besondere Massnahmen direkt an normale Digitaleingänge angeschlossen

So habe ich es auch gemacht . Aber damit ist es eben nicht so "sicher" wie mit schnellen Zählern/Interrupts.

"So irrsinnig schnell wie möglich erfassen" ist manchmal kontraproduktiv. Die an das Signal angepasst "langsame" Erfassung/Abtastung des Signals ist sogar "sicherer" als der Versuch, das verprellte Signal mit schnellem Zähler oder Interrupt zu zählen.

Beispiel: Wenn der Puls von der Wasseruhr mindestens 1 ms lang ist und die Pause zwischen den Pulsen auch mindestens 1 ms lang ist und das Prellen kürzer als 1 ms lang dauert, dann spielt das Prellen überhaupt keine Rolle, wenn man das Signal nur alle 1 ms abtastet! Weil man da ja nur höchstens einmal während dem Prellen die Flanke des Signals abtastet - da ist es aber egal, ob man das Prellen bei 1 oder 0 "erwischt". Man sieht den Signalwechsel lediglich 1 ms früher oder später. Also kurz gesagt: nicht schneller abtasten als das Prellen dauert. Und das machen SPS mit Prozessabbild einfach so Einmal im Zyklus den aktuellen Eingangszustand erfassen/abtasten. Deshalb spielt Kontaktprellen normalerweise keine Rolle bei der SPS-Programmierung. Es sei denn, man will irrsinig kurze Zykluszeiten erreichen oder verprellte Signale mit schnellen Zählern erfassen.

 

[Onkel Dagobert]

Nicht umsonst gibt es für Zähler die genormte S0-Schnittstelle. Diese S0-Impulse sollten bei normalen Zykluszeiten für einen gewöhnlichen Digitaleingang überhaupt kein Problem darstellen. Die durch die Zykluszeit mehr oder weniger starken Schwankungen kann man, wie es weiter oben schon erwähnt wurde, mit einem PT1-Glied glatt bügeln.

 

[Onkel Dagobert]

... Aber damit ist es eben nicht so "sicher" wie mit schnellen Zählern/Interrupts...

Du hast doch mit deiner Problemstellung schon bewiesen, was sicher und was nicht sicher ist. Oder was meinst du mit "sicher"?

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die durch die Zykluszeit mehr oder weniger starken Schwankungen kann man, wie es weiter oben schon erwähnt wurde, mit einem PT1-Glied glatt bügeln.

Genau das ist ja mehr oder minder das Thema. Hier sind die Schaltungen ja auch nett beschrieben... (Wunderte mich das Würth das macht)

https://www.we-online.com/catalog/media/o185480v410%20SN015_Contact%20debounce%20circuit%20for%20switches.pdf

Also wenn das Programm schwankende Zykluszeiten hat oder es später Erweiterungen gibt, dann ist die "sichere" variante ja Schnelle Eingänge oder Interrupts die neben dem Programm laufen. Dafür muss ich das Signal aber Aufbereiten.
Bei normalen DIs muss ich eine Feststellung treffen das die Zykluszeit ausreichend ist, dafür brauche ich die Eigenschaften des Signals die ja nicht Statisch sind mit dem alter. Im Programm bräuchte es dann hinweise wann es durch Änderungen an die grenzen der möglichen Zykluszeit geht. Was ich dann nicht Abgefangen habe sind Veränderungen des Prellenden Signals, außer ich berücksichtige den Verschleiß auch in meinem Programm irgendwie statistisch...

Ich dachte eben das es Komponenten gibt die als eine art Beobachter das Signal beurteilen wie ein Mensch am Oszi, nur eben dauerhaft. Man lernt es an und das Gerät beurteilt dann ob das Signal noch in einem Fenster ist oder nicht, und Interpretiert dann den Impuls.

Die Komponente gibt dan an die SPS eben noch den Fehler weiter "Signal nicht OK" bei verschlissenem Kontakt oder ähnlich.

Debouncing Contacts and Switches

Debouncing switches and contacts is surprisingly subtle. This page shows actual bounce characteristics of a number of switches and gives code to debounce them.

www.ganssle.com

in meinem Bild sind es ja nur 0,2ms. 10ms sind wohl bei Tastern nicht unüblich.


Abschließend kann man vielleicht sagen, das ihr es mit einem Normalen DI umsetzt und keinen großen Film von macht . So bin ich ja auch verfahren. Wenn doch, dann Sensor wechseln... Wie gesagt ist das IMHO ein Akademisches Problem. Mich hats einfach interessiertwie ihr es macht.

 

[Chräshe]

Ja, hörte sich bisher sehr akademisch an.
Ein paar Gedanken im Voraus können jedoch nie schaden. Du hast die Trägheit der Hardware, die Zyklus-Zeiten der Software und die Pulszeiten des Signals.
Diese 3 Werte müssen in einem günstigen Verhältnis stehen.
Wenn man Faktor 10 an Sicherheit verwendet, muss man nicht bei jeder Programm-Änderung nachrechnen.

 

[PN/DP]

Im Programm bräuchte es dann hinweise wann es durch Änderungen an die grenzen der möglichen Zykluszeit geht.

Oder dafür sorgen, dass die Zählerpulse Zykluszeit-unabhängig abgetastet werden, z.B. in einem zyklischen Weckalarm-OB (OB3x) alle 1 ms die Eingänge direkt aus der Peripherie einlesen und verarbeiten, oder noch besser: nur die Erfassung der Zählerpulse in eine eigene CPU auslagern, deren Programm sich später nicht mehr geändert/erweitert wird - sozusagen eine ET200 mit intelligenter Signal-Vorverarbeitung.

Bei mir waren das vor Jahren 44 Wasserzähler, die ich mit eigenen S7-200 erfasst habe. Die S7-200 fungieren als Vorzähler mit einem "Umlaufzähler" 1 Byte oder 1 Word, und per MPI werden diese Vorzähler-Zählerstände in die Haupt-SPS eingelesen und die Zählerstand-Änderung (Differenz) seit dem letzten einlesen zum eigentlichen Zählerstand addiert. Sehr Zykluszeit-unkritisch. Und diese dezentrale Lösung mit extra CPUs hat noch den Vorteil, dass die Haupt-CPU auch mal ein paar Minuten in Stop sein kann, ohne dass in der Zeit Zählimpulse verloren gehen. (Ich meine, ich hatte das hier im Forum schon mal erklärt, finde das aber gerade nicht wieder, nur dies: Impuls über Profibus weitergeben)

Heutzutage kann man dieses dezentrale Zählen z.B. mit S7-1200 und Profinet realisieren. Zu ähnlichen Preisen wie eine normale Digitaleingangskarte.

Hinweis: die Zählerstände in einem eigenen Global-DB speichern, der später nicht mehr angefasst wird, damit der vor Überschreiben und Reinitialisierung von TIA geschützt ist.

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zählerpulse in eine eigene CPU auslagern

Da sind wir uns ja einig, das ist meine beschriebene Komponente als Beobachter. Aber es wäre ja super wenn die mehr kann als eine S7-1200. Eben wesentlich detaillierte Signalverarbeitung mit mehr Fehler Erkennung beim Verschleiß oder ähnlich der Kontakte.

 

[Onkel Dagobert]

Genau das ist ja mehr oder minder das Thema. Hier sind die Schaltungen ja auch nett beschrieben... (Wunderte mich das Würth das macht) ...

Ich dachte bei PT1 natürlich vorrangig an einen softwareseitigen Tiefpass.

... Im Programm bräuchte es dann hinweise wann es durch Änderungen an die grenzen der möglichen Zykluszeit geht. Was ich dann nicht Abgefangen habe sind Veränderungen des Prellenden Signals, außer ich berücksichtige den Verschleiß auch in meinem Programm irgendwie statistisch...

Man könnte den Impuls auch in verschiedenen Tasks zählen und die Zählerstände oder Impulsabstände vergleichen.

... Heutzutage kann man dieses dezentrale Zählen z.B. mit S7-1200 und Profinet realisieren...

So getan bei einer Anlage zur Energieoptimierung. Eine S7-1200 erfasst verschiedene Impulse vom EVU-Stromzähler. Über Profinet-LWL werden sowohl diese Impulse als auch die daraus ermittelten Rechenergebnisse an eine entfernte Anlage übertragen. Dort wird alles noch einmal aus den Impulsen berechnet. Allerdings war das keine permanente Überwachung, sondern nur als Maßnahme zur Inbetriebnahme gedacht, um Unregelmäßigkeiten zu erkennen. Überwacht wird hingegen die Profinet-Verbindung über einen Watchdog und das Ausbleiben der Zähler-Impulse.

 

[JesperMP]

Das würde sicher bis knapp über 500Hz funzen. Aber 40kHz doch nicht. Oder?

PS: ICH RUDERE ZURÜCK
Das 40kHz Signal ist das Prellen*, bin da falsch abgebogen.

So hatte ich zuerst auch das Oszi Bild interpretiert.

Es hätte geholfen wenn der TE ein Bild mit die volle Pulsform angezeigt hatte.
Dann konnte man auch die realen Puls und Pauselängen sehen und davon entscheiden wie schnell das Signal abgetastet werden muss.