NGCGUI

Zur Verwendung geben Sie in ein Terminal ein:

Zur Verwendung geben Sie in ein Terminal ein:

Die folgenden INI-Datei-Elemente gehören in den Abschnitt [DISPLAY]. (Siehe weitere Abschnitte unten für zusätzlich benötigte Elemente)

Die folgenden INI-Datei-Elemente gehören in den Abschnitt [DISPLAY] zur Verwendung mit den grafischen Benutzeroberflächen AXIS, Gscreen oder Touchy. (Weitere benötigte Elemente finden Sie in den folgenden Abschnitten)

Die folgenden INI-Datei-Elemente gehören in den Abschnitt [DISPLAY] für jede GUI, die entweder NGCGUI oder PyNGCGUI einbindet.

Dies ist ein Beispiel für die Einbettung von NGCGUI in AXIS. Die Unterprogramme müssen sich in einem Verzeichnis befinden, das durch den [RS274NGC]SUBROUTINE_PATH angegeben ist. Einige Beispielsubroutinen verwenden andere Subroutinen, daher sollten Sie sicherstellen, dass Sie die Abhängigkeiten, falls vorhanden, in einem SUBROUTINE_PATH-Verzeichnis haben. Einige Unterprogramme können benutzerdefinierte M-Dateien verwenden, die sich in einem durch [RS274NGC]USER_M_PATH angegebenen Verzeichnis befinden müssen.

Der G-Code-Meta-Compiler (gcmc) kann Anweisungen wie diese enthalten:

Standardmäßig schließt gcmc das aktuelle Verzeichnis ein, das für LinuxCNC das Verzeichnis ist, das die LinuxCNC INI-Datei enthält. Zusätzliche Verzeichnisse können der gcmc-Suchreihenfolge mit dem Element GCMC_INCLUDE_PATH vorangestellt werden.

Ngcgui_ttt bietet Unterstützung für truetype-tracer (v4). Es erstellt eine AXIS-Registerkarte, die es dem Benutzer ermöglicht, eine neue NGCGUI-Registerkarte zu erstellen, nachdem er Text eingegeben und eine Schriftart sowie andere Parameter ausgewählt hat. (Truetype-tracer muss unabhängig installiert werden).

Um ngcgui_ttt in AXIS einzubetten, geben Sie zusätzlich zu den NGCGUI-Elementen die folgenden Elemente an:

NGCGUI verwendet den LinuxCNC-Suchpfad, um Dateien zu finden. Der Suchpfad beginnt mit dem Standardverzeichnis, das angegeben wird durch:

gefolgt von mehreren Verzeichnissen, angegeben durch:

Verzeichnisse (engl. directories) können als absolute Pfade oder relative Pfade angegeben werden.

Ein absoluter Pfad, der mit einem "/" beginnt, gibt einen vollständigen Dateisystemstandort an. Ein Pfad, der mit "~/" beginnt, gibt einen Pfad an, der im Home-Verzeichnis des Benutzers beginnt. Ein Pfad, der mit "~Benutzername/" beginnt, legt einen Pfad fest, der im Home-Verzeichnis des Benutzers beginnt.

Relative Pfade basieren auf dem Startverzeichnis, also dem Verzeichnis, das die INI-Datei enthält. Die Verwendung relativer Pfade kann das Verschieben von Konfigurationen erleichtern, erfordert aber ein gutes Verständnis der Linux-Pfadangaben.

Mehrere Verzeichnisse können mit [RS274NGC]SUBROUTINE_PATH angegeben werden, indem sie durch Doppelpunkte getrennt werden. Das folgende Beispiel veranschaulicht das Format für mehrere Verzeichnisse und zeigt die Verwendung von relativen und absoluten Pfaden.

Dies ist eine lange Zeile, fahren Sie nicht in mehreren Zeilen fort. Wenn LinuxCNC und/oder NGCGUI nach Dateien suchen, wird die erste Datei, die bei der Suche gefunden wird, verwendet.

LinuxCNC (und NGCGUI) muss in der Lage sein, alle Unterprogramme einschließlich der Hilfsroutinen zu finden, die aus den NGCGUI Unterdateien aufgerufen werden. Es ist zweckmäßig, Utility-Subs in einem separaten Verzeichnis zu platzieren, wie im obigen Beispiel angegeben.

Die Distribution enthält das Verzeichnis ngcgui_lib und Demodateien für Präambeln, Subdateien, Postambeln und Hilfsdateien. Um das Verhalten der Dateien zu ändern, können Sie eine beliebige Datei kopieren und sie an einer früheren Stelle des Suchpfads platzieren. Das erste Verzeichnis, das durchsucht wird, ist [DISPLAY]PROGRAM_PREFIX. Sie können dieses Verzeichnis verwenden, aber es ist besser, eigene Verzeichnisse zu erstellen und sie an den Anfang des [RS274NGC]SUBROUTINE_PATH zu stellen.

Im folgenden Beispiel werden die Dateien in /home/myname/linuxcnc/mysubs vor den Dateien in ../../nc_files/ngcgui_lib gefunden.

