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

[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 мм тоже длиннее!

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

 

[ЮрийВ]

Поэтому сравнивать время работы GGEasy и этого оптимизатора не совсем корректно.

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

Ещё стоит ограничение на количество трасс - 30000.

Вот число трасс из примера поста #68:

В архиве прикрепляю сам файл УП до работы с вашей программой.

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

означает, что программа НЕ РАБОТАЕТ

Судя по виду сверху, ваша программа работала с данным файлом. Расположение линий холостого хода отличается. Слева оптимизированная вашей программой УП (видно, в каком месте добавлена лишняя дорожка), справа - оригинальная.

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

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

Из описания Ruk.pdf:

А вот какие настройки есть в CAM программе GGEasy (там уже это предусмотрено в настройках Инструменты -> Параметры -> Утилиты...)

 

[VikNik]

Моей большой оплошностью является то, что я не поместил Guid вместе с представлением версии optim_laser_v1 в посте # 40 так, как это сделал в посте # 42 для фрезера. Исправлю это. Хотя большинство рекомендаций размещено в текстах постов, но не собирать же их по крохам, да и желательно иметь в одном месте под рукой.
Исправляю.
Прикреплены руководства на программы для лазера и фрезера.

 

[VikNik]

В архиве прикрепляю сам файл УП до работы с вашей программой.

Юрий.

Я запустил этот файл в симуляторе NCcorrector. Нормальные холостые перемещения без рывков и скачков. Но мы уже выяснили, что GGEasy хорошо оптимитизирует УП и не требует дополнительной обработки.
Чтобы заставить мою прогамму поработать с этим файлом пришлось сделать некоторые правки файла руками.
Вот кусок текста Вашей УП:
G21 G17 G90
G0Z0
M4
X4.893Y15.476S0
G1X4.899Y15.472F1500S255
X4.903Y15.474
И тут у меня появились вопросы:
- зачем двигать лазер по оси Z?
- включать "двигатель" (лазер) с вращением против часовой стрелки....
- первый холостой не обзначен командой G0, ну понятно, режим не изменился с движения по Z;
- команда подачи включена в первый рабочий ход, а если при последующей оптимизации эта трасса переместится в другое место, то с какой скоростью лазер будет перемещаться?

Эту часть я преобразовал вот так
G21 G17 G90
;G0Z0
M4F1500
G0X4.893Y15.476S0
G1X4.899Y15.472S255

В конце УП последняя трасса не закрыта командой S0. Конец трассы спокойно закрылся командой M5, но в случае перемещения этой трассы в другое место станок будет выполнять УП с выключенным лазером и что он нарисует?
Пришлось изменить с
X31.96Y7.921
M5
G0X0Y0
M30
на
X31.96Y7.921
S0
M5
G0X0Y0
M30

После таких изменей моя программа стала оптимизировать эту УП, но начисто теряла первую трассу.
Пришлось и её закрыть командой S0. Тогда оптимизация пошла нормально. Длина рабочих ходов сравнялась, а длина холостых ходов выросла по сравнению с исходной УП.
Прогон в симуляторе показал, что моя программа очень основательно перекроила УП и изменила порядок обхода. Увеличение длины холостых ходов выросло незначительно - с 1877 мм до 1911 мм.

Ну и выводы
- в УП, созданные GGEasy с оптимизацией лезть не стоит. Лучше не сделаешь;
- решение о необходимости применять оптимитизацию принимать при рассмотрении УП в NCcorrector, если рябит в глазах как на примерах в посте # 67- значит надо;
- УП должна соответствовать требованиям, изложенным в Guid_l поста # 73.
- мне нужно доработать алгоритм анализа команд G0 для того, чтобы трассы формировались корректно.

 

[Alexmit]

- в УП, созданные GGEasy с оптимизацией лезть не стоит.

Потому как она оптимизирует ещё и команды G-кода.
Что не всегда удобно.

- зачем двигать лазер по оси Z?

Это для пользователей Candle.

- включать "двигатель" (лазер) с вращением против часовой стрелки....

Почитайте чем отличаются M3 и M4 при работе лазера. Да и что такое лазерный режим.

Подключения лазера 5.5 w | ФОРУМ О СТАНКАХ CNC 3018

ФОРУМ О СТАНКАХ CNC 3018

cnc3018.ru