cnc-club.ru

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

В контроллерах есть планировщик. Он как раз и занимается предпросмотром кадров программы. По хорошему нужен предпросмотр минимум на 2-3 десятка кадров...

Строим кривую в пространстве и исследуем её на предмет скорости изменения координат по каждой оси отдельно. Наверное проще будет строить кривые отдельно для каждой плоскости и их уже исследовать...

А контроллер для чего планируется? Просто для разных операций можно по разному строить движение.
Навскидку:
1. художественная - обработка дерева, гравировка (допускается скругление траекторий в местах перелома)
2. машиностроительная - обработка металла и производство точных деталей (точное следование траектории обработки, возможна остановка в местах излома траектории)

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

Может кто знает как это сделано в grbl или LinuxCnc?

Kachik писал(а): ↑ А контроллер для чего планируется? Просто для разных операций можно по разному строить движение.

Контроллер стараюсь делать более менее универсальным.Работает как для фрезеровки гравировки так и для токарки.Пробовал так же на 3d printere.

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

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

Kachik писал(а): ↑ Обычно если какая-то ось не успевает разогнаться, то остальные оси просто подтормаживаются

Проблема в том ,что для правильного прихода оси в конечную точку разгона нужно соблюсти не одно ,а 2 условия.1-ое Ось должна прийти в точку со скоростью равной заданной.2-ое Она должна достичь этой скорости в строго заданном месте траектории не говоря уже о том ,что все оси должны закончить разгон одновременно.Это условие не всегда выполнимо при линейном ускорении.Для выполнения этого условия необходимо,чтобы предидущий разгон был закончен в такой же точке.Если же этого не было то линейно достигнуть точки следующего разгона принципиально не возможно.Требуется точка излома на разгонной характеристики.При экспоненциальном разгоне разгон всегда происходит по таким точкам.Поэтому даже если мы не закончили предидущий разгон ,мы все равно находимся в точке с нужными скоростью и отставанием от траектории(где отставание пропорционально скорости).

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

Manfred Weck · Christian Brecher
Werkzeugmaschinen
Mechatronische Systeme,
Vorschubantriebe, Prozessdiagnose
третий том. купите или скачайте и будет Вам счастье.

Сергей (sidor094), установи в свой автономный контроллер любой одноплатный ПК c LinuxCNC, а рядом - любой внешний контроллер (типа Mesa 7i92). Про экранчик, физический кнопки, галетники и т.п... ты сам в курсе. Интерфейс управления и настройки сделай отдельный и полностью свой. Стессна, он должен быть с закрытым исходным кодом и ключом активации по ID одноплатного ПК. Всё. Придумывать ничего лишнего не нужно. Никакие тома книг открывать не надо. Буквально, пару мануальчиков просмотреть/изучить.

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

Книгу скачал.Посмотрю.

MX_Master писал(а): ↑ ергей (sidor094), установи в свой автономный контроллер любой одноплатный ПК c LinuxCNC, а рядом - любой внешний контроллер

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

Возможно тебе стоит обратить внимание на алгоритм брезенхема, только вместо изменения значения координаты X или Y, рассматривать необходимость формирования импульсов для нужной оси, а вот как часто выполнять новый расчет значений будет являться скоростью.
В данных расчетах можно использовать не только 2 оси, но 3,4,5.

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

sidor094 писал(а): ↑ Не мой путь.Мне намного удобнее работать со своим контроллером.На нем я могу сделать все.С LinuxCNC надо еще разбираться.На мой взгляд даже при всей гибкости LinuxCNC достигнуть того,что можно в собственной разработке сложно.

Т.е., ты хочешь потратить в десятки раз больше времени на изучение более сложных книг, мануалов и алгоритмов, лишь бы не изучать инструкции к готовым открытым решениям? Как грицца, фиг с ним, с LinuxCNC... в GRBL, Marlin, Smothieware тоже не заглянешь?

Кстати, на каком железе будет контроллер? ARM микроконтроллер, ARM SoC, x86/64 CPU, FPGA? Просто, я по опыту знаю, сколько времени занимают обычные программные расчёты, включая графику. Если будет низкочастотный одно-ядерный микроконтроллер, можно вариант заворачивать. Ибо красиво распараллелить все процессы не получится. Нужно что-то поувесистее

sidor094 писал(а): ↑06 мар 2021, 09:17 Как раз так и делаю.Но это скорость.А ускорение таким способом можно получить только для одновременного разгона или торможения осей(например от нуля или до остановки.На данный момент у меня происходит как бы вертуальное движение координат с бесконечным ускорением.Одновременно как бы формируется программа имитирующая привода осей с п-регулированием,следящими за виртуальной координатой.И уже эта программа формирует шаги которые автоматически получают разгон по экспоненте.

Вот прочитай: http://ww1.microchip.com/downloads/en/a ... oc8017.pdf
Тут подробно описано как реализуется разгон, движение, и замедление, даже формулы есть, исходники так-же легко гугляться, но данный пример без планировщика, но является основой для старта в написании своего модуля генерации step сигнала.

На мой взгляд нужно отделить расчёт ускорений от вывода управляющих сигналов. Ибо управление может быть не только step/dir.

MX_Master писал(а): ↑06 мар 2021, 14:44 На мой взгляд нужно отделить расчёт ускорений от вывода управляющих сигналов. Ибо управление может быть не только step/dir.

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

Но конечно для станка изобретать управление приводами, потом некий интерфейс взаимодействия с пользователем, когда можно взять за основу linuxCNC и разработать только желаемый интерфейс управления, куда быстрее и проще. А сэкономленное время потрать на другие не менее интересные задачи. Но это лишь моё мнение, которое не стоит принимать близко к сердцу

selenur писал(а): ↑ Но конечно для станка изобретать управление приводами, потом некий интерфейс взаимодействия с пользователем,

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

MX_Master писал(а): ↑ На мой взгляд нужно отделить расчёт ускорений от вывода управляющих сигналов. Ибо управление может быть не только step/dir.

Даже если управление не step/dir программа все равно должна просчитывать каждую точку.Отличие только в том выдавать сигнал step в каждой точке или использовать другой способ передачи команд приводам.

Поэтому ВСО ЧПУ системы имеют предпросмотр от 80 кадров и задержку 0,5мс и менее.