G-Code: Syntax vs. Architektur :)

Hallo nochmal :) Ich habe vor Jahren auch Fragen zu diesem Thema gestellt, und damals hatte ich keinen Schimmer, wonach ich eigentlich suchte.

Syntax oder Grammatik geht um Lesbarkeit … und Lesbarkeit kostet Leistung :) Normalerweise spielt das keine Rolle, bis man an die Grenze kommt, an der die Blockverarbeitungszeit vergleichbar mit der Ausführungszeit ist; in diesem Moment beginnt jedes Leerzeichen, jede Blockadresslänge, die Anzahl der Blöcke, die Länge lokaler Variablennamen, die Länge einer gesamten G-Code-Zeile als String und anderes eine Rolle zu spielen: es ist die Grenze der Blöcke pro Sekunde, die zu Werkzeugreibung oder einem tatsächlichen Vorschub < programmiertem Vorschub usw. führen kann.

Dasselbe Ziel hat diese stark belasteten mathematischen Formeln/Makros … selbst mit NOEX können sie immer noch langsamer sein als linearer, sauberer, einfacher Code.

Eine solche Grenze nenne ich Echtzeit-Makros oder Echtzeit-Code; wenn man versucht, einen NURBS-Algorithmus zu pushen, um die G-Code-Leistung zu steigern, selbst bei einem 1000-Zeilen-Vorlaufpuffer, landet man schnell bei Formdiskretisierung, Maschinenverzug und Compilerzeit … Software vs. CNC :)

[HR][/HR]
Zuerst habe ich Architektur als vorbereitenden Code, allgemeines Verschachteln und Ablaufpläne von Prozeduren betrachtet … aber später habe ich erkannt, dass Architektur nicht auf der Ebene des G-Codes liegt, sondern dahinter, an der Quelle, aus der G-Code geboren wird.

Sie ist das Fundament, auf dem Syntax/Grammatik angewendet wird.

Sie ist der gemeinsame Nenner der Maschinen-Postprozessoren … sie ist ein Vektor, der darauf wartet, vom Werkzeug ins Metall geplottet zu werden …

[HR][/HR]
Syntax betrifft G-Code-Anwender.
Architektur betrifft Entwickler.

Danke :)