Forum: Analoge Elektronik und Schaltungstechnik Reedkontakt am Gaszähler funktioniert nicht korrekt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johnny S. (sgt_johnny)


Lesenswert?

Hallo zusammen,

Ich habe vor einigen Tagen an meinem Gaszähler (Honeywell BK-G4M) einen 
Reedkontakt (ELV ES-GAS-2) angeschlossen.

Der Sensor beinhaltet einen Reedkontakt der bereits im Sensor mit 
Widerständen versehen ist.

Mein Problem ist nun folgendes:
Der Sensor zählt falsch.

Beispielsweise habe ich folgende Zählerstände abgelesen:

Start: 145.637m3
Ende: 153.647m3
Verbraucht: 9.01m3

Bei 0.01m3 per Reed/Impulse würde dies 901 Impulse ergeben. Der Sensor 
hat aber 933 übermittelt.  Ein fehler von 32 Impulsen und somit 0.3m3.

Was aber das Spannende ist:

Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende 
Logik im MCU verbaut habe:

- Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen 
wenn der Magnet "vorbeigefahren" ist.
- Nach Interrupt einen Debounce von 10 Sekunden.
- Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um 
sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor 
"steht"
- Setzen eines neuen Impulses

Somit ist meiner Meinung nach ausgeschlossen, das es sich um ein 
elektrisches Prellen handelt. Betrachtet man den Kontakt des Reeds mit 
dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell).

Zusätzlich:
In meiner Auswertung per MQTT habe ich mir die jeweiligen Einzelimpulse 
welche übermittelt werden angesehen, auch dort kein Hinweis auf Prellen, 
da  nie ein Impuls direkt nach dem Ablauf des Debounce kommt. Zwischen 
jeder Übermittlung vergehen >20 Sekunden (30s wenn man den Debounce 
zählt), bis hin zu Minuten. Die Minimale Zeit zwischen Impulsen die ich 
gesehen habe, ist ca 20 Sekunden unter "Vollast". Beim theoretischen 
maximalen Gasverbauch von 1.8m3/h wären es genau alle 20s ein Impuls


Daher ist es für mich schon sehr fragwürdig an was das noch liegen 
könnte.
Hat jemand eine Idee die man noch probieren könnte?

von Falk B. (falk)


Lesenswert?

Johnny S. schrieb:

> Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende
> Logik im MCU verbaut habe:

HAHA!

> - Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen
> wenn der Magnet "vorbeigefahren" ist.

Soso, und du kannst hellsehen?

> - Nach Interrupt einen Debounce von 10 Sekunden.

Jaja, Angstenprellung, weil man keine Ahnung hat.

> - Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um
> sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor
> "steht"

Aha.

> - Setzen eines neuen Impulses

Kaum, denn das macht der Reedkontakt.

> Somit ist meiner Meinung nach ausgeschlossen, das es sich um ein
> elektrisches Prellen handelt.

Träumer.

> Betrachtet man den Kontakt des Reeds mit
> dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell).

soso, "nahezu". Was ist "Prell"? oder meinst du eher Prellen?

> Daher ist es für mich schon sehr fragwürdig an was das noch liegen
> könnte.
> Hat jemand eine Idee die man noch probieren könnte?

Machs mal Old school, OHNE Flanken-Interrupt, mit normalem 
Timer-Interrupt und der Entprellroutine aus dem Artikel 
Entprellung. du wurst Staunen.

von Sebastian (Gast)


Lesenswert?

Johnny S. schrieb:
> Hat jemand eine Idee die man noch probieren könnte?

Zeichne mal für alle erkannten Impulse einen Zeitstempel mit auf. Oder 
untersuche die Impulse mit einem PC-Logikanalysator der einen längeren 
Zeitraum aufzeichnen kann.

LG, Sebastian

von hacker-tobi (Gast)


Lesenswert?

@falk b. In seinem Szenario kann diese sehr langsame Entprellung 
durchaus funktionieren, voraus gesetzt sie ist korrekt implementiert .

@jonny: Es muss sicher gestellt sein, das ein impuls nie doppelt gezählt 
wird, auch wenn mehrere Impulse nahezu direkt hintereinander kommen , 
z.b. noch während der Abarbeitung der ISR.
Kannst du das sicher Ausschließen?
Wird sicher gestellt, das die Register, in welchen der interrupt 
vermerkt ist, sauber zurückgesetzt werden und das weitere Interrupts 
sofort nach eintreffen des ersten blockiert werden ?

Ansonsten empfehle ich dir auch, vorzugehen, wie es Sebastian 
vorgeschlagen hat. Dann sollte sich doch schnell zeigen, was hier das 
Problem ist.

von Johnny S. (sgt_johnny)


Lesenswert?

Falk B. schrieb:
> Johnny S. schrieb:
>
>> Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende
>> Logik im MCU verbaut habe:
>
> HAHA!
>
>> - Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen
>> wenn der Magnet "vorbeigefahren" ist.
>
> Soso, und du kannst hellsehen?

Nein, das lässt sich mit einem Oszilloskop gut sehen, immer wenn sich 
das Zählerrad auf der letzen Stelle über 0 dreht, wird ein Impuls 
ausgelöst. Der Kontakt wird geschlossen und öffnet sich wieder. Das 
Signal wechselt von 0V auf 3.3V und dann wieder auf 0V

>> - Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um
>> sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor
>> "steht"
>
> Aha.
Dies hatte ich festgestellt, wenn der Verbauch zufällig beim wechsel von 
9 auf 0 sich stark verlangsamt, dann bleibt der Eingang mehre Sekunden 
auf 3.3V


>> Betrachtet man den Kontakt des Reeds mit
>> dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell).
>
> soso, "nahezu". Was ist "Prell"? oder meinst du eher Prellen?
>
Ich erkenne beim Wechsel des Eingangs von 0 auf 3.3V ein leichtes 
Prellen, dies zeigt sich aber nur durch abfallen der Spannung auf ca. 
2.5-2.7V, nicht komplett auf 0. Da der ESP32 logisch-null erst bei 
0.25*3.3V registiert, sollte dieses prellen keinen Einfluss haben, und 
ist ja auch über den Code abgefangen.

Sebastian schrieb:
> Johnny S. schrieb:
>> Hat jemand eine Idee die man noch probieren könnte?
>
> Zeichne mal für alle erkannten Impulse einen Zeitstempel mit auf. Oder
> untersuche die Impulse mit einem PC-Logikanalysator der einen längeren
> Zeitraum aufzeichnen kann.
>
> LG, Sebastian

Die Zeitstempel habe ich grundsätzlich, da diese ja beim Einfügen in die 
Datenbank des Telegramms genommen werden.




hacker-tobi schrieb:
> @falk b. In seinem Szenario kann diese sehr langsame Entprellung
> durchaus funktionieren, voraus gesetzt sie ist korrekt implementiert .
>
> @jonny: Es muss sicher gestellt sein, das ein impuls nie doppelt gezählt
> wird, auch wenn mehrere Impulse nahezu direkt hintereinander kommen ,
> z.b. noch während der Abarbeitung der ISR.
> Kannst du das sicher Ausschließen?
> Wird sicher gestellt, das die Register, in welchen der interrupt
> vermerkt ist, sauber zurückgesetzt werden und das weitere Interrupts
> sofort nach eintreffen des ersten blockiert werden ?

Das habe ich so gut wie möglich versucht zu verhindern, auch habe ich 
keinen Impuls gefunden, der direkt nach Ablauf des Debounce übermittelt 
wurde, es sind immer mindestens 20-30 Sekunden dazwischen.

Hier die Codeauschnitte:
1
 void IRAM_ATTR ISR() {
2
   detachInterrupt(12);
3
   isInterrupted= true;
4
}
1
 void handleInterrupt(){
2
    if(isInterrupted){
3
      client.publish("sensors/gas01/count", "1");
4
      client.publish("sensors/gas01/rssi", String(WiFi.RSSI());
5
      isInterrupted = false;
6
      isDebounce = true;
7
      lastDebounce = millis();
8
}
1
 void handleDeboune(){
2
     if(isDebounce){
3
       if(millis()> (lastDebounce+10000){
4
         if(digitalRead(12) == LOW){
5
          isDebounce = false;
6
          attachInterrupt(12, ISR, FALLING);
7
         }
8
        }
9
       }
10
}

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Johnny S. schrieb:
> Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende
> Logik im MCU verbaut habe:

prust *gacker* Ich hole mir schon mal eine Portion Popcorn.

von Stefan F. (stefanus)


Lesenswert?

Vielleicht empfängst du Radiowellen. Beim Schalten von induktiven Lasten 
entstehen manchmal ziemlich starke Wellen, die ungewollte Reaktionen in 
deiner Schaltung auslösen können.

Ich hatte auf diesem Weg mal ungewollt sporadische Resets bei einem 
Mikrocontroller. Damals hatte ich nicht erwartet, dass 5 cm offene 
Leiterbahn so eine gute Antenne sein können. Solche Fehler macht man nur 
einmal, wenn man sie verstanden hat.

Zeige mal den Schaltplan. Verwendest du ein abgeschirmtes Kabel, und wie 
lang ist es?

: Bearbeitet durch User
von Carsten-Peter C. (carsten-p)


Angehängte Dateien:

Lesenswert?

Hallo, genau dieses Problem habe ich auch mit meinem Zähler. Derzeit 
hatte ich beim Bau keinen Reedkontakt rumliegen und habe einfach ein 
Reedrelais genommen.  Ähnlich wie dieses:
https://www.reichelt.de/reedrelais-1-wechsler-200-v-dc-0-5-a-litt-he721c1200-p241002.html?CCOUNTRY=445&LANGUAGE=de&trstct=pos_12&nbc=1&&r=1
Es kommt darauf an, den Kontakt möglichst genau zu positionieren. Am 
Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom 
Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist. Das 
Programm ist in Assembler geschrieben. Ausgewertet wird eine Flanke. Die 
Zählerwerte werden ausschließlich im ATtiny gespeichert und bei Bedarf 
abgefragt. Die Uhr läuft mit dem 2,.. Mhz Quarz erstaunlich genau.
Gruß Carsten

von Johnny S. (sgt_johnny)


Angehängte Dateien:

Lesenswert?

Hier auch noch ein kurzer Ausschnitt aus dem Log der letzten Stunde in 
Klammern die Zeit seit dem letzten Impuls

von A. B. (Gast)


Lesenswert?

Johnny S. schrieb:
> Start: 145.637m3
> Ende: 153.647m3
> Verbraucht: 9.01m3

Hm, sind das nicht eher 8.010m³ ???

von Winnie (Gast)


Lesenswert?

Johnny S. schrieb:
>
1
 void handleDeboune(){
2
>      if(isDebounce){
3
>        if(millis()> (lastDebounce+10000){
4
>          if(digitalRead(12) == LOW){
5
>           isDebounce = false;
6
>           attachInterrupt(12, ISR, FALLING);
7
>          }
8
>         }
9
>        }
10
> }

Die 10 Sekunden Abfrage muss so aussehen:
  if((millis() - lastDebounce) > 10000){

Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von 
(2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr, 
solange bis millis() wieder auf 0 geht.

Beispiel:
handleInterrupt(): lastDebounce = millis() = 2^32 - 10000
handleDebounce(): if((2^32-10000) > (2^32-10000 + 10000 = 0) ist immer 
true

von Wollvieh W. (wollvieh)


Lesenswert?

Als 7400 noch fünf Mark kostete, war Entprellung ein Problem. Aber im 
Jahre 2022?

von Thomas F. (igel)


Lesenswert?

Johnny S. schrieb:
> Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende
> Logik im MCU verbaut habe:

Ein Gaszähler bleibt ja auch mal stehen. Und wenn der Magnet dann gerade 
zwischen Nord und süd steht so kann ein Reed-Kontakt auch nach 10s 
prellen.

Ein bipolarer Hall-Sensor sollte da besser funktionieren:
https://www.tme.eu/Document/6752077a094d36387c89e99dd4fb98eb/SS41-datasheet.pdf

von Peter D. (peda)


Lesenswert?

Johnny S. schrieb:
> - Nach Interrupt einen Debounce von 10 Sekunden.

Du bist nicht der erste, der Delay mit Entprellen verwechselt. Man muß 
schon verstehen, wie ein externer Interrupt in der CPU arbeitet.

Ein arme Leute Entprellen mit Delay geht eingeschränkt, wenn man nach 
dem Warten erstmal das Pending Flag rücksetzt, bevor man den Interrupt 
wieder freigibt. Dabei beachten, daß manche CPUs das Flag verzögert 
löschen, d.h. nochmal etwas warten.
Ein Entstören (Schaltpulse in der Nähe) erfolgt allerdings damit nicht, 
das kann nur eine korrekte Entprellung mit Mehrfachabtastung per 
Timerinterrupt.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Winnie schrieb:
> Die 10 Sekunden Abfrage muss so aussehen:
> if((millis() - lastDebounce) > 10000){
+1

Johnny S. schrieb:
> Hier auch noch ein kurzer Ausschnitt aus dem Log der letzten Stunde in
> Klammern die Zeit seit dem letzten Impuls
Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran?

Carsten-Peter C. schrieb:
> Am Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom
> Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist.
Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt.

: Bearbeitet durch Moderator
von Thomas F. (igel)


Lesenswert?

Lothar M. schrieb:
> Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran?

Meine neue Gastherme - 1,5 Jahre alt - regelt tatsächlich kontinuierlich 
die Leistung. Solche Sprünge im Gasverbrauch sind da normal.

von Falk B. (falk)


Lesenswert?

Lothar M. schrieb:
>> Am Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom
>> Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist.
> Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt.

In der Tat 8-(

von J. S. (jojos)


Lesenswert?

dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen 
indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein 
Projekt auf github das sich schon vielfach bewährt hat.

von Thorsten S. (thosch)


Lesenswert?

J. S. schrieb:
> dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen
> indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein
> Projekt auf github das sich schon vielfach bewährt hat.

LOL!
Und du meinst ernsthaft, jemand, der schon mit einer trivialen 
Kontaktentprellung softwaretechnisch überfordert ist, bekommt die 
Software-Module für Kamera und AI zur Bilderkennung ans Laufen?

von Carsten-Peter C. (carsten-p)


Lesenswert?

Lothar M. schrieb:
> Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt.

Hallo, die gleiche SW nutze ich für die Auswertung der S0 Schnittstelle 
vom Stromzähler. Da läuft sie fehlerfrei. Es kommt auf die möglichst 
genauue Position des Reedkontaktes an.
Gruß Carsten

von Johnny S. (sgt_johnny)


Lesenswert?

Winnie schrieb:
> Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von
> (2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr,
> solange bis millis() wieder auf 0 geht.

Da hast du vollkommen recht, ist aber eher ein "Schönheitsfehler" da 
dieses Problem erst nach über 3 Jahren ununterbrochenem Betrieb auftritt 
;)

Lothar M. schrieb:
> Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran?

Es hängt die Heizung (Heizkörper) und Warmwasser dran und läuft 
tatsächlich ziemlich "unrund", was ja aber auch nicht falsch ist. Es 
gibt z.b. auch Abschnitte wo eine ganze Stunde nicht geheizt wird wenn 
z.b. kein warmes Wasser benötigt wurde, und die Temperatur im Haus 
stabil ist




Thorsten S. schrieb:
> J. S. schrieb:
>> dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen
>> indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein
>> Projekt auf github das sich schon vielfach bewährt hat.
>
> LOL!
> Und du meinst ernsthaft, jemand, der schon mit einer trivialen
> Kontaktentprellung softwaretechnisch überfordert ist, bekommt die
> Software-Module für Kamera und AI zur Bilderkennung ans Laufen?

Diese Projekte kenne ich und wären auch kein Problem zu realisieren, 
hatte bei unserem alten Stromzähler schon vor Jahren mit einm Raspi und 
einer Webcam gemacht, bevor dieser auf einen digitalen getauscht wurde.


Als nächsten Schritt werde ich jetz mal einige Stunden den Zähler mit 
einer Kamera aufzeichnen, um dann herauszufinden welche Impulse mit 
welchem Zeitstempel als "falsch" gezählt wurden, vielleicht gibt das ja 
Aufschluss.

von Falk B. (falk)


Lesenswert?

Johnny S. schrieb:
>> Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von
>> (2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr,
>> solange bis millis() wieder auf 0 geht.
>
> Da hast du vollkommen recht, ist aber eher ein "Schönheitsfehler" da
> dieses Problem erst nach über 3 Jahren ununterbrochenem Betrieb auftritt
> ;)

Das mit den Grundrechenarten müssen wir dann wohl noch ein wenig üben.

Eine 32 Bit Variable hat einen Maximalwert von 2^32-1, macht 4294967295. 
Bei einer Zählfrequenz von 1kHz erfolgt nach

4294967295 ms
4294967,295 s
1193,05 h
49,7 d

ein Überlauf.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Johnny S. schrieb:
> Lothar M. schrieb:
>> Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran?
> Es hängt die Heizung (Heizkörper) und Warmwasser dran und läuft
> tatsächlich ziemlich "unrund", was ja aber auch nicht falsch ist.
> Es gibt z.b. auch Abschnitte wo eine ganze Stunde nicht geheizt wird
Schon klar, mir fällt da nur dieses 1 Event mit 30 Sekunden inmitten der 
Minuten sehr ins Auge.

Johnny S. schrieb:
> Bei 0.01m3 per Reed/Impulse würde dies 901 Impulse ergeben. Der Sensor
> hat aber 933 übermittelt.  Ein fehler von 32 Impulsen
Also 1 fehlerhafter zusätzlicher Impuls unter 30 Pulsen. Sowas zeigt in 
etwa auch dein Screenshot vom Log...

: Bearbeitet durch Moderator
von Jens (Gast)


Lesenswert?

...einen externen Interrupt für einen prellenden Kontakt zu verwenden 
ist ein ganz schlechter Ansatz.

Den Pin mit maximal 1 ms pollen und vernünftig in Sofware entprellen, 
dann geht das auch.

VG
JJ

von Jester (Gast)


Lesenswert?

Falk B. schrieb:
> Machs mal Old school, OHNE Flanken-Interrupt, mit normalem
> Timer-Interrupt und der Entprellroutine aus dem Artikel
> Entprellung. du wurst Staunen.

Wie heftig prellen denn solche Reedkontakte?
Und im Vergleich dazu: Wie problematisch ist das Prellen bei benetzten 
Reedkontakten?

Vielleicht reicht ja schon ein kleines C / RC?

Aber Achtung: Reedkontakte reagieren allergisch auf kapazitive 
Belastung!

von ul5255 (Gast)


Lesenswert?

habe vor Jahren den Gaszaehler per Hall Sensoren ausgelesen (inzwischen 
Gas abgeschafft). Das hat erst dann sauber funktioniert, als ich zwei 
Sensoren ca. 90Grad versetzt angebacht habe (einen unter Zaehlerfenster 
und einen weiteren vorn auf Zaehlerfenster). Der Controller faengt an, 
die Umdrehung zu registrieren, wenn vom unteren Sensor der Zustand von H 
nach L wechselt, zaehlt aber nur 0.001m3 dazu, wenn darauffolgend auch 
der vordere Sensor von H nach L wechselt. Sobald der vordere Zaehler 
wieder L -> H geht, werden beide Sensorzustaende wieder auf Anfangslage 
zurueckgesetzt (Quadratur-Auslesung ???). Das Hauptproblem vorher war, 
das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo 
der Magnet drunter ist), und dann prellt das wie verrueckt.

von Jester (Gast)


Lesenswert?

ul5255 schrieb:
> Das Hauptproblem vorher war,
> das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo
> der Magnet drunter ist), und dann prellt das wie verrueckt.

Die magneto-mechanische Kontruktion muss schon stimmen, sonst kann sich 
das Problem recht sportlich gestalten.

Reedkontakte haben eine amtliche Hysterese fest eingebaut. Bei 
Hall-Sensoren ist das nicht sicher, kommt auf den genauen Typ an. 
Gestörte Betriebsspannung tut dann schnell den Rest ...

von ul5255 (Gast)


Lesenswert?

dann wuerde ich mit meinen Erfahrungen trotzdem zu zwei Reed-Kontakten 
mit aehnlicher Auswerte-Logik greifen, wenn ich das nochmal 
implementieren muesste (Gott sei Dank nicht notwendig)

von ul5255 (Gast)


Lesenswert?

Nachtrag:
wurde weiter oben bereits angesprochen, aber bei mir habe ich die 
Zustaende der Sensoren mit 1kHz (oder 100Hz ?, schon lange her) 
ausgelesen. Wenn die Brennwert-Therme den WW-Boiler beladen hat, hat die 
ziemlich viel Gas gezogen. Sonst "fliegt" das Zaehlrad am Sensor vorbei, 
ohne dass es der Controller bemerkt.

von Peter D. (peda)


Lesenswert?

ul5255 schrieb:
> Das Hauptproblem vorher war,
> das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo
> der Magnet drunter ist), und dann prellt das wie verrueckt.

Das dürfte dann ein analoger Hall-Sensor gewesen sein, d.h. die Spannung 
ist proportional zur Feldstärke. Den mußt Du mit einem ADC-Pin einlesen 
und eine Hysterese programmieren.

von Falk B. (falk)


Lesenswert?

ul5255 schrieb:


> wieder L -> H geht, werden beide Sensorzustaende wieder auf Anfangslage
> zurueckgesetzt (Quadratur-Auslesung ???).

BINGO! Siehe Drehgeber. Dann darf das Ding auch auf der Kippe stehen 
bleiben, die Schritte vor/zurück summieren sich nicht!

> Das Hauptproblem vorher war,
> das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo
> der Magnet drunter ist), und dann prellt das wie verrueckt.

EBEN!

Also braucht man zwei Reedkontakte für eine "kippelsichere" Auswertung.

von HolgerT (Gast)


Lesenswert?

ul5255 schrieb:
> Das Hauptproblem vorher war,
> das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo
> der Magnet drunter ist), und dann prellt das wie verrueckt.

Klingt unglaubwürdig. Reed-Kontakte zeigen deutliches 
Hystereseverhalten. Siehe auch 
https://www.conrad.de/de/o/reed-kontakte-0200190.html#charakteristik

von ul5255 (Gast)


Lesenswert?

HolgerT schrieb:
> Klingt unglaubwürdig. Reed-Kontakte zeigen deutliches
> Hystereseverhalten.

ich hatte Hall-Sensoren verwendet, die hatten auf der Platine bereits 
die Auswerte-Logik mit OpAmp und Sollwert-Vorgabe als Poti

von HolgerT (Gast)


Lesenswert?

ul5255 schrieb:
> ich hatte Hall-Sensoren verwendet

Tschuldigung, hatte ich übersehen. Hast aber auch geschrieben:

ul5255 schrieb:
> dann wuerde ich mit meinen Erfahrungen trotzdem zu zwei Reed-Kontakten
> mit aehnlicher Auswerte-Logik greifen, wenn ich das nochmal
> implementieren muesste (Gott sei Dank nicht notwendig)

von Johnny S. (sgt_johnny)


Angehängte Dateien:

Lesenswert?

Mittlerweilen habe ich herausgefunden, das die Fehlerhaften Impulse 
immer ca. bei der Zahl 3 auf dem Zähler generiert werden.

Auch habe ich heraugefunden, das der Sensor welcher vom Hersteller 
angeboten wird, als Standartversion und Version mit Alarm-Kontakt 
angeboten wird, der Alarmkontakt soll ermitteln wenn der Sensor 
demontiert wird. Hierzu gibt es wohl einen zweiten Magnet und zweiten 
Reed.

Rein vom Bild her, scheint mir der Kontakt vom ELV-Sensor anderst 
positioniert als der Orginalsensor. Ich vermute daher, das des dazu 
kommen könnte, das aus dem "vorbeifahrenden" Magneten und dem 
Sicherheitsmagneten irgendwie ab und zu der Reed Kontakt geschalten 
wird.

Ich werde nun einen Orginalsensor verbauen und prüfen.

Beitrag #7264418 wurde von einem Moderator gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.