Microcontroller AVR 8 oder 8051 ?

[Olaf Kaluza]

Michael Dreschmann <michaeldre@gmx.de> wrote:

Hast du da vielleicht ein bischen Erfahrung mit "Schrittmotoren und
glatten Bewegungen" ? Dann hätte ich da nämlich mal ein paar Fragen...

Was gibt es da zu fragen? Du musst dir halt sicher sein das der IRQ
fuer die Schritte immer rechtzeitig an die Reihe kommt und niemals
behindert wird.

Olaf


--
D.i.e.s.S. (K.)

 

[Michael Dreschmann]

Hallo!

Was gibt es da zu fragen? Du musst dir halt sicher sein das der IRQ
fuer die Schritte immer rechtzeitig an die Reihe kommt und niemals
behindert wird.

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

 

[Juergen Hannappel]

michaeldre@gmx.de (Michael Dreschmann) writes:

[...]

Das Problem ist nicht, dass der Controller nicht die korrekten
Zeitintervalle generiert.

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?

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.

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/~hannappe
mailto: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

 

[Olaf Kaluza]

Michael Dreschmann <michaeldre@gmx.de> wrote:

Mein Problem ist momentan der Zusammenhang zwischen aktueller
Geschwindigkeit (welche von 0 bis 127 linear ansteigt) und dem
Zeitintervall zwischen zwei Schritten.

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.)

 

[Michael Dreschmann]

Hallo!

Das Problem ist nicht, dass der Controller nicht die korrekten
Zeitintervalle generiert.

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?

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.

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.

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

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

 

[Michael Dreschmann]

On Tue, 9 Dec 2003 22:25:50 GMT, Olaf Kaluza <olaf@criseis.ruhr.de>
wrote:

Michael Dreschmann <michaeldre@gmx.de> wrote:

Mein Problem ist momentan der Zusammenhang zwischen aktueller
Geschwindigkeit (welche von 0 bis 127 linear ansteigt) und dem
Zeitintervall zwischen zwei Schritten.

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

Ä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

 

[Olaf Kaluza]

Michael Dreschmann <michaeldre@gmx.de> wrote:

Jetzt frage ich mich halt, ob die e-Funktion die "perfekte Funktion"
dafür ist und ob mein Problem eventuell eine zu geringe zeitliche

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.)

 

[Michael Dreschmann]

Hallo!

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

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

 

[Michael Schwingen]

In article <3FD47D95.41D9DE46@gmx.net>,
Michael Koch <astroelectronic@gmx.net> wrote:

Der F120 von Cygnal hat 100MIPS und kostet ca. 30 EURO bei 1
Stück. Welcher Standard 16/32 Bit Controller ist schneller
UND billiger?

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