Как изменить значение экструзии (параметр E) в G-коде?

Прежде чем задать вам свой вопрос, я хочу кратко изложить свою проблему.

Я пытаюсь построить свой личный 3D-принтер и могу посылать контроллеру моего экструдера (двигателя) только целочисленные значения. Слайсер (Cura) производит дроби. Я пытаюсь истолковать эти значения как обороты в минуту. Это означает, например, что я не могу отправить 282,040 об / мин (как расчетное значение), но я могу отправить только 282 об / мин.

Моя проблема заключается в том, что я получил параметр E в виде целого числа и десятичной формы, как показано ниже:

G1 X534.729 Y195.96 E144.96538
G1 X664.869 Y195.95 E161.48942
G1 X666.538 Y196.042 E161.70166

Есть ли способ получить E-параметр только в целочисленной форме?

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

, 👍2

Обсуждение

Существует разница в единицах измерения, значение E в G-коде-это длина (обычно в мм, но также может быть объемным), вы имеете в виду обороты в минуту (обороты в минуту). Последнее-это не длина (или объем), а скорость. Вам нужно объяснить, почему разница такова. в противном случае никакой слайсер вам не поможет., @0scar

После переосмысления я дополнил ответ предложенным подходом: измените прошивку для поддержки небольших устройств. Постобработка нарезанного G-кода все равно будет необходима, и я объяснил, как это сделать. Итак, это простой ответ о том, как получить целочисленные значения Ennn для реальной печати, с помощью слайсера или без него. (Также некоторые дополнительные пояснения по поводу оборотов в минуту.) Я надеюсь, что вы почерпнете из него много полезной информации. Наконец, очень многое будет зависеть от вашего оборудования, прошивки и выбранного подхода. *(Удален предыдущий избыточный комментарий.)*, @octopus8


1 ответ


1

Да, можно влиять на значения E-параметра, даже делать их целыми.

Я вижу три возможности:

  • принудительное прошивание для поддержки блоков размером менее мм - предлагаемый подход
  • принудительный срез для получения целочисленных значений-большая часть приведенного ниже объяснения
  • изменение смысла подхода E - custom, включая интерпретацию RPM

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

По книге, значение E-это новая координата на оси E (экструдер) в текущих единицах измерения. К сожалению, единственными единицами измерения положения, отраженными в стандартном G-коде, являются миллиметры (см. G21) или дюймы (см. G20). Поэтому использование целочисленных значений означало бы очень ограниченное разрешение, по крайней мере 1 мм нити, выталкиваемой за один раз. Введение меньшего блока в прошивку кажется наиболее разумным подходом.


Инструменты для постобработки файлов G-кода

G-код, сгенерированный slicer, будет содержать значения Ennn в виде долей в миллиметрах (или миллиметрах). Сгенерированный файл может быть постобработан строка за строкой, чтобы изменить эти значения. Существует множество примеров скриптов или инструментов, выполняющих подобную работу.

Одним из примеров является простой скрипт python metric-gcode-truncator, убирающий числа до 4 десятичных знаков. Простых изменений в этом сценарии может быть достаточно в самых простых случаях.

Я нашел этот скрипт в списке других утилит G-кода. Кроме того, я нашел исходный код grecode, который кажется гораздо более полным инструментом преобразования G-кода, но без аналогичной функциональности из коробки.

Следующим улучшением будет использование скрипта в качестве плагина slicer, чтобы упростить повседневный процесс. Возможно, какой-то существующий плагин Cura мог бы стать основой или примером.


Поддержка небольших устройств в прошивке

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

Исходный код существующей прошивки должен быть дополнен, чтобы правильно интерпретировать такие значения. В Marlin акцент должен быть сделан на parser.h и parser.cpp, следующие ключевые слова INCH_MODE_SUPPORT, LINEARUNIT_MM и LINEARUNIT_INCH. Соответствующие изменения также должны быть добавлены в конфигурационные файлы.

Ключевым вдохновением в парсере, по-видимому, является следующая часть:

static inline void set_input_linear_units(const LinearUnit units) {
  switch (units) {
    default:
    case LINEARUNIT_MM:   linear_unit_factor =  1.0f; break;
    case LINEARUNIT_INCH: linear_unit_factor = 25.4f; break;
  }
  volumetric_unit_factor = POW(linear_unit_factor, 3);
} 

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

Затем каждый файл G-кода должен быть постобработан подготовленным инструментом, который будет пересчитывать и изменять значения Ennn (или другие) только для выбранных команд G-кода (это должно повториться). Для метрических единиц это может быть простое умножение на 10n (визуально это смещение десятичной точки).

Подводя итог, возможно, самым простым было бы просто ввести новую единицу измерения для всех и повторно обработать файлы G-кода , соответствующим образом изменяя каждое значение X, Y, Z, E. Я не могу посоветовать, как такие изменения повлияют на настройки F (feedrate), скорости и ускорения.


Слайсер, производящий целочисленные значения параметра E

Короче говоря: уменьшите шаги/мм (прошивка/принтер), уменьшите диаметр филамента (слайсер), а затем значения Ennn в G-коде взлетят вверх и могут быть округлены до целых чисел без резкого снижения качества. Блоки для экструзии становятся затем поддельными (масштабированными).

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

Подробное теоретическое объяснение и примеры расчетов приведены ниже.

Шаги/мм

Однако это все еще полезно, потому что каждая прошивка печати имеет настраиваемую настройку шагов/мм (или аналогичное постоянное значение). Шаги/мм-это основная и известная характеристика экструдера, представляющая собой количество (микро)шагов шагового двигателя экструдера, чтобы протолкнуть этот 1 миллиметр филамента (траверса оси Е). Если эта константа steps/mm будет установлена на 1, то экструдер сделает только 1 (микро)шаг для G1 E1. Это изменение может быть сделано в конфигурации прошивки, временно с G-кодом M92 E1, или сохранено в EEPROM.

Объем

Нить - это длинный цилиндр, а длина экструзии-высота короткого цилиндра (отрезка целого): $l= \frac {4 V} {\pi d^2} R$, где:

  • V - объем, необходимый для pring path, внутренне рассчитанный программным обеспечением slicer
  • d - диаметр нити, сконфигурированной в срезе
  • R - настроенная настройка множителя экструзии (R) a.k.a. расход. (Он был введен для тонкой настройки во время выполнения или при чанигинге нитей, чтобы избежать обходных путей, таких как манипулирование шагами/мм или диаметром до неверных значений. Этот параметр не очень важен для этой дискузии, включен только для полноты.)

Конфигурация принтера

1 мм нити соответствует фактическому объему материала (3 мм). Правильные шаги/мм очень важны, поэтому вращение двигателя (перемещение вдоль оси Е) действительно выдавливает ожидаемую величину. Если значение шагов/мм, настроенное в принтере, уменьшится, то интерпретируемые команды G-Кода будут переведены на слишком короткие расстояния (меньше шагов). Чтобы обеспечить необходимый объем, нужно либо заказать больше миллиметров (G1 Ennn), либо нить должна быть толще. Нить-это то, что есть, поэтому возможен только первый выбор.

Например, используя нить 1,75 мм и имея экструдер, который должен сделать 760 шагов, чтобы толкнуть 1 мм (факт, определяемый аппаратными характеристиками), затем выдавливать 1 мм3:

  • если принтер установлен на 760 шагов/мм (правильно), то G-код должен содержать правильный E0.415752 мм для достаточно длинного цилиндра, проталкиваемого через сопло
  • если принтер "неправильно сконфигурирован" для 1 шага/мм, то G-код должен содержать edaquately масштабированное значение E315.9713 для того же cylinder, который будет выдвинут (760x большее число). Это значение на самом деле является точным числом (микро)шагов. И он большой. Десятичная часть ничтожна. Его можно смело округлять до целого числа.

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

Правильное место масштабирования

