cnc-club.ru

В связи с популярностью одноплатных ПК, пора подумать о том, что интерфейс LinuxCNC должен учитывать возможности мобильных видео чипов. Как пример, отрисовку траектории желательно делать средствами OpenGL ES. А в целях убыстрения работы интерфейса желательно перескочить с python на нативный C. Кто что думает по этому поводу?

MX_Master, тема интересная, однако возникают
Вторые мысли вслух - а насколько уж так сильно востребована визуализация на самом станке?

Программист, готовящий УП в какой-либо среде разработки обязан провести эту визуализацию, дабы проверить и окончательно убедиться, что подготовленную им УП можно передавать в производственный цикл. А вот, насколько так уж нужна эта визуализация в процессе производства, оператору станка?

Еще более явно этот вопрос касается любителей, как раз тех, кто чаще всего использует ARM в своих, часто собственноручно собранных станках. Мне как-то не совсем понятно, зачем мне, подготовившему УП, уже видевшему эту визуализацию в процессе создания УП, потом, после переноса в контроллер станка еще раз запускать эту визуализацию? Я больше за то, чтобы в УП была нумерация строк, а контроллер станка непрерывно фиксировал/запоминал номер выполненной строки. Это дает возможность в случае сбоя знать с какого места можно продолжить выполнение.

Все вышесказанное ИМХО.

Мастерю писал(а):Программист, готовящий УП в какой-либо среде разработки обязан провести эту визуализацию, дабы проверить и окончательно убедиться, что подготовленную им УП можно передавать в производственный цикл. А вот, насколько так уж нужна эта визуализация в процессе производства, оператору?

Запаришься в САМ программе усе моделировать. Например: для токарки нужно усе оправки нарисовать, показать под каким углом державка стоит, а если какая либо хитрая оправка то и ее рисовать и тд... На токарке довольно часто: зажимаю заготовку, загружаю УП, привязываю ноль и гоню резец в конец обработки. Смотрю на визуализацию и на реальную позицию инструмента.
надо было внутри детальки проточить канавку. Для этого нужно было руками повернуть детальку так чтобы зашел резец, включить обороты и проточить. Смысла писать УП для этого не было. По визуализации и протачивал.
Далее визуализация помогает на станке стартануть с нужной строчки УП. На визуализации подсвечивается.
На плазме постоянно по визуализации ловим откуда резать.
Визуализация на станке удобная штука, можно жить конечно и без нее.

Вопрос о показе траектории не стоит, потому что он уже решён. Кому не нужно, просто, выключают это дело и всё (: Как правильно заметил Александр, когда составляешь мини УП прям на стойке, или отлаживаешь какую-то операцию вручную, визуализация реально рулит.

Я, просто, планирую фронт дальнейших работ по ARM платкам с LinuxCNC на борту. Если такой открытый проект будет неинтересен пользователям, знатокам и коллегам-прогерам, я сделаю его самостоятельно, но оставлю его для своего проекта казахского сименса (:

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

Короче говоря, в качестве эксперимента попробую на чистом C и GTK+ накатать шаблончик тырфейса. У GTK+ с какой-то 3.22.x версии есть возможность рисовать средствами OpenGLES. Добавлю в отрисовку кучу примитивов и посмотрю как это будет работать на апельсиновом MALI 400.

ага и счет для сбора денеххх

Что то мне кажется, не зря на linuxcnc.org ребята всё активнее и активнее "толкают" qtpyvcp.

NKS писал(а):Что то мне кажется, не зря на linuxcnc.org ребята всё активнее и активнее "толкают" qtpyvcp.

Они не собираются переходить на мобильные платформы (: По крайней мере, не сейчас. QT взят на вооружение, потому что с ним легче работать, есть продвинутый задел на мультиплатформу + поддержка OpenGLES. Но при этом QT ни разу не лёгкий и нифига не быстрый.

Maxekb77 писал(а):ага и счет для сбора денеххх

Вроде, взрослый человек, а постоянно чем-то недоволен (:

MX_Master писал(а):Они не собираются переходить на мобильные платформы (: По крайней мере, не сейчас. QT взят на вооружение, потому что с ним легче работать, есть продвинутый задел на мультиплатформу + поддержка OpenGLES. Но при этом QT ни разу не лёгкий и нифига не быстрый.

По этим параметрам GTK+ и QT равнозначны, вопрос чисто религиозный.

P.S. подобные метания до добра не доводят...

По идее, для мобильной платформы юзать бы надо не QT/GTK, а что-то попроще да побыстрее (:

А в идеале, надо начать не с выбора GUI и прочих кнопочек, а прямо с визуализации. И если аппаратная отрисовка будет не так быстра, как я ожидаю, тему про QT/GTK можно смело сворачивать ))

MX_Master писал(а):По идее, для мобильной платформы юзать бы надо не QT/GTK, а что-то попроще да побыстрее (:

Xt, Motif, Fltk - куда уж проще и быстрее?..

MX_Master писал(а):А в идеале, надо начать не с выбора GUI и прочих кнопочек, а прямо с визуализации.

Рисуй прямо во фреймбуфере - куда уж быстрее... А кусок фрембуфера засунуть в любой "контейнер" особых проблем не составит.

Кстати, по поводу отрисовки, vtk backplot для QTvcp на linuxcnc.org оценивают (судя по отрывочным постам),как "гораздо более шустрый чем старый гремлин".

Зная как там это всё внутри устроено я чёта сомневаюсь в компетентности этих оценивателей...
Кстати, кто-нибудь тут уже использовал профайлер для исследования имеющейся отрисовки?
И кстати, а кто-нибудь тут понял, что я только что спросил?

Администрация запрещает материться (в любом виде)

UAVpilot писал(а):И кстати, а кто-нибудь тут понял, что я только что спросил?

Выявить наиболее затратные по ресурсам места, чтобы понять где и на что уходят ресурсы или что то другое имелось ввиду?

NKS писал(а):Администрация запрещает материться (в любом виде)

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

UAVpilot писал(а):Кстати, кто-нибудь тут уже использовал профайлер для исследования имеющейся отрисовки?
И кстати, а кто-нибудь тут понял, что я только что спросил?

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

Внутрь текущей визуализации я не лез, ибо я не большой любитель python

Профайлер - слышал, но не видел (:

MX_Master писал(а):Да, вроде, и без исследований видно, что с отрисовкой что-то не так.

В каком именно месте?.. Ну чтоб понимать чего именно ему не хватает и как исправить...

Без профайлера могу только гадать (: лично мне не нравится, что за отрисовку отвечает python

Немного побродил по тырнету и наткнулся на uGFX и LittlevGL, оба умеют работать с framebuffer. Выглядят красиво, жрут очень мало (: