Inkrementalgeber

[bartolomeos]

Hallo,
Habe einen Motor wo ein Inkrementalgeber an der Welle sitzt und wollte die Position ermitteln.
Wie kann ich den Inkrementalgeber anders auswerten,
weil was ich jetzt habe verzählt er sich manchmal. Es ist unterschiedlich mal 1, 3, oder 6 oder mehr inkremente und von Programmieren habe ich nicht so die ahnung wegen der Geschwindikkeit. Die Impulse was da rauskommen sin ca. 10kHz 100 Inkremente pro Umdrehung.
Hier ist eine Skitze wie ich es auswerte
https://www.roboternetz.de/phpBB2/album_pic.php?pic_id=752

und der link zum Inkrementalgeber RE30-2
http://www.dunkermotoren.de/data/technical_data/series/pdf/RE.pdf#page=1
wie kann ich den Geber anders auswerten

Grüsse,

Bartolomeos

[Manf]

Häufig liegt es auch nur an der Versorgungsspannung wenn Zähler mehrere Impulse zählen anstelle von einem.
Ist die Versorgungsspannung der Zähler mit Kondensatoren (100nF) nahe beim IC abgeblockt?
Manfred

[Vogon]

Hast du dir das schon mal angeschaut ?
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=88467#88467

[bartolomeos]

Aber wie Baue ich die Schaltung nach?

[Manf]

Ich habe mal in der Schaltung oben nachgesehen, auf welche Flanken die CLK der 7474 und 74191 reagieren. Es ist beides die positive Flanke.

Ohne Berücksichtigung der Laufzeit des 7474 (die 6ns beträgt) ändert sich damit der Zustand des Signals U/D während der aktiven Flanke an CLK beim 74191.

Das wird so nicht geplant sein, oder wie ist das zu verstehen?


Maßnahmen für die einfache Schaltung:
Die Signale a und b sollten jeweils über Schmitt Trigger geführt werden.

Inversion eines der beiden Signale CLK für 7474 oder CLK für 74191 (altenativ eine Verzögerung eines der beiden CLK Signale um 100ns).

Bei Betrachtung des Zustandsdiagramms wird deutlich, dass bei der einfachen Schaltung für die unterschiedlichen Richtungen nicht die Übergänge zwischen den gleichen Zuständen ausgewertet werden. Damit kann bei einer Richtungsänderung ein Fehler von einem Inkrement auftreten.
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=88467#88467
Manfred

[Hellmut]

Hallo Manfred

Ich werde in meiner Anwendung ebenfalls mit Dunkermotoren und dem Inkrementalwertgeber wie hier aufgeführt arbeiten. Der hier genannte Inkrementalwertgeber liefert aber noch ein drittes Signal, "sync". Das ist sowohl hier wie bei der hier referenzierten Diskussion nicht berücksichtigt worden.

Ich plane die Auswertung durch einen mega8 mit einem externen 16MHz Clock zu implementieren. Die Pegeländerungen am sync-Signal sollen ein Interrupt auslösen, die Interrupt-Service-Routine wartet dann per "BITWAIT"-Befehl vom BASCOM ob zuerst Signal a oder b eintrifft und kennt daraus sowohl Richtung wie auch das ein Impuls vom Inkrementalwertgeber gekommen ist. Nur zur Information, der Befehl BITWAIT in Bascom erkennt je nach gesetztem Parameter steigende oder fallende Flanken an einem Pin.

Die Dunkermotoren mit dem hier genannten Inkrementalwertgeber laufen im Allgemeinen maximal mit 50 biz 60 Umdrehungen pro Sekunde und bei meinen Inkrementalwertgebern mit 512 Impulsen pro Umdrehung ergibt das zwischen 25kHz und 30kHz. damit hat der Controller etwa 500 Clock-Zyklen um diese Impulse unter Softwaresteuerung zu zählen und die Positionsvariable zu pflegen.

Da ich mit dem Interrupt auf das Sync-Signal reagiere und bisher davon ausgehe das das Impulstripel vom Inkrementalwertgeber immer vollständig erscheint, also Sync und dann a+b, oder b+a, je nach Richtung, bin ich eigentlich der Meinung das der Zählfehler durch Richtungsänderung nicht eintritt. Habe ich da recht?

