www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Hilfe Schrittmotor Bahnsteuerung?!


Autor: sven möller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich bin gerde dabei mir eine "handsteuerung" für meine cnc fräse zu 
basteln
denke eigentlich ein ganz nettes projekt 3 zähler auf jeweils 7 segment 
anzeigen welche die takt richtungs signale zählen und in mm umrechnen 
s65 farbdisplay für einstellungen bezüglich referenzpunkte 
geschwindigkeiten und zum "mitmalen" der fräsdaten welches leider noch 
nicht so gut klapt da die takt richtungs daten zu schnell sind um sie 
zeitgleich auf nem s65 abzubilden
tastenfeld um die maschine von hand ohne pc zu bewegen
tastenfeld um die emc2 software fernzusteuern so stop play ...
soweit so gut

nunja jetzt habe ich mir vorgestellt vllt in des projekt eine art g code 
interpreter einzubauen
so und jetzt das eigentliche problem wie berechnet man die bahnen?!

es müssen ja alle 3 stepper gleichzeitig ihr ziel erreichen um die 
winkel einzuhalten

meine idee war ermitteln der achse mit dem weitesten weg meinetwegen x 
muss 1000 schritte fahren y muss 100 schritte fahren und z 10 schritte

x ist der haupttakt
alle 10 x schritte einen y
alle 100 x schritte einen z schritt

daas würde klappen


das problem endsteht wenn sich die werte nicht teilen lassen

x 1234
y 55
z 12

alle 22,436363636~... x schritte einen y schritt
alle 102,8333333~---  x schritte einen z schritt

ich kann ja keinen halben schritt zählen
so wenn ich dann als lösung alle 1000 schritte erst einen x schritt 
fahre könne ich wenigstens einwenig der komma schritte abfahren

problem dabei wieder x alle 1000 take verfahren kostet viel zeit bis der 
avr bis 1000 gezählt hat dauerts denke ich zu lange (habe ich noch nicht 
als versuch programiert)

zudem leidet die genauigkeit duch das runden ?!


also leute wie berechnet man sowas ? bitte helft mir

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
dafür nimmt man den Bresenham-Algorithmus.

ciao volker

Autor: sven möller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm ok danke für den tip glauibe ich hab mal wieder versucht das rad neu 
zu erfinden ?! wobei ich denke mein ansatz kann so verkehrt garnicht 
gewesen sein odeR?

bresenham... aus wikipedia ....

Eine erste Implementierung ist nicht sehr elegant, demonstriert das 
Prinzip des Algorithmus aber sehr gut.

 REM Bresenham-Algorithmus für eine Linie im ersten Oktanten in 
Pseudo-Basic

 dx = xend-xstart
 dy = yend-ystart
 REM im ersten Oktanten muss 0 < dy <= dx sein

 REM Initialisierungen
 x = xstart
 y = ystart
 SETPIXEL x,y
 fehler = dx/2

 REM Pixelschleife: immer ein Schritt in schnelle Richtung, hin und 
wieder auch einer in langsame


 WHILE x < xend
    REM Schritt in schnelle Richtung
    x = x + 1
    fehler = fehler-dy
    IF fehler < 0 THEN
       REM Schritt in langsame Richtung
       y = y + 1
       fehler = fehler + dx
    END IF
    SETPIXEL x,y
 WEND



siht eigentlich einfach aus aber ganz verstanden hab ich das jetzt dank 
pseudo-Basic mangel und so noch nicht

naja werd damit mal nen bissel spielen und gucken ob ich des ans laufen 
bringe
vielen dank :)

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, dein Grundgedanke war ja der von Bresenham.
Nur du hast ihn nicht konequent zu ende gedacht.

Viel Spass beim Umsetzzen auf drei Achsen.

ciao Volker

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> dafür nimmt man den Bresenham-Algorithmus.

Nein, bei einer Fräse natürlich nicht.

Wenn ein Stepper wie in der Pixelschleife nur alle 4 bis 5 Schritte des 
anderen mitsteppt, schwingt sich das ganze System auf, die Bahn wird 
zitterig und stufig.

Du weisst (aus den Differenzen) vorher, wie viele Schritte (bzw. 
Mikroschritte) du in die jeweilige Richtung brauchst.

Du weisst (bzw. hast als Konstante vorgegeben oder aus 
Fräserdurchmesser, Material, Anzahl Schneiden, Drehzahl berechnet bzw. 
machst eine 'Schnellfahrt' ausserhalb des Materials mit ganzen Schritten 
statt Mikroschritten) wie schnell und damit wie lange die Fahrt dauert, 
dabei solltest du Beschleunigungsrampen und Bremsrampen einkalkulieren.

