CNC mit Gleichstrommotoren

Moin.
Der neue in diesem Forum, aber nicht so ganz neu in der Materie... Darüber später mal mehr. Hierher bin ich über die Suche nach Selbstbau-Konzepten mit dem Suchbegriff Gleichstrom-Servomotor gekommen. Auf jeden Fall, das kann ich aus langer Erfahrung sagen, das Richtige, wenn es um Laufruhe, Vermeidung von Schrittfehlern etc. geht - im Gegenteil, man muß aufpassen, daß man sich mit den kraftvolleren Servomotoren nicht die Maschine verbeult.

Nun aber zum Aufhänger, warum ich mich an diesem Beitrag einklinke: Ich bau mir gerade privat eine neue 3-achsige, mit Optionen zu mehr als 4, 5, ... - schließlich heißt das hier Roboternetz.

Bei den Recherchen zur Bauelementebeschaffung fiel mir auf, daß es von den wenigsten Anbietern Angaben zur Linearität und vor allem zur absoluten Genauigkeit von Antriebsspindeln gibt. Besonders bei Kugelumlaufspindeln gibt es den Unterschied zwischn gerollt und geschliffen, und den merkt man dann natürlich im Preis. Wobei auch der noch nichts über die tatsächliche Genauigkeit aussagt. Ein ausgewiesener Experte aus meinem Bekanntenkreis (er ist wirklich einer) stellte bei Kugelumlaufspindeln, deren Mutter nach Steigung und Drehwinkel um exakt 500mm bewegt worden sein sollte, Fehler von bis zu 0.75 mm fest. Dafür gibt es bei Azubis schon im ersten Lehrjahr mahnende Worte... Gewindestangen sind hinsichtlich der Genauigkeit noch einmal ne Nummer vergnügungssteuerpflichtiger - dafür werden sie ja weder hergestellt noch spezifiziert.

Daher hab ich mal weitergesucht und bin auf lineare Weggeber gekommen. Da gibt es nicht nur die linearen Glasmeßstäbe, sondern auch elektromagnetisch arbeitende - ähnlich einem Tonband, auf das kalibriert S/N-Wechsel geschrieben sind, die dann mit zwei um einige Bogenminuten versetzten Sensoren mit großer Präzision ausgelesen werden können. Das ganze wird antriebsnah an / in den Linearantrieben eingebaut, sodaß man nicht den angenommenen, sondern den tatsächlichen Ist-Wert der Achse messen kann.

Hast Du mal die absolute Genauigkeit Deines Aufbaus gemessen? Und wie bringst Du ggf. die mechanische Kennlinie Deines Antriebs, soweit bekannt, in die Positionierung ein?

Gruß,
U.

Hi Langkieler,
kaum ist ein Monat vergangen schon kommt die Antwort. Irgentwie hab ich keine Benachrichtigung erhalten das eine neue Antwort im Thread eingegangen ist....

Zitat:

---

...wie bringst Du ggf. die mechanische Kennlinie Deines Antriebs, soweit bekannt, in die Positionierung ein?

---

Ich habe einfach Quadrate gefräst mit bekannten Abmaßen und mit einer Schieblehre nachgemessen. Die Maße waren so weit ich mich erinnere nahe am SOLL, aber natürlich nicht völlig Exakt.
Die Kenngrößen werden über Parameter der Steuerung im UI (User Interface) via VT525 Terminal eingegeben. Das UI was Du hier siehst läuft auf dem PC und emuliert einen VT525 Terminal.
Die Steuerung sendet dann die Escape-Sequenzen via RS232 im Digital Equipment VT525 Dialekt an das Terminal und rendert so das UI.
Das Terminal ist natürlich auch selbst geschrieben wie alles in/an der CNC-Maschine.


Eingabe von Achsparametern via VT525 Terminal (Threadbeitrag)
https://www.roboternetz.de/community...l=1#post437161

