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
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?
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.
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
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.
