cnc-club.ru

DmitriiNT писал(а):У меня заказчик есть один (оборонный завод в Туле), просит робота для покраски своих изделий. Вопрос не в тему конечно, но все же, - куда в hale завести абсолютные координаты по осям, по протоколу SPI? Как linuxcnc узнает, где находится сустав. Позже, конечно, я ветку открою в разделе роботов, там и будем обсуждать.Но сейчас, хтя бы куда копать?

Абсолютные энкодеры? Какой у них протокол связи в оригинале? Диф. сигнал или TTL?

Протокол связи у них закрытый, скорее всего.

DmitriiNT писал(а):У меня заказчик есть один (оборонный завод в Туле), просит робота для покраски своих изделий. Вопрос не в тему конечно, но все же, - куда в hale завести абсолютные координаты по осям, по протоколу SPI? Как linuxcnc узнает, где находится сустав. Позже, конечно, я ветку открою в разделе роботов, там и будем обсуждать.Но сейчас, хтя бы куда копать?

Вот здесь тема Lcnc с абс энкодерами Контроллер YSSC2P для серво Mitsubishi SSCNET-II (MR-J2S-B) #1

DmitriiNT писал(а):armbian-build рулит . 10 часов на виртуальной машине. Это что-то....

i7-3,6 Ггерца, 16Гиг ОЗУ + Linux на борту + QEMU(8Г ОЗУ, 6 потоков) - сборка образа первый раз 1,5 часа. Пересборка 30 мин. Ccache задействован.

DmitriiNT писал(а):С эти армбиан блин..., видимо его один человек поддерживает

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

Ох....давненько не заглядывал в эту ветку....я так понял уже есть рабочий вариант драйвера сопроцессора....у меня плата orange pi 2e. Где то должны быть пару старых образов для неё....если не удалил. Собственно вопрос, arisc драйвер будет работать на том образе? Версия ядра влияет на работу сопроцессора и драйвера? Ну и собственно есть где то подробное описание или ман по тому что умеет драйвер + сопроцессор и как это дело настраивать? Надо например настроить конфиг 3-х осевого фрезера. Есть 3 датчика home, стандартное управление шпинделем по pwm сигналу, 3 шаговика (ну или сервошаговика, вобщем step/dir сигналы)...вроде джентельменский набор перечислил.....задача связать это в кучу и повесить на сопроцессор, чтобы ездить быстро и с хорошей дискретностью...есть желающие помочь?

Забыл сказать....сборки образов делать не умею. Есть небольшой опыт настройки linuxcnc для хоббийных станков на классических PC через lpt. Ничего особенного, шаговики, шпиндель по шим управляется и 3 датчика для хомления....имею общее представление что такое linuxcnc и hal....в принципе с linux системами знаком давненько, но как юзер, а не разработчик...вобщем что то знаю, но в дебри исходников не лезу, пока не освоил....

Хотел ещё сказать свое мнение по данному проекту.....я считаю, что если получится задействовать сопроцессор в апельсине для реалтайм задачь, то получится очень гибкое и бюджетное решение для чпу самодельщиков, хоббийщиков и т.д. По сути эта плата заменит пк и те же платы месы...хотя бы в рамках базовых конфигов типа такого что я выше писал, это уже будет ой как интересно для массового применения...энкодеры, оптические линейки и т.д. это уже по сути экзотика для обычного хоббийного станка, такое еденицам нужно на самом деле. Мне например важно чтобы станок работал сутками без ошибок, с адекватной точностью и давал нужный результат. А как это будет достигнуто по сути не важно. Если будет софт работать стабильно, то пользователям будет абсолютно все равно на то как он написан этот софт с культурой производства или через ж...пу. Главное чтобы работало. И когда мне говорят что lpt это лажа и прошлый век, я отвечаю просто....оно работает и мне пофик что прошлый век. Есть живое сравнение. 2 станка, на одном степмастер плата развязки. На другом китайская за 500р. Оба выдают идентичный результат...и это реальность. Так вот плату степмастер многие хвалят, а про китайскую плюются....но суть понятна. И то и другое работает, если не нарукожопить...Дайте жизнь проекту и народ потянется...

Я, кстати, тут с видеодрайвером балуюсь на ядре 5.4 + X11. Завёл-таки на нём аппаратное ускорение. Но что-то прям очень медленное "ускорение" получается. На софте побыстрее через X11 всё пашет. Вощем, для работы OpenGL с ускорением, поставил прослойку gl4es. Шестерёнки glxgears чутка быстрее крутятся, но LinuxCNC + Axis ваще не стартует. Короче говоря, для работы Axis можно аппаратное ускорение дальше не телебонькать. Софт рендеринг вполне приемлемо справляется с отрисовкой траектории. Единственный прирост производительности, который я видел в интернетах, был на прямом выводе в fbdev и на Wayland (вместо X11). XFCE, который используется в арбмиан, с Wayland в данный момент не работает. Эта связка у разработчиков только в планах. Так что и здесь ловить нечего. Прямой аппаратный вывод в fbdev, канеш, можно юзать. Желательно, ваще без X-ов. Только нужно написать под это дело полностью новый интерфейс на чём-то вроде EGL/GLES.

Проще говоря, насчёт аппаратного видео вывода для траектории в LinuxCNC всё не так оптимистично.

antoxa-kylibin писал(а):orange pi 2e

https://cnc32.ru/downloads/9/obraz-dlja ... us-2E-v564
+
https://cnc32.ru/news/17/drajver-dlja-r ... r-H3/H2/H5
=
профит

MX_Master писал(а):Прямой аппаратный вывод в fbdev

fbdev и прямой аппаратный вывод несколько разные вещи. fbdev - это просто область памяти, где одному виртуальному пикселю соответствует одно 32-битное слово. И так как эта область в системной RAM, то там всё рисуется центральным процессором попиксельно, единственное, что там может быть аппаратного - это использование DMA для формирования горизонтальных линий. Это ровно тоже самое, что и софтверный "рендеринг" во фреймбуфере видеокарты, только видеокарта автоматически переносит его содержимое на экран.

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

Кстати, один добрый человек c армбиан форума поделился своим старым образом для OPi PC. Образ на старом ядре v4.19.38. Ну и все версии компонентов тоже старее. На этом образе он настраивал аппаратку точ также как я на новом. Вощем, только что всё проверил. Опа, а на его образе аппаратное EGL/GLES ускорение робит в 3 раза быстрее! В 3 раза, Карл! При этом процессор практически свободен. У него там даже Quake2 собран и вменяемо робит!

Мда.. что-то там такое в новых ядрах и иксах понаписали, и это что-то реально притормаживает связку для аппаратного вывода. На старых ядрах версии 4 всё робит повеселее.

MX_Master писал(а):Опа, а на его образе аппаратное EGL/GLES ускорение робит в 3 раза быстрее! В 3 раза, Карл! При этом процессор практически свободен. У него там даже Quake2 собран и вменяемо робит!

И ядро у него там с RT патчем?..

Вестимо, что нет И это может быть причиной, а может и не быть. Надо проверить на обычном свежем образе без RT. Канеш, для наших целей образы без RT бесполезны, но сравнить, всё-таки, надо.

Ведь можете когда хотите) .... я когда пробовал образ в работе, меня отрисовка axis устраивала по своей производительности, проблема в большом значении base period от которого зависит производительность stepgen и др. компонентов системы. Если arisc драйвер + сопроцессор решает эту проблему, так может не мучить уже этот Mali 400? Опять же, у меня плата с 2гб ОЗУ на борту, может это ещё даёт запас по ресурсам...хз...Если даже эту версию заставить работать как надо, без аппаратного ускорения видео, то уже будет хороший результат...

UAVpilot писал(а):И ядро у него там с RT патчем?..

Только что проверил на аналогичном ядре (v5.4.20) без RT патча. И.. результат точ такой же медленный как на ядре с RT патчем. Теоретически это значит, что RT патч на аппаратный видео вывод влияет слабо. Ну а практически - или я где-то что-то забыл настроить, или в новых ядрах и иксах действительно есть что-то новое

Суть в том, что если ты сам пересобираешь ядро (например с RT патчем), то ты автоматически теряешь проприетарный "драйвер" для Mali, ибо он вроде и по сей день поставляется только в виде готового модуля под конкретную сборку ядра. Если это действительно так, то поставщик модуля либо криворучка (поучится можно у NVidia и AMD), либо патологически жаден.

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

Проверил аппаратный видео вывод на том же свежем образе системы, но со старым ядром v4.19.38. Производительность такая же хреновая. Вощем, RT патч и версию ядра можно выкинуть из уравнения. Походу, связка иксов с драйвером armsoc является причиной притормаживания. Надо поставить предыдущую версию иксов и проверить.

UAVpilot писал(а): MX_Master писал(а):
Опа, а на его образе аппаратное EGL/GLES ускорение робит в 3 раза быстрее! В 3 раза, Карл! При этом процессор практически свободен. У него там даже Quake2 собран и вменяемо робит!


И ядро у него там с RT патчем?..

Интересный ход мысли.
РТ патч должен внести сумятицу в процесс вывода. Согласен. Но имеются нюансы.
Фирма разработчик драйвера mali для наших плат
https://developer.arm.com/tools-and-sof ... eo-drivers
https://developer.arm.com/tools-and-sof ... ard-kernel
рекомендует собирать драйвер своим компилятором и об этом есть инфа на сайте:
https://developer.arm.com/tools-and-sof ... e-compiler
Который потом работает с великими привилегиями и чихать он хотел на патчи, тем более РТ патч его не трогает.
Т.е. вопрос в том как это собрано.

MX_Master писал(а):Опа, а на его образе аппаратное EGL/GLES ускорение робит в 3 раза быстрее! В 3 раза, Карл!

Фраза как раз об этом. Как это собрано.

Хочется сделать аппаратное ускорение? Хорошо. Это надо собрать драйвер с поддержкой ДМА.
Тогда надо позаботится о возможности подвинуть этот ДМА, когда пришло время выполнится РТ процессу.
Подвинуть fbdev, gpu, когда пришло время выполниться РТ процессу.
Кстати:

UAVpilot писал(а):fbdev и прямой аппаратный вывод несколько разные вещи. fbdev - это просто область памяти, где одному виртуальному пикселю соответствует одно 32-битное слово. И так как эта область в системной RAM, то там всё рисуется центральным процессором попиксельно, единственное, что там может быть аппаратного - это использование DMA для формирования горизонтальных линий. Это ровно тоже самое, что и софтверный "рендеринг" во фреймбуфере видеокарты, только видеокарта автоматически переносит его содержимое на экран.

"Дядя Серёжа" частенько зрит в корень, надо отдать должное ему за это.

Всё это задачи уровня ядра. Игра с драйверами вне этого контекста - один большой вопрос.
Аппаратное ускорение <--> РТ задача, это компромисс о том что важнее. Вы уж определитесь.
MX_Master, Михаил, ты сделал всё возможное, что бы arisc контроллер работал.
Респект и уважуха.
Но это предел для контроллера. Надеюсь мы понимаем о чём речь.
Я смотрю на эту работу, как на фундамент для дальнейшего развития!
Искренне надеюсь, что ты продолжишь развивать идею на stm32 в связке по spi или ethernet.

going писал(а):на stm32 в связке по spi или ethernet.

Кстати а почему не USB? Для mach полно плат с USB, а для LCNC как-то не очень - все spi да ethernet.
Я вот себе такую макетку раздобыл: Там сейчас запаян pic32mx795f512l, как приедет pic32mk1024mcf100 заменю его.
А пока на mx795 USB CDC завел - вроде работает.

going писал(а):РТ патч должен внести сумятицу в процесс вывода. Согласен. Но имеются нюансы.
Фирма разработчик драйвера mali для наших плат

Насколько я в теме (хоть не особо и слежу за ней ) этот драйвер по ссылкам - неофициальный драйвер, который поддерживает далеко не все возможности Mali, ибо сделан не по лицензионным спекам, а посредством реверсинжинеринга.
Официальный-же поставляется в виде уже бинарного модуля (.ko) гвоздями прибитого к конкретной сборке ядра. И если ядро даже просто пересобрать без изменений исходников, то этот .ko уже не загрузится под новым ядром, ругнётся что-то там про несоотв. версии/сигнатуры.