Für jede Achse gibt es ein Parameterset:
Anhang 25210
Kp, Ki, Kd, Kv das ist denke ich klar
PWM MIN F minimale PWM Frequenz "forward"; 0=ignorieren
PWM MIN B minimal PWM Frequenz "backward"; 0=ignorieren
AXE DIR Positive Richtung der Achse (vorwärts +1/rückwärts -1)
UKS Umkehrspiel der Achse (Spiel im Spindel/Mutter Verbund)

und in den globalen Parametern wird das Folgende eingestellt:
Anhang 25211
SA Schleppabstand; Vorlaufwert der programmierten NC-Programm Position zur wirklichen Verfahrposition
TS Timeout Schleppabstand; Legt den Schwellenwert fest bis ein Fehler erkannt wird
EF Error Flag; Counter der angibt wann die Steuerung mit einem Regelfehler aussteigen soll.
PWM_MAX Der obere Grenzfrequenz für PWM; War wegen den Optokopplern nötig, da die bei einer bestimmten Frequenz aussteigen.
SPI WRD SPI write delay; Der zweite Atmega kontrolliert die Achspositionenen und braucht halt etwas bis er fertig ist.
SPI SPEED Damit wird die Übertragungsfrequenz zum zweiten ATMega eingestellt (0=Max Speed)
EENC SNAPD External Encoder Snapshot Delay; Finetuning beim lesen der einzelnen Koordinatendaten (X,Y,Z)

Die µC sind mit meiner selbstgeschriebenen IDE programmiert und geflasht(Mein Blog):
http://www.secius.com/AsuroFlash/archives/28


Der Blog zur IDE
https://www.roboternetz.de/community...u-Flashnnn-exe


Gruss,
Osser

Hallo, Osser,
danke für die Antwort - sie zeigt, daß Du die aus nicht ganz perfekter Mechanik herrührenden Fehler berücksichtigst und korrigierst. Das läßt sich ja leider nicht von jeder Steuerung behaupten.

Gruß,
- der Langkieler -

Es ist schon ein Weilchern her

das ich meine CNC Fräsmaschine gebaut habe. Ursprünglich war mein Ziel eine Machine zu bauen die von mit komplett selbst hergestellt ist, das bedeutet also alle mechanische Bauteile aus Standardwerkstoffen (in meinem Fall Stahl) selbst herstellen mit den mir zur Verfügung stehenden Maschinen. Dann sollten die Antriebe aus gewöhnlichen DC Motoren mit angekoppelter Positionsgebern erstellt werden wodurch ein selbst aufgebauter Servo entsteht. Schliesslich war mein Ziel die Steuerung der Servos, des Interpolators und des Positionsintegrators in einem kleinen! ATMega mit gerade einmal 4096 Byte Arbeitspeicher zu implementieren.

Das habe ich 2014 fertiggestellt und das Resultat ist auf der Seite "Meine CNC Fräsmaschine" zu sehen.




Vor Kurzem war ich dann mal wieder im Keller und sah die Maschine dort stehen. Sie war leider schon leicht angerostet in der Zwischenzeit -- ojeh.
Da ich am liebsten mit neuen Entwicklungen beschäftige und mein interesse am fertigen Proidukt ziemlich schnell schwindet, stand die Maschine leider aus diesem Grund in einem etwas traurigen Zustand auf ihrem Tisch.

Ich dachte mir im vorbeigehen das ich doch das Projekt in die jetzige Zeit transformieren könnte und die Steuerung die bislang in einem ATMega64 werkelte auf eine neuere Plattform migrieren könnte.
Die alte ATMega Platform hat zwar einigermaßen funktioniert, aber das Entwickeln der Software als Monolith ist schon ziemlich aufwändig.
Das Arbeiten auf dem µC war einigermaßen performant, aber es gibt schon noch einiges an Potential nach oben.

Ihr könnt euch ja vielleicht schon denken wofür ich mich entschieden habe :)

Ich werde also in der nächsten Zeit hier Berichten welche Fortschritte ich gemacht habe.

