S - разгон/торможение для ЕМС2 слабо?

[aftaev]

michael-yurov, у тебя есть привода которые аналог понимают?

[michael-yurov]

michael-yurov, у тебя есть привода которые аналог понимают?

Нет, а что?

Я подумывал те яксавовские купить, но пока что не могу определиться - что лучше, леадшайновские шаговики с энкодером, или яксавовские аналоговые сервы.
У шаговиков NEMA 23 момент намного выше (даже на максимальных оборотах) чем у 100 Ваттных сервомоторов. И шаговики более предпочтительны для станка с ременным приводом.
Шаговики придется использовать на более низких скоростях, соответственно, разрешение у станка будет ниже при таком же разрешении энкодера, но максимальные скорости - выше (за счет меньшего передаточного числа редуктора).
А цены на сервы и шаговики такие примерно одинаковые. В общем - думаю пока. Простите за оффтоп.

[Алексс]

чешский школьник написал систему управления станком с поддержкой S разгонов/торможений.
https://www.youtube.com/watch?v=ZfNcF--LarA

работает под виндой или АНДРОИДОМ.

описание:

SOČ.pdf

(8.43 МБ) 2966 скачиваний

[michael-yurov]

Молодец школьник.
Когда уже производители систем управления (не говорю о дорогих промышленных) дорастут до его уровня?

[Алексс]

это никому не нужно.

[michael-yurov]

это никому не нужно.

В том и беда...
Я уже писал о том, что давно задумывался над созданием собственного планировщика траектории.
И более, чем уверен, в том, что смог бы написать быстрый и грамотный планировщик с поддержкой S кривых изменения скорости...
Но что с ним потом делать? куда его? кому? Для себя любимого писать? Мне не настолько это и нужно...
Перевести на разные языки программирования я не смогу, внедрить в чужие системы - тоже для меня сложно.
Написать полноценную систему ЧПУ -считаю слишком сложной задачей. Меня хватит только на интерфейс и планировщик траектории.
Вот и получается - что "никому это не нужно."

[tooshka]

Хороший интерфейс сваять не каждый программист может (точнее если именно программеры интерфейсы делают, обычно не очень получается - видимо образ мышления и логика у программеров немного по другому работают)

[Алексс]

Написать полноценную систему ЧПУ

все написано до нас.
скачай исходники LinuxCNC и нерепиши планировщик.
всякие gui, hal и прочие плюшки уже есть.

[Nick]

Да, для S-curve насколько я понял надо переписать только 1 функцию ну и добавить объявлений по мелочи.

(выше писал какую)
---

Точнее не выше, а тут: LinuxCNC S-разгон и торможение #1

Уже даже что-то написал, но все нет времени доделать.

[PKM]

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

В LinuxCNC вставить, однозначно.
Хотя там уже есть, в ветке joint_axes3.

[michael-yurov]

Хороший интерфейс сваять не каждый программист может (точнее если именно программеры интерфейсы делают, обычно не очень получается - видимо образ мышления и логика у программеров немного по другому работают)

А я не программист по специальности, а дизайнер. При чем в первую очередь интересуюсь именно интерфейсами и промышленным дизайном.

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

скачай исходники LinuxCNC и нерепиши планировщик.
всякие gui, hal и прочие плюшки уже есть.

Я в этом совсем ничего не понимаю.
Для меня даже просто Linux - уже проблема.
Я только под Windows программировал и на Delphi,
А исходники у EMC, наверное, на С++.

Еще меня Linux не радует тем, что я не собираюсь им пользоваться.

Да, для S-curve насколько я понял надо переписать только 1 функцию ну и добавить объявлений по мелочи.
(выше писал какую)
---
Точнее не выше, а тут: LinuxCNC S-разгон и торможение #1
Уже даже что-то написал, но все нет времени доделать.

Я попробую разобраться, но для меня это очень сложно - чужой язык программирования, чужие исходники, чужие баги, чужая оптимизация и упрощение, чужие сокращения...
Всегда проще написать с чистого листа сразу так, как нужно.

[Serg]

скачай исходники LinuxCNC и нерепиши планировщик.
всякие gui, hal и прочие плюшки уже есть.

Я в этом совсем ничего не понимаю.
Для меня даже просто Linux - уже проблема.
Я только под Windows программировал и на Delphi,
А исходники у EMC, наверное, на С++.

Еще меня Linux не радует тем, что я не собираюсь им пользоваться.

Я попробую разобраться, но для меня это очень сложно - чужой язык программирования, чужие исходники, чужие баги, чужая оптимизация и упрощение, чужие сокращения...
Всегда проще написать с чистого листа сразу так, как нужно.

Не надо пробовать - только зря потратишь время. Поверь на слово специалисту.

[michael-yurov]

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

