Оптимизация холостых ходов

[Adagumer]

Холостых ходов на нём пшик. Я бы не оптимизировал

Оптимизация хороша там где надо нарезать кучу отверстий в одной плоскости, для рельефных моделей с растровой обработкой оптимизация бессмысленна!

 

[VikNik]

Вы совершенно правы. Но некоторым приходится это объяснять, причём долго.

 

[ЮрийВ]

Оптимизация хороша там где надо нарезать кучу отверстий в одной плоскости

И то не всегда. Например, GGEasy неплохо оптимизирует сверловку при большом числе (куче) отверстий и сама..
В приведенном ниже примере на скринах видим выигрыш после оптимизации программой этого топика в 1 сек из 135 часов 18 мин 22 сек линейного хода (97418 мм) и 11 мин 52 сек холостого хода (118594.9 мм). Причем, время самой оптимизации 3 мин 55 сек.
Путь холостого хода длиной 118594.9 мм после оптимизации стал 118434.7 мм, то есть на 160.2 мм короче, что составляет 0.135% первоначального пути.

 

[Adagumer]

И то не всегда. Например, GGEasy неплохо оптимизирует сверловку при большом числе (куче) отверстий и сама.

Опять же куча отверстий на плоскости, как можно оптимизировать растровую обработку фрезой при фрезеровке сложного рельефа!

 

[ЮрийВ]

Опять же куча отверстий на плоскости, как можно оптимизировать растровую обработку фрезой при фрезеровке сложного рельефа!

Я к тому, что данная программа-оптимизатор пока что немного оптимизирует для GGEasy резку по контуру с мостами. Визуально точно.
Растровая засветка в HLDI в GGEasy имеет свою специфику, там нечего оптимизировать от слова совсем...
Все мои посты связаны с применением или нет программы-оптимизатора ТС к УП, которые выдает GGEasy...
Типа защита её чести и достоинства...

"...Практически ничего не изменилось. Т.е. Aspire сработал отлично..."

GGEasy тоже....

Так что остается искать дальше, в каких случаях программа-оптимизатор даст нужный пользователю эффект...

 

[VikNik]

Я тоже провёл некоторые исследования. Взял довольно приличный dxf файл и конвертировал его в G-code в разных САМ программах, которые dxf формат воспринимают (из тех, которыми я пользуюсь). Это Aspire, Carbide Creat и примочку к ABVviewer 14, которая генерит G-code.
Поскольку Aspire принимает ещё и eps формат, то я этот dxf файл сконвертировал в eps и тоже скормил Aspire. Результаты получилис такие:
Самая оптимальная УП получилась в Aspire из eps файла. Её практически не нужно оптимизировать.
Интересно то, что из dxf они всё выдали разные картины холостых ходов. Причём по приближенности к оптимальному я бы расставил их так: 1 место - Carbide Creat, 2 место - Aspire и 3 мето - ABVviewer. Видимо они все по разному интерпретируют dxf и по разному выбирают начала путей.
Из-за этого оптимизированные картинки холостых ходов тоже различаются, но их сетка во всех случаях заметно реже.
Это качественное исследование. На более подробное, т.е. определением времени выпонения и определения длнн холостых ходов у меня пороху не хватило. Этим займусь как нибудь позже, чтобы самому понимать какая САМ лучше. Или плюну на всё и подйу по пути - все форматы в eps и кормить Aspire.

 

[VikNik]

Ну и некоторый анализ в цифрах.
Поскольку все САМ программы выдали разные размеры конечного рисунка то анализ я делал по соотношению длинн рабочих и холостых ходов.
И вот на этом месте я немного охренел. То, что мне казалось самым лучшим, оказалось совсем не таким.
Обработка eps файла аспирином показала отношение длинн рабочих и холостых ходов как 1:0.3, а на картинке обнаружилось очень много мелких переходов при очень благостном расположении длнных. И вся катинка в сплошных подскоках на безопасную высоту.
Тут я склонен к тому, чтобы грешить не на Aspire, а на конвертер форматов файлов. Своего конвертера dxf -> eps у меня нет. Пользуюсь обычно онлайн конвертацией. Но тот сайт, которым я пользовался раньше, лёг. И пришлось пользоваться другим. Оптимизпция, однако, ничего не изменила. Т.е аспирин хоть в этом не подкачал. Поиски конвертера придётся продолжить.
Остальные результаты для фала dxf сведены в таблицу.

до оптимизации после оптимизации
ABViewer 1:0.18 1:0.15

Carbide 1:0.14 1:0.12

Aspire 1:0.12 1:0.1

Aspire и в этом случае не подкачал, хотя на певый взгляд его сетка холостых ходов была более насыщенной, чем у Carbide.

Вывод.
Комплект программ optim_laser_v2.exe и optim_mill_v1.exe работает и выполняет заложенные в него функции.
В некоторых случаях эффект его работы очень заметен.
Пример из поста # 40


Прмер из поста # 26



В случае, если САМ программа, создававшая g-code файл имеет собственные средства оптимизации, или кто то хорошо поработал в bCNC руками, эффект практически не заметен. Но и вреда не приносит.
Для рельефных моделей с растровой обработкой оптимизация бессмысленна!

Фактус на мордус (лат), оптимизатор свою функцию выполняет и имеет право быть в наборе софта нашего брата.

Так что скачивайте, владейте и при необходимости применяйте.

Ваши сообщения автоматически объединены: Вчера в 16:16

Что то этот редактор не хочет воспринимать табуляции, таблица получилась не очень красивая, но как есть.

 

[ЮрийВ]

В случае, если САМ программа, создававшая g-code файл имеет собственные средства оптимизации, или кто то хорошо поработал в bCNC руками, эффект практически не заметен.

