Учим принтер печатать окружности, а не многоугольники

Подписаться на 3Dtoday
4gordi
Идет загрузка
Загрузка
05.04.17
25099
98
печатает на ZAV-L
Техничка
89
Здравствуйте уважаемые мейкеры)

Решил я накануне изучить тему скриптов для слайсинга, благо информации на просторах великого интернета много.
Все эти скрипты в основном: рассчитывают более или менее точное время печати, выводят на экран принтера дополнительную информацию, но почти никак не касаются процесса печати.

И в один прекрасный день я наткнулся на замечательный скрипт "g1tog23", что в переводе на наш "исконно-русский" он переводит (там где нужно) отрезки описанные g-кодом в дуги и окружности.
Авторство скрипта как вы поняли не моё, а сиё чудо принадлежит Алексею Хохлову, за что ему выражаю огромною благодарность. И заранее прошу прощения за плагиат, просто пытаюсь разжевать информацию.

Краткая справка из wiki:
G01 Линейная интерполяция
G02 Круговая интерполяция по часовой стрелке
G03 Круговая интерполяция против часовой стрелки

Это сделано для оптимизации кода ЧПУ обработки, но в бесплатных слайсерах g-code генерируется так что круговая интерполяция не используется, а окружности и дуги описываются отрезками прямых. Знающие люди говорят, что в Кура и Симплифай3д это возможность реализована программно без скриптов, но я эту инфу проверил и был очень сильно разочарован, нигде в трех крупных слайсерах этой возможности не было (прошу сильно не пинаться, если где то ошибся).

Что нам понадобиться:

- Сам скрипт
- Python версии не ниже 2.7
- Slic3r
- Хоть сколько терпения и капельку прямых рук)

И так приступим:

Устанавливаем Python (не забываем установить галочку здесь, иначе придется прописывать вручную)
63f22e6621e324aee01e43597cb2773e.jpg
Скачиваем архив скрипта с репозитория
10cd5d185bacb1c064b0dfc2a955223d.jpg
Затем распаковываем архив, желательно поближе к Python, я обычно распаковываю прямо в папку с питоном
должен получиться путь что-то типа C:/Python27/g1tog23/
Теперь необходимо у файла g1tog23.bat изменить разрешение на g1tog23.cmd

После изменения разрешения открываем блокнотом файл g1tog23.cmd и изменяем строчку

c:\Python26\python.exe f:\3dprinting\g1tog23.py %*

В ней нужно во-первых указать путь до питона у вас на компьютере, во-вторых путь до файла g1tog23.py который находиться после распаковки вместе с файлом g1tog23.cmd.

Завершаем редактирование файла, сохраняемся)

Далее необходимо открыть настройки Sliс3r, у меня это вкладка Print Settings раздел Output options строка Post-processing scripts
030289c1fbe114ac0fe2c020e843ec32.jpg
Сюда вводим путь до файла g1tog23.cmd!!!
На этом настройки кончились, сохраняем конфигурацию. И можно приступить к слайсингу.
Ахтунг: после того как вы пропишите скрипт, генерация g-кода будет замедлена!!!

Результат распечатки детали до использования скрипта:
16cf71633352eb5f440b8f5c0e8ea340.jpg
Результат распечатки детали после работы скрипта:
PREVIEW
Это мой первый пост, и то информация принадлежит не мне, но я надеюсь что я хоть как то помог)
Подписаться на 3Dtoday
89
Комментарии к статье

Комментарии

05.04.17 в 23:15
0
Картинка впечатляет, а как с размерами, не уходят?
05.04.17 в 23:23
0
Честно говоря, печатаю теперь только с этим скриптом, размеры у меня из-за сильной усадки abs пластика и до этого уходили, поэтому не могу ответить, поидее не должны уходить)
05.04.17 в 23:45
0
Спасибо, а то до этого боролся с этим явлением увеличением количества полигонов в модели. Теперь пусть скрипт работает!
05.04.17 в 23:31
0
Спасибо попробуем
06.04.17 в 00:16
6
но в бесплатных слайсерах g-code генерируется так что круговая интерполяция не используется
- не совсем верное утверждение. Кормом для слайсеров (бесплатных или за деньги - без разницы) служит .stl, в котором дуги отсутствуют в определении формата.
А, как сказалось на скорости печати применение круговой интерполяции?
06.04.17 в 00:49
0
присоединяюсь к вопросу, а так тема годная!

И еще вопрос, что если цилиндр будет повернут параллельно плоскости стола, как тогда будет?
06.04.17 в 07:33
1
Я думаю, если перевернуть цилиндр параллельно плоскости стола, то слайсер будет обрабатывать его как множество параллелограммов друг над другом, в таком случае этот скрипт не сработает) Имеет отношение к деталям у которых окружности и дуги находятся перпендикулярно соплу.
06.04.17 в 01:15
0
некоторые слайсеры понимают не только .stl ;)
06.04.17 в 01:55
2
а по существу? дуги то они генерируют эти некоторые?
06.04.17 в 02:51
0
Сарказм?
06.04.17 в 06:53
0
Речь шла об stl. Просветите, пожалуйста, какие форматы файлов (применяемых в 3д-печати) содержат описания дуг? CAD-форматы не в счёт - слайсеры их напрямую не едят.
06.04.17 в 11:41
1
скорость печати на 8-битных платах с прошивкой Marlin ускоряется примерно на 10-20%, в зависимости от количества имеющихся круговых элементов. Особо круглые детали, например, как на фото - до 30% ускорение. Бедной атмеге не нужно на каждую часть сегмента вычитывать Гкод, а просто спокойно шагать моторами всю дугу целиком.
06.04.17 в 12:11
0
на 10-20%
Вот это хорошая новость! За ради такого имеет смысл заморочиться!
06.04.17 в 12:26
3
Еще добавление: в октопринте, например, требуется вносить G2/G3 коды в список долго выполняемых, так как оно может посчитать что печаталка отвалилась по таймауту и тогда процесс печати будет остановлен. Возможно в других программах тоже есть что-то аналогичное.
06.04.17 в 14:17
0
Не знал про такое. Спасибо. Учту. :)
06.04.17 в 01:43
0
Спасибо за инфу! Только не «разрешение», а «расширение» видимо имелось в виду...
06.04.17 в 04:30
0
В нашем случае что cmd что bat идентичны. Ибо там в файле ни чего такого не происходит.
06.04.17 в 03:06
0
Очень интересная тема, к тому же объём конечного кода должен существенно уменьшиться.
Но поведайте всё-таки конкретный формат сохранения моделей с которым этот скрипт работает.
А лучше выложите конечный файл G кода в котором G2/G3 присутствуют.
Запустим на печать и всё увидим.
Тут же ещё вопрос - понимают ли прошивки принтеров эти G2/G3 .
06.04.17 в 04:34
2
Прям существенно.
Вот такое деталье
63c276c65549a7e5a8bb2d0b849e363f.JPG

имеет вот такие размеры:
e7452fb8b185fd0bb4d8f598a9a8d239.JPG

normal - это без применения плагина.
06.04.17 в 04:36
0
Marlin и Repetier точно понимают, Смузи тоже, но почему-то подглючивало на последней стабильной версии
06.04.17 в 05:10
0
На G02/3 или и на G01?
06.04.17 в 06:09
3
G2 g3
(как-будто в шахматы играю :D)
06.04.17 в 07:48
0
Все последние прошивки поддерживают обработку команд G2/G3 (у меня Repetier), но для того чтобы он его распознал нужно его в принтер сначала забить) Что и делает скрипт, у меня все последние деталюхи обработал скрипт корректно, во всяком случае в файле g-кода есть строки с G2/G3 там где нужно, даже с точки зрения ЧПУ вроде стоят как надо)
06.04.17 в 11:43
0
смузи где-то с лета 16 года не может корректно напечатать дугу - моторы с ума сходят. Но на 32битах круговые оптимизации и не нужны, можно тупо завышать точность экспорта в STL.
06.04.17 в 04:47
9
Очень дельная тема. Но есть одно но. Приведенный вами пример решается легко экспортом STL не с точностью в 1мм как у вас в первом примере, а скажем с точностью 0.01 как я обычно экспортирую/импортирую. Да файл на выходе довольно тяжелый, но эта окружность так размазывается прямыми что на деле отличить окружность этим кодом от сотни тысяч прямых не выйдет.
Плюс время обработки кода (загрузка, расчет) в окте занимает ровно одно и тоже время для обоих кодов, хотя на деле код в 2 раза станвоится легче. но тут встает вопросец - "А какого меге от такой команды?". Мега то по идее все равно разобьет эту одну команду на кривую линию которая будет состоять из тысячи прямых отрезков равных шагу/микрошагу. Дельта как я понимаю так же разделит, только еще и тужиться будет считать привычные ей дела.
И вот сколько надо RAM для того чтобы отпечатать окружность скажем 10см в диаметре чтобы разбить ее на эти шаги и держать их координаты?
Надо кому-то на меге с нормальной дельтой попробовать на пределе скорсоти. Т.е. чтобы при "обычном" коде еще 10мм/с и дельта подвисала и дать ей котом код после этого скрипта. Есть предположение что мега просто склеит ласты...
В общем больше вопросов чем ответов. Тему надо прилично исследовать, ибо приведенный пример на второй картинке показывает что там все так же линии, либо у автора проблемы с кинематикой.
06.04.17 в 04:52
0
Зачем столько мороки? Все последние марлины уже давно поддерживают LookAhead - опцию которая как раз таки на ходу интерполирует ломанные и проскакивает нежелательные углы. Опция, конечно, не для этого предназначена - но это ее приятный бонус, я, правда, не уверен, работает ли она постоянно или ее как на лазерах - надо в G коде включать.
06.04.17 в 05:06
0
Там не все так радужно. Во первых работает только на буфере. И работает не так как ты себе эт представляешь:
Look-ahead
Marlin has jerk-type look-ahead. Without it, it would brake to a stop and re-accelerate at each corner. Lookahead will only decelerate and accelerate to some non-zero velocity, so that the change in vectorial velocity magnitude is less than the max_xy_jerk. This is only possible, if some future moves are already processed, hence the name look-ahead. It leads to less over-deposition of material at corners, especially at flat angles.
Т.е. в оригинале на каждой прямой будет полное ускорение и полное торможение. Эта штука замедляет на в ноль, а лишь до определенно скорости, тем самым проезжая угол. Так что не радужно от слова совем.
06.04.17 в 05:31
0
Блин, надо было прочитать описание, а то слово знакомое увидел и экстраполирую тут свой опыт ЧПУшника на прошивки 3д принтеров =/
Сорян.
06.04.17 в 04:59
1
Утро сложилось скверным - вынужден был тебя плюсануть.
Напьюсь наверное :)
06.04.17 в 12:38
0
Вот тоже хотел написать насчёт разрешения при экспорте. Особенно чувствуется в автокаде, он по-умолчанию гранёные стаканы делает вместо цилиндров
06.04.17 в 13:49
6
Вы зравые мысли говорите.
Когда то круговая интерполяция была необходима, потому что G код писали руками.
С появлением САПР её актуальность падала.
Размер G кода перестал играть значение, а круговая интерполяция мало чем отличается от кусочно линейной интерполяции дуги.
Даже обработка сплайнов в G коде стала не актуальной...
Вся эта проблема раньше упиралась еще в один аспект - поддержание постоянной скорости. Но сейчас вычислительные мощности достаточны для качественной планировки траектории...
Главный критерий - разрешение исходного STL.
06.04.17 в 13:51
0
Лайкнул тебя )
06.04.17 в 06:02
0
Ну, гуру Осьминога, кто его туда прикрутит? :)
06.04.17 в 08:07
0
Куда? Ты слайсеришь в осьминожке?
06.04.17 в 08:15
0
сюда

