Druckbare Version
Hallo,
ich kann nicht entdecken, wo die Sub Serial0charmatch(), in der der kritische Term steht, aufgerufen wird.
EDIT: Hab grad entdeckt, was die Sub macht.#-o
Würd ich jetzt auch vermuten.Zitat:
Kann es sein, dass dadurch die Sub zu lange dauert und daher das Programm blockiert?
Vielleicht gibt es Probleme mit dem $hwstack. 32 ist wohl das absolute Minimum wenn Interrupts laufen:
http://halvar.at/elektronik/kleiner_...swstack_frame/
Gruß
Searcher
Hab jetzt die Ursache gefunden: das PWM-Signal für den Motor stört den Inkrementalgeber, selbst wenn der Strom für den Motor abgestellt wird. Wenn ich das Kabel vom Pololu-Board entfern (darüber läuft gerade die PWM) wird wieder richtig gezählt. Anscheinend muss ich dort die Schaltung noch etwas entstören, allerdings weiß ich nicht, wie. An den Bauteilen, wo die PWM anliegt, Kondensatoren parallel zum Gnd-Anschluss legen?
Edit: nun klappt es so halbwegs. Musste noch die Versorgungsleitungen vom Steckbrett und dem Pololu-board miteinander verbinden. Dachte, das wäre über die TTL-Schnittstelle, wo ich auch schon +5V und Gnd angeschlossen hatte, geklärt, aber nun läuft es.
Der Regler läuft, ist erstmal nur ein einfacher Proportionalregler, allerdings musste ich einen kleinen Versatz einbauen wegen der Anlaufspannung am Motor. Dadurch flattert die Welle relativ fix um die Nulllage. Außerdem passiert es hin und wieder, dass er sich verzählt und die Nulllage verschiebt sich. Mal gucken, was sich dagegen machen lässt.
So, jetzt gibts von mir auch mal ein kleines Video.
Zuerst spiel ich nur ein wenig mit der Sollwertvorgabe herum, nicht wundern, dann lenk ich die Antriebswelle ein wenig von Hand aus und im Anschluss ist nochmal die Bedienoberfläche, die ich in Labview erstellt habe, mehr schlecht als recht zu sehen. Ich verstell da auch wieder ein wenig die Sollwertvorgabe, sodass man gemessene Position (weiß) und Geschwindigkeit (rot) in dem Panel sehen kann.
http://www.youtube.com/watch?v=OKjAIZY8F0A
Bekomm das Video leider igendwie nicht eingebettet...
Gratuliere!
Bin selbst an etwas ähnlichem: Quadratursignal vom Mausencoder mit ATtiny24 auswerten und kämpfe gerade damit, ob meine gemessenen Werte bei Vorwärts- und Rückwärtslauf mit den tatsächlichen übereinstimmen. Wie hast Du das gemacht?
Gruß
Searcher
Ich hab jetzt die einfache Version gemacht: wenn die eine GLS einen High-Impuls bekommt, wird die andere GLS abgefragt und je nachdem die Istposition um einen hinauf oder herunter gesetzt. Die Methode 2 Signale=4 Informationen nutze ich bewusst nicht, da ich vermute, dass die Rechtecksignale nicht genau um 90° versetzt sind. Auflösung ist jetzt schon gut genug. Über die UART schickt LabView in regelmäßigen zeitlichen Abständen die Sollposition und erhält als Antwort die Istposition zurück. Die PWM wird dann durch Labview mit einem Soll-Istwert-Vergleich berechnet und über das Pololuboard eingestellt. Zukünftig soll das dann alles auf dem ATmega implementiert werden, zum Testen macht sich LabView aber besser.
Ah, danke, muß ich mir auch nochmal durch den Kopf gehen lassen.
Ich benutze aus dem RN-Wissen diese Methode: http://www.rn-wissen.de/index.php/Dr...ENCODER-Befehl
Die beiden Signale von dem Doppelfototransistor sind auf je einen Pin des gleichen Ports gelegt, maskiert für den gleichen Pin Change Interrupt und in der ISR läuft dann o.g. Programm.
Bei mir sind die Signale auch nicht 90 Grad versetzt, müssen sie auch nicht. Allerdings wird die Zeit für die Auswertung knapper. Ich habe gerade im worst case 40µs Zeit (Oszi) und das sind noch langsam laufende Motore mit wenig Schlitzen in der Encoderscheibe.
Gruß und weiterhin Erfolg
Searcher
Irgendwie kommt mir der Code komisch vor. Einige Syntax ist mir auch neu, vielleicht liegt es daran. Ich finds nur komisch, dass der Sensor nur jede ms abgefragt wird, hieße das, bei 1kHz wäre schon Schluss oder wie? Ich kann mir gut vorstellen, dass bei höheren Geschwindigkeiten gerne mal Schritte verschluckt werden könnten. Der Counter löst ja wirklich immer dann aus, wenn ein Schritt getätigt wird. Alternativ habe ich ach schon von der Methode gelesen, diese Auswertung in der Hauptschleife laufen zu lassen, sodass wirklich ständig abgefragt wird, und alles andere über Interrupts laufen lassen. Dann könnte höchstens ein Schritt verloren gehen, während gerade ein Interrupt ausgeführt wird, allerdings glaube ich, dass das schnell genug läuft. Vorteil ist natürlich, dass man keinen weiteren Timer dafür verbraucht, und wenn ich das auf nem ATtiny umsetzen will, muss ich da schon drauf achten.
Apropos ATtiny: die meisten von den Teilen lassen sich ja gerade mal über SPI ansprechen, allerdings habe ich damit noch keine Erfahrungen gemacht. Ist das ähnlich einfach wie UART oder muss man da mehr Arbeit reininvestieren?
Außerdem soll bei denen der HW-Multiplikator fehlen, wie führt man dann Multiplikationen aus? Geht das so wie sonst auch, nur, dass der Chip halt langsamer arbeitet, oder muss man da auch extra eine Funktion für schreiben?
Ich hab den Code aus RN_wissen schon ein wenig angepaßt. Die ISR wird bei mir nicht in festen Abständen angesprungen, sondern nur wenn ein PCINT auftritt. Wenn das vorzeigbar ist und ich entsprechende Kommentare eingefügt habe, werd ich ihn mal in meinem Blog zeigen.
Der ATtiny24 hat 2 Ports. PortA und PortB. Alle Pins eines Ports können einen zugehörigen Pin Change Interrupt auslösen. Also PinA.x kann PCINT0 und PinB.x PCINT1 auslösen. Im Maskenregister wird bestimmt, welche Pins tatsächlich scharf sind.
Ich beschränke mich nur auf PortA. Das klappt schon mit gewissen Einschränkungen. Wenn das ausgetestet ist kommt ein zweiter Encoder an PortB.
Der PCINT wird bei fallender und bei steigender Flanke ausgelöst. Die beiden Signale vom Doppelfototransistor lösen also in einer Periode vier Interrupts aus. Jedesmal werden also die Statusse (Stati ??) des Quadratursignals ausgewertet.
Ich erhalte damit Werte, die der doppelten Schlitzfrequenz entspricht, da der Algorithmus bei gültigen Übergängen immer Eins addiert, wenn beide Pins low und beide Pins high sind.
Bisherige Tests sind recht plausiebel. Da ich aber noch in Versuchen stecke, alles mit etwas Vorsicht genießen.
Ich denke gerade darüber nach, einen zweiten Tiny einzusetzen, nur um den Motor zu steuern und mit zusätzlicher Lichtschranke die Quadraturauswertung zu überprüfen.
Zur Anzeige benutze ich SW-UART mit 115000 Baud. Weil es aber trotzdem Timingprobleme gibt, speichere ich jede Sekunde die Werte ab (zB 4 Meßwerte) und lasse sie danach jede Sekunde ausgeben (ohne daß eine Messung läuft)
Der Tiny könnte auch SPI was wesentlich schneller wäre als UART. TWI hat er auch. SW-SPI hab ich schon testweise ausprobiert - gut und einfach.
Im Algorithmus wird mit 4 multipliziert. Das habe ich mit zweimal SHIFT LEFT ersetzt.
EDIT Multiplikation geht natürlich auch ohne HW Unterstützung. einfach x * y in Bascom schreiben - ist langsamer als shift.
Gruß
Searcher
So, ich hab jetzt ein wenig weitergemacht. Ich habe eine Vorsteuerung eingebaut, die aus den ersten beiden Ableitungen der Sollposition die benötigte Motorspannung errechnet. Dadurch bewegt sich der Motor im unbelasteten Zustand schon einigermaßen dem Sollpositionsverlauf entsprechend. Dort hab ich dann eine einfache Proportionalregelung gelegt, um die Abweichungen auszuregeln, und das Verhalten gefällt mir bisher schon ziemlich gut. Wesentlich glatter, als die reine Regelung. Allerdings mag er die Ableitungen von der Schiebeleiste nicht so recht, da das doch sehr verruckelt ausfällt. Müsste ich wohl noch ein wenig filtern, damit ein halbwegs glatter Verlauf entsteht.
So, hab mir mal paar von den im Eingangspost erwähnten Getriebemotoren geholt und bin erwartungsgemäß vom Getriebespiel enttäuscht :/
Vom Händler hab ich die Info, dass das Getriebe eine Untersetzung von 1:140 hat, also mal an der Motorwelle gedreht, bis sich der Abtrieb rührt, und ich konnte eine ganze Runde herumdrehen :(
Demnach müsste das Umkehrspiel bei 2,5° liegen, was wirklich beträchtlich ist. Nun bin ich am überlegen, ob es sinnvoller ist, andere Getriebemotoren mit weniger Spiel zu suchen (wo sollte ich da am Besten gucken?) oder als Rückführung nach Art des Servos ein Potentiometer an das tatsächliche Gelenk zu setzen und dessen Wert am Analogeingang zu erfassen. Allerdings wird die Auflösung vom normalen Analogeingang auch nicht so besonders toll sein (10 bit). 1024 Schritte über den gesamten Stellbereich empfinde ich irgendwie immernoch als ein wenig grob, wobei es auch schwierig sein dürfte, auf andere Art und Weise etwas besseres bei vergleichbarem Budget zu realisieren. Außerdem kommt es auch noch darauf an, wie gut die Linearität des Potis ist. Was meint ihr, welche Variante wäre da vielversprechender?