Разработка 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 или загрузите предыдущие ревизии.

Или лучше сделать пост процессор... с простой заменой re.sub("([XYZIJKRxyzijkr]\s*\d+\.\d{4})\d+", "\1",g) перед return g или перед выводом... Или написать класс post_processing ...

В любом случае какой-то пост-процессинг желателен. Хотя бы в варианте синтаксиса вида "количество знаков после запятой" и выбор из дроп-даун списка конфигураций

Есть предложения по интерфейсу? Куда лучше этот пост постпроцессинг запихать?

ЗЫ Помимо всего прочего добавил новую фишку, теперь когда отрисовывается кривая из бирок, у каждой прямой и арки рисуется стрелка . Сразу видно в каком направлении будет рез.

А все прочее это: улучшенный офсет, функция проверки ориентации контура и расширение для токарного станка уже вроде по чуть-чуть работает .

очевидно в options/preferences в виде дроп-даун списка. Суть проблем в том что это надо городить целый класс, который по-разному всё выводит, что весьма ёмко и сложно. Типа процедуры, принимающей на вход нашу "каноническую g-code инструкцию-сообщение " [g01 XYZ/F/G02 ijk/G03 ijk/P/G00/e.t.c.]" и форматирующей вывод согласно всей совокупности критериев.
Иными словами - выкинуть все print'ы из кода и оставить только в footer/header/tool_changer/measurer кусках и этой процедуре.

Можно заменить запись в файл на передачу текста постпроцессору.

Я про это и говорю. Только у нас пост-процессор должен быть внутри скрипта. Без этого никак, похоже. Отдельно же никто ничего запускать не будет...
Держать весь массив в памяти чтобы после скормить разом может быть накладно.

Я предпочёл бы сделать пост-процессинг уже имеющегося g-кода. Для меня это самое очевидное. Т.е. чтобы output.ngc файл в самом конце начал читаться и обрабатываться с учётом какой-то другой специфики. Т.е. gcodetools работает на пространстве emc-g-code, а после отдельное преобразование запускается. Причина такого подхода - слишком дофига ньюансов. В итоге получится что число вызовов по сложности сравнится с обычной обработкой .ngc файла в виде фильтра-постпроцессора.

Кстати, а ведь его можно вообще отдельным сделать. Т.е. выполняем gcodetools как есть, а потом, в самом конце, выполняем из gcodetools python postprocess.py --file=input.file --options...
Но все же, наверно лучше в gcode tools отдельную процедурку сделать...

Итак какие нам нужны постпроцессоры?
1. Уменьшение длины чисел.
2. ???

1. округление всех цифр
2. (возможно) тут сделать свой препроцессор для замены #-значений вместо корявых кусков в каждом месте основного кода как сейчас
3. точно специфика дуг для некоторых g-code станков (по g04 ijk делается переход к диаметру и ещё чему-то)
4. (пока) не знаю

А как их миксовать? Т.е. если мы например хотим 1 и 2. как это задавать в интерфейсе?

Я предполагаю, что надо сделать незатейливый дроп-даун для разных g-code интерпретаторов, а опцию параметрический/не параметрический g-code трактовать как пост-процессор пересчитывающий #-арифметику в константы

вполне адекватный вариант. Плюсы - уйдут сложные IF из кода, все print'ы станут очевидными.

Согласен. Кстати можно сделать автоматическую параметризацию:
Ко всем координатам автоматом приписываем смещение и множитель. И создаем таблицу из всех найденных feed. И вообще убрать параметризацию из функции генерации Gкода.
Еще нужно будет добавить отражение оси как пост процессор. Для токарки нужно, там точки ориентации не совсем помогают.

Тогда принимаем решение о пост-процессоре. Если наши коды генерируются ТОЛЬКО в абсолютных координатах, то можно все повторные операции OR-векторов дать, смещения и т.п. Так же точность, параметризация и какие-то ещё неведомые на данный момент плюшки.

Есть вопрос на счет интерфейса:
Куда этот пост процессор запихать?
Отдельная вкладка? Или на страницу с параметрами?

Я более менее созрел, чтобы его написать, благо вроде не так сложно должно быть .

ЗЫ нужно подумать на счет следующего релиза: появились новые функции (расширение для токарки + возможно расстановку допишу...), изменился интерфейс. Предлагаю назначить приблизительную дату релиза на конец августа.

Логично в options/preferences сделать дроп-даун для "типа станка".
P.S. Надо взять себя в руки и дописать необходимые для меня опции =)

Я боюсь что одного дропдауна может нехватить...

Например если у станка нужно сделать флип оси Y или флип оси Z это уже +3 строчки... И станков может быть много ...

для гибкой конфигурации только текстовое поле в котором все параметры вписываем через запятую.
precision=4; flip=z,x; и т.п.

Точно, классная идея!

Ревизия 144

1. Добавил класс постпроцессор.
2. Написал простенький парсер.
3. Написал две функции для постпроцессора remap и remapi.
синтаксис функций remap("что менять"->"на что менять", ... "что менять"->"на что менять");
Самое главное что изменения происходят одновременно, т.е. remap("x"->"y","y"->"z"); заменит "x10 y 20" на "y10 z20" a не на "z10 z20".
remapi - тоже самое, что и remap, только не чувствительно к регистру.

Постпроцессор пока приделал только к path to gcode. К остальным не успел, скоро приделаю.
ЗЫ inx был изменен - нужно выполнить "python create_inx.py".

В post-processing добавил функцию scale.
синтаксис: scale(xscale[, yscale [, zscale [, ascale ]]]);

Если scale меняет ориентацию G02 или G03, то выполняется remapi("G02"->"G03", "G03"->"G02").
_____________

И в догонку flip() или flip_axis() можно и так и так. Параметры это просто перечисление осей.
Пример:
flip(xz); flip_axis(z); flip_axis(z y);
Flip(x) просто выполняет scale(-1,1,1,1).

Revision 148

Добавил функции round и move в постпроцессор.

Syntax:
round(r int) - округляет до r знаков. Если r<0 то округляет до десятков.
move(x float [, y float[, z float[, a float]]]) - делает сдвиг Gcode на уставновленную величину по осям x,y,z,a.