нестандартная рабочая зона на ЕМС для робота

[PKM]

7I85S может подойти, если не больше 4 приводов

[Тима]

7I85S может подойти, если не больше 4 приводов

Осей 3. Остальные механизмы на пневматике.

[Тима]

С рабочими зонами принцип понятен. Но сейчас это проверить неначем. Комп с линусом от меня 165 километрах...)))
Повторю следующий вопрос: В алгоритме работы робота должны быть задействованы и входа/выхода. Т.е. отработал часть кода, остановился и ждет сигнала с дискретного входа для отработки следующей части кода.
И отработал часть кода, выдал сигнал на выход и работает дальше.
Как можно вписать управление входами/выходами в G-код?

[torvn77]

Как можно вписать управление входами/выходами в G-код?

http://linuxcnc.org/docs/devel/html/gco ... ec:M62-M65
Вообще есть хорошая таблица:
http://linuxcnc.org/docs/devel/html/gcode.html

[torvn77]

И отработал часть кода, выдал сигнал на выход и работает дальше.

А ещё можно через это

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

halui.program.is-running (bit, out) - status pin telling that a program is running
halui.program.pause (bit, in) - pin for pausing a program
halui.program.step (bit, in) - pin for stepping in a program

http://linuxcnc.org/docs/devel/html/gui/halui.html

net programm_pause halui.program.is-running => halui.program.pause
net programm_step =>halui.program.step

[torvn77]

7I85S может подойти, если не больше 4 приводов

Тоже подумал 7i85 + 7i76
Надо только проверить чтоб под эту комбинацию была подходящая прошивка.

[Serg]

Принцип управления менять не хочу, пусть остается step/dir + контроль положения по энкодерам!

А какой смысл оставлять step/dir и покупать для этого отдельную плату? Если хотите использовать контроль по положению, то управлять придётся по скорости, а это проще делать по +/-10V с помощью той-же 7i77.

В общем берешь компонент из примера и заменяешь,раздуваешь пока не выйдет желаемое.

А зачем? Чтобы иметь проблемы при апгрейде LinuxCNC?..

[torvn77]

Готовый файл с компонентом называется по его имени,а это значит,что если это сделать,
то файл с компонентом при обновлении скорей всего перезаписываться не будет.
Ну может,если файлы компонентов надо не просто класть в каталог,а ещё и регистрировать,то да,при обновлении проблемы будут.
Но тогда можно сделать *.deb с тригерным скриптом,который будет срабатывать при обновлении и ставить компонент обратно.
Как делать *.deb я не знаю,это надо смотреть на сайте,который посвящён этому формату пакетов.
Ну или изучить пакет к виртуал боксу,по идее внём должен быть триггер на обновление ядра.

[Serg]

Готовый файл с компонентом называется по его имени,а это значит,что если это сделать,
то файл с компонентом при обновлении скорей всего перезаписываться не будет.

Но библиотеки (LinuxCNC и системные), которыми пользуется компонент перезапишутся, и если там будут изменения, влияющие на таблицу имён или распределение памяти для переменных, то "самодельный" компонент может выполнить совсем не тот код, который ожидался. А т.к. HAL компоненты выполняются в кольце ядра, то будет просто зависание компа на ровном месте без какой-либо диагностики...
Главное непонятен смысл рожания собственного компонента, если задачу можно решить штатными средствами...

[torvn77]

Но библиотеки (LinuxCNC и системные), которыми пользуется компонент перезапишутся...

Об этом я не подумал,тогда остаётся только делать собственный *.deb с триггером.

Главное непонятен смысл рожания собственного компонента, если задачу можно решить штатными средствами...

Смыслов несколько
1)Рабочая зона сложная,а значит хал из стандартных компонентов выйдет слишком сложным
2)Очень сложный хал с большим количеством компонент создаст и большую нагрузку на комп за счёт самой тягомотной операции - перетасовки данных между компонентами.
Ресурсов компьютера скорее всего хватит,но зачем его грузить лишней работой.
Лучше научится делать *.deb с триггерами и применять это знание не только здесь,но и в других случаях.
3)Куча усилии на вылавливание ошибок в очень сложном хале.
Который можно потрать более разумным способом,который я описал ранее.

[Serg]

Об этом я не подумал,тогда остаётся только делать собственный *.deb с триггером.

Можно создать собственный .deb с компонентом и прописать необходимые зависимости, но тогда придётся организовать собственный репозитарий для этого компонента и нужно будет перед апгрейдом LinuxCNC сначала на каком-то другом компе поставить новую версию LinuxCNC, собрать там новую версию компонента, сделать новый .deb, положить его в репозитарий и только потом запускать апгрейд на рабочем компе. В противном случае возникнет неразрешимая коллизия версий LinuxCNC и компонента.

1)Рабочая зона сложная,а значит хал из стандартных компонентов выйдет слишком сложным

Ничего там сложного нет - три компонента wcomp на всю запретную зону (по одному на каждое измерение) + простая логика для объединения 3 выходов в один.

Очень сложный хал с большим количеством компонент создаст и большую нагрузку на комп за счёт самой тягомотной операции - перетасовки данных между компонентами.
Ресурсов компьютера скорее всего хватит,но зачем его грузить лишней работой.

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

