Hallo, (Mein letzter Beitrag zum Thema Drehgeber-Auswertung wurde leider etwas für Trollbeiträge missbraucht. Ich hoffe ein weiterer Thread zu dem Thema ist erlaubt.) Ich habe festgestellt, dass mein Inkrementalgeber zu viele Pulse erzeugt um sie mit der Timer-Interupt Methode zuverlässig abtasten zu können. Dazu nochmal ein Oszibild im Anhang (blau/gelb zeigen das Encodersignal, lila zeigt PORTB ^= (1<<PB3) in der Timer ISR aufgerufen). Ideen bisher: -ATMEGA16 gegen einen ATMEGA644 tauschen. Der kann pin-change-interupts -zweiten AVR als decoder-IC verwenden (z.B. per polling einlesen) was nicht in Frage kommt: -GAL/CPLD/FPGA: keine Programmierhardware vorhanden -ein nicht-AVR µC -anderen Encoder verwenden oder mechanischen Aufbau verändern: ist fest verbaut Danke für wertvolle Tipps!
Angehängte Dateien:
-
TEK00011.PNG
6,6 KB
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.
:
Bearbeitet durch User
Marvin N. schrieb: > (Mein letzter Beitrag zum Thema Drehgeber-Auswertung wurde leider etwas > für Trollbeiträge missbraucht. Ich hoffe ein weiterer Thread zu dem > Thema ist erlaubt.) Dort wurden Dir alle Informationen gegeben, die Du brauchst. "Ich kann mich garnicht entscheiden, ist Alles so schön bunt hier!" Marian B. schrieb: > Bau halt ne Auswertung mit 7400ern auf. Z.B. hier beschrieben: > http://www.elektrik-trick.de/sminterf.htm Ich denke mittlerweile, das wird der Anfrage am besten gerecht ;-)
Michael B. schrieb: > Man muss ihn halt bloss ordentlich programmieren. Sehe ich das also richtig, dass ich den AVR mit nicht viel andrem beschäftigen darf 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? Die empfohlene Methode aus dem Drehgeber wiki-Artikel war ja nicht so erfolgreich.
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...
:
Bearbeitet durch Moderator
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.
Lothar M. schrieb: > 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... An was denkst du da zum Beispiel? ich kenne FPGA Boards mit USB nur für >50€ Hab ich da was übersehen? (C-Code gibts morgen, vielleicht bringt das Klarheit in die Angelegenheit)
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.
:
Bearbeitet durch User
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.
Hp M. schrieb: > 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. Verwendet wird ein magnetischer Encoder mit eingebauter Logik. Zum Encoder gehen etwa 3m geschirmtes Kabel mit +5V/GND hin und A/B zurück. Wo kann ich da am ehesten ansetzen um das Signal zu verbessern? Kondensatoren an der Versorgungsspannung (1µF parallel zu 100nF) brachten noch keine Abhilfe.
marvin_n schrieb: > Verwendet wird ein magnetischer Encoder mit eingebauter Logik So gut wie alle professionellen Encoder, die ich bisher gesehen habe, geben differentielle Signale aus. Die Controller haben dafür als Eingänge RS422-Empfänger. Das schliesst Störungen weitgehend aus. Georg
Von den maxon MR Encodern gibt es Modelle mit differenziellen Ausgängen und welche mit einfachen Ausgängen. Meiner hat 6 Anschlüsse: - Motor + (durchgeschleift) - Motor - (durchgeschleift) - +5V - GND - A - B
@ 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: > was nicht in Frage kommt: > -ein nicht-AVR µC Was hast du gegen die anderen Atmel Mikrocontroller mit entsprechender Hardwareunterstützung für schnelle Drehgeber? Fertige Arduino Boards damit gibt es für 15€.
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...
Lothar M. schrieb: > 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... Programmer? http://www.ebay.de/itm/New-USB-Download-Cable-Jtag-SPI-Programmer-for-LATTICE-FPGA-CPLD-/181282253332?hash=item2a3543aa14 Gibts von denen auch nen FPGA im DIP Gehäuse? Irgendwas kleines? Die Modelle, die ich so gesehen habe sind etwas übertrieben für die Anwendung. Wenns da nichts gibt, dann ist wohl ein zweiter AVR (per SPI angebunden?) die beste Idee.
marvin_n schrieb: > Die empfohlene Methode aus dem Drehgeber > wiki-Artikel war ja nicht so erfolgreich. Du mußt den Timer nur mit 100 kHz laufen lassen, dann ist Polling kein Problem.
@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"
Radiergummi schrieb: > marvin_n schrieb: >> Die empfohlene Methode aus dem Drehgeber >> wiki-Artikel war ja nicht so erfolgreich. > > 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".
Falk B. schrieb: >> Irgendwas kleines? > > Ja > Beispiel hierfür? >> 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. Wäre eine gute Idee, aber ich nutze den einen uart des MEGA16 schon für die PC Kommunikation
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.
Gibt's unter den AVRs keine Funktion bei der der Wert eines Timers durch einen EXT IRQ in ein Register geschrieben wird? Also Hardwaremäßig ohne dass Code nötig wird? Dann hat man alle Zeit der Welt..
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?
Lothar M. schrieb: > 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? 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.
@ 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.
:
Bearbeitet durch User
Uwe Bonnes schrieb: > Was spricht jegen einen uC mit Hardwaredrehencode, wie z.B. STM32? Marvins Aversion dagegen ... Marvin N. schrieb: > was nicht in Frage kommt: > ... > -ein nicht-AVR µC
>>> 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...
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch Moderator
Hu, wie breit sind denn die Glitches und bist du sicher das es keine Masseprobleme beim Messen sind? Ich frage weil im anderen Beitrag das Bild ohne C's unterschiedliche Signalhöhen bei A/B zeigt. Wenn nicht alle Massen der Tastköpfe an einem geeigneten GND sind können die Bilder schon so aussehen. Viel Erfolg, Uwe
Falk B. schrieb: > 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 Für das Geld gibt es schon ein-zwei STM32 Nucleo-Boards bester Leistung. Lothar M. schrieb: > oder auch einen > kleinen 8-beinigen uC damit beschäftigen Der 1 Euro Tiny25 wurde ja schon genannt. Thomas E. schrieb: > Das sind bei 16MHz 160 Takte. Was machst du die ganze Zeit? So ein delay_ms(1) braucht schon seine Zeit :-)
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...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Aber > manchmal will sich einer einfach weh tun und nimmt einen ungeeigneten > Controller... Ich glaube eher, das Problem sitzt ausserhalb des Controllers und hat zwei Beine. Mit ein wenig Programmierkenntnis würde der Dekoder längst auf der vorhandenen Hardware funktionieren, wenn auch vielleicht nicht in aller Perfektion. Heute ist ja Liefertermin für C-Quellcode. Es wird sicher viel Geräusch erzeugen, wenn Alle die Hände über dem Kopf zusammenschlagen ;-)
Angehängte Dateien:
-
tek00013.png
5,1 KB -
TEK00012.png
5,6 KB -
TEK00014.PNG
5 KB
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?
:
Bearbeitet durch Moderator
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)
:
Bearbeitet durch User
Auweia, woher hast Du denn diesen blöden Code? Ändere Deine "counter"-Variable nach int32_t, und verändere sie nur in der Auswerteroutine(ISR_T0). Nicht irgendwo wieder löschen!
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...
:
Bearbeitet durch Moderator
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.
Angehängte Dateien:
-
graph.PNG
18 KB -
TEK00015.PNG
7,1 KB -
graph_vergroessert.PNG
33 KB
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.
:
Bearbeitet durch User
Thomas E. schrieb: > Nebenbei: > Warum ist enc_delta int16? Bei PeDa ist es int8. > Das Rücksetzen von enc_delta muss atomar erfolgen. Das ist ja auch Blendercode, der vortäuschen soll, kurz und schnell zu sein. Ohne permanente ext. Abfrage läuft der 8 Bit Wert schnell über und verfälscht den Zählerstand. Hier reicht allein eine Encoderdrehung. Inkrementaldecoder müssen eigenständig im Hintergrund ohne Fehler bei der Zählung laufen. Auf die Zählervariable wird extern nur lesend zugegriffen.
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.