Schaltbare Kinematik (switchkins)

Bei Verwendung eines identischen Kinematiktyps kann der Modulparameter Koordinaten verwendet werden, um den Gelenken Buchstaben in beliebiger Reihenfolge aus der Menge der zulässigen Koordinatenbuchstaben zuzuweisen. Beispiele:

Die Gelenkzuweisungen für Identitäts-Kinematiken bei Verwendung des Koordinatenparameters sind identisch mit denen für das Modul trivkins. Die Duplizierung von Achsenbuchstaben zur Zuweisung mehrerer Gelenke für einen Koordinatenbuchstaben ist jedoch im Allgemeinen nicht für serielle oder parallele Kinematiken (wie genserkins, pumakins, genhexkins usw.) geeignet, bei denen es keine einfache Beziehung zwischen Gelenken und Koordinaten gibt.

Die Duplizierung von Achskoordinatenbuchstaben wird in den Kinematikmodulen xyzac-trt-kins, xyzbc-trt-kins und 5axiskins (bridgemill) unterstützt. Typische Anwendungen für doppelte Koordinaten sind Gantry-Maschinen, bei denen zwei Motoren (Gelenke) für die Querachse verwendet werden.

Schaltbare Kinematiken werden mit motion.switchkins-type==0 initialisiert und implementieren ihre gleichnamige Kinematikmethode. Wenn der motion.switchkins-type-Pin nicht angeschlossen ist - wie in Legacy-Konfigurationen - ist nur der Standard-Kinematik-Typ verfügbar.

A module providing more than three kinematics types has one kinstype.is-N pin per type.

G12.1 and G13.1 ask motion for a kinstype directly and need no HAL connection at all.

A kinstype can also be selected by writing the pin motion.switchkins-type, which is sourced from an analog output pin like motion.analog-out-03 so that it can be set by M68 commands:

G12.1 P- selects a kinstype and G13.1 cancels back to identity kinematics. Which kinstype that is, the module declares (see Code Notes), not fixed to a number; on a module whose slides do not line up with its frame it is the machine frame type the module declares instead:

These codes ask motion for the kinstype directly and synchronize task and motion themselves, so no HAL connection and no separate sync command are needed. The G-code words and the motion.switchkins-type pin are both acted on when they change, so whichever asked most recently is the one in force. motion.kins-type reports what is currently selected.

The pin is deprecated, see the warning under HAL Connections.

The kinstype in force is readable in G-code as #<_kins_type>, which lets a subroutine restore whatever its caller had selected:

Selection is not cancelled by the end of a program or by an abort, so that the kinstype continues to match the position readout. A program that should leave the machine in identity kinematics ends with G13.1.

A module that declares no identity or machine frame kinstype refuses G13.1 with an error and can still be driven by number with G12.1; see Code Notes for how a module declares its types.

For tool length work there are spellings that name the kinematics by what it is rather than by number: G43.4 applies the tool length offset and switches to the kinstype the module declares its working transform, and the G49 that cancels it switches back to identity. See the G-code documentation for G43.4 and G49, and for G12.1 and G13.1, for the full description.

Writing motion.switchkins-type through an analog output pin needs the HAL connection shown above. Kinstype selection is then managed using G-code sequences like:

Diese G-Code-Befehlssequenzen werden in der Regel in G-Code-Unterprogrammen als remapped M-codes oder mit herkömmlichen M-code-Skripten implementiert.

Vorgeschlagene Codes (wie in den Sim-Konfigurationen verwendet) sind:

Herkömmliche Benutzer-M-Codes:

Neu zugeordnete M-Codes:

LinuxCNC Bahnplanung verwendet Grenzen für die Position (min, max), Geschwindigkeit und Beschleunigung für jede anwendbare Koordinaten-Buchstaben in der Konfiguration INI-Datei angegeben. Beispiel für den Buchstaben L (im Satz XYZABCUVW):

Die angegebenen INI-Datei-Grenzwerte gelten für die Standardkinematik vom Typ 0, die beim Start aktiviert wird. Beim Umschalten auf eine andere Kinematik sind diese Grenzen möglicherweise nicht anwendbar. Da jedoch beim Umschalten der Kinematik eine Synchronisierung zwischen Interpreter und Bewegung erforderlich ist, können INI-HAL-Pins verwendet werden, um Grenzwerte für einen anstehenden Kinematik-Typ festzulegen.

Die für eine gemeinsame Nummer (N) relevanten INI-HAL-Pins sind:

Die für eine Achsenkoordinate (L) relevanten INI-HAL Pins sind:

Ein vom Benutzer bereitgestellter M-code kann eine oder alle der Achsenkoordinaten Grenzen vor der Änderung der motion.switchkins-type Pin und die Synchronisierung der Interpreter und Motion-Teile von LinuxCNC ändern. Als Beispiel kann ein Bash-Skript, das halcmd aufruft, "hardcoded" werden, um eine beliebige Anzahl von HAL-Pins zu setzen:

Skripte wie dieses können als Benutzer-M-Code aufgerufen und vor dem Kinstype-Switching-Mcode verwendet werden, der den motion.switchkins-type HAL Pin aktualisiert und einen interp-motion-Sync erzwingt. Normalerweise würden für jeden kinstype (0,1,2) separate Skripte verwendet werden.

Wenn Identitätskinematiken als Mittel zur Steuerung einzelner Gelenke vorgesehen sind, kann es sinnvoll sein, die in der System-INI-Datei angegebenen Grenzwerte festzulegen oder wiederherzustellen. Ein Beispiel: Ein Roboter startet nach der Referenzfahrt mit einer komplexen (nicht identischen) Kinematik (Typ 0). Das System ist so konfiguriert, dass es auf eine Identitätskinematik (Typ1) umgeschaltet werden kann, um einzelne Gelenke mit den herkömmlichen Buchstaben aus dem Satz XYZABCUVW zu manipulieren. Die Einstellungen in der INI-Datei ([AXIS_L]) sind beim Betrieb mit Identitätskinematik (Typ1) nicht anwendbar. Um diesem Anwendungsfall gerecht zu werden, können die Benutzer-M-code-Skripte wie folgt gestaltet werden:

M129 (Switch to identity type1)

M128 (restore robot default kinematics type 0)

Wie die Limit Einstellungen in der INI-Datei gelten auch die Koordinatensystem-Offsets (G92, G10L2, G10L20, G43 usw.) im Allgemeinen nur für die Standard-Startkinematik vom Typ 0. Beim Wechsel des Kinematik-Typs kann es wichtig sein, entweder alle Offsets vor dem Wechsel zurückzusetzen oder die Offsets entsprechend den systemspezifischen Anforderungen zu aktualisieren.

Externe Offsets (gesetzt auf eine Achse (L) über axis.L.eoffset-request) bleiben bei Kinematikwechseln erhalten. Wenn ein Offset auf einer Achse vor dem Wechsel aktiv ist (sichtbar in axis.L.eoffset), behält der Trajektorienplaner dieses Offset nach dem Wechsel bei, ähnlich wie er die befohlene Position aus einem G-Code beibehält. Dies gewährleistet ein konsistentes Maschinenverhalten unabhängig von der aktiven Kinematik.

Wenn das Beibehalten des Offsets aufgrund von Achsgrenzenänderungen oder anderen Faktoren problematisch sein könnte, stellen Sie sicher, dass das eoffset vor dem Kinematikwechsel gelöscht und gegebenenfalls deaktiviert wird.

Custom kinematics can be coded and tested on Run-In-Place (RIP) builds. A template file src/emc/kinematics/userkfuncs.c is provided in the distribution. This file can be copied/renamed to a user directory and edited to supply custom kinematics with kinstype==2: the in-tree modules register its USERK_OPS as that kinstype, so the forward and inverse in the copy are what runs.

Die benutzerdefinierte Kinematikdatei kann bei rt-preempt-Implementierungen aus den Out-of-Tree-Quellen kompiliert werden oder bei rtai-Systemen durch Ersetzen der In-Tree-Vorlagendatei (src/emc/kinematics/userkfuncs.c).

Preempt-rt make Beispiel:

A complete kinematics module can be built out-of-tree with halcompile using the same switchkins implementation the in-tree modules use, so it gets the kinematics switching, the kinstype.is-N pins, the coordinates= identity mapping and the G-code and HAL controls without reimplementing any of them.

The implementation is the switchkins_core module. It provides no kinstypes of its own; it exports switchkinsInit() and the rest of the switchkins.h interface, and the identity kinematics and helpers kins_module.h declares. A module of your own includes switchkins.h, supplies switchkinsSetup() and a kinsDescribe() that replays it through switchkinsDescribeWith(), and calls switchkinsRunSetupWith() and switchkinsInit() from EXTRA_SETUP(), which halcompile runs after hal_init() and before hal_ready(). See Code Notes for the calls.

The template is src/hal/components/switchkinscomp.comp. Copy and rename it (both the file and the component name) and replace the example kinstype with the real kinematics. Start from the template, not from an in-tree component such as millturn.comp: those link the switchkins objects into the module through hal/components/Submakefile, which a halcompile build outside the tree does not do.

The HAL file loads switchkins_core ahead of the module:

A module loaded without switchkins_core ahead of it fails to load, and the error names the first switchkins or kinematics function it could not find:

A module written as a plain C file links switchkins_main.o (switchkins_main.c) for its rtapi_app_main(). That main program reads the (optional) module command-line parameters (coordinates, sparm) and passes them to the module-provided function switchkinsSetup():

which sets the configuration settings, names the geometry table and registers the kinstypes with switchkinsRegisterOps(). The pointer arguments are the older route for kinstypes 0,1,2; a module using them leaves the rest alone. switchkinsRunSetup() in switchkins_setup.c is what runs switchkinsSetup() and registers what it returned, for the main program and for kinsDescribe() alike.

A module written as a halcompile component gets rtapi_app_main() from halcompile instead. It supplies the same switchkinsSetup() and a kinsDescribe() that replays it, and from its EXTRA_SETUP() routine, which halcompile runs after hal_init() and before hal_ready(), runs switchkinsSetup() and then switchkinsInit():

switchkinsRunSetupWith() and switchkinsDescribeWith() take the module’s switchkinsSetup() as an argument, so they work from switchkins_core. switchkinsRunSetup() and the kinsDescribe() in switchkins_setup.c call the switchkinsSetup() they were linked with, and only a module built in tree links them.

Where the switchkins code comes from depends on where the component is built. Out of tree, the switchkins_core module provides it, loaded ahead of the component (see Building a switchkins module of your own). In tree, the component links the objects into itself instead, named in hal/components/Submakefile:

A switchkinsSetup() with the kinematics itself left out: the table, the ops table of the machine’s own kinstype, and the shared identity and userk ops for the other two:

For the surrounding shape, the in-tree switchkinsSetup() routines are in src/emc/kinematics: 5axiskins.c, xyzac-trt-kins.c, genserkins.c, scarakins.c and the others listed at the top of this document. None of them registers a fourth kinstype yet, so a call for one has no in-tree example to copy.