Important announcement: there is an English version of this forum on
Datum:
Hallo Community, Wir haben ein Projekt bei dem wir eine Vierfach-Drehgeber-Auswertung mit µC realisieren sollen. Da wir alle jedoch noch keinerlei Erfahrungen damit haben kommen wir einfach nicht weiter. Könnte uns jemand erklären wie man vorgehen muss? Also nicht wie man es genau programmiert, sondern die allgemeine Vorgehensweise, was man beachten muss oder was sonst noch dazugehört. Wir haben schon versucht mithilfe eines Zaehlers die steigenden Flanken zu zaehlen, jedoch hat bislang noch nichts funnktioniert. Unsere Hardware: STK500 ATmega32 Hengstler Drehgeber mit 5000 Schritten/Umdrehung Wäre super wenn uns jemand weiterhelfen könnte =) Viele Grüße Olli
Datum:
Peter schrieb: > vll hilft der code..... > > http://www.mikrocontroller.net/attachment/1971/ENCODE.C Tut mir leid, aber den Code verstehe ich so ohne weiteres nicht. Könntest du vllt ein zwei Sätze dazu sagen warum man das ganze so programmiert hat?
Datum:
Olli ElPunkt schrieb: > Hengstler Drehgeber mit 5000 Schritten/Umdrehung Bei welcher Drehzahl sollen die Dinger denn laufen? Und sind das Absolut- oder Inkrementaldrehgeber (Typenbezeichnung)?
Datum:
Werner schrieb: > Olli ElPunkt schrieb: >> Hengstler Drehgeber mit 5000 Schritten/Umdrehung > > Bei welcher Drehzahl sollen die Dinger denn laufen? > Und sind das Absolut- oder Inkrementaldrehgeber (Typenbezeichnung)? Ist ein Inkrementalgeber. Die Drehzahl soll variabel sein. Von 0 - 2800 U/min. Den Drehgeberbeitrag (http://www.mikrocontroller.net/articles/Drehgeber) habe ich mir auch schon durchgelesen, aber hilft mir auch nicht wirklich weiter. Viele Grüße, Olli
Datum:
Olli L. schrieb: > Ist ein Inkrementalgeber. Die Drehzahl soll variabel sein. Von 0 - 2800 > U/min. Das könnte mit einem ATmega32 schon eng werden. Evtl. wäre ein FPGA da die bessere Lösung. Das kommt auch drauf an, was in der Auswertung passieren soll.
Datum:
Werner schrieb: > Olli L. schrieb: >> Ist ein Inkrementalgeber. Die Drehzahl soll variabel sein. Von 0 - 2800 >> U/min. > > Das könnte mit einem ATmega32 schon eng werden. Evtl. wäre ein FPGA da > die bessere Lösung. Das kommt auch drauf an, was in der Auswertung > passieren soll. Das ist leider nicht möglich. Das Ganze muss mit einem ATmega32 laufen. Das Hauptziel ist, eine möglichst genaue Messauflösung bei kleinen Frequenzen. Bei den schnellen Frequenzen darf es ruhig ein bisschen ungenauer sein. mfG
Datum:
Holla. (2800rpm*5000pulse)/60s = 233kHz -> wird eng mit ner normalen Drehgeber Lib Soll denn auch die Richtung erkannt werden? Wenn nein kann am Code gespart werden, so müssen nur die Flanken eines der Kontakte pro zeiteinheit gezählt werden (per externem Takteingang des Hardwaretimer).
Datum:
Olli L. schrieb: > Das Hauptziel ist, eine möglichst genaue Messauflösung bei kleinen > Frequenzen. Was heißt "genaue Messauflösung"? Wie lang darf die Messung dauern? Wie genau soll es sein? Was soll gemessen werden?
Datum:
Martin Wende schrieb: > (2800rpm*5000pulse)/60s = 233kHz Warum so schüchtern? Bei 4-fach Auswertung sind es 4 x 233kHz :-) Olli L. schrieb: > Das Ganze muss mit einem ATmega32 laufen. Liefert der Drehgeber Sinus/Cosinus- oder Rechtecksignale? Bei phasenverschobenen Rechtecksignalen müßte der ATmega mit >50MHz laufen, um die Impulse zu verarbeiten.
Datum:
Willi schrieb: > Liefert der Drehgeber Sinus/Cosinus- oder Rechtecksignale? Ohne Typenbezeichnung oder Link aufs Datenblatt läßt sich das schlecht beantworten, wenn man den Geber nicht beim Vornamen kennt.
Datum:
Werner schrieb: > Willi schrieb: >> Liefert der Drehgeber Sinus/Cosinus- oder Rechtecksignale? > > Ohne Typenbezeichnung oder Link aufs Datenblatt läßt sich das schlecht > beantworten, wenn man den Geber nicht beim Vornamen kennt. Es handelt sich um einen Hengstler RI58-0. Es soll die Position, Beschleunigung und Drehrichtung erkannt werden. Ist es mit dieser Drehgeber+Mikrocontroller Kombination überhaupt möglich?
Datum:
Olli L. schrieb: > Ist es mit dieser Drehgeber+Mikrocontroller Kombination überhaupt > möglich? Definitiv: NEIN! Das muß mit spezieller Hardware gemacht werden. Am besten mit einem µC, der schon einen Quadratur-Dekoder auf dem Chip hat wie zum Beispiel der STM32F407. Hierfür gibt es ein kostengünstiges 'discovery-board'. Falls eine größere Stückzahl gebaut werden soll, würde ich einen Renesas RX210 empfehlen; er ist leistungsfähig+günstig. Das Entwicklungsboard wird bei Renesas verschenkt: RPBRX210. Es gehen aber auch dessen größere Brüder RX62N oder RX621, oder aber auch H8S und H8SX Prozessoren, die bis zu 4 Quadratur-Dekoder auf dem Chip haben.
Datum:
Also mit den Anforderungen isses aufm AVR allgemein unmöglich, da sind die zu langsam. Da sollteste nen FPGA nehmen, da in Hardware auswerten und nen CPU Softcore noch draufbasteln für die Auswertung. Position mit nem Inkremetalgeber ist übrigens eh Gülle, das Gerät weis ja nicht, wo die Welle startet.
Datum:
Martin Wende schrieb: > Position mit nem Inkremetalgeber ist übrigens eh Gülle, das Gerät weis > ja nicht, wo die Welle startet. Da gibt es aber durchaus Möglichkeiten, das herauszufinden :-) > Da sollteste nen FPGA nehmen, da in Hardware auswerten und nen CPU > Softcore noch draufbasteln für die Auswertung. Das würde ich davon abhängig machen, wo die Prioritäten liegen. Meistens ist das Quadratursignal eher von geringer Bedeutung, da der Prozessor noch viele andere Schnittstellen bedienen muß. Ein Standardprozessor, den man von der Stange kaufen kann und wiederholt auch für andere Schaltungen einsetzt, dürfte einfacher zu handhaben sein.
Datum:
Das Problem ist, dass uns diese Aufgabe von unserem Professor gestellt wurde. Wäre die Problemstellung zu lösen wenn man einen Drehgeber mit weniger Schritten (zB 1000) nutzt? Wäre es möglich die Auswertungen (Geschwindigkeit, Beschleunigung und Drehrichtung) sequentiell zu machen? Sprich ich schalte das Programm bei bestimmter Eingabe um? Was begrenzt das ganze denn? Verzeiht mir meine vllt dummen fragen, bin absoluter Neuling auf dem Gebiet. mfG
Datum:
Solls denn NUR mitm AVR sein? mit ner Vorauswertung der Drehrichtung in hardware gehts dann vllt doch: http://www.mikrocontroller.net/articles/Drehgeber Da das den Softwareaufwand schonmal verringert.
Datum:
Martin Wende schrieb: > Solls denn NUR mitm AVR sein? > mit ner Vorauswertung der Drehrichtung in hardware gehts dann vllt doch: > http://www.mikrocontroller.net/articles/Drehgeber > > Da das den Softwareaufwand schonmal verringert. Ja uns steht nichts anderes zur Verfügung. Unsere Vorgänger sollen das auch geschafft haben.
Datum:
Such Dir einen µC mit Eingang speziell für einen Drehgeber und gut. Der Rest ist einfache Software.
Datum:
spontan schrieb: > Such Dir einen µC mit Eingang speziell für einen Drehgeber und gut. Der > Rest ist einfache Software. Es geht um ein Ausbildungsprojekt: Olli L. schrieb: > Ja uns steht nichts anderes zur Verfügung. Unsere Vorgänger sollen das > auch geschafft haben. Da muss man sich schon an die Vorgaben halten, oder man disqualifiziert sich. Ich meine allerdings auch, dass eine reine Softwarelösung mit dem AVR verdammt eng wird, zumindest ist die klassische Art mit Abfrage der Zustände im Timer-Interrupt und Erkennen der Flanken durch Vergleich mit dem Vorwert bei dieser Impulsflut überfordert. ...
Datum:
Hannes Lux schrieb: > spontan schrieb: >> Such Dir einen µC mit Eingang speziell für einen Drehgeber und gut. Der >> Rest ist einfache Software. > > Es geht um ein Ausbildungsprojekt: > > Olli L. schrieb: >> Ja uns steht nichts anderes zur Verfügung. Unsere Vorgänger sollen das >> auch geschafft haben. > > Da muss man sich schon an die Vorgaben halten, oder man disqualifiziert > sich. > > Ich meine allerdings auch, dass eine reine Softwarelösung mit dem AVR > verdammt eng wird, zumindest ist die klassische Art mit Abfrage der > Zustände im Timer-Interrupt und Erkennen der Flanken durch Vergleich mit > dem Vorwert bei dieser Impulsflut überfordert. > > ... Richtig, es ist ein Studienprojekt. Ich versteh allerdings noch nicht genau warum das eng werden könnte. Liegt es an dem Takt von 8MHz? Wir könnten auch nen externen 16MHz Takt anschließen falls das was bringt. mfG
Datum:
@ Olli ElPunkt (Gast) >Richtig, es ist ein Studienprojekt. Und dann gleich so hoch hinaus? >Ich versteh allerdings noch nicht genau warum das eng werden könnte. Beitrag "Re: Drehgeber Vierfachauswertung STK500 + ATmega32" Der Drehgeber muss schnell genug abgetastet werden, damit man keinen Codewechsel verliert. Bei der 2800 U/min und 5000 Pulsen/U ist das halt nicht gerade wenig. Genau genommen über 1 MHz Abtastrate. Da der AVR für einen Drehgeber keinerlei Hardwaremodule hat, muss alles in Software gemacht werden. Macht bei 16 MHz CPU-Takt bestenfalls 16 Befehle/Durchlauf. Das wird nix. Mit einem passenden Hardwaredekoder wäre es machbar. Entweder ein fertiger IC, oder ein CPLD, oder ein TTL-Grab oder, oder, oder.
Datum:
Falk Brunner schrieb: > @ Olli ElPunkt (Gast) > >>Richtig, es ist ein Studienprojekt. > > Und dann gleich so hoch hinaus? > >>Ich versteh allerdings noch nicht genau warum das eng werden könnte. > > Beitrag "Re: Drehgeber Vierfachauswertung STK500 + ATmega32" > > Der Drehgeber muss schnell genug abgetastet werden, damit man keinen > Codewechsel verliert. Bei der 2800 U/min und 5000 Pulsen/U ist das halt > nicht gerade wenig. Genau genommen über 1 MHz Abtastrate. Da der AVR für > einen Drehgeber keinerlei Hardwaremodule hat, muss alles in Software > gemacht werden. Macht bei 16 MHz CPU-Takt bestenfalls 16 > Befehle/Durchlauf. Das wird nix. Mit einem passenden Hardwaredekoder > wäre es machbar. Entweder ein fertiger IC, oder ein CPLD, oder ein > TTL-Grab oder, oder, oder. Das einzige was uns angeboten wurde, ist ein Drehgeber mit weniger Strichen bzw weniger Impulsen/Umdrehung.
Datum:
"Das Hauptziel ist, eine möglichst genaue Messauflösung bei kleinen Frequenzen. Bei den schnellen Frequenzen darf es ruhig ein bisschen ungenauer sein." Was sind hier kleine Frequenzen? Bei 280 U/min hat man 10 mal soviel Takte zur Verfügung, das könnte was werden. Aber bei voller Drehzahl muss man dennoch alle Codewechsel erwischen, sonst klappt die Richtungsauswertung nicht.
Datum:
Falk Brunner schrieb: > "Das Hauptziel ist, eine möglichst genaue Messauflösung bei kleinen > Frequenzen. Bei den schnellen Frequenzen darf es ruhig ein bisschen > ungenauer sein." > > Was sind hier kleine Frequenzen? Bei 280 U/min hat man 10 mal soviel > Takte zur Verfügung, das könnte was werden. Aber bei voller Drehzahl > muss man dennoch alle Codewechsel erwischen, sonst klappt die > Richtungsauswertung nicht. Am besten ich zitiere mal den Aufgabentext: "Inkrementalgeberauswertung mit µ-Controller Es soll eine Vierfachauswertung (mit Atmega32) folgender Messgrößen erfolgen: - Position bzw. Winkel - Geschwindigkeit - Beschleunigung bzw Winkelbeschleunigung Für eine Antriebsregelung mit relativ hohen Abtastraten (zB 0,1ms bis 2ms) wird mit reiner Frequenzmessung die Drehzahl und die Beschleunigung nur gering aufgelöst (Nur wenig Impulse pro Abtastzeit). Insbesondere bei niedrigen Drehzahlen soll die Geschwindigkeit und die Beschleunigung genauer gemessen und höher aufgelöst werden. Kombination von Zeit- und Frequenzmessung."
Datum:
Nach einem Gespräch mit unserem Professor kam heraus, das wir einen Hardwaredekoder verwenden sollen. Nach kurzer Recherche fanden wir den LS7083 bzw LS7084 die unserer Meinung nach gut geeignet wären. Leider sind sie schwer zu beschaffen in Deutschland. Gibt es Alternativen dazu?
Datum:
> > Ist es mit dieser Drehgeber+Mikrocontroller Kombination > > überhaupt möglich? > Definitiv: NEIN! 4 Drehgeber mit 233kHz Strichrate, also ca. 300kHz Abtastfrequenz ? Doch, schaffbar, die Frage ist, was der AVR noch zusätzlich tun soll. Vermutlich gelegentlich die 4 Positionen über die serielle Schnittstelle senden, vielleicht Grenzwerte vergleichen. Das kann er auch noch, programmieren muß man halt können. Soll er nebenher eine CNC Maschine mit 5 Achsen in Kreisbahnen interpoliert steuern, wird's eng.
Datum:
So ungefähr:
// 8kByte Tabellen, einfach mit Byte addressierbar
char increment01[4][256]={...}; Richtung +1/0/-1 bit 0,1
char increment23[4][256]={...}; Richtung +1/0/-1 bit 2,3
char increment45[4][256]={...}; Richtung +1/0/-1 bit 4,5
char increment67[4][256]={...}; Richtung +1/0/-1 bit 6,7
uint8_t table01[4][256]={...}; Übergang bit 0,1 auf nächsten Zustand
0..3
uint8_t table23[4][256]={...}; Übergang bit 2,3 auf nächsten Zustand
0..3
uint8_t table45[4][256]={...}; Übergang bit 4,5 auf nächsten Zustand
0..3
uint8_t table67[4][256]={...}; Übergang bit 6,7 auf nächsten Zustand
0..3
register uint8_t state1,stat2,stat3,state4; // 4 Register
register int16 position1,position2,position3,position4; // 8 Register
while(1) // RJMP : 2
{
state=PORTB; // bit 0,1 Drehgeber 1, bit 2,3 Drehgeber 2, ... // IN:
1
position1+=increment01[state1][state]; // LD ADD LD ADD: 5
state1=table01[state1][state]; // LD Rd,(X): 2
position2+=increment23[state2][state];
state2=table23[state2][state];
position3+=increment45[state3][state];
state3=table45[state3][state];
position4+=increment67[state4][state];
state4=table67[state4][state]; // 35 Takte/16MHz = 450kHz Abtastrate
}
und vielleicht fällt ja jemandem noch schnelleres ein.
Datum:
Und selbst wenn...jetzt hast Du die Position. Wo ist die Geschwindigkeit und die vor allem die Beschleunigung? Wenn es da nicht von 0 auf 1000/s^2 springen soll, dann ist da etwas mehr notwendig als eine einfache Differenzenbildung.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten