www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Thema: Atmega 32: Ich brauche mehr Rechenleistung für meine CNC


Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr µC Freunde!

Ich wende mich mit einer Frage zu einem schon recht fortgeschrittenen 
Projekt an euch: ich habe vor einiger Zeit begonnen eine 3-Achs 
CNC-Steuerung zu Programmieren, welche auf einem Atmega 32 läuft. Die 
Daten für diese werden in einer Windowsanwendung generiert und dann mit 
115200baud seriell an den µC übertragen. Zu Anfang, als ich nur geraden 
interpoliert habe, hatte ich kaum Probleme. Dafür hat der Atmega 32 
eindeutig genug Leistung. Inzwischen ist die Steuerung jedoch gewachsen:
-  Geraden/Kreise werden interpoliert
-  die Achsen werden linear abgebremst/beschleunigt
-  es werden permanent die Achsenwerte an Windows übermittelt
-  ein prozentuelle Vorschubberechnug erfolgt
-  ein Handrad wird ausgewertet
-  Taktrichtungssignale werden erzeugt
All diese Aufgaben sind mehr oder weniger rechenintensiv und erfordern 
viele Interrupteinsprüng, so dass ich, wenn ich Kreise interpoliere und 
gleichzeitig noch Sätze empfange, eine maximale Vorschubgeschwindigkeit 
von ca. 1000 mm/min erreiche. Was bei meinen Motoren/Gewindespindeln 
eine Taktrate von 2666Takten/sec entspricht. Stelle ich die 
Vorschubgeschwindigkeit höher ein, so fährt meine CNC undefinierte werte 
an, da vermutlich Interrupteinsprünge durch den zu hohen Rechenaufwand 
übergangen werden.
Geraden lassen sich logischerweise sehr viel schneller ausführen, da 
hier keine Quadrierung von 24bit werten nötig ist.

Um die hohe serielle Übertragungsrate zu ermöglichen lasse ich den µC 
mit 14.746 Mhz laufen. Das gesamte Programm ist in Assembler 
geschrieben.

Nun überlege ich was ich tun kann um eine schnellere Ausführung zu 
ermöglichen. Klar Codeoptimierung ist natürlich an der einen oder 
anderen Stelle noch möglich, doch das sind geringe Zeiten, die ich so 
noch rausholen kann.
Die Tackfrequenz auf 16Mhz zu erhöhen ist auch noch möglich bewirkt 
jedoch auch nicht viel. Außerdem wäre dann auch die Baudrate zu 
verringern. Doch das möchte ich ungern!

Die einzige Idee dich habe lautet: einen anderen Controller! Aber gibt 
es einen  Controller der viel schneller ist als 16 Mhz und trotzdem mit 
meinem Code zurecht kommt? Wohl kaum oder? Es wäre schade, wenn ich am 
Ende dieser enormen Arbeit feststellen müsste, dass ich mich mit den 
Geschwindigkeiten zufrieden geben muss.

Herzlichen Dank für euer Mitdenken, vielleicht habt ihr ja eine Idee…

Grüße,
Andreas

Autor: mp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da haben wir wieder ein tolles Beispiel für Assemblerprogrammierung !!!

Super Idee !!!

Mit C hättest du das ganze an einem Wochenende auf nen ARM oder PIC24 
umgesetzt und fertig.

Autor: Marcus Müller (marcus67)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist nícht so viel zu machen - es gibt ein paar neue Atmels, die 20Mhz 
können (sogar Pin kompatibel zum Mega 32) z.B. Mega 324P oder 644P - das 
wars dann allerdings.

Sonst hilft nur eine neue Architektur (32 Bit Xmega, Coldfire, ARM).

Wie ist denn die Software geschrieben ? - Wenn es C ist, kann man es in 
aller Regel ganz gut portieren. Wenn es Assembler oder gar Basic ist, 
sieht es natürlich schlecht aus.

Gruß, Marcus

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum reichen dir 1000mm/min zum fräsen nicht?
Man könnte einige Aufgaben auf einen zweiten µC auslagern, z.B. die 
Kreisberechnung.
Angenommen der Tisch hat 1000mm Länge dann sollten 16Bit Werte reichen, 
das ergibt eine Auflösung von 15µm.

Autor: Till Uhde (tuhde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst die verschiedenen Aufgaben auf mehrere Controller verteilen 
und sie per SPI verbinden.
RS232 Kommunikation,
Interpolation,
Ansteuerung der Motoren und
Abfrage des Handrad
sollten sich gut von einander trennen lassen. Die Interpolation kannst 
Du, wenn nötig, sogar noch für jede Achse mit einem eigenen Controller 
ausstatten.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest erst einmal die Teile identifizieren, die am meisten 
Rechenleistung fressen. Du hast z.B. etwas von "Quadrierung von 
24Bit-Zahlen" geschrieben. Da solltest du einmal schauen, ob es da für 
deine Zwecke nicht bessere Algorithmen oder Näherungsverfahren gibt. Was 
Kreisfunktionen betrifft, kannst du einmal nach dem Stichwort "CORDIC" 
suchmaschinen.

Gruß, DetlevT

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie machst du die Kreise? Bresenham?

Ralf

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also im ersten Augenblick würde ich einen XMEGA nehmen. Ich hab 
allerdings mit dem Teil keine Erfahrungen. Der läuft (glaub) mit ca. 
30/32 MHz. Die Teile bekommnt man aber (noch) nicht bei den Hobby 
Distributoren.

Alternativ könntest Du einen STM32 nhemen. Das ist ein ARM Controller, 
mit Cortex-M3 Kern. Die Teile laufen mit bis zu 72 MHz. Als Compiler 
kannst den von Raisonance benutzen. Der JTAG Adapter kostet ca. 100 
Euro. Debug ist auf 32k beschränkt. Programmieren geht ohne 
Einschränkung.

Für 24-bit Arithmetik sollte die 32-bit Architektur reichen ;-)

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Warum lässt Du die Kreise nicht vom Steuer PC in viele kleine Geraden 
zerlegen und die dann zum µC übertragen. Damit kann man am µC relativ 
viel Rechenleistung einsparen und der PC hat dann auch noch etwas zu 
tun...

Gruß,
Tubie

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Also im ersten Augenblick würde ich einen XMEGA nehmen. Ich hab
>allerdings mit dem Teil keine Erfahrungen. Der läuft (glaub) mit ca.
>30/32 MHz. Die Teile bekommnt man aber (noch) nicht bei den Hobby
>Distributoren.

Doch. CSD.

MfG Spess

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also von der Beschreibung würd ich auch sagen das eher ein Problem der 
herangehensweise ist oder vieleicht ein Software bug?
So arg viel zu tun hat der AVR ja nicht. Außerdem kannst du mit 
passendem Quarz (z.b.18,....) auch hohe Baudraten fahren auch wenns 
etwas außerhalb der Spezifikation ist.
Ansonsten wie schon gesagt, wenn eh der PC rumsteht mach doch die 
aufwändigen Berechnung im Zweifel dort.
Ansosnten solltest du IRGENWIE versuchen rauszubekommen wo wirklich die 
Zeit verloren geht, ggf kann man da ja relativ leicht was drann 
drehen...

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke wer in Assembler programier, weiß was er tut.
Andreas schrieb ja schon:
> Geraden lassen sich logischerweise sehr viel schneller ausführen, da
> hier keine Quadrierung von 24bit werten nötig ist.

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor eineiger Zeit auch mal eine Radiusinterpolation 
programmiert. Ich bin hergegangen und habe ein externes EProm als 16 Bit 
Sinus Generator mißbraucht. Das ergebnis war, das es ab diesem Zeitpunkt 
keinen unterschied mehr machte, ob der µC eine Gerade fährt oder einen 
Radius. 16 Bit Adresse rein (2 Befehle) 16 Bit Daten raus (wieder 2 
Befehle) und der Sinus Wert steht im Register. Ok, zwischendrin noch auf 
Eingang umschalten.

