Разработка Gcodetools

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

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

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

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

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

Требуются

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

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

Исходный код находится на launchpad.net. Получить последнюю версию при помощи bazaar можно так: Последнюю версию можно загрузить через 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 или загрузите предыдущие ревизии.

МИР ТРУД МАЙ Товарищи !!!
С чем Вас сердечно поздравляю!

Ревизия 60

Функция проверки к чему привязаны контуры готова к тестированию.
Для того чтобы ее запустить, создаем рисунок, создаем инструменты, выбираем контуры (если ничего не выбрано, то проверяет по всем контурам, также как и при ptg), открываем Tools library->Check tools. Должна добавиться группа в которой будут содержаться контуры, раскрашенные в цвета инструментов, расположенные сверху вниз в порядке обработки. На контурах должны появиться стрелки, указывающие направление обработки.

На старых рисунках работать не будет. Т.к. в коде все gcode tools заменены на gcodetools.

Если импортировать DXF файл, то после этого OR-вектор строится в каком-то произвольном месте страницы вместо (0,0)-левого нижнего угла. Пытаюсь разобраться в сути проблем.

А какие становятся параметры страницы/документа? (Ctrl+Shift+D)

Ревизия 62

Доваял скрипт, который разделяет inx-ы. Как с ним работать: либо просто python create_inx.py, тогда создастся стандартный набор inx-ов, который кстати нужно еще обсудить. Или python create_inx "Name: module1 module2 ..." если не добавить no_help, no_options или no_preferences, то эти табы добавятся автоматически.

После выполнения скрипта копируем inx-ы в папку /usr/share/inkscape/extensions.
Кстати, чтобы постоянно не копировать файлы я создал симлинк на файлы в директории /home/nick/gcodetools/.

В свойствах страницы ничего не меняется. Причём есть закономерность - после вставки OR с большой вероятностью следующий импорт DXF закинет чертёж куда-то не туда. Т.е. точка 0,0 из DXF не попадёт в 0,0 страницы.

То ли в разных DXF по-разному это происходит.... непонятно. Надо больше экспериментов, но проблема ТОЧНО есть.

Добавь сюда svg, я посмотрю, что к чему.

Ревизия 63

Добавил инструмент tangent knife и его обработку.
Соответственно изменения внесены в tools library и generate_gcode.
Особенности тангенсального ножа: В каждой точке траектории значение четвертой оси должно быть равно наклону касательной к траектории в этой точке.
Особенные параметры:

• "4th axis meaning" - значение четвертой оси: для него "tangent knife".
• "4th axis scale" - масштаб
• "4th axis offset" - отступ

Уххаха! Занятная ошибка.

Лог: Z automatic scale = 0.282222223864 (computed according orientation points)
ведёт к тому, что "всё нормально", но при выводе g-кода все глубины неверные.

Временно убрал строку N 943: добавив 944: self.Zauto_scale[layer] = 1

Да, наверное Zauto_scale уже не нужен... Нужно будет в релизе поправить...

я это в rev 64 внёс. Явно просроченная вещь =)
P.S. Насчёт DXF - надо уделить пару минут обыгрыванию ситуации. Такое ощущение, что это "не всегда" проявляется. Метод тестирования: File/open/dxf, gcodetools/ptg - смотрим куда OR добавился. Альтернатива - в обратном порядке, смотрим куда центр DXF попал

Импорт dxf в Inkscape имеет ошибку

последний сегмент замкнутой полилинии заменяется на отрезок. Пути решения:
1. добавлять сегмент нулевой длины в чертёжной программе
2. экспортировать в .svg/.pdf (в .ps не очень удачная идея, т.к. для Windows надо ставить дополнительно тогда ghostscript. причина проста - inkscape вообще не умеет ps читать, только pdf, т.е. выполняет конвертацию .ps→.pdf силами gs).

примеры:
исходный файл: http://kalyaev.com/2010/20100513/03_freza_d4.dxf
импорт .dxf в qCAD и сохранение в .svg http://kalyaev.com/2010/20100513/qcad-svg.png
прямой импорт: (inkscape, последняя бета. file/open): http://kalyaev.com/2010/20100513/inkscape-direct.png
-------------------------------------

Проблема размещения OR (не в 0,0)

1. Inkscape/gcodetools rev65 "multi"
2. File/open/03_freza_d4.dxf
3. no checkmark/1.0/Latin 1
4. получили файл http://kalyaev.com/2010/20100514/steps-04.svg
5. Gcodetools→ptg area...→Path to gcode→apply
6. OR-вектор размещается непонятно где. http://kalyaev.com/2010/20100514/steps-06.png

Проблема с ОР:
В приложенном svg высота и ширина рисунка(документа) задана следующим образом: Хотя в нормальном svg так: Поэтому плагин берет ставит ОР в точку (x, y) = (0, 100) вместо (x, y) = (0, 1052.3622047).

