Jump to content

    
MX_Master

Простенький ЧПУ контроллер

Recommended Posts

2 часа назад, _pv сказал:

место около ЧПУ станка экономят, или энергопотребление?

Есть контроллеры, встроенные в ручной пульт. И автономность не повредит, чтобы не потерять, на каком месте остановился станок после пропадания питания.

 

2 часа назад, _pv сказал:

выплюнуть езернет пакет со всеми межпакетными паузами, преамбулами и минимальными 64байтами полезной нагрузки вроде меньше микросекунды,

Можно копнуть немного глубже и окажется, что не все Ethernet контроллеры умеют так быстро работать, главным образом со стороны хоста. Видел много рекомендаций по читингу настроек драйверов, но подходит эта процедура далеко не всем. Есть черные списки по чипам, не рекомендованные к применению с LCNC. Но речь не об этом, были времена, когда SOC стоили в разы дороже, ситуация понятна.

Share this post


Link to post
Share on other sites

Помнится автор топика начинал с "защиты прошивки".

Она возможна во всех этих вариантах х86 и т.д.? А то потом окажется, что на плату придется ставить и маленький STM32 в качестве донгла :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Параллельно данному проекту прикидываю на будущее вариант контроллера, который всю RT логику и расчёт траекторий будет держать внутри. А снаружи будет не RT интерфейс пользователя на отдельном ПК или на дисплее с физ. кнопками, подключёнными прямо к контроллеру. 

Не могу определиться, что из STM32 ставить на такой контроллер. Однозначно, должно быть что-то быстрое и, желательно, с двумя ядрами. Одно ядро будет на лету парсить gcode файлы с внешней USB/MicroSD флэхи, превращая сие в траекторию, другое ядро будет заниматься подсчётом и выводом сигналов. Сам контроллер - продукт не массовый, закупать под него тысячи чипов не нужно. Пока кризис на дворе, можно, просто, поскрести по сусекам китайцев :friends:

Собсна, выбор - или ставить что-то двуядерное (кортекс М7+М4, A7+M4) или ставить два чипа (М4+М4, М7+М4, М7+М7). И в том, и в другом случае - свои плюсы и минусы. К примеру, когда всё в одном чипе - обвязки надо меньше, обмен данными между ядрами проще, обновление прошивки через свой загрузчик проще. Но линейка таких чипов небольшая, быстро заменить на какой-то аналог и перестроится не получится + цены на такие чипы кусаются. Если ставить два чипа, с ценами и заменяемостью будет порядок, аппаратной периферии в 2 раза больше, но коммуникация между чипами и обновление прошивок будут явно непростыми. Возможно, есть и другие плюсы/минусы, которые я не увидел. Советы крайне приветствуются :crazy:

Share this post


Link to post
Share on other sites
2 hours ago, MX_Master said:

Однозначно, должно быть что-то быстрое и, желательно, с двумя ядрами.

Мир не вращается вокруг одних STM32. Посмотрите на LPC4337.

2 hours ago, MX_Master said:

Одно ядро будет на лету парсить gcode файлы с внешней USB/MicroSD флэхи, превращая сие в траекторию, другое ядро будет заниматься подсчётом и выводом сигналов.

Это всё круто звучит: два ядра. А как Вы взаимодействие между ними наладите? Есть у Вас опыт написания приложений для нескольких ядер?

2 hours ago, MX_Master said:

Советы крайне приветствуются :crazy:

Зачем Вам вообще два ядра? Вы бы посчитали нагрузку на эти ядра. Может быть окажется, что двух ядер будет недостаточно. Кстати, есть микроконтроллеры и с тремя ядрами. Почему бы не выбрать их? А может быть с вашими требованиями справится один Cortex-M7.

З.Ы. Я, вот, имею опыт работы с двухядерным МК LPC4337 с 2013 года. Задачи: сбор аналоговых и дискретных данных на частоте дискретизации до 1 МГц. Одновременно с этим: отображение данных на графическом дисплее, работа с Ethernet (web/ftp/modbus), MMC/SD, что-то ещё на шинах висело, modbus rtu (RS485/Ethernet). Я тоже сначала думал, что нужно задействовать помимо основного Cortex-M4F второе Cortex-M0. А вот и нет. Всё прекрасно улеглось на одно ядров в окружении FreeRTOS. Ещё раз: смотрите не только на ядра, но и на периферию микроконтроллера. У некоторых она весьма впечатляющая. Почти "полуплисины" приделаны.

З.Ы.Ы. Кстати, два ядра задействовал в своё время для изучения. На Cortex-M0 вертелся USB-стек, а на Cortex-M4F графический интерфейс пользователя + сбор и обработка данных.

Share this post


Link to post
Share on other sites

Провентилировал данные по LPC4337.. Я понимаю, что Вы с ним давно знакомы и успешно работаете.. Но цена сейчас на них кусается и у китайцев еле еле можно найти в закромах. По требуемой периферии - чуток недостаточно аппаратных таймеров/счётчиков, маловато SRAM. 

Опыт работы с двумя ядрами есть, совсем небольшой, но, вроде, успешный. 

В целом мои задачи похожи на ваши. Графика, активная работа по сети (web), активное чтение с флэшек SDMMC/USB, активные расчёты с плавающей точкой. Это всё - работа с данными пользователя. Работа с устройствами - это неторопливый обмен по RS485 c частотниками (VFD), не менее 5-ти отдельных счётчиков для ABZ энкодеров/линеек (от 1 МГц и выше), не менее 5-ти отдельных ШИМ генераторов для управления приводами осей (от 1 МГц и выше), ещё один низкочастотный (до 20 КГц) ШИМ генератор для аналогового управления частотниками (VFD). Причём, работа с вводом и выводом сигналов частично программная. Для управления приводами крутится (на прерываниях) цикл с периодом 50мкс, в нём идёт правка, ВКЛ и ВЫКЛ параметров таймеров, обновление позиций и иногда ручное подергивание GPIO. Для нулевой метки (Z) энкодеров есть программные прерывания для сброса счётчиков в нуль (важна скорость реакции).

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

У китайцев, кстати, завалялось довольно много STM32H750VBT6, ещё по малым ценам. Но флэшу маловато, нужна внешняя. Что-то из H743VIT6 (пин-, флэш-, код-совместимое) у китайцев тоже есть, но в мало. Двуядерное в стоке, что-то ничего и нет. 

Share this post


Link to post
Share on other sites
1 hour ago, MX_Master said:

Но цена сейчас на них кусается

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

1 hour ago, MX_Master said:

недостаточно аппаратных таймеров/счётчиков

Есть SGPIO, который может помочь в сборе данных с тех же энкодеров (сам обрабатываю три штуки на частоте 1 МГц). Возможно, что-то и выводить сможет.

1 hour ago, MX_Master said:

маловато SRAM

136 кБайт, ЕМНИП)

1 hour ago, MX_Master said:

У китайцев, кстати, завалялось довольно много STM32H750VBT6, ещё по малым ценам

Ну выбор за Вами) Если знаете, как работать с несколькими ядрами, и прикинули нагрузку.

1 hour ago, MX_Master said:

Если всё на одно ядро (даже М7) повесить, загрузка будет приличная

Гм...

1. Неторопливый обмен по RS-485. Если USART у выбранного МК имеет FIFO, можно сцепить с ПДП, то процессор будет тратить время на парсинг входящих пакетов и формирование исходящих. Скорее всего загрузка будет малозаметной.

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

3.Пять ШИМов. Тут только предположу, что ШИМы можно кормить тем же ПДП по связанному списку, чтобы писать данные непосредственно в регистры MATCH. И писать их из некого буфера в ОЗУ, куда Ваш алгоритм подкидывает рассчитанные значения.

4. Активное чтение с флэшек SDMMC/USB. А насколько активное? Прямо во время работы приводов с энкодерами? А что, если считать G-коды, или что-там сейчас используют, в память, распарсить, и предоставить в максимально готовом виде для расчётных алгоритмов? Тогда, может быть, и читать не придётся. Просто я сам машиностроитель по образованию, и представляю, как работает станок с ЧПУ, но не представляю что=там можно активно читать с флешки. Могу чего-то не знать)

5. Активная работа по сети (web). Вот прямо во время работы приводов и энкодеров?))) Ну подтормозит немного вебка, и ладно) Тем более, что при использовании ОСРВ с вытесняющим планировщиком, задаче веб-сервера можно дать приоритет ниже, чем тем, которые крутят привода.

6. Активные расчёты с плавающей точкой. А на сколько активные? Начиная с Cortex-M4F у Вас есть FPU. Для M4F это одинарной точности, а для M7 это двойной точности. Подозреваю, что двойная точность не сильно нужна, поэтому M7 только для больших частот и чего-то ещё, но точно не сопроцессора.

7. Графика. Хм... тут некомпетентен. Никогда не любил графику, и на работе ею занимаются коллеги. Но Что там сложного в целом? Вывод через ПДП... А окна... Ну для случая, когда работают приводы, сделать наипростейшее окно, и выводить туда цифры XYZ и других осей. Тогда отрисовка не займёт много процессорного времени.

Особо критические участки кода можно написать на ассемблере, ибо компилятор не весь ассортимент команд умеет использовать. Например, SIMD-команды Вы просто так не задействуете.

 

ЗЫ. Я бы обрисовал задачу более детально. На это надо не стесняться потратить время. Затем подобрать нужную периферию, понять, что она может, а что не может. Подумать, а нельзя ли из двух "недо"-периферий сделать одну, но полноценную. Например, в младших семействах STM32F0 нет FIFO у USARTов. И при приёме пакетов иногда данные теряются, вызывая ошибку переполнения, OVERRUN. Вариант - присобачить один из каналов ПДП к приёмнику USART, и читать ПДП в память. Это как пример. Ибо из Ваших слов очень часто звучит "активно работать", но нет конкретных или приблизительных цифр. Поэтому трудно понять, сколько ядер и каких надо.

Share this post


Link to post
Share on other sites
16 minutes ago, haker_fox said:

Есть SGPIO, который может помочь в сборе данных с тех же энкодеров (сам обрабатываю три штуки на частоте 1 МГц). 

Не расскажите как вы это делаете ?

Share this post


Link to post
Share on other sites
13 minutes ago, dimka76 said:

Не расскажите как вы это делаете ?

Шесть линий конфигурируются на вход. Затем, данные с этих линий собираются на тактовой частоте 1 МГц в два буфера по 25-бит (SS_REG, длина в битах настраивается). Один теневой, второй активный (см. документацию на периферию). Каждые 25 бит вызываются прерывания (тоже настраивается), и я получая пять отсчётов с фильтрацией по пять бит. Фильтрация табличная. Голосование идёт по большему количеству логических сигнал в отсчёте. Далее полученные три пары сигналов в виде текущего отсчёта и предыдущего (по 6 бит) подаю на таблицу пересчёта. Таблица огромная, около 16 кБайт. Зато я успеваю обработать три энкодера, сигналы с которых поступают на максимальной частоте 100 кГц. Вот и всё)

З.Ы. Возможно, какие-то нюансы опустил, но мне простительно. Эту работу я выполнил три года назад, и к ней не возвращался.

З.Ы.Ы. Там же, кроме энкодеров, обрабатываются другие дискретные сигналы. Линий-то у SGPIO 16. 

З.Ы.Ы.Ы. Модуль можно связать с GPDMA, который у LPCшек может работать по связанному списку. Поэтому, при наличии фантазии и тщательного ознакомления с документацией, можно что-то соорудить)

Share this post


Link to post
Share on other sites
2 minutes ago, haker_fox said:

Шесть линий конфигурируются на вход. Затем, данные с этих линий собираются на тактовой частоте 1 МГц в два буфера по 25-бит (SS_REG). Один теневой, второй активный (см. документацию на периферию). Каждые 25 бит вызываются прерывания, и я получая пять отсчётов с фильтрацией по пять бит. Фильтрация табличная. Голосование идёт по большему количеству логических сигнал в отсчёте. Далее полученные три пары сигналов в виде текущего отсчёта и предыдущего (по 6 бит) подаю на таблицу пересчёта. Таблица огромная, около 16 кБайт. Зато я успеваю обработать три энкодера, сигналы с которых поступают на максимальной частоте 100 кГц. Вот и всё)

Спасибо !

Share this post


Link to post
Share on other sites
21.08.2021 в 20:33, rloc сказал:

Есть Linux, на который портируется LCNC.

Вот че-то я не догоняю, а линукс там вообще зачем? Ну я могу понять, когда нужен продвинутый сетевой стек, видеоускорители, на которые нет доков, какие-нибудь навороты с приложениями, которые трудно делать без ОС, но тут-то зачем, ради того, чтоб на питоне можно было че-то сляпать, ну е-мое, это уж как детский сад... ИМХО ОС здесь - это и есть самый большой костыль, к которому нужно делать подпорки из РТ-патчей, чтоб не упало совсем...

Edited by mantech

Share this post


Link to post
Share on other sites
3 часа назад, mantech сказал:

линукс там вообще зачем?

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

Share this post


Link to post
Share on other sites
56 минут назад, rloc сказал:

Для того, чтобы воспользоваться готовой программой управления

Что за "программа управления"?  Это типа стартового экрана мач3 что-ли? И ради этого тащить сюда Ось, которая явно не предназначена для реалтайма? Ну так себе задумка...

Share this post


Link to post
Share on other sites
7 минут назад, mantech сказал:

И ради этого тащить сюда Ось

Разговор ни о чем. Автор взялся воплотить baremetal, идея хорошая.

Share this post


Link to post
Share on other sites
25.08.2021 в 11:26, haker_fox сказал:

4. Активное чтение с флэшек SDMMC/USB. А насколько активное? Прямо во время работы приводов с энкодерами? А что, если считать G-коды, или что-там сейчас используют, в память, распарсить, и предоставить в максимально готовом виде для расчётных алгоритмов? Тогда, может быть, и читать не придётся. Просто я сам машиностроитель по образованию, и представляю, как работает станок с ЧПУ, но не представляю что=там можно активно читать с флешки. Могу чего-то не знать)

Текстовые файлы с G кодом бывают довольно увесистыми (сотни мегабайт). Особенно, для 3Д печати и каких-то нелинейных рельефов для фрезера. Поэтому чтение и разбор данных файла возможно только небольшими кусочками. Делать это надо прямо во время работы всех подключенных устройств и интерфейса юзера. Для, более менее, продуманной траектории надо читать и разбирать хотя бы 1 килобайт текста за 1 миллисекунду (1Мб/с). И чтение здесь не самый медленный процесс. Гораздо больше времени уйдёт на разбор текста. А для разбора как раз нужны большие мегагерцы процессора.

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.