Da ich mit diesen Dunkermotoren und ihren Inkrementalwertgebern diverse mechanische Systeme steuere, die, wenn die Mechanik über die Endstellungen hinweglaufen würden, mein Modellsegelboot im Bruchteil einer Sekunde z.B. das Bug abscheren würden, bin ich am Thema Zuverlässigkeit der Positionsbestimmung sehr interessiert. Zur Sicherheit arbeite ich noch mit Endstellungsschalter um immer wieder diese als Korrelationspunkte zur Sicherstellung der aktuellen Position meiner Mechanik verwende und auch Notabschaltschaltungen vorsehe. Eurer Thread und der referenzierte sind daher für mich sehr bedeutsam!

[PicNick]

In dem referenzierten Thread ist es vornehmlich um die logische analyse der Inkrementalgeber-Signale gegangen, nicht sosehr um die technische Umsetzung. Natürlich ist auch eine Softwarelösung möglich, doch nimmt die Edge-detection den Controller ganzschön in Anspruch. 500 Cycles sind nämlich schneller abgefackelt, als man meint. Das Pushen und Poppen der Register für einen Interrupt braucht mehr als 120 Cycles und da hast du noch garnix gemacht. Auch das einfache inkrementieren von mehrbytigen Variablen geht ins geld. Von einer effektiven Auswertung red' ich garnicht.
Da tut ein bißchen Hardware-unterstützung ganz gut.

[Manf]

Die Inkrementalgeber arbeiten berührungslos und verschleißfrei.
Eine Leuchtdiode, eine metallische Schlitzscheibe
und ein Fotodiodenarray bilden eine Lichtschranke.
Eine interne Logik erzeugt aus dem Signal der
Fotodioden zwei um 90° verschobene Rechtecksignale,
ohne bzw. mit Referenzimpuls.
Den Referenzimpuls kann man man als gemeinsames Signal zur Anzeige von Änderungen des Quadraturcodes von a und b nehmen. Während das Indexsignal aktiv ist sollen a und b stabil sein.
Sonst kommt man auch mit a und b alleine aus.

Ordnet man die vier Zustände von a und b in einem Kreis an (oder im Quadrat wie beim Zustandsdiagramm), dann sieht man leicht den Ablauf bei der Änderung einer Position. Wertet man jeden Zustandsübergang in der richtigen Richtung aus dann gehen auf logischer Ebene keine Zustandsänderungen verloren.

Setzt man eine vereinfachte Auswertung ein, die nicht alle Zustandsänderungen erfasst sondern wie beispielsweise im Bild nur jeweils einen der vier möglichen in jeder Richtung, dann kann man eine Bewegung in jeweils einer Richtung sauber erfassen, aber wie man leicht im Diagramm erkennt, eine Bewegung, die begiebige Richtungsänderungen beinhaltet, kann zu Zählfehlern führen.
Manfred

[Hellmut]

Hallo Robert

Ich werde in naher Zukunft mal genau messen wie sich die Lösung per Interrupt versus der Lösung mit BITWAIT verhält. Nach der Literatur, das Buch "Mikrocontroller Lehrbuch" von Roland Walter, ist die mögliche Auflösung der Impulsmesungslänge höher wenn diese per Interrupt i9mplementiert wird. Aus diesen Grund mache ich mir überhaupt die Mühe die funktionierende Lösung bei der Messung der Impulslänge vom RC-Empfänger für die Dekodierung des Inkrementalwertgebers umzuschreiben.

Mir ist es außerdem vorgekommen das die hier besprochenen Hardware-Lösungen wesentlich teuerer als so ein mega8 sind!?

[PicNick]

Wie so oft, kommt's auf die Details an.
Grad bei einem Motor ist es ja nicht so, daß der einfach zwischen zwei ticks die Richtung wechselt.
Aber zumindest die edge-detection würde ich schon eher mit HW machen.
Teurer ? ich weiß ehrlich gesagt nicht, was die paar Logik-Gatter kosten, ich selbst hab so Zeugs immer auf Halde und kauf nie einzeln.
Aber man muß ja ev. auch die Platinen-entwicklung /Fertigung berücksichtigen.
WIe oben gesagt, die Details machen's.