Auswertung "schneller" Inkrementalgeber

Bau halt ne Auswertung mit 7400ern auf. Z.B. hier beschrieben: 
http://www.elektrik-trick.de/sminterf.htm

Marvin N. schrieb:
> Ich habe festgestellt, dass mein Inkrementalgeber zu viele Pulse erzeugt
> um sie mit der Timer-Interupt Methode zuverlässig abtasten zu können.

Hier stehen alle effektiven Methoden:

http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

Neben den im vorherigen Thread schon genannten Spezial-ICs
 http://www.lsicsi.com/encoders.htm 
(LS7082/7083/7084/7182/7183/7166/7266/7366)
 http://www.avagotech.com/docs/5988-5895EN 
(HCTL2000/2016/2020/2022/2032)

siehst du auch den Code mit dem auch dein ATmega16 problemlos 4us 
Impulse statt deiner grosszügigen 34us Impulse auswerten kann, also noch 
massig Zeit hätte die erfassten Daten zu verarbeiten und weiterzuleiten.

Man muss ihn halt bloss ordentlich programmieren.

Marvin N. schrieb:
> was nicht in Frage kommt:
> -GAL/CPLD/FPGA: keine Programmierhardware vorhanden
Seltsames Argument. Solche Hardware kostet gerade mal 20 Euronen. Und 
vor allem: über ein Gebersignal mit 1 (oder auch 10) MHz lacht so ein 
FPGA einfach mal kurz...

Wer ein spezielles Problem hast, muss das nicht unbedingt mit dem 
billigsten Standardtool lösen können. Oder wieder mal: wer nur einen 
Hammer kennt, für den sieht die ganze Welt wie ein Nagel aus...

marvin_n schrieb:
> Michael B. schrieb:
>> Man muss ihn halt bloss ordentlich programmieren.
>
> ... lässt sich die "gute" Lösung
> auch in C programmieren? Die empfohlene Methode aus dem Drehgeber
> wiki-Artikel war ja nicht so erfolgreich.

Wenn du dir konkrete Hinweise erhoffst, dann mußt du auch dein konkretes 
Problem zeigen. Welchen Code genau und wie übersetzt verwendest du 
jetzt? Zeig am Besten den C Code und was der C-Compiler dafür generiert.

Handgedengelter Assemblercode ist zwar sicher am schnellsten, aber du 
brauchst ja nur erstmal etwas, das schnell genug ist.

marvin_n schrieb:
> Sehe ich das also richtig, dass ich den AVR mit nicht viel andrem
> beschäftigen darf

Na, bei 4us vs. 34us hast du gerade mal 12% Auslastung, da kann man 
einen uC schon noch mit einer Menge Anderen beschäftigen, bei nur einem 
auszuwertenden Drehgeber läge die Auslastung sogar nur bei 6%.

> und am Besten statt C Assembler verwenden sollte um
> die geforderten Zeiten einzuhalten?
> Oder lässt sich die "gute" Lösung auch in C programmieren?

Ich kann mir vorstellen, daß sich dein 34us Drehgeber auch in C 
auswerten lässt, aber wer schon so fragt, wird nicht ausreichend gut in 
C sein.

Jedenfalls hast du kräftiges Übersprechen zwischen den Kanälen.
Wenn du das beseitigst, z.B. indem du die Flanken nicht gar so steil 
machst, ist das Problem vielleicht schon gelöst.

Wenn's der uC nicht packt, dann könnte man ihm einen FPGA-Vorteiler 
spendieren

@ Marvin Noll (marvin_n)

>-ATMEGA16 gegen einen ATMEGA644 tauschen. Der kann pin-change-interupts

Nützt dir nix! Davon wird die ISR-Bearbeitung NICHT schneller!

>-zweiten AVR als decoder-IC verwenden (z.B. per polling einlesen)

Kann man machen

>was nicht in Frage kommt:
>-GAL/CPLD/FPGA: keine Programmierhardware vorhanden

Muss man auch nicht.

>-ein nicht-AVR µC

Nimm einen ATXmega, die sind den AVRS SEHR ähnlich, der Umstieg ist 
einfach und sie haben Dekoder in Hardware drin. Du kannst die auf die 
gleiche Weise mit Atmelstudio und deinem ISP-Programmieradapter 
programmieren.

marvin_n schrieb:
> An was denkst du da zum Beispiel? ich kenne FPGA Boards mit USB nur für
>>50€
> Hab ich da was übersehen?
Das FPGA selbst braucht ja keinen USB. Den braucht nur der Programmer.

Und zum FPGA selbst: ich würde da die Lattice MachXO(ff) näher 
ansehen...

@marvin_n (Gast)

>Gibts von denen auch nen FPGA im DIP Gehäuse?

Nein.

> Irgendwas kleines?

Ja

> Die
>Modelle, die ich so gesehen habe sind etwas übertrieben für die
>Anwendung.

Ja.

> Wenns da nichts gibt, dann ist wohl ein zweiter AVR (per SPI
>angebunden?) die beste Idee.

Die Lösung im Artikel Drehgeber nutzt den UART, der braucht nur ein 
Leitung.

Beitrag "Re: Versetzte Rechtecksignale auswerten, kein drehgeber"

marvin_n schrieb:
>> Du mußt den Timer nur mit 100 kHz laufen lassen, dann ist Polling kein
>> Problem.
>
> Das habe ich ja probiert. Der Timer im CTC Modus konnte zwar den OC Pin
> schnell genug toggeln, aber die ISR wird nicht schneller abgearbeitet
> als oben im Oszi Bild gezeigt. Mir wurde schon erklärt, das viele der
> Interrupts "unter den Tisch fallen".

Das sind bei 16MHz 160 Takte. Was machst du die ganze Zeit?

mfg.

@ marvin_n (Gast)

>Beispiel hierfür?

Es gibt kleine und kleinste FPGAs. Aber die Baustelle wolltest du doch 
nicht aufmachen! Ich kann sich auch nicht wirklich empfehlen, auch wenn 
sie rein technisch die leistungsfähigste ist.

Das ier ist ein CPLD, reicht für dein Zwecke aber.

http://shop.trenz-electronic.de/de/23565-C-ModC2-mit-Xilinx-CoolRunner-II-CPLD?c=119

Ein echtes FPGA, aber schon teuer

http://shop.trenz-electronic.de/de/TE0260-00-GODIL_XC3S250E-DIL-FPGA-module-bare-module?c=7

Ein Micro-FPGA

http://www.eetimes.com/author.asp?section_id=216&doc_id=1327108

>> Die Lösung im Artikel Drehgeber nutzt den UART, der braucht nur ein
>> Leitung.

>Wäre eine gute Idee, aber ich nutze den einen uart des MEGA16 schon für
>die PC Kommunikation

Ich sags nochmal, nimm einen ATXmega und sei glücklich.

* Schritt 1: Notwendige Samplerate festlegen und dabei bleiben.
* Schritt 2: Timer-Interrupt mit der Auswertung in C implementieren und 
messen ob noch genug Zeit für die restlichen Aufgaben übrigbleibt die 
der µC sonst noch nebenher erledigen soll.

falls ok => fertig.

* Schritt 3: Timer-Interrupt in asm implementieren und messen ob jetzt 
wieder genug Zeit für die restlichen Aufgaben übrigbleibt die der µC 
sonst noch nebenher erledigen soll.

falls ok => fertig.

* Schritt 4: Nach besser geeigneter Hardware Ausschau halten und diese 
verwenden.

Meister schrieb:
> der Wert eines Timers durch
> einen EXT IRQ in ein Register geschrieben wird?

was bringt Dir ein solcher Wert? Du hast 2 Kanäle von dem 
Inkrementalgeber und Du müsstest wissen, in welcher Reihenfolge die sich 
geändert haben.

Außerdem hilft ein einzelnes Register nicht viel, denn wenn der Geber 
prellt, müsstest Du das in kurzer Zeit auslesen können um keine Wechsel 
zu verpassen.

Was Du bräuchtest, wäre ein echter DMA-Controller, der von GPIOs aus 
getriggert werden kann. Und der Atmega hat keinerlei DMA.

Nochmal meine Frage (das war vorher wohl etwas subtil): Brauchst die 
diese ultrahohe Auflösung? Oder hast du die einfach, weil der Geber 
"eben schon eingebaut" war?
Würde auch 1/8 oder 1/16 der Auflösung reichen?

@ marvin_n (Gast)

>Eine geringere Auflösung würde auch reichen. Es reicht, wenn ich die
>Position auf 50 Inkremente genau erfassen kann. Aber ich muss den Motor
>reproduzierbar darauf positionieren können.

Da du aber den Encoder nicht wechseln kannst/willst, musst du halt 
hochfrequenz abtasten und dekodieren, geht nicht anders. Du hast 
genügend Lösungsvorschläge. Entscheide dich!

marvin_n schrieb:
> Zum
> Encoder gehen etwa 3m geschirmtes Kabel mit +5V/GND hin und A/B zurück.

Eine gemeinsame Abschirmung der Signaladern nützt etwas gegen Störungen 
von aussen. Das Übersprechen passiert aber innerhalb der Abschirmung 
wegen der Kapazität zwischen den Adern, und es ist in deinem 
Oszillogramm gut zu sehen.
Wenn du nicht einzeln abgeschirmte Adern für diese Signale zur Verfügung 
hast, könntest du z.B. zwischen Encoderausgang und Kabeleingang 220 Ohm 
legen, und die beiden Kabeleingänge ausserdem über je etwa 3nF an GND 
legen.

Dadurch werden die Signalflanken zwar etwas verrundet, aber die 
Glitches, die man in der Mitte der Impulse sieht, sollten weitgehend 
verschwinden.

Du solltest dir das am Empfangsende mit dem Scope ansehen: Wenn die von 
dem GND-Potential ausgehenden Spikes etwa 1V überschreiten, ist damit zu 
rechnen, dass sie einen ungewollten Interrupt auslösen.

P.S.: Alternativ könntest du, da die Glitches ja von einer Flanke in dem 
anderen Signal ausgelöst werden, nach der Erkennung des Interrupts 
einige µs in der ISR vertrödeln, dass der Glitch auf jeden Fall 
abgeklungen ist, bevor du daran gehst die Pegel der Signalleitungen 
auszuwerten.

>>> Eine geringere Auflösung würde auch reichen. Es reicht, wenn ich die
>>> Position auf 50 Inkremente genau erfassen kann. Aber ich muss den Motor
>>> reproduzierbar darauf positionieren können.
> Da du aber den Encoder nicht wechseln kannst/willst, musst du halt
> hochfrequenz abtasten und dekodieren, geht nicht anders
Man könnte ein kleines CPLD oder ein winziges FPGA oder auch einen 
kleinen 8-beinigen uC damit beschäftigen, das schnelle Gebersignal in 
ein 32 mal langsameres Quadratursignal herunter zu skalieren. Das ginge 
ganz einfach und ohne die Reproduzierbarkeit zu beeinträchtigen: einfach 
einen 7 Bit Zähler nehmen und die vordersten beiden Bits wieder in den 
Graycode überführen. Oder gleich einen Graycode-Vorteiler verwenden. 
Dann käme der eingesetze uC locker zum Auswerten und könnte auch noch 
was Anderes tun...

Hp M. schrieb:
> nach der Erkennung des Interrupts einige µs in der ISR vertrödeln
Wenn die Rechenzeit eh schon knapp ist, scheint mir irgendeine Art 
aktiver Rechenzeitvernichtung kontraproduktiv...

Lothar M. schrieb:
> Hp M. schrieb:
>> nach der Erkennung des Interrupts einige µs in der ISR vertrödeln
> Wenn die Rechenzeit eh schon knapp ist, scheint mir irgendeine Art
> aktiver Rechenzeitvernichtung kontraproduktiv...

Ich habe mittlerweile gesehen, dass er ja gar nicht einen 
Pin-Change-Interrupt verwendet, sondern den Zustand mittels Polling 
feststellt.
Dann muss er die Glitches entweder wie beschrieben durch Hardware 
wegbringen, oder kurz hintereinander 2x abfragen.
Wenn das Ergebnis der Abfragen verschieden ist, hat eine der Abfragen 
einen Glitch oder eine reguläre Flanke erwischt und man muß noch einmal 
testen, welcher Zustand sich letztlich eingestellt hat.

Ausserdem Shannon beachten, d.h. die Poll-Frequenz muss so hoch sein, 
dass jedes Impulsdach mindestens zweimal abgetastet werden kann, sonst 
droht Impulsverlust.

Hp M. schrieb:
> Dann muss er die Glitches entweder wie beschrieben durch Hardware
> wegbringen, oder kurz hintereinander 2x abfragen.
Damit ist nichts gewonnen, denn was, wenn er dann bei diesen beiden 
Abfragen '0' und '1' erhält? Erst bei 3 Abtastungen könnte man einen 
"Mehrheitsentscheid machen. Und dann könnte man auch einen gleitenden 
Mittelwert über diese 3 Abtastungen laufen lassen und eine 
Schwellwertauswertung mit Hysterese drauf ansetzen.
(Das wird dort z.B. gemacht: 
http://www.lothar-miller.de/s9y/archives/3-Tastenentprellung-mit-Schieberegister.html 
--> erst wenn 4 Bits hintereinander '1' oder '0' sind, wird der Pegel 
übernommen).

