cnc-club.ru

По результатам вот этого обсуждения
Начало https://www.linux.org.ru/news/opensourc ... d=15028307 и далее вниз по странице.

Вот у меня какая мысль, для того чтобы интерполировать кривую с некоторой заданной точностью её необходимо разбить не менее чем на m блоков.
Это значит что время прохождения кривой не может быть меньше чем m*servoperiod

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

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

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

Ну понятно что k должен делить servoperiod на целое число без остатка, то есть делить servoperiod на равные промежутки времени через которые stepgen будет брать из блока новые координаты.

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

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


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

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

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

В моем контроллере на STM32 (для LinuxCNC) сервопериод = 50 мкс, в то время как сервопериод в самой LinuxCNC обычно = 1000 мкс. Это позволяет сделать вывод шагов плавнее в 20 раз, без каких-либо изменений в LinuxCNC (:

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

Вощем, аппаратные внешние контроллеры решают этот вопрос всегда быстрее и лучше.

MX_Master писал(а):которые отвечают за плавный набор скорости сами, получая задание от LinuxCNC каждый сервопериод

А нельзя не делить на сервопериоды ,а сделать как в GRBL и передавать прямо команды(ну или конечную точку) и добавить только значение скорости в каждой команде.При этом решается вопрос с короткими командами ,когда контроллер просто не успевает разогнаться до конечной g1 или G0 так как скорость в каждой команде рассчитывает пк.Единственная проблема здесь синхронизация времени между передачами команды компьютером и выполнением команды контроллером но при достаточном буфере внутри контроллера это не проблема даже для операционной системы не реального времени(типа WINDOWS).Просто выдавать сигнал неготовности при определенной степени заполнения буфера.Т е источником синхронизации будет не компьютер ,а микроконтроллер.Тогда протокол передачи команд контроллеру станет более простым и понятным,что позволит его использовать с различными программами на ПК.Кстати при этом пожно будет использовать более медленные интерфейсы (COM или 485)

MX_Master писал(а):Это позволяет сделать вывод шагов плавнее в 20 раз, без каких-либо изменений в LinuxCNC (:

Это как?
например LinuxCNC передаёт контроллеру, что в след. сервоцикле надо генерить шаги со скоростью N, а контроллер что будет делать?..

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

UAVpilot писал(а):

MX_Master писал(а):Это позволяет сделать вывод шагов плавнее в 20 раз, без каких-либо изменений в LinuxCNC (:

Это как?
например LinuxCNC передаёт контроллеру, что в след. сервоцикле надо генерить шаги со скоростью N, а контроллер что будет делать?..

Драйвер ничего сам не считает, он просто передаёт новые значения пинов/параметров в/из STM32. А внутри у STM32 свой сервоцикл (я выбрал 50мкс), который не зависит от сервоцикла LinuxCNC. Скорость рассчитывает сам контроллер, в своём сервоцикле.

А как происходит синхронизация с LinuxCnc ?Ведь время в контроллере и расчетное в LinuxCnc могут не совпадать.Как избежать накапливание ошибки по времени ну и соответственно отставания или опережения по положению?Я так понимаю,что основное преимущество перед GRBL ?это то ,что основную кривую разгона строит ПК с частотой 1 мс ,а микроконтроллер только делает линейный разгон между соседними точками в 1мс с частотой 50мкс т.е вместо ступенек получается ломаная

sidor094 писал(а):А как происходит синхронизация с LinuxCnc ?Ведь время в контроллере и расчетное в LinuxCnc могут не совпадать.Как избежать накапливание ошибки по времени?

Да это тот же stepgen, только внутри STM32 (: Ничего там хитрого нет. LinuxCNC по большому счёту требует только текущую позицию, перед началом новых вычислений планировщика. А вот каким способом и как плавно stepgen делает вывод шагов для LinuxCNC неважно. Успеваешь попадать в нужную позицию или скорость - молодец, претензий нет

MX_Master писал(а):LinuxCNC по большому счёту требует только текущую позицию, перед началом новых вычислений планировщика

А откуда он её берёт? Если по какому -нибудь последовательному интерфейсу,то задержка по получению информации о достижении позиции из контроллера может быть довольно большой .Более того,контроллер однозначно отстает от LinuxCNC,соответственно ожидание получения информации по позиции от контроллера тем более не допустимо.

Какую вообще информацию передает LinuxCNC контроллеру каждый сервоцикл 1000 мкс?

Ethernet, SPI. Передаёт в STM32 новые значения входных пинов и параметров компонента. Получает состояние выходных пинов компонента.

MX_Master писал(а):В моем контроллере на STM32 (для LinuxCNC) сервопериод = 50 мкс, в то время как сервопериод в самой LinuxCNC обычно = 1000 мкс. Это позволяет сделать вывод шагов плавнее в 20 раз, без каких-либо изменений в LinuxCNC (:

Это влияет в первую очередь не на плавность прохождения траектории, а на скорость прохождения УП в кадрах.

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

Повышение скорости прохождения УП в кадрах целевой эффект и прямое следствие сделанного мной предложения.

Но впечатление что я один в треде понимаю как и почему сервоцикл и ferror влияют на скорость прохождения УП в кадрах(и почему в кадрах) и сам смысл сделанного мной предложения.
(Я тоже виноват так как плохо объяснил, какой ОП, такое и обсуждение)

torvn77 писал(а):Но впечатление что я один в треде понимаю как и почему сервоцикл и ferror влияют на скорость прохождения УП в кадрах

Ну почему же, Сергей (UAVpilot) тоже понимает (:

MX_Master писал(а):Ethernet, SPI. Передаёт в STM32 новые значения входных пинов и параметров компонента. Получает состояние выходных пинов компонента.

Извините за ,может быть глупые вопросы,просто я плохо знаком с LinuxCNC.И не знаю принципов её внутренней работы.
Разве SPI есть в ПК?Что касается Ethernet,то на мой взгляд протокол обмена сжирает кучу времени и поэтому он выгоден только при обмене большим объемом данных.Кроме того,я не знаю как в LINUX ,а в WINDOWS между командой передать байт и непосредственной передачей может пройти различное(довольно большое время).Команда передачи только сует данное в буфер,а когда WINDOWS соизволит передать байт зависит от того когда освободится процесс и дойдет очередь до этого байта. Что такое пин?В моем понимании это просто нога(вход или выход).И если так ,то как может состояние выходных пинов что-нибудь сообщать о параметрах скорости , положения и состояния контроллера.

torvn77 писал(а):Это влияет в первую очередь не на плавность прохождения траектории, а на скорость прохождения УП в кадрах.

Разве скорость прохождения не задает LinuxCNC?Если кадр пройдет быстрее чем задано это не вызовет паузу ,которая в свою очередь вызовет неравномерность шагов?

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

Максимальная подача тоже влияет, но речь не о ней.
Смотри, станку дали команду идти по кривой.
Но на самом деле станок будет двигаться не по кривой, эта кривая будет разбита на прямые отрезки длинна которых подбираться так, чтобы не выходить за пределы заданного допуска И чтобы каждый отрезок проходился за равное время.

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

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

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

В совокупности это даст меньшее время прохождения УП

torvn77 писал(а):Так как отрезки должны проходится за равное время, то если отрезок из-за ограничений допуска оказыаается слишком коротким то ЧПУ приходится снижать скорость его прохождения(подачу)

Тут не понятно.Противоречит предидущему предложению.

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

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

sidor094 писал(а):я плохо знаком с LinuxCNC

sidor094 писал(а):И не знаю принципов её внутренней работы.

sidor094 писал(а):Кроме того,я не знаю как в LINUX

sidor094 писал(а):Что такое пин?

Чтобы обсуждать предмет, надо в нём разбираться. Предлагаю вам, sidor094, пройти в раздел документации и изучить вопрос. Ну а потом уже обсудим (:

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

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

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

П.С. MX_Master прав, вам надо изучить вопрос, потому что не зная его, вы не понимаете и повод для обсуждения этой темы.

torvn77, а ты давай по новой, в двух словах, объясни, что ты конкретно предлагаешь (: