Ich möchte einen relative Inkrementalgeber mit 4096 Strichen pro Umdrehung mit 100kHz abtasten...um einen Winkel zu erechnen. Ich habe bisher eine Lösung gesehen wo die beiden Spuren auf eine TTL Logik geführt wurden...wo dann mittels 4 Bit Counter gezählt wurde. Der Zählstand steht dann auf 12 Datenleitungen zur Verfügung. Dies finde ich sehr aufwendig..und da ich 3 Inkrementalgeber abfragen muss komme ich ja auch mit den Pins beim ATMEGA32 (den möchte ich verwenden) gar nicht hin. Meine Frage an Euch: Kann ich die beiden Spuren A und B nicht einfach direkt auf den MC führen und von da mit 100 kHz abtasten und auswerten? Brauche ich diese aufwendige TTL Schaltung?
Klar kannst du das, nur wird der ATmega nicht mehr so viel anderes machen können.
Ja nur wenn ich 3 Inkrementalgeber abgragen muss...wobei jeder nachher 12 Pins für den Zählerausgang hat...dann hab ich ja nachher 36 Pins nur für die Eingänge der Inkrementalgeber...das ist ja irre? da bräuchte ich ja auch dementsprechend einen anderen Prozessor?
Du hast pro Geber 16 Mhz/100 KHz/3 (160/3 Takte) Zeit. Könnte funktionieren (Assembler). Einfach einmal durchrechnen. Eventuell einen 20 MHz AVR nehmen oder z. B. auf einen ARM umsteigen.
>Ja nur wenn ich 3 Inkrementalgeber abgragen muss...wobei jeder nachher >12 Pins für den Zählerausgang hat...dann hab ich ja nachher 36 Pins Naja, falls du wirklich Parallel machen willst, kannst du auch achtmal den 74HC165 zum einlesen nehmen. Da würden dann drei Pins reiche, statt 36... Oder falls du sowieso nen Datenbus, könntest du auch mit Latches (74HC541) diese Info direkt in den SRAM mappen.. Aber egal wie, du brauchst einiges an Standart-Logik-ICs. Deshalb wären andere Maßnahmen zu überlegen...
Ich habe hier noch einige CF32007NT (!RoHS) zu liegen. Es sind 24Bit Zähler mit Inkrementaleingängen und 4-fach Auswertung. Gegen Portoerstattung würde ich sie Dir schenken. Ein paar 74HCT2000 wären auch noch auffindbar. Eine alternative wäre, pro Kanal einen ATtiny oder Mega48 einzusetzen und die Daten vom Mega32 auszulesen. Bei 100kHz schafft man, nur einen einzigen Kanal auszuwerten, und auch nur dann, wenn andere Interrupts nicht zugelassen werden.
> Du hast pro Geber 16 Mhz/100 KHz/3 (160/3 Takte) Zeit.
Es sollte etwas mehr Zeit zur Verfuegung stehen weil man
alle sechs Leitungen an einem Port anordnen kann und dann
beim einlesen auswerten einiges parallel laufen kann.
Ich halte das schon fuer machbar.
Die Frage ist nur warum 100kHz. Deshalb weil sich die Encoder
so schnell drehen koennen, das dies notwendig wird? Oder
muss so oft der Winkel ausgerechnet werden. Im letzeren
Fall wuerden mir auch leichte Bedenken kommen.
Haengt dann wohl noch von der notwendigen Aufloesung ab,
also passen Tabellen ins Rom oder muss man rechnen.
Olaf
wieso braucht ein 4 Bit Counter 12 Datenleitungen? Du wirst um eine anständige Quardaturauswertung nicht drumrumkommen, wenn du ein stabiles System willst. Stell dir vor, die Achse ist im Stillstand um "zittert" dabei genau über 1/4 increment. Dann können da Frequenzen auftreten, die größer sein können, als deine Frequenzen im "normalen" Betrieb. Und wenn du dann mit 100kHz abtastest, könnte sein, dass der Herr Shannon da ganz gewaltig was dagegen hat und du nicht mehr aussagen kannst, was für eine Art von Bewegung da genau stattfindet ;-) Ich kenn den Atmega nicht, aber wenn er Capture-Compare Units hat (mit up/dn-Umschaltung) dann setz nen externen Quadraturenocder und zähl mit diesen Einheiten. Wenn nicht, dann setz externe Quadraturencoder mit Counter und mappe diese in den Adressbereich des µC
ne ein 4 Bit Counter hat natürlich nur 4 Ausgänge ...aber von dem bräuchte ich ja 3 Stück (Synchrones Zählwerk) um den Zählbereich abzudecken. ...Also meinst du ich könnte Beispielsweise einen GAL Programmieren mit der Auswergung der Richtung (4 Zustände) ... und gehe von diesem GAL nicht auf den Zähleingang des ersten Counters sondern direkt auf den Microcontroller?
@Olaf ja die 100kHz habe ich so gewählt weil angenommen wird, dass die Änderung der Encoder scheibe bei max. 40kHz liegt.
>..Also meinst du ich könnte Beispielsweise einen GAL Programmieren mit >der Auswergung der Richtung (4 Zustände) ... und gehe von diesem GAL >nicht auf den Zähleingang des ersten Counters sondern direkt auf den >Microcontroller? Ob du das kannst, weiß ich nicht ;-) Denkbar wäre das. Da könntest du die µC-Anbindung sinnvollerweise als 8bit, oder als SPI machen... Aber ob das in einen GAL reinpasst, kann ich nicht beurteilen. Hier im Wiki gibts jedenfalls eine geeignete "GAL-Schaltung" http://www.mikrocontroller.net/articles/Drehgeber#Dekoder_mit_diskreten_Logik-ICs
>...Also meinst du ich könnte Beispielsweise einen GAL Programmieren mit >der Auswergung der Richtung (4 Zustände) ... und gehe von diesem GAL >nicht auf den Zähleingang des ersten Counters sondern direkt auf den >Microcontroller? Ja, wobei es noch besser wäre, wenn du gleich extern zählen würdest. Aber so wie es aussieht, willst oder kannst du nicht genügend Pins spendieren. Ich würd dann an deiner Stelle entweder über ein GAL (oder CPLD) die Quadratursignale auswerten (es gibt auch fertige ICs, die das machen). Kleine FSM, mit 4 Zuständen, die pro Zustand einen Impuls ausgibt und ein Up/Down-Signal (je nach Drehrichtung) Diese Zählimpulse würde ich auf einen INT-Eingang des µC geben und im Interrupt je nach Stand des Up/down-Signals einen SW-Zähler inkrementieren oder dekrementieren.
ja ok...also die Eingänge des Microcontrollers dann über ein Timerinterrupt ständig abfragen..?
nee nicht ständig, sondern immer dann, wenn ein Takt vom Qadraturencoder kommt, einen INT auslösen und im INT den zustand des Richtungssignals abfragen und entsprechend den Zähler verändern (+ oder -) Problem wird nur ggf da du 3 unabhängig laufende Encoder hast, die natürlich auch mal gleichzeitig nen INT auslösen könnten. Wenn du dann nach der Abarbeitung des einen zum nächsten springst und dort das Richtungssignal abfragst, musst halt sicherstellen, dass das dann noch den gleichen Wert hat, wie zum Zeitpunkt, als der INT auftrat.
Externer Interrupt ist die schlechteste Lösung, ein zitternder Eingang legt den Controller lahm. 100 kHz Abtastrate per Timer-Int sind 80 Takte bei 8 MHz internem Takt, das dürfte (in ASM) machbar sein, aber dann ist nicht mehr viel Spielraum für andere Aufgaben. Ich würde mit einer 16 Byte großen LUT arbeiten, deren Index aus dem aktuellen Pinstatus und dem gemerkten vom letzten mal besteht. ...
>Externer Interrupt ist die schlechteste Lösung, ein zitternder Eingang >legt den Controller lahm. stimmt! Also doch reines Sampling der beiden Spuren und komplette Auswertung im µC oder eben die externe Zählerlösung und Übertragung der Daten mittels (z.B) SPI
>@lippy: Dann sind wir wieder ganz am Anfang von Thread ;-)
Nicht ganz. Am Anfang störten ihn dabei die vielen Leitungen. Mögliche
Lösungen wurden schon gebracht
ok vielen dank...ich glaube die externe Zählung wird evt. am effektivsten sein...dann muss ich nur mal gucken wie ich den Zählerstand in den MC bekomme... habe noch nie mit SPI gearbeitet...nur mal gehört. Muss mich da mal schlau machen. danke schonmal!
@Gasst Wenn das Angebot noch steht würde ich gerne darauf zurückkommen!
> ja die 100kHz habe ich so gewählt weil angenommen wird, dass die > Änderung der Encoder scheibe bei max. 40kHz liegt. Ist das die Frequenz, die der Geber maximal kann, oder die in deiner Anwendung tatsächlich maximal auftritt? Falls ersteres der Fall ist, ist dein Gedankengang nicht der richtige. Du musst dir statt dessen Gedanken darüber machen, welches die maximal zu erwartende Drehzahl ist. Dann wirst du evtl. feststellen, dass du mit wesentlich weniger als 100kHz Abtastfrequenz auskommst. Oder aber du stellst fest, dass die 40kHz des Gebers schon zu wenig sind. 40kHz bei 4096 Strichen entspricht einer maximalen Drehzahl von 10/s. Und um die 40kHz Signalfrequenz voll auszuschöpfen, reichen die 100kHz Abtastfrequenz am µC nicht, da brauchst du mindestens 160kHz. Vielleicht reicht aber auch eine geringere Auflösung als die 4096 Striche, dann genügt auch eine geringere Abtastfrequenz des µC. Meist ist es nämlich so, dass man entweder hohe Drehzahlen hat oder eine hohe Winkelauflösung braucht, aber nicht beides gleichzeitig. Lass dir die Anforderungen also noch einmal durch den Kopf gehen. Die Alternative mit dem externen Zähler ist auch nicht so trivial, wie sie zunächst erscheint, es sei denn, du nimmst einen Spezialbaustein wie den von Gasst angebotenen 74HCT2000. Wenn du so etwas mit einfachen Binärzählern aufbauen willst, musst du u.a. dafür sorgen, dass der µC nicht gerade zu dem Zeitpunkt den Zähler ausliest, wenn dieser gerade weiterschaltet. Das geht zwar, macht die Schaltung aber schon wieder ein Stück komplizierter. > ne ein 4 Bit Counter hat natürlich nur 4 Ausgänge ...aber von dem > bräuchte ich ja 3 Stück (Synchrones Zählwerk) um den Zählbereich > abzudecken. Der Zähler muss nicht unbedingt eine komplette Umdrehung des Gebers abdecken. Wichtig ist nur, dass der µC den Zählerstand oft genug ausliest, um Mehrdeutigkeiten im Ergebnis zu vermeiden. Ist s die Anzahl der Striche, N die Drehzahl und b die Bitbreite des Zählers, muss die Abfragefrequenz mindestens
betragen. Die direkte Abfrage des Gebers entspricht einem b von 2. Mit einem 4-Bit-Zähler kannst du somit die minimale Abfragefrequenz schon um den Faktor 7 veringern.
VIELEN DANK FÜR DIE AUSFÜHRLICHE ANTWORT!!!! Das wird mir schonmal was weiterhelfen...werde mir über die Sache nochmal den Kopf zerbrechen :-) Nur ich kann die max. Geschwindigkeit nicht vorhersagen...oder jedenfalls schwierig...da es sich hierbei um eine Ansteuerung eines inversen Pendels handelt... habe noch keine Ahnung welche maximalen Geschwindigkeiten auftreten können ?
Gesetzt den Fall es geht um eine Positionierung wäre es natürlich auch möglich, absolute Drehgeber zu benutzten. Diese liefern Dir einen Wert der direkt proportional zum Winkel ist. Nur im Falle einer Geschwindigkeitsregelung würde ich bei Inkrementalgebern bleiben. Für schnelle Anwendungen sind Drehgeber mit SSI-kompatiblen Schnittstellen empfehlenswert. Diese haben Takt- und Datenleitungen (RS485/RS422). Um die Position abzufragen erzeugt man einen Takt und liest dann das aktuelle Datenbit ein, das wiederholt man solange bis man alle Datenbits eingelesen hat. Wenn Du einen Port für alle Datenleitungen benutzt und die Drehgeber synchron taktest, kannst Du die Datenbits von allen 3 Drehgeber gleichzeitig einlesen. Wenn es denn ABSOLUT Inkrementalgeber ;-) sein müssen, würde ich auch mal über einen alternativen Mikrocontroller nachdenken! Ich habe jetzt auf Anhieb keine Typbezeichung im Kopf, aber Microchip z.B. bietet Mikrocontroller mit einer Hardware-Schnittstelle für Inkrementalgeber an.
Habe gerade erst in Deinem letzten Beitrag gesehen, das es um ein inverses Pendel geht. Also wenn es ein einfaches inverses Pendel ist (ein einfach gelagerter Stab, der in 2 Richtungen fallen kann), müßtest Du aber auch mit nur einem Inmrementalgeber klar kommen. Die Position erfaßt Du über das Zählen der Inkremente, und die Geschwindigkeit berechnest Du über einen digitalen Differenzierer. Diese beiden Eingangssignale sollten genügen.
>und Position des "Wagens"
Ich kenn den Versuch inverses Pendel selber..
Aber die Position des Wagens wird doch nicht aus dem Winkel ermittelt...
>@Gasst >Wenn das Angebot noch steht würde ich gerne darauf zurückkommen! Kläre bitte ab, was Du genau brauchst. Ich würde mich freuen, wenn Du meine Teile noch einsetzen könntest. Falls nicht, möchte ich sie nicht nutzlos verschicken. Noch etwas Allgemeines: um zu hohe Eingangsfrequenzen von einer Auswerteschaltung abzuhalten, bieten sich D-FFs zur Synchronisierung an. Wird an CLK 100kHz angelegt, kann die Änderung von D nach Q auch nur mit max. 100kHz erfolgen. Ein zitterndes Signal kann so den µC nicht per Interrupt lahmlegen.
Ja möchte das mit den Bausteinen schon gerne machen...und die Zählung komplett extern. Diese benötige ich auf jeden Fall. Stelle mir nur noch die Frage wie das mit dem Prozessor aussieht. Also ob ich vielleicht einen nehme mit genügend I/O Pins... oder ob ich den Zählerstand irgendwie seriell in den Controller bekomme. Aber das werde ich schon noch herausbekommen. Wir müssten uns dann nur mal die Adressen austauschen...etc.!? ...und vielen Dank für den Tip mit dem Einsynchronisieren...das habe ich bereits eingeplant.
@ Gasst (Gast) >Wird an CLK 100kHz angelegt, kann die Änderung von D nach Q auch nur mit >max. 100kHz erfolgen. Ein zitterndes Signal kann so den µC nicht per >Interrupt lahmlegen. Klar, weil ja auch 100 kHZ Interruptfrequenz Peanuts sind . . .
"...und vielen Dank für den Tip mit dem Einsynchronisieren...das habe ich bereits eingeplant." besser gesagt....hatte ich mit eingeplant. Wenn ich die Bausteine bekomme benötige ich das ja normalerweise eigentlich gar nicht mehr!?
@Falk, für Dich wiederhole ich gerne, was ich oben schon geschrieben habe: >Eine alternative wäre, pro Kanal einen ATtiny oder Mega48 einzusetzen >und die Daten vom Mega32 auszulesen. >Bei 100kHz schafft man, nur einen einzigen Kanal auszuwerten, und auch >nur dann, wenn andere Interrupts nicht zugelassen werden. Es sind auch nach meiner Auffassung keine Peanuts. Das Maximum was ein ATmega bei 16MHz Takt zuläßt, sind Flankenwechsel ca. alle 2,5µs: per Assemblerprogramm und mit reservierten Registern.
@ Gasst. Soll ich meine Email posten, damit du mir deine zuschicken kannst`?
>Soll ich meine Email posten, damit du mir deine zuschicken kannst`?
Hallo Christian, das wäre gut. Allerdings werde ich erst kommende Woche
wieder erreichbar sein.
> Stelle mir nur noch die Frage wie das mit dem Prozessor aussieht. Also > ob ich vielleicht einen nehme mit genügend I/O Pins... oder ob ich den > Zählerstand irgendwie seriell in den Controller bekomme. Aber das > werde ich schon noch herausbekommen. Wenn du die Bausteine von Gasst nimmst, brauchst du bei 3 Stück etwa 13 I/O-Leitung am Controller, nämlich 8 x D Daten (D0-D7) 1 x CLK Takt (Timer-Ausgang des Controllers) 1 x A0 Auswahl High-/Low-Byte 3 x /RD Auswahl eines der drei Bausteine --- 13 Alle Leitungen bis auf /RD werden für alle drei Bausteine gemeinsam genutzt. Damit solltest du bei entsprechender Programmierung von jedem der drei Geber den Zählerstand mit 16-Bit Auflösung auslesen können und hast beim ATmega32 noch 19 I/Os frei für andere Dinge.
> Kann mal jemand von dem Teil ein Datenblatt posten? Ich finde keines.. Ich auch nicht. Die Dinger stammen noch aus der Steinzeit. Eine Neuauflage mit ein paar kleinen Änderungen gibt es hier: http://www.adronic.biz/produkte/peparts/index.php
HCT2000 stammen echt aus der Steinzeit Zwischendurch waren mal HCTL2016 aktuell, hab die oft sehr erfolgreich eingesetzt, da meine Prozessoren damals zu langsam waren. Die heutigen uP sind um einiges schneller. Schau mal den PIC18F2431 der hat sogar so nen Teil auf dem Chip. Kannst ihn über I2C auslesen oder per UART. Obs die HCTL2016 noch gibt, entzieht sich meiner Kenntnis.
Wo ein Datenblatt zu finden ist, hat yalu ja schon gezeigt. Der Anschluß an einen µC ist jedoch simpel, wenn beispielsweise ein 8051-Derivat oder ein ATmega64 verwendet wird, die externes IO/RAM mit Adress- und Datenbus sowie /RD-/WR unterstützen. >Die heutigen uP sind um einiges schneller. Schau mal den PIC18F2431 der >hat sogar so nen Teil auf dem Chip. Kannst ihn über I2C auslesen oder >per UART. Die CF32007 (THCT12024) können bis 20MHz zählen. Die Signale von Inkrementalgebern können bis 5MHz (1/4 Taktfrequenz) betragen, wenn ich mich richtig erinnere. Und der µC/µP kann die Daten (24Bit) in rund 200ns auslesen. Das schafft kein PIC/MIC/MAX/MORITZ: weder über IIC noch über UART. Wenn man z.B. schnelle Drehbewegungen zu definierten Zeitpunkten abtasten und erfassen muß, kommt man an solchen Bausteinen nicht vorbei. Eine Alternative würden FPGAs bieten, die diese Bausteine nachbilden. Für anspruchsvollere Anwendungen würden sich µCs von z.B. Renesas anbieten. H8S, H8SX, und SH Serien bieten jeweils zwei Inkremental-Eingänge mit 16-Bit Zählern, die auf 32-Bit erweiterbar sind.
@Gasst ich habe mich jetzt nochmal ausführlich über die Sache informiert...bei den Geschwindigkeiten bzw. Frequenzen komme ich um externe Zählbauseteine nicht rum. Ist es möglich die HCT2000 bzw. HCTL2016 gegen Bezahlung der Unkosten zu erhalten? Das wäre echt super...würde mich freuen!
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.