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
Wie machst du die Kreise? Bresenham? Ralf
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
ganz nebenbei mal die grenzen des AVR sind hier zu sehen... http://www.youtube.com/watch?v=oHKiBjiAg8o&eurl=http%3A%2F%2Fbelogic%2Ecom%2Fuzebox%2Findex%2Ehtm&feature=player_embedded Gruß, Tubie
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
AtmelFreak (Gast) wrote:
> Ich fahre meine Fräse mit 5m/Min in Kunststoffen bei 6000 U/Min
Wie du schon sagtest: Schwachsinn!!
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
Ach ja, für unsere Schnellfräser http://www.youtube.com/watch?v=QsmiIeAkE-o&feature=channel_page Cool!
> 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.
moin moin, @Echo ich arbeite u.a. mit TB6560, da 8*200Steps und 16mm Spindelsteigung. @Tubie ich arbeite mit Rasterung 10µm... MfG Pieter
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.