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
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 :)
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
> 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.
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.
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 :)
> 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.
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
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:
1 | x_t = k_x * t + d_x |
2 | 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
1 | x_0 = k_x * 0 + d_x zum Zeitpunkt 0 soll die X-Achse bei x_0 sein |
2 | 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.
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
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
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.
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 :)
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/loesungen/Robotik_mit_Matlab_Kapitel_05_Loe.pdf -------------------------- Grüße, Florian
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.