> Ausserdem Shannon beachten,
Die Herren Nyquist und Shannon haben das Theorem übrigens nicht für 
Digitalsignale aufgestellt. Denn um ein binäres rechteckiges 
Digitalsignal halbwegs treffsicher in den Frequenzbereich und wieder 
zurück zu bekommen, empfiehlt sich eine mindestens 10-fache 
Überabtastung. Aber diese aufgabe ist hier sowieso nicht gestellt.

> d.h. die Poll-Frequenz muss so hoch sein, dass jedes Impulsdach
> mindestens zweimal abgetastet werden kann, sonst droht Impulsverlust.
Nicht ganz. Es reicht eine Abtastung. Aber die muss garantiert sein. 
Auch bei verschobenem Puls-Pausen-Verhältnis. Und deshalb empfiehlt 
sich diese doppelte Abtastfrequenz (die als Richtwert ähnlich zu 
bewerten ist, wie die altbewährten 100nF als Blockkondensator). Wenn es 
knapp hergeht, wird die Auswertung bei guten Signalen aber auch mit der 
1,1 fachen Frequenz sicher funktionieren.

Radiergummi schrieb:
> Der 1 Euro Tiny25 wurde ja schon genannt.
Schon, aber mit einer komplett anderen Aufgabe. Ich würde den wie gesagt 
als Vorteiler "transparent" zwischen den Geber und "den uC" schalten und 
die Zählerauswertung trotzdem komplett auf "dem uC" machen.

> Für das Geld gibt es schon ein-zwei STM32 Nucleo-Boards bester Leistung.
Womit dann wieder mal die Frage nach dem Interface bliebe. Ein 
serielles Interface für einen Zähler ist ungünstig. Man wird niemals 
(oder nur zufällig) etwas bei exakt "dieser Position" auslösen können. 
Sondern immer nur, wenn man "schon drüber weg" ist...

Radiergummi schrieb:
> Für das Geld gibt es schon ein-zwei STM32 Nucleo-Boards bester Leistung.
Dass ein STM32 mit Quadratureingang das schon in Hardware und viel 
billiger könnte, ist sonnenklar und steht ausser Diskussion. Aber 
manchmal will sich einer einfach weh tun und nimmt einen ungeeigneten 
Controller...

Vielen Dank schonmal für die hilfreichen Antworten.

-Die STM Boards werde ich mir für zukünftige Projekte auf jeden Fall 
näher anschauen. Die schauen sehr modern und leistungsfähig aus.

-Ich habe mich jetzt erst einmal mit der Entstörung der Encoder-Signale 
beschäftigt:

Erläuterungen zu den Oszi-Bildern:

TEK00013:
Ausgangssituation. An Encoder-Versorgungsspannung 1µF/100n 
Kondensatoren, sonst nichts

TEK00012:
Eingefügte 220 Ohm Widerstände in den A/B Leitungen. Habe ich da was 
falsch verstanden? Der Effekt ist ja "eher" negativ.

TEK00014:
10nF Kondensatoren gegen GND an A/B. Habe die Skalen mal etwas 
vergrößert. Mit dem Signal müsste sich doch etwas anfangen lassen.

Marvin N. schrieb:
> -Ich habe mich jetzt erst einmal mit der Entstörung der Encoder-Signale
> beschäftigt: ...
Auch wenn es sich anhört, wie wenn ich mich wiederhole (siehe den 
Beitrag "Re: Drehgeber-Auswertung zählt falsch/ungenau") :
wo genau ist das Messgerät angeschlossen und wo sind im Besonderen die 
beiden Messeklemmen des Messgeräts angeschlossen? Direkt und dicht an 
den Signalleitungen? Hast du mal ein Foto vom Messaufbau?

Radiergummi schrieb:
> Heute ist ja Liefertermin für C-Quellcode. Es wird sicher viel Geräusch
> erzeugen, wenn Alle die Hände über dem Kopf zusammenschlagen ;-)

Na dann liefere ich mal Code + Erklärung, was passieren soll:

-auf den UART wird ###### geschrieben -> Rückmeldung, dass der µC läuft
-der Motor wird blind gegen den linken Anschlag gefahren (wird später 
noch optimiert)
-mit der Tastatur des PCs lässt sich nun der Motor fein (, und .Taste) 
und grob (m und - Taste) bewegen.
-mit 'h' kann die aktuelle Position abgefragt werden, mit 'j' auf 0 
gesetzt werden.

Der simple Regler ist vorerst zweckmäßig, denke ich.

Es scheint auch zu funktionieren, aber wenn ich den Motor ein paar mal 
hin und her fahren lasse, dann steht er bei angezeigten Position 50000 
nicht mehr an der gleichen Stelle wie zuvor.

Lothar M. schrieb:
> wo genau ist das Messgerät angeschlossen und wo sind im Besonderen die
> beiden Messeklemmen des Messgeräts angeschlossen? Direkt und dicht an
> den Signalleitungen? Hast du mal ein Foto vom Messaufbau?

Oszilloskop ist nahe den µC Beinen angeschlossen. die Kondensatoren 
gegen Masse direkt dort. Masse über beide Tastkopfclips am 7805-Gehäuse. 
(Foto im Moment leider nicht möglich)

Marvin N. schrieb:
> Eingefügte 220 Ohm Widerstände in den A/B Leitungen. Habe ich da was
> falsch verstanden? Der Effekt ist ja "eher" negativ.

Interessant, daß beide eigentlich identischen Signale so vollkommen 
unterschiedlich beeinflusst werden.

Du hast wohl einen massiven Schaltungsfehler im System, d.h. die 
Encoder-Anschlüsse nicht verstanden, zumal ja auch die Skalierung 
0.5V/5V so vollkommen unterschiedlich ist.

Marvin N. schrieb:
> Masse über beide Tastkopfclips am 7805-Gehäuse.
Die Masse gehört dort angeschlossen, wo auch die Signale sind. Denn du 
willst ja nicht wissen (und messen), wie das Signal bezogen auf den 
Masseanschluss des Reglers aussieht, sondern wie das Signal bezogen auf 
den Masseanschluss des uCs aussieht. Dann müssen aber auch die 
Masseklemmen an den Masseanschluss des uCs...

Michael B. schrieb:
> Interessant, daß beide eigentlich identischen Signale so vollkommen
> unterschiedlich beeinflusst werden.
Ach, das ist nur eine Gleichtaktstörung auf dem Massepfad...

> zumal ja auch die Skalierung 0.5V/5V so vollkommen unterschiedlich ist.
Nochmal ein Messfehler: da wurde wohl ein 10:1 Tastkopf angeschlossen 
und das dem Oszi nicht gesagt.
Allerdings könnte es auch sein, dass die Ausgänge Open-Collector sind 
und einen strammen Pullup brauchen...

1

void timer0_init(void)

2

{

3

  TCCR0 = (1<<WGM01)|(1<<CS00); //CTC-mode 

4

  OCR0  = (uint8_t)25;

5

  TIMSK = (1<<OCIE0);

6

}

Der Timer-Interrupt kommt alle 26 Takte. In diesen 26 Takten muss das:

1

ISR(TIMER0_COMP_vect)

2

{

3

  static char enc_last = 0x01;

4

  char i=0;

5

  if(PHASE_A)i=1;

6

  if(PHASE_B)i^=3;

7

  i-= enc_last;

8

  if(i&1)

9

  {

10

    enc_last+=i;

11

    enc_delta +=(i&2)-1;

12

  }

13

  PORTB ^=(1<<PB3);

14

}

ausgeführt werden.

26 Takte braucht der Interrupt inkl. der Push-Pop-Orgie schon für sich 
selbst. Dazu kommt dann noch die eigentliche Funktion. Während der 
Abarbeitung der ISR kommt dann schon der nächste Interrupt. D.h. nach 
Beendigung der ISR wird im restlichen Programm 1 Maschinenbefehl 
ausgeführt und dann geht es wieder in die ISR. Dein Programm läuft also 
effektiv mit ein paar Hundert KHz.

In einem Timer-Interval muss die ISR ausgeführt werden und es muss noch 
genug Zeit für das restliche Programm vorhanden sein.

Nebenbei:
Warum ist enc_delta int16? Bei PeDa ist es int8.
Das Rücksetzen von enc_delta muss atomar erfolgen.

1

 uart_puts("\n\r##########\n\r");

Sende ein maximal zwei Zeichen und keinen Roman.

mfg.

So, hier nochmal etwas Material:

-ich habe den Code mal zur Fehlersuche fast 1:1 auf den aus dem Wiki 
hier geändert.

-die Masseklemmen sind jetzt direkt am µC GND angeschlossen und die 
Tastkopfsettings stimmen

-ich hab die UART Ausgabe, wenn ich den Motor in eine Richtung drehen 
lasse mal in Excel plotten lassen. Das Ergebnis ist angehängt.
Da läuft wohl noch eine Variable über(?)

Aber zu langsam ist es immer noch.