Stay Tuned

Zitat:

---

Zitat von Osser

Es ist schon ein Weilchern her
...
Stay Tuned

---

Schlappe noch nicht mal neun Jahre.... :) Das Leben saust so wuuuusch durch. Bin gespannt.

Ja manchmal geht das Schneller als man denkt.

:cool:

Hi,

ich habe die Maschine schon in ihre Bestandteile zerlegt und mir drei neue Drehgeber besorgt.
Da ich zuvor einen ziemlich bunten Mix an Drehgebern hatte
X-Achse; ROQ425; 2048 Schritte; EnDat; 5V
Y-Achse; ROQ425; 2048 Schtitte; EnDat; 5V
Z-Achse; ROQ424; 512 Schritte; SSI; 10-30V
will ich bei der neuen Steuerung mal Hardwareseitig mit einheitlichen Bedingungen starten.

Ehrlich gesagt waren die beiden alten Drehgeber defekt seit ich aus versehen 12V auf die 5V Drehgeber gegeben habe.

-- Toast -- ;)

Naja, wie dem auch sei. Ich habe mir bereits drei neue Drehgeber besorgt die jetzt alle die gleichen Parameter aufweisen.
Anhang 35705
Alle SSI
Alle 10-30V
Alle von einer Dumpfbacke einfach 20cm hinter dem Drehgeber abgezwickt. :confused:

Dafür haben sie aber auch nur 40€ gekostet, was für einen Heidenhain Drehgeber schon ein top Preis ist.
Ich hab einen Drehgeber an die ausgebaute Achse angeflanscht um dann die ersten Tests zu fahren zu können. Als Rechner Hardware habe ich mir einen Raspi 4 gehohlt mit 1GiB Arbeitspeicher der für die Zwecke mehr als ausreichend sein sollte.
Anhang 35706

Ich habe im Netz viel gelesen das es mit einem regulären Linux nicht möglich wäre eine CNC Steuerung zu bauen. Dort war dann zum Beispiel die Rede von z.B. RTOS als Betriebsystem der Wahl.
Ich bezweifle eigentlich sehr stark das mir das "normale" Linux derart Probleme bereitet wenn ich damit einen Regelzyklus aufbaue.
Wie ihr ja vielleicht noch wißt ist meine alte Steuerung in einem 8 Bit µC mit 4KiB Arbeitspeicher und 64Kib Flash gelaufen bei 16MHz Takt.

Da hat der kleine Raspi doch extrem viel mehr zu bieten! Wäre gelacht wenn der das nicht wuppt.

Okay, so viel für heute.

Zitat:

---

Zitat von Osser

Hi,

Ich bezweifle eigentlich sehr stark das mir das "normale" Linux derart Probleme bereitet wenn ich damit einen Regelzyklus aufbaue.
Wie ihr ja vielleicht noch wißt ist meine alte Steuerung in einem 8 Bit µC mit 4KiB Arbeitspeicher und 64Kib Flash gelaufen bei 16MHz Takt.

Da hat der kleine Raspi doch extrem viel mehr zu bieten! Wäre gelacht wenn der das nicht wuppt.

Okay, so viel für heute.

---

Du übersiehst da ne Kleinigkeit: im Gegensatz zu nem kleinen 8bitter ist Linux bzw, ein Raspi mit Linux kein Echtzeit-System.
Für Ubuntu Linux gab es mal nen Echtzeit-Kernel, glaub aber, der wurde eingestellt. Das war bei Ubuntu Studio, bis 16 oder so.
Ich glaub aber nicht, dass man den auf den Raspi bekäme.
Sachen, die ein Atmel mit links macht (wie z.B. an mehreren Pins gleichzeitig ne PWM auszugeben) kann ein Raspi nicht.
Aber versuchs mal (und berichte drüber), ich halts durchas für möglich, dass sich diese Probleme mit der wesentlich höheren Arbeitsgeschwindigkeit grösstenteils überspielen lassen, so dass man es praktisch nicht mehr merkt.