Пример из поста # 26

В посте #26 использовался Лазергрбл для создания ПП. В итоге данная программа оптимизации была при деле и спасла там ситуацию.
Итак, вывод вижу такой - если нужно делать печатные платы, используйте CAM-ы, заточенные под ПП, а не то, что попалось под руку.
GGEasy доказала по факту на примере сверления огромного количества отверстий, что УП сверловки в GGEasy создается очень оптимизированной...
Теперь приведу пример сложной не растровой засветки в GGEasy для создания УП для ПП и попробую её опять же оптимизировать с помощью программы-оптимизатора:

GGEasy потратила на создание своей, как выяснилось позже очень оптимизированной, УП 5 сек.
Программа-оптимизатор работала над оптимизацией 11 мин 21 сек:

А вот результаты до оптимизации и после в сравнении с помощью NC Corrector:

Линейный путь в оптимизированном варианте на 49.56 мм длиннее! Холостой ход в оптимизированной УП на 9.455 мм тоже длиннее!

То есть делаем вывод, что для фрез и лазера, а также сверловки GGEasy создает УП (причем очень быстро), которые не требуют дальнейшей оптимизации... (обрезка периметра ПП с мостами пока не оптимальна в GGEasy, но по времени всего процесса создания ПП проигрыш в этой части работы над ПП не такой уж и большой). Но для обрезки периметра с мостами УП после GGEasy можно оптимизировать данной программой-оптимизатором,
чтобы совсем всё было идеально.

Это ещё раз говорит о том, что для изготовления ПП лучше не пользоваться любыми подручными программами, а следовать давно известной методе:
создание файлов gerber и drl, потом импорт в CAM для ПП (лучше заранее проверенные, как видим, GGEasy в этой теме мы уже протестировали) и создание
быстро и оптимизированно сразу же рабочих G-кодов для станка.

Да, в ходе тестов оказалось, что УП размером 17.68 Мб программа-оптимизатор считает слишком большой и не работает с ней.
Такое ограничение хорошо бы тоже отметить в описании программы optim_mill_v1.

 

[VikNik]

Уважаемый Юрий.
Как я понимаю, Вы занимаетесь ППМ отнюдь не на любительском уровне и потому используете самый продвинутый в этой области софт. Тем, кто занимается этим от случая к случаю вполне достаточно и способа, который был использован в посте # 26

В посте #26 использовался Лазергрбл для создания ПП. В итоге данная программа оптимизации была при деле и спасла там ситуацию.

т.е. 2 простенькие как 3 рубля программки.
И я ничуть не умаляю достоинств GGEasy, просто каждому, как говорят, овощу своё время.
Для мелких корректировок dxf файлов я использую возможности, заложенные в ABViewer. Ну что то удалить, добавить по мелочи, преместить слегка. Хотя есть монстры типа AutoCAD, Компас и др. Но я не профи и все их возможности мне ни к чему, как и многим другим.
Так что в принципе мы с Вами говорим об одном и том же. Для разовых поделок можно пользоваться тем, что под рукой. Та ППМ из поста # 26 довольно сложная, но разовая. А если это постоянно, то GGEasy.
Ограничения по размеру файлов для программ оптимизации мной были описаны ещё год назад. Я их выбирал из того расчёта, чтобы время работы программ не превышало 30 мин. Причём для своего компа с процссором 3.6 ГГц. Освежу чтобы всем не рыскать по всей теме.

Такие же замечания (и за, и против) хотелось бы получить о программе из поста # 39.

 

[ЮрийВ]

т.е. 2 простенькие как 3 рубля программки

Согласен. Но и Sprint-layout и GGEasy тоже простенькие как 1 копейка. Просто на выходе SL можно получить Gerber и Excellon, а можно HPGL и картинки.
А от этого выбора многое что зависит, как оказалось в Вашей теме...
Спасибо Вам, за возможность протестить GGEasy.

 

[VikNik]

Да, в ходе тестов оказалось, что УП размером 17.68 Мб программа-оптимизатор считает слишком большой и не работает с ней.

Размер файла в байтах моей программе до фонаря. Она работает со строками и сейчас в ней стоит ограничение 250000 строк включая комментарии.
Ещё стоит ограничение на количество трасс - 30000.
Работает медленно потому, что написана на бейсике. А это интерпретатор, а не компилятор. Черепаха по сравнению с С++, например. То, что у неё расширение .exe это вовсе не значит, что она скомпилирована. Это вариант портабельной версии (Portable Executable), в который запиханы небходимые для работы библиотеки самого бейсика и таблицы связи с смстемными ресурсами виндозы. Поэтому Вы можете спокойно запускать эту программу не имея собственно её IDE.
Поэтому сравнивать время работы GGEasy и этого оптимизатора не совсем корректно. Да и она несравненно проще GGEasy, поскольку кроме выбора файла вообще больше ничего выбирать не надо.
Но это лтвлечённый трёп
А вот сообщение

Линейный путь в оптимизированном варианте на 49.56 мм длиннее! Холостой ход в оптимизированной УП на 9.455 мм тоже длиннее!

означает, что программа НЕ РАБОТАЕТ. При отладке я строго следил, чтобы длина рабочих ходов оставалась той же самой. Если она увеличивается, значит часть холостых ходов программа принимает за рабочие, и значит на выходе вы получаете брак дорожки сольются/пересекутся и прочие неприятности. А тут ещё и длина холостых ходов растёт, хотя должна уменьшаться. Стало быть в структуре Вашей программы есть какие то нюансы, которые я не учёл. Не могли бы Вы сделать не шибко большой файл (с учётом вышеуказанных ограничений по числу строк) чтобы я смог отловить баги?