STM32F4 Encoder Mode "nur" 16bit + Z-Kanal Auswertung

[R. H. (breezer)]

Hallo,

ich beschäftige mich zurzeit mit der Entwicklung einer Ansteuerung eines 
6-Achs Roboters. Zum Einsatz kommt hierbei ein STM32F4 Discovery Board. 
Der Roboter besitzt normale DC-Motoren mit angeflanschen Encodern. Die 
Auswertung der Encoder soll über den Encoder Mode des STM32 laufen, 
hierfür stehen genau 6 Eingänge zur Verfügung.

Momentan ergeben sich folgene Probleme:

1. Die Counter sind nur 16bit breit, was für die Encoder nicht 
ausreichend ist, wie erweitere ich den Bereich am effektivsten auf 
32bit?

2. Die Encoder besitzen einen Z-Kanal, wie setze ich diesen am besten 
ein? Bei jeder Z-Flanke den Zähler zurücksetzen? Damit wäre das 16bit 
Problem der Counter auch erledigt.

Auf jeden fall benötige ich den Z-Kanal um eine Startinitialisierung 
durchzuführen um von der Relativposition der Encoder auf eine 
Absolutposition zu kommen.

[m.n. (Gast)]

R. H. schrieb:
> 1. Die Counter sind nur 16bit breit, was für die Encoder nicht
> ausreichend ist, wie erweitere ich den Bereich am effektivsten auf
> 32bit?

Über- und Unterläufe mitzählen oder 32 Bit Zähler verwenden.

> 2. Die Encoder besitzen einen Z-Kanal, wie setze ich diesen am besten
> ein? Bei jeder Z-Flanke den Zähler zurücksetzen? Damit wäre das 16bit
> Problem der Counter auch erledigt.

Per Capture-Register den Zählerstand als Offset speichern und beim 
Auslesen verrechnen.

[R. H. (breezer)]

m.n. schrieb:
> Über- und Unterläufe mitzählen oder 32 Bit Zähler verwenden.

Ok, also innerhalb des Über- bzw. Unterlaufinterrupt eine Variable hoch- 
bzw. runterzählen?
32bit Zähler gibts nur zwei...

> Per Capture-Register den Zählerstand als Offset speichern und beim
> Auslesen verrechnen.

Ok, das verstehe ich jetzt nicht ganz. Wie genau muss ich vorgehen? Per 
Capture die Ticks mitzählen, oder durch einen Pin-Change-Interrupt am 
Z-Kanal?

[m.n. (Gast)]

Zwei 32 Bit Kanäle mit TIM2 und TIM5 sollte klar sein. Die Phasen A und 
B kommen an die Eingänge TIMx_CH1 und TIMx_CH2. Der Indeximpuls Z an 
TIMx_CH3 fängt per Capture-Funktion den Zählerstand ein. Die relative 
Position ist dann TIMx_CNT - TIMx_CCR3.

Bei der Erweiterung der 16 Bit Zähler war ich zu optimistisch, da ich 
bei diesen Funktionen immer Renesas µCs im Hinterkopf habe, bei denen 
eine Kaskadierung der Zähler auch im Dekodermodus möglich ist.
(Auf den 2. Blick zeigen sich bei den STM32s immer diverse Schwächen.)

Welche Eingangsfrequenzen müssen denn verarbeitet werden? Vielleicht 
findet sich eine Alternative, die Impulse mit höchster Priorität per 
Interrupt zu erfassen. Andererseits bin ich mir nicht sicher, ob beim 
DISCO-Board mit dem 100 poligen µC genug Zählereingänge freigeräumt 
werden können.

Da es 'nur' um die Position der DC-Motore geht, wären separate Dekoder 
vielleicht eine Alternative: 
Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"

Damit werden bis zu 350 kHz verarbeitet bei ca. € 1,-- pro Kanal.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Bei Encoder den Überlauf erkennen ist keine gute Idee. Wenn der Encoder 
gerade einmal an eine Überlauf zu stehen kommt und dort jittert, ist ein 
Fehler vorprogrammiert.

Besser Du hast eine Routine, die mindestens zweimal pro Überlauf bei der 
schnellstmöglichen Bewegung die Differenz zur letzten Ablesung errechnet 
und in einer 32 Bit Variablen aufsummiert..

Mit dem Indeximpuls kannst Du einen Capturevorgang in dem Zaehler 
triggern. Der Wert sollte sich vom letzten Capturewert um die Anzahl der 
Impulse pro Indeximpuls  oder um Null jeweils +/-1 unterscheiden. Die 
+/- 1 kommt daher, dass die Richtung nicht bekannt ist wenn der 
Indeximpuls ansteht. Falls andere Werte anstehen, ist irgendetwas 
falsch, als 42 oder "the end of the world as we know it".

[m.n. (Gast)]

Uwe B. schrieb:
> Wenn der Encoder
> gerade einmal an eine Überlauf zu stehen kommt und dort jittert,

Jitter mit welcher Frequenz: 100 Hz oder 100 MHz?

Uwe B. schrieb:
> Die
> +/- 1 kommt daher, dass die Richtung nicht bekannt ist wenn der
> Indeximpuls ansteht.

Man kann Z leicht verzögern; die STM32 haben dafür passende 
Signalfilterung an den ICP-Eingängen. Selbiges trifft auch auf die 
TIMx_CH1 und _CH2 Eingänge zu, womit man die Dekoder-Bandbreite 
verringern kann.

[Georg (Gast)]

R. H. schrieb:
> Bei jeder Z-Flanke den Zähler zurücksetzen? Damit wäre das 16bit
> Problem der Counter auch erledigt.

Üblich ist mit dem Index-Puls den Zähler auf Null zu setzen, aber nur 
beim ersten Anfahren zur Initialisierung.

Bei weiteren Indexpulsen ist das keine gute Idee:

Linear-Massstab mit einem Index:  steht der Zähler steht wieder auf 
Null, dann hat er richtig gezählt und der Reset ist überflüssig, oder es 
sind Impule verlorengegangen, dann führt der Reset zu einer plötzlichen 
Änderung des Zählerstandes, was den Positionieralgorithmus ins Nirwana 
befördern kann. Man kann den falschen Zählerstand aber als Fehlerhinweis 
auswerten und entsprechende Massnahmen ergreifen.

Drehencoder oder Massstab mit mehreren Indexen: nach einer ganzen 
Umdrehung ist es selbstverständlich falsch auf Null zu stzen, der 
korrekte Zählerstand ist n x die Impulszahl des Encoders. Solange der 
Zähler selbst nicht überläuft ist es also korrekt einfach 
weiterzuzählen.

Zählerüberlauf: da gibt es ein Zeitproblem - wird das Maximum des 
Zählers überschritten, so müsste die Erweiterung um 1 hochgezählt 
werden, aber in Nullzeit, damit kein falscher Zählerstand entstehen 
kann. Das geht nur mit Hardware-Kaskadierung. Man kann aber in der 
Leseroutine mit dem vorherigen Zählerstand vergleichen, ist der alte 
Wert beim Maximum und der neue klein, so muss die Zählerwerweiterung um 
+1 korrigiert werden, und umgekehrt, danach hat man den korrekten 
Zählerstand.

Beim Drehencoder ergibt sich bei Initialisieren ein zusätzliches 
Problem: man kann nicht einfach den nächsten Index zum Nullstellen 
nehmen, sondern man muss zusätzliche Informationen auswerten, z.B. 
Endschalter. Ein generelles Verfahren ist: fahre langsam bis der 
Endschalter anspricht und dann in Gegenrichtung bis zum Index.

Georg