cnc-club.ru

Надо считать на расстояние необходимое для полной остановки.

ЗЫ А сколько надо памяти на траекторию? Там же по идее просто координаты для 9 осей с частотой сервоцикл. Т.е. на 1 минуту надо около 6Мб...

Nick писал(а):Надо считать на расстояние необходимое для полной остановки.

Можно на время.

Nick писал(а):Там же по идее просто координаты для 9 осей с частотой сервоцикл. Т.е. на 1 минуту надо около 6Мб...

Во первых - разбиение на мелкие участки будет происходить два раза. Первый раз с фиксированным расстоянием каждого участка, а потом уже на сервоциклы по времени. И для первоначального расчета, если использовать jerk потребуется многократно больше памяти, т.к. скорее всего нужно будет делать много итераций для нахождения оптимального варианта. Посмотри это видео. если еще не успел: http://webserv.lurpa.ens-cachan.fr/geo3 ... n_VPOp.swf

Предлагаю делить траекторию на участки, где скорость одной из осей падает до нуля. и Потом уже жти участки оптимизировать.
Набросал тут для примера программку, должно быть понятно: вертикальные линии - развернулся вектор Х, норизонтальные -У.

Тогда можно рассматривать траекторию, как набор таких вот кусочков, которые надо максимально быстро пройти и правильно состыковать с последующим.
Как вариант - можно каждый участком обсчитывать с двух концов: в начале мы рассчитываем ускорение, а с конца - торможение.

michael-yurov писал(а):И для первоначального расчета, если использовать jerk потребуется многократно больше памяти, т.к. скорее всего нужно будет делать много итераций для нахождения оптимального варианта

Если программа проработает 10 минут и позволит сократить время обработки детали на два часа - то оно того стОит.

Я так и не могу понять: мы хотим внешнюю программу, которая будет работать между CAMом и LCNC, или доработать LinuxCNC?

Лучше доработать LinuxCNC.

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

aaleksander писал(а):Если программа проработает 10 минут и позволит сократить время обработки детали на два часа - то оно того стОит.

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

aaleksander писал(а):Я так и не могу понять: мы хотим внешнюю программу, которая будет работать между CAMом и LCNC, или доработать LinuxCNC?

Мы хотим доработать LinuxCNC.

aaleksander писал(а):Предлагаю делить траекторию на участки, где скорость одной из осей падает до нуля. и Потом уже жти участки оптимизировать.
Набросал тут для примера программку, должно быть понятно: вертикальные линии - развернулся вектор Х, норизонтальные -У.

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

Nick писал(а): Сразу разбивать на отдельные участки не очень хорошо, надо еще сделать возможность скругления...

Можно взять два соседних участка и скругляй как хочешь. Тут плюс в том, что программе не надо пытаться обхватить всю траекторию. Вот есть два куска: 1 и 2, состыковали, перешли на 2-3, потом 3-4 и т.д.
Плюс еще в том, что ты точно знаешь, что на этом участке полная остановка будет только в начале и в конце.

Короче, моя идея - продвинутый LookAHead. Мы не задаем какое-то абстрактное число сегментов, на которых неизвестно что будет. Мы задаем конкретное "колено", где будет серьезный разворот. Как только мы прошли этот разворот, можно подключить следующий сегмент, до следующего разворота.
Получается LookAHead переменной длины.

michael-yurov писал(а):В любом случае во всех углах траектории станок должен остановиться.

ненене, не в любом. Все зависит от допуска, если стоит G61, тогда да остановится, а если G64 - то можно его скруглить.

aaleksander писал(а):Как только мы прошли этот разворот, можно подключить следующий сегмент, до следующего разворота.

У меня в траекториях стыки порой наступают через много миллионов строк. Так что все равно стоит ограничивать по времени или по пути.
А одновременные ограничения ни к чему - только программу усложнят.

Nick писал(а):ненене, не в любом. Все зависит от допуска, если стоит G61, тогда да остановится, а если G64 - то можно его скруглить.

Это понятно.
Я, кстати, уже писал, что мне такой механизм не нравится. Я считаю, что углы после некоторого значения вообще не стоит сглаживать.
А любой несглаженный угол потребует остановки в вершине для смены направления вектора движения (это я для aaleksander уточняю).
При чем не обязательно, что речь про смену направления движения по оси. В любом случае резко изменить вектор движения невозможно.

michael-yurov писал(а):

Nick писал(а): Посмотри это видео. если еще не успел: http://webserv.lurpa.ens-cachan.fr/geo3 ... n_VPOp.swf

У них с сайта можно скачать работающую демонстрационную программу и с ней поэкпериментировать. Нужно только зарегистрироваться.http://www.lurpa.ens-cachan.fr/version- ... 3266986942

http://hal.archives-ouvertes.fr/docs/00 ... uities.pdf -- там вокруг еще много всякого интересного...

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

Только что поступило в рассылку, мож кто не видел. Насчет предпросмотра.

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.

PKM писал(а):Только что поступило в рассылку...

там как раз поднимается вопрос переопределения подачи
то есть :
при определенной скорости создали траекторию на основе предпросмотра - а уже во время исполнения программы оператор увеличил подачу допустим с 100% до 200%
так вот интересно - как с этим в мач или Kflop ??

nkp писал(а): уже во время исполнения программы оператор увеличил подачу допустим с 100% до 200%
так вот интересно - как с этим в мач или Kflop ??

В Mach3 с этим какие-то косяки, он не увеличивает скорость на криволинейных участках, а только поднимает на прямых.
С одной стороны кажется логично, а в реальности - если станок движется по окружности из мелких сегментов - сглаженные стыки рассчитываются исходя из допустимых ускорений, и если потом увеличить подачу до 200% - Mach3 будет двигаться рывками, снижая подачу до 100% на скругленных заранее (исходя из 100% скорости подачи) стыках сегментов. Т.е. проблема в том, что параболу скругления он строит так, чтобы двигаться с требуемой скоростью, но при этом минимально отклоняться. А когда потом оказывается, что требуемая скорость в два раза выше - он уже не перестраивает сглаженные стыки, и вынужден сбрасывать на них скорость до 100%.

А у килофлопа проблем не возникает - после смены скорости подачи он рассчитывает дальнейшую траекторию уже на основе новых данных, т.о. изменение скорости подачи происходит не мгновенно, а через пару секунд (после того, как контроллер выработает то, что было у него в буфере),
но, за то дальнейшее движение станка происходит так, как будто в файл была задана 200% скорость подачи. Без всяких дерганий и т.п, как у Mach3.

michael-yurov писал(а):роисходит не мгновенно, а через пару секунд (после того, как контроллер выработает то, что было у него в буфере),

не кошерно конечно - но за то просто...

nkp писал(а):не кошерно конечно - но за то просто...

Главное - результат ожидаемый, а не непонятные конвульсии станка, как у Mach3.
Т.е. можно смело задать скорость подачи очень грубо, а потом уже отрегулировать так, как нравится, и на качество обработки это никак не повлияет.
Есть одно мизерное "но" по поводу изменившихся отклонений при скруглении углов, но лично меня оно не колышет.

Еще интересную теорию нашел, вникаю пока.
http://web.cs.wpi.edu/~matt/courses/cs5 ... nurbs.html