Neuzuordnung (engl. remap) für das Erweitern von G-Code

Mit "Neuzuordnung" (engl. Remapping) von Codes meinen wir eine der folgenden Optionen:

Der Satz von Codes (M,G,T,S,F), die derzeit vom RS274NGC-Interpreter verstanden werden, ist festgelegt und kann nicht durch Konfigurationsoptionen erweitert werden.

Insbesondere implementieren einige dieser Codes eine feste Abfolge von Schritten, die ausgeführt werden müssen. Während einige dieser Codes, wie M6, durch die Aktivierung oder das Überspringen einiger dieser Schritte über INI-Dateioptionen einigermaßen konfiguriert werden können, ist das Verhalten insgesamt ziemlich starr. Wenn Sie also mit dieser Situation zufrieden sind, dann ist dieser Abschnitt des Handbuchs nichts für Sie.

In vielen Fällen bedeutet dies, dass die Unterstützung von Konfigurationen oder Maschinen, die nicht "out of the box" sind, entweder umständlich oder unmöglich ist, oder dass Änderungen auf der Ebene der Sprache "C/C+\+" vorgenommen werden müssen. Letzteres ist aus guten Gründen unpopulär - die Änderung von Interna erfordert ein tiefes Verständnis der Interpreter-Interna und bringt darüber hinaus eine Reihe von Support-Problemen mit sich. Obwohl es denkbar ist, dass bestimmte Patches ihren Weg in die Hauptdistribution von LinuxCNC finden, ist das Ergebnis dieses Ansatzes ein Sammelsurium von Speziallösungen.

Ein gutes Beispiel für diesen Mangel ist die Werkzeugwechselunterstützung in LinuxCNC: Während zufällige Werkzeugwechsler gut unterstützt werden, ist es nahezu unmöglich, eine Konfiguration für eine manuelle Werkzeugwechselmaschine vernünftig zu definieren, wobei beispielsweise ein automatischer Werkzeuglängen-Offset-Schalter nach einem Werkzeugwechsel besucht und entsprechende Offsets gesetzt werden. Auch wenn ein Patch für einen sehr spezifischen Rack-Werkzeugwechsler existiert, hat er nicht seinen Weg zurück in das primäre Quellcode Repository gefunden.

Viele dieser Probleme können jedoch durch die Verwendung einer O-Wort-Prozedur anstelle eines eingebauten Codes behoben werden - wann immer der - unzureichende - eingebaute Code ausgeführt werden soll, rufen Sie stattdessen die O-Wort-Prozedur auf. Dies ist zwar möglich, aber umständlich - es erfordert eine Quelltextbearbeitung der NGC-Programme, wobei alle Aufrufe des mangelhaften Codes durch einen Aufruf einer O-Wort-Prozedur ersetzt werden müssen.

In seiner einfachsten Form ist ein remapped Code nicht viel mehr als ein spontaner Aufruf einer O-Wort-Prozedur. Dies geschieht hinter den Kulissen - die Prozedur ist auf der Konfigurationsebene sichtbar, aber nicht auf der NGC-Programmebene.

Im Allgemeinen kann das Verhalten eines umgewandelten Codes wie folgt definiert werden:

M- und G-Codes und O-Wörter Unterprogrammaufrufe haben eine recht unterschiedliche Syntax.

O-Wort-Prozeduren zum Beispiel nehmen Positionsparameter mit einer bestimmten Syntax wie folgt:

während M- oder G-Codes in der Regel erforderliche oder optionale "Wort"-Parameter enthalten. Für G76 (Einfädeln) sind beispielsweise die Wörter P, Z, I, J und K erforderlich, und optional sind die Wörter R, Q, H, E und L erforderlich.

Es reicht also nicht aus, einfach zu sagen: "Wann immer Sie auf Code X stoßen, rufen Sie bitte Prozedur Y auf" - es muss zumindest eine Überprüfung und Konvertierung der Parameter stattfinden. Dies erfordert einen "Glue Code" zwischen dem neuen Code und der entsprechenden NGC-Prozedur, der ausgeführt werden muss, bevor die Kontrolle an die NGC-Prozedur übergeben wird.

Dieser "Glue"-Code kann nicht als O-Wort-Prozedur geschrieben werden, da der RS274NGC-Sprache die introspektiven Fähigkeiten und der Zugriff auf interne Datenstrukturen des Interpreters fehlen, um den gewünschten Effekt zu erzielen. Den Glue-Code in - wiederum - C/C+\+ zu schreiben, wäre eine unflexible und daher unbefriedigende Lösung.

Um eine einfache Situation einfach und eine komplexe Situation lösbar zu machen, wird das Problem des Glue Codes als Zwischenebene wie folgt angegangen:

Die eingebetteten Python-Funktionen im Interpreter waren ursprünglich als Glue-Code gedacht, erwiesen sich aber weit darüber hinaus als sehr nützlich. Benutzer, die mit Python vertraut sind, werden es wahrscheinlich einfacher finden, remapped Codes, Glue, O-Wort-Prozeduren usw. in reinem Python zu schreiben, ohne auf die etwas schwerfällige RS274NGC-Sprache zurückgreifen zu müssen.

Viele Menschen sind mit der Erweiterung des Python-Interpreters durch C/C++-Module vertraut, und dies wird in LinuxCNC stark genutzt, um von Python-Skripten aus auf Task-, HAL- und Interpreter-Interna zuzugreifen. Python erweitern bedeutet im Grunde: Ihr Python-Skript wird so ausgeführt, als wäre es der Bestimmer und kann auf Nicht-Python-Code zugreifen, indem es Erweiterungsmodule importiert und verwendet, die in C/C+\+ geschrieben sind. Beispiele hierfür sind die LinuxCNC-Module hal, gcode und emc.

Eingebettetes Python ist ein wenig anders und weniger bekannt: Das Hauptprogramm ist in C/C geschrieben und kann Python wie ein Unterprogramm verwenden. Dies ist ein leistungsfähiger Erweiterungsmechanismus und die Grundlage für die "Skripterweiterungen", die in vielen erfolgreichen Softwarepaketen zu finden sind. Eingebetteter Python-Code kann auf "C/C"-Variablen und -Funktionen über eine ähnliche Erweiterungsmodulmethode zugreifen.

Bitte beachten Sie, dass derzeit nur einige bestehende Codes umdefiniert werden können, während es viele "freie" Codes gibt, die für eine Neuzuordnung zur Verfügung stehen. Bei der Entwicklung eines umdefinierten bestehenden Codes ist es eine gute Idee, mit einem nicht zugewiesenen G- oder M-Code zu beginnen, damit Sie sowohl ein bestehendes als auch ein neues Verhalten verwenden können. Wenn Sie fertig sind, definieren Sie den vorhandenen Code so um, dass er Ihre Konfiguration für die Neuzuordnung verwendet.

Derzeit gibt es zwei vollständige, nur in Python verfügbare Remaps, die in stdglue.py verfügbar sind:

Diese sind für die Verwendung mit Drehmaschinen gedacht. Drehbänke verwenden nicht M6, um die Werkzeuge zu indexieren, sondern den Befehl T.

Diese Neuzuordnung fügt auch Verschleißkorrekturen zur Werkzeugkorrektur hinzu, d.h. T201 würde auf Werkzeug 2 indexiert (mit der Werkzeugkorrektur von Werkzeug 2) und fügt die Verschleißkorrektur 1 hinzu. In der Werkzeugtabelle sind die Werkzeugnummern über 10000 Verschleißkorrekturen, d.h. in der Werkzeugtabelle wäre das Werkzeug 10001 die Verschleißkorrektur 1.

Hier ist, was Sie in der INI brauchen, um sie zu verwenden:

Sie müssen auch die erforderliche Python-Datei in Ihrem Konfigurationsordner hinzufügen.

Upgrade einer bestehenden Konfiguration

Beachten Sie, dass derzeit nur einige wenige bestehende Codes umdefiniert werden können, während es viele "freie" Codes gibt, die durch eine Neuzuordnung verfügbar gemacht werden könnten. Bei der Entwicklung eines umdefinierten bestehenden Codes ist es sinnvoll, mit einem nicht zugewiesenen G- oder M-Code zu beginnen, damit sowohl das bestehende als auch das neue Verhalten geübt werden kann. Wenn Sie fertig sind, definieren Sie den bestehenden Code neu, um Ihre Remapping-Einstellung zu verwenden.

Nehmen wir an, der neue Code wird durch eine NGC-Prozedur definiert und benötigt einige Parameter, von denen einige erforderlich und andere optional sein können. Wir haben die folgenden Optionen, um der Prozedur Werte zuzuführen:

Die erste Methode wird für dynamische Parameter wie Positionen bevorzugt. Sie müssen definieren, welche Wörter des aktuellen Blocks eine Bedeutung für Ihren neuen Code haben, und angeben, wie diese an die NGC-Prozedur übergeben werden. Ein einfacher Weg ist die Verwendung der argspec-Anweisung. Ein eigener Prolog könnte bessere Fehlermeldungen liefern.

Die Verwendung von INI-Datei-Variablen ist besonders nützlich, wenn Sie sich auf Einrichtungsinformationen für Ihre Maschine beziehen, z. B. auf eine feste Position wie die Position eines Werkzeuglängensensors. Der Vorteil dieser Methode ist, dass die Parameter für Ihre Konfiguration festgelegt sind, unabhängig davon, welche NGC-Datei Sie gerade ausführen.

Es ist immer möglich, auf globale Variablen zu verweisen, aber sie werden leicht übersehen.

Beachten Sie, dass es nur eine begrenzte Anzahl von Wörtern gibt, die als Parameter verwendet werden können, so dass man möglicherweise auf die zweite und dritte Methode zurückgreifen muss, wenn viele Parameter benötigt werden.

Ihr neuer Code kann erfolgreich sein oder scheitern, z. B. wenn eine ungültige Parameterkombination übergeben wird. Oder Sie entscheiden sich dafür, die Prozedur "einfach auszuführen" und die Ergebnisse zu ignorieren, in diesem Fall gibt es nicht viel Arbeit zu tun.

Epilog-Handler helfen bei der Verarbeitung der Ergebnisse von Remap-Prozeduren - siehe den Referenzabschnitt.

Ausführbare G-Code-Wörter werden in Modalgruppen eingeteilt, was auch ihr relatives Ausführungsverhalten definiert.

Wenn ein G-Code-Block mehrere ausführbare Wörter in einer Zeile enthält, werden diese Wörter in einer vordefinierten Ausführungsreihenfolge ausgeführt, nicht in der Reihenfolge, in der sie im Block erscheinen.

Wenn Sie einen neuen ausführbaren Code definieren, weiß der Interpreter noch nicht, wo Ihr Code in dieses Schema passt. Aus diesem Grund müssen Sie eine geeignete Modalgruppe wählen, in der Ihr Code ausgeführt werden soll.

Damit Sie sich ein Bild davon machen können, wie die einzelnen Teile zusammenpassen, wollen wir eine ziemlich minimale, aber vollständige Definition von neu zugeordnetem Code untersuchen. Wir wählen einen nicht zugewiesenen M-Code und fügen die folgende Option zur INI-Datei hinzu:

Zusammengefasst bedeutet dies:

Es wird erwartet, dass die Datei myprocedure.ngc im Verzeichnis [DISPLAY]NC_FILES oder [RS274NGC]SUBROUTINE_PATH existiert.

Eine ausführliche Erläuterung der REMAP (engl. für Neuzuordnung)-Parameter finden Sie im folgenden Referenzteil.

Um einen Code neu zuzuordnen, definieren Sie ihn mit der Option REMAP im Abschnitt RS274NG Ihrer INI-Datei. Verwenden Sie eine REMAP-Zeile pro neu zugeordnetem Code.

Die Syntax von REMAP lautet:

Es ist ein Fehler, den Parameter <code> wegzulassen.

Die Optionen der REMAP-Anweisung werden durch Leerzeichen getrennt. Die Optionen sind Schlüsselwort-Wert-Paare und lauten derzeit:

Die Optionen python, prolog und epilog erfordern, dass das Python-Interpreter-Plugin configured ist und dass dort entsprechende Python-Funktionen definiert sind, damit sie mit diesen Optionen angesprochen werden können.

Die Syntax für die Definition eines neuen Codes und die Umdefinierung eines bestehenden Codes sind identisch.

Beachten Sie, dass zwar viele Kombinationen von argspec-Optionen möglich sind, aber nicht alle von ihnen sinnvoll sind. Die folgenden Kombinationen sind nützliche Idiome:

Wenn Sie lediglich Python-Code aus G-Code aufrufen wollen, gibt es den etwas einfacheren Weg Aufruf von Python-Funktionen wie O-word-Prozeduren.

Die Argumentenspezifikation (Schlüsselwort argspec) beschreibt erforderliche und optionale Wörter, die an eine ngc-Prozedur übergeben werden, sowie optionale Vorbedingungen für die Ausführung dieses Codes.

Ein argspec besteht aus 0 oder mehr Zeichen der Klasse [@A-KMNP-Za-kmnp-z^>]. Er kann leer sein (wie argspec=).

Ein leeres argspec oder gar kein argspec-Argument bedeutet, dass der umgewandelte Code keine Parameter von dem Block erhält. Eventuell vorhandene zusätzliche Parameter werden ignoriert.

Beachten Sie, dass die RS274NGC-Regeln weiterhin gelten - zum Beispiel dürfen Sie Achsenwörter (z. B. X, Y, Z) nur im Zusammenhang mit einem G-Code verwenden.

Achsenwörter können auch nur verwendet werden, wenn die Achse aktiviert ist. Wenn nur XYZ aktiviert ist, kann ABCUVW nicht in argspec verwendet werden.

Die Wörter FST? haben die normalen Funktionen, sind aber als Variablen in der neu zugeordneten Funktion verfügbar. `F setzt den Vorschub, S setzt die Spindeldrehzahl, T löst die Werkzeugvorbereitungsfunktion aus. Die Wörter FST sollten nicht verwendet werden, wenn dieses Verhalten nicht erwünscht ist.

Die Wörter DEIJKPQR haben keine vordefinierte Funktion und werden für die Verwendung als argspec-Parameter empfohlen.

Standardmäßig werden Parameter als lokale benannte Parameter an eine NGC-Prozedur übergeben. Diese lokalen Parameter erscheinen als "bereits gesetzt", wenn die Prozedur mit der Ausführung beginnt, was sich von der bestehenden Semantik unterscheidet (lokale Variablen beginnen mit dem Wert 0.0 und müssen explizit mit einem Wert versehen werden).

Optionale Wortparameter können mit dem Idiom EXISTS(#<Wort>) auf ihr Vorhandensein getestet werden.

Angenommen, der Code ist wie folgt definiert

REMAP=M400 modalgroup=10 argspec=Pq ngc=m400

und m400.ngc sieht wie folgt aus:

Angenommen, der Code ist wie folgt definiert

REMAP=M410 modalgroup=10 argspec=@PQr ngc=m410

und m400.ngc sieht wie folgt aus:

Es ist möglich, neue Codes ohne ein NGC-Verfahren zu definieren. Hier ist ein einfaches erstes Beispiel, ein komplexeres Beispiel finden Sie im nächsten Abschnitt.

Angenommen, der Code ist wie folgt definiert

REMAP=G88.6 modalgroup=1 argspec=XYZp python=g886

Dies weist den Interpreter an, die Python-Funktion g886 im Modul module_basename.remap auszuführen, was etwa so aussehen könnte:

Probieren Sie dies mit aus mit: g88.6 x1 y2 z3 g88.6 x1 y2 z3 p33 (ein Kommentar hier)

Sie werden die schrittweise Einführung der eingebetteten Python-Umgebung bemerken - siehe hier für Details. Beachten Sie, dass es bei Python-Remapping-Funktionen keinen Sinn macht, Python-Prolog- oder Epilog-Funktionen zu haben, da es sich in erster Linie um die Ausführung einer Python-Funktion handelt.

Die Module interpreter und emccanon legen den größten Teil des Interpreters und einige Canon-Interna offen, so dass viele Dinge, die bisher in C/C+\+ programmiert werden mussten, nun in Python erledigt werden können.

Das folgende Beispiel basiert auf dem Skript nc_files/involute.py - aber als G-Code mit einigen Parameterextraktionen und -überprüfungen festgehalten. Es demonstriert auch den rekursiven Aufruf des Interpreters (siehe self.execute()).

Angenommen, die Definition lautet wie folgt (Anmerkung: Hier wird argspec nicht verwendet):

REMAP=G88.1 modalgroup=1 py=involute

Die unten aufgefuehrte Funktion involute in python/remap.py macht alle Wortextraktionen direkt aus dem aktuellen Block. Beachten Sie, dass Interpreterfehler in Python-Ausnahmen übersetzt werden können. Denken Sie daran, dass es sich hierbei um eine "Vorlaufzeit" handelt - Ausführungszeitfehler können auf diese Weise nicht abgefangen werden.

Die bisher beschriebenen Beispiele finden Sie in "configs/sim/axis/remap/getting-started" mit vollständigen Arbeitskonfigurationen.

Wenn Sie mit den Interna von LinuxCNC nicht vertraut sind, lesen Sie zuerst den Abschnitt How tool change currently works (dire but necessary).

Beachten Sie, dass wir bei der Neuzuordnung eines bestehenden Codes die this codes' built-in functionality des Interpreters vollständig deaktivieren.

Unser remapped Code muss also etwas mehr tun, als nur einige Befehle zu generieren, um die Maschine so zu bewegen, wie wir es wollen - er muss auch die Schritte aus dieser Sequenz wiederholen, die nötig sind, um den Interpreter und die Task bei Laune zu halten.

Dies hat jedoch keine Auswirkungen auf die Verarbeitung von Befehlen, die sich auf Werkzeugwechsel in task und iocontrol beziehen. Das heißt, wenn wir step 6b ausführen, wird dies immer noch iocontrol auslösen.

Entscheidungen, Entscheidungen:

Je nach Antwort ergeben sich vier verschiedene Szenarien:

Der Gesamtansatz für unser erstes Beispiel lautet also:

iocontrol bietet zwei HAL-Interaktionssequenzen, die wir verwenden oder nicht verwenden können:

Sie müssen entscheiden, ob die vorhandenen "iocontrol"-HAL-Sequenzen ausreichen, um Ihren Wechsler zu steuern. Vielleicht brauchen Sie eine andere Interaktionssequenz - zum Beispiel mehr HAL-Pins oder vielleicht eine komplexere Interaktion. Je nach Antwort können wir die vorhandenen iocontrol-HAL-Sequenzen weiter verwenden oder unsere eigenen definieren.

Aus Dokumentationsgründen werden wir diese iocontrol-Sequenzen deaktivieren und unsere eigenen Sequenzen erstellen - das Ergebnis wird wie die bestehende Interaktion aussehen und sich auch so anfühlen, aber jetzt haben wir die vollständige Kontrolle über sie, da sie in unserer eigenen O-Wort-Prozedur ausgeführt werden.

Wir werden also einige motion.digital-* und motion.analog-* Pins und die zugehörigen M62 … M68 Befehle verwenden, um unsere eigene HAL Interaktion in unserer O-Wort Prozedur durchzuführen, und diese werden effektiv die iocontrol tool-prepare/tool-prepared und tool-change/tool-changed Sequenzen ersetzen. Wir definieren also unsere Pins, welche die vorhandenen "iocontrol"-Pins funktionell ersetzen, und machen aus den "iocontrol"-Interaktionen eine Schleife. In unserem Beispiel werden wir die folgende Korrespondenz verwenden:

Entsprechung der "iocontrol"-Pins in den Beispielen

Nehmen wir an, Sie wollen den M6-Befehl umdefinieren und durch eine O-Wort-Prozedur ersetzen, aber ansonsten sollte alles "weiter funktionieren".

Unser O-Wort-Verfahren würde also die Schritte hier ersetzen. Wenn Sie sich diese Schritte ansehen, werden Sie feststellen, dass NGC-Code für die meisten, aber nicht für alle, verwendet werden kann. Das, was NGC nicht kann, wird in Python Prolog- und Epilog-Funktionen erledigt.

Um die Idee zu vermitteln, ersetzen wir einfach die eingebaute M6-Semantik durch unsere eigene. Sobald das funktioniert, können Sie alle Aktionen, die Sie für sinnvoll halten, in die O-Wort-Prozedur einfügen.

Wenn wir die Schritte durchlaufen, finden wir:

Wir brauchen also einen Prolog und einen Epilog. Nehmen wir an, unsere INI-Datei Beschwörung der M6-Remap sieht wie folgt aus:

Der Prolog, der die Schritte 1 und 2 abdeckt, würde also wie folgt aussehen: Wir beschließen, einige Variablen an die Remap-Prozedur zu übergeben, die dort überprüft und geändert oder in einer Nachricht verwendet werden können. Diese sind: tool_in_spindle, selected_tool (Werkzeugnummern) und ihre jeweiligen tooldata-Indizes current_pocket und selected_pocket:

Sie werden feststellen, dass die meisten Prologfunktionen sehr ähnlich aussehen:

Unsere erste Iteration der O-Wort-Prozedur ist unaufregend - wir überprüfen nur, ob wir die Parameter richtig eingegeben haben, und signalisieren den Erfolg, indem wir einen positiven Wert zurückgeben; die Schritte 3-5 werden schließlich hier behandelt (siehe here für die Variablen, die sich auf die Einstellungen der INI-Datei beziehen):

Unter der Annahme, dass die "change.ngc" erfolgreich ist, müssen wir die Schritte 6-8 abschließen:

Dieser Ersatz-M6 ist mit dem eingebauten Code kompatibel, allerdings müssen die Schritte 3-5 mit Ihrem NGC-Code ausgefüllt werden.

Wieder haben die meisten Epiloge ein gemeinsames Schema:

Beachten Sie, dass sich die Reihenfolge der Operationen geändert hat: Wir führen alles aus, was in der O-Wort-Prozedur erforderlich ist - einschließlich des Setzens/Lesens von HAL-Pins, um einen Wechsler in Gang zu setzen und einen Werkzeugwechsel zu bestätigen - wahrscheinlich mit motion.digital-* und motion-analog-* IO-Pins. Wenn wir schließlich den Befehl CHANGE_TOOL() ausführen, sind alle Bewegungen und HAL-Interaktionen bereits abgeschlossen.

Normalerweise würde iocontrol erst jetzt sein Ding machen, wie in here beschrieben. Wie auch immer, wir brauchen den HAL-Pin nicht mehr - alles, was iocontrol noch zu tun hat, ist zu akzeptieren, dass wir mit Prepare fertig sind und wechseln.

Dies bedeutet, dass die entsprechenden iocontrol-Pins keine Funktion mehr haben. Daher konfigurieren wir iocontrol so, dass es eine Änderung sofort quittiert, indem wir es wie folgt konfigurieren:

Wenn Sie aus irgendeinem Grund Tx neu zuordnen wollen (vorbereiten), müssen die entsprechenden iocontrol-Pins ebenfalls durchgeschleift werden.

Die Standard-Prologs und Epilogs, die in ncfiles/remap_lib/python-stdglue/stdglue.py zu finden sind, übergeben einige exponierte Parameter an die Remap-Prozedur.

Ein "exponierter Parameter" ist eine benannte lokale Variable, die in einer Remap-Prozedur sichtbar ist und einer interpreterinternen Variable entspricht, die für den aktuellen Remap relevant ist. Exponierte Parameter werden im jeweiligen Prolog eingerichtet und im Epilog überprüft. Sie können in der Remap-Prozedur geändert werden und die Änderung wird im Epilog aufgegriffen. Die exponierten Parameter für remappbare Built-in-Codes sind:

Wenn Sie spezielle Anforderungen an zusätzliche Parameter haben, die sichtbar gemacht werden sollen, können Sie diese einfach zum Prolog hinzufügen - praktisch alle Interpreter-Interna sind für Python sichtbar.

Denken Sie daran, dass die Neuzuordnung eines Codes normalerweise die gesamte interne Verarbeitung für diesen Code deaktiviert.

In einigen Situationen könnte es jedoch ausreichen, einige Codes um die bestehende eingebaute Implementierung von M6 zu ergänzen, z. B. einen Werkzeuglängentaster, aber ansonsten das Verhalten von M6 beizubehalten.

Da dies ein häufiges Szenario sein kann, wurde das integrierte Verhalten neu zugeordneter Codes innerhalb der Neuzuordnungsprozedur zur Verfügung gestellt. Der Interpreter erkennt, dass Sie sich auf einen neu zugeordneten Code innerhalb der Prozedur beziehen, der sein Verhalten neu definieren soll. In diesem Fall wird das eingebaute Verhalten verwendet - dies ist derzeit für den Satz aktiviert: M6, M61, T, S, F. Beachten Sie, dass andernfalls das Verweisen auf einen Code innerhalb seiner eigenen Remap-Prozedur ein Fehler wäre - eine "Remapping-Rekursion".

Ein leichtes Verdrehen eines Einbaus würde so aussehen (im Fall von M6):

Im Verzeichnis configs/sim/axis/remap/extend-builtins finden Sie eine vollständige Konfiguration, die der empfohlene Ausgangspunkt für die eigene Arbeit bei der Erweiterung eingebauter Codes ist.

Wenn Sie mit der default implementation vertraut sind, müssen Sie dies nicht tun. Aber remapping ist auch ein Weg, um Unzulänglichkeiten in der aktuellen Implementierung zu umgehen, zum Beispiel um nicht zu blockieren, bis der "tool-prepared"-Pin gesetzt ist.

Was Sie zum Beispiel tun könnten, ist: - In einem neu zugeordneten T einfach das Äquivalent des tool-prepare-Pins setzen, aber hier nicht auf tool-prepared warten. - In der entsprechenden neu zugeordneten M6, warten Sie auf das tool-prepared ganz am Anfang der O-Wort-Prozedur.

Wieder würden die iocontrol Tool-Prepare/Tool-Prepared Pins ungenutzt und ersetzt durch motion.* Pins, daher müssten diese Pins in einer Schleife sein:

Hier ist also der Aufbau für ein remapped T:

Das minimale ngc-Vorbereitungsverfahren sieht wieder so aus:

Und der Epilog:

Die Funktionen prepare_prolog und prepare_epilog sind Teil des standard glue, der von nc_files/remap_lib/python-stdglue/stdglue.py bereitgestellt wird. Dieses Modul ist dazu gedacht, die meisten Standard-Remapping-Situationen auf eine gemeinsame Weise abzudecken.

Die eingebaute Werkzeugwechselprozedur hat einige Vorkehrungen für den Umgang mit einem Programmabbruch, z.B. Drücken der Escape-Taste in Axis während eines Wechsels. Ihre neu zugewiesene Funktion verfügt über nichts dergleichen, weshalb eine explizite Bereinigung erforderlich sein könnte, wenn ein neu zugewiesener Code abgebrochen wird. Insbesondere kann eine Remap-Prozedur modale Einstellungen festlegen, die nach einem Abbruch nicht mehr aktiv sein sollen. Wenn Ihre Remap-Prozedur beispielsweise Bewegungscodes (G0,G1,G38…) enthält und die Remap-Prozedur abgebrochen wird, bleibt der letzte modale Code aktiv. Sie möchten jedoch höchstwahrscheinlich, dass jede modale Bewegung abgebrochen wird, wenn die Neuzuordnung abgebrochen wird.

Dazu verwenden Sie die Funktion [RS274NGC]ON_ABORT_COMMAND. Diese INI-Option spezifiziert einen O-Wort-Prozeduraufruf, der ausgeführt wird, wenn "task" aus irgendeinem Grund die Programmausführung abbricht. on_abort empfängt einen einzelnen Parameter, der die Ursache für den Aufruf der Abbruchprozedur angibt, die für eine bedingte Bereinigung verwendet werden könnte.

Die Gründe sind in nml_intf/emc.hh definiert

Die vorgeschlagene on_abort-Prozedur würde folgendermaßen aussehen (passen Sie sie an Ihre Bedürfnisse an):

Stellen Sie sicher, dass sich on_abort.ngc im Suchpfad des Interpreters befindet (empfohlener Ort: SUBROUTINE_PATH, um Ihr NC_FILES-Verzeichnis nicht mit internen Prozeduren zu überladen).

Die Anweisungen in dieser Prozedur stellen in der Regel sicher, dass alle Zustände nach dem Abbruch bereinigt wurden, wie z.B. das ordnungsgemäße Zurücksetzen der HAL-Pins. Ein Beispiel finden Sie unter configs/sim/axis/remap/rack-toolchange.

Beachten Sie, dass das Beenden eines remapped Codes durch Rückgabe von INTERP_ERROR aus dem Epilog (siehe vorheriger Abschnitt) auch den Aufruf der Prozedur on_abort bewirkt.

Wenn Sie in Ihrer Handler-Prozedur feststellen, dass eine Fehlerbedingung aufgetreten ist, verwenden Sie nicht M2, um Ihren Handler zu beenden - siehe oben:

Wenn die Anzeige einer Fehlermeldung und das Anhalten des aktuellen Programms ausreichen, verwenden Sie die Funktion (abort, <message>), um den Handler mit einer Fehlermeldung zu beenden. Beachten Sie, dass Sie nummerierte, benannte, INI- und HAL-Parameter im Text wie in diesem Beispiel ersetzen können (siehe auch tests/interp/abort-hot-comment/test.ngc):

Wenn eine feiner abgestufte Wiederherstellungsmaßnahme erforderlich ist, verwenden Sie die im vorherigen Beispiel beschriebene Redewendung:

Diese Fehlermeldung wird in der Benutzeroberfläche angezeigt, und wenn INTERP_ERROR zurückgegeben wird, dann wird dieser Fehler wie jeder andere Laufzeitfehler behandelt.

Beachten Sie, dass sowohl (abort,`__msg__)` als auch die Rückgabe von INTERP_ERROR aus einem Epilog dazu führt, dass ein ON_ABORT-Handler aufgerufen wird, falls er definiert ist (siehe vorheriger Abschnitt).

Ein möglicher Verwendungszweck für einen umprogrammierten S-Code wäre die "automatische Gangwahl" in Abhängigkeit von der Geschwindigkeit. Bei der Neueinstellung würde man prüfen, ob die gewünschte Geschwindigkeit mit der aktuellen Gangeinstellung erreicht werden kann, und andernfalls entsprechend schalten.

Ein Anwendungsfall für die Neuzuordnung von M0/M1 wäre die Anpassung des Verhaltens des vorhandenen Codes. So könnte es beispielsweise wünschenswert sein, Spindel, Nebel und Flutung während einer M0- oder M1-Programmunterbrechung auszuschalten und diese Einstellungen bei der Wiederaufnahme des Programms wieder einzuschalten.

Für ein vollständiges Beispiel, das genau das tut, siehe configs/sim/axis/remap/extend-builtins/, das M1 wie oben beschrieben anpasst.

An example for remapping the built in behavior of M7/M8/M9 is the option to pass optional arguments like a P word for more complex coolant control (eg through tool vs external coolant flow).

See configs/sim/axis/remap/extend-builtins/, for an example of such an extension of the built in behavior for M7,M8 and M9.

Für die Ad-hoc-Ausführung von Befehlen wurde der Python hot comment hinzugefügt. Die Python-Ausgabe geht standardmäßig nach stdout, so dass Sie LinuxCNC aus einem Terminal-Fenster starten müssen, um die Ergebnisse zu sehen, zum Beispiel im MDI-Fenster:

Beachten Sie, dass die Interpreterinstanz hier als self zur Verfügung steht, so dass Sie sie auch ausführen könnten:

Es wird erwartet, dass der Namespace wie folgt angelegt wird:

Der Interpreter ist eine bestehende C++-Klasse ("Interp"), die in "src/emc/rs274ngc" definiert ist. Konzeptionell sind alle oword.<function> und remap.<function> Python-Aufrufe Methoden dieser Interp-Klasse, obwohl es keine explizite Python-Definition dieser Klasse gibt (es handelt sich um eine Boost.Python-Wrapper-Instanz) und daher den ersten Parameter self erhalten, der für den Zugriff auf Interna verwendet werden kann.

Wenn das Modul TOPLEVEL eine Funktion __init__ definiert, wird diese aufgerufen, sobald der Interpreter vollständig konfiguriert ist (INI-Datei gelesen und Zustand mit dem Weltmodell synchronisiert).

Wenn das Modul TOPLEVEL eine Funktion __delete__ definiert, wird sie einmal aufgerufen, bevor der Interpreter heruntergefahren wird und nachdem die persistenten Parameter in der PARAMETER_FILE gespeichert worden sind.

Hinweis_ Zur Zeit funktioniert der __delete__-Handler nicht für Interpreter-Instanzen, die durch den Import des gcode-Moduls erzeugt wurden. Wenn Sie dort eine gleichwertige Funktionalität benötigen (was ziemlich unwahrscheinlich ist), ziehen Sie bitte das Python-Modul atexit in Betracht.

Diese Funktion kann verwendet werden, um alle Python-seitigen Attribute zu initialisieren, die später benötigt werden könnten, z.B. in remap- oder O-word-Funktionen, und um einen Zustand zu speichern oder wiederherzustellen, der über das hinausgeht, was PARAMETER_FILE bietet.

Wenn es Einrichtungs- oder Aufräumaktionen gibt, die nur in der milltask-Interpreter-Instanz stattfinden sollen (im Gegensatz zu der Interpreter-Instanz, die im gcode-Python-Modul sitzt und der Vorschau/Fortschrittsanzeige dient, aber sonst nichts), kann dies durch evaluating self.task getestet werden.

Ein Beispiel für die Verwendung von __init__ und __delete__ findet sich in configs/sim/axis/remap/cycle/python/toplevel.py, das Attribute initialisiert, die für die Handhabung von Zyklen in ncfiles/remap_lib/python-stdglue/stdglue.py benötigt werden (und in configs/sim/axis/remap/cycle/python/remap.py importiert wurde).

Python-Code wird in den folgenden Situationen von NGC aufgerufen:

Argumente:

Genauso wie NGC-Prozeduren Werte zurückgeben können, tun dies auch O-Word-Python-Unterprogramme. Von ihnen wird erwartet, dass sie entweder zurückgeben

Jeder andere Rückgabewerttyp löst eine Python-Ausnahme aus.

In einer aufrufenden NGC-Umgebung sind die folgenden vordefinierten benannten Parameter verfügbar:

Siehe auch tests/interp/value-returned für ein Beispiel.

Argumente sind:

Beispielaufruf:

Rückgabewerte:

Argumente sind:

Das minimale python=-Funktionsbeispiel:

Rückgabewerte:

Wenn der Handler eine "Queuebuster-Operation" (Werkzeugwechsel, Messtaster, HAL-Pin-Lesen) ausführen muss, dann soll er die Ausführung mit der folgenden Anweisung unterbrechen:

Queue-Buster unterbrechen eine Prozedur an dem Punkt, an dem eine solche Operation aufgerufen wird, so dass die Prozedur nach dem Interpreter synch() neu gestartet werden muss. Wenn dies geschieht, muss die Prozedur wissen, ob sie neu gestartet wurde und wo sie fortfahren soll. Die Python-Generator-Methode wird verwendet, um den Neustart einer Prozedur zu bewältigen.

Dies zeigt die Fortsetzung des Anrufs mit einem einzigen Ausgangspunkt:

NGC-Code wird von Python ausgeführt, wenn

Der Prolog-Handler ruft den Handler nicht auf, sondern bereitet dessen Aufrufumgebung vor, indem er z. B. vordefinierte lokale Parameter einrichtet.

Konzeptionell werden ein Prolog und ein Epilog auf der gleichen Aufrufebene wie die O-Wort-Prozedur ausgeführt, d. h. nach dem Aufbau des Unterprogrammaufrufs und vor dem Ende des Unterprogramms oder der Rückkehr.

Das bedeutet, dass jede lokale Variable, die in einem Prolog erstellt wird, eine lokale Variable in der O-Wort-Prozedur ist, und dass alle lokalen Variablen, die in der O-Wort-Prozedur erstellt werden, immer noch zugänglich sind, wenn der Epilog ausgeführt wird.

Das Array "self.params" dient zum Lesen und Setzen von nummerierten und benannten Parametern. Wenn ein benannter Parameter mit _ (Unterstrich) beginnt, wird angenommen, dass er ein globaler Parameter ist; wenn nicht, ist er lokal für die aufrufende Prozedur. Auch nummerierte Parameter im Bereich 1..30 werden wie lokale Variablen behandelt; ihre ursprünglichen Werte werden bei Return/Endsub einer O-Wort-Prozedur wiederhergestellt.

Hier ist ein Beispiel für umgewandelten Code, der das Einfügen und Extrahieren von Parametern in/aus der O-Wort-Prozedur demonstriert:

Die Funktion self.params() gibt eine Liste aller derzeit definierten Variablennamen zurück. Da myname lokal ist, verschwindet es nach Beendigung des Epilogs.

Sie können den Interpreter aus dem Python-Code wie folgt rekursiv aufrufen:

Beispiele:

Sie sollten prüfen, ob der Rückgabewert < INTERP_MIN_ERROR ist. Wenn Sie viele execute()-Anweisungen verwenden, ist es wahrscheinlich einfacher, eine InterpreterException wie unten beschrieben abzufangen.

CAUTION:

wenn interpreter.throw_exceptions ungleich Null ist (Standardwert 1) und self.execute() einen Fehler zurückgibt, wird die Ausnahme InterpreterException ausgelöst. InterpreterException hat die folgenden Attribute:

Fehler können auf die folgende Python-Weise abgefangen werden:

Die Kanonebene besteht praktisch nur aus freien Funktionen. Beispiel:

Die eigentlichen Kanon-Funktionen sind in src/emc/nml_intf/canon.hh deklariert und in src/emc/task/emccanon.cc implementiert. Die Implementierung der Python-Funktionen ist in src/emc/rs274ncg/canonmodule.cc zu finden.

Die folgenden Module sind bereits integriert:

Diese verpacken ein NGC-Verfahren für Tx Tool Prepare.

Die folgenden Parameter werden für das NGC-Verfahren sichtbar gemacht:

Wenn die Werkzeugnummer Null angefordert wird (d.h. Werkzeug entladen), wird die entsprechende Tasche als -1 übergeben.

Es ist ein Fehler, wenn:

Beachten Sie, dass Werkzeug und Platznummer identisch sind und die Platznummer aus der Werkzeugtabelle ignoriert wird, wenn Sie nicht den Parameter [EMCIO] RANDOM_TOOLCHANGER=1 setzen. Dies ist derzeit eine Einschränkung.

Diese schließen ein NGC-Verfahren für den M6-Werkzeugwechsel ein.

Anschließend werden die folgenden Parameter in das NGC-Verfahren exportiert:

Diese umhüllen eine NGC-Prozedur, so dass sie als Zyklus fungieren kann, was bedeutet, dass der Bewegungscode nach Abschluss der Ausführung erhalten bleibt. Wenn die nächste Zeile nur Parameterwörter enthält (z. B. neue X- und Y-Werte), wird der Code erneut ausgeführt, wobei die neuen Parameterwörter in die Menge der beim ersten Aufruf angegebenen Parameter eingefügt werden.

Diese Routinen sind so konzipiert, dass sie in Verbindung mit einem argspec=<words>-Parameter arbeiten. Dies ist zwar einfach zu verwenden, aber in einem realistischen Szenario würden Sie argspec vermeiden und den Block manuell gründlicher untersuchen, um bessere Fehlermeldungen zu erhalten.

Der Vorschlag für argspec lautet wie folgt:

Auf diese Weise kann cycle_prolog die Kompatibilität der im Block angegebenen Achsenwörter ermitteln (siehe unten).

TBD

TBD

TBD

Normalerweise wird eine O-Wort-Prozedur mit Positionsparametern aufgerufen. Dieses Schema ist sehr einschränkend, insbesondere wenn optionale Parameter vorhanden sind. Daher wurde die Aufrufkonvention erweitert, um etwas zu verwenden, das dem Python-Modell für Schlüsselwortargumente sehr ähnlich ist.

Siehe LINKTO G-Code/Main Subroutinen: sub, endsub, return, call.

Neu zugeordnete Codes können wie Prozeduraufrufe verschachtelt werden, d. h. ein neu zugeordneter Code, dessen NGC-Prozedur auf einen anderen neu zugeordneten Code verweist, wird korrekt ausgeführt.

Die maximale Verschachtelungsebene, die neu zugeordnet werden kann, beträgt derzeit 10.

Sequenznummern werden wie bei O-Wort-Aufrufen propagiert und wiederhergestellt. Siehe tests/remap/nested-remaps/word für den Regressionstest, der die Verfolgung der Sequenznummer bei verschachtelten Remaps drei Ebenen tief zeigt.

Die folgenden Flags sind für das Mapping und die Ausführung in Python relevant:

oder diese Flags in die ‚[EMC]DEBUG‘-Variable nach Bedarf. Eine aktuelle Liste der Debug-Flags finden Sie in src/emc/nml_intf/debugflags.h.

Das Debuggen von eingebettetem Python-Code ist schwieriger als das Debuggen von normalen Python-Skripten, und es gibt nur ein begrenztes Angebot an Debuggern. Eine funktionierende Lösung auf Open-Source-Basis ist die Verwendung der Eclipse IDE und des PydDev Eclipse Plug-ins und seiner Remote-Debugging-Funktion.

Um diesen Ansatz zu verwenden:

Um die letzten beiden Schritte abzudecken: die o<pydevd>-Prozedur hilft, aus dem MDI-Modus in den Debugger zu gelangen. Siehe auch die Funktion call_pydevd in util.py und ihre Verwendung in remap.involute, um einen Haltepunkt zu setzen.

Hier ist ein Bildschirmfoto von Eclipse/PyDevd beim Debuggen der obigen involute-Prozedur:

Siehe den Python-Code in configs/sim/axis/remap/getting-started/python für Details.

Der derzeitige Satz von bestehenden Codes, die neu definiert werden können, ist:

Beachten Sie, dass die Verwendung von M61 derzeit die Verwendung von "iocontrol-v2" erfordert.

Derzeit nicht zugewiesene G-Codes (für remapping) müssen aus den leeren Bereichen der folgenden Tabellen ausgewählt werden. Alle aufgelisteten G-Codes sind bereits in der aktuellen Implementierung von LinuxCNC definiert und kann nicht verwendet werden, um neue G-Codes zu remappen. (Entwickler, die neue G-Codes zu LinuxCNC hinzufügen werden ermutigt, auch ihre neuen G-Codes zu diesen Tabellen hinzufügen.)

Diese M-Codes sind derzeit undefiniert in der aktuellen Implementierung von LinuxCNC und können verwendet werden, um neue M-Codes zu definieren. (Entwickler, die neue M-Codes in LinuxCNC definieren, werden aufgefordert, sie aus dieser Tabelle zu entfernen.)

Alle M-Codes von M100 bis M199 sind bereits benutzerdefinierte M-Codes, die nicht neu zugeordnet werden sollten.

Alle M-Codes von M200 bis M999 sind für die Neuzuordnung verfügbar.

Konzeptionell besteht der Zustand des Interpreters aus Variablen, die in die folgenden Kategorien fallen:

Die task Teil von LinuxCNC ist verantwortlich für die Koordinierung der tatsächlichen Maschine Befehle - Bewegung, HAL Interaktionen und so weiter. Er verarbeitet nicht selbst die RS274NGC-Sprache. Um dies zu tun, ruft task den Interpreter auf, um den nächsten Befehl zu analysieren und auszuführen - entweder von MDI oder der aktuellen Datei.

Die Interpreter-Ausführung erzeugt kanonische Maschinenoperationen, die tatsächlich etwas bewegen. Diese werden jedoch nicht sofort ausgeführt, sondern in eine Warteschlange gestellt. Die eigentliche Ausführung dieser Codes geschieht in der task Teil von LinuxCNC: Kanon Befehle sind aus dieser Interpreter Warteschlange gezogen, und ausgeführt, was zu tatsächlichen Bewegungen der Maschine führt.

Das bedeutet, dass der Interpreter in der Regel der tatsächlichen Ausführung von Befehlen weit voraus ist - das Parsen des Programms kann durchaus abgeschlossen sein, bevor eine spürbare Bewegung einsetzt. Dieses Verhalten wird als "Read-ahead" bezeichnet.

Um die kanonischen Maschinenoperationen beim Vorlesen im Voraus zu berechnen, muss der Interpreter in der Lage sein, die Maschinenposition nach jeder Zeile G-Code vorherzusagen, und das ist nicht immer möglich.

Schauen wir uns ein einfaches Beispielprogramm an, das relative Züge ausführt (G91), und nehmen wir an, die Maschine startet bei x=0,y=0,z=0. Relative Züge bedeuten, dass das Ergebnis des nächsten Zuges von der Position des vorherigen abhängt:

Hier kann der Interpreter die Maschinenpositionen für jede Linie eindeutig vorhersagen:

Nach N20: x=10 y=-5 z=20; nach N30: x=10 y=15 z=15; nach N40: x=10 y=15 z=45 und kann so das gesamte Programm parsen und kanonische Operationen im Voraus erzeugen.

Ein vollständiges Vorlesen ist jedoch nur möglich, wenn der Interpreter die Auswirkungen auf die Position für jede Zeile im Programm im Voraus vorhersagen kann. Schauen wir uns ein modifiziertes Beispiel an:

Um die Bewegung in N90 vorauszuberechnen, müsste der Interpreter wissen, wo sich die Maschine nach Zeile N80 befindet - und das hängt davon ab, ob der Probe-Befehl erfolgreich war oder nicht, was erst nach der tatsächlichen Ausführung bekannt ist.

Daher sind einige Operationen mit einer weiteren Vorauslesefunktion unvereinbar. Diese werden queue busters genannt und sind:

Wann immer der Interpreter auf einen Queue-Buster stößt, muss er das Vorlesen stoppen und warten, bis das entsprechende Ergebnis vorliegt. Dies funktioniert folgendermaßen:

Ein oder mehrere "Wörter" können in einem NGC-"Block" vorhanden sein, wenn sie kompatibel sind (einige schließen sich gegenseitig aus und müssen in verschiedenen Zeilen stehen). Das Ausführungsmodell schreibt jedoch eine strenge Reihenfolge der Ausführung von Codes vor, unabhängig von ihrem Auftreten in der Quellzeile (G-code Ausführungs-Reihenfolge).

Sobald eine Zeile gelesen wird (entweder im MDI-Modus oder aus der aktuellen NGC-Datei), wird sie geparst, und Flags und Parameter werden in einem "struct block" (struct _setup, member block1) gesetzt. Diese Struktur enthält alle Informationen über die aktuelle Quellzeile, jedoch unabhängig von der Reihenfolge der Codes in der aktuellen Zeile: Solange mehrere Codes kompatibel sind, führt jede Quellreihenfolge dazu, dass die gleichen Variablen im Strukturblock gesetzt werden. Direkt nach dem Parsen werden alle Codes eines Blocks auf Kompatibilität geprüft.

Nach erfolgreichem Parsen wird der Block mit execute_block() ausgeführt, wobei die verschiedenen Elemente in der Reihenfolge ihrer Ausführung behandelt werden.

Wird ein "Queue Buster" gefunden, wird ein entsprechendes Flag im Interpreterstatus gesetzt (toolchange_flag, input_flag, probe_flag), und der Interpreter gibt einen INTERP_EXECUTE_FINISH-Rückgabewert zurück, der dem Aufrufer (task) signalisiert, dass die Vorauslesung vorerst gestoppt und neu synchronisiert wird. Werden nach der Ausführung aller Elemente keine Queue-Buster gefunden, wird INTERP_OK zurückgegeben, was bedeutet, dass die Vorauslesung fortgesetzt werden kann.

Wenn das Lesen nach der Synchronisierung (via der Funktion synch() ) fortgesetzt wird, beginnt task wieder mit der Ausführung von read()-Operationen des Interpreters. Beim nächsten Lesevorgang werden die oben genannten Flags überprüft und die entsprechenden Variablen gesetzt (da gerade eine Synchronisation ausgeführt wurde, sind die Werte jetzt aktuell). Das bedeutet, dass der nächste Befehl bereits in dem richtig gesetzten Variablenkontext ausgeführt wird.

O-Wort-Prozeduren erschweren die Handhabung von Warteschlangen-Bustern ein wenig. Ein Queue Buster könnte irgendwo in einer verschachtelten Prozedur gefunden werden, was zu einem halbfertigen Prozeduraufruf führt, wenn INTERP_EXECUTE_FINISH zurückgegeben wird. Task stellt sicher, dass das Weltmodell synchronisiert wird und setzt das Parsen und die Ausführung fort, solange noch eine Prozedur ausgeführt wird (call_level > 0).

Die Aktionen, die in LinuxCNC passieren, sind ein bisschen kompliziert, aber es ist notwendig, um die allgemeine Idee zu bekommen, was derzeit passiert, bevor Sie sich auf den Weg machen, um diese Abläufe an Ihre eigenen Bedürfnisse anzupassen.

Beachten Sie, dass durch die Neuzuordnung (engl. remapping) eines vorhandenen Codes die gesamte interne Verarbeitung dieses Codes vollständig deaktiviert wird. Das bedeutet, dass Sie über Ihr gewünschtes Verhalten hinaus (das wahrscheinlich durch ein NGC O-Word oder eine Python-Prozedur beschrieben wird) die internen Aktionen des Interpreters nachbilden müssen, die zusammen eine vollständige Ersetzung des bestehenden Codes ergeben. Der Prolog- und Epilog-Code ist der richtige Ort, um dies zu tun.

Mehrere Prozesse sind an Werkzeuginformationen "interessiert": task und sein Interpreter, sowie die Benutzeroberfläche. Außerdem der halui-Prozess.

Die Werkzeuginformationen werden in der Struktur "emcStatus" gespeichert, die von allen Beteiligten gemeinsam genutzt wird. Eines ihrer Felder ist das Array "toolTable", das die Beschreibung enthält, wie sie aus der Werkzeugtabellendatei geladen wurde (Werkzeugnummer, Durchmesser, vorderer und hinterer Winkel und Ausrichtung für Drehmaschinen, Werkzeugkorrektur-Informationen).

Die maßgebliche Quelle und der einzige Prozess, der tatsächlich Werkzeuginformationen in dieser Struktur "festlegt", ist der Prozess "iocontrol". Alle anderen Prozesse konsultieren diese Struktur lediglich. Der Interpreter besitzt eine lokale Kopie der Werkzeugtabelle.

Wer neugierig ist, kann die aktuelle emcStatus-Struktur mit Python statements abrufen. Die Wahrnehmung des Interpreters über das aktuell geladene Werkzeug wird beispielsweise aufgerufen durch:

Sie müssen LinuxCNC von einem Terminal-Fenster aus gestartet haben, um die Ergebnisse zu sehen.

Der Interpreter wertet lediglich den Parameter toolnumber aus, sucht den entsprechenden tooldata-Index, speichert ihn für später in der Variablen selected_pocket und stellt einen Kanon-Befehl (SELECT_TOOL) in die Warteschlange. Siehe Interp::convert_tool_select in src/emc/rs274/interp_execute.cc.

Wenn task dazu kommt, ein SELECT_TOOL zu bearbeiten, sendet es eine EMC_TOOL_PREPARE Nachricht an den iocontrol Prozess, der die meisten werkzeugbezogenen Aktionen in LinuxCNC bearbeitet.

In der derzeitigen Implementierung wartet task tatsächlich darauf, dass iocontrol die Positionierung des Wechslers abschließt, was m.E. nicht notwendig ist, da es die Idee zunichte macht, dass die Vorbereitung des Wechslers und die Ausführung des Codes parallel laufen können.

Wenn iocontrol den Befehl "Select Pocket" sieht, führt es das entsprechende HAL-Pin-Wackeln aus - es setzt den "tool-prep-number"-Pin, um anzuzeigen, welches Werkzeug als nächstes an der Reihe ist, hebt den "tool-prepare"-Pin an und wartet darauf, dass der "tool-prepared"-Pin auf High geht.

Wenn der Wechsler mit der Meldung "tool-prepared" antwortet, betrachtet er die Vorbereitungsphase als abgeschlossen und signalisiert an task, die Aufgabe fortzusetzen. Auch dieses "Warten" ist meiner Meinung nach nicht unbedingt erforderlich.

Siehe die Python-Funktionen prepare_prolog und prepare_epilog in `nc_files/remap_lib/python-stdglue/stdglue.py `.

Sie müssen dies vollständig verstehen, bevor Sie es anpassen können. Es ist sehr wichtig für das Schreiben eines Prolog- und Epilog-Handlers für einen neu zugeordneten M6. Das Remapping eines bestehenden Codes bedeutet, dass Sie die internen Schritte, die normalerweise durchgeführt werden, deaktivieren und sie so weit wie nötig für Ihre eigenen Zwecke replizieren.

Auch wenn Sie mit C nicht vertraut sind, empfehle ich Ihnen, sich den Code von "Interp::convert_tool_change" in "src/emc/rs274/interp_convert.cc" anzusehen.

Wenn der Interpreter ein M6 sieht, wird er:

Auch hier nicht viel mehr, als die Kontrolle an iocontrol zu übergeben, indem man ihm eine EMC_TOOL_LOAD Nachricht sendet und zu warten, bis iocontrol sein Ding gemacht hat.

Im letzten Schritt werden die Tooltable-Einträge in der emcStatus-Struktur gesetzt. Die tatsächlich durchgeführte Aktion hängt davon ab, ob die INI-Option RANDOM_TOOLCHANGER gesetzt wurde, aber am Ende des Prozesses spiegelt toolTable[0] das aktuell in der Spindel befindliche Werkzeug wider.

wenn dies geschehen ist: