Или осенний калейдоскоп из Хомов, Хард\Софт лимитов, Аварийной остановки и неравной борьбы с Матчем...
Тема с Домами и Лимитами для меня получилась достаточно неоднозначная.
У самого опыта нет пока никакого, на форумах мнения кардинально различаются, суждения тоже, и варьируются от категоричных до очень осторожных.
Документация на сам Матч по мнению одних более чем исчерпывающая, по моему же мнению более чем спартанская.
Чем больше читал документацию, мнений на разных форумах, тем больше каши и тумана образовывалось в голове.
Перехода количества прочитанного в качество понимания не произошло, вопреки мнениям философов.
Решил проверить еще одно философское утверждение: "Практика - критерий Истины".
Что мы имеем:
- Монстрика переехавшего на новое место жительства.
Путем суммирования всех плюсов и минусов он все-таки оказался на даче.
Если в ближайшее время ничего не изменится, ему предстоит готовиться к первой в его жизни зимовке в суровых условиях.
А мне, как приложившему некоторые усилия к его появлению, изучать темы о консервации оборудования.
- Ненастроенный (в смысле рассматриваемого вопроса) Матч (лицензия, русифицированный).
- Моросящий осенний дождь за окном, препятствующий работам на свежем воздухе и дающий возможность сделать попытку разобраться в теме.
Это из объективных предпосылок.
Из субъективных:
Переводная документация на Матч + куча разнообразных схем/рекомендаций подключений с форумов
(извиняюсь перед владельцами англоязычного Матча, у меня русифицированный и я не смогу сделать
двойные скриншоты, но там всего два пункта меню, надеюсь это не будет непреодолимой преградой для
нахождения аналогов).
Куча проводов и разъемов, позволяющая реализовать самые разнообразные фантазии в несколько движений.
Все подключения сделаны разъемными из других соображений (я рассказывал об этом чуть ранее в своей теме о монстрике),
для данного эксперимента это оказалось просто удачным стечением обстоятельств.
Что хочу:
Получить для себя ответ на вопрос:
Нужны ли мне Хомы и Лимиты или зря заморачивался?
Если все-таки нужны, то какую схему подключения выбрать?
******************************************************************
Занимательно, но когда проектировал/собирал монстрика эти вопросы даже не ставились под сомнение: однозначно нужно.
По Хомам - ищем нулевой отсчет. Лимиты - предохраняют выезд за физические возможности монстрика.
На каждую ось было установлено по два индуктивных датчика.
Один из которых играет совмещенную роль - он "Домашний" при поиске нуля и он же "Ограничитель" во всех остальных случаях.
Второй - "Ограничитель" в "чистом виде".
Поэтому в моем случае семь претендентов (по два датчика на каждой из трех осей + Аварийная остановка) на пять входов (физическое ограничение одного порта).
Понятно, что надо было как-то выходить из несоответствия требуемого количества входов с действительным их наличием,
и в какой-то момент была реализована следующая схема подключения всего этого :
Схема была выбрана именно такой на основании рекомендации из документации на Матч:
Все пределы могут быть настроены на использование одной "ИЛИ", и подведены к одному входу концевика.
Тогда для каждой оси можно назначить собственный выключатель Баз, подключенный к соответственному вводу.
Так что станок с тремя осями потребует только четыре входа.
Ну и пятый вход у меня занят Аварийной остановкой.
Позже я узнал, что многие объединяют Аварийную остановку и "Ограничители", но к этому моменту уже все было распаяно.
С одной стороны все пять входов заняты, с другой стороны в ближайшей перспективе больше входов вроде как и не нужно.
Пока ничего менять стал, просто из-за отстутствия необходимости.
Схема станка на всякий случай:
Может я где забуду что-то уточнить...
*******************************************************************
Далее все "Задания №", это я так, сам для себя, сочинял задания и пытался реализовать.
Пунктов меню задействовалось в основном всего два:
Меню Конфигурация --> Порты и пины --> Сигналы входа
и
Меню Конфигурация --> Базы/Границы.
Часть первая.
Паутина. Попытка распутать.
Часть вроде и не Софт, но и не совсем Хард.
Провода, разъемы, датчики, схемы...
Задание № 1
Настроить датчики, хотя бы на одной оси, хоть как-нибудь.
Для выполнения этого задания выбрал ось Z (как самую короткую).
На время экспериментов сильно упростил схему подключений.
"Дом" и "Лимит" оси на одном пине. Все оси, кроме Z отключены.
Возможность подобного подключения (оба датчика по одной оси на один вход) проскальзывала в описании Матча.
Первая часть задания:
Попытаюсь настроить "Дом".
Направление и какой из двух датчиков станет "Домом" пока безразлично.
Пусть хоть кто-то из них откликнется, потом поменяю на нужный.
Меню Конфигурация --> Порты и пины --> Сигналы входа
Скорости подъезда к базе и прочее пока не меняю.
Меню Конфигурация --> Базы/Границы.
При попытке найти "Базу" все происходит как описано:
Матч подъезжает к датчику, датчик срабатывает.
Матч отъезжает от "Базы", датчик гаснет.
Все останавливается.
0 по Z найден!!!
Меняем направление поиска датчика.
Честно находит Базу с другой стороны.
Базу настроить получилось!!!
К сожалению сильно пасмурно, видео снять не получется - темновато и для фотика, и для телефона (только фотки со вспышкой).
Вторая часть задания:
Лимиты надо настраивать или они сработают и так?
Схема подключения прежняя. Управление с клавиатуры.
Эксперимент на нижнем датчике. На нем у меня "настраиваемый" ограничитель из тонкой гибкой пластинки.
Если что, согнется пластинка, "удара" о механический ограничитель не будет.
Руку держу на Аварийной остановке (в смысле на клавише "Esc").
Чуда не произошло.
Датчик сработал. Матч на него не обратил внимания, двигает ось дальше.
Пластинка согнута. Аварийная остановка.
Значит датчики Лимитов надо где-то прописывать.
В документации было что-то о ОСЬ++ и ОСЬ--.
Прописываем параметры, благо вариантов не так много:
Ура!!! Все заработало!!!
Датчик сработал, согласно своему ТТХ, около 4мм до железной пластины.
Происходит аварийная остановка движения уже самим Матчем.
Снимаем программно аварию с датчика (нажимаем на сброс).
Аккуратно отъезжаем в другую сторону, и едем до противоположного датчика.
Датчик с другой стороны тоже вполне себе срабатывает.
"Дом" и "Лимиты" настроены.
Задание № 2
Меняю схему подключения на свою, только пока в сильно упрощенном варианте.
Т.е. разношу датчики Дома и Лимита на разные пины.
Единственное изменение, которое приходит в голову до эксперимента:
- направление поиска датчика Дома имеет значение.
Если будем искать в другую сторону, то выйдем на аварийную становку из-за сработавшего датчика "Лимита".
Но на практике... Оба-на. Как бы не так:
Датчик "Лимита" сработал, но Матч на него не отреагировал.
Хорошо, что я сегодня на кнопке Аварийной остановки просто дежурю.
Т.е. получается, что в Матче поиск "Дома" имеет более высокий приоритет, чем аварийная ситуация в виде сработавшего ограничителя!!!
Перепрописываю в настройках датчики наоборот.
Если первый раз так получилось случайно - не перенастроил и искал дом не там, то теперь, поменяв датчики местами делаю это специально.
Результат тот же. Наезд на датчик "Лимита".
Обращаемся к документации. После долгих поисков нахожу нужное:
Во время Принятия концевики не работают.
Скромно так написано, без выделения, в общем я, ища СПЕЦИАЛЬНО, эту фразу ЕЛЕ НАШЕЛ.
(Это, кстати, один из "кирпичиков", из-за которых я считаю документацию на Матч более чем спартанской, ну или у меня такой вариант документации).
На самом деле эта фраза означает:
При поиске "Дома" Матч ИГНОРИРУЕТ сигналы датчиков "Лимита", висящих на пинах, отличных от пина, на котором висит датчик "Дома".
Приоритет, такой рабочей в общем-то операции, как поиск "Дома" оказался выше, чем приоритет аварийной (в документации выход за границы
и сработавший датчик "Лимита" считается аварийной ситуацией).
После исправления этой ошибки в настройках все заработало и на разнесенных пинах "Дома" и "Лимитов".
Вывод из первых двух заданий:
Кто разносит датчики "Дома" и "Лимитов" по одной оси на разные пины, делайте первоначальные настройки с осторожностью и дежурьте около кнопки "Аварийной остановки".
Как результат первых двух заданий:
Оба датчика на оси Z настроены, как мне хотелось.
При Базировании верхний датчик определяется как "База" и по нему выставляется аппаратный ноль.
Затем, при работе оба датчика работают как аппаратные ограничители движения.
Остальные оси настраиваются, наверняка, аналогично.
Задание № 3
Теперь буду экспериментировать с вариантами объединения датчиков.
Цель - просто поиграться с объединениями различных датчиков в различные комбинации и посмотреть, что получиться.
Вариант 1.
Подключаем ВСЕ датчики на один пин.
Этой части сначала в планах не было. Она появилась после выполнения второго Задания.
Аварийная остановка в предыдущих заданиях осуществлялась с клавиатуры, клавишой "Esc".
Здесь хочу проверить чей приоритет выше: датчика "E-Stop" или поиска базы.
Умом я вроде понимаю, что датчик "E-Stop" обязан обладать наивысшим приоритетом,
но после результатов второго задания хочется в этом убедиться.
Убедился. У E-Stop приоритет выше.
Причем попадаем в замкнутый круг:
Пока активен сигнал E-Stop не можем съехать с датчика. А снять E-Stop тоже не можем
(если сработал не сам E-Stop, а датчик лимита), так как он на одном пине со сработавшим датчиком.
С этой стороны вроде как все логично.
Получился следующий порядок приоритетов:
Высший приоритет - E-Stop.
Следующий - Поиск "Базы".
Затем - "Лимиты".
Проводил эксперимент в попытке выяснить кто круче: Хард или Софт лимит?
Но оказалось все просто - кто раньше встал, того и тапочки.
Или кто раньше попался по пути, тот и лимит. Поэтому третья строка приоритетов без уточнений.
И как результат - получается как минимум два занятых входа, если будет применяться "Базирование" по датчикам.
E-Stop не совместим на одном пине с остальными датчиками при операции Базирования.
Схематично получается два возможных варианта:
Поначалу мне второй вариант больше нравился. Все логические операции на одном пине, все аварийные на другом.
Экспериментируя дальше пересмотрел это мнение в пользу первого варианта.
Правда при такой схеме подключения мы "в теории" попадаем на следующее ограничение (из документации):
... Вы можете связать все выключатели баз на использование одной ИЛИ, и назначить срабатывание всех входов баз на этот сигнал.
В этом случае за один раз Вы сможете калибровать только одну ось...
Не совсем смог прояснить для себя этот момент в документации.
У меня Матч сначала ищет базу по Z, затем, когда нашел ее ищет базу по Y, затем по X.
Т.е. одномоментно срабатывает только один концевик.
И Матч прекрасно находит все базы за один раз при подключении, при котором, он по документации этого делать не должен.
Может имеются в виду какие-то моменты, когда возможна сработка одновременно двух концевиков, не знаю.
После ответа MaratT на это сомнение:
MaratT писал(а):Это про случай когда по оси два винта и два датчика Home соответственно.
Появилось Задание №4.
Итого по этим схемам 2 входа заняты, 3 свободны. Но предупреждается о ограничениях при базировании.
Вариант 2.
Подключаю по следующей схеме:
Все настраивается и работает как в Задании №1.
Понравилась простота операции базирования.
Если сами пины настроены правильно, то база будет или с одной или с другой стороны оси.
Не угадали Базу по какой-то оси - меняем на этой оси направление поиска базы.
За простоту платим пинами: 3 занятых + 1 под E-Stop. Итого 4 занятых из пяти возможных.
Зато по всем осям можно менять точки базирования как нравиться, просто меняя направление поиска Баз.
Вариант 3.
Опять меняю схему подключения:
Всем "Базам" по отдельному входу, все "Лимиты" + E-Stop вешаем на один.
Все тоже, что и в Задании №2:
Внимательность в настройке и базирование не "где попало", а "как подключено".
Те же самые четыре занятых входа и один свободный.
Преимуществ по сравнению с предыдущей частью по свободным пинам нет, зато теряется легкость перемены Баз.
Как итог третьего Задания:
Либо три свободных входа, но базирование осей только по одной за раз (посмотрим, что получим в результате выполнения Задания №4, поэтому пока напишу "согласно документации").
Либо один свободный вход, и одновременное базирование всех осей.
Задание №4.
Появилось после уточнения MaratT чуть выше.
/* В первой версии этого поста этой части не было.
Я ее смог физически проделать только после того как немного разобрался с Софт лимитами.
Но по логике она должна быть здесь.
Поэтому решил расположить здесь, опустив все, что касается Софт лимитов.*/
Итак, два ходовых винта и, соответственно, два датчика Home на одной из осей .
Основываясь на предыдущих опытах можно предположить следующее:
Четыре оси (три + одна подчиненная) дают нам четыре датчика Дома.
Если разносить каждый "Дом" на свой вход + объединяем все лимиты и к ним же добавляем E-Stop, то получаются заняты все пять входов.
И появление еще одного потребителя "входов" потребует установки дополнительной платы LPT.
Подключение по другой схеме: каждой оси (Дом + лимит) по отдельному входу дает четыре занятых входа + E-Stop занимает пятый.
Вывод тот же, что и в предыдущем абзаце: появление еще одного потребителя "входов" потребует установки дополнительной платы LPT.
Есть ли еще какие варианты?
У меня на каждой оси только по одному двигателю.
Чтобы понять как работают два Дома на одной оси решаюсь на эксперимент:
Подчиняю ось Y оси X.
Перепрописал настройки оси Y на ось A, саму ось Y отключил.
Ну и собственно сама процедура подчинения оси Y оси X.
Не совсем правильно по сути, но механизм работы посмотреть попробую.
Подключаю по следующей схеме:
Схема работает с ошибками.
Вполне логично, программа не знает какой из датчиков сработал и останавливает
первый попавший под руку двигатель, а вторым продолжает искать базу.
В общем как повезет.
Дальше не копал, понятно, что схема подключения некорректная.
Меняю схему подключения:
После настройки монстрик довольно прикольно катается по диагонали.
/* Немного лирики:
В процессе экспериментирования идея объединять лимиты с E-Stop на одном входе мне стала нравиться все меньше и меньше.
Причина следующая:
Если срабатывает (в смысле нажимаем на кнопку аварийной остановки) сам E-Stop, то проблем не сильно много.
Поворачиваем/отключаем кнопку, сигнал аварии пропадает, что-то делаем дальше.
А вот если срабатывает датчик лимита (я сжато уже упоминал об этом чуть выше), а он на одном входе с E-Stop,
а у E-Stop приоритет самый высокий, и Матч в силу приоритетов думает что это E-Stop, а не лимит...
Приходится либо выключать станок и руками съезжать с датчика, либо съезжать не выключая,
но противоборствуя режиму удержания двигателей, а руки в такую погоду уже замерзли, валы двигателей проскальзывают...
В общем брр. Ну это сугубо личное. */
Решаю еще усугубить задачу. Матч поддерживает до шести осей. При любом способе, из опробованных ранее,
кроме глобального объединения, способов подключения хотя бы пяти осей (три + две подчиненные) + E-Stop,
входов гарантированно не хватит.
А тут нельзя объединять все датчики на один вход.
Поэтому, чтобы понять чего с чем объединять добавляю временную шкалу и рисую схему:
Так как операция базирования по разным осям разнесена во времени, то получается, что мы можем использовать
одни и те же входы для разных осей.
Тем более в документации есть упоминание:
... Матч не запоминает, какой концевик и какой оси сработал...
После чего получаю следующую схему подключения/объединения:
После объединения датчиков по этой схеме получаем два свободных входа.
Или один, если ось, которая без починенных осей, подключать на отдельный вход.
Ее без разницы куда подключить (показал пунктиром), кроме E-Stop в моем случае
(E-Stop стала для меня почти идолом, см. лирическое отступление).
Внимание:
Схему подключений, получившуюся в данном упражнении, я на своем станке не смогу проверить.
Более того я пока не изучал вопроса о возможности подключения пяти двигателей на одном порту LPT,
так что полученную схему пока считаю "теоретической", иллюстрирующей возможности группировки входов.
С другой стороны получилось же у меня покатать монстрика по диагонали, а "теоретическая схема"
получена на основе этого эксперимента.
Часть вторая.
Властелины абсолютных координат.
Или Софт Лимиты.
Задание №1
Цель - просто посмотреть, что за "зверь такой, с чем его едят".
Я выше показывал схему станка, тут тоже самое только в двухмерных координатах.
Оказалось достаточно, просто подставить в нужные места нужные цифры.
На предыдущей картинке плохо видно цифры, то вот скриншот, чего подставил:
И последнее - ставлю или наоборот снимаю галочку на пункте "В заданных пределах", чтобы Матч отслеживал координаты программно или нет.
Все заработало с первого раза.
В документации на Матч указывается, что границы рабочего поля можно указывать от немерянного минуса до столь же немерянного плюса.
Т.е. варьируя "глубиной" минуса и "возвышением" плюса мы можем указать "нулем абсолютных координат" ЛЮБУЮ точку рабочего стола.
Получается, что на данный момент, якорем левого ближнего угла координат является точка базирования.
Если есть возможность ее изменения, то мы приобретем полный контроль над абсолютными координатами (в пределах рабочего стола).
Это и будет следующим заданием.
Задание №2
Цель озвучена в предыдущем.
Попробую сместить абсолютные координаты, например установить ноль абсолютных координат по центру стола.
С самими координатами проблем нет просто указать новые Soft Min и Soft max.
А вот как сместить координаты точки базирования?
Ответ вроде очевиден - просто где-то в Матче надо указать абсолютные координаты точки, по которой мы приняли базу.
По идее программе должно быть абсолютно все равно какие они. Я имею в виду, что они не обязательно должны быть нулевыми.
В явном виде ни в документации, ни на форумах не нашел ничего подобного.
Зато постоянно натыкался на загадочную возможность "Home Off".
В документации опять что-то невнятное про минус пол дюйма, что бы не врезаться в ограничители.
По форумам, что же ничего определенного.
Советы и варианты мнений самые разные: от оставить как есть и не трогать, до расстояния на которое переедут оси после принятия базы.
Пробую сопоставить поиски "где же это указать" с этим загадочным пунктом меню.
Вот схема по которой я делал:
Поменял значения Soft Min и Soft max, координаты базы в свете изменившихся границ прописал в "Home Off".
Вот скриншот отдельно, на схеме не видно цифр.
Работает вроде нормально.
Станок в "нулевых" координатах по команде G0 X0 Y0.
Неужели это оказалось так просто?
Как-то даже не верится, но противоречий на данный момент не выявил.
Задание №3
Когда проектировал монстрика - казалась база будет удобнее в левом ближнем углу.
Оказалось так удобнее менять инструмент.
А вот крепить заготовку удобнее, когда база в левом дальнем углу.
Попробую сместить базу в другую точку.
Поменял (всего-то надо поменять направление поиска и указать новые координаты базы).
Базируется, где указано.
После выполнения предыдущего задания это показалось как-то даже скучноватым...
Задание №4
Зона замедления - что такое и как работает?
По документации - есть возможность настройки "Зоны замедления" при приближении к границам, обозначенным Софт лимитами.
Такое ощущение, что зона замедления работает только при "ручных" переездах.
При программных (например, при ручном вводе G0 Y чего-то там туда и затем обратно) я замедления не наблюдал.
При первых экспериментах, у меня при цифре 5, например, получался довольно жесткий удар механики
(вначале думал, что оси просто не успевают тормозить), а уже при 10 - было нормальное, плавное замедление и остановка.
Но при продолжении экспериментов создалось ощущение, что если выставленная величина чем-то не устраивает Матч,
то он ее просто игнорирует.
Например, если вместо 10 поставить 9, то как будто ничего не выставлено вообще (эффект такой же, как если стоит 5 или 0).
Не чувствуется даже попыток затормозить.
А при 10 тормозит с явным запасом (при скорости 3000).
Немного увеличиваю скорость и Матч перестает обращать внимание на цифру 10 в качестве параметра замедления.
Зато начинает воспринимать 15, 20 и т.п., в зависимости от выставленной скорости двигателей.
Зону замедления пока везде поставил десятки но надо будет еще поэкспериментировать,
уж больно "мутно" расписан этот режим в документации...
Задание №5
Скорость поиска баз.
Цель - так же как и в предыдущем задании - просто посмотреть, что за пункт такой.
Из документации (опять довольно "мутно"):
... используется для предотвращения врезания в стопы осей на полной скорости при поиске переключателей Баз...
Ну, как станок "врезается" в базы на полной скорости, я уже почувствовал на предыдущих экспериментах.
Еще где-то читал/слышал что при уменьшении скорости поиска Баз выше точность их нахождения.
Только как ее оценить эту самую точность?
"Ковыряясь" в экранах Матча случайно набрел на проверку местоположения:
Работает, насколько я понял, следующим образом (в моей версии документации эта возможность вообще не расписана):
Станок находится в некоторой точке, например X150 Y200 Z-50.
При нажатии на клавишу "ПРОВЕРКА" все оси повторно Базируются (с учетом выставленной скорости базирования)
и затем возвращаются в эту точку уже на скорости переезда.
Далее некоторым образом Матч вычисляет некоторую погрешность.
И вот, что у меня получилось:
При 90 %
При 60 %
При 20 % (которые по умолчанию)
Т.е. при уменьшении скорости поиска Баз вычисляемая погрешность падает от 0.3-0.4 миллиметра, до тысячных
миллиметра, а затем сводится к нулю.
Несколько дольше сам процесс поиска, но если это один раз за сеанс, наверное можно и потерпеть.
В итоге оставил предлагаемые по умолчанию 20% по всем осям как некий компромисс.
До выяснения дополнительных обстоятельств во всяком случае.
Задание №6
Автоматическое обнуление при нахождении баз.
В свете выполненного Задания 2 не совсем обнуление, а принятие величин указанных в Home Off.
Снимаю галочки - типа обнулять не надо.
Шпиндель где-то посередине стола.
Выбираю принять базы.
В окнах индикации текущих координат какие-то значения.
Пока в размышлениях.
Видимо, если записать цифры, которые были перед принятием базы и те, что получили после принятия,
то Матч дает нам последний шанс вычислить некоторым образом координаты точки, с которой мы только что уехали,
с точностью до четвертого знака.
Не получилось разбить предыдущее предложение на несколько, остается надеяться, что хотя бы идею все-таки можно понять.
Задание №7
Реверс чего-то неизвестного.
Столкнулся как-то с такой ситуацией:
Был готовый код для вырезания чего-то там, и оно не влезло, как на первом рисунке.
Интерента нет, G-кодов не знаю.
Начал крутить и так и так (на рис. 2 и 3.), вроде влезает но оси меняются местами и по одной из осей меняется
направление отсчета.
И если как поменять местами X и Y в редакторе я еще догадался, то с реверсом координат запутался.
Очень похоже, что это то самое, чего мне тогда не хватило.
Без реверса координата увеличивается в плюс:
С реверсом тоже, только в минус:
Больше никаких изменений - начальная точка почти одна и та же, клавиша перемещения нажималась одна и та же.
Очень похоже на реверс отсчета координат.
(на время эксперимента оказалось лучше отключить контроль Софт лимита)
Задание №8
Абсолютные координаты для команды G28.
Так как сами команды еще не изучал, то не знаю в каких случаях она применяется.
Остается констатировать тот факт, что если в окне Ручного Ввода Данных Матча попытаться
выполнить команду G28 без аргументов, то станок уедет в те координаты, которые прописаны.
Фууух. Вроде больше пунктов меню нет.
Остается только посмотреть, что мы теряем с установкой датчиков.
Кроме потери рабочего пространства что-то ничего в голову не приходит.
При любых раскладах, наверное, у каждого есть какое-то табу - не подъезжать к границе ближе чего-то там.
Размер границы зависит от смелости конкретного человека и в перспективе может стремиться к нулю.
Посмотрю, что там у меня в цифрах получится, попробую измерить.
Сначала базируюсь по Z (в настройках обнуление координаты, т.е. получаю 0).
Затем той самой гибкой пластиной наезжаю на датчик почти до касания, там на просвет чуть-чуть остается.
И смотрю, что получается в окне координат.
Чуть меньше шести мм.
На датчиках Лимита, наверное, что-то подобное получу.
Итого, в сумме, около 12мм на ось.
По Z чуть меньше, я там не полное перекрытие верхнего датчика металлом делал.
Не знаю много это или мало, просто констатация.
Попытка сделать выводы.
Написал. Перечитал.
Вот такой получился материал за день мучений с Матчем под моросящий дождик и несколько вечеров чуть позже...
А вот каких-то однозначных выводов у меня сделать так и не получилось.
На монстрика изначально было установлено по два индуктивных датчика на ось, из соображений, изложенных где-то в начале.
Наверное, мне стало просто интересно посмотреть, какие есть возможности в Матче для их использования.
И большую часть из рассказанного я банально или не смог найти, или приходилось по крохам выжимать из разных источников, часто противоречащих друг другу.
Именно поэтому пришлось проводить эксперименты.
Я не возьмусь утверждать, что рассказанного материала нет в природе.
Вполне возможно я просто не смог его найти или правильно сформулировать запросы для поиска.
Более того, я не возьмусь утверждать, что все эксперименты были поставлены корректно и соответственно полученные результаты абсолютны.
Но другой стороны я только в начале пути, а устанавливать или нет датчики, и если устанавливать, то какие, каждый решает сам.
Я только попытался рассказать...
Из тех немногих выводов, которые удалось таки сделать:
После всех проведенных экспериментов необходимость установки датчиков Хард Лимита при наличии
настолько мощных возможностей программного ограничения - вопрос действительно сильно философский.
Поэкпериментировал, погонял, да и настроил пока Софт лимиты, как "последний барьер" перед Хард лимитами
(типа датчики уже все равно стоят, не снимать же их).
Но при этом надо помнить, что и Хард лимиты, и Софт лимиты обрабатываются Матчем ПРОГРАММНО,
и "последний барьер" при серьезном сбое Матча вещь, видимо, сильно условная.
Само принятие баз, вроде как нужная вещь.
Поэтому, наверное, созрею перейти на другую схему подключения.
По результатам экспериментов она мне больше понравилась, но именно этот вариант в документации как-то совсем вскользь упомянут...
P/S/
Многие пользователи вроде как вообще прекрасно обходятся без датчиков.
А мне без них "как-то неуютно что-ли".