Microcontroller AVR 8 oder 8051 ?

Hallo!

Das Problem ist nicht, dass der Controller nicht die korrekten Zeitintervalle generiert. Mein Problem ist momentan der Zusammenhang zwischen aktueller Geschwindigkeit (welche von 0 bis 127 linear ansteigt) und dem Zeitintervall zwischen zwei Schritten. Das beste Ergebniss bekam ich bisher mit der e-Funktion, aber ideal war das auch noch nicht.

Cu, Michael

Reply to
Michael Dreschmann
Loading thread data ...
[...]

Nicht die, die Du nach der Programmierung erwarten wuerdest oder zwar die, die Du Dir ausgedacht hast, aber das sind nict die, die den gewuenschten Effekt bringen?

Hae?? v ~ 1/t D.h. bei 0 unendlich lange warten, bei 1 127 mal so lange wie bei 127...

--
Dr. Juergen Hannappel          http://lisa2.physik.uni-bonn.de/~hannappemailto:hannappel@physik.uni-bonn.de  Phone: +49 228 73 2447 FAX ... 7869
Physikalisches Institut der Uni Bonn Nussallee 12, D-53115 Bonn, Germany     
CERN: Phone: +412276 76461 Fax: ..77930 Bat. 892-R-A13 CH-1211 Geneve 23
Reply to
Juergen Hannappel

Ich glaub ich verstehe. Es gibt da einen Zusammenhang den man nicht haben will nicht wahr? :-) Ich habe dafuer einen weiteren Timer laufen.

Olaf

--
D.i.e.s.S. (K.)
Reply to
Olaf Kaluza

Hallo!

Sorry, da habe ich mich etwas ungenau ausgedrückt. Der Controller generiert schon die Zeitintervalle richtig, so wie sie bei der Programmierung geplant waren. Ich bin mir aber nicht sicher, welche Intervallfolge so ein Motor für einen möglichst guten Beschleunigungsvorgang erwartet.

Ja, das noch durch die e-Funktion gejagt und dann passts etwa. :) Ich beschreibe mal kurz meinen Algorithmus: Geschwindigkeit 0 bedeutet der Motor steht still.

1 - 127 -> Vorwärts laufen

-1 - -127 -> Rückwärts laufen

Wenn nun die Firmware merkt, dass sie den Motor von 0 auf 100% beschleunigen muss, dann erhöht sie die Variable "Speed" um 1 und wartet dann ein bestimmtes Zeitintervall. Wenn das abgelaufen ist erhöht sie die Variable Speed wieder um 1 und wartet dann wieder ein bestimmtes Zeitintervall. Usw... bis Speed den Wert 127 erreicht hat. Die länge des "bestimmten Zeitintervalls" hängt jeweils vom Wert der Speed Variable ab. Desto kleiner Speed, desto grösser der Zeitintervallwert... Da der Zusammenhang jedoch nicht linear ist, habe ich im EEPROM eine Lookup-Table gespeichert, wo jedem Speed-Wert ein Delaywert zugeordnet ist. Und bei dieser Zuordnung hat eine e-Funktion bisher am Besten funktioniert.

Jetzt frage ich mich halt, ob die e-Funktion die "perfekte Funktion" dafür ist und ob mein Problem eventuell eine zu geringe zeitliche Auflösung der Zeitintervalle kurz vor der Höchstgeschwindigkeit ist, oder ob das "e" doch noch nicht der Weisheit letzter Schluss ist.

Wenn mir das jemand sagen könne... würde mir sehr helfen

Cu, Michael

Reply to
Michael Dreschmann

Äh, ich weiss jetzt nicht, ob ich Dich verstehe... Naja, der Zusammenhang ist nicht linear. Wobei da auch noch die Frage ist, wie der Algorithmus arbeitet (siehe oben, da hab ich meinen beschrieben). Bei mir wird die Speed Variable ja nicht (zeitlich) kontinuierlich erhöht sondern nach jedem Schrittmotordelay, d.h. am Anfang langsam, am Ende schnell. Ob es jetzt schlauer wäre, das zu ändern, so dass Speed immer mit konstanten Zeitintervallen läuft müsste man ausprobieren. Vielleicht weisst Du oder jemand anderes es ja auch. Wobei ich aber eigentlich vermute, dass meine jetzt implementierte Variante auch funktionieren muss und es lediglich eine Frage der richtigen Funktion zwischen Speed und Delay ist. Im Grunde brauche ich einfach die Delaywerte die man an einem perfekt funkionierenden System bei einer Beschleunigung messen würde nur 1:1 in meinen EEPROM zu übernehmen... denke ich...

Aber was das alles mit einem Timer zu tun hat verstehe ist jetzt nicht. Ausserdem, wenn ich doch einen Hardwaretimer habe kann ich mir im Prinzip beliebig viele Timer per Software bauen. In meinem Projekt hier werden beide Timer übrigens auch nur direkt für die Lampendimmung verwendet und nur indirekt als Zeitbasis für das Hauptprogramm, welches dann die 4 Schrittmotoren bedient.

Cu, Michael

Reply to
Michael Dreschmann

Ich glaube nicht das es eine perfekte Funktion gibt. Das haengt sicherlich auch stark von der Mechanik ab die dahintersteht und deinem Anwendungsprofil.

Olaf

--
D.i.e.s.S. (K.)
Reply to
Olaf Kaluza

Hallo!

Naja, die Mechanik ist eigentlich recht simpel. Der Motor soll halt eine relativ (zu ihm) grosse Masse bewegen, d.h. genau auf einen Ort positionieren. Dazu muss er erst Beschleunigen und kurz vor Endposition wieder abbremsen. Und dabei soll eben zu jedem Zeitpunkt eine möglichst geringe Kraft "zwischen Motor und Masse" sein. Ich nehme nun an, dass das am Besten mit einer "natürlich wirkenden Bewegung" geht. Und die sollte doch für alle Motorstärken und Massen vom Prinzip her gleich sein. Ihm Grunde will ich eigentlich nur, dass er sich so verhält, als wenn ich einen normalen DC-Motor da hätte :)

Cu, Michael

Reply to
Michael Dreschmann

Ich habe keine Einzelstückpreise, aber der LPC210x von Philips sollte da von der Leistung her gut mithalten können - 60MHz ARM7, Flash mit im Normalfall

0 waitstates, handliches PLCC-Gehäuse. Sobald Du mit mehr als 8-Bit-Daten rechnest, dürfte der den 8051 locker schlagen, und es gibt sehr brauchbare, auch freie, Compiler dafür.

cu Michael

Reply to
Michael Schwingen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.