Du weisst also zu welchen Zeitpunkten du Schrittimpulse an die 
jeweiligen Achsen senden musst. Das macht dann dein Programm.

ABER: Der G-Code kennt auch Kreisbögen. Ohne die ist eine Handbedienung 
recht witzlos. Denn was man mit Handbedienung gern machen würde, ist ein 
45mm Rundloch mit einer 8mm Fräse.... Und dazu ist es am besten, wenn 
sich der Fräser elliptisch an die Kurve annähern kann, was die 
Berechnung nicht einfacher macht. Hat man floats, macht man sich weniger 
Probleme.

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Nein, bei einer Fräse natürlich nicht.

Und warum beschreibst du dan den Algorithmus in deiner Post?

Natürlich entfernt mann die äuserste Schleife und ruft dann die Funktion 
dan in einer Timer-ISR auf. Wobei die Timerzeit die Geschwindig vorgiebt 
und auch die Rampen bestimmen kann.
Ich wollte aber dem TO auch noch was zum überlegen lassen.

Wie du aber mit Float-Berechnungen unter einen halben Step (wie Step 
auch immer definiert ist: Voll-,Halp oder MicroStep) Fehler kommen 
willst ist mir allerding völlig unklar.

Die Feinheiten (Berücksichtigung des Fräserduchmessers, eliptisches 
Anfahren von Löchern ist Sache der Bahnberechnung und nicht der 
Bahnsteuerung und sollte hier längst erledigt sein.

Autor: sven möller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so jetzt bin ich erstmal wieder ganz verwirrt

zitat mawin

Wenn ein Stepper wie in der Pixelschleife nur alle 4 bis 5 Schritte des
anderen mitsteppt, schwingt sich das ganze System auf, die Bahn wird
zitterig und stufig.

ähm ??? wenn er nicht alle par schitte mitstept ? was soll er dann tun?
ich glaube so bresenham und ich glaube auch meine idee würde auf dem 
prinzip arbeiten

auch der motor kann keine halben schritte bzw schon aber da ich im 
schritt richtungsverfahren arbeite und 1600 schritte eine umdrehung sind 
und ich das auch nicht änern kann oder möchte
muss ich ja zwangsleufig alle x schritte einen y schritt machen auch 
wenn das "pixelig" ist
wobei pixelig sehr fein ausgedrückt ist

1600 schritte pro mm vorschub da wird wohl das nicht auffallen

so ähm fräser berechnen und so ist erstmal unwichtig das mach ich zur 
not im kopf bei der eingabe

zudem muss ich dazusagen ich arbeite bislang mit linux emc2 einen 
kostenlosen cam dxf2gcode und nem cad und ich hab da bislang meine 
zeichnungen immer von hand auf die fräser eingerechnet

ich weiß es gibt die möglichkeit der radienkorektur und so aber 
irgendwie hat die nicht das gemacht was ich wolte also hab ich darauf 
schnell verzichtet und bin damit bislang sehr gut gefahren

nechstes "problem" kreise und co

kerise sind schön
aber kreise kann ich sogar berechnen :)

    x=cos(a*PI/180)*radius
    y=sin(a*PI/180)*radius

wobei a von 0-360° gezählt wird

als ausgabe habe ich meine wunderschönen x y koordinaten
welche ich halt noch nicht anfahren kann

vllt is das auch noch keine perfekte lösung aber auf pixelorientierten 
displays klappt das ganz gut

ich werd jetzt erstmal den bresenham programieren und denn mal sehen was 
so geht :)

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und warum beschreibst du dan den Algorithmus in deiner Post?

Tue ich nicht, sondern sage daß das, was sich sven möller um 14:11 
ausgedacht hat schon richtiger war als deines, er aber den Ansatz wählen 
sollte von der Zeitachse ausgehend zu denken, und nicht von der 
Schritt(Entfernungs)achse.

Leider hat er's nicht ganz verstanden:

> ähm ??? wenn er nicht alle par schitte mitstept ? was soll er dann tun?

Die Motoren sollten zeitlich asynchron ihre Schritte machen.
Wenn einer 5 und der andere 7 machen muss also:

|    |    |    |    |    |    |    |
|      |      |      |      |      |

zusätzlich noch am Anfang/Ende gedehnt als Start/Stopprampe:

