Moin, ich bin auf der Suche nach einem Ersatz für Drehencoder mit Taster von Bourns Typ PEC11R-4225F-S0024. Ich habe mehrere von denen aus der Bucht mit Filterplatine gekauft. Technisch ist an denen nichts auszusetzen. Aber: Die Auswertung ist recht aufwändig, da der Geber die Zustandsänderungen zwischen den Rastungen hat und ich nicht mit Interrupts arbeiten kann. Auf jedem Rastpunkt sind A und B auf High-Potential. Mein AVR-ASM-Programm fragt nun 50x alle 2 ms die Spuren ab und speichert diese Werte im SRAM. Dann werden diese 50 Werte auf eine entsprechende Änderungsabfolge analysiert und dann eben Links- oder Rechtsdrehung erkannt. Das funktioniert sehr gut ist aber auch Zeitaufwändig... Ich habe optische Geber von Bouns vom Typ EM14A1D-C24-L008S. Die sind für die Auswertung ganz einfach, da auf jedem Rastpunkt A und B definiert sind 11 01 00 10. Nachteil: Zu teuer. Was ich nun suche ist ein etwas hochwertigeren mechaniscen Drehencoder mit Taster, der mir auf jeden Rastpunkt wie der EM14A1D-C24-L008S definierte Zustände ausgibt. Mein Preismaximum ist so 5 EUR/Stück. was könnt Ihr empfehlen? Holger
Holger schrieb: > Mein AVR-ASM-Programm fragt nun 50x alle 2 ms die Spuren > ab und speichert diese Werte im SRAM Wozu? Wenn dein Programm die Zustände ungleich 11 erfassen kann, dann kann man das ja auch mit einer Zustandsmaschine direkt auswerten, ohne mehr zu speichern als den letzten Zustand. Georg
Genau, Software überarbeiten. Interrupts (ausser dem Timer) braucht es dafür nicht. Schau mal hier in die Codesammlung. Alles ganz easy und zuverlässig.
Holger schrieb: > Aber: Die Auswertung ist recht aufwändig, da der Geber die > Zustandsänderungen zwischen den Rastungen hat und ich nicht mit > Interrupts arbeiten kann. Das muss man nicht verstehen, oder? Es ist doch nur gut, wenn die Umschaltung zwischen den Rastungen stattfindet, sonst zappelt der Wert auf der Rastung - je nach Temperatur, Wetterlage und Tagesform. Das will keiner. > was könnt Ihr empfehlen? Wenn du unbedingt einen wackeligen Wert brauchst, kann es helfen, die beiden Phasensignale zu tauschen. Da kein vernünftiger Anwender das braucht, ist der Umschaltpunkt für die zweite Phase, bezogen auf die Rastposition allerdings vom Hersteller meist nicht genauer spezifiziert, i.e. du kannst "Glück" haben oder auch nicht.
Moin, wie üblich wird rumgemäkelt ohne überhaupt irgend eine Kenntnis vom Restprogramm zu haben ... Leute Leute. Ich brauche eine Empfehlung für Drehencoder. Holger
Holger schrieb: > Ich brauche eine Empfehlung für Drehencoder. Holger schrieb: > Aber: Die Auswertung ist recht aufwändig, Dein Problem scheint doch die Auswertung zu sein ... Alle 2ms die beiden Signale abzufragen und in einen Zustandsautomaten mit 4 Zuständen reinzufüttern, ist doch nun nicht so schlimm. Und da muss auch nichts 50x alle 2ms abgefragt werden, sondern 1x reicht.
Holger schrieb: > wie üblich wird rumgemäkelt Ok, hat sich erledigt, wer nicht will der hat schon. Frechheiten müssen wir uns nicht bieten lassen. Georg
Leute? Wo ist Eurer Problem eine einfache Frage zu beantworten? Ich habe nicht gefragt, was ist an meiner Problemlösung scheiße! Viele Lösungen sind gut und auch kürzer im Code. Das ist aber nicht Gegenstand meiner Frage. Ich habe einfach keine Timer mehr frei für einen 2 ms - Poll. Und wenn, wie ich ja schrieb, meine Lösung funktiert, dann muss man dazu doch eigentlich nichts sagen. Aber in diesem Forum scheint das ja so üblich sein. @Georg (Gast) Verstehst Du den Inhalt meines ersten Posts überhaupt? Holger
https://www.reichelt.de/Drehimpulsgeber/STEC11B03/3/index.html?ACTION=3&LA=446&ARTICLE=73913&GROUPID=3714&artnr=STEC11B03&SEARCH=encoder Mit taster, Abstastung wie gewollt. Dauerte 1 min. Wie suchst du im internet? Gruß J
Moin fpga, vielen Dank. Den habe ich auch gefunden. Aber taugt der auch was? Ich fragte ja nach einer Empfehlung. Holger
Holger schrieb: > Ich habe einfach keine Timer mehr frei für einen 2 ms - Poll. Dann hast du da vielleicht irgendetwas ungünstig organisiert. Irgendeinen Millisekunden- oder Sonstwas-Timer braucht man meist doch sowieso meist. Warum kannst du den nicht mit nutzen? - Womit beschäftigst du deine Timer? - Wie ist der minimale zeitliche Abstand zwischen zwei Codeworten deines Inkrementalgebers?
>Aber taugt der auch was?
Wie definierst du das?
Gruß J
Holger schrieb: > Aber taugt der auch was? Ja, der ist toll! Passt aber vermutlich auch nicht zu Deiner komischen Software. Ist im übrigen nicht unser Problem, sondern Deins :-) Und: Du möchtest das Problem unbedingt aus unerfindlichen Gründen behalten. Wieso sollen wir Verständnis dafür haben? Gruß Jobst
Moin, oha. Ich habe es kapiert! Wenn ich es nicht so mache, wie man es hier will oder üblicherweise handhabt, ist man halt zu blöd. Daher: Großes Redesign. Jahaha extra für Euch! Nun aber zwei Fragen: 1. Ich nehme den STEC11B03. Der Controller ist ein ATMEGA mit 8 MHz. Angenommene Zeitdauer von Schritt zu Schritt 1 Sekunde: Wie hoch muss die Abfragefrequenz sein? 2. Wie 1 nur Schritt zu Schritt 1/10 Sekunde. Wie hoch muss die Abfragefrequenz sein? Holger
Jobst M. schrieb: > Passt aber vermutlich auch nicht zu Deiner komischen Software. Moin, das ist ja Quatsch. In den 100 ms erfasse ich doch jegliche A/B-Zustände und kann die Übergänge ausfiltern. Holger
Irgendwie ist dein Ton immer noch nicht so dolle - naja, vielleicht bist du ja einfach so.... 1. Ich benutze den PEC11L in Massen, da gibts keine Probleme mit. Ob da so grosse Unterschiede zum PEC11R sind? Bei mir sind am Rastpunkt jedenfalls abewechselnd beide H oder beide L. Ist aber letzten Endes wurscht. 2.Läuft an einem ATTiny, Timmerinterrupt 1ms mit vielleicht 0,5% Prozessorauslastung (geschätzt, eher weniger). Schau ich jetzt aber nicht genau nach.
>Wie 1 nur Schritt zu Schritt 1/10 Sekunde. Wie hoch muss die >Abfragefrequenz sein? Min. doppelt so hoch: https://de.wikipedia.org/wiki/Nyquist-Shannon-Abtasttheorem Du bleibst noch eine Antwort schuldig. Gruß J
Holger schrieb: > Angenommene Zeitdauer von Schritt zu Schritt 1 Sekunde: Wie hoch muss > die Abfragefrequenz sein? So hoch, dass du beim Drehen jedes Codewort sicher mindestens einmal erfasst. In dem Bild Wikipedia-Bild mit den Rechtecksignale also häufiger als alle 90°. https://de.wikipedia.org/wiki/Inkrementalgeber#Signalauswertung Zeig einfach mal im Zeitdiagramm, was du als Schritt bezeichnest. Bei Inkrementalgebern mit Rastung liegen die Rastpunkte - übertragen auf das Diagramm in 180° Abstand.
H.Joachim S. schrieb: > Irgendwie ist dein Ton immer noch nicht so dolle - naja, vielleicht bist > du ja einfach so.... Moin, wenn man eine simple Frage nicht beantwortet bekommt und wie ein Blödmann dargestellt wird nur weil man einen anderen Ansatz hat. Warum ist das so ein großes Problem? Und meine erster Text war ja wohl anständig formuliert - oder? Nun mal weg vom Encoder-Typ zur Abfrage. Wenn ich 100x pro Sekunde abfrage, dann bekomme ich nicht unbedingt bei einem Schritt ein Pegelwechsel mit. Ich würde auch noch einen zweiten Abfragen. Reichen da 1 ms? Wie sieht es mit Sprüngen oder dem nicht erkennen von Pegelwechseln von Schritt zu Schritt aus? Holger
Du liest ja nicht mal die Antworten. Helf dir selbst.
Mein letzter Beitrag hier Holger schrieb: > Mein AVR-ASM-Programm fragt nun 50x alle 2 ms die Spuren > ab und speichert diese Werte im SRAM. Dann werden diese 50 Werte auf > eine entsprechende Änderungsabfolge analysiert und dann eben Links- oder > Rechtsdrehung erkannt. Das funktioniert sehr gut ist aber auch > Zeitaufwändig... Dort liegt der Hund begraben, das ist gelinde gesagt Schwachsinn in höherer Ausprägung. Du bist der Meinung, das funktioniert gut. Aber eben nur nur mit einem bestimmten Encodertyp, der dir aber wiederum zu teuer ist. Jetzt willst du, dass andere für dich Encoder suchen oder finden mit Eigenschaften, die eigentlich sonst keiner braucht. Alle sagen dir - mach es einfach richtig, so wie es 1000fach funktioniert (alle anderen Ansätze, Flankenerkennung im Interrupt auf einem oder gar beiden Kanälen) sind regelmässig zum Scheitern verurteilt, wenn die Encoder etwas abgenutzt sind. Kommt immer wieder mal einer vorbei, der das Rad neu erfinden möchte (bei mir funktioniert es super...) Du willst es nicht hören oder begreifen (weil dein Ansatz ja so gut funktioniert)? Und rede nicht von Zeitproblemen, wenn du Zeit hast 50mal die Eingänge zu lesen und wegzuspeichern und nachträglich zu analysieren. Es gibt KEINEN Grund, es anders machen zu wollen als das hier in der Codesammlung stehende Verfahren, ich glaube von Peter Danegger - hast du es dir denn überhaupt mal angeschaut?? Und jetzt geh hin und schau dir das an. Ansonsten ist jede weitere Diskussion hier müssig.
H.Joachim S. schrieb: > Aber eben nur nur mit einem > bestimmten Encodertyp, der dir aber wiederum zu teuer ist. Moin, warum willst Du meinen Text nicht richtig lesen? Und dann bin ich schwachsinnig? Bitte? H.Joachim S. schrieb: > hast > du es dir denn überhaupt mal angeschaut?? Jo. Ist aber C und ich programmiere nur in Assembler. Ich habe schlicht weg keine Lust auf C umzustellen. Außerdem selber schreiben bringt ja meistens mehr als abschreiben. Zu Sache. Habe jetzt mal einen 1 ms-Interrupt eingebaut und frage den Encoder ab. Drehung nach rechts: 10 00 01 11 Drehung nach links: 01 00 10 11 Egal wie schnell ich drehe. Immer kommen die entsprechenden Reihenfolgen. Die minimale Geschwindigkeit ist durch das Moment, welche beim Überwindung der Reibung der Rastung bestimmt und dafür reichen 1 ms gut aus. Holger
Holger schrieb: > Und dann bin ich schwachsinnig? Du doch nicht. Nur der Lösungsansatz. Jeder kann mal einen schwachen Moment haben. Und das mit der Pufferung im RAM war so einer: Symptombekämpfung statt Ursachensuche. Holger schrieb: > Wenn ich es nicht so mache, wie man es hier will oder üblicherweise > handhabt, ist man halt zu blöd. Man kann es natürlich auch anders machen, wenn das denn besser funktioniert. Allerdings ist es immer eine gute Idee, einen bereits tadellos funktionierenden Ansatz zu verstehen und dann verbessern. Holger schrieb: > Jo. Ist aber C und ich programmiere nur in Assembler. Ich habe schlicht > weg keine Lust auf C umzustellen. Ja und, zum Verstehen des Prinzips musst du ja nur die zehn Zeilen C-Code lesen können. So viel Phantasie traue ich dir zu. Man muss sich halt mal auf was Neues einlassen... ? Holger schrieb: > was könnt Ihr empfehlen? Nimm ein Oszi und miss die Signale. Das ist der allererste Schritt in so einem Fall. Denn sonst kannst du nur raten. Insbesondere, ob die Abtastung mit 1ms tatsächlich schnell genug ist... BTW, kennst du diese alte Redewendung: Wie man in den Wald hineinruft schallt es wieder heraus.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.