Industrial Counter - Jitter, Debouncing, Value Change

[m.schmidt]

Hallo zusammen,

ich habe ein seltsames Verhalten von einem Industrial Counter:

Die Impulse kommen von einem 24V Netzteil, welches über einen Reedkontakt unregelmäßig mit ~3 Hz durchgeschaltet wird und ich möchte die einzelnen Perioden von Falling zu Falling Edge messen. Meistens klappt das gut und die Werte sind sinnvoll, ab und an wird aber eine zu kleine Periode (z.B. 100ms) und ein unrealistischer Duty Cycle Wert von 0,00% (??) oder 50,00% angezeigt. "Echte" Events haben größere Periodenlängen und einen Duty Cycle von ~60% mit zufälligeren Nachkommastellen.

Das Problem tritt nur beim Aufbau mit 24V und dem Reedschalter auf. Mit dem parallel geschalteten Oszi sehe ich keine Auffälligkeiten und keine zu kurze High/Low-Perioden bis auf etwas Überschwingen an den Flanken, welches aber im µs Bereich und in der Amplitude außerhalb des High/Low-Wechsels liegt. Bei einem "perfekten", regelmäßigen Signal von einem 20V Frequenzgenerator gibt es keine Probleme.

Jetzt bin ich mit meinem Latein am Ende:

1. der Prescaler ist ausreichend groß, so dass ein Counter Overflow ausgeschlossen sein sollte (z.B. 4096: Minimale Frequenz 0.36Hz, Auflösung 42.66us)
2. Ein Debouncing-Setting wie im Digital In Bricklet scheint es nicht zu geben?
3. Verschiedene Kanäle zeigen das gleiche Verhalten
 

Hat jemand eine Idee?

 

Eine Frage auch zu Callbacks bei Werteänderung:

Was ist mit Werteänderung gemeint, der value, d.h. der High-Low-Zustands des Kanals oder z.B. Periode bzw. Frequenz? Wenn ich den Abstand von Falling zu Falling Edge messen will, bräuchte ich im Idealfall einen Callback bei jedem Übergang von High zu Low (und nicht bei jeder Value-Änderung).
 

Zitat

BrickletIndustrialCounter.set_all_counter_callback_configuration(period, value_has_to_change)

Wenn der value has to change-Parameter auf True gesetzt wird, wird der Callback nur ausgelöst, wenn der Wert sich im Vergleich zum letzten mal geändert hat. Ändert der Wert sich nicht innerhalb der Periode, so wird der Callback sofort ausgelöst, wenn der Wert sich das nächste mal ändert.

...

Callback-Parameter:

duty_cycle – Typ: [int, ...], Länge: 4, Einheit: 1/100 %, Wertebereich: [0 bis 10000] period – Typ: [int, ...], Länge: 4, Einheit: 1 ns, Wertebereich: [0 bis 264 - 1] frequency – Typ: [int, ...], Länge: 4, Einheit: 1/1000 Hz, Wertebereich: [0 bis 232 - 1] value – Typ: [bool, ...], Länge: 4 https://www.tinkerforge.com/de/doc/Software/Bricklets/IndustrialCounter_Bricklet_Python.html#industrial-counter-bricklet-python-callbacks

 

bearbeitet September 6, 2021 at 16:56 von m.schmidt
Frage zu Callbacks hinzugefügt

[borg]

Bezüglich der Callbacks: Der Callback wird ausgelöst sobald sich irgendeiner der im Callback übergebenen Werte ändert verglichen zur letzten Auslösung.

 

Das Zählen und Messen der Periode, Duty Cycle etc übernimmt eine Hardwareeinheit des XMC1400, dort lässt sich leider kein Debounce-Wert konfigurieren.

Falls das möglich ist, könntest du um sicher zu gehen dass der Prozessor wirklich keine Glitches sieht, mit dem Oszilloskop einmal auf der Prozessorseite hinter den Optokopplern messen.

Dazu müsstest du vom Optokoppler (das sind die 4 Bauteile in der Mitte der Leiterplatte, je einer pro Kanal, mit 2 Pinnen unten zum Eingang hin und 3 Pinnen oben zum Prozessor hin) den mittleren Pin oben gegen GND messen. An GND kommst du am einfachsten über das Haltepad vom Bricklet-Stecker. Falls das Bricklet an einem Master Brick angeschlossen ist: Das Gehäuse des USB-Steckers ist auch GND.

Das ist dann das Signal welches der Prozessor wirklich als Eingang bekommt.

Andere Frage: Ist die Firmware auf dem Bricklet auf dem neuesten Stand?

[m.schmidt]

Danke für die Antwort!

Die Firmware sollte mit 2.0.5 auf dem neuesten Stand sein.

Dein Hinweis hinter dem Optokoppler zu messen hat mich nochmal auf die debouncing Problematik aufmerksam gemacht, der Reedschalter scheint kurz nach Betätigung noch einmal auf zu schwingen und auch wenn die vom Bricklet ausgegebene Periode nicht so ganz passt, ist das die naheliegenste Erklärung für die Glitches.

Ich werde mir wohl mal Gedanken über ein analoges Debouncing machen. Wenn ich die Periode auf ~100µs genau bestimmen will, ist die Variante ein Software Debouncing und Flankenzählung via Industrial Digital In Bricklet + Red Brick wohl zu langsam. (?)

Danke noch einmal.