baritono

Нет ни диска, ни G-кодов, ни синхронизации. Один поток с управляющей программой на C, на другом индикация и логи. У второго доступ к данным первого только на чтение.

Камни эти у меня лежат без дела. Кроме дрыганья ногами пока ничего не нужно. Синхронизировать потоки тоже не нужно, хотя при когеррентном кэше это элементарно. Данный камень довольно давно поддерживается Linux mainline kernel, так что и без доков и многое другое можно. А станок стоит как 20 таких SBC.

Большое спасибо, картинка проясняется. По одному потоку на ядро и нужно, без какого-либо шедулинга. Интересно, отличается ли Ваш опыт от опыта GenaSPB. Конечные цели слишком далеко лежат, чтобы обсуждать их здесь.

Допустим, есть желание перенести сравнительно несложную программу управления станком на многоядерный ARM - например, Rockchip RK3399. Но не заморачиваться при этом с RTOS, т.к. управление задачами и периферия не нужны. Насколько я понимаю, проще всего взять исходники какого-нибудь загрузчика, выбросить лишее, добавить нужное. Но в многопоточность загрузчик вряд ли умеет. Кто-нибудь делал запуск потоков "руками" на других ядрах в ARM? Или хотя бы где почитать про это? Гугление не помогло, вопросы находятся, ответы нет.

Шилд Protoneer купил в магазине в Москве. MKS Gen я не взял, потому что не было чёткого представления о потребностях, и хотелось иметь возможность менять драйвера. Цена контроллера в любом случае - копейки, в сравнении с общей стоимостью станка. Насчёт встроенных функций Ардуино - чем конкретно плохо то, что ими приходится пользоваться? Мне они показались достаточно удобными. Меняется не только острота, но и условия работы инструмента, и довольно быстро. Это долго объяснять в деталях, но, например, при завершении сверления стенки профильной трубы инструмент может резко заклинить из-за выпадания высверленного участка. Хотелось бы такие вещи обнаруживать, не доводя до аварийной остановки двигателя. Не могу пока сказать, какая частота там нужна, вряд ли все 50МГц, но легко может быть поболее 100Гц. Насколько "монструозный" контроллер мне совершенно неважно, ибо устройство не серийное. Будет сделано лишь несколько штук для собственных станков. На шаговике с энкодером и гибридным драйвером (а речь о нём) это возможно.

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

Я зарабатываю программированием уже 25 лет, а с опытом постепенно понимаешь преимущества концептуально простых систем. Перестаёшь бросаться использовать всё, что есть, а смотришь на свою конкретную задачу. Которая может и отличаться от типичных, под которые создавалась железка или среда. Пока я не вижу серьёзных препятствий к тому, чтоб сделать требуемое суперлупе. Поэтому усложнять систему использованием перефирии не хочу. Я не собираюсь заниматься программированием МК регулярно, поэтому мне удобнее поддерживать такую, понятную мне систему. Если что-то меняется раз в пару месяцев, неудобно копать каждый раз доки API, свой код в старом добром цикле понятнее. В чём по-вашему особая сложность регулировки оборотов в зависимости от тока? Мгновенного отклика и идеальной точности, как при управлении бесщёточником, здесь не требуется. Должно хватить простенького PID-регулятора.

Интересно, на Ардуине Мега такой фичи нет. Но невозможность делать вычисления в реальном времени - это серьёзное ограничение. Не хотелось бы его без крайней необходимости вносить. Может потребоваться, например, регулировать подачу и обороты в зависимости от остроты инструмента. То есть, управлять движением двигателя оси Z и шпинделя, в зависимости момента (тока) на на шпинделе. Как это реализовать без суперлупа или прерываний по таймеру? На ядро, управляющее обработкой, я точно ничего больше вешать не буду, по целому ряду причин. Если будет нужно что-то, что способно нарушить работу главного цикла, будет делаться остановка обработки с последующим возобновлением, или поставлен двухядерный или отдельный проц. Обратил уже в процессе обсуждения, буквально сегодня, внимание на Arduino Portenta на STM32H7. Возможно, это и есть то, что нужно.

За счёт чего аппаратные прерывания по таймерам будут существенно быстрее проверок счётчика циклов на кратность константам (мой софтовый "таймер")? И даже если будут, я бы не хотел усложнять систему из-за недетерминированности поведения, необходимости запрета прерываний на ответственных участках и т.п. Так у меня если "таймер" запаздывает, просто выдаётся предупреждение и сообщение (в отладочном режиме) - на сколько именно. А если аппаратный таймер сработал, а прерывания запрещены, потому что другой ещё не обработался - что будет? Частота импульсов, бывает, зависит от вычислений, в т.ч. и динамических с плавающей точкой. У меня сейчас аналогичная конструкция, только на Меге с шилдом. Плюс ещё один шаговик мощный, с внешним драйвером. Чем плохо делать через скетчи? Си оно вроде и в Африке Си. Таймаутов как таковых у меня нет, вместо этого в начале loop() берётся значение micros() и вызываются "таймеры", время вызова которых подошло. Когда "таймер" завершается, он устанавливает себе время следующего запуска. Движки осей сами по себе может и не тормозили бы, но есть ещё мощный движок с 50KHz пульсом, плавный разгон/останов его, датчики, в дальнейшем возможно придётся ещё ток на ходу мерять и управлять движением. Может быть всё это можно и на Меге сделать, но хотелось бы с запасом и без ухищрений.

Вкусно всё это выглядит. Но тактовая в 3 с лишним раза ниже, чем у STM32H7, несколько смущает. Как и отсутствие аппаратной плавающей точки. В целом устройство оставляет впечатление варианта "для бедных". Меня цена, в общем, не волнует, продукт не серийный.

А почему не STM32H7, он вроде мощнее? Таймеры - штука хорошая, но в Ардуине я вполне обошёлся, эмулируя их софтово. А почему не STM32H7, он вроде мощнее? Таймеры - штука хорошая, но в Ардуине я вполне обошёлся, эмулируя их софтово. Девайс только для себя, максимум несколько штук. И не хотелось бы вкладываться в изучение сравнительно малоиспользуемой платформы. STM32 Nucleo вроде есть в продаже, даже в магазинах в Москве. Или это мы остатки доедаем? Миландровские МК сильно хуже китайских?Вот на такие, например, устройства с STM32 смотрю: https://www.chipdip.ru/product/nucleo-h743zi2

Шаговики сейчас работают в режиме 1600 шагов на оборот, один из них на максимальной скорости (до 2000 об/мин). То есть, более 50 тыс. шагов (там ещё понижающий редуктор стоит). Есть желание заменить этот быстрый на сервопривод, которому не нужны будут шаги, но это пока только желание. Эти функции лежат на драйверах двигателей. Ток, может быть, будет нужно мерять, но чисто порогово - обнаружить близость к предельному.

Сделал прототип специализированного ЧПУ-станка на Ардуине Мега. Всё бы ничего, но проц подтормаживает. Запаздывает управление несколькими шаговиками на приличной скорости и микрошаге, реакция на датчики. И это ещё прототип, на рабочем варианте скорости будут выше. Подскажите, на какой "взрослый" микроконтроллер лучше заменить? По периферии ничего особенного не надо, кроме GPIO ничего не используется, максмум будет I2C. Главное - скорость проца и минимум гемора с разработкой под Линкусом из командной строки. Загрузка-отладка через UART, без проприетарных IDE и тому подобного. Смотрю на STM32 и платы на его основе - правильно? Ещё смотрю платы вроде Raspberry Pi (лежат несколько без дела разных видов), но не охота возиться с Линкусом на станке, нравится простота работы с микроконтроллером.

Это отфильтровывается, но при такой частоте измерений получается слишком медленно.

Попробовал я этот VL6180. Зря потраченное время, увы. Точность всего 1 мм., но главное - нестабилен (скачут показания) и довольно медленно работает - порядка 10 Гц макс. частота. Сделал контактный датчик из подшипика, линейной направляющей с кареткой и двух винтиков в качестве контактов - работает как часы.