Heute würde ich das mit einem schnellen SPI oder I²C@1Mhz machen.


Gruß,
Tubie

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander Schmidt schrieb:
> Ich denke wer in Assembler programier, weiß was er tut.
> Andreas schrieb ja schon:
>> Geraden lassen sich logischerweise sehr viel schneller ausführen, da
>> hier keine Quadrierung von 24bit werten nötig ist.
Niemand ist fehlerfrei ich hab auch größere Sachen in ASM programmiert, 
trozdem hatte ich den ein oder anderen Bug der sich nur unter bestimmten 
Bedingungen zeigte...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt: Wofür die Quadrierung? Kreisgleichung? Wohlmöglich noch 
Gleitkommazahlen?

Das geht einfacher mit Lookup Table (wie Tubie sagt). Das Ganze kann man 
bei großen AVRs problemlos im Flash ablegen und in sehr wenigen 
Taktzyklen laden.
Oder gleich mit nem anderen Algorithmus nach CORDIC oder Bresenham.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tubie (Gast)

>Heute würde ich das mit einem schnellen SPI oder I²C@1Mhz machen.

Heute gibts AVRs mit 256k Flash. ;-)
Und man kann auch relativ schnell interpolieren, das spart ziemlich viel 
Flash.

MfG
Falk

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ACK

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich weis zwar nicht was du genau mit der CNC -Steuerung anfangen willst, 
aber einen Vorschub von 1m/min wirst du z.B. bei Fräsmaschinen höchsten 
für den Eilgang brauchen, aber nie als Vorschub beim Fräsen.

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krass, ihr habt ja viel zu sagen :-) esrtmal danke!
So aber an die die sich hoffentlich jetzt angesprochen fühlen: bitte 
erst mal lesen dann schreiben!
Ja ich programmiere in Assembler aus gutem Grund, da ich, wie ja auch so 
zu merken, an die Grenzen des Atmega32 stoße. Den hatte ich gewählt, um 
nicht schließlich bei smd Bauteilen zu landen außerdem ist er schön 
günstig...

Und nochmal das Projekt ist schon sehr weit! Die Steuerung funktioniert 
komplett nur eben mit Fehlern, die sich verdammt schwer eingrenzen 
lassen!
Also Grundlegende Gedanken zu Maschinengröße sind nett aber, nicht so 
ganz das Thema. Und meine 24bit variablen brauch ich schon! Ja und auch 
für den Bresenham (jedenfalls wird er so genannt - Bresenham gibt es 
ansich nur für Geraden) - und nochmal das es alle verstehe ich arbeite 
nicht mit Gleitkommazahlen!!!

Zu CORDIC könnte ich allerdings mal was lesen davon habe ich bisher noch 
nichts gehört - danke!

Tubie schrieb:
> Ich habe vor eineiger Zeit auch mal eine Radiusinterpolation
> programmiert. Ich bin hergegangen und habe ein externes EProm als 16 Bit
> Sinus Generator mißbraucht. Das ergebnis war, das es ab diesem Zeitpunkt
> keinen unterschied mehr machte, ob der µC eine Gerade fährt oder einen
> Radius. 16 Bit Adresse rein (2 Befehle) 16 Bit Daten raus (wieder 2
> Befehle) und der Sinus Wert steht im Register. Ok, zwischendrin noch auf
> Eingang umschalten.

Das mit dem 16 Bit Sinus Generator im Eprom ist mir noch nicht klar!
Wobei ich ja auch für meinen Algorithmus keine Winkelfunktionen brauche! 
Klingt aber trotzdem interessant. Was sind Lookup Table?

>Also von der Beschreibung würd ich auch sagen das eher ein Problem der
>herangehensweise ist oder vieleicht ein Software bug?
>So arg viel zu tun hat der AVR ja nicht.

Denken kannst du das ja, wobei es meiner meinung nach völlig logisch 
ist, dass hier nicht mehr viel Rechenleistung übrig bleibt, wenn ich 
schon 115200 baud gewählt habe und alle drei timer mit teilweise nicht 
kurzen Rechnungen laufen habe!

>ich weis zwar nicht was du genau mit der CNC -Steuerung anfangen willst,
>aber einen Vorschub von 1m/min wirst du z.B. bei Fräsmaschinen höchsten
>für den Eilgang brauchen, aber nie als Vorschub beim Fräsen.

Das ist völlig richtig! Ich hab schon so einiges an Spänen erzeugt... 
Allerdings brauch ich, je nachdem wie hoch die Auflösung der 
angeschlossenen Fräsmaschine/Microschschritsteuerung ist sehr viel 
höhere Taktraten als ich geschrieben habe. Im Eilgang erreiche ich ja 
wie gesagt auch eine höhere Geschwindigkeit. Da die Geschwindigkeiten 
wie sie sind (für meine Maschine) ausreichen kann ich mich mit der 
ganzen Sache auch abfinden. Doch wenn ich schon so eine ganze Steuerung 
gebaut habe fände ich es toll, wenn auch andere in den Genuss dieser 
kommen können. Da wäre etwas mehr Leitung noch schöner...

Glaubt bitte nicht, dass ich mir über die ganze Sache noch nicht 
wirklich gedanken gemacht habe ich bin an diesem Projekt mit teilweise 
sehr langen pause viele Monate. Ich weiß was ich von meiner Steuerung 
will. Aber fürs sinvolle mitreindenken bedanke ich mich!

Grüße,
Andreas

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

ich müßte mal das alte Projekt wieder rauskramen. Ist schon ne Weile her 
aber es war mit einem AT90S8535 bei 8Mhz. Den Kreis kann man entweder 
mit Quadraten/Wurzeln berechnen oder halt mit Sinus.

In der Look up Tabelle werden ganz einfach gesagt in einem Speicher ALLE 
möglichen Ergebnisse abgespeichert. Diese können dann jedewrzeit wieder 
abgerufen werden. Ich habe z.B. den Sinus von 0-90° abgelegt.

Den Winkel als 16 Bit wert angelegt:  0° = $0000, 90° = $FFFF

als Ergebnis bekommt man 2 Takte später fix und fertig den 
entsprechenden Sinus Wert. Damit kann man dann wunderbar alle möglichen 
Kreisberechnungen machen. Bei 16 Bit wären das aber schon alleine 256kB 
an ROM Speicher.

Gruß,
Tubie

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Andreas Heyl (entenkind)

>Ja ich programmiere in Assembler aus gutem Grund, da ich, wie ja auch so
>zu merken, an die Grenzen des Atmega32 stoße.

Das sind DEINE Grenzen, nciht die des AVRs ;-)


>Und nochmal das Projekt ist schon sehr weit! Die Steuerung funktioniert
>komplett nur eben mit Fehlern, die sich verdammt schwer eingrenzen
>lassen!

Heheh, das ist wohl einer der klassischten Sprüche auf dem Gebiet.

