Что я еще не знал о LinuxCNC, что нам еще предстоит сделать
- Nick
- Мастер
- Сообщения: 22776
- Зарегистрирован: 23 ноя 2009, 16:45
- Репутация: 1735
- Заслуга: Developer
- Откуда: Gatchina, Saint-Petersburg distr., Russia
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Надо считать на расстояние необходимое для полной остановки.
ЗЫ А сколько надо памяти на траекторию? Там же по идее просто координаты для 9 осей с частотой сервоцикл. Т.е. на 1 минуту надо около 6Мб...
ЗЫ А сколько надо памяти на траекторию? Там же по идее просто координаты для 9 осей с частотой сервоцикл. Т.е. на 1 минуту надо около 6Мб...
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Можно на время.Nick писал(а):Надо считать на расстояние необходимое для полной остановки.
Во первых - разбиение на мелкие участки будет происходить два раза. Первый раз с фиксированным расстоянием каждого участка, а потом уже на сервоциклы по времени. И для первоначального расчета, если использовать jerk потребуется многократно больше памяти, т.к. скорее всего нужно будет делать много итераций для нахождения оптимального варианта. Посмотри это видео. если еще не успел: http://webserv.lurpa.ens-cachan.fr/geo3 ... n_VPOp.swfNick писал(а):Там же по идее просто координаты для 9 осей с частотой сервоцикл. Т.е. на 1 минуту надо около 6Мб...
-
- Мастер
- Сообщения: 577
- Зарегистрирован: 23 авг 2013, 18:04
- Репутация: 118
- Откуда: г. Ухта
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Предлагаю делить траекторию на участки, где скорость одной из осей падает до нуля. и Потом уже жти участки оптимизировать.
Набросал тут для примера программку, должно быть понятно: вертикальные линии - развернулся вектор Х, норизонтальные -У.
Набросал тут для примера программку, должно быть понятно: вертикальные линии - развернулся вектор Х, норизонтальные -У.
-
- Мастер
- Сообщения: 577
- Зарегистрирован: 23 авг 2013, 18:04
- Репутация: 118
- Откуда: г. Ухта
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Тогда можно рассматривать траекторию, как набор таких вот кусочков, которые надо максимально быстро пройти и правильно состыковать с последующим.
Как вариант - можно каждый участком обсчитывать с двух концов: в начале мы рассчитываем ускорение, а с конца - торможение.
Я так и не могу понять: мы хотим внешнюю программу, которая будет работать между CAMом и LCNC, или доработать LinuxCNC?
Как вариант - можно каждый участком обсчитывать с двух концов: в начале мы рассчитываем ускорение, а с конца - торможение.
Если программа проработает 10 минут и позволит сократить время обработки детали на два часа - то оно того стОит.michael-yurov писал(а):И для первоначального расчета, если использовать jerk потребуется многократно больше памяти, т.к. скорее всего нужно будет делать много итераций для нахождения оптимального варианта
Я так и не могу понять: мы хотим внешнюю программу, которая будет работать между CAMом и LCNC, или доработать LinuxCNC?
- Nick
- Мастер
- Сообщения: 22776
- Зарегистрирован: 23 ноя 2009, 16:45
- Репутация: 1735
- Заслуга: Developer
- Откуда: Gatchina, Saint-Petersburg distr., Russia
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Лучше доработать LinuxCNC.
Сразу разбивать на отдельные участки не очень хорошо, надо еще сделать возможность скругления...
Сразу разбивать на отдельные участки не очень хорошо, надо еще сделать возможность скругления...
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Естественно, это будет происходить во время работы станка, но она не столько сократит время, сколько увеличит качество, уберет вибрации, увеличит точность обработки, снизит нагрузки на станок и фрезу.aaleksander писал(а):Если программа проработает 10 минут и позволит сократить время обработки детали на два часа - то оно того стОит.
Мы хотим доработать LinuxCNC.aaleksander писал(а):Я так и не могу понять: мы хотим внешнюю программу, которая будет работать между CAMом и LCNC, или доработать LinuxCNC?
В любом случае во всех углах траектории станок должен остановиться. Исключение составляют очень пологие углы, которые желательно сгладить, т.к. изначально (до разбиения CAM программой) они представляли из себя плавную кривую.aaleksander писал(а):Предлагаю делить траекторию на участки, где скорость одной из осей падает до нуля. и Потом уже жти участки оптимизировать.
Набросал тут для примера программку, должно быть понятно: вертикальные линии - развернулся вектор Х, норизонтальные -У.
-
- Мастер
- Сообщения: 577
- Зарегистрирован: 23 авг 2013, 18:04
- Репутация: 118
- Откуда: г. Ухта
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Можно взять два соседних участка и скругляй как хочешь. Тут плюс в том, что программе не надо пытаться обхватить всю траекторию. Вот есть два куска: 1 и 2, состыковали, перешли на 2-3, потом 3-4 и т.д.Nick писал(а): Сразу разбивать на отдельные участки не очень хорошо, надо еще сделать возможность скругления...
Плюс еще в том, что ты точно знаешь, что на этом участке полная остановка будет только в начале и в конце.
-
- Мастер
- Сообщения: 577
- Зарегистрирован: 23 авг 2013, 18:04
- Репутация: 118
- Откуда: г. Ухта
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Короче, моя идея - продвинутый LookAHead. Мы не задаем какое-то абстрактное число сегментов, на которых неизвестно что будет. Мы задаем конкретное "колено", где будет серьезный разворот. Как только мы прошли этот разворот, можно подключить следующий сегмент, до следующего разворота.
Получается LookAHead переменной длины.
Получается LookAHead переменной длины.
Последний раз редактировалось aaleksander 27 сен 2013, 13:02, всего редактировалось 1 раз.
- Nick
- Мастер
- Сообщения: 22776
- Зарегистрирован: 23 ноя 2009, 16:45
- Репутация: 1735
- Заслуга: Developer
- Откуда: Gatchina, Saint-Petersburg distr., Russia
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
ненене, не в любом. Все зависит от допуска, если стоит G61, тогда да остановится, а если G64 - то можно его скруглить.michael-yurov писал(а):В любом случае во всех углах траектории станок должен остановиться.
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
У меня в траекториях стыки порой наступают через много миллионов строк. Так что все равно стоит ограничивать по времени или по пути.aaleksander писал(а):Как только мы прошли этот разворот, можно подключить следующий сегмент, до следующего разворота.
А одновременные ограничения ни к чему - только программу усложнят.
Это понятно.Nick писал(а):ненене, не в любом. Все зависит от допуска, если стоит G61, тогда да остановится, а если G64 - то можно его скруглить.
Я, кстати, уже писал, что мне такой механизм не нравится. Я считаю, что углы после некоторого значения вообще не стоит сглаживать.
А любой несглаженный угол потребует остановки в вершине для смены направления вектора движения (это я для aaleksander уточняю).
При чем не обязательно, что речь про смену направления движения по оси. В любом случае резко изменить вектор движения невозможно.
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
У них с сайта можно скачать работающую демонстрационную программу и с ней поэкпериментировать. Нужно только зарегистрироваться.http://www.lurpa.ens-cachan.fr/version- ... 3266986942michael-yurov писал(а):Nick писал(а): Посмотри это видео. если еще не успел: http://webserv.lurpa.ens-cachan.fr/geo3 ... n_VPOp.swf
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Об этом я тоже написал. http://cnc-club.ru/forum/viewtopic.php? ... =60#p86509dpss писал(а):У них с сайта можно скачать работающую демонстрационную программу и с ней поэкпериментировать. Нужно только зарегистрироваться.http://www.lurpa.ens-cachan.fr/version- ... 3266986942
- Starik
- Опытный
- Сообщения: 136
- Зарегистрирован: 13 май 2012, 21:22
- Репутация: 17
- Откуда: Долгопрудный
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
http://hal.archives-ouvertes.fr/docs/00 ... uities.pdf -- там вокруг еще много всякого интересного...
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Неспешно начал изучать возможность параллельного вычисления такого алгоритма.
- PKM
- Почётный участник
- Сообщения: 4263
- Зарегистрирован: 31 мар 2011, 18:11
- Репутация: 705
- Настоящее имя: Андрей
- Откуда: Украина
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Только что поступило в рассылку, мож кто не видел. Насчет предпросмотра.
Proposing a Lookahead implementation for the EMC2 module
Hi All,
I'm a grad student working on trajectory planning for robots. While
doing some fine-detail work using LinuxCNC on a mini-mill, I've bumped up
against the feed rate limitations due to small G-Code segments. Since this
kind of thing is my area, I wrote up a proposal to improve speed through a
longer queue and lookahead, linked here as a PDF:
https://www.dropbox.com/s/p1g1zbwmviv5c ... oposal.pdf
I'm obviously a bit of an outsider to emc development, so any feedback you
all have (positive or negative) would be greatly appreciated.
Proposing a Lookahead implementation for the EMC2 module
Hi All,
I'm a grad student working on trajectory planning for robots. While
doing some fine-detail work using LinuxCNC on a mini-mill, I've bumped up
against the feed rate limitations due to small G-Code segments. Since this
kind of thing is my area, I wrote up a proposal to improve speed through a
longer queue and lookahead, linked here as a PDF:
https://www.dropbox.com/s/p1g1zbwmviv5c ... oposal.pdf
I'm obviously a bit of an outsider to emc development, so any feedback you
all have (positive or negative) would be greatly appreciated.
-
- Мастер
- Сообщения: 8340
- Зарегистрирован: 28 ноя 2011, 00:25
- Репутация: 1589
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
там как раз поднимается вопрос переопределения подачиPKM писал(а):Только что поступило в рассылку...
то есть :
при определенной скорости создали траекторию на основе предпросмотра - а уже во время исполнения программы оператор увеличил подачу допустим с 100% до 200%
так вот интересно - как с этим в мач или Kflop ??
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
В Mach3 с этим какие-то косяки, он не увеличивает скорость на криволинейных участках, а только поднимает на прямых.nkp писал(а): уже во время исполнения программы оператор увеличил подачу допустим с 100% до 200%
так вот интересно - как с этим в мач или Kflop ??
С одной стороны кажется логично, а в реальности - если станок движется по окружности из мелких сегментов - сглаженные стыки рассчитываются исходя из допустимых ускорений, и если потом увеличить подачу до 200% - Mach3 будет двигаться рывками, снижая подачу до 100% на скругленных заранее (исходя из 100% скорости подачи) стыках сегментов. Т.е. проблема в том, что параболу скругления он строит так, чтобы двигаться с требуемой скоростью, но при этом минимально отклоняться. А когда потом оказывается, что требуемая скорость в два раза выше - он уже не перестраивает сглаженные стыки, и вынужден сбрасывать на них скорость до 100%.
А у килофлопа проблем не возникает - после смены скорости подачи он рассчитывает дальнейшую траекторию уже на основе новых данных, т.о. изменение скорости подачи происходит не мгновенно, а через пару секунд (после того, как контроллер выработает то, что было у него в буфере),
но, за то дальнейшее движение станка происходит так, как будто в файл была задана 200% скорость подачи. Без всяких дерганий и т.п, как у Mach3.
Последний раз редактировалось michael-yurov 29 сен 2013, 21:54, всего редактировалось 1 раз.
-
- Мастер
- Сообщения: 8340
- Зарегистрирован: 28 ноя 2011, 00:25
- Репутация: 1589
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
не кошерно конечно - но за то просто...michael-yurov писал(а):роисходит не мгновенно, а через пару секунд (после того, как контроллер выработает то, что было у него в буфере),
- michael-yurov
- Почётный участник
- Сообщения: 11630
- Зарегистрирован: 26 июл 2012, 00:10
- Репутация: 4641
- Настоящее имя: Михаил Львович
- Откуда: Новоуральск
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Главное - результат ожидаемый, а не непонятные конвульсии станка, как у Mach3.nkp писал(а):не кошерно конечно - но за то просто...
Т.е. можно смело задать скорость подачи очень грубо, а потом уже отрегулировать так, как нравится, и на качество обработки это никак не повлияет.
Есть одно мизерное "но" по поводу изменившихся отклонений при скруглении углов, но лично меня оно не колышет.
-
- Мастер
- Сообщения: 577
- Зарегистрирован: 23 авг 2013, 18:04
- Репутация: 118
- Откуда: г. Ухта
- Контактная информация:
Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел
Еще интересную теорию нашел, вникаю пока.
http://web.cs.wpi.edu/~matt/courses/cs5 ... nurbs.html
http://web.cs.wpi.edu/~matt/courses/cs5 ... nurbs.html