Servus zusammen, ich bin gerade daran einen Schrittmotor-Controller zu basteln. Ziel ist es mit dem Schrittmotor einen Schlitten von A nach B und zurück zu bewegen. Nun, gibt ja viel zu lesen, allerdings finde ich nicht alles, was mich quält. 1. Ist es sinnvoll einen AVR mit einem 16-bit Timer/Counter zu suchen um dann mit 16-bit die Schrittverzögerungen "abzuwarten" (eigentlich nur 12 Bit, wenn man bei unter 10% Geschwindigkteits-Schrittweite landen möchte)? Oder gibts da klügere Ansätze? 2. Eine Beschleunigungsrampe: im Prinzip würde mir eine Tabelle zusagen, doch so viel Speicher findet man ja quasi nur in den größeren AVRs. Oder riechen tatsächlich 64 Schritte zur Höchstdrehzahl (werden wohl um die 100kHz werden) aus? (64 Schritte ergeben sich aus 128bit EEPROM gefüllt mit einer 16-bit-Timertabelle.) Oder doch besser realtime Berechnen. Welche Formeln sind da am sinnvollsten für bis zu 100kHz mit max. 16MHz Quarz. Taugt die ATMEL Application Note AVR446 dafür noch? Ich kann das immer so schlecht einschätzen ob für ein paar Zeilen C-Code 160Takte ausreichen (inkl. Interrupt einleiten etc.) Vielen Dank schonmal lg Peter PS: Falls mein Vorhaben nicht genau genug rüber kam nochmal ausführlich: Hardware: ein display, eine Platine, zwei greifer, ein Schrittmotortreiber und ein Schrittmotor. Der schrittmotor soll einen Greifer auf den anderen zu oder weg bewegen während die Greifer wechselseitig zupacken. Im Ganzen soll letztlich eine stange immer wieder nachgeschoben werden. Software: soll nicht mehr erledigen als eine zuvor am display eingestellte anzahl an schritten vorwärtsfahren, umgreifen, zurückfahren und nochmal umgreifen. Erledigt hätte ich das jetzt mit einem 16bit-CTC-Timer, der in seiner Interruptroutine die Schritte auslöst und gleich die nächste Timerdelay berechnet/aus einer Tabelle ausliest. Das Display und ein paar Taster werden in der main-loop bedient. Wobei die Tasten während einem angefangenen "Nachgreifprozesses" mittels eines Falgs gesperrt werden.
Peter schrieb: > 100kHz Welchen Treiber hast Du denn im Einsatz? Welcher Motor? Wenn Du 10Khz hast und der Motor fährt auch diese Geschwindigkeit, kannst Du dich schon freuen. Für die Greiferanwendung werden es wohl max. 2 Umdr./sec werden eher weniger. Das geht locker mit Software Impulserzeugung. ansonsten lese mal was über Bresenham. Axel
Weitere Fragen: wieviele Schritte macht Dein Motor pro Umdrehung? Daraus folgend: Wieviele Schritte musst du machen von einer machanischen Endlage bis zur entgengesetzten? Dann kannst Du überlegen, wie schnell diese Schritte gemacht werden sollen. Axel
ixh stelle gerade fest, das ganze blabla um die 12-bit ist käse. Ich brauche lediglich einen mindestwert für den Timer. ganze bits gehen nicht für präzission drauf... @ Düsendieb. Das läuchtet mir jetzt nicht ein. Ich weiß im moment nicht wieviele schritte es letztendlich sein werden. Aber das ist ja auch,, was in der Software als variable bleiben soll. Allerdings weiß ich, dass die die maximaldrehzahl bei 400kHz erreicht wird. Unter Last sind 100kHz drin und unser Ziel. Aber kannst/willst du mal deinen Gedankengang noch etwas azsführen?
Peter schrieb: > 400kHz glaube Du meinst 400Hz. So ein Schrittmotor hat irgendwas zwischen 50 bis 200 Schritte pro Umdrehung. Last oder keine ist für einen Schrittmotor egal, da diese mit einem eingeprägten Strom gefahren werden. Das heißt, der Treiber schiebt immer den gleichen Strom in die Motorspulen. Hier aufpassen: es gibt Treiber, die haben keine Stromregelung, da wird das Motormoment mit zunehmender Drehzahl schnell kleiner. Sich zu überlegen, in welchem Schrittbereich die Maschine nachher bewegen wird macht schon Sinn, da evtl die Struktur des Programms anders werden kann. Axel
Peter schrieb: > Allerdings weiß ich, dass die die maximaldrehzahl bei 400kHz erreicht > wird. Unter Last sind 100kHz drin und unser Ziel. Das wären bei angenommenen 100 Schritten pro Umdrehung eine Drehzahl von max. 4000 U/s, also 240000 U/s. Zahnarztbohrer kommen glaube ich so hoch, aber bestimmt kein Schrittmotor um irgendwas auf einer Schubstange zu bewegen!
Hab nochmal mit meinem Mechaniker gequatscht, der für die gesammte Mechanik zuständig ist und auch bereits den Motor + Treiber vorliegen hat. Es handelt sich also um einen DC-Motor mit Decoder und kleiner Treiberplatine, die für jeden Eingangsimpuls einen Decoder-schritt weiter fährt. Mit Getriebe etc. wird der Motortrieber dann mit 1000 Schritten pro mm angepulst und es soll gesammt eine Strecke von 10mm bis 400mm gefahren werden. So siehts also aus. Welche Maximalbeschleunigung möglich ist konnte er mir jetzt am Telefon nicht sagen, aber innerhalb der ersten 2 mm wird sie sicher erricht. Maximalgeschwindigkeit ist dann bei 400kHz erreicht, wobei unter Last die 100kHz unser ereichbares Ziel sind. Ich dachte eigentlich, es sei Möglich, erstmal ein flexibles Programmgerüst aufzustellen, in das dann nurnoch die Beschleunigung und Endgeschwindigkeit eingetragen wird (ggf. vorberechnet in tabellarischer Form).
Peter schrieb: > Mit Getriebe etc. wird der Motortrieber dann mit 1000 Schritten pro mm > angepulst und es soll gesammt eine Strecke von 10mm bis 400mm gefahren werden. > Maximalgeschwindigkeit ist dann bei 400kHz erreicht, wobei unter Last > die 100kHz unser ereichbares Ziel sind. Schätze mal Du meinst: bei 1000 Schritten pro mm möchtest Du 100mm/sec erreichen und der Mechaniker meint, dass 100mm/sec in 2 Sekunden erreichbar sind. Richtig verstanden? Kommt mir sehr schnell vor. Axel
Düsendieb schrieb: > bei 1000 Schritten pro mm möchtest Du 100mm/sec > erreichen ... Ergibt dann 100kHz. Läuft also auf gleiche raus. Richtig. > ... 100mm/sec in 2 Sekunden erreichbar sind. Da es sich hierbei um einen ungenauen aber großzügig bemessenen Wert handelt, denke ich kann man getrost diese Umformulierung vornehmen. > Richtig verstanden? Sieht so aus. > Kommt mir sehr schnell vor. Ja schnell ist das schon. Das zeug geht ordenltich ab, brauch dabei aber auch relativ viel Strom. Das ist aber ein anderes Theman. lg Peter
ich kann mir absolut nicht vorstellen, dass es einen solchen Treiberbaustein gibt, der diese Ansteuerung mit 100kHz braucht. Ich bin fest davon überzeugt, dass da irgendwo ein paar Zehnerpotenzen falsch sind. Wenn der Weg von 400mm auf 400.000 Schritte aufgelöst werden soll sind das 1 µm Auflösung. Axel
wir groß ist die Getriebeübersetzung? Wie groß ist die Motordrehzahl bei 100mm/sec am Schlitten?
Peter schrieb: > Es handelt sich also um einen DC-Motor mit Decoder und kleiner > > Treiberplatine, die für jeden Eingangsimpuls einen Decoder-schritt > > weiter fährt. Dann handelt es sich nicht um eine Schrittmotorsteuerung sondern um eine PWM-Steuerung eines DC-Motors. Das ist ein ganz anderes Konzept. B.
Eine geeignete und bessere Lösung findet man erst, wenn alle! Voraussetzungen korrekt angegeben wurden. B.
(ich nix ahnung) aber: hier steht z.b. Schrittmotor Endstufe 1Mhz scheint also "übliche" zu sein "Schrittmotor" und "hohe kHz" in eine Satz zu schreiben... http://www.indel.ch/schrittmotor/schrittmotor.php
da muss ich "Boh Ey" sagen, dass es so schnell geht wusste ich auch noch nicht.
Würde fast sagen, dass dafür 16Mhz Taktfrequenz zu wenig sind. Da sind nur 80 Takte für 1 und 80 Takt 0 aus übrig. Du könntest bis zum halben Weg bei jedem Durchlauf der Timerrouting den Geschwindigkeitssollwert um 1 erhöhen und ab dem halben Weg wieder um 1 verringern. Das ergibt dann zwar keine lineare Rampe, aber ist nicht so aufwendig zu berechnen. Axel
Es steht bisher offen, wieviele Schritte pro Umdrehung der Controller braucht. Diese können nämlich Mikroschritte sein, beliebiger Umrechnung in Vollschritte / Umdrehungen. Und es gibt Controller, die die Schritte "speichern" können, d.h. Du kannst mit bis zu x kHz / MHz die Anzahl der Schritte reinpulsen (sozusagen die SollPosition vorgeben), und der Controller macht dann selbst die Rampen. AlphaStep ASD-Serie ist z.B. ein solcher. Und unser Fall hier ist gar kein Schrittmotor, sondern ein DC-Servo mit einer Schritt-Ansteuerung. Wie Bernadette schon schrieb: mit solch schwammigen Infos bekommst Du keine Hilfe!
Düsendieb schrieb: > ich kann mir absolut nicht vorstellen, dass es einen solchen > Treiberbaustein gibt, der diese Ansteuerung mit 100kHz braucht. Treiberbaustein weiß ich nicht. Das ist eine fertige Treiberplatiene. Nicht von mir aber tutos complettos fertig und getestet bis 400kHz. > Wenn der Weg von 400mm auf 400.000 Schritte aufgelöst werden soll sind > das 1 µm Auflösung. Korrekt. Sowas gibts im bereich der CNC-Fräsungen. zwar fräsen die auch meißt nur auf hundertstel mm, aber für weichere Bewegungen sind tausendstel Auflösungen durchaus üblich. Bernadette schrieb: > Dann handelt es sich nicht um eine Schrittmotorsteuerung sondern um eine > PWM-Steuerung eines DC-Motors. Was die Motor-Treiber-Platine mit meinen Takten macht, ist mir doch egal?! DC-, AC-, Schritt-, Servomotor. Mir doch völlig egal, solange ich gewisse vorgegebene Grenzen einhalte. eProfi schrieb: > Wie Bernadette schon schrieb: mit solch schwammigen Infos bekommst Du > keine Hilfe! Ja sorry, ich war selbst falsch informiert. Kommt leider auch mal vor. Aber jetzt bitte erkläre mir mal einer für was die Mechanik dahinter interessant ist. Wenn mir gegeben ist 100kHz Maximalfrequenz, variable Beschleunigung (um die 50kHz/s) sowie variable Schrittzahl (10.000-400.000), dann müsste man sich mit den Angaben doch ein grobes Konzept der Programmierung ausdenken können. Mein Ansatz steht ja im ersten Post letzter Absatz. Mich würde nur interessieren, ob ich da völlig auf dem Holzweg bin, oder obs bessere Vorschläge gibt?! Ist jetz alles nicht irgendwie beleidigend gemeint, ich kanns nur nicht besser formulieren.
Also ich mache zur Zeit etwas ähnliches, mit schrittmotoransteuerung per 16-bit Timer. CTC-Mode, Takt über COM1A ausgegeben(also Hardware), Frequenz kann man ja leicht über OCR1A einstellen. In der ISR zähle ich dann die Anzahl der Schritte runter, die gemacht werden sollen. Bei 0 halte ich dann den Timer an. Das scheint bis jetzt auch soweit ganz gut zu funktionieren, ist aber noch nicht ganz fertig getestet. Ob dein gewünschter Frequenzbereich damit ausreichend abgedeckt wird, kannst du dir ja mit der Formel im Datenblatt selber ausrechnen. Zu dem Link oben mit 1MHz: Das ist nur die Endstufe... Die Endstufe die ich verwende kann auch 200KHz, aber ich hab noch kein Motor gehabt der auch nur im Ansatz in dem Bereich lief. Aber ist wahrscheinlich wie bei allem, ne Frage des Geldes ;)
Max schrieb: > Die Endstufe die ich verwende kann auch > 200KHz, aber ich hab noch kein Motor gehabt der auch nur im Ansatz in > dem Bereich lief. Aber ist wahrscheinlich wie bei allem, ne Frage des > Geldes ;) also bei uns sind 4 Achsen beriets mit diesen Motor-Treiber-Kombination im Betrieb... mit bis zu 100kHz. Allerdings über den PC gesteuert. Das ganze stellt eine 4-Achs CNC-Maschine dar. Nun soll halt noch ein Nachschub realisiert werden, die allerdings von der PC-Software so nicht vorgesehen ist. Deshalb muss mit einem kleinen µC nachgeholfen werden. Aber danke Max. Dein Beitrag hat mich auf die Idee gebracht. Ich lass das ding im CTC-Modus eine "Hardware-PWM" generieren und berechne in konstanten Zeitabständen neue Geschwindigkeiten, die ich in OCR1A scheibe. Gebremst wird minimal verfrüht wobei die letzten paar Schritte dann mit minimaltempo als eine Art Puffer gegen zu ruckartiges abbremsen auf null (wegen zu hohen Geschwindigkeiten) ablaufen. Müsste ich mir nurnoch den Bremspunkt ausrechen, aber der ist halt kurz vor der Hälfte der Schritte oder wird anhand der Beschleunigungsrampe (Schritte der gesammten Rampe) abgezählt. Oder ist das eher dumm so zu lösen?
Sowie ich das Problem verstehe, möchtest Du Schrittimpulse erzeugen, die auf eine wie auch immer geartete vorhandene 'Ausführungseinheit' gehen. Ob die Bewegung durch Stepper oder DC-Motor ausgeführt wird, ist nicht von Bedeutung. Soweit - so gut. Aber Impulsfolgen mit variabler Rampe bis 100kHz zu erzeugen, ist für einen AVR eine knifflige Aufgabe, die er unter Umständen nicht schaffen kann. Die Impulserzeugung muß in Verbindung mit einem Interrupt passieren, der alle 10µs bedient werden muß. Sofern noch eine andere Interruptquelle dazukommt, wird das Timing vermutlich nicht einzuhalten sein. Ein anderer Prozessor mit mehr Reserven dürfte die bessere Wahl sein, es sei denn, Du hast viel Zeit für die Programmierung und es wird eine kostengünstige hohe Stückzahl gewünscht. Beides trifft wohl nicht zu, wenn ich Dich richtig verstanden habe: >"ich bin gerade daran einen Schrittmotor-Controller zu basteln."
Hmm... warum ist ein 10µs Interrupt nötig? folgendes Vorgehen: (mal mit einem Mega48/88/168 angedacht) Timer/Counter1 habe jetzt 16-bit und laufe im CTC-Modus. Bei jedem Comparematch wird der Pin OC1A getoggelt. OC0A ist mit T0 (der externen clock-source vom 8-bitigen Timer/Counter0 verbunden, sensitiv auf Fallende flanken) Erst ein Overflow von TCNT0 verursacht dann einen Interrupt (um mehr als 256 Schritte zählen zu können) bzw. ein CompareMatch mit Timer/Counter0 kann verwendet werden um exakt den letzten Schritt nicht zu verpassen und zu stoppen. Weiters läuft ein Timer/Counter2 mit prescaler so, dass alle 0,5-1ms ein Interrupt ausgelöst wird, indem dann wiederum die Rampe berechnt und in OCR0A geschrieben wird. Oder um Interrupts nicht zu blockieren wird ein Flag gesetzt, dass dann in der main-routine die berechnungen auslöst. Das behandeln von Display und Tasten läuft ebenfalls im Idle (main-routine). Wär das nix? So müsste sich der Prozessor doch die meiste Zeit langweillen. auch wenn er gerade auf der Beschleunigungsrampe nahe bei 100kHz unterwegs ist.
Die Frage ist, ob Du basteln willst und bereit bist, ggf. Kompromisse einzugehen, oder ob Du bauen willst, mit dem Ziel eine 100% funktionierende Lösung zu erreichen. Sind die 100kHz eine zugesicherte Eigenschaft, oder kannst Du nach Belieben die Anforderungen auch auf 30kHz zurückschrauben? Sollen bei 20000 Schritten alle ausgeführt worden sein, oder dürfen auch mal 50 fehlen? Dann nimm einen ATmega. Für jemanden, der mit Entwicklung solcher Schaltungen Geld verdienen will, halte ich den µC für zu riskant/zeitaufwendig zu programmieren. Berichte uns, wie es Dir ergangen ist :-)
Mein ganzen anfängliche Fragen nach der Mechanik zielten auch darauf hin, ob man die Randbedingungen nicht etwas entschärfen kann. 10Khz statt 100kHz und schon ist das Ganze mit einem AVR leicht handhabbar.
Also es geht um eine Unikat-lösung. Einmal und vorerst nie wieder. Sogesehen will ich also basteln, nicht entwickeln. 100kHz sind versprochen, auch wenn ich mich damit blind versprochen habe... Fahre ich mit 30kHz läuft der Prozess halt dreimal so lang... Das ist auf dauer Teuer, denn die Produktion läuft deutlich langsamer. Und ganz wichtig: es müssen ALLE Schritte durchgeführt werden. wenn ein offset zwischen vor- und rückweg entsteht, gibts irgendwann teure kollisionen zwischen Schlitten und Fräskopf oder Anschlag. Düsendieb schrieb: > 10Khz statt 100kHz und schon ist das Ganze mit einem AVR leicht handhabbar. Du glaubst also nicht, dass mein im letzten Post verfasster Plan funktioniert?
mit dem Timer 2 die Rampe zu machen ist bestimmt machbar, aber zuerst musst Du doch die Schritte zählen. Du brauchst daher einen Zähler bis 400.000 zählt und der muss bei jedem Schritt hoch oder runtergezählt werden. Wenn der PWM Ausgang zappelt, ist es normalerweise egal wie oft das passiert ist. da könnte ein 16Bit Zähler her und dann müssen die Überläuft gezählt werden. Oder doch alles in den Timerinterrupt, aber dann wird es eng mit der Zeit. Axel
> Du glaubst also nicht, dass mein im letzten Post verfasster Plan > funktioniert? Es faellt mir auch schwer zu glauben das es das was du zu haben glaubst auch gibt. Bei DC-Motoren ist es ja normalerweise so das die eine Spannung erwarten und am Encoder Impulse zurueckliefern. Und dann auch gerne mit mehreren 100khz. An eine Platine die einen Impuls erwartet und dann einen 'virtuellen' Schritt ausfuehrt kann man schwer glauben. Grund dafuer ist das sich dann auf dieser Platine ein relativ komplexer Regler befinden muesste der jederzeit weiss was der Motor gerade macht und der sich noch dazu schwertun wird wenn du deine Impulsgeschwindigkeit abrupt aenderst. Wenn man soetwas baut dann ist es eigentlich viel vernuenftiger wenn man dem Controller gleich ueber eine RS232, SPI, I2C, usw Schnittstelle sagt auf welche Sollposition er drehen soll weil er das intern bereits koennen muss und er damit viel einfacher seine Regelgrenzen einhalten kann. Daher wuerde ich nochmal genau nachfragen ob man dir keinen Unsinn erzaehlt hat. Wenn es aber wirklich so ist wie du dir das vorstellst dann brauchst du ja nur zwei hintereinandergeschaltete Timer. In dem einen steht ein Wert drin der Runtergezaehlt wird und jedesmal am Ausgang ein Signal ausgibt und bei Null stehenbleibt und so die Position vorgibt, und der andere bestimmt die Frequenz mit der gezaehlt wird, also deine Geschwindigkeit. Das sollte deinen Controller in keinster Weise belasten. Allerdings waere dann zwei 16bit Timer vermutlich interessant weil du zum einen mehr als 256 Schritte fahren willst und zum anderen im unteren Drehzahlbereich eine feine Aufloesung brauchst. Olaf
Düsendieb schrieb: > Du brauchst daher einen Zähler bis 400.000 zählt und der muss bei jedem > Schritt hoch oder runtergezählt werden. Wenn der PWM Ausgang zappelt, > ist es normalerweise egal wie oft das passiert ist. Den Absatz verstehe ich nicht ganz. Mein 16-bit Timer generiert mir einen Takt recht beliebeiger Frequenz. @ 16MHz ohne Prescaler kann ich 244Hz-100kHz gut abdecken, wenns nach unten nicht reicht könnte ich sogar noch am Presacaler spielen. Schritte Zählen übernimmt auch die Hardware in form eines 8-Bit Zählers, dessen überläufe ich in Software mitzähle. somit kann ich gut und leicht 400.000 Schritte mitzählen. Ich benötige so oder so einen 16-bit softwarezähler um die 8-bit-überläufe zu zählen, damit kann ich dann aber sogar bis zu 16.777.216 (2^8*2^16) Schritte abzählen. Und um auf den Schritt genau zu stoppen kann ich meinen 8-bit-Hardwarezähler mit einem Comparematch ausstatten, der im richtigen Moment den Vorgang Stoppt. Oder etwa nicht?
anscheinend ist der Fahrweg immer gleich. Dann könntest Du den Schlitten auch mit 4 Lichtschranken-Endschalter oder Effektoren fahren. Beim Vorendschalter einfach die Rampe herrunter fahren und beim nächsten Endschalter stoppen.
Ich denke schon, dass Dein Ansatz klappen könnte. Genau wirst Du es erst wissen, wenn Du es probiert hast. > Wenn man soetwas baut dann ist es eigentlich viel vernuenftiger > wenn man dem Controller gleich ueber eine RS232, SPI, I2C, usw > Schnittstelle sagt auf welche Sollposition er drehen soll > weil er das intern bereits koennen muss und er damit viel > einfacher seine Regelgrenzen einhalten kann. Das habe ich ja oben schonmal vermutet, dass es ein intelligenter Regler ist, dem halt die Sollposition in µm reingepulst werden muss. Evtl. klappt es dann sogar, die Impulszahl ganz ohne Rampe reinzusenden. Die Rampe erzeugt der Regler dann selbst. Um welches Teil (Hersteller, Typ, Link zum Datenblatt) geht es denn (das hätte bereits im ersten Post stehen sollen)?
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.