Announcement: there is an English version of this forum on Guten Abend, wir haben in der Arbeit ein kleines Projekt gestartet und ich wollte Euch nur kurz bitten euren Senf dazu zu geben =) Also wenn wer eine Idee hat immer her damit ! Kurz zum Projekt: Miniatur 6Achs-Roboter um Firmen-Intern Know-How zu sammeln. Vorerst sollte es aber nicht zuviel kosten. Unsere Idee: Ein ganz normaler PC errechnet die Verfahrwerte jeder Achse, also wie viel Grad sich die Geschichte drehen soll. Diese Daten werden dann, für alle Achsen in einem Block der wie folgt aussieht Achse[i](Vorschub mm/min) (Winkelwert °) (WinkelRichtung +/-) (RampenWert %) an ein Raspberry PI gesendet. Also alle erforderlichen Daten für den kompletten Bewegungszyklus. Auf welche Art genau wissen wir noch nicht. Dieses verteilt dann den jeweiligen Block an die betreffende Achs-Steuerung und Arbeitet sich durch, wie bei einem NC-Programm. Die Steuerung ist für jede Achse gleich und soll wie folgt aussehen: Ein Arduino Nano empfängt die Daten und berechnet die Rampen etc. Aus dem Vorschub/min wird dann eine Frequenz errechnet die über einen SPI-Interface an einen programmierbaren Frequenzgenerator gesendet wird. (AD 9833+ OpAmp 3mal +1 gain um auf 5V TTL zu kommen) Programmierbar um eben die Frequenz im Betrieb hoch- bzw runterzuregeln um die Rampe zu erzeugen. Der gibt dann das eigentliche Step-Signal an die Motor-Endstufe. Der Arduino übernimmt während dieses Vorgangs die Soll-Ist Abfrage vom Motor-Encoder(5V TTL 4000i/u) und positioniert den dann falls kleine Fehler auftreten. Auch überwacht Er über die Analog Eingänge die Temperatur an der Endstufe, am Motor, am Arduino selbst und in der näheren Umgebung im Schaltschrank. Drehrichtung und DE/EN wird halt auch vom Arduino übernommen. Die Temperatur-Werte und noch n bissel andres Zeug schickt der Arduino nach jedem empfangenen Block mit einer Quittierung des Blocks an den PI zurück. Das Raspberry PI übernimmt die komplette Peripherie, soll heißen: Not-Aus, Stromüberwachung, Temperatur Überwachung, TeachIn etc etc. Soweit unsere Idee. Jetzt zurück zum Anfang! Ist das überhaupt machbar? Wenn ja => Was haltet Ihr davon? Was kann man besser machen? Was ist gut? Zu Aufwendig? Gibt es effizientere Wege (Soll erstmal nicht zu teuer werden, daher der Eigenbau)? Vielen Dank für jeden Kommentar im voraus ! Und nein, uns ist nicht mehr zu helfen =D
Das halte ich für viel zu kompliziert. Warum ein Arduino pro Achse, wenn man das auch mit 1-2 Controllern für alle Achsen zusammen machen kann? Und warum erzeugst du die Taktfrequenz nicht direkt mit dem Controller? Wie soll der denn vernünftig nachregeln, wenn er dafür erst noch einen externen Taktgeber beeinflussen muss? KIS - Keep it simple! Ihr wollt ja keine Mondlandfähre bauen ;) Mit freundlichen Grüßen Thorsten Ostermann
Das GRBL ist recht übersichtlich aufgebaut. Da lassen sich auch die Einzelteile des Quellcodes benutzen. https://github.com/grbl/grbl Beschleunigungsrampen zusammensetzen und 3 Schrittmotore synchron ansteuern - alles auf einem Arduino.
Danke erstmal für euren Input!
"Und warum erzeugst du die Taktfrequenz nicht direkt mit dem
Controller?"
Wie macht man das? Was hat man für Möglichkeiten? Ein PWM-Signal
herzunehmen ist mir auch schon durch den Kopf gegangen aber ein Arduino
ist dafür nicht geeignet, deswegen haben wir das verworfen.
"Wie soll der denn vernünftig nachregeln, wenn er dafür erst noch einen
externen Taktgeber beeinflussen muss?"
Kannst du mir bitte genauer erklären wie du das meinst?
Wir stellen uns da so vor :
BlockDaten kommen zum Arduino
=>
Aus Vorschub/min wird eine Frequenz[x] für die Endstufe errechnet.
=>
Frequenz wird auf 0 gestellt und dann stufenlos bis X hochgeregelt.
Ungefähr so:
//Für jedes setFreq(); muss man 28BIT via SPI an den Chip senden. Das
dürfte nicht zu lange dauern, denke ich.
setFreq(0);
for ( i= 0; i <??; i++){
setFreq(i);
delay(1);
}
==> hier ist die 10% Rampe zu Ende
setFreq(Verfahrgeschwindigkeit für die mittleren 80% der Strecke)
==> und dann wie gerade eben eine 10% Rampe zum abbremsen
//Aus Encoder-Werten lesen wie weint man vom Soll-Wert weg ist
//und dann mit einer kleinen Frequenz(500-1000Hz) zum Soll-Wert fahren.
==>
//Block beendet an Raspberry PI senden, mit Achsname und Kontrollwerten.
==> nächster Block =)
Sollte halt eine Rampe rauskommen.
Währenddessen überwacht er den Encoder um so nahe wie möglich an den
Soll-Wert zu kommen.
Und wir wollten einen Nano pro Achse verwenden, um nur einen seeeeehr
einfachen Code schreiben zu müssen der dann Universell einsetzbar ist.
Auch würde die Platine dafür perfekt neben die Endstufe auf die
Hut-Scheine passen.
Dieses GRBL sieht interessant aus, aber ist das nicht nur was für
Werkzeugmaschinen? Das an unsere Bedürfnisse anzupassen wäre doch viel
Aufwendiger, oder irre ich mich?
Ich bin dir sehr dankbar für den Tipp und werde es mir anschauen =)
Was gibt es denn noch für Möglichkeiten ein regelbares TTL
Rechtecksignal zu erzeugen?
Mir fällt nur das PWM-Signal ein, welches aber beim Arduino wegen zu
kleiner Frequenz ausfällt(max 65kHz). Wir wollten bis Minimum 1MHz
(Ergibt bei 16x Microstepping und 1,8° Motor 1875 u/min). Um anständig
fahren zu können, ihr versteht =)
Das mit dem stark fallendem Drehmoment bei dieses Umdrehungszahlen haben
wir bedacht und durch eine ausreichende Übersetzung bereinigt =D
Später wenn das alles weiter ist werden wir dann wohl auch Servos
verwenden.
Oder man erzeugt jedes Taktsignal mit dem Arduino selbst an einem Pin,
aber schafft der da die 1MHz und kann währenddessen noch einen Encoder
mit 4000i/u auswerten?
Wir sind wie gesagt noch auf der Suche nach einer Lösung!
Vielen Dank für die Tipps das hilft schon mal weiter.
Maxi Melzer schrieb: > Und wir wollten einen Nano pro Achse verwenden, um nur einen seeeeehr > einfachen Code schreiben zu müssen der dann Universell einsetzbar ist. > Auch würde die Platine dafür perfekt neben die Endstufe auf die > Hut-Scheine passen. Eins hab ich vergessen =D Jede Achse hat ja unterschiedliche Verfahrgeschwindigkeiten, also braucht man wenn man das mit 2 Arduino's macht jeweils 3 Taktsignale mit unterschiedlicher Frequenz. Wie gesagt bis 1MHz. Dazu dann noch drei Encoder auswerten und verrechnen. Wird das nicht zuviel für einen Arduino? Eine Idee hab ich auch noch: Zwei Arduinos übernehmen alle sechs Achsen und ein dritter wertet die Encoder aus. Die Werte müssten dann aber halt wieder verschickt werden, was eine Menge Traffic nach sich ziehen würde. Lieg ich mit der Behauptung soweit richtig? Gerade weil alleine durch die vielen Positions-Werte die verschickt werden eh einiges los ist (Wollen auch komplexe 3D Bahnen abfahren).
Maxi Melzer schrieb: > Wir wollten bis Minimum 1MHz > (Ergibt bei 16x Microstepping und 1,8° Motor 1875 u/min). Um anständig > fahren zu können, ihr versteht =) Ich wollte ja noch mehr schreiben, aber wenn ich diese komischen Zahlen nachrechne, komme ich auf 18750 Upm. Mich würde der Motor interessieren, der so 'zügig' dreht. Ich melde mich wieder, wenn die Taktrate <= 50 kHz liegen wird ;-)
Maxi Melzer schrieb: > Wie gesagt bis 1MHz. Bist Du Dir da sicher, das Du den Stepper bis 1MHz takten möchtest? Maxi Melzer schrieb: > (Ergibt bei 16x Microstepping und 1,8° Motor 1875 u/min). Um anständig > fahren zu können, ihr versteht =) Wie kommst Du eigentlich auf diese Berechnung? Maxi Melzer schrieb: > Mir fällt nur das PWM-Signal ein, welches aber beim Arduino wegen zu > kleiner Frequenz ausfällt(max 65kHz). PWM???? Bitte nicht!! Fangt mal klein an, und versucht zu verstehen, wie ein Stepper und dessen Treiber aufgebaut sind und wie sie funnktionieren.
:
Bearbeitet durch User
Danke für eure Beiträge m.n. und Bülent. Muss ich mich wohl von 1MHz auf 100kHz runter korrigieren. Diese verdammten Nachkommastellen =D Rechnung sieht wie folgt aus: 1875U/Min => 31,25U/Sekunde 31,25U/Sekunde * 200Schritte/Umdrehung => 6250 TaktSignale pro Sekunde 6250Taktsignale pro Sekunde * 16Fach MikroStepping => 100.000 TaktSignale pro Sekunde == 100kHz Ist das diesmal korrekt oder vertue ich mich schon wieder? War mein Fehler, wie gesagt wir Sammeln noch Erfahrung. Dennoch würde es mich sehr freuen wenn ihr beiden vielleicht noch den einen oder anderen Tipp für uns habt! Danke
1875 U/min musst du mit einem Schrittmotor erst einmal erreichen. Vergiss nicht, dass dann kaum noch Drehmoment zur Verfügung steht. Und wenn du das schaffst, brauchst du auch kein 1/16-tel Schritt mehr, weil die Stromregelung dann längst nicht mehr greift. Falls im unteren Drehzahlbereich trotzdem 1/16 gewünscht sein sollte, könnte man dynamisch umschalten. Aber das kann GBRL dann sicherlich nicht mehr ohne Anpassung. Was soll das eigentlich für ein Roboter werden, der 6 Achsen benötigt, die mit jeweils 1875 U/min angetrieben werden? Mit freundlichen Grüßen Thorsten Ostermann
Danke für Eure Beiträge, Chefentwickler schrieb: > Nimm ein BLDC-Motor. Daran haben wir Anfangs auch gedacht. Leider haben BLDC-Motoren für unser Vorhaben zu wenig Drehmoment und sind mit komplettem Equipment meines Wissens nach zu teuer. Auch ist die enorme Stromstärke durch unsere beschränkten finanziellen Mittel ein Problem. Korrigiert mich bitte wenn ich mich irre, denn wenn ich mich irre ist das eine Gute Alternative. Thorsten Ostermann schrieb: > Und wenn du das schaffst, brauchst du auch kein 1/16-tel Schritt mehr, > weil die Stromregelung dann längst nicht mehr greift. Falls im unteren > Drehzahlbereich trotzdem 1/16 gewünscht sein sollte, könnte man > dynamisch umschalten. Das hört sich nach einer guten Idee an !! Das werden wir mal weiter verfolgen. Thorsten Ostermann schrieb: > Was soll das eigentlich für ein Roboter werden, der 6 Achsen benötigt, > die mit jeweils 1875 U/min angetrieben werden? Nur ein Prototyp um wie oben genannt Know-How zu sammeln. Ich weis, hört sich äußerst ambitioniert an.... Aber wer nichts wagt der nichts erreicht =) Die 1875u/min kommen durch die hohen Untersetzungen zu Stande und ist auch das Maximum was wir uns wünschen. Also für die unteren Achsen. Für die vorderen wird es dank der kleineren Untersetzung und des weniger benötigten Halte-/Drehmoments eine kleinere Motor Drehzahl sein. Aber wie das !immer! ist wird eh weniger rauskommen =) Die Untersetzungen liegen zwischen 1:8 (6Achse) und 1:20(1Achse) um vom Bauraum her kleiner Motoren verwenden zu können und trotzdem das benötigte Drehmoment zu erreichen. Unsere Überlegung: Bei der 1Achse z.b soll ein NEMA 34 mit 9Nm Haltemoment (mit US 1:20 ca. 180Nm) zum Einsatz kommen. Laut Nanotec.com hat der bei 48V Parallel Versorgung bei n=1000u/min zwar nurnoch 1,35Nm (mit US 1:20 ca. 27Nm) Drehmoment aber logischer-Weise annähernd seine volle Leistung. Mehr brauchen wir ja nicht. Ist die Last (über die Rampe erst einmal beschleunigt) hilft uns die Trägheit weiter und wir brauchen keine hohen Momente mehr, nur Drehzahl. So sieht unser Plan zumindest aus. Und das abbremsen kriegen wir auch irgendwie hin, zur Not verlängern wir die Brems-Rampe, oder bauen gleich was Mechanisches dazu. Zur Untersetzung werden wir wohl Zahnriemen verwenden, da diese leicht, billig und Einfach zu verwenden sind. Auch zeichnen sie sich durch einen guten Wirkungsgrad aus und sind absolut (Die hundertstel oder 1/1000mm vernachlässigen wir mal =D ) spielfrei. Erklärung: Eine Drehzahl von 1000U/Min wird schätzungsweise am Ende rauskomen, trotz angepeilten 1875U/Min. Bei n=1000 schaffen wir trotz 1:20 Untersetzung 300°/Sekunde ohne Rampe etc pipapo. Das reicht uns erstmal. Langsamer geht immer und wenn wir schneller werden wollen kommt wieder das mit dem Know-How sammeln ins Spiel. Rechnung: 1000 U/Min / 60 ==> 16,666U/Sekunde(motor) 16,6U/Min(Motor) / 20 ==> 0,833 U/Sekunde (Achse) =>(Untersetzung 1:20) 0,833U/Sekunde (Achse) *360° = 300°/Sekunde(Achse) Ich denke diesmal hab ich mich nicht verrechnet =) Ich hoffe ich konnte Euch einen besseren Überblick zu unserem Vorhaben geben. So zu zurück zum eigentlichen Thema: Ich stell mir das nun so vor: 1Nano pro Achssteuerung =>4 DPins für die Codierung des uSteppings => SPI an AD9833 um eben die RechtEck-Taktfrequenz erzeugen zu können. =>2 DPins für DIR und DE/EN =>4 APins für Temperatur Überwachung etc. Das alles um die Flexibilität und Einfachheit des Codes zu gewährleisten. Auch wegen den Kosten (Ein Nano kostet nur 5€ soweit ich mich erinnere). Das ganze andre Zeugs nochmal 15€ ==> 20€ Achs-Controller in den man ohne Ende Softwaremäßige Features einbauen kann, wenn man will. Zusätzlich ist noch Platz für endlos elektronische Peripherie. Aber das ist Zukunftsmusik. Und der Kernpunkt, ein auf 0.004 Hz genaues TaktSignal. Das benötigen wir, da wir auch komplexe Stecken möglichst präzise abfahren wollen. (Man denke an Vermessung von Werkstücken, Freiform-Bearbeitung im Modellbau etc. !Wie gesagt Zukunftsmusik!) Zitat AD Datasheet: "with a 1 MHz clock rate, the AD9833 can be tuned to 0.004 Hz resolution." Bei 4/1000Hz kommt mir das mit den Kanonen und Spatzen in den Sinn, aber schaden wird es auch nicht! Wenn Euch was bessere einfällt bin ich dankbar um jeden Tipp! Wie ihr seht, setze ich mich auch ernsthaft damit auseinander, da wir ja Know-How sammeln wollen =) Vielen Dank
Es ist wohl wieder Karneval. Bring erst einmal irgendeinen Schrittmotor zum Drehen. Mehr fällt mir dazu nicht ein.
m.n. schrieb: > Es ist wohl wieder Karneval. Es tut mir sehr leid das du so denkst, aber könntest du mir bitte auch sagen wieso du uns für so unfähig hältst? Wir sind vielleicht keine Experten oder haben die Weisheit gar mit Löffeln gefressen.....=> Genau deswegen gibt es diesen Topic also verzeih mir wenn ich Stuss rede. Falls dir aber doch noch etwas konstruktives einfallen sollte, bedanke ich mich schon einmal im Voraus!
Für eine Untersetzung 1:20 benötigst du aber schon zwei Riemenstufen. Und bei den Leistungen die ihr da abrufen wollt (140W mechanisch), solltet ihr ernsthaft darüber nachdenken, ob Schrittmotoren die richtige Technologie sind. Schließlich benötigt ein mobiler Roboter auch Batterien, welche die Leistungs zur Verfügung stellen. Wenn es Schrittmotoren sein sollen, würde ich eine Steuerung verwenden, die echten closed-loop Betrieb erlaubt. Und ja, eine Steuerung für 5-8A bei 48V mit closed-loop gibt es auch nicht geschenkt. Da sind die paar € mehr oder weniger für ein oder zwei zusätzliche Controller Peantus. Schade dass du nicht mehr über den Verwendungszweck des Roboters schreiben kannst/willst. Aus Spaß am Basteln investiertert keine Firma Geld in so ein Projekt. Also sollte man es gleich vernünftig aufziehen. Und dazu gehören Lasten- und Pfichtenheft, damit die Anforderungen und der vorgesehene Lösungsweg klar definiert sind. Aber wenn noch nicht einmal die Grundlagen in Sachen Antriebstechnik vorhanden sind läuft das wohl eher auf "Jugend forscht" hinaus, als auf ein Projekt, mit dem ein konretes Ziel erreicht werden soll. Wahrscheinlich macht sich die Projektleitung da ziemlich falsche Vorstellungen von der Komplexität der Aufgabenstellung. Mit freundlichen Grüßen Thorsten Ostermann
:
Bearbeitet durch User
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.