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
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.
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
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.
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.
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
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 ;-)
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
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
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...
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.
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
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...
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.
@ 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
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.
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
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
@ 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
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
@ 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
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
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
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.
>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
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
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.
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.
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
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.
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
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.
> 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....
>> 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.
> 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.ä.
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.
> 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.
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?
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.
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.
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.
@ 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
> 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.
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
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.
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.
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.
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
> 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.
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)
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.
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
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
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
> 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.
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
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
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/doc5167.pdf
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
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
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.
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
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
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 ;-)
http://www.youtube.com/watch?v=PsB_bbH6Krg
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
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
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