Neue Benutzer können versehentlich versuchen, Dateien zu verwenden, die nicht so strukturiert sind, dass sie mit den Anforderungen von NGCGUI kompatibel sind. NGCGUI wird wahrscheinlich zahlreiche Fehler melden, wenn die Dateien nicht nach seinen Konventionen kodiert sind. Gute Praxis legt nahe, dass ngcgui-kompatible Unterdateien in ein dafür vorgesehenes Verzeichnis gelegt werden sollten und dass Präambel-, Postambel- und Hilfsdateien in separaten Verzeichnissen liegen sollten, um Versuche, sie als Unterdateien zu verwenden, zu unterbinden. Dateien, die nicht für die Verwendung als Unterdateien vorgesehen sind, können einen speziellen Kommentar enthalten: "(not_a_subfile)", so dass NGCGUI sie automatisch mit einer entsprechenden Meldung zurückweist.

Eine NGCGUI-kompatible Unterdatei enthält eine einzelne Unterprogrammdefinition. Der Name der Subroutine muss derselbe sein wie der Dateiname (ohne das Suffix .ngc). LinuxCNC unterstützt benannte oder nummerierte Subroutinen, aber nur benannte Subroutinen sind mit NGCGUI kompatibel. Für weitere Informationen siehe das Kapitel O-Codes.

Die erste unkommentierte Zeile sollte eine sub-Anweisung sein.
Die letzte unkommentierte Zeile sollte eine endsub-Anweisung sein.

Der Hauptteil (Körper, engl. body) des Unterprogramms sollte mit einer Reihe von Anweisungen beginnen, die lokale benannte Parameter für jeden für den Unterprogrammaufruf erwarteten Positionsparameter definieren. Diese Definitionen müssen fortlaufend sein, beginnend mit #1 und endend mit der zuletzt verwendeten Parameternummer. Für jeden dieser Parameter müssen Definitionen angegeben werden (keine Auslassungen).

LinuxCNC betrachtet alle nummerierten Parameter im Bereich #1 bis #30 als Aufrufparameter, so dass NGCGUI Eingabefelder für jedes Auftreten von Parametern in diesem Bereich zur Verfügung stellt. Es ist eine gute Praxis, um die Verwendung von nummerierten Parametern #1 bis #30 überall sonst in der Subroutine zu vermeiden. Die Verwendung lokaler, benannter Parameter wird für alle internen Variablen empfohlen.

Jede definierende Anweisung kann optional einen speziellen Kommentar und einen Standardwert für den Parameter enthalten.

Wenn ein default_value angegeben ist, wird dieser beim Start in das Eingabefeld für den Parameter eingetragen. Wenn comment_text angegeben ist, wird dieser anstelle des Parameternamens zur Identifizierung der Eingabe verwendet.

Hinweise zu globalen benannten Parametern und NGCGUI:

(globale benannte Parameter haben einen führenden Unterstrich im Namen, wie #<_irgendeinglobalername>)

Wie in vielen Programmiersprachen ist die Verwendung von globalen Parametern mächtig, kann aber oft zu unerwarteten Konsequenzen führen. In LinuxCNC werden bestehende globale benannte Parameter bei der Ausführung von Unterprogrammen gültig sein und Unterprogramme können globale benannte Parameter ändern oder erstellen.

Von der Übergabe von Informationen an Unterprogramme unter Verwendung globaler benannter Parameter wird abgeraten, da eine solche Verwendung die Einrichtung und Pflege eines genau definierten globalen Kontexts erfordert, der schwer zu pflegen ist. Die Verwendung der nummerierten Parameter Nr. 1 bis Nr. 30 als Unterprogramm-Eingaben sollte ausreichen, um eine breite Palette von Design-Anforderungen zu erfüllen.

NGCGUI unterstützt einige globale benannte Eingabeparameter, aber deren Verwendung ist veraltet und hier nicht dokumentiert.

Während von global benannten Eingabeparametern abgeraten wird, müssen LinuxCNC-Subroutinen global benannte Parameter für die Rückgabe von Ergebnissen verwenden. NGCGUI-kompatible Unterdateien sind auf die Verwendung in der Benutzeroberfläche ausgerichtet. Daher sind Rückgabewerte keine übliche Anforderung. Allerdings ist NGCGUI als Testwerkzeug für Subroutinen nützlich, die global benannte Parameter zurückgeben, und es ist üblich, dass NGCGUI-kompatible Subdateien Utility-Subroutinen aufrufen, die Ergebnisse mit global benannten Parametern zurückgeben.

Um diese Verwendungen zu unterstützen, ignoriert NGCGUI globale benannte Parameter, die einen Doppelpunkt (:) in ihrem Namen enthalten. Die Verwendung des Doppelpunkts (:) im Namen verhindert, dass NGCGUI Eingabefelder für diese Parameter erstellt.

Im obigen Beispiel befindet sich das Unterprogramm in einer separaten Datei namens helper.ngc. Die helper-Routine liefert ein Ergebnis in einem globalen benannten Parameter namens #<_helper:answer.

Aus Gründen der guten Praxis lokalisiert die aufrufende Teildatei das Ergebnis sofort für die Verwendung an anderer Stelle in der Teildatei. Es wird der globale benannte Parameter genullt, der für die Rückgabe des Ergebnisses verwendet wird, um seine unbeabsichtigte Verwendung an anderer Stelle im globalen Kontext zu verhindern. (Ein Nullifizierungswert von 0,0 ist nicht immer eine gute Wahl).

NGCGUI unterstützt die Erstellung und Verkettung von mehreren Features für ein Subfile und für mehrere Subfiles. Es ist manchmal nützlich, die Reihenfolge der Unterdateien zur Laufzeit zu bestimmen, daher fügt NGCGUI einen speziellen globalen Parameter ein, der in Unterprogrammen getestet werden kann. Der Parameter heißt #<_feature:>. Sein Wert beginnt mit dem Wert 0 und wird für jedes hinzugefügte Feature inkrementiert.

Ein spezieller info-Kommentar kann überall in einer NGCGUI-kompatiblen Unterdatei eingefügt werden. Das Format ist:

Der info_text wird im oberen Bereich der Registerkarte NGCGUI in AXIS angezeigt.

Dateien, die nicht für die Verwendung als Unterdateien vorgesehen sind, können einen speziellen Kommentar enthalten, so dass NGCGUI sie automatisch mit einer entsprechenden Meldung zurückweist.

Eine optionale Bilddatei (.png,.gif,.jpg,.pgm) kann eine Unterdatei begleiten. Die Bilddatei kann zur Verdeutlichung der von der Teildatei verwendeten Parameter beitragen. Die Bilddatei sollte sich im gleichen Verzeichnis wie die Unterdatei befinden und den gleichen Namen mit einem entsprechenden Bildsuffix haben, z.B. könnte die Unterdatei example.ngc von einer Bilddatei examp.png begleitet werden. NGCGUI versucht, große Bilder durch Subsampling auf eine Größe mit einer maximalen Breite von 320 und einer maximalen Höhe von 240 Pixeln zu verkleinern.

Keine der Konventionen, die für die Herstellung einer NGCGUI-kompatiblen Subdatei erforderlich sind, schließen ihre Verwendung als allgemeine Subroutinendatei für LinuxCNC aus.

Die LinuxCNC-Distribution enthält eine Bibliothek (ngcgui_lib Verzeichnis), die sowohl Beispiel NGCGUI-kompatiblen Subdateien und Utility-Dateien, um die Funktionen von LinuxCNC Subroutinen und NGCGUI Verwendung zu veranschaulichen enthält. Eine weitere Bibliothek (gcmc_lib) bietet Beispiele für Unterprogrammdateien für den G-Code-Meta-Compiler (gcmc).

Weitere benutzerdefinierte Subroutinen finden Sie im Forum im Abschnitt zu Subroutinen.

Dateien für den Gcode-Meta-Compiler (gcmc) werden von NGCGUI gelesen und es werden Eingabefelder für die in der Datei markierten Variablen erstellt. Wenn ein Feature für die Datei fertiggestellt ist, übergibt NGCGUI die Datei als Eingabe an den gcmc-Compiler und, wenn die Kompilierung erfolgreich ist, wird die resultierende G-Code-Datei an LinuxCNC zur Ausführung gesendet. Die resultierende Datei wird als Single-File-Subroutine formatiert; .gcmc-Dateien und .ngc-Dateien können von NGCGUI gemischt werden.

Die Variablen, die für die Aufnahme in NGCGUI identifiziert wurden, werden mit Zeilen markiert, die dem gcmc-Compiler als Kommentare erscheinen.

In diesen Beispielen hat das Eingabefeld für varname1 keinen Standardwert, das Eingabefeld für varname2 hat den Standardwert 2 und das Eingabefeld für varname 3 hat den Standardwert 3 und die Bezeichnung label3 (statt varname3). Die Standardwerte müssen Zahlen sein.

Um die Änderung gültiger Zeilen in einer gcmc-Datei zu erleichtern, werden alternative Tag-Zeilenformate akzeptiert. Die alternativen Formate ignorieren abschließende Semikolons (;) und abschließende Kommentarzeichen (//). Mit dieser Bestimmung ist es oft möglich, einfach das //ngcgui: Tag zu bestehenden Zeilen in einer .gcmc-Datei hinzuzufügen.

Eine Info-Zeile, die oben auf einer Registerkarte erscheint, kann optional mit einer Zeile mit der Kennzeichnung als:

Falls erforderlich, können Optionen mit einem Zeilen-Tag an den gcmc-Compiler übergeben werden:

Die Optionen für gcmc sind mit dem Terminalbefehl verfügbar:

Ein gcmc-Programm verwendet standardmäßig den metrischen Modus. Mit der Option setting kann der Modus auf Zoll eingestellt werden:

Eine eventuell verwendete Präambel-Datei kann einen Modus (g20 oder g21) festlegen, der mit dem von einer gcmc-Datei verwendeten Modus kollidiert. Um sicherzustellen, dass der gcmc-Programmmodus in Kraft ist, fügen Sie die folgende Anweisung in die .gcmc-Datei ein:

und geben Sie den richtigen Pfad für gcmc include_files in der INI-Datei an, zum Beispiel: