LinuxCNC - Альтернативная кинематика.

[Serg]

Эта тема предлагается для обсуждения моих решений некоторых вопросов кинематики в LinuxCNC и других, связанных с ними.

На сегодня стоит задача получить рабочее решение для вот этого монстрика: Многосевой станок лазерной резки листа и профиля #1 - нужно управлять количеством моторов (joints), которое пока не под силу штатным средствам LinuxCNC. Ну и скорее всего и для других проектов, которым окажутся тесными возможности штатной кинематики LinuxCNC.

Если появятся желающие присоединиться к работам по этой тематике, то добро пожаловать в тему.
Оставляю за собой узурпаторское право "отселять" обсуждения, выходящие за рамки этой темы.

ВНИМАНИЕ!
Все опубликованные ниже разработки предлагаются "AS IS" (как есть), без каких-либо гарантий, в том числе и по сопровождению
Имеющиеся описания ориентированы на тех, кто более-менее разбирается в LinuxCNC и в его HAL в частности, или хотя-бы прочитал и понял документацию.
Считайте это своеобразным порогом вхождения. Если сделать подробное описание "для чайников", то оные не преминут этим воспользоваться и в случае любых непоняток будут задавать вопросы, которые как правило так или иначе освещены в документации. Отвечать на них я не желаю, не из вредности, а из-за отсутствия у меня на это времени....

Extended Gantry Axis Component for LinuxCNC HAL (egantry)

Описание: https://cncdevice.com/devel/eaxis/egantry.txt
Архив: https://cncdevice.com/devel/eaxis/egant ... re3.tar.gz предыдущая версия: https://cncdevice.com/devel/eaxis/egant ... re2.tar.gz
Устанавливается командой

Код: Выделить всё

sudo halcompile --install egantry.c

Совместим с LinuxCNC версий 2.6.x и выше. Для уточнения проверяйте у компонента axis.N наличие пинов home-state и homed.

BlackBox userspace component for LinuxCNC HAL

Описание: Re: LinuxCNC - Альтернативная кинематика. #76
Компонент: https://cncdevice.com/devel/misc/BlackBox.py

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Начало темы было такое:

А что за кинематика? Для твоего мега-станка?

gantry кинематика, которая которая использует только одну axis.N для любого количества приводов оси, ну и решает можество других проблем, сопутствующих штатной gantrykins.

[umerov]

да, дествительно

gantry.comp

не доделаный, не работает с HOME_USE_INDEX = YES

[Serg]

Кстати при HOME_USE_INDEX = YES есть ещё один глюк, связанный с работой этого самого индекса: При уточнении по индексу одновременно происходит обнуление показаний энкодера, axis.N видит это обнуление и, как и положено, обнуляет своё задание. Но "видит" оно в одном сервоцикле, а обнуление задания до pid.N доходит только в следующем - если система PID+привод быстрая, то она успевает заметить эту милисекундную разницу и отреагировать на это ощутимым "ударом".
Как это победить пока не понятно...

[Nick]

А если поменять порядок addf не поможет?
Не совсем понимаю откуда получается удар? ПИД рассчитывается со старым звданием и новым показанием encoder?
PID по положению?

[Serg]

порядок addf не важен, сигналы между компонентами передаются "между" сервоциклами.
По любому функция сервоцикла компонента axis работает примерно так:

Код: Выделить всё

Начало
  прочитать данные с входов
  сделать свои вычисления
  выставить новые данные на выходах
Завершение

Т.е. данные на выходе появятся "в конце сервоцикла", а до pid они дойдут только в начале следующего - т.е. по любому в течении одного сервоцикла у него будет разница между command и feedback с которой он обязан что-то сделать.

Да, PID по положению.

В принципе такая фигня будет при любых конфигурациях (теоретически), где используется обратная связь по положению и обнуление по индексу.

P.S. Может всё это в свою тему отделить и в ней-же поселить мои "усилия" в направлении "альтернативной кинематики" (зависимые оси, вспомогательные оси, т.п.)?..

[PKM]

А если в момент завершения хоуминга снижать чувствительность пид?

Тему надо бы отделить...

[umerov]

А что если делать обнуление показаний энкодера, когда Axis в режиме “machine off.” только потом включать linuxcnc в режим “machine on”?

например как здесь.
http://wiki.linuxcnc.org/cgi-bin/wiki.p ... smaMachine

homing sequence begins:

Enable the Granite drives. Normally, in machine-off state, the Granite drives are disabled. We force them to be enabled so they can do the homing sequence.
Turn the Axis mode to “machine off.” Since the Granite drives will be moving the X and Y axes independent of linuxcnc control, we put linuxcnc into the “off” state so it will not generate a following error fault or try to send corrective step/direction pulses to the drives.
Toggle the GPIO that tells the Granite drives to do the homing sequence (hardware controlled).
Wait for the GPIO signal from the Granite drives that the homing sequence is complete
Reset the X and Y axes encoders –this eliminates the following error from the drives moving without linuxcnc control.
Turn the linuxcnc state to “machine on”
Do the normal linuxcnc homing sequence, including the Z axis homing to limit switch.
return to the “ready on” state

[Serg]

А если в момент завершения хоуминга снижать чувствительность пид?

У этого решения есть неопределённости:
На какое время снижать чувствительность? Если времени окажется мало, то рискуем не успеть выровняться, если много, то рискуем не успеть вернуть чувствительность до начала рабочего движения. Если не на время, а до тех пор пока есть разница, то риск тот-же самый...

А что если делать обнуление показаний энкодера, когда Axis в режиме “machine off.” только потом включать linuxcnc в режим “machine on”?

В режиме "machine off" вообще нельзя ничем двигать просто по соображениям безопасности, всё, что может двигаться должно быть отключено безусловно.

[PKM]

Хорошо, а при обычном хоуминге такое тоже происходит? Вроде не замечал.
ПИД вообще не любит скачков...

[Nick]

Если будешь переносить - они всеравно будут вверху, они по времени сортируются.

[aftaev]

А здесь можно обсуждать как на токарном можно нарезать зубчатые шкивы/шестеренки если рядом с резцедержкой поставить серву которая будет вращать резец в нужный момент

[Serg]

А здесь можно обсуждать как на токарном можно нарезать зубчатые шкивы/шестеренки если рядом с резцедержкой поставить серву которая будет вращать резец в нужный момент

При условии, если окажется, что штатным набором средств LinuxCNC эту проблему не решить. Супер-пупер многомудрый конфиг считается решением штатным набором средств.
Ну и при наличии добровольца способного реализовать решение. Просто теоретических изысканий без практического результата и так хватает.

Хочется собрать тут только те решения по кинематике, на которые штатная LinuxCNC не способна.
Полагаю, что в какой-то теме обсуждаются варианты решения какой-то проблемы/задачи, связаной с кинематикой. В какой-то момент становится понятным, что штатными средствами её не решить, но можно, скажем, написать новый HAL-компонент или ещё что. С этого момента можно говорить о включении этого решения сюда, в виде переноса каких-то сообщений или просто добавления ссылки на первой странице.
В любом случае для публикации готовых решений имеет смысл создать соотвю раздел в Wiki.

[Serg]

Хорошо, а при обычном хоуминге такое тоже происходит? Вроде не замечал.
ПИД вообще не любит скачков...

Происходит всегда при уточнении по индексу. Хорошо заметно если индекс "далеко" от места размыкания концевика. Причем заметно только при первом хомлении после включения питания станка с сервоприводов. Гарантированный способ получить удар: запустить станок и выполнить поиск начал с уточнением по индексу, выключить станок и сервы, повернуть вал сервы примерно на полоборота в сторону от датчика, включить станок и сервы, выполнить поиск начал с уточнением по индексу.
А вот при повторных хомлениях без выключения этого эффекта уже не будет, ибо ноль сервы будет совпадать с нулём axis.N по результатам предыдущих попыток.

[Serg]

Как правило в портале всегда есть внутренние напряжения, от колебаний температуры, от выравнивания при хомлении и т.п.

Тут описано решение штатными средствами: Re: Плазморез со смарт-вентиляцией #40

[Dmaster]

У этого решения есть неопределённости:
На какое время снижать чувствительность? Если времени окажется мало, то рискуем не успеть выровняться, если много, то рискуем не успеть вернуть чувствительность до начала рабочего движения. Если не на время, а до тех пор пока есть разница, то риск тот-же самый...

pid.N.maxoutput
Можно использовать этот параметр на время хоуминга.
Я его использовал при ориентации инструмента перед сменой, что-б шпиндель не рвал со всей дури , но при этом следил жестко.

PS. пошу прощения. перепутал.
pid.N.maxerror

[Serg]

pid.N.maxerror

Смотрел в ту сторону, но даже не рискнул попробовать - оно ограничивает все три коэфициента, а на "резвых" сервах, как на этом станке, это чревато, т.к. на некоторых значениях I,D меньше заданных случается нехилый "расколбас"...
И жёстко он следить не сможет - остановиться быстро ему не даст это ограничение.

Вобщем в рамках этой темы проблему можно считать решённой (бонусом к egantry), а рабочее "штатное" решение "без оговорок" описано в плазморезе.

[Nick]

Кстати, а почему pid.N.maxoutput не поможет?

[Serg]

Вопервых pid.N.maxerror и pid.N.maxoutput (и некоторые другие) заметно меняют поведение настроенного PID, например ограничение pid.N.maxoutput может помешать вовремя подавить возможную раскачку.
Вовторых ограничение pid.N.maxoutput мало чем поможет - этим можно ограничить в лучшем случае скорость, а нужно ограничивать ускорение.

[Nick]

Тогда pid.N.maxoutput через mux либо в limit либо сразу в аналог

[Serg]

Какая разница каким способом его менять? Суть в том, что при этом меняются параметры системы PID-привод, а это чревато...
Собственно вопрос с gantry можно считать решённым - первая версия компонента egantry готова, работают все запланированные функции.
Чуть позже опубликую, а сейчас на работу надо сходить...

[umerov]

первая версия компонента egantry готова

очень интересно