cnc-club.ru

Если очень хочется на МК "и рыбку съесть и кости сдать", то для плавной программной траектории на приемлемых частотах, нужно выбирать хотя б двуядерные МК

.

А они стоят в два раза дороже и пошло-поехало...

Как будет время покажи как выглядит на лог.анализаторе непрерывная последовательность шагов с аппаратного генератора шагов (на таймере) например по 10имп. со значениями ARR: 2, 3, 4, 8, 16, ... При PSC=0.
Лучше с куском исходника, чтоб можно было удостовериться в повторяемости результата.

P.S. И дело тут не многоядерности МК, а в самой архитектуре ARM-Cortex.

Prav писал(а): ↑ А они стоят в два раза дороже и пошло-поехало...

ESP32 нынче такие дорогие

Serg писал(а): ↑ Как будет время покажи как выглядит на лог.анализаторе непрерывная последовательность шагов с аппаратного генератора шагов (на таймере) например по 10имп. со значениями ARR: 2, 3, 4, 8, 16, ... При PSC=0.

Для более плавного вывода и более широкого диапазона частот играть нужно обеими величинами. Мы же не просто дискретность в вакууме обсуждаем. Применительно к выводу импульсов для управления ШД, и в диапазоне частот, который физически может выдать софт, дискретность вывода таймера нас более чем устроит. При этом ЦП ещё успеет отдохнуть.

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

Прикольные ща цены на STM'ы... Мне, канеш, много не надо. Но по факту, штучно можно купить STM32F429VIT6 (180 МГц, 2Мб флэша, 256Кб ОЗУ) на 20% дешевле, чем популярный STM32F407VET6 (168 МГц, 512Кб, 192Кб) Хорошо, что пин совместимых чипов довольно много - от STM32F207xxxx до STM32F439xxxx.

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

MX_Master писал(а): ↑ Мы же не просто дискретность в вакууме обсуждаем.

Ну можешь изобразить полный цикл разгона от 0 до Fmax и обратно до 0, всё равно у тебя на самом пике будет меняться только ARR при PSC=0, суть от этого не изменится, я просто предложил изобразить лишь наглядный кусок для понимания сути. Также можешь использовать низкие частоты - эффект полностью сохраняется, просто не так хорошо заметен на анализаторе. И код там не при чём - это особенность работы таймеров и прерываний.

На всякий случай напомню суть проблемы: дело совсем не в доступном наборе частот для плавного повышения/понижения результирующей. А в плавности перехода между двумя соседними частотами, например чтобы после последнего шага с периодом M следом шёл чёткий шаг с периодом N без каких-либо лишних импульсов и пауз.

Такой вопрос: был период следования М, потом между импульсами пришло задание двигаться с периодом следования N через какое время нужно выставить следующий импульс?
А зачем кстати частоты больше МГц?

В идеале, внутри контроллера должен крутиться свой сервоцикл, именно он должен переключать частоты. Со стороны LinuxCNC задания могут приходить хаотично (+/-200мкс). Поэтому менять периоды шагов на лету нежелательно.

Частоты выше 1 МГц, в основном, для серв.

Какая разница насколько нестабильно приходит задание. (+/-200 это очень много) обычно цифры +/-20-30 МКС. Пришло новое исполняй новое прямо сейчас. И причем здесь нестабильность сервопрериода. Приходит задание по середине между импульсами, неважно вообще какой там сервопериод. Длительность между импульсами может быть больше сервопрериода вообще.
Про 1 МГц:
Все же максимальная частота задаёт соотношение между дискретностью перемещения и максимальной скоростью. 1000000 это очень хорошее соотношение. Вряд ли кому нужно будет микронная точность и Макс скорость выше 60 м/с. Я по крайней мере не могу себе представить такую задачу.
Я вот понимаю что нет какого то Т.З. конкретного.

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

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

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

Про 1 МГц :
В драйвере серв есть свой "фильтр" входящих импульсов. При последующей обработке и выводе с учётом настроек драйвера, кривые входящие периоды могут значения не возыметь. Так что, абсолютная точность частот не сильно и нужна.

Вопрос был изначально не об всем этом. Ну, ничего.....

mmv писал(а): ↑14 июн 2021, 19:04 Вопрос был изначально не об всем этом. Ну, ничего.....

Что тут непонятного.. Если внутри контроллера не крутится свой сервоцикл, то менять частоту надо сразу, как пришло новое задание. Если крутится внутри свой сервоцикл - то менять частоту надо не сразу, задание кладём в буфер.

MX_Master писал(а): ↑06 июн 2021, 07:03 Небольшой воскресный вопрос

Какой способ программного вывода степ/дир будет для STM32 эффективнее?

• для каждого степ/дир канала свой аппаратный таймер + своё прерывание;
• для всех степ/дир каналов один аппаратный таймер + одно прерывание;
• все степ/дир каналы обрабатывать в основном цикле программы

Хоть и "прокис" вопрос давно
но добавлю свой вариант.
- одно прерывание на базовой частоте для генерации и подсчета шагов для всех каналов.
- второе прерывание для расчетов и управления частотами (servothread по терминологии LCNC).
- индикация, опрос органов управления - в основном цикле.

Из практики - делал в доковидные времена автономный специализированный контроллер, там похожий вариант был реализован на STM32F072 (Cortex M0, 48 МГц). Максимальная частота шагов, она же базовая частота - 131072 Гц. Три независимых канала, генерация шагов программная, по Брезенхем - подобному алгоритму.

Немного не в тему, увидел тут китайцы продают платы от майнеров на xilinx zynq7010 практически даром, на борту ethernet и слот под sd, больше ничего полезного. Soc содержит в себе двухьядерный арм и неплохую фпга. Штатно там крутится линукс, круто бы было запустить linuxcnc прямо там, а на фпга сделать все степгены и прочее мясо. Правда арм кмк слабоват, да и картинку выводить особо некуда.

Kost_irk писал(а): ↑14 июн 2021, 23:32 Немного не в тему, увидел тут китайцы продают платы от майнеров на xilinx zynq7010 практически даром, на борту ethernet и слот под sd, больше ничего полезного. Soc содержит в себе двухьядерный арм и неплохую фпга. Штатно там крутится линукс, круто бы было запустить linuxcnc прямо там, а на фпга сделать все степгены и прочее мясо. Правда арм кмк слабоват, да и картинку выводить особо некуда.

Бывший ASIC сгодится максимум как автономный контроллер. Мордочку управления всё равно придётся мутить на отдельном устройстве, с передачей данных по сети (Ethernet). Развязку тоже надо делать. Ну и месовские прошивки как-то оптимизировать. С одной стороны (по цене платы) это удобно, с другой стороны (всё остальное) - нет

Сергей Саныч писал(а): Хоть и "прокис" вопрос давно
но добавлю свой вариант.
- одно прерывание на базовой частоте для генерации и подсчета шагов для всех каналов.
- второе прерывание для расчетов и управления частотами (servothread по терминологии LCNC).
- индикация, опрос органов управления - в основном цикле.

Спасибо. Вы уже несколько раз этот вариант предлагали, я, просто, о нём забыл

По мере того как лучше разбираюсь в устройстве LCNC понимаю что всё-таки есть возможность сделать дешевый выносной генератор шагов корректно отрататывающий концевики, датчики и пр. ссязанный с LCNC через медленный интерфейс (USB, Ethernet, WiFi) Для этого надо в этот выносной модуль переносить не только траектории из планировщика, но и логику работы с датчиками актуальную для данной части траектории. Например, что сейчас не просто фрезеруем по линии, едем до датчика касания. А это требует добавления анализа данных в LCNC но это конечная определенная задача и это возможно реализовать, причем это имеет смысл, для большинства применений важна дешевизна и простота реализации, платы MESA не всегда нужны и не всегда оперативно доступны.

Но это на будущее. А сейчас я сосредоточен над портированием LCNC ZedBoard это нужно для задач управления роботами с тактильной обратной связью. О результатах доложусь.

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

Вот Америку то открыли. ЧПУ нц31 и прочие старые. Работают на процессоре с производительностью 100000 операций в секунду. Никаких вам сто ядер и даже мегагерцев.
Программу нужно писать нормально. И критичные участки кода на асме, а не на питонах, Ява и прочих... И графический интерфейс туда же влезет.
Просто хотим взять то что уже написаное и как то запихнуть во что то что китайцы продают.

сейчас писать код на асме, кмк, весьма накладно)
раньше bcpp 7 компилил сначала в асм, а потом в ехе. и ещё упаковывал, емнип. ))

mmv писал(а): ↑ Вот Америку то открыли. ЧПУ нц31 и прочие старые. Работают на процессоре с производительностью 100000 операций в секунду. Никаких вам сто ядер и даже мегагерцев.
Программу нужно писать нормально. И критичные участки кода на асме, а не на питонах, Ява и прочих... И графический интерфейс туда же влезет.
Просто хотим взять то что уже написаное и как то запихнуть во что то что китайцы продают.

И ты один из тех, кто хочет viewtopic.php?p=613826#p613826
Так что завязывай эту проповедь про "как надо". Ибо трактовки "правильного" у всех (и у тебя) разные.

Я про то, что реально для контроллера какого то производительного чипа совсем не нужно...