cnc-club.ru

у МК есть 20 Кб ОЗУ, что мы можем тут придумать в лоб?

Пока придумал только менять частоту перерасчёта в зависимости от максимальной частоты текущего вывода. Но частота перерасчёта будет ограничена определенным максимумом. Теоритичесикими 10 КГц.

Идея...
Генерация степов посредством STM32 в моем будущем проекте будет как-то так:
STEPы генерируются ШИМом
Скорость их, как и кривые разгона, управляются воздействием на частоту таймера, к к-рому привязан ШИМ.

Начальные условия:
время разгона и конечная скорость.
До начала выдачи последовательности шагов вычисляем линейный инкремент скорости (конечная скорость/время разгона)
S-кривую формируем суммируя линейное нарастание скорости и эээ... искривляющий фактор типа табличное значение к-л кривой (синус?)

Запускаем прерывание с частотой 10 кГц.
В нем вычисляем текущую скорость типа
Cur_velocity += Increment_factor + S_curve;
Ну и соответственно, частота таймера является прямой функцией от Cur_velocity.

По-моему, разумный минимум вычислений.

Про ШИМ понятно, оно ща так и работает, а DMA как счётчик. С линейным ускорением тоже всё понятно. Табличный коэффициент представляет интерес, но надо сразу продумать случаи, когда с таблицей надо будет идти на компромисс. Например, при затяжном разгоне.

Shkryab писал(а):Да я и рад бы помочь, да мои мозги настолько отформатированы ассемблером, что от меня будет только моральная поддержка.
Я могу решить задачку, но пользы от этого вашему проекту будет меньше чем никакой...

Разве что потестировать то, что получается...

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

MX_Master писал(а): а DMA как счётчик

счетчик шагов? можно поподробнее?

Argon-11 писал(а):

MX_Master писал(а): а DMA как счётчик

счетчик шагов? можно поподробнее?

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

Но на больших частотах вовремя остановить генерацию внутри DMA обработчика не получается. Поэтому я сделал небольшой тюнинг в минус по ОЗУ, но в плюс по частоте и точности вывода. Я передаю 1 байт в 4-хбайтовый регистр управления таймером. Использую массив. Например, если нужно остановить вывод после 1000 шагов, то в 999-й элемент массива помещается будущее значение регистра управления, которое отключит таймер. Все предыдущие элементы массива заполнены значениями, не мешающими работе таймера. При таком подходе возможна раздельная генерация для 4-х осей на частотах в районе 1 МГц. Если занять проц и DMA еще чем-ньть, то максимальная частота точного вывода, стессна, упадёт. Но для платки за 1.7$ это неплохой результат, учитывая, что большинство дров больше 200 КГц не берут.

Argon-11 писал(а):Начальные условия:
время разгона и конечная скорость.

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

UAVpilot писал(а):

Argon-11 писал(а):Начальные условия:
время разгона и конечная скорость.

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

у Argon-11 уже есть подобный софт на OrangePi под андроид. А я хочу позже написать управляющий софт в OrangePi под Armbian, а также аналогичный софт на другой STM'ке. Может и для ардуинки сделаем пример.

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

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

Не суть, вопрос в другом:
Допустим от этого софта генератору приходит задание "количество шагов, начальная и конечная частота". Я правильно понимаю, что софт предполагает, что генератор линейно увеличит частоту от начальной до конечной за заданное количество шагов? Но ведь генератор наплюёт на это дело и будет увеличивать частоту не линейно, а по S-кривой... И какая траектория получится в результате при движении двух осей?...

Все-таки не очень понятно, какая цель этой разработки? Если создание своей системы ЧПУ, то может, есть смысл проектировать ее "сверху вниз"? Тогда будет более-менее понятно, какие требования предъявляются к шагогенераторам, как ими управлять и насколько тесное взаимодействие будет между системой ЧПУ и генераторами.

UAVpilot писал(а):Допустим от этого софта генератору приходит задание "количество шагов, начальная и конечная частота". Я правильно понимаю, что софт предполагает, что генератор линейно увеличит частоту от начальной до конечной за заданное количество шагов? Но ведь генератор наплюёт на это дело и будет увеличивать частоту не линейно, а по S-кривой... И какая траектория получится в результате при движении двух осей?...

Cофт даёт чёткие команды по SPI - генератор их чётко выполняет. Генератор тут играет роль обычного солдафона. Так что софт знает и решает какие будут разгоны и ускорения у каждого движения.

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

Системой ЧПУ тут и не пахнет. Как я и сказал выше, генератор это чисто солдафон принимающий команды по SPI. Что ему прикажешь по SPI, то он чётко и выполнит. Если его спрашивать по SPI значения текущих параметров - он будет отвечать. Всё.

Я понимаю, что в начале темы я мог ставить более оптимистичные цели, но согласно набранному опыту уклон чуть сместился. Цель сего устройства и прошивки - разгрузка внешних устройств (или МК) от бремени генерации шагов. Т.е. чтобы создать какое-то ЧПУ, надо вместе с генератором использовать еще одно внешнее устройство со своим отдельным МК.

Пожалуй, "снизу вверх". Начинать надо как раз с низкого уровня, а уж потом переходить к продвинутым планировщикам и прочим GUI. А то получится как у всех начинающих контроллеров - все красиво, но медленно.

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

MX_Master писал(а):Cофт даёт чёткие команды по SPI - генератор их чётко выполняет. Генератор тут играет роль обычного солдафона. Так что софт знает и решает какие будут разгоны и ускорения у каждого движения.

Т.е. S-кривые в генераторе уже не нужны?..

MX_Master писал(а):Цель сего устройства и прошивки - разгрузка внешних устройств (или МК) от бремени генерации шагов.

Вот тут её уже достигли: https://github.com/tinkercnc/spi-fpga-driver

Давайте добавим с цель слово "бюджетное". И s-кривые, стессна, нужны.

MX_Master писал(а):И s-кривые, стессна, нужны.

Для чего, если

MX_Master писал(а):Как я и сказал выше, генератор это чисто солдафон принимающий команды по SPI. Что ему прикажешь по SPI, то он чётко и выполнит.

UAVpilot писал(а):Для чего, если

А что непонятного-то? Мастер говорит по командному интерфейсу (в частности, SPI): ось A, езжай с такой-то скоростью в таком-то направлении на такое-то расстояние, для разгона используй такую-то кривую, для торможения такую-то.
Суть в том, что мастер знает параметры всех осей (шагов на мм и т.п.) и может вычислить/выбрать правильные времена разгона (или формы кривых).

А может проще почаще команды "солдафону" отдавать и рапорты требовать? Тогда от "солдафона" потребуется гораздо меньше умений:
- выдавать шаги с заданной частотой
- подсчитывать пройденное по осям расстояние (количество фактически выданных шагов с учетом направления)
Остальное - ускорения, кривые разгона, согласование осей - забота "командира".
Собственно, в генераторах для LCNC так и сделано. Запрос-ответ производится с сервочастотой (1 кГц).
Недостаток - требуются интерфейсы с малым временем отклика - LPT, PCI...
SPI бы тоже подошел, но в типовых компьютерах его либо нет, либо организован без расчета на реалтайм.

Сергей Саныч писал(а):А может проще почаще команды "солдафону" отдавать и рапорты требовать?

Тогда солдатику совсем нечего делать будет...

Сергей Саныч писал(а):Недостаток - требуются интерфейсы с малым временем отклика - LPT, PCI...
SPI бы тоже подошел, но в типовых компьютерах его либо нет, либо организован без расчета на реалтайм.

Ну и Ethernet не надо забыть. К STM'ке есть разные ethernet модули, коннект опять же по SPI.
Если на мат. плате всего 1 ethernet порт, который уже используется (как у меня), то за 3$ есть PCI-Ethernet платки.

Сергей Саныч писал(а):- подсчитывать пройденное по осям расстояние (количество фактически выданных шагов с учетом направления)

Количество фактически выданных шагов будет недостаточно. Нужно делать "substep interpolation".

Argon-11 писал(а):для разгона используй такую-то кривую, для торможения такую-то.

А вот этого он как раз и не говорил!

Argon-11 писал(а):Суть в том, что мастер знает параметры всех осей (шагов на мм и т.п.)

Прямо-таки все? И содержимое таблиц для расчёта S-кривых?

Argon-11 писал(а):и может вычислить/выбрать правильные времена разгона (или формы кривых).

А зечем тогда реализовывать S-кривые в генераторе, если "мастер" уже всё сделал?..

tims писал(а):Количество фактически выданных шагов будет недостаточно. Нужно делать "substep interpolation".

Удивительно, но Mach и LinuxCNC как-то умудряются выдавать нужное количество шагов...