cnc-club.ru

Доброго времени суток!

Хотелось бы привлечь внимание форумчан, активно участвующих в развитии проекта LinuxCNC, к проблеме открытия больших файлов УП.
Речь идёт о файлах, размером более 400Мб, количество строк кода ~18.5млн. Проводил опыты на доступных мне ПК, что-бы понять с какими сложностями столкнулся Илья. В эксперементах приняло участие два ПК:
- моноблок HP3420 на базе процессора "Intel(R) Pentium(R) CPU G840 @ 2.80GHz" + 4 Гб ОЗУ + sata2 SSD 128Gb, далее ПК-1
- системный блок на базе "рязань" 3400 + 8Гб озу (доступно 6Гб, т.к под видео выделено 2Гб) + sata3 2Tb Hitachi, далее ПК-2

Было сделано два "подхода к снаряду":
1. Установка ОС по умолчанию (1Гб swap), далее опыт-1.
2. Установка с заданием раздела swap 32Гб, далее опыт-2.

Результаты.
Опыт-1:
* ПК-1 не смог загрузить УП ни в одном из GUI - LinuxCNC прекращал работу и ругался на какие-то строки у себя в исполняемых файлах. Дополнительно открывал УП текстовыми редакторами, что в поставке дистра - на глухо зависал ПК-1. Установил Emacs - время открытия файла в районе 2-3 секунд, при этом сохраняет и позволяет редаткировать без каких-либо фризов системы.
* ПК-2 загрузил УП только в GUI TkLinuxCNC, Axis или Gmoccapy падали в ошибку минут через 25... ОЗУ + swap загружены на 100%

Опыт-2:
* ПК-1 GUI TkLinuxCNC: загрузка УП примерно 2 минуты, начало исполнения УП после нажатия "старт" примерно через 2.5 минуты. Axis или Gmoccapy - время открытия файла в районе 95 минут. Занято 24Гб раздела подкачки. После открытия УП, система довольно сильно тупит. Запускать на выполнение не стал.
Видео с GUI TkLinuxCNC - ставьте ускорения на два.
https://youtu.be/gYoiHyfdDEs

* ПК-2 GUI TkLinuxCNC: загрузка УП примерно 8 секунд, начало исполнения УП после нажатия "старт" тоже примерно 8 секунд.Axis или Gmoccapy - время открытия файла в районе 30 минут. Занято 16Гб раздела подкачки[/u] После открытия УП, есть некоторая тормознутость в интерфейсе ОС. УП так-же стартует через 30-35 минут после нажания "старт".
Видео с GUI TkLinuxCNC - тут всё быстро.
https://youtu.be/dlKjxaDUNpQ

Исходя из эксперемента, в личке начали прикидывать нужный под задачу ПК.. получается машина, в разы лучше, чем используемая на данный момент для создания УП.. 1200 сокет 10/11 поколение корки 5, 32 Гб ОЗУ, ssd Nvme...По моему это прям совсем перебор..

Можно ли как-то скрестить "турбо-загрузку" TkLinuxCNC c Axis, Gmoccapy? В идеале бы - как Emacs.. что-бы ПК-1 хватало для решения таких задач. Готов проводить тесты/эксперементы на указанных выше ПК.
Спасибо.

А если в г-код добавить первой строчкой - решает вопрос?

Нет, не решает. К сожалению. Для этого и ставил Emacs на ПК-1
Я не программист.. глянул исполняемый файл axis - на сколько я понял, Axis, Gmoccapy используют либы "питона" для работы с файлами.
Файл с УП предоставить без разрешения Илья не могу, а написать цикл для генерации разумного g-code мозгов не хватает.. и есть подозрение что на питоне писать генератор не нужно... С++.. Как-бы идея сразу появляется.. оснастка/инструмент для тестирования в виде генератора примитивной УП с заданием количество строк кода.

В качестве редактора кода вполне приемлем vim - он и блоки кода сворачивать умеет (не в стоковой с LCNC поставке, а в более свежей версии), и работает быстро. Что отдельно хорошо - режим редактирования текста и просто режим просмотра - разные вещи и для нас, с ж-кодом, очень полезные.
А про TkLinuxCNC GUI - можно больше подробностей и на русском? http://linuxcnc.org/docs/html/gui/tklinuxcnc.html Прописать в ini DISPLAY = tklinuxcnc, оно же DISPLAY = tkemc, не сложно, но уже минут десять не могу найти начала (провести хоминг). И в окошке Плоттер у меня ничего не отрисовывается.

iMaks-RS писал(а): ↑ Я не программист.. глянул исполняемый файл axis - на сколько я понял, Axis, Gmoccapy используют либы "питона" для работы с файлами.

Да python это всё переварит и не чихнёт.
Вопрос в разборе файла, но насколько я видел linuxcnc файл перед запуском не разбирает и не проверяет, это делается только для целей визуализации. Если её выключить, то и проблем не должно быть. Вроде бы.

А строчку в начало добавить, для этого никаких редакторов не надо.

Плоттер тоже пустой, с датчиками считерил.. прописал в ини файл - в раздел traj: NO_HOMING_FORCE = 1

