LinuxCNC 2.8 + 2 мотора на ось инструкция и примеры как поделить 3 входа датчиков Home на 5 и более моторов
Добавлено: 02 апр 2022, 20:53
Ниже - достаточно полное резюме по вопросу.
Стоит LCNC 2.8, плата Степмастер (это маловажно), на станке 5 моторов и 4 датчика Home + пробе + естоп. Входы LPT столько не дадут - все пины заняты, 5 моторов + естоп + шпиндель ШИМ + реле = 13 пинов, входы е-стоп + пробе = 2, остается три входа на 4 и более датчиков. В контексте конкретно Степмастера - у него аппаратно три входа для датчиков осей, которые жестко завязаны на конкретные ножки LPT. Инструкиция Степмастера, который может двигать одновременно 5 осей, предлагает датчики дополнительной оси подключать к клемме датчика Z, разработчик, он же изготовитель, в ответ на прямой вопрос ничего не ответил viewtopic.php?p=632848#p632848.
Благодарности коллеге и гражданину гражданинъ за viewtopic.php?f=15&t=29994
Опасности и неожиданности - при переходе к такой компоновке (два мотора на оси) после старта LinuxCNC до момента Хоминга мы получаем вцелом неуправляемый станок, поскольку до момента хоминга каждый мотор управляется отдельно и именно в том порядке очередности, в каком они поименованы в конфиге. Обычно именуют ХУZ, располагают в этом же порядке. Стрелки на клавиатуре влево-вправо двигают Х, вверх-вниз У и Пейдж+ Ап или Даун - Z. При двух моторах на Х будет двигаться Х1, Х2 и У. Из этого следует интересный вывод - если ось с двумя моторами располагать последней (или последними), то раздельное управление до хоминга сохранится по всем осям, кроме задвоенных - за эту возможность придется терпеть смену осей на кнопках компьютера. Сказанное имеет значение для разрешения ситуаций, когда мы на один вход подаем сигналы от нескольких датчиков.
Следует отметить, что конфигуратор Stepconf версии 2.8 отличается от версии 2.7 не только бОльшей тормознутостью, но и бОльшими возможностями и он не вполне бесполезен - это важно для тех, кто пробуя степконф от 2.7 морально готовится к переходу на 2.8 и пробует решения. Степконф 2.8 прямо предусматривает бОльшее число осей для управления - вроде 6, а также не только вариант "все датчики на один вход", но и это же раздельно по группам "все хоме на один вход", "все ...", это притягивает внимание, но не дает полного решения задачи.
Я шел по обычному пути - в новом степконфе сделать обычную конфигурацию 3 оси на 3 моторах и потом вручную плавить hal + ini. По существу это нужно только и исключительно для пробы скоростей моторов и вычисления нужных для конфига коэффициентов. Проще взять два прилагаемых здесь конфига и даже архив директория с конфигами, сохранить себе на диск и там поправить только в ini файле коэффициенты, координаты пределов осей, их скорости и ускорения, нежели идти обычным путем - копировать и модифицировать собственную трехмоторную конфигурацию в обоих файлах - простом ini и витееватом hal.
Суть в том, что возникает неразрешимый конфликт программно-аппаратной части - входов мало, а датчиков много. Пустив несколько датчиков по одному проводу и входу программа получает конфликт. На что я надеялся? - видя в Степконфе вариант распиновки ЛПТ "все пределы на одну ногу" я надеялся, что LCNC при этом применяет дополнительную логику обработки, не приводящую к неизбежно возникающему конфликту при таком варианте подключения - несмотря на то, что в настройках каждой оси явно указано "игнорировать лимиты при хоминге", это "игнорировать" работает и применяется только к той оси (мотору), который в текущий момент хомится. Как следствие ось хомится, но при этом получаем аборт, ошибку - мол, достигнут предел (сработал датчик) другой оси. Это преодолеть не смог. Идея была все первые моторы и их датчики завести на одну ножку ЛПТ, вторые моторы - на втору и третья была бы резервом на другие нужды. Но не прокатило.
Мои личные задачи полностью решены следующим образом - в hal отдал одну ножку ЛПТ оси Z (предел и хоме датчик), на первые моторы двухмоторных осей - им дал только Home со второй ножки, третью отдал Home вторых моторов осей (Х и У). Только Home, без пределов - поскольку у меня на Х и У сервы с обратной связью и механическими ограничителями хода = для меня приемлемо.
Стоит LCNC 2.8, плата Степмастер (это маловажно), на станке 5 моторов и 4 датчика Home + пробе + естоп. Входы LPT столько не дадут - все пины заняты, 5 моторов + естоп + шпиндель ШИМ + реле = 13 пинов, входы е-стоп + пробе = 2, остается три входа на 4 и более датчиков. В контексте конкретно Степмастера - у него аппаратно три входа для датчиков осей, которые жестко завязаны на конкретные ножки LPT. Инструкиция Степмастера, который может двигать одновременно 5 осей, предлагает датчики дополнительной оси подключать к клемме датчика Z, разработчик, он же изготовитель, в ответ на прямой вопрос ничего не ответил viewtopic.php?p=632848#p632848.
Благодарности коллеге и гражданину гражданинъ за viewtopic.php?f=15&t=29994
Опасности и неожиданности - при переходе к такой компоновке (два мотора на оси) после старта LinuxCNC до момента Хоминга мы получаем вцелом неуправляемый станок, поскольку до момента хоминга каждый мотор управляется отдельно и именно в том порядке очередности, в каком они поименованы в конфиге. Обычно именуют ХУZ, располагают в этом же порядке. Стрелки на клавиатуре влево-вправо двигают Х, вверх-вниз У и Пейдж+ Ап или Даун - Z. При двух моторах на Х будет двигаться Х1, Х2 и У. Из этого следует интересный вывод - если ось с двумя моторами располагать последней (или последними), то раздельное управление до хоминга сохранится по всем осям, кроме задвоенных - за эту возможность придется терпеть смену осей на кнопках компьютера. Сказанное имеет значение для разрешения ситуаций, когда мы на один вход подаем сигналы от нескольких датчиков.
Следует отметить, что конфигуратор Stepconf версии 2.8 отличается от версии 2.7 не только бОльшей тормознутостью, но и бОльшими возможностями и он не вполне бесполезен - это важно для тех, кто пробуя степконф от 2.7 морально готовится к переходу на 2.8 и пробует решения. Степконф 2.8 прямо предусматривает бОльшее число осей для управления - вроде 6, а также не только вариант "все датчики на один вход", но и это же раздельно по группам "все хоме на один вход", "все ...", это притягивает внимание, но не дает полного решения задачи.
Я шел по обычному пути - в новом степконфе сделать обычную конфигурацию 3 оси на 3 моторах и потом вручную плавить hal + ini. По существу это нужно только и исключительно для пробы скоростей моторов и вычисления нужных для конфига коэффициентов. Проще взять два прилагаемых здесь конфига и даже архив директория с конфигами, сохранить себе на диск и там поправить только в ini файле коэффициенты, координаты пределов осей, их скорости и ускорения, нежели идти обычным путем - копировать и модифицировать собственную трехмоторную конфигурацию в обоих файлах - простом ini и витееватом hal.
Суть в том, что возникает неразрешимый конфликт программно-аппаратной части - входов мало, а датчиков много. Пустив несколько датчиков по одному проводу и входу программа получает конфликт. На что я надеялся? - видя в Степконфе вариант распиновки ЛПТ "все пределы на одну ногу" я надеялся, что LCNC при этом применяет дополнительную логику обработки, не приводящую к неизбежно возникающему конфликту при таком варианте подключения - несмотря на то, что в настройках каждой оси явно указано "игнорировать лимиты при хоминге", это "игнорировать" работает и применяется только к той оси (мотору), который в текущий момент хомится. Как следствие ось хомится, но при этом получаем аборт, ошибку - мол, достигнут предел (сработал датчик) другой оси. Это преодолеть не смог. Идея была все первые моторы и их датчики завести на одну ножку ЛПТ, вторые моторы - на втору и третья была бы резервом на другие нужды. Но не прокатило.
Мои личные задачи полностью решены следующим образом - в hal отдал одну ножку ЛПТ оси Z (предел и хоме датчик), на первые моторы двухмоторных осей - им дал только Home со второй ножки, третью отдал Home вторых моторов осей (Х и У). Только Home, без пределов - поскольку у меня на Х и У сервы с обратной связью и механическими ограничителями хода = для меня приемлемо.