06.04.17 в 08:24
0
Не выйдет. Там именно команды gcode. Добавить вызов внешней функции там не выйдет. Настрой слайсер. Я в симпли настроил, работает на ура. Да и туго будет апельсине. У меня 4ГГц проц встает на минуту в 100% нагрузку. и это очень легкий код на молтора метра. А представь если там будет нормальная такой на 10-20 метров.
06.04.17 в 08:36
0
у осьминога есть плагин, позволяющий через гкод внешние команды запускать
06.04.17 в 08:48
0
Проблема в том что в этот момент файл у окты уже будет открыт. И я не думаю что есть какой-то смысл в него влезать в этот момент. Надо править функцию загрузки (не в фс), а перед печатью.
В теории там немного перемаслать, но желания нет. Да и сейчас 1 программа дедлайн, но почти дописана, один пункт, а вторая дедлайн будет через неделю, но там даже алгоритма и исходных данных нет...
06.04.17 в 08:51
0
Поставить питона в дебиан вообще не проблема. строка запуска есть в мане. только имя файла выхватить надо. Но повторюсь это будет долго. Я даже слайсером не пользуюсь в окте. Ибо опять же долго.
06.04.17 в 06:26
0
Я из Fusion 360 экспортирую модели и там нет "ломаных" окружностей
06.04.17 в 08:53
1
Есть. STL не подразумевает ни чего кроме плоскости заданной 4-мя точками и нормалью. Просто ты их не видишь и у тебя стоят настройки скажем точнсоть 0.01мм или итого точнее.
06.04.17 в 09:48
5
[Режим Зануда включен]
все верно, но только вектором и ТРЕМЯ точками
REAL32[3] – Normal vector
REAL32[3] – Vertex 1
REAL32[3] – Vertex 2
REAL32[3] – Vertex 3
[Режим Зануда выключен]
06.04.17 в 10:16
0
Да. Спасибо что напомнили.
06.04.17 в 07:44
0
У меня кинематика XZ-head Y-bed короче Prusa) Мне этот скрипт помогает, нет дерганных перемещений как мне кажется визуально и код самим принтером обрабатывается шустрее, на качестве поверхности тоже сказывается положительно, но это все ИМХО)
Кстати, товарищи а кто пользуется Курой или Симплифаем, поговаривают там слайсер изначально режет с G2/G3, но мои тесты привели к тому что они также режут линейной интерполяцией.
06.04.17 в 08:12
0
Я тебе сейчас скину круг отпечатай его без скрипта. ок?
https://www.dropbox.com/s/b8b679zf10s7k8n/%D0%94%D0%B5%D1%82%D0%B0%D0%BB%D1%8C.stl?dl=0
И потмо со скриптом. и расскажешь есть ли разница хоть какая. я во вьювере вообще не увидел у себя
06.04.17 в 11:15
1
Попробую вечером и залью фото до/после)
06.04.17 в 14:13
0
544c2d48180e999406c5c4af45c1e9a2.jpg
06.04.17 в 14:19
0
Это с и без? Тогда скрипт лишний от слова совсем )
06.04.17 в 14:22
0
Только если разгрузить мозги или улучшить качество низкополигональной модели
06.04.17 в 15:00
0
хз... Я же говорю это надо проверить именно на дельте с мегавскими мозгами на предельно скорости. Если подвиснет с этими кодами, то печально, если нет попробвоать поднять так что бы на обычном коде подвисала и посмотреть будет ли подвисать на этом.
06.04.17 в 08:14
0
Плюс опять же какая у тебя версия прошивики?
06.04.17 в 11:14
0
Repetier 0.92.9 там при конфигурировании прошивки надо поставить галочку
0786a8277047f657dc125904db1be4e2.jpg

Тогда он будет отрабатывать G2/G3, но она там стоит автоматически
06.04.17 в 11:17
0
Ты попробовал отпечаать оба круга? или пока принт в не досягаемости?
06.04.17 в 12:18
0
Я на работе пока) Вечером отпечатаю гляну, сфоткаю, вылажу)
06.04.17 в 09:51
0
Самая последняя кура (2.5, которая еще в бетке) режет только с G1, что .stl, что .obj - одинаково.
06.04.17 в 09:58
0
Я использую cura. Нет там G2, G3. Точность всегда ыкручиваю на максимум. Код получается огромных размеров и все G1. Авненько задумываюсь про круговую интерполяцию, а так же подпрограммах, это когда определенный кусок код повторяется у тебя в нужном месте нужное количество раз.
06.04.17 в 07:50
0
P.S. Автор скрипта Алексей просил писать ему если ссылка на скрипт умрет)
06.04.17 в 09:29
3
Странная ссылка.
Вот, поискал на github:
https://github.com/TheLongRunSmoke/g1tog23
06.04.17 в 11:08
0
Там лежит какая-то одна из первых и оригинальных версий скрипта, по ссылке которую я дал исправленная версия, что в ней правили не в курсе) За такими вопросами и как конкретно программно работает скрипт к автору Алексею Хохлову, я лишь попытался объяснить как точно устанавливать и использовать данный скрипт)
06.04.17 в 11:17
0
файлы в обоих местах - идентичны
06.04.17 в 11:10
0
спасибо, добавил в watch ;)
06.04.17 в 11:28
0
Ну, уже кто-то склонировал. Кстати, почему ссылка странная?)
06.04.17 в 15:02
2
Я не успел закончить форк, а вы уже ссылку нашли.
06.04.17 в 09:36
0
Просто наблюдения... Не кажется ли вам, что РепитерХост сам переваривает исходный GCODE от слайсера в G01/G02? Печать окружностей с карты и под управлением RH происходит по разному. Команда "пауза" и "стоп" отрабатываются исключительно в конце печати дуги.
06.04.17 в 11:03
0
Возможно, не в курсе точной работы Repetier Host но g-code генерируется не только для того чтобы запускаться с ПК, я печатаю с флешки, и у меня G2/G3 отрабатывает уже прошивка, если они присутсвуют в коде)
06.04.17 в 11:19
1
Команда "пауза" и "стоп" отрабатываются исключительно в конце печати дуги.
буффер?
06.04.17 в 11:58
0
Может и буффер. Наблюдения показывают, что в некоторых случаях пауза срабатывает быстро, а в некоторых приходится ждать завершения команды. Т.к. у нас много дуг, то зависимость бросается в глаза. Но может это наша интерпретация. Спецы могут сами отправить команды GCODE в принтер и посмотреть как их прошивка отрабатывает. Ведь мы понимаем, что в прошивке есть параметры насколько частей ей разбивать дугу. Это количество подбирается автором из расчета возможностей принтера. И в этом случае принтер определяет максимально возможно достижимое качество. Отправляя ему прямые вместо дуг, мы сами, по сути, задаем параметры качества.
06.04.17 в 09:53
0
А можно выложит куда нибудь файл с G2 G3, и без них, а тоесли честно лень ради проб ставить и настраивать сликер, обещаю выложить фото результата с дельты.
06.04.17 в 11:03
0
У меня картезиан( Для дельты даже не знаю как настроить слайсер(
06.04.17 в 12:40
0
Слайсер к кинематике принтера не привязан, следит лишь за границами области печати, это не его забота что там потом с его G-кодами вытворяют.
06.04.17 в 11:25
0
Я конечно круто извиняюсь. Но вы знаете как отрабатывает прошивка G02 И G03. Наверное удивлю вас...но она точно также дуги режет на много прямых....И какая разница кто вам разложит дугу на прямые...в одном случае размер файла меньше, во втором проц больше занят.
Как известно от перестановки мест слагаемых сумма не меняется.
06.04.17 в 11:53
1
Для 8битных плат значение имеет - на разбор текста Гкода тратится меньше ресурсов. Да, дугу оно режет, но по сути мозгам эти сегменты нужно только прошагать, а если оно сделано через G1 - нужно каждый сегмент преобразовать из текста во внутреннее представление сегментов, на что AVR тратит ну очень много времени.
Если не верите - потратьте пару часов на эксперименты с таймером, распечатать цилиндр с обычными сегментами и после этого оптимизатора, с таймером. После этого можно задавать вопросы о целесообразности.
06.04.17 в 14:01
0
Вычисления с плавающей точкой...ой как не любят 8 битки, если прямые обрабатываются алгоритмом брезенхема...то тут обходиться без дробей...а вот при разложении дуги насколько я помню как раз используется вычисления с плавающей точкой.....потому как надо сначала найти точки на этой дуге, и хотя тот же алгоритм есть и для окружностей...он там вроде не используется..(хотя смотрел давно ...может и путаю)
Замеры делать как вы сказали не показатель...потому как нужно тогда точно знать на сколько сегментов разбита у вас дуга в gcode и насколько сегментов разобьет его прошивка. Кстати преобразование текста gcod в циферки...одна из вещей которая почти не требует вычислений...Тупо берется строка и начиная с начала строки сравнивается с определенными символами такие как G, M ну и еще парочку. В зависимости от это идет ветвление дальше..и все происходить примерно тоже самое.
Ой блин не совсем понял вас :)...
Так и я про тоже, зачем нужен этот скрипт что бы из прямых отрезков делать кривые, что бы прошивка потом их опять била....Смысла не вижу в этом.
06.04.17 в 12:39
0
Под 3-й питон скрипт годится? 2ой уже больно вымирающий
06.04.17 в 13:57
0
Автор пишет что не смог запустить на 3м, поэтому не могу ничего сказать, я ставил свежую 2.7.13 помоему
06.04.17 в 15:52
2
Выше человек выложил версию с поддержкой 3го питона)Оперативно у нас люди работают) https://github.com/TheLongRunSmoke/g1tog23/releases
Спасибо TheLongRunSmoke
06.04.17 в 16:09
0
Спасибо! :)
06.04.17 в 13:21
0
Года два назад я пытался добиться от разработчиков Simplify3d, почему у них не реализована эта возможность. Мне сухо ответили, что она была в ранних версиях, но потом её отключили (!!!). Причина, якобы, в том, что не все принтеры её поддерживали. Козлы, чо...
06.04.17 в 20:13
0
как только я не изголялся, не работает оно
начиная с того, что заключенный в кавычки путь до батника вообще вызывает ошибку слика "не выполнимо"
без кавычек вроде что-то пытается, выскакивает на мнгновение окошко коммандной строки. но никаких изменений в г-коде.
в итоге оказалось нужно тупо прописать в "post-processing scripts" путь до g1tog23.py без всяких свистоплясок с .cmd или .bat
нарисовал цилиндр ака многоугольник. размер г-кода со скриптом уменьшился более чем в 10 раз. в г-коде одни G3, ни одной G2 .
интересно, почему нет G2?
распечатался цилиндр уже без граненности, но с хаотичным "воблингом". ессно, это не воблинг, без скрипта цилиндр печатается идеально ровно, но с гранями.
вощем, спасибо, интересно было попробовать. но скрипт косячный. инструкция тоже вводит в заблуждение.
06.04.17 в 21:14
0
Скрипт писал не я( извиняйте(Нет g2 значит нет у вас перемезений по часовой стрелки, а все перемещения только против часовой стрелки))Скрипт написан нормально в бантике всего лишь запись запуска питона со скриптом, возможно у вас в винде не стоит путь в переменных в разделе path к питону. Другим ни чем помочь не могу, написал последовательность действий как оно заработало у меня на нескольких компьютерах
06.04.17 в 23:19
0
к Вам я без претензий и говорю спасибо за наводку, интересно попробовать. про G2 понял, slic3r действительно выкладывал цилиндр без заполнений одними периметрами строго против часовой стрелки. насчет путей переменных path: как раз наоборот, батники с полными путями нужны именно в том случае, если они не прописаны. у меня все запускается без батников, я просто указал прямо в slic3r c:\g1tog23\g1tog23.py и всё, больше ничего нигде не прописывал и не дополнял. и хз, почему с батниками не работало. причем видно, что сам батник отрабатывается, но скрипт не стартует. а после того, как скрипт удалось стартануть, вылезло гуляние слоев, очень напоминающее воблинг. вобщем, скрипт не идеален, мягко говоря... надо попробовать на 3 питоне, а вдруг...
08.04.17 в 19:01
3
Я переработал скрипт и попытался повысить точность. Кроме того, упрости установку для винды.
https://github.com/TheLongRunSmoke/g1tog23
Воблинг связан с поведением принтера.
11.04.17 в 11:50
0
Спасибо за труды. Очень актуальная и интересная штука. Особенно когда печатаешь чужие модели, сделанные непонятно чем и непонятно как, имеющие ярко выраженную граненность.
Про "воблинг" я писал именно в кавычках. Так как это не классический воблинг, а неточность наложения слоев. Без скрипта никаких проблем с точностью нет, всё ровно, относительно ровно. При использовании скрипта проявляется гуляние слоев. Поэтому делаю вывод, что поведение принтера тут не причем. Разбег не критичен и явно заметить можно только на некоторых цветах пластика(серый) и при печати высокой ровной вертикльной стенки(высокий цилиндр). Это, можно сказать, крайний экстремальный случай. В остальных случаях, которые составляют 99% печати скрипт делает свое дело. Не идеально, но лучше, чем ничего :) Еще раз спасибо.
07.04.17 в 02:47
0
Cura 2.3 плагин не цепляет, жаль.
11.12.17 в 17:13
0
Не подскажите в чем может быть проблема с правами на Windows 10?
The configured post-processing script is not executable: check permissions. ("c:\Python27\g1tog23\g1tog23.cmd")
11.12.17 в 17:33
0
Разобрался. Убрал кавычки ))
19.12.17 в 10:08
0
Кто-нибудь запускал скрипт под mac os? Ошибка в слайсере: "The configured post-processing script is not executable: check permissions. (python /путь/g1tog23.py)". Установлены Python 2.7.14; Slic3r 1.37.2-Prusa3d
16.03.18 в 19:03
0
Если ещё актуально
The configured post-processing script is not executable
вам система говорит, что «не является выполняемым»
Надо либо в терминале выполнить команду:

chmod +x /путь/g1tog23.py
Либо в окне свойств файла скрипта разрешить выполнение как программы, или включить флаги «x».
Должно быть примерно так:
2654e40332bd4856c9ffcd05f5195f53.png
22.02.18 в 20:33
0
Ребята заливайте формат stl в компус или что там у вас меняйте формат на step после чего в freCAD ЗАЛЕЙТЕ в stl , т.е компас плохо конвертирует stl попробуйте, моя проблема решилась именно так, теперь счастлив
22.02.18 в 20:34
0
не нужно ничего скачивать, не нужно заливать скетчи, все намноооого проще
07.06.18 в 07:20
0
Все действительно намного проще.
Попытался я проделать операции по описанному выше алгоритму. У меня репитер_хост выдавал откровенную белиберду.
Я обычно экспортирую 3D модели в stl формат из AutoCADа. Да, при настройках по умолчанию, окружности представляют собой многоугольники. Но есть одна "секретная" команда в AutoCADе, которая и отвечает за качество сетки. Эта команда FACETRES. По умолчанию она принимает значения 0,5. Поигрался я этими значениями (задавал 1, 2, 3 .... до 5). И, о чудо, при 5 окружности стали окружностями (даже при большом увеличении). Правда размер файла stl увеличивается в разы.
08.07.18 в 15:16
0
Доброго времени суток коллегам-мейкерам!

Давно интересовался темой использования G2/G3 команд. Печалился отсутствию в Simplify3D их поддержки.
Наконец-то дошли руки пошаманить с Python. Большое спасибо thelongrunsmoke за проделанную работу. Скрипт работает с Python 3, дружит с Simplyfy3D и даже прогресс-бар нормально показывает.

Одно существенное но. Почему-то при печати на командах G2/G3 мотор экструдера вообще ничего не делает, соответственно, пластик не выдавливается. Даже на довольно длинных арках. Остальные части с командами G1 печатаются нормально.

Должна была печататься вот такая деталь:
04a4b8d4031ee479514e07160dcfbce7.png


Кто-нибудь сталкивался с подобными проблемами? Удавалось ли их решить?
Прикрепляю файл с текстом, где видны Gcode-команды.
7b048bec0b9a38dae3f0b3a0233baf6f.png


Буду рад конструктивной помощи и советам.
Заранее спасибо.
18.07.18 в 18:54
0
Вопрос решился. Порылся на форумах в районе прошивок и особенностей их работы с G2/G3. У меня стоит MK4Duo (Marlin Kimbra для Arduino Due и других 32-битных систем).

Оказалось всё довольно банально. Я использую относительные координаты при слайсинге, а команда G2/G3 в 3D-печати используется редко, и потому никто не тестил их работу в режиме относительных координат и они их просто не поддерживают. Переключился в слайсере на абсолютные координаты - и принтер запел новыми причудливыми звуками отрисовки арок.

