Что я еще не знал о LinuxCNC, что нам еще предстоит сделать

[aaleksander]

Пока я пытаюсь догнать вашу мысль, ответьте на вопрос: что такое jerk. В инете только в контексте рыбалки нашел.

[nkp]

что такое jerk

тут на форуме две темы (по S-разгон ищем))
там кое что есть...
http://cnc-club.ru/forum/viewtopic.php? ... hilit=jerk
http://cnc-club.ru/forum/viewtopic.php? ... erk#p60859

[Nick]

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

Это в идеале, а на самом деле (по крайней мере в условиях LinuxCNC) у нас скорость на протяжении каждого servo-thread постоянна, поэтому функция получается кусочно непрерывно дифференцируемая (на каждом отрезке servo-thread), а на всем времени - просто непрерывная и дифференцируемая.

Все равно при дроблении по 1 мс не получится достаточно плавно менять ускорение.

? можешь по подробнее это описать?

Так это я так, для aaleksander объяснял задачу.

Я просто пару сообщений пропустил

[aaleksander]

Ну например такой приблизительный алгоритм.
Дано: фиксированный промежуток времени - t.
1. Допустим, прямо сейчас мы находимся на траектории в точке А. У нас есть некоторое ускорение и некоторая скорость. И еще есть вектор
2. Зная ускорение и скорость, пробегаем по траектории вперед и смотрим, где мы с такими параметрами окажемся через t. Это точка Б.
3. Анализируем промежуточные точки между А и Б на предмет превышения заданных пределов ускорений, по каждой из осей.
4. Если превышений не обнаружено, то точку Б оставляем как есть и переходим на шаг 1. (там Б становится А и все сначала)
5. Если превышение обнаружено, то надо рассчитать, с какими ускорениями нам тут надо было оказаться и скорректировать отрезок от А до этого места на предмет торможения и прочего.
Шаг пять скорее всего будет рекурсивный с возвращением на несколько шагов назад.

Есть какая-нибудь песочница-эмулятор, чтобы поэкспериментировать? Под винду?

[aaleksander]

Кстати, можно разбить траекторию на участки. В качестве границ участка - точки, где скорость падает до нуля.
И уже эти участки оптимизировать. Заодно и распаралелить можно на многоядерном проце.

[michael-yurov]

у нас скорость на протяжении каждого servo-thread постоянна, поэтому функция получается кусочно непрерывно дифференцируемая (на каждом отрезке servo-thread)

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

можешь по подробнее это описать?

А че тут описывать - Видео в теме про фрезу смотрел? трохоидальную обработку видел? там станок делает больше десяти витков по траектории в секунду, что там можно успеть нарегулировать, если у тебя на виток менее 100 сервоциклов?
Там не то что ускорение плавно изменять не получится, а даже скорость будет скакать, не говоря об отклонении сервоприводов от траектории.

А если еще это разбиение на сервоциклы добавит проблем в численном дифференцировании - то совсем дело плохо.

Ну например такой приблизительный алгоритм.

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

И самое, что выносит мне мозг - это что делать, если, например, в точке "B" мы обнаружили, что текущая скорость слишком высокая, а текущие ускорение слишком низкое, или наоборот, или и то и другое слишком высокое, или и то и другое слишком низкое?
Ладно скорость... а если у нас скорость изменения ускорения настолько мала, что мы не успеваем достаточно быстро увеличить ускорение? Короче - я уже запутался.

А не получится ли так, что у нас будут две рекурсивные функции, одна в другой?

И что значит "скорректировать отрезок от A до этого места?", а как его скорректировать?

Я себе это дело вообще по другому пытался представить:
Вот у нас есть графики скоростей движения по всем осям.
В случае с постоянным ускорением у них будет трапецеидальная форма с постоянным наклоном.
А теперь - скругляем углы этих трапеций так, чтобы площадь и высота трапеций осталась прежней. Графики выдавятся в ширину, и нужно будет одновременно отмасштабировать графики скорости по остальным осям.
Самое важное - правильно выбрать очередность, чтобы не получилось так, что ограничивая одну ось мы выведем за допустимые рамки jerk на другой оси.
Либо - сглаживать графики на всех осях несколько раз до тех пор, пока все не будет в пределах допустимого.

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

[Serg]

Тут ещё вот какой момент: в случае S-разгона увеличивается время между нулевой скоростью и заданной (наоборот), т.е. увеличивается время, когда режимы резания не соответствуют заданным. А это может быть чревато...

P.S. Т.е. надо ещё соотв. образом согласованно менять обороты шпинделя.

[Сергей Саныч]

что такое jerk.

третья производная от пути (первая - скорость, вторая - ускорение). Иногда переводят как "рывок".

[michael-yurov]

Тут ещё вот какой момент: в случае S-разгона увеличивается время между нулевой скоростью и заданной (наоборот), т.е. увеличивается время, когда режимы резания не соответствуют заданным. А это может быть чревато...