Так как же получить это масштабирование? Самый простой способ-увеличить расход в принтере (например, до 760%). Это позволит масштабировать значения Ennn в виде G-кода во время выполнения. Для этого нужен оригинальный G-код с крошечными цифрами. Так что это не решение для целых чисел.

Тогда как заставить slicer производить G-код с масштабированными числами?

Конфигурация слайсера

Слайсер вычисляет объем, необходимый для печати некоторого фрагмента, и укрывает его до миллиметров нити, исходя из заданного диаметра. Так что этот диаметр тоже очень важен. Все должно совпадать. Если в срезе установлен очень маленький диаметр, то это резко увеличит длину выталкиваемой нити.

Например:

  • Для филамента 1,75 мм, чтобы выдавить 1 мм3 объема, слайсер прикажет протолкнуть Е0.415752 мм.
  • После изменения настроенного диаметра филамента на 0,01 мм слайсер прикажет протолкнуть Е12732,4 мм. Это большое число. Но даже не похожая на вышеприведенную необходимая длина Е315.9713.

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

Уравнение соответствия

Изменение диаметра должно отражать изменение шага/мм. Эта пропорция может быть получена из формулы объема цилиндра. Диаметр для настройки в slicer равен $d= D \sqrt { \frac L l}$, где:

  • D - реальный диаметр филамента
  • L - стандартное расстояние экструзии: высота цилиндра, имеющего некоторый ссылочный объем и диаметр D, если шаги/мм отражают фактическое оборудование
  • l - масштабируемое расстояние экструзии: высота цилиндра, имеющего тот же указанный объем, если шаги/мм отражают фактическую конфигурацию принтера

Значения для расчета необходимо определить для некоторого примера объема. Это уже было сделано. После предыдущих примеров диаметр, необходимый в slicer: $d= 1.75 \sqrt { \frac {0.415752} {315.9713}} = 0.063479$. После этого все еще снабжающ нить 1.75 mm такой же штрангпресс, slicer произведет большие значения как E315.9713, но принтер выполнит olny один (микро)шаг для одного милиметра в G-коде.

Удалить дробную часть

Сгенерированный G-код будет по-прежнему включать дробную часть в значения Ennn. Файл должен быть постобработан построчно, чтобы удалить его. Простой скрипт справится с этой задачей. Это может быть простая метрика-gcode-truncator, после изменения шаблона на ([E][0-9]*)([.][0-9]+) (не проверено). Улучшением качества было бы использование руд вместо усечения десятичной части.

Совокупные расхождения

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

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

Еще точнее?

Поскольку прошивка может принимать доли ниже 1 для шагов/мм (Марлин принял бы 0,01), то теоретически масштаб может быть еще больше - и поэтому значения Ennn. Срез должен поддерживать достаточно низкий диаметр. (В крайних случаях это может вызвать неожиданные переполнения или ошибки или быть заблокировано программным обеспечением.) Затем принтер умножит значения E на долю (шаги/мм). Разрешение выдавливания по-прежнему ограничено 1 (miro)шагом. Но если микропрограммное обеспечение аккумулирует округленные дробные части во время выполнения и компенсирует, то общее количество экструдированных на слой будет более точным.

Реальная попытка нарезать кусочки в реальном времени

После настройки профиля экструдера для такой очень тонкой нити в Cura можно было установить диаметр филамента 0,01. Диаметр сопла должен быть установлен на реальный размер, так как он влияет на многие параметры нарезки. Общее использование филамента в моем образце G-кода составляло >52 км. Файл содержит такие записи, как:

G1 X72.976 Y63.428 E2623.66351
G1 X74.498 Y61.523 E2607.85791
G1 F1500 E-608
G0 F1800 X107.344 Y85.452
G1 F1500 E608
G1 F1200 X107.583 Y85.642 E326.54744
G1 X107.988 Y85.938 E536.51282

Расчетное время печати составляет >5 дней. Параметр F предположительно используется также экструдером, тогда вся печать все равно замедлится. Чтобы печать действительно произошла, возможно, все настройки скорости в slicer нужно будет настроить (т. Е. Скорость печати для стен, верхней/нижней кожи, заливки и т. Д.). Тогда только жесткие ограничения скорости в прошивке будут блокировать быстрые движения. Качество результатов, скорее всего, будет поставлено под угрозу.


Пользовательские подходы (собственный G-кодовый вкус)

Slicer всегда будет вычислять длину (расстояние перемещения), в противном случае это будет противоречить стандарту G-кода. По крайней мере, я не слышал ни о каком программном обеспечении для нарезки, которое выводило бы что-то другое, чем длина для экструзии.

В какой-то собственной прошивке значение параметра E может быть определено любым способом. Например, значение E может быть точно определено как количество (микро)шагов шагового двигателя экструдера, угол поворота, отраженный в виде целого числа и т. Д. Расстояние, рассчитанное slicer, должно быть пересчитано в постобработке G-кода, чтобы соответствовать требованиям этой прошивки.

Затем потребуется собственное штучное программное обеспечение для выполнения повторных вычислений (простых или нет) и перезаписи исходных значений Е. Код может быть, возможно, вдохновлен некоторыми из перечисленных выше, но логика расчета должна соответствовать спецификации из прошивки. Возможно, это может стать собственным плагином для Cura или другого слайсера.

RPM подход (критика идеи)

Попытка интерпретировать значение E как RPM (раунды в минуту) бесполезна, пока она не будет синхронизирована с реальной скоростью движения печатающей головки, т. Е. Другими двигателями, выполняющими движение вдоль собственных векторов для печати эффективного пути. Это, вероятно, можно вычислить, но звучит как создание собственного G-кода, который игнорировал бы многие другие важные параметры.

Одним из них является параметр F, определенный в нескольких командах G-кода (включая G1). Он определяет скорость движения для прохождения пути. Он может меняться от движения к движению, используя настройки ускорения. Что еще хуже, он, как ожидается, будет запоминаться между командами и использоваться для последовательных перемещений принтера. Поэтому фокусировка на одной строке G-Кода не расскажет всего плана слайсера, а сложный план, отраженный в файле G-Кода, будет выполнен лишь частично.

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


,

Дополнил ответ четким обзором и лучшим предложенным подходом: измените встроенное ПО для поддержки небольших устройств., @octopus8

Спасибо вам за ваш ответ. Я действительно провел последние два дня, читая информацию, которую вы предоставили. Теоретически это должно сработать, но на самом деле мне нужно понять, что вы имели в виду, говоря "Каждому из вышеперечисленных требуется постобработка вывода G-кода"?? Должен ли я написать скрипт на python для этой работы или такой скрипт уже существует? Подсказка: Я использую слайсер Cura, @Otto_Scho

Да, я думаю, вам следует создать собственную логику, основанную на каком-то существующем сценарии. Я сомневаюсь, что есть что-то точно соответствующее вашим потребностям, но, возможно, достаточно близкое. Я только что быстро нашел в гугле [код процесса](https://github.com/norpchen/ProcessGCode/blob/master/process_g_code.py), найдите там "Экоординаторы". Лично я до сих пор выполнял только ограниченную постобработку, в основном с помощью существующих плагинов Cura (ввод дополнительных строк) или вручную. Выбор Python может быть наиболее перспективным, если вы подумаете о [Cura, потому что он использует движок Python для плагинов](https://github.com/Ultimaker/Cura/wiki/Plugin-Directory)., @octopus8

Отто, я также хотел бы искренне поблагодарить тебя за то, что ты прочитал мой текст. Я очень ценю это, поверьте мне :) Как вы могли видеть, я начал с идеи обратного торможения о повторном масштабировании шагового движения E, только чтобы предложить гораздо более простую смену единицы измерения. Я полагаю, что последнее также является вашим предпочтением. Я надеюсь, что вы добьетесь хороших результатов в своем проекте., @octopus8