"Eigentlich alles fertig, nur noch ein paar Kleinigkeiten . . ."

>für den Bresenham (jedenfalls wird er so genannt - Bresenham gibt es
>ansich nur für Geraden)

Aus denen man bei entsprechnder Anzahl einen Kreis approximieren kann, 
den viele Ecken wirken rund.

>Das mit dem 16 Bit Sinus Generator im Eprom ist mir noch nicht klar!

Ganz einfach, Winkel rein, Sinus raus. Ist eine schlichte, grosse 
Tabelle!

>Klingt aber trotzdem interessant. Was sind Lookup Table?

Ach ja, da waren wieder die Grenzen des AVRs . . . ;-)

>Denken kannst du das ja, wobei es meiner meinung nach völlig logisch
>ist, dass hier nicht mehr viel Rechenleistung übrig bleibt, wenn ich
>schon 115200 baud gewählt habe und alle drei timer mit teilweise nicht
>kurzen Rechnungen laufen habe!

Das haben vor dir schon zu viele gesagt, und sind kurz darauf mit langem 
Gesicht, dafür aber deutlich besserem Programm hier wieder abgezogen.

>höhere Taktraten als ich geschrieben habe. Im Eilgang erreiche ich ja
>wie gesagt auch eine höhere Geschwindigkeit.

Und genau DORT brauchst due KEINE hohe Auflösung, wahrscheinlich nicht 
mal Kreise. Nur einfache Linien. Ein Schiff auf dem Ozean navigiert auch 
nicht mit cm-genauer Präzision (auch wenn das heute im GPS-Zeitalter 
problemlos geht). Sondern eher im Bereich von Meilen. Erst in Küstennähe 
muss man genauer navigieren. Aber natürlich auch auf hoher See den 
Ausguck besetzten, man will ja keinen Blauwal rammen ;-)

>kommen können. Da wäre etwas mehr Leitung noch schöner...

Kauf dir nen Golf.

>Glaubt bitte nicht, dass ich mir über die ganze Sache noch nicht
>wirklich gedanken gemacht habe ich bin an diesem Projekt mit teilweise
>sehr langen pause viele Monate.

Das ist ein Mass der Quantität, welches nur schwach mit Qualität 
korrelliert ist.

> Ich weiß was ich von meiner Steuerung will.

ALLLES!

MfG
Falk

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, verstehe! Wegen des großen Speicherbedarfs kommt so etwas bei mir 
sowieso nicht in frage, da mir 16bit sowieso nicht ausreichen. Meine 
Maschine ist dafür zu groß, außerdem bin ich damit wieder sehr 
eingeschränkt was andere Steuerungen/Maschinen angeht. Ganz abgesehen 
davon werde ich nicht noch mal alles umbauen. Das schaffe ich zeitlich 
nicht...

Noch was anderes: habt ihr Tipps wie eine Fehlersuche am effektivsten 
ist, wenn ein Fehler nur ca. alle Fünftausend NC-Sätze auftaucht und 
dann selten wiederholbar. Also ich suche noch Ideen wo ich suchen 
könnte. Es muss ja (was anderes kann ich mir nicht denken) was mit den 
ISR´s zu tun haben und nicht gesicherten Registern (nur sollte es so was 
bei mir schon lange nicht mehr geben...)? fallen euch weitere 
Fehlerquellen ein - ganz allgemein!

Ich habe bisher nicht mit dem JTAG Anschluss gearbeitet, aber wie weit 
könnte der mir bei einer derartigen Fehlersuche helfen?

Grüß,
Andreas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Andreas Heyl (entenkind)

>Noch was anderes: habt ihr Tipps wie eine Fehlersuche am effektivsten
>ist, wenn ein Fehler nur ca. alle Fünftausend NC-Sätze auftaucht und
>dann selten wiederholbar.

Böse Stresstests. Komplexe Muster, 110% Geschwindigkeit etc.

MFG
Falk

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ganz nebenbei mal die grenzen des AVR sind hier zu sehen...

Youtube-Video "Uzebox - Atmel AVR based Game Console (Only two chips used!)"

Gruß,
Tubie

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi


>Ja ich programmiere in Assembler aus gutem Grund, da ich, wie ja auch so
>zu merken, an die Grenzen des Atmega32 stoße.

Die wahrscheinlich am einfachste Alternative wäre der ATMega644. 
Pinkompatibel mit den ATMega32. Doppelter Flash, RAM, EEPROM und 20MHz 
garantiert (mit Sicherheit auch mehr). Bei der Frequenz sind alle 
gängigen Baudraten bis 115200Bd (Bei Double Speed auch 230400Bd) mit 
ausreichender Genauigkeit zu erreichen. Die Hauptarbeit bei der 
Implementierung deiner Software dürfte die Änderung von 
in/out-IO-Zugriffen in lds/sts-Zugriffe sein.

>Den hatte ich gewählt, um nicht schließlich bei smd Bauteilen zu landen

SMD ist kein Grund zu Fürchten.

> außerdem ist er schön günstig...

2..3€ dürften aber bei dem Projekt keine Rolle spielen.

MfG Spess

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry "Falk Brunner" - aber was soll das?

Kaum ein Kommentar welches du so hinterlässt ist irgendwie sinnvoll!
Und deine Schiffsgeschichte ist ja wohl echt zum lachen. Ich beschäftige 
mich seit Jahren mit der CNC Thematik und ich denke ich weiß wirklich 
was ich will! Ich meine nicht dass ich alles könnte und dass alles 
optimal wäre, sonst hätte ich hier ja nicht nachgefragt!

>Und genau DORT brauchst due KEINE hohe Auflösung

Ich sage dazu jetzt mal nur: Schrittmotoren und Absolutmaßerfassung!

Danke an die, die schreiben, da sie Ideen beisteuern wollen und nicht um 
sich besser zu fühlen, wenn sie anderen zeigen, dass sie vermeintlich 
völlig bescheuert und überheblich wären!


>>Ja ich programmiere in Assembler aus gutem Grund, da ich, wie ja auch so
>>zu merken, an die Grenzen des Atmega32 stoße.

>Das sind DEINE Grenzen, nciht die des AVRs ;-)

Und ob es diese grenze beim AVR gibt! Ob sie jetzt gering darüber liegt 
oder nicht ist für die Thematik völlig unerheblich!


>>Und nochmal das Projekt ist schon sehr weit! Die Steuerung funktioniert
>>komplett nur eben mit Fehlern, die sich verdammt schwer eingrenzen
>>lassen!

>Heheh, das ist wohl einer der klassischten Sprüche auf dem Gebiet.

>"Eigentlich alles fertig, nur noch ein paar Kleinigkeiten . . ."

Du bist echt ein toller Hecht! Wau!
Diese Steuerung hat sicher schon einige Kilometer an Fräsweg 
zurückgelegt. Trotzdem ist sie nicht soweit, dass ich sie anderen in die 
Hände geben würde! Das ist nicht mein erstes Projekt! Ich kenne diese 
Erfahrung auch. Überlege bitte warum ich so eine Aussage treffe! Ich 
wollte vermeiden, dass ihr euch die mühe macht mir vieles überflüssiges 
mitzuteilen

Autor: Hans Mayer (hansilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk schreibt nicht besonders nett.
Aber im Kern liegt das Problem darin, daß Du zusehr im Projekt 
drinsteckst und nicht mehr frei bist Vorschläge anzunehmen.
Der Atmega kann definitiv mehr, siehe das Youtube-video.
Die zu geringe Leistung liegt an Deinem Code.
Klar willst Du den so wenig wie möglich ändern, ist ja Assembler.
Dann löt halt smd wenn du nicht besser programmieren willst.
Oder lass den Rechner mehr machen. Oder nutze externen Speicher mit 
vorberechneten Werten.
Zu den bugs:
schaltest Du während den ISR die Interrupts aus? Ich weiss nicht was der 
avr macht, wenn immer mehr isr gestartet werden.

Autor: AtmelFreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich weis zwar nicht was du genau mit der CNC -Steuerung anfangen willst,
>aber einen Vorschub von 1m/min wirst du z.B. bei Fräsmaschinen höchsten
>für den Eilgang brauchen, aber nie als Vorschub beim Fräsen.

Schwachsinn!!

Ich fahre meine Fräse mit 5m/Min in Kunststoffen bei 6000 U/Min 
Spindeldrehzahl. Buntmetalle oder Stahl sind mit diesem Vorschub 
natürlich nicht zu schaffen (Ausser Alu mit 1,5m/Min). Ich denke eh 
nicht das Andreas Stahl fräsen wird. Schrittmotoren eignen sich 
allenfalls für Gravier- und Leichtfräsmaschinen.
Grosse Fräsen haben keine Schrittmotoren und lesen ihre Genauigkeit an 
einem
geätzten Glasmasstab ab.
Aber auch hier zeigt sich das Wissen um bestimmte Dinge notwendig sind 
um beste Ergebnisse zu erzielen. Meine Motorsteuerung für 4-Achsen 
arbeitet mit
einem alten 8-Bitter bei Sage und Schreibe 12 MHz. Nicht das manche hier
Denken die Steuerung käme von mir, aber ich bin gerade dabei den alten 
Controller durch einen Mega32 zu ersetzen der das ganze locker schafft.
@Andreas
Ich glaube Du hast Dir viel Mühe und Arbeit gemacht und bist der Meinung
alles sauber durchdacht zu haben. Sei bitte nicht verbohrt und nimm die 
Ratschläge hier an und überdenke den ein oder anderen Punkt nochmal. Bei
meiner Maschine wird das Handpult, die Spindelsteuerung und die 
einzelnen
Ventile für Kühlmittel,Werkzeugwechsel und Sperrluft von jeweils einem
anderen Controller übernommen.
Wenn Du drannbleibst stellt sich auch der Erfolg ein. Auf jeden Fall 
kannst Du schonmal stolz auf Deine Arbeit sein.

Schönen Abend noch
Gruss Behrle

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AtmelFreak (Gast)  wrote:
> Ich fahre meine Fräse mit 5m/Min in Kunststoffen bei 6000 U/Min

Wie du schon sagtest: Schwachsinn!!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Klar willst Du den so wenig wie möglich ändern, ist ja Assembler.

Was hat das mit Assembler zu tun? Ein ordentlich geschriebenes 
Assemblerprogramm lässt sich problemlos ändern. Du darfst das nicht mit 
dem Anfängercode vergleichen, der hier öfters auftaucht.

>Ich weiss nicht was der avr macht, wenn immer mehr isr gestartet werden.

Mit dem (Nicht-) Wissen solltest du nicht solche Aussagen machen.

MfG Spess

Autor: AtmelFreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast (Gast) wrote:
>Wie du schon sagtest: Schwachsinn!!

Wenn Du von der Materie keine Ahnung hast einfach Klappe halten ok?
Erkundige dich mal nach den auf dem Markt erhältlichen Machinen, aber 
ich denke mal das packst Du nicht da eh alles was über Dein Wissen und 
Horizont hinausgeht "Schwachsinn" ist.

Autor: Hans Mayer (hansilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>Klar willst Du den so wenig wie möglich ändern, ist ja Assembler.
>
> Was hat das mit Assembler zu tun? Ein ordentlich geschriebenes
> Assemblerprogramm lässt sich problemlos ändern. Du darfst das nicht mit
> dem Anfängercode vergleichen, der hier öfters auftaucht.

Na dann soll er das Zeug doch mal schnell auf einen cortex m3 portieren 
und gut ist.

>
>>Ich weiss nicht was der avr macht, wenn immer mehr isr gestartet werden.
>
> Mit dem (Nicht-) Wissen solltest du nicht solche Aussagen machen.

Pff,
sollte nur ein Vorschlag sein, da ich weiß daß bei anderen Controllern 
eine Maximale Verschachtelungstiefe für ISR existiert, bei deren 
Überschreitung böse Fehlfunktionen passieren.

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AVR sperrt beim Aufruf einer ISR das Interrupt Flag. Wenn dies nicht 
in der Interrupt routine wieder gesetzt wird, ist es nicht möglich einen 
zweiten Interrupt aufzurufen. Jedoch werden Interrupts, die während der 
Ausführung einer ISR auftreten, gemerkt und im Anschluß abgearbeitet.

Gruß,
Tubie

Autor: AtmelFreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist sicherlich möglich das Ganze mit ein paar Änderungen rein mit 
Megas
zu vervollständigen. Der M3 wäre meineserachtens, nachdem ich mich 
eingehend
mit ihm beschäftig habe, gnadenlos unterfordert. Das ganze Konzept 
nochmal
überdenken, das eine oder andere wirklich auslagern dann passt das 
schon.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>sollte nur ein Vorschlag sein, da ich weiß daß bei anderen Controllern
>eine Maximale Verschachtelungstiefe für ISR existiert, bei deren
>Überschreitung böse Fehlfunktionen passieren.

Schön, das du das weißt. AVRs haben im Normalfall überhaupt keine 
Verschachtelung. Während der Ausführung einer ISR werden andere 
Interrupts nur registriert, aber nicht ausgeführt. Lässt sich aber 
beeinflussen, wenn man weiß was man macht.

MfG Spess

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Heyl schrieb:
>>Also von der Beschreibung würd ich auch sagen das eher ein Problem der
>>herangehensweise ist oder vieleicht ein Software bug?
>>So arg viel zu tun hat der AVR ja nicht.
>
> Denken kannst du das ja, wobei es meiner meinung nach völlig logisch
> ist, dass hier nicht mehr viel Rechenleistung übrig bleibt, wenn ich
> schon 115200 baud gewählt habe und alle drei timer mit teilweise nicht
> kurzen Rechnungen laufen habe!

Klar du kannst auch noch so viel Rechenpower reinstecken wenn dir z.B. 
der Stack überläuft!
Ich hatte mal einen Bug das ich den Stackpointer (Mega16 also der 
"kleine Bruder" des Mega32) in der falschen Reihenfolge beschrieben 
habe.

Ergebnis war das mein Programm (Digitaler Tacho+ein paar extra Aufgaben) 
SUPER funktioniert hat... zumindest solange bis 100 kmh überschritten 
wurden. An dem Punkt wurde nämlich ein unterprogramm Aufruf mehr gemacht 
bevor der Interupt kam und schon gabs nen Stacküberlauf in den 
Variablenbereich o.ä. zumindest sponn die Anzeige...

Auch sehr beliebt: SREG nicht sichern, ein Register nicht geretettet und 
so weiter.

So jezt mal zu logisch:
Du sagst immer der AVR hat "zu wenig Leistung" aber hast du das auch mal 
nachgeprüft? z.B. im Simmulator hast du nen wunderschönen Cyclecounter, 
laß deine Berechnungen da mal mit ein paar Beispielen durchlaufen und 
schau wieviel Zeit verbraucht wird, dann kannst du ohne Probleme sehen 
obs daran liegt das ne Berechnung zu lange dauert.

Aber du mutmaßt einfach das es daran liegt das der AVR überlastet ist, 
und stößt die Leute vor den Kopf die dir HINWEISE geben wo du mal 
nachsehen könntest. Ich mein du bist der einzige der den Code vorliegen 
hat daher kann man auch nur allgemeine nebulöse Tips geben.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn Du von der Materie keine Ahnung hast einfach Klappe halten ok?
> Erkundige dich mal nach den auf dem Markt erhältlichen Machinen, aber
> ich denke mal das packst Du nicht da eh alles was über Dein Wissen und
> Horizont hinausgeht "Schwachsinn" ist.

Lol, unser Rambo unter den Fräsern gibt seinen Auftritt....

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Du sagst immer der AVR hat "zu wenig Leistung" aber hast du das auch mal
>> nachgeprüft?

Guter Vorschlag.

In der EP1090 von isel ist der 8-Bit Controller 80535 verbaut und der 
hat weniger als ein 1 MIPS. Ein ATMEGA32 z. B. dürfte erheblich 
leistungsfähiger sein. Das Problem könnte an der Umsetzung/Effizienz der 
Algorithmen liegen.

Autor: Al Bundee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> AtmelFreak (Gast)  wrote:
>> Ich fahre meine Fräse mit 5m/Min in Kunststoffen bei 6000 U/Min

> Wie du schon sagtest: Schwachsinn!!

Lass uns doch mal an Deinem Wissen teilhaben: Warum Schwachsinn?
Für mich klingen die Werte durchaus plausibel, zumindest für PVC u.ä.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ein "Argument" durch mehr als eine Wiederholung eines Satzzeichens 
unterstrichen werden muß und der Satz weniger als 4 Worte beinhaltet 
sollte man einfach eins tun: Es ignorieren.
Das bringt doch nix und hat mit dem Problem auch nichts zu tun.

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So jezt mal zu logisch:
> Du sagst immer der AVR hat "zu wenig Leistung" aber hast du das auch mal
> nachgeprüft? z.B. im Simmulator hast du nen wunderschönen Cyclecounter,
> laß deine Berechnungen da mal mit ein paar Beispielen durchlaufen und
> schau wieviel Zeit verbraucht wird, dann kannst du ohne Probleme sehen
> obs daran liegt das ne Berechnung zu lange dauert.
>
> Aber du mutmaßt einfach das es daran liegt das der AVR überlastet ist,
> und stößt die Leute vor den Kopf die dir HINWEISE geben wo du mal
> nachsehen könntest. Ich mein du bist der einzige der den Code vorliegen
> hat daher kann man auch nur allgemeine nebulöse Tips geben.

Moment: da hast du was falsch verstanden. Zum einen habe ich das 
Problem, dass ich ab einer bestimmten Vorschubgeschwindigkeit Fehler bei 
der Berechnung bekomme! Je schneller ich werde umso mehr treten auf bzw. 
es geht gar nicht mehr... Egal ob ich meinen Timer der für die 
Schritterzeugung (also Vorschub) oder den Beschleunigungstimer kürzer 
einstelle.

Das zweite Problem, mit den mir zurzeit unberechenbaren (relativ 
seltenen) Fehlern sehe ich davon getrennt, da es selten auftritt, egal 
bei welchen Geschwindigkeiten.
Ich habe allgemein (relativ codeunabhängig) nach Ideen für die 
Fehlersuche (des 2. Fehlers) gefragt, ich denke das kann man machen, da 
ich ihn selbst bisher kaum eingrenzen konnte...

> und stößt die Leute vor den Kopf die dir HINWEISE geben wo du mal
> nachsehen könntest.

Dafür bedanke ich mich auch gerne noch mal (für die Hinweise)! Aber ich 
habe nur darauf hingewiesen, dass es nicht nötig ist jeden misst hier 
rein zu schreiben. Der ein oder andere könnte einen Sozialtherapeuten 
ganz gut gebrauchen. Das ist ja keine Gesprächskultur...

Ich wünsche viel Spaß beim weiterzanken.

Autor: Hans Mayer (hansilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tubie schrieb:
> Der AVR sperrt beim Aufruf einer ISR das Interrupt Flag. Wenn dies nicht
> in der Interrupt routine wieder gesetzt wird, ist es nicht möglich einen
> zweiten Interrupt aufzurufen. Jedoch werden Interrupts, die während der
> Ausführung einer ISR auftreten, gemerkt und im Anschluß abgearbeitet.
>
Interessant, da die Profis hier schon sind:
Wieviele Interrups werden da maximal gespeichert?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Mayer schrieb:
> Tubie schrieb:
>> Der AVR sperrt beim Aufruf einer ISR das Interrupt Flag. Wenn dies nicht
>> in der Interrupt routine wieder gesetzt wird, ist es nicht möglich einen
>> zweiten Interrupt aufzurufen. Jedoch werden Interrupts, die während der
>> Ausführung einer ISR auftreten, gemerkt und im Anschluß abgearbeitet.
>>
> Interessant, da die Profis hier schon sind:
> Wieviele Interrups werden da maximal gespeichert?

Von jedem Modul kann maximal ein Interrupt gleichzeitig gespeichert 
werden. Wenn also der Prozessor gerade mit einem UART Interrupt zugange 
ist, kann jedes andere Modul einen Interrupt schon mal anmelden.
Sollte der UART Interrupt so lange dauern, dass andere Module mehrfach 
Interrupts auslösen, dann gehen diese verloren.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Heyl schrieb:
> Dafür bedanke ich mich auch gerne noch mal (für die Hinweise)! Aber ich
> habe nur darauf hingewiesen, dass es nicht nötig ist jeden misst hier
> rein zu schreiben. Der ein oder andere könnte einen Sozialtherapeuten
> ganz gut gebrauchen. Das ist ja keine Gesprächskultur...

Ja, teilweise ist hier das übliche Getrolle los, aber das eigentliche 
Problem ist, dass du meinst, dass der Atmega32 nicht reicht, was wir 
aber nicht glauben können und den Fehler woanders vermuten. Aber das 
lässt du dir nicht sagen und bist eingeschnappt und meinst du hast das 
voll im Griff.

Deswegen ist das, was wir sagen kein Mist der dich ärgern soll, sondern 
Kritik.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas, ich glaube nicht, dass du einen anderen Controller brauchst, 
der wäre erst nötig wenn dir der Speicher ausgeht, aber vielleicht eine 
andere Herangehensweise.

Vom Prinzip her muss es der Software egal sein, ob der Controller 
schnell genug ist, denn kann er keine Befehle mehr vom PC annehmen, muss 
er eben die serielle Verbindung stoppen, und hat er keine Befehle mehr, 
muss halt der Vorschub stoppen. Zwischen unterschiedlichen schnellen 
Teilen (darunter zählt auch die softwaretechnische Umwandlung eines 
Kommandos in eine Schrittfolge) helfen Pufferspeicher.

Wenn ich ASSEMBLER höre, denke ich an nicht-optimale Algorithmen, und 
mir scheint, du hast schon gelernt, dass es für Kreise etc. bessere gibt 
als die, die du derzeit verwendest. Für Bögen berechnet man keinen 
Sinus, daher braucht man auch keinen CORDIC.

Gegen die Fehler hilft vermutlich nur sauberes Design. Es könnte helfen, 
die höheren Aufgaben in C zu programmieren. Das soll nicht heissen, dass 
in den schnellen Passagen (PWM?) der AVR nicht möglichst effektiv 
eingesetzt werden muß. So etwas, daß die CNC undefinierte Werte anfährt, 
weil Interrupts ignoriert wurden, kann bei einem sauberen Design nicht 
sein. Vor dem Kreis-zeichnen hat er das Kreis-Kommando empfangen und 
wenn er bis nach dem Kreis-fräsen nicht dazu kommt, ein neues Kommando 
entgegenzunehmen, macht das nicht, niemand würde es bemerken, er muß nur 
die Flußkontroller der seriellen richtig steuern.

Eigentlich ist bei Maschinensteuerungen alles ereignisgesteuert und 
könnte alles von Interrupts ausgelöst werden, aber dann wäre die 
Hauptschleife leer. Damit hat man die Hauptschleife zur Verfügung, um 
ohne Programmoverhead zeitliche Reihenfolgen organisieren zu könenn. 
Deine Hauptschleife könnte die Verwaltung der Pufferspeicher übernehmen, 
wenn Empfangspufferr leer schalte serielle empfangsbereit, wenn Kommando 
vorhanden wandle Kommando in Stepkommando sum, wenn neue Stepkommandos 
vorliegen und die alten abgelaufen sind setze neue Fräsrichtung, wenn 
Sendepuffer leer ist sende nächste vorliegende Positionsdaten, wenn 
Handrad bewegt wurde, update Position, so in der Art, und die Interrupts 
werden bei dir vor allem timerbasiert sein: Wenn Time(r) erreicht ist, 
ändere die Ausgangspins wie vorgesehen und setze nächste Zeit und lese 
Inkremantalgeber. Endschalter könnten per Interrupt gehen.

Ich seh natürlich ein, daß optimale Programme zu schreiben nicht 
unbedingt die Erfüllung des Hobbylebens sein muß, daher:

Einfacher, als den Controller zu wechseln, könnte es sein, gewisse 
Aufgaben (du hast Schrittmotoren?) an einen zweiten AVR zu übertragen. 
Du hast schon den Code, kennst die Architektur, und vom Preis macht es 
wohl auch weniger aus als ein Umstieg.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  MaWin (Gast)

>Gegen die Fehler hilft vermutlich nur sauberes Design.

Eben.

>Eigentlich ist bei Maschinensteuerungen alles ereignisgesteuert und
>könnte alles von Interrupts ausgelöst werden, aber dann wäre die
>Hauptschleife leer.

Naja, damit wäre ich vorsichtig! Ich würde dem OP besser empfehlen, eine 
saubere State Machine in der Hauptschleife aufzusetzen und nur WENIG im 
Interrupt zu machen, siehe Artikel. Wenig im Interrupt, wenig 
Wahrscheinlichkeit selbige zu verschlucken.

>Ich seh natürlich ein, daß optimale Programme zu schreiben nicht
>unbedingt die Erfüllung des Hobbylebens sein muß, daher:

Aber Sphaghetticode?

>Einfacher, als den Controller zu wechseln, könnte es sein, gewisse
>Aufgaben (du hast Schrittmotoren?) an einen zweiten AVR zu übertragen.

Noch viel besser ist es, eine saubere Stuktur und Konzept anzuwenden.

Wenn der OP mutig genug ist postet er mal seinen Code als ANHANG!
Allerding sollte er sich vorher fragen, wie kritikfähig er ist . . .

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Arne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Noch was anderes: habt ihr Tipps wie eine Fehlersuche am effektivsten
> ist, wenn ein Fehler nur ca. alle Fünftausend NC-Sätze auftaucht und
> dann selten wiederholbar.

Und wenn Du statt des MTmega32 einen ATmega644P (IMHO pinkompatibel)
nimmst? Der hat einen zweite UART, da könntest Du Dir die berechneten 
Ergebnisse an ein Terminalprg auf dem PC schicken lassen und 
vergleichen.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@MaWin

>>Für Bögen berechnet man keinen Sinus, daher braucht man auch keinen CORDIC.

Gib bitte mal ein Rechenbeispiel für einen Kreisbogen von 31,3° bis 
71,9° gegen Uhrzeigersinn.
------
Bei meiner Fräsensteuerung dauert die Berechnung eines float Sinuswertes 
ca. 90µs.

MfG
Pieter

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pieter schrieb:
> moin moin,
>
> @MaWin
>
>>>Für Bögen berechnet man keinen Sinus, daher braucht man auch keinen CORDIC.
>
> Gib bitte mal ein Rechenbeispiel für einen Kreisbogen von 31,3° bis
> 71,9° gegen Uhrzeigersinn.
> ------
> Bei meiner Fräsensteuerung dauert die Berechnung eines float Sinuswertes
> ca. 90µs.

Inwiefern ein Rechenbeispiel? Der Bresenham Algorithmus macht das ganz 
ohne Sinus/Cosinus.

Mit Lookuptable braucht die "Berechnung" eines Sinuswertes 
wahrscheinlich nur 5% der Zeit.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wuerd mal davon ausgehen, dass die Fraesmaschine, dh der mechanische 
Teil, sicher langsamer ist als die Berechnungen dazu. Ein float in 90us, 
das schaut doch gut. aus. Man sollte der Fraesmaschine nur Werte 
mitteilen, die Sinn machen. Dh wenn der minimale Schritt 10um ist, macht 
es keinen Sinn der Fraese Werte mit 0.03um Incrementen mitzuteilen.

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Pieter schrieb:
>> moin moin,
>>
>> @MaWin
>>
>>>>Für Bögen berechnet man keinen Sinus, daher braucht man auch keinen CORDIC.
>>
>> Gib bitte mal ein Rechenbeispiel für einen Kreisbogen von 31,3° bis
>> 71,9° gegen Uhrzeigersinn.
>> ------
>> Bei meiner Fräsensteuerung dauert die Berechnung eines float Sinuswertes
>> ca. 90µs.
>
> Inwiefern ein Rechenbeispiel? Der Bresenham Algorithmus macht das ganz
> ohne Sinus/Cosinus.

So einfach ist das dann auch wieder nicht.
Selbst dann benötigst du immer noch die Koordinaten des Anfangs und 
Endpunkts, ausgehend von Mittelpunkt und Radius.

Und ein Bogenbresenham, der nicht auf einer der Koordinatenachsen 
startet, ist alles andere als trivial.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@Simon K.

zeige bitte wie der Bresenham für Kreise Werte für einen beliebigen 
Kreisbogen liefert. Dafür möchte ich eine Rechenvorschrift und kein 
gelaber was wie zu tun sein könnte.

>>Mit Lookuptable braucht die "Berechnung" eines Sinuswertes
wahrscheinlich nur 5% der Zeit.

Glaskugelkucken. wie groß soll den die Tabelle werden, Schrittweite 
0,1°...

Den Bresenham für Keis habe ich durch (arbeitet mit Bogen sowie rechts 
und links rum) und wieder weg. Mit Sin/Cos ist das Programm wesendlich 
einfacher und kleiner.

MfG
Pieter

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gib bitte mal ein Rechenbeispiel für einen Kreisbogen von 31,3° bis
> 71,9° gegen Uhrzeigersinn.

Ohne Winkelfunktionen spezifiziert man Bögen in Bogenmass, ist doch wohl 
logisch.

Bei einer Fräse spezifiziert man sie aber als Fortsetzung einer Linie, 
und nennt wie weit der Mittelpunkt von der Linie entfernt ist.

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

Bewertung
0 lesenswert
nicht lesenswert
Pieter schrieb:

> Den Bresenham für Keis habe ich durch (arbeitet mit Bogen sowie rechts
> und links rum) und wieder weg. Mit Sin/Cos ist das Programm wesendlich
> einfacher und kleiner.

(Wir reden von einem Vollkreis, richtig?)

Das wiederrum glaub ich dir nicht.
Nicht wenn du die Implementierungen für sin/cos mit dazuzählst.
(Was aber u.U keine grosse Rolle spielt, da du die für Bögen sowieso 
brauchst)

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

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
>> Gib bitte mal ein Rechenbeispiel für einen Kreisbogen von 31,3° bis
>> 71,9° gegen Uhrzeigersinn.
>
> Ohne Winkelfunktionen spezifiziert man Bögen in Bogenmass, ist doch wohl
> logisch.

Aha.
Dann möchte ich jetzt auch mal einen Bresenham in Aktion sehen, der 
einen Bogen (Mittelpunkt im Ursprung, Radius = 258) beginnend bei 0.2rad 
bis 1.78 rad generiert.

Nur weil du die Dinge plötzlich Radianten nennst und nicht Grad, ändert 
sich nichts am Problem.

> Bei einer Fräse spezifiziert man sie aber als Fortsetzung einer Linie,
> und nennt wie weit der Mittelpunkt von der Linie entfernt ist.

OK. Dann zeig doch bitte mal deinen Bresenham in Aktion.

Gegeben eine Linien

    0/0     ->   20/100

und ein Kreismittelpunkt

    80/140

gesucht sind die Bresenham-Punkte am Kreisbogen, wenn der Bogen einen 
Radius von 85 Einheiten hat und der Bogen bei einem Winkel von 38° enden 
soll (bin jetzt zu faul eine Linie zu konstruieren, die genau an diesem 
Punkt beginnt)

Es geht nicht um den Bresenham an sich. Es geht darum, wie du die 
Anfangsparameter des Bresenham ohne Trigonometrie berechnest. Das möchte 
ich sehen. Nicht alle Bögen die einem so unterkommen sind Schmiegekreise 
zwischen exakt horizontal bzw. vertikalen Linien. Das werden schon sehr 
viele sein, zugegeben. Aber von einer allgmeinen Fräse erwarte ich, dass 
sie jeden beliebigen Bogen fräsen kann und nicht nur solche die bei 0, 
45, 90, ... ° beginnen oder enden.

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt ist hier mal wieder die Standartdiskussion zum 
Kreisalgorithmus ausgebrochen...
Meiner Erfahrung macht eine Kreisberechnunug mit Hilfe von 
Winkelfunktionen im Mic auch bzw. gerade mit Tabellen keinen Sinn, wenn 
es um die erforderlichen Genauigkeiten geht!
Ich habe es folgendermaßen gelöst: Ich teste immer ob ich nur in einer 
oder in zwei ebenen fahren muss in dem ich schaue für welchen 
Folgeschritt der Fehler kleiner ist (also einfach Pythagoras...). Das 
rechenaufwändige sind hier die erwähnten Quadrate der Strecken vom 
Mittelpunkt zu den zwei potenziellen anfahrbaren Punkten. Genau 
beschrieben ist das hier:

http://algorithm.name/rasteralgorithmus_6.html

Bei diesem Algorithmus ist es auch absolut kein Problem irgendwo in 
mitten eines Kreisachtels zu beginnen... Ich habe bisher keine Lösung 
gefunden die schneller ist und diesen Komfort bietet. Ich lasse mich 
gerne ein besseren belehren. Ich bin seit Jahren auf der Suche nach noch 
schnelleren Lösungsansätzen...

Grüße (ach übrigens ich bin keineswegs eingeschnappt),

Andreas

Autor: Gerd Vg (gerald)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Und genau DORT brauchst due KEINE hohe Auflösung, wahrscheinlich nicht
> mal Kreise. Nur einfache Linien. Ein Schiff auf dem Ozean navigiert auch
> nicht mit cm-genauer Präzision (auch wenn das heute im GPS-Zeitalter
> problemlos geht). Sondern eher im Bereich von Meilen. Erst in Küstennähe
> muss man genauer navigieren. Aber natürlich auch auf hoher See den
> Ausguck besetzten, man will ja keinen Blauwal rammen ;-)
>
Na dann rück mal den Code dafür raus oder eine Beschreibung der Methode 
für diese hohe Genauigkeit im cm-Breich.
Bin ich gespannt wie man ein Schiff so supergenau steuern kann ...denn 
genau da liegt mein Problem!!

Bitte keine Sprüche sondern nachvollziehbare Methoden, die zum Erfolg 
führen.
Sprüche wie, die Amis können das mit ihren Raketen, kenne ich bereits.

Bin gespannt auf Deine aussagekräftige Antwort.

Gruss

Gerd

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@Andreas,
so in der Art war meine Implementation vom KreisBresenham.
In der Realität gab es dann immer wieder Probleme mit der exakten 
Position.

Da ich in meiner Fräsensteuerung auch gleich noch die 
Fräsradienkorrektur mitrechne, bin ich zu alles in Float rechnen 
übergegangen. Allerdings verwende ich mehrere MC (zur zeit sind es 7) 
für die Teilaufgaben. (je Motor, Handrad, HauptMC und FPU).
Als Rampe für Start/Stop nehme ich sin^2, da linear zugroße 
Beschleunigungssprünge macht.

MfG
Pieter

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann möchte ich jetzt auch mal einen Bresenham in Aktion sehen,

Schreib dir einen.

Ein üblicher Weg, um inmitten eines Kreises zu beginnen und dabei die 
richtigen Startwerte für den Bresenham zu bekommen, ist binäre 
Einschachtelung des Startpunktes. Ganz ohne Sinus.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

>>Schreib dir einen.

soll ich das als heiße Luft deuten?

Wie schon gesagt, ich rechne Kreisbogen an Gerade mit 
Fräsradienkorrektur.
Und nun lasse den Bogen mal von -36°(324°) nach +42° gehen und dann eine 
Gerade mit Anstieg -12°.

MfG
Pieter

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

apropos Bresenham Startwerte berechnen:
http://algorithm.name/rasteralgorithmus_7.html
x und y sind aus dem Abstand Mittelpunkt zu Startpunkt gegeben. Der 
Radius eigentlich auch über r^2= x^2+y^2 kann aber leicht daneben 
liegen.
D kann man dann mit diesen Werten berechnen.
Nun ändert sich D linear in x/y wenn x,y sich um +-1 ändert.(x^2 
->(x+1)^2= x^2+2*x+1=(x soll ja auch x+1 werden) =  x^2(schon 
gerechnet)+ 2*(x+1)-1.
Das heißt, man braucht nur die Änderungen von x,y und D bestimmen und ab 
und an (alle 45 Grad Grenzen eine andere Formel/Vorzeichen benutzen)
Jetzt ist die Frage, wie intelligent die Steuerung sein soll. Soll die 
Steuerung die ganze Rechnerei mit Fräsradienkorrektur und Bestimmung der 
Startpunkte oder gar Tangenten an zwei Kreisen etc. oder bereitet ein PC 
die Daten soweit auf, das eine Kollisionsprüfung, Wegoptimierung etc pp 
stattfindet , sodass nur Linien/Kreisbögen gesendet werden.
Muss der Kontroller auch öfter als alle 0.5 Sekunden mitteilen, wo der 
Fräser gerade steht?.

Gruß Horst

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, wenn ich die Diskussion über den Bresenham unterbreche, aber ich 
bin immer noch der Meinung, das eine 16-Bit Look Up Tabelle vollkommen 
ausreichend ist. Sie ist sehr schnell, das ist ja gefordert. Sie 
benötigt lediglich 128kB an Speicher, der natürlich extern zur verfügung 
stehen muß - Andreas möchte je keine SMD µC's verwenden. Ein kleinen 8 
Pin SMD Chip sollte eigentlich jeder löten können...

http://www.atmel.com/dyn/resources/prod_documents/...

Oder halt alternativ über Latches die EProms alter PC Mainboards 
benutzen. Geht beides super. Der Flash hat halt den riesen Vorteil, das 
man keinen EProm Brenner benötigt und man die Daten ggf. per RS-232 vom 
Controller selbst Flashen lassen kann.

Beispiel zur Look Up Tabelle:
Sinus Kurve 0-90° wird gespeichert in Adresse $0000 - $FFFF

ergibt:
90° / 65535 Adressen = 0,00137° Schrittwinkel

Also ich frage mich jetzt wirklich warum das ganze mit 24 Bit laufen 
muß. Selbst bei riesengroßen Radien (1000mm) ergibt sich eine Rasterung 
von nur <0,03mm. Diese Distanz könnte dann bei bedarf durch eine Gerade 
interpoliert werden. Die Präzision der Mechanischen Seite natürlich 
vorausgesetzt.

Gruß,
Tubie

Autor: Steffen I. (echo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

@ Gerd Vg: Differential GPS und Aktive Funkbaken ist hier das stichwort. 
Damit erreicht man wesentlich höhere Auflösungen als mit simpler 
Navi-GPS.

Kennt sich jemand eventuell mit den Trinamic-ICs 
(Mikroschritt-Schrittmotoren-Controller/Treiber) aus? Wollte mich mal in 
die reinarbeiten und mich würde interessieren ob jemand schon was mit 
denen realisiert hat.

MfG Echo

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, erstmal Respekt, wenn Du schon so weit bist.

2. Es gibt den 644(P) auch im 40-Pol-DIL-Gehäuse, und er läuft auch bei 
24 MHz (ist zwar dann schon außer der Spec, aber bei mir hatte das 
bisher noch jeder geschafft).
geeignete Frequenzen für 115200 sind alle Vielfachen von 1843200:
 1843200,  3686400,  5529600,  7372800,  9216000,
11059200, 12902400, 14745600, 16588800, 18432000, 20275200,
22118400, 23961600, 25804800, 27648000, 29491200, 31334400


3. Zur Fehlersuche: du musst Fallen einbauen, in die er kommt, wenn er 
einen Fehler macht. Dann Debuggen über die zweite Serielle (Abfragen von 
Variablen, Prüfen des Stacks).

JTAG-Debugger haben viele Möglichkeiten.

Das mit der benötigten Rechenleistung ist nur eine Frage des Konzeptes. 
Viele Wege führen nach Rom, aber es gibt lange und kurze, langsame und 
schnelle.


@Falk: Du kannst auch etwas netter sein.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@Echo
ich arbeite u.a. mit TB6560, da 8*200Steps und 16mm Spindelsteigung.


@Tubie
ich arbeite mit Rasterung 10µm...

MfG
Pieter

Autor: Gerd Vg (gerald)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen I. schrieb:
>
> @ Gerd Vg: Differential GPS und Aktive Funkbaken ist hier das stichwort.
> Damit erreicht man wesentlich höhere Auflösungen als mit simpler
> Navi-GPS.
>
Davon war aber nicht Rede, er sprach nur von GPS auf dem Ozean.
Funkbarken und Ähnliches war nicht sein Thema.
Problemlos geht das also auch nicht, sondern mit erhöhtem Einsatz an 
Technik.
Ausreden sind immer willkommen.

Mein Vater sagte immer zu mir wenn ich mich Rausreden wollte:
Warum erschlug der Teufel seinen Grossmutter?
Weil sie keine Ausrede wusste!!!

Falk mag ja nicht mal antworten....kann ja nur ständig nerven mit seinen 
Bilformaten!

Gruss

Gerd

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

@Andreas,

meine Lösung ist etwas anders, eventuell findest Du was brauchbares.


-  es werden permanent die Achsenwerte an Windows übermittelt

in welchem Format wird gesendet?

Bei mir lauscht die Handsteuerung (gleichzeigig Anzeige) am Bus, wird 
ein Stepbefehl gesendet aktualisiert die Anzeige selbsständig, der 
MainMC bekommt davon nichts mit.

MfG
Pieter

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, da gab es ja doch noch den ein oder anderen Netten Tipp, danke!

Ich dachte, ihr wollt sicher gern mal ein kleines Video sehen, so quasi 
als Belohnung, dafür das sich der ein oder andere so mit voller Energie 
hier beteiligt hat ;-)

Youtube-Video "HolzCNC fräst Multiplexwand"

Und falls es euch gefallen hat, dann dürft ihr auch dazu wieder was 
schreiben, und euch kloppen und eure Schiffe per GPS cm genau über die 
Ozeane steuern ;-)

Viel Spans damit!

Grüße,
Andreas

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist Ja echt Genial!

Ist das die maximale Vorschubgeschwindigkeit, die in dem Video gefahren 
wird? Klär uns doch bitte mal auf, was du nun letztendlich an Programm 
Optimierung getrieben hast. Sind die Fehler mittlerweile beseitigt?

Gruß,
Tubie

Autor: Andreas Heyl (entenkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tubie schrieb:
> Ist Ja echt Genial!
>
> Ist das die maximale Vorschubgeschwindigkeit, die in dem Video gefahren
> wird? Klär uns doch bitte mal auf, was du nun letztendlich an Programm
> Optimierung getrieben hast. Sind die Fehler mittlerweile beseitigt?
>
> Gruß,
> Tubie

Hallo!
Während des Eilgangs ist derzeit die maximale Vorschubgeschwindigkeit zu 
sehen...
Optimiert habe ich nicht viel. Ich konnte die Frequenz des Timers für 
die Beschleunigung noch reduzieren, ohne das sich daraus eine 
Veränderung ergeben hat, da ich hier zuvor in kleineren Schritten 
beschleunigt habe als nötig wäre. Dadurch habe ich natürlich weniger 
IRQ´s und kann auch bei etwas höheren Schrittfrequenzen alles was auf 
der seriellen Schnittstelle passiert mitbekommen. Also am 
Kreisalgorithmus wurde nichts optimiert. Dafür hatte ich noch keine 
durchschlagenden Ideen...
Der Code war also prinzipiell richtig nur habe ich dem Controller 
dadurch, dass ich etwas ineffektiv gearbeitet habe mehr Leistung 
abverlangt als nötig wäre. So kann ich jetzt meine angegebenen 
Geschwindigkeiten sicher fahren. Wobei ich versuchen werde den Code 
weiter zu optimieren um höhere Geschwindigkeiten zu erreichen.

Gruß,
Andreas

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.