CNC mit Gleichstrommotoren

[Osser]

Ja manchmal geht das Schneller als man denkt.

[Osser]

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.

Alle SSI
Alle 10-30V
Alle von einer Dumpfbacke einfach 20cm hinter dem Drehgeber abgezwickt.

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.


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.

[Rabenauge]

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.

[Osser]

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.

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

[oberallgeier]

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

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

[Osser]

Hallo Oberallgeier,

das Regelintervall der CNC ist ja üblicherweise 4ms, was mir bei dem ATmega mit 16MHz also 64.000 Takte für das Abarbeiten ließ.
Das wäre also grob folgendes
- SSI Positionswerte lesen
- SSI dekodieren und Fehlerprüfung
- evtl. DNC Daten nachladen
- NC Regler abarbeiten und Koordinate abholen
- PID Ist und Soll einstellen (x, w)
- PID durchlaufen
- VT515 Display über serielle Leitung updaten
- Bedienpanel abfragen/steuern
- Bestimmt noch einiges mehr

Die Steuerung lief -- wie soll ich sagen -- ordentlich, nicht perfekt aber ordentlich.


Wenn ich jetzt einen Raspi 4 nehme habe ich folgendes.
- ARM Cortex A72 1,5GHz Quad Core
- 1GB Speicher
- Flash Disk für die NC Programme
- HDMI für einen Monitor

Dann schafft der Prozessor im Regelzyklus also 6e6 Zyklen in 4ms, das ist etwa 93 mal so viel wie beim ATmega64.
Da ich vier Kerne habe, können die Aufgaben Anzeige updaten, Tastenabfragen und Bedienpanel abfragen schonmal in andere Rechenkerne verteilt werden. Dadurch bleibt in den 4ms noch viel mehr Rechenzeit übrig, was von Vorteil sein sollte.

naja wir werden ja sehen obs klappt oder nicht.


Gruß,
Osser

[oberallgeier]

Du hast natürlich recht - ATmega gegen RasPi sind 16 MHz gegen 1,5 GHz - die fast hundertfache Taktrate. Vom 8Bitter gegen den Vielbitter+Multicore ganz abgesehen. Ich bin neugierig und wünsche Dir viel Erfolg - ohne Widerstände!