Предложение по увеличению скорости работы LinuxCNC

[sidor094]

В режиме положения, значения maxvel и maxaccel используются во внутреннем цикле положения чтобы избежать цепочки импульсов, которой мотор не сможет следовать. Когда установлены значения, которые приемлемы мотором, даже быстрые смены установленного положения приведут к плавным трапециевидным перемещениям к новому положению. Алгоритм работает измеряя оба отклонение положения и отклонение скорости, и вычисляет ускорение которое будет стремится одновременно уменьшить оба отклонения до нуля.
А функция для расчета скорости, положения и обратной связи stepgen более медленная и нет большой необходимости вызывать ее часто, поэтому она работает в servo-thread (1кГц).

Соответственно maxaccel ограничивает изменение частоты выдачи шагов между двумя сервоциклами(ускорение).Получается что внутри сервоцикла никакого ускорения нет(частота выдачи шагов постоянна).

[torvn77]

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

Ивкдь я знал это, но подумал что авось как-то там скорость от сервоцикла к сервоциклу передают, а вот оказывается нет.

Значит предложение cvs-255 передавать не только конечные координаты сервоцикла, но и скорость которую генератор шагов должен в его конце иметь имеет смысл.

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

[torvn77]

torvn77,тебе трудно написать разрабам?
если твое предложение стоящее - на него обязательно обратят внимание...
если нет - ... ))

Вот смотри, я общаюсь с форумчанами на одном языке, с моей точки зрения я всё описал в первом посте, но из всех присутствующих только в полной мере merkwurdigliebe понял что я хочу сделать, хотя и не понял почему я хочу это сделать, может потому что с УП из кучи мелких отрезков не сталкивался(или я в CAM слишком большую точность делал).
И что важно, понял он моё предложение потому что уже не то сам делал, не то сталкивался с так работающей системой.

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

[michael-yurov]

У гуглопереводчика английский лучше, чем у тебя русский.

torvn77, ты уже почти три страницы исписал своими мыслями, но я даже приблизительно не понимаю, о чем речь. Может быть есть смысль изъясняться кратко и по существу.

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

Какая разница, как передавать данные? Зачем ты предлагаешь усложнить этот процесс? Чем он тебя не устраивает?

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

[merkwurdigliebe]

merkwurdigliebe понял что я хочу сделать

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

[MX_Master]

И вот в ходе ругани с одним человеком на другом сайте я пришёл к следующей идее:

Контролировть не все блоки, а только каждый k блок, то есть каждый сервопериод посылать пакет координат(вершин) из k блоков, которые контролёр будет с периодом servoperiod/k сам себе задавать и по сервопериоду контролировать координаты только последнего блока.

Тогда время прохождения кривой уменьшится в k раз.

Во-первых, время прохождения кривой не уменьшится в k раз, а останется прежним. А иначе законы физики будут нарушены (: Михаил Юров об этом и говорит.

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

[torvn77]

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

Но не кратно сервоциклу.

исходя из заданных в G64 Px Qx допусков он эти мелкие отрезки должен склеить вместе.

1. Скорость достигается за счёт снижения точности, а уменьшение сервопериода уменьшает время выполнения УП без снижения точности.
2. Помимо P0.03Q0.03 ещё можно предпросмотр в планировщике поднять до нескольких тысяч сервоциклов, это тоже заметно уменьшит время обработки, но даже на фоне этих оптимизаций уменьшение сервоцикла даст заметный на глаз результат.

merkwurdigliebe понял что я хочу сделать

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

Побитость траектории имеет значение, команда гкода должна начинаться и заканчиваться концом сервоцикла, то есть меньше одного сервоцикла она занять не может. В целом если даже команда занимает более одного сервоцикла, то в конце всё равно будет не полный сервоцикл, который приведёт к некоторой потере скорости.
Это очень хорошо заметно на УП в которых кадры состоят из мелких отрезков от 10 до 150 микрон с той или иной вероятностью встретить команду той или иной длинны.
Вот пример идеального случая, когда вся УП состоит из отрезков по 30 микрон и выполняемая с подачей 20 мм/сек.
(Я это писал в личку, по этому ставлю как цитату)

Пусть подача будет 20 мм/сек, за один сервопериод в 1 мс станок проедет по одной оси 20 микрон.
Положим длинна кадра УП по этой оси будет 31 микрон, поскольку в любом случае на прохождение кадра надо тратить два сервопериода то linuxcnc проедет этот кадр на скорости 0.031/0.002=15.5 мм/сек.

Если сервопериод в linuxcnc сделать в 10 раз меньше, в 0.0001 сек, то за сервопериод он продёт 2 микрона.
Такое расстояние он проедет за 31/2 за 15.5 , то есть 16 сервопериодов по 0.0001 сек/период
Скорость при этом будет 31/(16*0.0001)=19.375 что почти соответствует заданной подаче.

Разница получается (15.5/20)*100=77.5% и (19.375/20)*100=96.875%, прирост скорости 19.375%
То есть время фрезеровки можно сократить с 10 до 8 часов, то есть на 2 часа.
Даже если на практике экономия будет в два раза меньше, то это всё равно 1 час.

[Serg]

torvn77, Ты что, совсем не понимаешь что такое сервоцикл?..

[torvn77]

torvn77, Ты что, совсем не понимаешь что такое сервоцикл?..

Утрируя это каждые servoperiod наносекунд axis отправляет в компонент stepgen координаты и забирает у него текущие, чтобы в случае их выхода за некоторые пределы(ferror) от ожидаемых координат внести коррекцию в координаты отправляемые в stepgen в следующем сервоцикле.
В принципе текущие координаты положено брать не из stepgen, а с подключенной тем или иным образом и отражённой в HAL линейки.

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

[MX_Master]

torvn77, уменьшай сервоцикл и твоя задача с микро отрезками будет решена (:

[merkwurdigliebe]

Make sure moves are long enough to suit your machine/material. Principally because of the rule that the machine will never move at such a speed that it cannot come to a complete stop at the end of the current movement, there is a minimum movement length that will allow the machine to keep up a requested feed rate with a given acceleration setting.

судя по этой фразе, возможно да, я ошибаюсь. тогда надо фиксить планировщик

Утрируя это каждые servoperiod наносекунд axis отправляет в компонент stepgen координаты и забирает у него текущие, чтобы в случае их выхода за некоторые пределы(ferror) от ожидаемых координат внести коррекцию в координаты отправляемые в stepgen в следующем сервоцикле.

насколько я понимаю, планировщик траектории вообще никак не учитывает фидбэк от моторов. только если он вышел за FERROR - все останавливается

[sidor094]

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

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

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

Это очень хорошо заметно на УП в которых кадры состоят из мелких отрезков от 10 до 150 микрон
Вот пример идеального случая, когда вся УП состоит из отрезков по 30 микрон и выполняемая с подачей 20 мм/сек.

"Я не отдам Некту яблоко, хоть он дерись!"(c)
Какой идиот CAM выдает такие УП?
Как реальный станок будет отрабатывать такие УП на такой скорости, кроме как перемещаясь по прямой или дуге большого радиуса?

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

Но тем не менее, как нас учили в эпоху исторического материализма (c), практика - критерий истины.

Берем вот такую УП

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

G90
G00 X0. Y0.
G64 P0.005
G90
G0 X0. Y0.
G91
F1200
o10 REPEAT [2000]
 G01 X0.03
o10 ENDREPEAT
o11 REPEAT [1000]
 G01 Y0.03
o11 ENDREPEAT
o12 REPEAT [2000]
 G01 X-0.03
o12 ENDREPEAT
o13 REPEAT [1000]
 G01 Y-0.03
o13 ENDREPEAT
o14 REPEAT [2000]
 G01 X0.03 y0.015
o14 ENDREPEAT
G90
M02

и прогоняем на обычном станке с обычным LinuxCNC

И видим, что скорость прохождения - 1200 мм/мин, то есть те самые заданные 20 мм/с.
То есть, по крайней мере на прямых отрезках, состоящих из мелких кусочков, снижение скорости не наблюдается.

[torvn77]

Сервоцикл и команда не должны быть никак связаны.

Точно не связаны?
Интересно что будет, если случайно сойдётся так что ЧПУ отфрезерует карман или кубический выступ за два сервоцикла?

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

Интересно что будет, если случайно сойдётся так что ЧПУ отфрезерует карман или кубический выступ за два сервоцикла?

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

[torvn77]

Какой идиот CAM выдает такие УП?
Как реальный станок будет отрабатывать такие УП на такой скорости, кроме как перемещаясь по прямой или дуге большого радиуса?

Берём вот такую картинку, но только в векторном формате

,
Для слздания УП использовать Арткам, размер картинки выставить положим в 60 на 130 мм, точность на всех траекториях выставить в 0.001мм.(в linuxcnc потом задать G64P0.03Q0.03), в постпроцессоре прописать указание указывать 4 знака после запятой.
Если сделать меньше то могут быть сложности с центром круговой интерполяции, для координат центра надо потребовать 6 знаков после запятой(это чтобы linuxcnc не писало что начальная или конечная точка не лежит на создаваемой окружности)

А вообще я то, что УП состоит только из отрезков по 30 микрон предположил для упрощения расчётов.
Понятно что в реальной УП будет распределение длин отрезков с различной вероятностью встретить ту или другую длинну.
То есть я показываю схему рассуждения и определяюю примерную оценку.

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

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

Скорость выполнения такой УП, понятное дело, будет ограничена, но не "длительностью сервоцикла", а инерционностью механики станка, которая отражена в заданных максимально допустимых ускорениях.

[torvn77]

Скорость выполнения такой УП, понятное дело, будет ограничена, но не "длительностью сервоцикла", а инерционностью механики станка, которая отражена в заданных максимально допустимых ускорениях.

Это тоже, но практика настройки linuxcnc показывает что ограничение связанное с сервоциклом проявляется до ограничений механики.

[sidor094]

Отрезки по три сотки реально ограничат скорость даже если из них составить прямую.Просто Линухснс может обрабатывать кадры программы с определенной скоростью.А перемалывание большого количества кода в единицу времени сама по себе грузит процессор.Только никакие внешние контроллеры здесь не помогут.Тут дело в быстродействии именно ПК.