Только-только поставил тестовую печать - скоро поделюсь результатами, стоила ли игра свеч.
15.01.19 в 03:02
0
Подскажите пожалуйста, как подружить этот скрипт с симплифай3д.
Вроде всё зделал по инструкции, но не понятно что именно впечатывать в окно команд для постпроцессора.
Пробовал по разному, но всё без результата. Питон версии 2.7.15
28.07.18 в 16:48
0
В итоге сравнения двух моделей, на 32-битном принтере под управлением Marlin могу для себя сделать следующие выводы:
1. Код с G2/G3 печатает окружности средней величины чуть глаже, чем без G2/G3. Скорее всего, с увеличением размера модели разница станет ощутимее. К сожалению, Marlin довольно сильно дробит на прямые участки даже арочный код.
2. Вся деталь с использованием G2/G3 печатается немного быстрее. На четырёхчасовой модели выигрыш - около 20 минут. Сравнивал по реальному времени печати, а не теоретическому в слайсере. Теоретическое время показывает выигрыш чуть ли не на час больше.
3. После преобразования код весит легче раза в три на деталях, где преимущественно печатается цилиндр плюс какое-то количество ровных слоёв и немного заполнения.

Из минусов:
1. Довольно долгая конверсия кода из G1 в G2/G3. Без прогресс-бара подумал бы что ничего не происходит или зависло.
2. После загрузки обратно в слайсер преобразованного кода мой Simplify не адекватно его отображает (внешние стенки отображает цветом внутреннего периметра, местами ровные слои рисует цветом заполнения и пр.), но печатает нормально.

Как итог: в большинстве случаев не стоит заморачиваться, особенно с деталями, где нет чисто цилиндрических поверхностей. Но если нужно улучшить гладкость большой цилиндрической детали - то, на мой взгляд, стоит подзапариться.
13.09.18 в 00:06
0
Нарисовал в компасе цилиндр радиусом 30 мм и высотой 100 мм.
Слик3 обсчетал в G1/ Время печати 1 час 2 сек.
Добавил этот скрипт. G-код генерировался 7 минут. В итоге время печати 1 час 2 сек. Т.е. не поменялось.
Смотрю G-код, а он всего в двух строчках изменился на G3/
В чем трабла?
19.02.19 в 12:44
1
Скрипт на больших файлах работает довольно долго и следить за процессом по росту выходного файла не всегда удобно.
Добавил в код несколько строк чтобы отображался прогресс в консоли.

Исправленный файл доступен по ссылке: G1toG23.py
* Также кроме Python 2.7.x требуется установка Python 3 для правильной работы вывода на экран.

9800c74e16bddc8d411d2ec5f865ca36.png
04.06.19 в 19:40
0
feaa2114fa9958121c443d511d196581.png
Выходит такая ошибка. Что я сделал не так?

Для написания комментариев, пожалуйста, авторизуйтесь.

Читайте в блогах

За-Ку-Ski-с? Подано!

Перехожу в караульный режим. Тут кто-то есть?

FormaX - 2019. Будущее пластиков наступило!

SLA-печать (стереолитография) | 3D-оборудование UnionTech

Подальше от веганов: компания 3D Bioprinting Solutions займется 3D-печатью мяса в космосе

Обзор печати нового FormaX на Picaso Designer X.