Перемикальна кінематика (перемикачі)

Під час використання кінематики типу identity параметр модуля coordinates може бути використаний для призначення літер суглобам у довільному порядку з набору дозволених літер координат. Приклади:

Спільні завдання, передбачені для кінематики identity при використанні параметра координат, ідентичні тим, що передбачені для модуля trivkins. Однак дублювання літер осей для призначення декількох з’єднань для літери координати, як правило, не застосовується для послідовної або паралельної кінематики (такої як genserkins, pumakins, genhexkins тощо), де немає простого взаємозв’язку між з’єднаннями та координатами.

Дублювання літер координат осей підтримується в кінематичних модулях xyzac-trt-kins, xyzbc-trt-kins та 5axiskins (bridgemill). Типовими застосуваннями для дублювання координат є портальні верстати, де два двигуни (з’єднання) використовуються для поперечної осі.

Перемикається кінематика ініціалізується з motion.switchkins-type==0, реалізуючи однойменний метод кінематики. Якщо контакт motion.switchkins-type не підключений, як у старих конфігураціях, доступний тільки тип кінематики за замовчуванням.

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:

Ці послідовності команд G-коду зазвичай реалізуються в підпрограмах G-коду як перепризначені M-коди або за допомогою звичайних скриптів M-коду.

Рекомендовані коди (як використовуються в конфігураціях SIM-карти):

Звичайні M-коди користувача:

Перепризначені M-коди:

Планування траєкторії LinuxCNC використовує обмеження для положення (min, max), швидкості та прискорення для кожної відповідної літери координати, зазначеної в конфігураційному файлі INI. Приклад для літери L (у наборі «XYZABCUVW»):

Вказані обмеження файлу INI застосовуються до типу кінематики за замовчуванням типу 0, який активується під час запуску. Ці обмеження можуть не застосовуватися при переході на альтернативну кінематику. Однак, оскільки при переході на іншу кінематику необхідна синхронізація інтерпретатора та руху, для налаштування обмежень для очікуваного типу кінематики можна використовувати контакти INI-HAL.

Відповідні контакти INI-HAL для номера з’єднання (N):

Відповідні контакти INI-HAL для координати осі (L):

M-код, наданий користувачем, може змінювати будь-які або всі межі координат осей перед зміною руху.switchkins-type pin і синхронізацією інтерпретатора та частин руху LinuxCNC. Наприклад, скрипт bash, що викликає halcmd, може бути «жорстко закодований» для встановлення будь-якої кількості контактів HAL:

Такі скрипти можна викликати як M-код користувача і використовувати до M-коду перемикання kins, який оновлює HAL-контакт motion.switchkins-type і примусово виконує синхронізацію interp-motion. Зазвичай для кожного типу kinstype (0,1,2) використовуються окремі скрипти.

Коли кінематика ідентичності надається як засіб управління окремими шарнірами, може бути зручно встановити або відновити обмеження, як зазначено в системному файлі INI. Наприклад, робот починає роботу зі складною (неідентичною) кінематикою (тип 0) після повернення в початкове положення. Система налаштована таким чином, що її можна переключити на ідентичну кінематику (тип 1) для маніпулювання окремими суглобами за допомогою звичайних літер з набору «XYZABCUVW». Налаштування файлу INI ([AXIS_L]) не застосовуються при роботі з ідентичною кінематикою (тип 1). Для вирішення цього випадку використання скрипти M-коду користувача можна розробити наступним чином:

M129 (Switch to identity type1)

M128 (restore robot default kinematics type 0)

Як і налаштування обмежень файлу INI, зміщення координатної системи (G92, G10L2, G10L20, G43 тощо) зазвичай застосовуються лише для типу кінематики за замовчуванням 0. При перемиканні типів кінематики може бути важливо або скинути всі зміщення перед перемиканням, або оновити зміщення відповідно до вимог конкретної системи.

Зовнішні зміщення (встановлені на вісь (L) через axis.L.eoffset-request) зберігаються під час перемикання кінематики. Коли зміщення активне на осі перед перемиканням (видиме в axis.L.eoffset), планувальник траєкторії зберігає те саме зміщення після перемикання, подібно до того, як він зберігає задане положення з G-коду. Це забезпечує стабільну роботу машини незалежно від активної кінематики.

Якщо підтримка зміщення буде проблемою через зміни обмежень осей або інші проблеми, обов’язково очистіть і, можливо, вимкніть eoffset, перш ніж перемикати кінематику.

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.

Файл користувацької кінематики можна скомпілювати з позадеревних джерел для реалізацій rt-preempt або шляхом заміни шаблонного файлу в дереві (src/emc/kinematics/userkfuncs.c) для систем rtai.

Приклад створення Preempt-rt:

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.