3)Куча усилии на вылавливание ошибок в очень сложном хале.

Никаких проблем при правильной организации.
У меня не вызывает никаких проблем большие HAL-конфиги, для примера: AG-400 - чуть более 600 строк, Плазморез - почти 1700 строк.
IMHO проще вылавливать ошибки в большом HAL-конфиге, чем и в HAL-конфиге и в своём компоненте, учитывая, практически полное отсутствие средств отладки компонентов.

[torvn77]

Можно создать собственный .deb с компонентом и прописать необходимые зависимости, но тогда придётся организовать собственный репозитарий для этого компонента и нужно будет перед апгрейдом LinuxCNC сначала на каком-то другом компе поставить новую версию LinuxCNC, собрать там новую версию компонента, сделать новый .deb, положить его в репозитарий и только потом запускать апгрейд на рабочем компе. В противном случае возникнет неразрешимая коллизия версий LinuxCNC и компонента.

Думаю,что это не потребуется.
1)Зачем делать репозитории если можно установить пакет локально?
2)Как ставится компонент?
Сначала распаковываются файлы,потом запускается установочные или триггерные скрипты.
Что мешает в них прописать вызов halcompile,который вызовет распакованный исходник?
А вообще *.deb может ничего не распаковывать,а содержать только вызов скрипта /root/halcompile/components_update.sh
Или даже кощунственное /home/user/Documents/LinuxCNC/components_update.sh
О!
На худой конец можно сделать ещё и так,прописать в ярлык вместо linuxcnc ....ini вызов linuxcnc_start ....ini
Ну и в этот linuxcnc_start запихнуть вызов halcompile и что ещё посчитается нужным.
(собственно задача автоматизировать запуск скрипта при обновлении linuxcnc,а вовсе не делать полноценный пакет)

В противном случае возникнет неразрешимая коллизия версий LinuxCNC и компонента

А в apt можно просто прописать в зависимостях linuxcnc без уточнения версии?
Ну и триггер на переустановку linuxcnc?
Точно такой вариант будет приводить к коллизии?

(по одному на каждое измерение)

Зона П-образная.

учитывая, практически полное отсутствие средств отладки компонентов

Можно делать промежуточные тестовые пины.

[Serg]

1)Зачем делать репозитории если можно установить пакет локально?

Не суть, важно то, что сначала надо будет где-то его создать и куда-то положить.

Что мешает в них прописать вызов halcompile,который вызовет распакованный исходник?

Ничего не мешает, тогда для этого на рабочем компе придётся установить кучу софта, не нужного для самой работы: halcompile, gcc, make, кучу библиотек и т.п. А если этот комп - какой-нибудь RaspberiPI с мелкой флешкой?.. Да ещё защищённой от записи, чтоб можно было выключать просто "выдёргивая" питание...

Зона П-образная.

Неправильно. Запретная зона - прямоугольная. Внешние габариы рабочей ограничены штатно - лимитами.

Можно делать промежуточные тестовые пины.

Можно. Только зачем всё это?
Сделать свой нестандартный компонент, наделать внутри него средств его отладки попутно увеличивая вероятность порождения багов в нём, организовать процесс обновления этого компонента, который тоже может стать источником глюков и привести компонент производства (станок) в нерабочее состояние...
Или просто добавить к конфигу десяток строк...

[Тима]

Прикинул алгоритм ограничения движения в запретные зоны.
По оси Y пока ограничений не делаю. Там ограничения по всей плоскости, можно просто передвинуть лимиты. Поэтому будет обработка по Х и Z.
Вот эта плоскость:

Теперь алгоритм такой:
Если (x>x1) и (x<x2) и (z>z1) то стоп.
Алгоритм правильный или еще какое условие добавить надо?

[Serg]

Алгоритм правильный или еще какое условие добавить надо?

Правильный, только (z<z1) - 0 ведь вверху.

[Тима]

Алгоритм правильный или еще какое условие добавить надо?

Правильный, только (z<z1) - 0 ведь вверху.

Нет, как-раз нужно чтоб срабатывал "стоп", если z>z1. Если z<z1, пусть работает.
0 наверху, и при опускании z увеличивается.

[Serg]

Вообще-то когда 0 вверху при опускании z должен уменьшаться: -1, -2, -3, ...

[Тима]

Вообще-то когда 0 вверху при опускании z должен уменьшаться: -1, -2, -3, ...

Ну, тут система координат сделана так! отрицательных значений нету!
В работе этого робота есть еще один подводный камень, опишу его позже. Сейчас времени нету!

[Nick]

7I85S может подойти, если не больше 4 приводов

Там нет дополнительных IO.

Написано прямое вращение 0..10в, обратное вращение -10..10в.
Это как? Или опечатка?

Там кстати не вращение, а "предел крутящего момента".
Но похоже на управление. В общем 5i25+7i77 самое то.

[Serg]

Там кстати не вращение, а "предел крутящего момента".
Но похоже на управление. В общем 5i25+7i77 самое то.

Там вроде 14 контакт - управление по скорости...