Hi Sly,

nein nein, das ist mir schon bewust.
Ich gehe einfach nur davon aus das die Zeit die mir durch den Scheduler geklaut wird, im Verhältnis zu der zusammenhängenden, nicht ins Gewicht fällt.

Ich habe mir vorgenommen die Steuerung in C zu realisieren, die Kommunikation mit SSI erst mal auch in C direkt zu programmieren. Pins hab ich ja ausreichend zur Verfügung.
Da ich nur 5V RS485 Treiber vorrätig habe brauchts dann noch ein Pegelwandlerchen oder einfach einen Spannungsteiler.
Mal sehen.

Als erstes entwickel ich mir eine Bibliothek damit ich ein Interface habe um die Pins schnell ansteuern. Damit soll dann SSI implementiert werden und ein Testproggi das mir anzeigt was da raus kommt.
Die Hardware baue ich mir dann mal schnell auf einem Breadboard auf und da ich unter einem MHz bleibe dürfte ich wenig Phasen und Amplitudenprobleme bekommen, hoffe ich zumindestens.

Für die, die nicht mehr wissen wie mein Maschinchen aussieht. Das ist ein Foto das ich von der fertigen Machine aufgenommen hatte mit der Steuerung basierend auf den ATmega64.
Anhang 35707
Hier sind sogar noch meine selbst gebauten Wegaufnehmer/Drehgeber verbaut die -- wie soll ich sagen -- Charaktervoll gemessen haben.
Ich habe dann später doch auf Zukaufteile gesetzt weil man sowas einfach nicht selbst bauen muß.



Gruß
Osser

Schönes Projekt; ich lese schon ne Zeitlang mit.

Zitat:

---

Zitat von Osser

.. Ich gehe einfach nur davon aus das die Zeit die mir durch den Scheduler geklaut wird .. nicht ins Gewicht fällt ..

---

Ach, nun muss ich mal meine Bedenken (nach eigenen Erfahrungen) vorlegen.

ABER: das ist etwas langatmig >> also lieber nicht wirklich alles lesen << (Punkt 6 reicht *gg*). Warum schreib ich es trotzdem? Ne CNC muss bei Schrägen oder Kurven möglichst die theoretisch gewünschte Synchronizität der verschiedenen Achsen gewährleisten um messbare Abweichungen von der gewünschten Kontur zu vermeiden. WENN da ein Motor auch nur Millisekunden (vermutlich eben sogar Mikrosekunden) anders reagiert als ein anderer - ist das, zumindest bei meinen Antriebsmotoren des Minid0, messbar.

Ich hatte die Motorregelung meiner rollenden Coladose mit zwei UNabhängigen, zeitlich versetzten Regelungsroutinen (Taktung 100 Hz für JEDE der beiden Routinen, die aber gegeneinander versetzt laufen) überprüft, weil ich keinen einwandfreien Geradlauf erreichen konnte. Insbes. der Anlauf zeigte einen Versatz. Hintergrund sind die steilen Beschleunigungen der DC-Motoren bei Geschwindigkeitssprüngen.
Hardware: ATmega1284p, Minimotörchen aus Billigstservo, Software: C.

Und so war - etwas gerafft - mein Weg zur Erkenntnis:

1. der Wunsch

2. noch immer Wunsch

3. erste Be-merkungen

4. im Rahmen des Möglichen gleichzeitig (also ein paar µs-Bruchteile hintereinander)

5. Stochern im Sprung-Nebel

6. erste Klarheit/en

Wie erwähnt - es geht hier nur um die bestmögliche "Gleichzeitigkeit" der Motörchen bei meinem MiniD0. Das zeigte eben schon deutliche Probleme beim Beschleunigen, obwohl - wenn weitgehend unbeschleunigt - ein guter Geradauslauf möglich ist.

Vielleicht nützt Dir der Hinweis etwas? Und - sorry für die Langatmigkeit.