LinuxCNC + Orange Pi (allwincnc)

[MX_Master]

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

Чё-ньть выйдет. С Raspberry Pi, BeagleBone и другими одноплатниками получилось. Cофт генерацию как минимум сделаем, но хочется дотянуться до более скоростных режимов. С применением аппаратной части ARM.

[MX_Master]

Так, вроде, все основные косяки GPIO драйвера я исправил. И провёл парочку небольших тестов с софт генерацией шагов. Результаты можно посмотреть ниже.

Создал новую конфигурацию из 3-х осей. BASE_PERIOD выставил 30000 ns. Процессор пашет на всех 1200 МГц. Одно ядро проца изолировано и на нём запущен бесконечный цикл. Настройки драйвера в HAL файле очень простые:

Код: Выделить всё

loadrt hal_gpio_h3 output_pins=3,5,7,8

addf hal_gpio_h3.read base-thread
addf hal_gpio_h3.write base-thread

net xstep           => hal_gpio_h3.pin-03-out
net ystep           => hal_gpio_h3.pin-05-out
net zstep           => hal_gpio_h3.pin-07-out

В результатах анализатора видно, что боль мень стабильная частота шагов - 16-17 КГц. И если я сделаю функцию reset_port как в драйвере LPT порта (parport), то частоту мы поднимем вдвое, т.е. до 34 КГц. Над функцией reset_port я поработаю на неделе и позже выложу результаты. Работу GPIO на вход я чёта забыл протестировать, выложу результаты в следующий раз.

Что я могу сказать, на данном этапе софт генерация шагов у нас удалась. Дальше будет тюнинг этого процесса. Могу поздравить всех кто ждал результатов, и себя в том числе

[nevkon]

В результатах анализатора видно, что боль мень стабильная частота шагов - 16-17 КГц.

Получается уже сейчас при микрошаге 1/8 и ШВП с шагом 5мм получится скорость перемещений порядка 3 м/мин (если я правильно посчитал). Это уже неплохо.

[fredy79]

А вот такой вопрос, возможно ли к оранж подключить ПЛИС, для генерации шагов и расширения портов ввода вывода, на подобе плат MESA для PC

[MX_Master]

Получается уже сейчас при микрошаге 1/8 и ШВП с шагом 5мм получится скорость перемещений порядка 3 м/мин (если я правильно посчитал). Это уже неплохо.

Да, всё верно. 17000 / (8*200/5) * 60 = 3187.5 мм/мин

А вот такой вопрос, возможно ли к оранж подключить ПЛИС, для генерации шагов и расширения портов ввода вывода, на подобе плат MESA для PC

Можно, пишете драйвер для LCNC и создаёте прошивку для Плисины/МК всё просто
Наверн, быстрее саму МЕСУ подключить..

[MX_Master]

Добавил в драйвер возможность инвертировать сигналы. Функционал аналогичен драйверу LPT порта.

Например, нам нужно инвертировать сигнал от домашнего концевика оси Х. Вместо

Код: Выделить всё

net min-home-x      <= hal_gpio_h3.pin-05-in

надо написать

Код: Выделить всё

net min-home-x      <= hal_gpio_h3.pin-05-in-not

Теперь пример инвертирования выходного сигнала DIR для оси Z

Код: Выделить всё

setp hal_gpio_h3.pin-07-out-invert 1
net zdir            => hal_gpio_h3.pin-07-out

Вощем, что касается настроек в HAL файле.. Я хочу сделать их абсолютно такими же как для LPT порта. Это значит, что имея готовый рабочий конфиг для материнки с LPT, можно получить конфиг для Orange Pi всего за пару минут. Нужно будет просто заменить строку вида "parport.0." на "hal_gpio_h3.", а также поменять номера пинов на желаемые. Когда драйвер выйдет стабильным, я могу накатать HTML страницу с конвертером HAL файла из LPT в GPIO.

[Serg]

Нужно будет просто заменить строку вида "parport.0." на "hal_gpio_h3."

Код: Выделить всё

loadrt hal_gpio_h3 names=parport.0 output_pins=3,5,7,8

[MX_Master]

Добавил в драйвер функцию reset_port как у LPT порта. Ничего не оптимизировал, сделал по аналогии. И тут же появилась главная проблема софт генерации - нехватка ресурсов проца Нельзя просто так взять и растранжирить время ядра проца. Ведь на этом же ядре крутятся и другие компоненты LCNC. Имея всего 1200 МГц, оптимизировать код нужно очень тщательно. Особенно, если он запускается каждые 30 мкс и чаще. Вощем, как и везде, будем оптимизировать..

Где-то читал, что в Machinekit'ах добавили поддержку многоядерных процессоров. Надо уточнить что там и как.. А в LinuxCNC такого, вроде, нет. Поэтому все компоненты крутится на одном ядре.

P.S. проверил входные сигналы и инвертирование пинов - всё работает

[Serg]

Где-то читал, что в Machinekit'ах добавили поддержку многоядерных процессоров. Надо уточнить что там и как.. А в LinuxCNC такого, вроде, нет. Поэтому все компоненты крутится на одном ядре.

LinuxCNC состоит из нескольких процессов, в некоторых из них работают несколько потоков:

Код: Выделить всё

 9179 pts/4    S+     0:00 linuxcncsvr -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9183 pts/4    S+     0:00 io -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9185 pts/4    S+     0:00 halui -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9191 ?        SLsl   0:00 /usr/bin/rtapi_app load trivkins
 9191 ?        SLsl   0:12 /usr/bin/rtapi_app load trivkins
 9236 pts/4    S+     0:00 milltask -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9239 pts/4    Sl+    0:10 /usr/bin/python /usr/bin/gmoccapy -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9239 pts/4    Sl+    0:00 /usr/bin/python /usr/bin/gmoccapy -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9239 pts/4    Sl+    0:00 /usr/bin/python /usr/bin/gmoccapy -ini /home/serg/linuxcnc/configs/laser/laserplane.ini.expanded
 9248 pts/4    Sl+    0:00 /usr/bin/python /usr/bin/gladevcp -x 54526035 -c gmoccapy.override -u override.py override.glade
 9248 pts/4    Sl+    0:00 /usr/bin/python /usr/bin/gladevcp -x 54526035 -c gmoccapy.override -u override.py override.glade

ядро Linux само в состоянии распределять их по разным ядрам, если это потребуется, для этого никаких специальных действий предпринимать не требуется.

[MX_Master]

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

Сейчас меня интересует вопрос - как, всё-таки, полностью убрать хозяйственные операции ядра Linux с изолированного ядра проца? В прошлый раз, когда я проверял ногодрыг на изолированном ядре (в режиме "nohz_full"), было видно, что ядро Linux всё равно отнимает у нас по 15мкс каждую секунду. Эта задержка даёт нам возможность плавно генерировать шаги только до 66 КГц. На частотах выше будет едва заметная пауза каждую секунду. Но хочется её убрать.

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

Пояснения:
Смысл софт генерации шагов на отдельном ядре процессора в том, что мы сразу убиваем двух зайцев.
Освобождаем LinuxCNC от этой трудоёмкой задачи. А также повышаем частоту вывода шагов.

[Serg]

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

[MX_Master]

Это я понимаю, будем тестировать всё на местах, в данный момент ответить за базар не могу

Немного покопался в интернетах.. Вижу, что несколько человек ведут работу над патчем под названием "task_isolation". Свежая версия патча добавлена 3 ноября - https://patchwork.kernel.org/patch/10040801/. В описании говорится, что режим "nohz_full" это, всё-таки, не полная изоляция процесса от ядра. Что, в общем-то, и видно из осциллограмм с простым ногодрыгом. Патч призван максимально приблизиться к жёсткой изоляции процесса от прерываний ядром Linux.

Сергей, что вы об этом думаете? Стоит ли двигаться в этом направлении?

[going]

как, всё-таки, полностью убрать хозяйственные операции ядра Linux с изолированного ядра проца?

Вопросом на вопрос!
А как можно отловить, что происходит и каким процессом в этот "нехороший момент" ?? И на какой период времени??

[Serg]

Стоит ли двигаться в этом направлении?

Патч не панацея, нужна ещё соотв. поддержка в железе. Увы, Orange Pi и аналоги - это не тот случай. На этих платформах может помочь только значительное увеличение тактовой частоты процессора, шины, памяти, ну или отказ от программной генерации шагов.

[MX_Master]

Вопросом на вопрос!
А как можно отловить, что происходит и каким процессом в этот "нехороший момент" ?? И на какой период времени??

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

Патч не панацея, нужна ещё соотв. поддержка в железе. Увы, Orange Pi и аналоги - это не тот случай. На этих платформах может помочь только значительное увеличение тактовой частоты процессора, шины, памяти, ну или отказ от программной генерации шагов.

Для ARM и ARM64 этот патч портирован. Да, и чего-то аппаратного он в явном виде не касается (детально не смотрел). Это, скорее, программная перенастройка поведения ядра Linux. В общем, изучу вопрос детальнее..

[Serg]

Да, и чего-то аппаратного он в явном виде не касается (детально не смотрел).

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

[Крафтер]

Может лучше мой код на какую-нибудь популярную плату STM32F407 портируешь? В принципе он уже рабочий, алюминий пилить хватает

[MX_Master]

Может лучше мой код на какую-нибудь популярную плату STM32F407 портируешь? В принципе он уже рабочий, алюминий пилить хватает

Дык, тебе и флаг в руки, здесь никто еще полноценных контроллеров на F4 не делал.

[arkhnchul]

"не делал" в смысле самостоятельно не писал?)

[MX_Master]

"не делал" в смысле самостоятельно не писал?)

А чё, разве кто-то на форуме выкладывал исходники какого-ньть ЧПУ контроллера на STM32F4 ?