Разработка Gcodetools - плагин Inkscape для экспорта в Gкод

[Nick]

Разработка Gcodetools

Эта ветка посвящена разработке Gcodetools, плагина для векторного редактора Inkscape, позволяющего конвертировать кривые из Inkscape в Gкод, используя круговую и линейную интерполяцию.

Описание работы, установка, помошь и уроки по плагину можно найти в теме: Gcodetools - plug-in Inkscape для экспорта в Gcode

На данный момент ведется работа над Gcodetools 1.7

Что мы хотим увидеть в новой версии:

• Улучшение расширения для плазменной резки
• Добавление дополнительных опций экспорта:
• Улучшение функции обработки площади
• Угол заглубления
• Расширение для сверловки

Требуются

• Тестеры
• Разработчики
• Помощь в технических аспектах по работе станков и обработке материалов
• Новые идеи

Последняя версия

Исходный код находится на launchpad.net. Получить последнюю версию при помощи bazaar можно так:

Код: Выделить всё

bzr branch lp:gcodetools

Последнюю версию можно загрузить через web-интерфейс: http://bazaar.launchpad.net/~gcodetools ... lope/files

Установка

1. Загрузите последнюю ревизию, из указанных выше мест.
2. Выполните "python create_inx.py" в директории с загруженными файлами.
3. Скопируйте все созданные файлы с расширением *.inx и файл gcodetools-dev.py в каталог:
Linux: /usr/share/inkscape/extensions/ и перезапустите inkscape
Windows: Program Files\Inkscape\share\extensions\
4. Перезапустите Inkscape

Последняя версия может быть не рабочей! Для получения стабильной рабочей версии зайдите сюда Gcodetools - plug-in Inkscape для экспорта в Gcode или загрузите предыдущие ревизии.

[dormouse]

Насчёт оффсетов. Салатовый контур это не совсем оффсет. Это:
1. Уширяем линию до 1мм
2. преобразуем линию в 2 контура (внешний и внутренний)
3. разбиваем (break apart)
4. внутренний уширяем опять до 1мм, но (!!!) в режиме "скругления"
5. берём от него только наружний контур, ВСЁ остальное удаляем.
Получился "скруглённый внутрь с D=1mm исходный контур". Возможно, при правильном выборе этого диаметра указанный алгоритм достаточно хорошо уберёт все "сложные" места (близкие касания, изломы и т.п.) исходного контура.

Про запятую - я не понял белый цвет внутри запятой (чуть ниже середины, правая сторона).

[Nick]

Я уже писал, и приводил пример, что делать обводку толщиной 1 мм и брать внутреннюю/внешнюю часть это то-же самое, что сделать оффсет на -1/+1 мм. Те же косяки появляются.
Вот здесь писал http://www.cnc-club.ru/forum/viewtopic. ... rt=80#p179 пункт 3. Там показана ошибка при оффсете и ошибка при толстом контуре.


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

[dormouse]

можно сам файл выложить из того поста? у меня почему-то не получается воспроизвести проблему. (и в тот раз не получилось).
Приму к сведению, что этот метод [возможно] должен быть растровым а не векторным (нарисовать круг в каждой точке контура, потом проанализировать растровую картинку и оконтурить).

[Nick]

можно сам файл выложить из того поста? у меня почему-то не получается воспроизвести проблему. (и в тот раз не получилось).
Приму к сведению, что этот метод [возможно] должен быть растровым а не векторным (нарисовать круг в каждой точке контура, потом проанализировать растровую картинку и оконтурить).

Присобачил файл... Ошибка обведена кружком.

Трейсить растровую картинку это тоже сложно .

[dormouse]

Мне бы с исходным контуром, который уширялся.

Надо опробовать "Trace bitmap" из состава inkscape. Насколько помню, его хвалили. В любом случае, биарком а уж тем более набором ломаных оконтурить (ПОСЛЕ РАДИУСНОГО СГЛАЖИВАНИЯ) любого пятнистого растрового жирафа проблем не составит =)

[Nick]

Мне бы с исходным контуром, который уширялся.

Так там слева направо:

• Исходный Контур + dinamic offset
• Исходный Контур + Оконтуренная обводка контура 30 рх (исходного не видно потому, что он снизу)
• И отдельно исходный контур

[dormouse]

Признаю, ступил. Учитывая реальное качество работы последнего варианта возникает предложение: довести до ума и начать использовать.

1. Простейший вариант - дублирование всего синего контура. Уже готово. [1проход, на вход 1 контур]
2. Сложнее - вычесть внешний контур салатового [1проход, на вход 2 контура]
3. Ещё сложнее - линия переменной ширины для произвольного последующего редактирования [2 прохода]

Попробуем начать хотя бы с п.1 ?

[Nick]

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

Написать-то написал, даже успел проверить что оно работает, но вот оценить насколько алгоритм стал быстрее работать не успел . Дома проверю.

Единственно напрягает то, что сложость всеравно осталась О(n*n)...

[Nick]

Сейчас проверил контур со 132 узлами. Обработка шла около 40 сек. В принципе это приемлемо, но при больших количествах узлов нужно что-то делать...
Точнее, это приемлемо, если есть уверенность в правильном результате. Т.е. если алгоритм работает без ошибок наверное можно и 10 минут подождать чтобы получить готовый результат.
Можно конечно ввести хитрое разбиение сегментов контура на группы, чтобы уменьшить сложность алгоритма до O(n * log n ), но не уверен что это получится ...

[Nick]

Вот пример готовой обработки контура 99 узлов. Обработка 1 мин 20 секунд. Компьютер пентиум 4 3Ггц (но у него какой-то хитрый гипертридинг, поэтому на процесс уходит не больше 1.5) памать 1Гб.

Вот скрин:

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

Кстати при уменьшении диаметра фрезы с 30 до 10 время обработки сократилось до 30 сек. И вот что поучилось:

[Nick]

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

Т.е. из 39 сек 38.5 это 2000 поисков решений.
Обнаружилось что модуль numpy хоть и дает много возможностей, но работает очень медленно.
Например поиск 10 000 определителей матрицы методом numpy.linalg.det( ) выполняется за 1.5 секунды, когда поиск определителя напрямую занимает около 0.05 сек. Т.е. примерно в 30 раз быстрее. Не нужно думать, что numpy такой плохой, просто его вычисление определителя более универсально, что естественно будет медленнее.

сейчас нужно написать вычисление обратной матрицы. И может время вычисления снизится раза в два. И я думаю, на этом можно будет закругляться и писать вывод в Gкод.

[dormouse]

И опять: поздравления!

Если возможно.... просьба НЕ ОПТИМИЗИРОВАТЬ КОД! Поясню это заявление:
1. Используем готовую numpy (которая условно "отлажена") и она тратит в 50 раз больше времени на нашу конкретную часть => ждём в 50 раз дольше (пока нет тысяч активных пользователей)
2. Люди мы живые и человеческий ресурс у нас ограничен => лучше написать медленный "условно-надёжный" вариант, чем "половину самого-самого быстрого".

Так что - если возможно, попробуем определить путь для генерации G-кода (те три пути, что я сумел разделить: весь контур , контур+обводка салатового, контур переменной толщины для редактирования пользователем) прямо сейчас, а ускорять работу потом, когда будет НАРАБОТАН ОПЫТ на медленной программе.

Конкретное предложение - сделать первый вариант, т.к. он останется навсегда как составная часть программы (он необходим для снятия фаски по всем контурам, это РЕГУЛЯРНАЯ реальная задача)!

P.S. По какой причине на lauchpad.net (насколько я могу судить) не последняя версия?

[Nick]

Упс, я уже оптимизировал ...
Теперь все работает в 30 раз быстрее . И выглядит в 2 раза красивее.

Теперь, я думаю завтра напишу общий алгоритм работы с несколькими контурами одновременно и нужно будет тестировать!

[dormouse]

Упс, я уже оптимизировал ... Теперь все работает в 30 раз быстрее

Бывает так, что потом в каких-то местах начинают проявляться совершенно неясные глюки. Вроде особого случая, который стронняя библиотека умеет отрабатывать, а своя нет. В этом случае часто актуально оставить обе процедуры с возможностью переключения между ними - это даёт возможность при необходимость решать срочную задачу (пускай и медленнее).

Жду первую рабочую версию по варианту 1 (обход всего контура) =)

[Nick]

В этом случае из numpy было взято : матричное умножение, поиск определителя матрицы 3х3 и поиск обратной матрицы 3х3. Особый случай определитель = 0, тогда нет обратной матрицы, и он уже был описан.

[Nick]

Такая задача:
Нужно продумать интерфейс. Нужно продумать алгоритм действий пользователя.
Кстати, может имеет смысл убрать нижний radiobutton с выбором функции, а функцию выбирать в зависимости от активного таба на момент нажатия apply?


Какие параметры сейчас задаются:
1. Диаметр фрезы
2. Диаметр фрезы цилиндрической обработки, чтобы уменьшить размер обработки
3. Количество начальных приближений для метода Ньютона для каждого сегмента
4. Допуск острого угла, например, угол больше чем 150 градусов острым не считать, т.е. в нем отступ не будет уходить в 0.

Что еще нужно ввести :
1. Способ задания формы фрезы.
Уравнением z(w) (заглубление от ширины)? Можно попробовать добавить туда различные функции.
+ Нужно будет задать параметры (граничные условия для функции z(w)).
2. Что я еще упустил?

[Nick]

Вот что пока получилось:

Время обработки ок. 30 сек. на все.

Теперь нужно фиксить баги ...

Баги:
1. Если контур замкнут, то не распознается первый угол.

[dormouse]

Багов хватает *rofl*
Насчёт Z(h) надо сделать:
1) без ограничений (сверло-фреза), НО ДОБАВИТЬ ОТДЕЛЬНУЮ СКОРОСТЬ (и параметр) для этого (сейчас приходится реплейсом заменять в полученном G-коде вхождения "заглубления по Z" на адекватную величину)
2) врезаться на шаг (это параметр), резать вперёд на R фрезы, подниматься обратно, возвращаться обратно, заглубляться ещё на 1 шаг и т.п. до победного
Остальные только "со временем", для обычной работы этих достаточно будет.

[Nick]

После небольшого багфикса:

Уже лучше . Но проблема первой/последней точки до конца пока не решена.

[Nick]

Багов хватает *rofl*
Насчёт Z(h) надо сделать:
1) без ограничений (сверло-фреза), НО ДОБАВИТЬ ОТДЕЛЬНУЮ СКОРОСТЬ (и параметр) для этого (сейчас приходится реплейсом заменять в полученном G-коде вхождения "заглубления по Z" на адекватную величину)

Не совсем понял... Что за отдельная скорость?

2) врезаться на шаг (это параметр), резать вперёд на R фрезы, подниматься обратно, возвращаться обратно, заглубляться ещё на 1 шаг и т.п. до победного
Остальные только "со временем", для обычной работы этих достаточно будет.

Это на сколько я понял заглубление фрезы с не рабочим центром?