|        |      |    |    |    |      |        |
|          |        |      |        |          |

Die Zeiten lassen sich mit floats leicht ausrechnen, und dann auf ein 
festes, ganzzahliges (aber natürlich möglichst hochauflösendes) 
Zeitraster runden.

Man implementiert das dann z.B. so, daß man vorher eine Tabelle mit den 
Zeitdifferenzen und den Impulsen erzeugt, in einem Timer-Interrupt dann 
jedesmal den Timer auf den nächsten Zeitintervall umprogrammiert, 
zumindest habe ich das so gemacht:

Zustand: 00 Zeit: 9
Zustand: 01 Zeit: 2
Zustand: 11 Zeit: 5
Zustand: 10 Zeit: 4
Zustand: 00 Zeit: 1
Zustand: 01 Zeit: 5
Zustand: 00 Zeit: 1
Zustand: 10 Zeit: 4
Zustand: 11 Zeit: 5
Zustand: 01 Zeit: 2
Zustand: 00 Zeit: 9

> aber kreise kann ich sogar berechnen :)

Jupp, wenn der uC sin und cos kann. Sonst muss man mit Tabellen oder 
CORDIC arbeiten, was mittelmässig ätzend ist.

Autor: sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok mawin

das klint wesentlich besser noch
ich habe nun den Bresenham programiert
zumindest aufm pc und das ergebnis ist nicht schlecht
aber vllt auch nicht umbedingt gut
weil halt auf der y z-b- 3 takte nacheinander kommen dann längere pause 
dann wieder 2 takte ...

irgendwie ungleichmäßig

obwohl ja Bresenham scheinbar da soeine art standart zu sein scheint
würde mit das mit den gleichbleibenden takten eher zusagen

so jetzt steh ich also wieder so da
und weiß nicht so recht wie ich die taktzeiten ausrechnen kann

---> Die Zeiten lassen sich mit floats leicht ausrechnen

wenn ich jetzt wüste was floats sind o.O

liebe grüße

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sven schrieb:

> ich habe nun den Bresenham programiert

Der Bresenham ist für diesen Fall nicht so toll.
Das Problem:
  Der Bresenham berücksichtigt nicht, dass ein Schritt in X-Richtung
  weniger Weg abfährt als ein Schritt in diagonaler Richtung.
Von daher ist es schwierig, mit dem Bresenham eine konstante 
Schnittgeschwindigkeit zu fahren.

Oder anders ausgedrückt:
Aus dem Bresenham kriegst du für den Verfahrweg 0;0 -> 100;0 zwar deine 
100 Schritte raus. Aber auch beim Verfahren 0;0 -> 100;100 kriegt man 
100 Schritte raus. Der zurückzulegende Weg ist aber im 2.ten Fall um den 
Faktor Wurzel(2) länger. Dementsprechend fährt dein Fräser dann 
Diagonalen schneller ab als Wege entlang der Hauptachsen.

> so jetzt steh ich also wieder so da
> und weiß nicht so recht wie ich die taktzeiten ausrechnen kann

Du stellst die anzufahrende x;y Position als Funktion der Zeit dar:
   x_t = k_x * t + d_x
   y_t = k_y * t + d_y

Du kennst den Verfahrweg von x_0;y_0 nach x_1;y_1 insgesamt (Phytagoras) 
und weisst mit welcher Geschwindigkeit du den abfahern willst. Daraus 
errechnest du dir wie lange das dieser Weg dauern wird. Damit kennst du 
t_tot.

mit x_0, x_1 und t_tot kannst du dir für die erste Gleichung k_x und d_x 
berechnen. Es gilt: wir wissen
     x_0 = k_x * 0     + d_x     zum Zeitpunkt 0 soll die X-Achse bei x_0 sein
     x_1 = k_x * t_tot + d_x     zum Zeitpunkt t_tot soll die X-Achse bei x_1 sein

und damit kann man k_x und d_x bestimmen. Das selbe dann noch in der y 
Richtung und man hat alle Zutaten beisammen.

Und dann lässt du ein t in Schritte von 0 bis zu diesem t_tot laufen, 
errechnest dir mit den Geradengleichungen da oben die anzufahrenden 
Positionen und fährst sie einfach an. Wenn die Schrittweiter klein genug 
ist, kriegst du auch keine Probleme damit, dass eine Achse von einem 
Zeitpunkt zum nächsten mehrere Schritte auf einmal ausführen muss.

Anfahr und Abbremsrampen kann man dann zb programmieren, indem man Gott 
spielt und die Zeit im Rechner dehnt. Das Programm rechnet zwar mit zb 
0.1 Sekunden aber am Anfang des Verfahrwegs lässt man einen 
demenstrechenden 0.1 Sekunden Schritt nur alle 0.5 Sekunden zu. 
Sukzessíve wird dann die Dehhnung verringert, bis man auf der 
endgültigen Geschwindigkeit ist.

Ist jetzt nur so eine Idee.

Besser ist es wahrscheinlich die Rampen explizit auszuformulieren und 
den Verfahrweg in 3 Teile aufzuteilen.

>
> ---> Die Zeiten lassen sich mit floats leicht ausrechnen
>
> wenn ich jetzt wüste was floats sind o.O

Gleikomma.

Aber im Ernst. Wenn du diese Frage stellen musst, solltest du erst 
einmal ein wenig C-Grundlagen pauken und am PC ein wenig üben.

Autor: sven möller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohweih ohweih
das wird ja immer komplizierter


zitat Karl heinz
Aus dem Bresenham kriegst du für den Verfahrweg 0;0 -> 100;0 zwar deine
100 Schritte raus. Aber auch beim Verfahren 0;0 -> 100;100 kriegt man
100 Schritte raus. Der zurückzulegende Weg ist aber im 2.ten Fall um den
Faktor Wurzel(2) länger. Dementsprechend fährt dein Fräser dann
Diagonalen schneller ab als Wege entlang der Hauptachsen.
zitat ende

ich denke ich habs mal wieder nicht verstanden

verfahrweg 0:0 bis 100:0 sind 100 takte auf x
verfahrweg 0:0 bis 100:100 sind 100 takte auf x und 100 auf y
weil 100:100 ist ja meine absolute ziel position

jetzt frage ich mich warum sollte ich die länge der gerade ausrechnen?

wenn meine koordinaten nun mm währen hätte ich
bei 0:0 zu 0:100 eine gerade von 100 mm
und bei 0:0 zu 100:100 eine gerade 141,42mm habe aber dennoch nur die 
für mich relevante position 100:100 angefahren

das ganze währe interesannt wenn ich startpunkt winkel und länge als 
vorgabe hätte
oder ??



ich glaub ich tendire langsam wieder zu meiner eigentlichen grundidee 
weil recht einfach und dennoch vermutlich besser wie der brasham
zeiten ausrechnen und abfahren denke ich werd ich aber auch noch 
versuchen und dann mal sehen welche lösung am besten klappt bzw sich am 
besten umsetzen läst

nun ich hätte nicht gedacht das das doch so "ausartet" wo ich mit dem 
projekt angefangen hab dachte ich mir na dann takte ich halt mal zu der 
position :)



> ---> Die Zeiten lassen sich mit floats leicht ausrechnen
>
> wenn ich jetzt wüste was floats sind o.O

Gleikomma.

Aber im Ernst. Wenn du diese Frage stellen musst, solltest du erst
einmal ein wenig C-Grundlagen pauken und am PC ein wenig üben.

nur weil ich iergendwelche begriffe nicht kenne soll ich nun c lehrnen ? 
find ich blöd! ich schreib fast alle programme in asm und die 
programierung macht mir eigentlich auch wenig sorgen eher die idee zur 
grundlage

mein problem weswegen ich hier gefragt hatte war ja das ich von der 
"formel" her etwas überlastet bin und wie du ja sihst gibt es in diesem 
beitrag schon mehrere unterschiedliche ideen


liebe grüße

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@ Karl heinz Buchegger
>>Datum: 24.02.2010 02:20
....................^^^^^^
...wenn ich mal Nachts nicht schlafen kann, lese ich immer ein klenes 
Hex-Listing ;-)

@Sven
Die Bahnensteurung für Linie und Kreis(bogen) ist eigendlich simpel. 
Interessant wird es erst mit Fräsradienkorrektur (G40..G42).

Bei mir rechne ich Stufenweise
1. Werte für Linie oder Kreis berechnen
2. Übergabe Steuerbyte an einen FiFo, wegen Start/Stop
3. Steuerbyte aus dem FoFo holen, senden und Timer je nach Anzahl der 
gleichzeitig bedienten Achsen mit einem modifizierten Wert laden.
Dabei gilt: 1 Achse Timerwert, 2 Achsen :Timerwert*SQRT(2) , 3Achsen: 
Timerwert * SQRT(3). Dadurch wird unabhängig von der Bahkurve immer die 
selbe Geschwindigkeit gefahren. Als Rampe für Start/Stop nehme ich 
sin^2.

Alles in 8051 MacroAssembler.

Mit Gruß
Pieter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sven möller schrieb:
> ohweih ohweih
> das wird ja immer komplizierter

Halb so wild.
Das hört sich schwieriger an als es ist.

>
>
> zitat Karl heinz
> Aus dem Bresenham kriegst du für den Verfahrweg 0;0 -> 100;0 zwar deine
> 100 Schritte raus. Aber auch beim Verfahren 0;0 -> 100;100 kriegt man
> 100 Schritte raus. Der zurückzulegende Weg ist aber im 2.ten Fall um den
> Faktor Wurzel(2) länger. Dementsprechend fährt dein Fräser dann
> Diagonalen schneller ab als Wege entlang der Hauptachsen.
> zitat ende
>
> ich denke ich habs mal wieder nicht verstanden
>
> verfahrweg 0:0 bis 100:0 sind 100 takte auf x
> verfahrweg 0:0 bis 100:100 sind 100 takte auf x und 100 auf y
> weil 100:100 ist ja meine absolute ziel position

Aus dem bresenham fallen nicht Takte an.
Aus dem Bresenham fällt bei dir die nächste anzufahrende Position raus.

Bei einer Gerade von 0;0 nach 8;0 kommt aus dem Bresenham

   0;0   1;0   2;0   3;0   4;0   5;0   6;0   7;0   8;0

Bei einer Geraden von 0;0 nach 8;0 kommt aus dem Bresenham

   0;0   1;1   2;2   3;3   4;4   5;5   6;6   7;7   8;8

In beiden Fällen teilt der Bresenham die abzufahrende Strecke in 9 
anzufahrende Positionen auf. Aber im 2-ten Fall ist die abzufahrende
Strecke länger als im ersten Fall


> nur weil ich iergendwelche begriffe nicht kenne soll ich nun c lehrnen ?
> find ich blöd! ich schreib fast alle programme in asm und die
> programierung macht mir eigentlich auch wenig sorgen eher die idee zur
> grundlage

Du schreibst das in Asm?
Hut ab, meinen Respekt.

Würd ich mir nicht antun.
Alleine schon deswegen, weil das was ich dir weiter oben vorgeschlagen 
habe, in C ein (über den Daumen) 15 Zeiler ist, den man in 10 Minuten 
hinschreiben kann und der 10 Minuten später soweit debuggt ist, das es 
läuft.

Autor: sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hoi

nunja das aus dem bresenham keine takte kommen ist schon klaar zumindest 
in seiner ursprungsvorm werden variablen incrementiert das hatte ich 
aber schon beim ersten versuch durch ausgabe von einem takt modifiziert
nun denke ich aber mittlerweile (durch testen) das bresenham zwar geht 
aber irgendwie nicht das is was ich mir vorgestellt hab
wobei ich vllt zu genau denke wenn man mal so rumgoogelt findet man x 
fräsprogramme welche irgendwie alle auf bresenham laufen sollen 
zumindest steht es bei vielen dran
mag aber vllt auch dran liegen das das eine einfache art ist ans ziel zu 
kommen

nunja asm nutze ich weil meine c kentnisse nicht so gut sind und 
keinesfalls ausreichen
und ich denke bis ich c komplett versanden hab hab ich das allemal in 
asm fertig


interesieren würde mich nun was kommt aus dem linux emc2
vllt werd ich das die tage mal ausmessen

zu Pieter
auf Fräsradienkorrektur werde ich verzichten das werd ich mir nicht 
antun :)

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,

ich bin auf der Suche nach einem Problem auf folgenden Link gestoßen 
(s.u.).
Sicherlich ist dieses Thema schon ein paar Tage alt und ich hoffe, dass 
du deine Steuerung trotzdem realisieren konntest.
Wie auch immer, für dich und alle Anderen, die auf das Problem mit den 
zwei Achsen stoßen, hier die Lösung:

Unter anderem wird auch verständlich gezeigt, wie das mit der 
Beschleunigung ist. Zu guter letzt müssen nur noch die notwendigen 
Schritte des Motors in Abhängigkeit des Takts ermittelt werden. Aber das 
bekommt ihr schon hin!


-----(Seite 3 und 4)-----

http://www.hs-augsburg.de/stark/robotik_mit_matlab...

--------------------------

Grüße, Florian

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.