P.S. Т.е. надо ещё соотв. образом согласованно менять обороты шпинделя.

За то, что хорошо, - это то что на маленьких участках ускорения будут ниже, т.к. не будут успевать нарастать до высоких значений, а, соответственно, точность движения по траектории - выше,
А на больших элементах - будет успевать и ускорение высокое набрать, и скорость.

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

Но вся эта веселуха с плавными ускорениями будет иметь смысл только при полноценном LookAhead.

А менять обороты шпинделя - это уже высший пилотаж.

[Nick]

А че тут описывать - Видео в теме про фрезу смотрел? трохоидальную обработку видел? там станок делает больше десяти витков по траектории в секунду, что там можно успеть нарегулировать, если у тебя на виток менее 100 сервоциклов?
Там не то что ускорение плавно изменять не получится, а даже скорость будет скакать, не говоря об отклонении сервоприводов от траектории.

Видео видел, имхо для этого вполне хватит сервоцикла в 1000Гц, в крайнем случае частоту серво периода можно повысить...
Скорость скакать не будет, т.к. это сгладит механика + ПИД привода.

Тут ещё вот какой момент: в случае S-разгона увеличивается время между нулевой скоростью и заданной (наоборот), т.е. увеличивается время, когда режимы резания не соответствуют заданным. А это может быть чревато...

Ну этот момент и при обычном разгоне существует, и шпиндель там никто не синхронизирует

[dpss]

Видео видел, имхо для этого вполне хватит сервоцикла в 1000Гц, в крайнем случае частоту серво периода можно повысить

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

[nkp]

вот здесь говорится про некий фильтр в емс :

(для просмотра содержимого нажмите на ссылку)

I could be wrong, but I have read the manuals and follow the developer’s list and from what I can understand there is not any lookahead in the trajectory planner. (There is lookahead in the form of a GCode filter to reduce the number of GCode blocks, but this happens before any trajectory planning). I don’t understand it well enough to figure out if it is considering 1, 2, 2.5, possibly even 3 line segments but it clearly isn’t N segments. This also is what makes on-the-fly federate changes so easy for LinuxCNC.

I was a bit surprised myself so I did some math to try to understand why nobody is screaming. It turns out a fairly high performance machine is needed to require a lot of lookahead. The machine needs to require high speed and high accuracy at the same time. If you are ok with larger path tolerance at high speed (for roughing), and go slow when accuracy is needed (finish pass), then not much lookahead is required. If there is some curved path to follow and very high accuracy is required then the line segments must be very short to accurately describe the path, so without lookahead the speed is quite limited. If high accuracy is not required then the line segments can be longer which allows a higher speed.

пока непонятно - это в дополнение к LA ??
зы
кажись это разработчик Kflop(?)

[michael-yurov]

кажись это разработчик Kflop(?)

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

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

[Сергей Саныч]

Пишет, что в LinuxCNC есть некий предпросмотр, который позволяет объединить мелкие сегменты в более крупные отрезки

Есть такое, называется "naive cam detector" http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G64

[michael-yurov]

Почитал ту ветку форума.
Том говорит о том, что LinuxCNC выбрала путь перерасчета сервопетли на стороне компьютера и, судя по всему не собирается отклоняться от этой идеи.
По этой причине система практически непригодна для внешних контроллеров, поэтому практически нет шансов состыковать его KFlop и LinuexCNC.
Хотя, казалось бы, его контроллер может производить ПИД расчеты и сам, но если LinuxCNC отдаст эту часть работы он уже не будет LinuxCNC.

[Nick]

Хотя, казалось бы, его контроллер может производить ПИД расчеты и сам, но если LinuxCNC отдаст эту часть работы он уже не будет LinuxCNC.

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

[Impartial]

А че тут описывать - Видео в теме про фрезу смотрел? трохоидальную обработку видел? там станок делает больше десяти витков по траектории в секунду, что там можно успеть нарегулировать, если у тебя на виток менее 100 сервоциклов?

Ты наверняка присматриваешься к LinuхCNC на предмет управления ракетой с самонаведением. Не предназначена она для этого. Она сделана для использования в хоббийных станках с шаговым приводом и управлением через LPT порт.
В нее при создании заложена безопасность использования неподготовленными любителями. Все доработки делаются на свой страх и риск и не поддерживаются публичной версией.

[PKM]

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

Вообще-то EMC создавался для управления вот этой "хоббийной" машинкой http://web.archive.org/web/201005272044 ... /hexa.html

[nkp]

Она сделана для использования в хоббийных станках

таки да - с самого начала проект был нацелен на управление промышленными станками и в документах NIST (начиная с декабря 1993г)
прямо об этом говорится...
а вот про хоббийное использование "родители" ЕМС как раз нигде не упоминали ))))
вот начальный прикид разработчиков (1993г):

(для просмотра содержимого нажмите на ссылку)

[PKM]

Жаль, что еще лет 5 ЕМС не поварился у профессионалов NIST. Наверное, деньги закончились