CNC-Bewegungssteuerung: Bahnplanung, Vorschub und Rückmeldung verstehen

Beim selbst ausgeführten CNC-Umbau meiner Optimum BF 20 ist die Bewegungssteuerung ein zentraler persönlicher Bezug. Welche Steuerung, Antriebe oder Messsysteme ich verwendet habe, ist hier jedoch nicht dokumentiert. Der Artikel erklärt deshalb die Funktionen anhand veröffentlichter LinuxCNC-Unterlagen und eigener Rechenmodelle, ohne diese Software als Bestandteil meines Umbaus darzustellen.

Vom Programmsatz zur Bewegung

Ein NC-Programm beschreibt unter anderem Zielpositionen, Bewegungsarten und Vorschubangaben. Die Bahnplanung muss daraus einen ausführbaren Verlauf machen. Die LinuxCNC-Dokumentation beschreibt das Motion-Modul als Verarbeitung von Wegpunkten zu einer begrenzten und gegebenenfalls überblendeten Folge von Gelenkpositionen für die Antriebe. Das ist eine konkrete Umsetzung dieses allgemeinen Aufgabenbereichs.

Die CNC-Steuerung als Gesamtsystem umfasst zusätzlich weitere Aufgaben. Werkzeugwechsel, Bedienoberfläche oder Ablaufbedingungen sind nicht dasselbe wie die fortlaufende Sollwertbildung. Für eine Fehlersuche würde ich deshalb zuerst festhalten, an welcher Stelle die Abweichung sichtbar wird: im Programm, in der geplanten Bewegung, im Rückmeldesignal oder erst am gefertigten Teil.

Koordinatenachse und mechanischer Antrieb unterscheiden

LinuxCNC trennt Achskoordinaten von den mechanischen Freiheitsgraden, die dort als Joints bezeichnet werden. Bei einer einfachen kartesischen Maschine kann eine direkte Zuordnung vorliegen. Bei einer anderen Kinematik muss dieselbe gewünschte Werkzeugbewegung durch eine andere Kombination mechanischer Bewegungen entstehen. Die Anzahl der Motoren allein beschreibt daher nicht vollständig die programmierten Freiheitsgrade.

Ich würde bei einer unbekannten Maschine zuerst die tatsächliche Zuordnung dokumentieren: Welche Bewegung gehört zu welcher Anzeige, welche Einheit wird verwendet und wo liegt der Referenzbezug? Die Referenzfahrt und der Werkstücknullpunkt beantworten dabei unterschiedliche Fragen. Eine plausible Bildschirmposition ist noch kein unabhängiger Nachweis für die Lage des Werkzeugs im Raum.

Warum der Vorschub nicht sofort erreicht wird

Wir setzen für eine Lehrrechnung 10 mm Weg, 20 mm/s Zielgeschwindigkeit und 100 mm/s² Beschleunigung beziehungsweise Verzögerung an. Start- und Endgeschwindigkeit sind null. Die Zielgeschwindigkeit entspricht 1.200 mm/min. Das Modell verwendet sofort wechselnde Beschleunigungen; eine reale Ruckbegrenzung wird nicht abgebildet.

Für das Beschleunigen gilt t = v/a = 20/100 = 0,2 s. Der Weg beträgt bei konstanter Beschleunigung aus dem Stillstand s = v²/(2a) = 2 mm. Das Bremsen benötigt ebenfalls 2 mm. Für die verbleibenden 6 mm bei 20 mm/s kommen 0,3 s hinzu. Die gesamte Bewegung dauert deshalb 0,7 s, obwohl 10/20 nur 0,5 s ergeben würde.

Die Division Weg durch Zielgeschwindigkeit berücksichtigt die Beschleunigungsphasen nicht. Der mittlere Vorschub unseres Modells liegt bei 10/0,7 ≈ 14,29 mm/s oder rund 857 mm/min. Es liegt kein Rechenfehler vor, wenn dieser Wert kleiner als die programmierte Zielgeschwindigkeit ist.

Kurze Strecken erreichen die Zielgeschwindigkeit möglicherweise nicht

Bei gleichen Annahmen verkürzen wir den Weg auf 1 mm. Für Beschleunigen und Bremsen auf 20 mm/s wären zusammen 4 mm erforderlich. Das ist mehr als der gesamte Weg. Ein symmetrisches Dreiecksprofil erreicht hier nur v = √(a × s) = √100 = 10 mm/s und benötigt insgesamt 0,2 s.

Diese zweite Rechnung zeigt das Prinzip, nicht das exakte Verhalten einer bestimmten Steuerung. LinuxCNC erläutert bei der Bahnplanung ebenfalls den Zusammenhang zwischen kurzen Segmenten und notwendigem Abbremsen. Konkrete Parameterdefinitionen unterscheiden sich; die Beschleunigung unserer Übung darf deshalb nicht ungeprüft als gleichnamiger Konfigurationswert übernommen werden.

Bahnübergänge sind eine eigene Entscheidung

Die LinuxCNC-Unterlagen unterscheiden genaues Anfahren beziehungsweise Stoppen und das Überblenden von Bahnabschnitten. Wer eine Ecke mit endlicher Geschwindigkeit durchfahren möchte, muss die Richtungsänderung unter den Bewegungsgrenzen berücksichtigen. Eine Überblendung kann dafür die geplante Kontur verändern. Die erlaubte Abweichung gehört zur Aufgabe und zur Steuerungseinstellung.

Der Beitrag zum Überschleifen von CNC-Bahnen behandelt diese Frage genauer. Eine schnellere Bewegung ist nicht automatisch die bessere Bearbeitung. Ich würde Oberflächenanforderung, zulässige Konturabweichung und Werkzeugverhalten zusammen betrachten. Eine Änderung der Bahnplanung muss außerdem mit den vorgesehenen Freiräumen vereinbar bleiben.

Rückmeldung und tatsächliche Position einordnen

Ein Rückmeldesignal muss immer zusammen mit seinem Messort betrachtet werden. Eine erfasste Motorbewegung und eine direkt am Maschinenschlitten gemessene Bewegung können unterschiedliche Teile der mechanischen Übertragung einschließen. Der Schleppabstand beschreibt einen Vergleich in einer bestimmten Signalkette; ohne diese Zuordnung ist eine einzelne Zahl leicht missverständlich.

Bei einer Diagnose würde ich Sollverlauf, verfügbares Rückmeldesignal und unabhängige Prüfung getrennt protokollieren. Eine ruhige Anzeige oder eine fehlerfrei abgespielte Simulation beweist keine Maßhaltigkeit des Werkstücks. Für den Endzustand bleiben Werkzeug, Aufspannung, Temperatur und geeignete Messungen relevant.

Änderungen nachvollziehbar prüfen

Ich würde immer einen dokumentierten Ausgangsstand aufbewahren und genau eine begründete Änderung vergleichen. Dazu gehören Softwarestand, Parameterbedeutung und ein geeigneter Prüfablauf aus den Maschinenunterlagen. Grenzwerte blind zu erhöhen, weil ein Programm langsamer als erwartet läuft, ist keine belastbare Diagnose.

Ein Messprotokoll kann geplante Bewegung, beobachtete Abweichung und Ergebnis zusammenführen. Erst diese Verbindung zeigt, ob eine Änderung das eigentliche Problem verbessert hat. Die beste Ausgangsfrage lautet deshalb nicht „Wie stelle ich alles schneller?“, sondern „Welche Bewegung wird verlangt, welche Begrenzung wirkt und was wurde tatsächlich gemessen?“