Seltsames Phänomen mit Gabellichtschranken

[Moppi]

wieso ich einen CHANGE-Interrupt überhaupt entprellen soll.... Nach meiner Logik ist das völlig unnötig- und es stimmt auch.

Du hattest schon selber mal an anderer Stelle mechanische Probleme angeführt, vielleicht erinnerst Du Dich.

Ich habe tatsächlich auch mal drüber nachgedacht, einen C anzulöten. Habe aber darin keinen Sinn gesehen. Ich habe mir Anfangs die Impulse auch mit einem Oszi angesehen und nichts gesehen, was mich verwundert hätte. Dies wären nur Signale, die zwischen LOW-und HIGH wechseln, also die mit ihrem Ausschlag diese Schwellen überschreiten. Man müsste dann auch wissen, welche Frequenz man filtern möchte. Bei den 3D-gedruckten Scheiben, wie die, die ich benutze, kommen noch Eigenheiten durch Ungenauigkeit des 3D-Drucks hinzu. Bzw. auch des Schrittmotors, eventuell fällt der in eine Vollschrittposition zurück, nachdem die Lichtschranke schon einen Signalwechsel hatte, was im ungünstigen Fall auch zu einer Doppelzählung führen kann. Ähnliche Probleme könnten auch bei normalen DC-Motoren auftreten, wenn die erst einmal Gewicht transportieren. Und wenn es durch das Profil oder andere Eigenheiten der Räder zustande kommt, dass nach Anhalten das Rad ein Tick zurückdreht. Dies Wackeln ist dann aber mechanisch bedingt.
Ich glaube aber, auf einen Tick mehr oder weniger kommt es dann praktisch nicht unbedingt an. Das hat auf eine Regelung kaum Einfluss. Wenn erst mal Hindernisse überfahren werden, könnte auch, wenn man zwischendrin stoppen muss, ein Zurückrollen stattfinden und wieder hat man mehr Ticks gezählt. Auch aufgrund der Belastung beim Überfahren von Hindernissen könnte man unterschiedlich viele Ticks zwischen den Rädern zählen. Vieles lässt sich dann auch durch Software kompensieren, wenn ein C hilft, ist es aber auch gut. Zumindest kann man in Zukunft daran verstärkt denken und schauen, ob ein C was nützen würde.

MfG

[Rabenauge]

Sehe ich ähnlich.
Ich meine, im Grunde ist es eine rein mechanische Lösung (und nich eben die beste, dazu müssten die Encoder wenigstens am Motor sitzen, und nich erst am Getriebeausgang).
Wenn sich Freddie II bewährt, kriegt der ordentliche TT-Motoren rein (die dann vielleicht auch mit Encodern am Motor, gibts ja welche bei DF robot).
Die jetztigen sind ohnehin recht schnell (ich musste mit der PWM runter auf 70, um die Radumdrehungen überhaupt mitzählen zu können).
In dem Link zu dem Blog waren Oszi-Screenshots, die das mit den Ripples zeigen, wenn man in höhere Auflösung umschaltet.

Heut muss ich erstmal arbeiten, aber danach schaue ich mal, wie präzise das jetzt wirklich funktioniert.

[Moppi]

Ich habe mir das jetzt mal ganz genau angeschaut, also so weit reingezoomt, wie es mir möglich war, ist eben nur ein günstiges Oszi. Ich habe das Signal im Betrieb gemessen, als die Motoren liefen. Dabei habe ich tatsächlich etwas gefunden, ich denke, das ist das, was in dem andern Beitrag auch gemeint war. Hier mal die Bilder:

Bild hier  

Ich habe extra einen 100nF raus gesucht. Auf dem Breakout ist ein LM393 verbaut, mit zwei Komparatoren. Die erzeugen aber oft kein eindeutiges Signal auf der Platine. Der Ausgang springt auch mal schnell hin und her. Weiter rein zoomen in den zeitlichen Verlauf kann ich mit meinem Oszi nicht und erst dort sehe ich das. Die Ausschläge sind auch sehr groß. Dieses Verhalten zeigt sich bei fallenden und steigenden Flanken. Mit einem nachgeschalteten 100nF sieht es dann besser aus. Wie es aussieht, überbrückt er die Zeit, in der diese unerwünschten Zustände aufreten.

Nachtrag:

Noch was, folgend, wie ich dieses Signal per Software auswerte.
Ich arbeite mit einer variablen Frequenz über einen Timer. Ähnlich wie das Oszi eigentlich, nur mit einer viel geringeren Auflösung (diese Frequenz bestimmt die Schrittgeschwindigkeit meines Motors). Maximal kann ein Intervall der ISR aber etwa 10µs kurz sein (meist viel länger).
Beim ersten Auftreten des Timer-Interrupts frage ich das Signal der Lichtschranke ab, wenn das nicht denselben Zustand hat (0 oder 1), wie bei der letzten Abfrage, wird dieser Wechsel (von 0 auf 1 oder 1 auf 0) nicht gezählt. Also die erste Abfrage erfolgt und das Signal wird gespeichert, bei Zeitpunkt "0". Bei Zeit "10µs" erfolgt die nächste Abfrage, ergibt die dasselbe Ergebnis, wird dieses Ereignis gezählt. Damit muss ein Signal stabil für mindestens 10µs anliegen. Ist das Signal vor den 10µs ein anderes, als danach, wird der neue Zustand, nach den 10µs, gespeichert, aber das Ereignis eben nicht gezählt. Je langsamer die Motoren drehen, desto größer wird der Zeitabstand bis zum Erfassen des Eingangszustandes. Somit habe ich die Entprellung, die man hier, für das oben gezeigte Beispiel, auch durch einen Kondensator bekommen kann.

[Rabenauge]

Auch ne Idee, deine Entprellung....die merk ich mir mal.

Zu deinem Oszi: ist das so ein DSO 138?
Das Ding interessiert mich nämlich auch...

[Moppi]

Ja, DSO Shell und irgend eine Nummer bei der Firmware. Letztens hatte ich Probleme wollte, zwei Signale vergleichen. Hat aber keine zwei Tastköpfe. Das ist nur ganz einfach gehalten, mit Kroko-Klemmen. Wenn man das Oszi mit Batterie betreibt, bekommt man weniger Störungen im Signal, da ist ein Netzteil dazu, aber dann hat man eben mehr Störungen. Das DSO liefert nie eine saubere stabile Nulllinie, da ist immer irgendwas dabei. Muss man sich dran gewöhnen. Vielleicht kaufe ich mal ein etwas Besseres, als dieses.

MfG