Для обоих вариантов важно понять главное - единственное, что мы можем делать, чтобы уложиться в допустимые границы скорости, ускорения и jerk (для каждой оси - это снижение скорости подачи. (не буду рассматривать подход Mach3, который тупо отклоняется от траектории).

Первый метод расчетов: Разбиваем траекторию на небольшие участки. И для каждой позиции рассчитываем максимально допустимую скорость подачи. Для этого представим, что мы уже находимся в данной точке, и имеем некоторую скорость и ускорение и пытаемся представить - сможем ли мы проехать еще несколько секунд по траектории управляя только параметром jerk (т.е. плавно меняя ускорение), и при этом не отклониться от требуемого пути.
Если расчет говорит о том, что это возможно - значит ускорение и скорость в данной точке допустимы.
Далее пробуем тот же самый расчет, но для большего ускорения (как если бы на протяжении прошедшего маленького участка jerk был допустимым, положительным).
Затем - для меньшего.
Если оказываются допустимы все три или два варианта - сравниваем время прохождения пути для каждого и выбираем наименьшее.
Те же расчеты необходимо будет провести для каждой оси, и найти наименьшее время для всей матрицы результатов.

И так - на каждом маленьком кусочке траектории.
Данный метод потребует большого объема расчетов, особенно в случае с более, чем тремя осями.
Метод можно сильно оптимизировать. Особенно, важно оптимизировать ту часть расчетов, которая оценивает допустимость скорости и ускорения для каждой конкретной точки.


Второй метод - аналитический.
Его проще представить в виде работы с геометрией графиков скоростей и ускорений.
Если бы не было параметра jerk - графики изменения скорости представляли бы из себя трапецеидальную форму (если всю траекторию разбить на мелкие прямолинейные сегменты).
Т.е. в простейшем случае для каждого участка траектории есть точка старта (возможно - с некоторой начальной скоростью), участок линейного изменения скорости, участок постоянной скорости, и второй участок линейного изменения скорости до конечного значения.
На этом этапе скорости и ускорения должны быть ограничены допустимыми значениями и учтена скорость изменения угла траектории, для оценки допустимых ускорений по осям.
Теперь к этим идеальным графикам нужно добавить еще скругления углов этих трапецеидальных форм.
При чем потребуется изменять графики всех осей одновременно. Т.е. если мы добавляем плавное ускорение для одной из осей - мы должны соответственно откорректировать и графики других осей в данном месте траектории, так, чтобы не возникло рассогласования.
При таких действиях придется правильно определить последовательность корректировок (скругления графиков скорости) осей. Сначала нужно будет корректировать те участки, которые принадлежат оси с наименьшим значением Jerk и ускорения (еще нужно будет умножить на проекцию вектора скорости движения на данную ось ).
В общем - второй метод намного более сложный, но при этом объем вычислений многократно меньше, особенно для многоосевых станков.
По большому счету нам нужно будет рассчитать параметры только для граничных точек (там где меняется значение Jerk).

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

Первый метод похож на Рендеринг 3d изображения с помощью лучевой трассировки (когда для каждой точки рассчитывается цвет),
а второй метод больше похож на работу видеокарты с Direct 3d (как в CAD программах).

Еще можно сравнить с растровым и векторным редакторами. В первом случае - алгоритмы проще, но для более высокой точности - потребуется очень большой объем вычислений.

И еще - все эти рассуждения применимы к Декартовым станкам. Как быть с осями вращения - я не знаю.

[dpss]

Судя по тем материалам, которые я успел изучить, вообще неважно линейная ось или поворотная. У поворотной те же ограничения- максимальные скорость, ускорение, рывок.
Второму алгоритму будет сложно работать с сплайнами.

[michael-yurov]

Судя по тем материалам, которые я успел изучить, вообще неважно линейная ось или поворотная. У поворотной те же ограничения- максимальные скорость, ускорение, рывок.
Второму алгоритму будет сложно работать с сплайнами.

Да я тут думал, думал,
По идее и со сплайнами не должно быть проблем.
Проще не трапеции скруглять, как оказывается, а сразу правильную форум строить.
Кривая разгона то для каждой оси постоянна, так вот нужно графики скоростей осей подровнять (как фигурным шпателем) под эту форму, так, чтобы площадь под ними (пройденный путь) осталась неизменной.
Соответственно, в тех же местах "подмять" и остальные оси согласно вкладу в направление вектора траектории.

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

[КУ!]

Вводная статейка по данному вопросу:
http://archive.nbuv.gov.ua/portal/natur ... 2010_2.pdf

Реализовывал программу по данному алгоритму на описаном устройстве. Кому интересны подробности, можем пообщаться здесь или: Kuznetsoff<dot>Yu<at>mail.ru

[michael-yurov]

Вводная статейка по данному вопросу:
http://archive.nbuv.gov.ua/portal/natur ... 2010_2.pdf

Реализовывал программу по данному алгоритму на описаном устройстве. Кому интересны подробности, можем пообщаться здесь или: Kuznetsoff<dot>Yu<at>mail.ru

Бегло просмотрел, но не увидел главного.
Вы пишите о том, как рассчитать изменение скорости на том или ином участке зная начальную и конечную требуемые скорости.
Но как их узнать - это же самый сложный вопрос!
Как узнать, до какой скорости можно разгоняться в том или ином месте траектории, чтобы и скорость и ускорение и скорость изменения ускорения не вышли за допустимые рамки?