С замкнутыми контурами в ближайшее время гляну.

1. Насчёт размеров согласен. В svg файле width="100%", но при открытии в Inkscape пишется shift+ctrl+d/page: 210х297мм или соответственная величина в пикселах. Из этого можно сделать вывод что явно в процедуре добавления OR-вектора. 1624..1626 добавил затычку: Залил как rev66. Будем предполагать, что не бывает документа с адекватной высотой "100" и что это только проценты =) Отдельной характеристики "единиц измерения" я не нашёл, только число "100"

Насчёт последнего сегмента замкнутых полилиний - это полностью проблема плагина-импортёра DXF. Что мы тут можем сделать?

По поводу высоты документа, она определяется в inkex.py. Путем doc_root.get("height") лучше в затычку вставить проверку именно его =="100%".

По поводу импорта dxf, сам импортер возно он тоже реализован в виде питонгвского скрипта и лежит там же в папке extensions. Можно поискать баг самим, а можно просто написать баг репорт на http://www.launchpad.net/inkscape

Понял, исправил. rev 67
rev 68 - все параметры default tool исправлены на float. К примеру, ранее нельзя было заглубляться с depth step=1.5

Импорт POINT из dxf и сверления отверстий

В svg нет точек и это реализуется плагином импорта как окружность. Сверлить сейчас при помощи gcodetools вовсе не представляется возможным. можно решить двумя способами:
В плагин импорта dxf-файлов добавляем xml тэг 'gcodetools:dxfpoint' (уже реализовано - dxf_input.py умеет это делать после проставления галочки в момент импорта. http://kalyaev.com/2010/20100524/dxf_import.zip ) для любого примитива типа 'd'. Первая координата 'm x,y ...' является искомой точкой. сам примитив значения не имеет, главное чтоб начинался в нужном месте.

В gcodetools надо реализовать сверление по следующему алгоритму: выкидываем из рассмотрения алгоритмов p-t-g/area/engr и т.п. объекты с тэгом 'gcodetools':'dxfpoint'. Как такой объект встретился делаем сверловку Указанный плагин вместо окружностей импортирует POINT как красную стрелочку и добавляет 'gcodetools':'dxfpoint'. DXF-Файл с точками (пример): http://kalyaev.com/2010/20100524/dot0_0--100_100.dxf

P.S. Попытка выиискать такие окружности без модификации кода dxf_import.py кажется порочной, так как они вполне могут совпасть с обычными. Так же в варианте с 'gcodetools':'dxfpoint' можно легко ставить точки сверловки прям в Inkscape - т.е. нарисовали любой примитив (хоть отрезок) и дали ему дополнительный тэг - получилась точка (начало пути 'd').

Проблема с импорта из DXF локализована

Суть проблемы: последний сегмент замкнутой полилинии заменялся на отрезок. Причина: ошибка (не реализован целый кусок) dxf_import.py
Как это выглядит (на псевдо-dxf): Иными словами если контур замкнутый, то он ВСЕГДА замыкается прямой линией в плагине импорта. hotfix, надеюсь, завтра будет полностью готов =)

И (похоже) полностью решена

Заменить стандартный плагин Inkscape DXF import (dxf_import.py и dxf_import.inx) на http://kalyaev.com/2010/20100525/dxf_input.v2.zip

Необходимо обсудить POINT. Желательно срочно.

Предполагается на выбор два варианта:
1. Любой примитив с одним 'd' и его первая точка 'M x,y ...' и атрибут 'gcodetools':'dxfpoint'
минусы: надо вызывать XML редактор и добавлять атрибут
плюсы: можно нарисовать любую линию вручную
можно сделать инструмент "сделать примитив точкой" - всем выделенным объектам добавить этот тег
точки можно по-разному отображать
2. Примитив конкретной формы без атрибута 'gcodetools':'dxfpoint'
минусы: нельзя нарисовать, можно только щёлкать мышкой (написав доп.скрипт) "добавить точку" и потом её копировать
плюсы: не требуется XML
можно нарисовать даже в любом CAD или PDF редакторе (Ilustrator) и он нормально импортируется
тот же подход "сделать выделенный объект точкой" - заменит выбранный примитив на нашу стрелку

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

Варианты: сверло берет любую кривую и сверлит в любой точке "m" или только в первой точке "m".
Т.е. для сверловки создается отдельный слой. И отдельный инструмент.

Хотя, если нужно сверлить той-же фрезой, которой делается фрезеровка, то это не оптимально с точки зрения рисования - больше телодвижений. Однако, имхо это правильно с точки зрения банальной эрудиции .

Время реализации такого подхода около 2-3 дней. При этом подход будет универсален, как для импортированных файлов, так и для нарисованных вручную.

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

Из английской ветки:
Нужно вставить это в код gcodetools т.к. в inkscape 0.46 в inkex.py gettext не импортируется.
------------------

Ревизия 69

Добавил import gettext.


ЗЫ Нужно разобраться с импортами, что-то там слишком дохрена всего:

import inkex, simplestyle, simplepath
import cubicsuperpath, simpletransform, bezmisc

import os
import math
import bezmisc
import re
import copy
import sys
import time
import cmath
import numpy
import codecs - это кто такой?

Насчёт кривых. смею верить, что у сверла нет специфических характеристик. Это лишь ТЕКУЩИЙ инструмент. Хотим - выносим "точки" на новый слой и добавляем туда новый инструмент и т.п., но это не имеет значение, т.к. только "penetration speed" и Zstart,Zend из OR-вектора. Максимум можно добавить характеристику "pause" в инструмент - пауза для "отработки фрезой полной глубины.

Так же часто надо сверлить фрезой и часто надо фрезеровать сверлом =) .... так что для меня это один и тот же инструмент, т.е. сверление прям среди фрезерования часто требуется без смены инструмента.

Я желаю предложить либо подход
1) "добавить тэг gcodetools:dxfpoint у любого примитива"
2)"трактовать как точки примитивы с геометрией d=m 0,0 30,-40 a 50,50 0 0 1 10,10 z" - [можно рисовать в другой программе]

При этом сделать инструмент "добавь выбранным примитивам gcodetools:dxfpoint" или "преврати выбранную кривую в такой кусочек пирога, но с той же начальной точкой"
Как только в режиме p-t-g встретится "точка", то её не обрабатывать как контур (ранее я говорил "игнорировать" - это ошибочно. Как раз в режиме p-t-g надо сверловку делать!!!), а сверлить в её начале.

Конкретная реализация: процедура path_to_gcode(self):, строка for path in paths[layer]: вместо строки p += csp сделать проверку что При таком простейшем подходе теряется возможность "сортировки", т.е. надо не сразу как встретился dxfpoint сверлить, а добавить к функции сортировки для оптимизации путей.

При таком подходе вообще неважно, как именно реализован dxfpoint, т.е. вся реализация прячется внутрь check_path_is_dxfpoint(path) - либо проверка на геометрию "условного символа", либо "проверка на атрибут gcodetools:dxfpoint". Возможно, даже оба подхода можно оставить для потомков. Где-то так удобнее, где-то иначе. Всего-то одну строчку добавить в процедуру.

Про отдельный инструмент я написал, т.к. обыно в САМ программах сверловка иет отдельной статьей.
Есть ли разница сначала все фрезеровать а потом все сверлить, или есть неоходимость сверлить в процессе фрезеровки?

Все вопросы "одновременности и порядка действий" нам задаёт НОМЕР слоя. Внутри слоя - функция сортировки.

В терминах "сверловка-среди-контуров p-t-g" логично сортировать отверстия наравне с кусочками p-t-g контуров. Предлагаю оставить это "на потом", а сейчас я сделаю как получится. Т.е. вся сверловка на слое сработает хаотично и ДО работы p-t-g кусочков =)
При этом уже можно будет ставить точки и импортировать их из DXF-файлов. Это я считаю большим прогрессом для gcodetools. Т.к. почти во всех реальных изделиях машиностроительного толка (не "художественного") есть сверловки.

Готова первая реализация (реагирует на наличие тега 'dxfpoint' с любым значением. по размышлению выходит что gcodetools:dxfpoint может с чем-то нашим конфликтовать. Лучше отдельный тег ввести.): Делает такой g-код: При этом не учитывается "параметричность" кода #zsafe

rev.71: dxfpoints

http://kalyaev.com/2010/20100526/dxfpoint.zip В него вошли:
gcodetools rev70, понимающий сверловку точек (точка= любой 'd'-path с добавленным атрибутом 'dxfpoint':'что угодно')
dxf_import.inx - добавлена галочка "Gcodetools compatible point import"
dxf_import.py - исправлены проблемы последнего выпуклого контура у замкнутых LWPOLYLINE
добавлен режим импорта DXF POINT как gcodetools-совместимого формата для последующей сверловки
файлы примеров - 2dots.dxf - две точки, 3circles.dxf и circle.dxf - ранее в dxf_import.py эти файлы импортировались с ошибкой.
P.S. Считаю, что необходимо включить dxf_import* в нашу ветку bzr.

Отлично!

Согласен, это нужно добавить в нашу ветку.
Еще нужно написать багрепорт на ланчпаде и постараться пропихнуть это в основную ветку inkscape. Не помню, говорил я или нет, разработчики inkscape предлагали отправить запрос на включение gcodetools в основную ветку inkscape. В принципе я считаю это разумным, но через некоторое время - пол-года - год, когда gcodetools станет более менее стабильным и будут реализованны все основные функции (токарка и т.д.).