alex_sar писал(а): ↑ linuxcnc файл перед запуском не разбирает и не проверяет

Дилетантский вопрос: что тогда означают сообщения, вроде, возле строки 100500 начало или конец дуги не совпадает с заданным радиусом?

iMaks-RS писал(а): ↑ Плоттер тоже пустой, с датчиками считерил.. прописал в ини файл - в раздел traj: NO_HOMING_FORCE = 1

Я бегло попытался осилить описниае, что по ссылке - плоттер показывает пройденный путь. Потому, видимо, и запускается быстро. Но по моим меркам 450 метров - еще далекая перспектива. Пока укладываюсь в 3-7 метров. Когда надо - вручную сокращаю файлы и программы, организуя циклы.

А большой файл сгенерировать не вопрос - скормите комплектному image-to-gcode графический файл и задайте должные настройки дискретизации и можно получить нечто огромное.

daiman444 писал(а): ↑11 авг 2022, 18:35

alex_sar писал(а): ↑ linuxcnc файл перед запуском не разбирает и не проверяет

Дилетантский вопрос: что тогда означают сообщения, вроде, возле строки 100500 начало или конец дуги не совпадает с заданным радиусом?

я туда не смотрел, возможно правда читает и парсит во внутренний формат...

точно знаю что некоторые ошибки очевидные только в работе выдает .типа выхода за края рабочей области.

На здешнем форуме нет активных разработчиков LinuxCNC. Надо писать в issues гитхаба LinuxCNC. Но не факт, что кто-то отреагирует, ибо указанное ТЗ, по моим меркам, довольно большое.

Лично моё мнение - LinuxCNC уже давно перестала быть чем-то свободным по масштабу и независимым. Слишком уж много тонн всякого ненужного система тянет за собой. Слишком много ограничений по установке на современные системы. Я бы даже за деньги не взялся дорабатывать питоновские интерфейсы и оптимизировать отрисовку траектории. Перспективы в этом абсолютно никакой. Легче новое накатать.

MX_Master писал(а): ↑ Легче новое накатать.

Ну а ещё проще написать "легче новое накатать". Там годы дебага.

Я знаю о чём говорю. Легче тонну своего говнокода накатать, чем разбираться в чужом, пытаясь выдавить из него то, для чего он не был задуман. Кто видел код разных enterprise систем, не даст соврать. Там, блин, одни грабли, костыли и прочая пое.. повсеместно. В открытых проектах чуть получше, но всё равно единого подхода к архитектуре и модульности нет. Часть кода на С++, часть на С, часть на питоне, часть на TCL (+TK). И к каждому коду есть свои вопросы и косяки, которые никто исправлять не будет, ибо проект открытый.

MX_Master писал(а): ↑ Там, блин, одни грабли, костыли и прочая пое.. повсеместно

Еще там в исходниках есть комментарии к коду, типо: я не знаю как это работает.

Но есть и другие способы облегчения взлета. Например, в зависимости от того, кто и как создал г-код, использование регулярных выражений в команде замены кусков текста sed может облегчить вес файла на 25-30%. От тех самых 400мб это пусть даже 50 метров (12%) - и запуск вместо 90 минут будет несколько быстрее.
Гипотезу эту проверял на своем конкретном примере с текущим заданием (буфет) - около 85000 строк, около 5мб, сгенерировано во FreeCAD. Из спортивного интереса провел простейшие операции типа удаления из z19.000000 (а также из Х, У и подачи) шести нулей и точек. Получил облегчение на 15%. А в запасе оставались еще эти Z19 в каждой строке, подача в каждой строке, часто - неизменные Х или У. Тот же image-togcode в этом плане очень гуманен - не меняющиеся значения не пишет.

На мой взгляд, основные тормоза вызывает отрисовка всех линий и дуг на питоне (opengl). Разбор текста в этом ряду занимает намного меньше времени.

MX_Master писал(а): ↑ Разбор текста в этом ряду занимает намного меньше времени.

память занимают буковки, точнее - цифорки. ИМХО, способ это простой, не затратный и вряд ли приводящий к росту потребления памяти и времени исполнения. Потому не разумно им пренебрегать.

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

TkLinuxCNC отрисовку по дефолту не использует, на сколько я понял.. но всё равно... требует под задачу 8Гб.. будь то ОЗУ, либо ОЗУ+swap.
Даже скорости ДДР4 и "рязань" 3400 подтупливают на 8 секунд.. может это всё-таки такая работа с файлами. Даже если я открою исполняемые файлы TkLinuxCNC и Axis, то всё равно ничего не мойму.

8 секунд похожи на чтение файла УП и его анализ. Там уже GUI не причём. Скорее всего, инструментально выполнено на C++. Но, опять же, зачем весь файл в ОЗУ класть для анализа. Непонятно.

MX_Master писал(а): ↑ Но, опять же, зачем весь файл в ОЗУ класть для анализа. Непонятно.

Ну просто не думали, что программы будут такого размера.. на linuxcnc.org пишут 4Гб достаточно.. это исходя из 500к строк на 1Гб.. те. УП небольшого размера изначалально задумано.. Интересно, как быстро откроет и запустит 18млн. строк версия LinuxCNC от Tormach...