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.
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
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
