Arc Welder vs Детализация STL

metlion
Идет загрузка
Загрузка
07.06.2021
1907
38
Разное

Подпишитесь на автора

Подпишитесь на автора, если вам нравятся его публикации. Тогда вы будете получать уведомления о его новых постах.

Отписаться от уведомлений вы всегда сможете в профиле автора.

20
Статья относится к принтерам:
Ender 3 Pro

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

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

Сначала сделал два цилиндра диаметром 30мм с максимальным отклонением 0,5% (значение по умолчанию) и 0,01%. Размеры STL-файлов получились 24кБ и 49кБ, соответственно.

Визуально эти STL-ки выглядят примерно так:

После слайсинга этих моделей в файлах получилось разное количество отрезков на окружность, 47 против 121, так что всё сходится и для дальнейших тестов годится.

Далее обработал оба этих файла плагином и тут выяснились особенности:

  • Менее детальный файл не хочет обрабатываться с дефолтными настройками плагина, пришлось поднять разрешёное отклонение с 0,05 до 0,075. Это я уж выяснил в прошлой заметке.
  • Более детальный файл нормально обрабатывается со стандартными настройками.

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

Следующим этапом я напечатал эти файлы и получился следующий результат:

Диаметр 30мм, скорость 120мм/сСлева: детализация 0,5%, по центру, детализация 0,01%, справа детализация 0,01% + AW  с отклонением 0,05.

Детализированный файл с отрезками действительно практически не отличается по внешнему виду от файла с дугами. При этом:

  • При печати с сенсорного экрана показалось, что были подтормаживания. Не сказать, что сильные, но ранее я подобного не наблюдал. При печати дугами лагов также не наблюдалось.
  • По звуку печати слышно, что на дугах движение происходит без ступенек. А даже на файле с высокой детализацией, эта ступенчатость слышна. И похоже ещё экструдер потрескивает. Попробовал такой же файл напечатать без LinearAdvance, но и там слышны эти потрескивания, то есть экструдер в любом случае отрабатывает все эти мелкие отрезки, а на дуге происходит равномерная подача пластика, даже с учетом того, что там по сути тоже какие-то прямые отрезки, которые выдала прошивка.
  • Время печати детализированного файла с отрезками составило 10 минут 40 секунд, а файла с дугами – 9минут 20 секунд, то есть дуги на 12,5% сократили время печати как раз за счет того, что не нужно на каждом отрезке тормозить и разгоняться. Тут конечно кто-то скажет, что можно поднять джерки и ускорения и тогда этой разницы не станет, но это не на всех принтерах возможно, а дуги будут печататься одинаково на любом, где это разрешено в прошивке. К слову сказать, что печать менее детализированного файла составила те же 9:20, то есть как раз баланс разгонов-торможений совпал со скоростью печати дуг.

Уже когда все тесты провёл и почти написал статью, вышел стрим Соркина, где его заодно спросили и про ArcWelder. Он в рамках своей «Диванной аналитики» заявил, что применять этот плагин смысла нет, так как благодаря плагину дважды вносятся дополнительные искажения в деталь и поэтому её точность только ухудшается. Я лично точность деталей не замерял, но думаю, для технаря такого медийного уровня, тем более склонного к проведению тщательных тестов всего и вся, негоже бросаться такими утверждениями голословно. Вполне мог бы сделать подобные замеры и для деталей с ArcWelder и без и быть более объективным.

Например, необходимо учесть, что AW имеет настройку максимального отклонения, и в значении по умолчанию она 50 микрон, или, как написано в пояснении, это +- 25 микрон. Думаю, найти эту погрешность в 25 микрон даже Соркину будет сложно. А ведь эту настройку можно и уменьшить. Специально после этого стрима проверил - для детализированного цилиндра разрешение в плагине можно поставить 0,03 и даже 0,02. В обоих случаях он выдаёт процент замен более 95%. А это уже означает максимальное отклонение всего плюс-минус 10-15 микрон.

Выводы:

  1. Визуально напечатанная деталь из STL-файла с большой детализацией практически не отличается от напечатанной дугами.
  2. ArcWelder делает исполняемый файл меньше, заменяя серию команд с линейными отрезками на одну дугу. Соответственно, поток команд  получается не такой большой, и там, где из-за этого были проблемы с лагами, это может их убрать. Но это лучше пусть подтвердят или опровергнут те, у кого такое наблюдается часто.
  3. Даже если детализированный файл печатается без лагов, то на каждый отрезок происходят разгоны и торможения. Это прерывистое движение достаточно хорошо слышно, особенно на больших скоростях. Если позволяет железо, то это можно скомпенсировать увеличением джерков и ускорений. В случае с печатью дуги, деление на отрезки происходит аппаратно, но при этом движение происходит более плавно, без заметного разделения на отрезки.
  4. Если принтер не позволяет в достаточной мере увеличить джерки и ускорения, то печать детализированного файла отрезками выполняется дольше. При этом печать более детализированного файла будет всегда медленнее менее детального.
  5. Для того, чтобы плагин работал точнее, ему лучше давать исходный файл, сделанный по STL-модели с высокой детализацией. При этом и максимальное отклонение можно уменьшать до 0,02..0,03, что даст бОльшую точность дуг.
  6. В случае, если исходная модель имеет относительно небольшую детализацию, плагин выполняет замену на дуги менее 5% дуг и окружностей в файле. В этом случае можно увеличивать максимальное отклонение до 0,75. Более высокие отклонения тоже можно ставить, но производитель рекомендовал проверять сгенерированные детали визуально, всё ли устраивает. Единственная проблема - сложно контролировать сколько реально произошло замен, особенно если файл чуть посложнее, чем простой цилиндр, и особенно, если неизвестно, с какой детализацией был создан STL.

Подпишитесь на автора

Подпишитесь на автора, если вам нравятся его публикации. Тогда вы будете получать уведомления о его новых постах.

Отписаться от уведомлений вы всегда сможете в профиле автора.

20
Комментарии к статье

Комментарии

07.06.2021 в 10:24
0

еще включить аппаратные ретракты, размер кода станет еще немножко меньше. Отличная функция.

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

А учитывая, что нужно делать какие то дополнительные телодвижения - и для цилиндров AW сомнительно... Хотя... попробуйте в другую сторону, малый цилиндрик, например 4мм диаметром в 2 стенки.

Я вывожу STL с отклонением 0.05мм когда не хотелось бы видеть грани, и 0.1мм когда это не важно.

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

07.06.2021 в 12:35
0

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

Вот как раз люди считают что точность нарушается, а для художки точность не очень важна.

А учитывая, что нужно делать какие то дополнительные телодвижения - и для цилиндров AW сомнительно...
попробуйте в другую сторону, малый цилиндрик, например 4мм диаметром в 2 стенки.

Дополнительных движений - минимум. В куре просто плагин поставить и параметры выставить. В других слайсерах - в скрипт пост-обработки добавить.

С цилиндрами надо попробовать, но там вроде ограничений нет

07.06.2021 в 13:28
1

Сделал цилиндр 4мм, высокая детализация, отслайсил только стенки, два периметра.

Плагин с r=0.02 заменил 98,9%

Причём нормально так, всего две команды с экструзией, внутренний и внешний периметры

;LAYER:4
G1 X111.213 Y111.842
G1 E1.00000 F2400.000
;TYPE:Internal perimeter
G3 X111.187 Y111.896 I1.289 J0.654 E0.26397
G1 X110.862 Y111.747 F12000.000
;TYPE:External perimeter
G3 X110.838 Y111.802 I1.641 J0.749 E0.32952
G1 X110.894 Y111.744 F12000.000
;LAYER:5

Далее попробовал 3D Benchy, там тоже только периметры, без заполнений и перекрытий - 88% замен.

07.06.2021 в 14:22
0

мне больше интересно было бы глянуть на внешний вид, спекаемость, "ровность" и пр

07.06.2021 в 17:10
0

Это вон даже Вольтник показывал, и вазочки разные печатал, и нигде не сказал, что спекаемость плохая.

07.06.2021 в 11:52
0

А как, собственно, изменить детализацию экспорта во FreeCAD?

07.06.2021 в 12:21
0

верстак mesh desigh

Становимся в дереве на последнюю модификации детали

Вверху: Полигональные сетки - Создать ПС из фигуры

Отклонение поверхности.

Стандартно - самый оптимум. Но можете поиграть и в Netgen, но это больше подходит для художки, кроликов белочек и т п.

07.06.2021 в 12:31
3

Второй вариант -

По мне так удобнее, чем каждую деталь переводить в Mesh, а потом уже экспортировать.

Но с Mesh мне показалось детализацию можно сделать больше. Зачем только, непонятно

07.06.2021 в 16:53
0

И правильно Сорокин сказал, если вы посмотрите как обрабатывается команда G2 в коде то увидите что дуга разбивается на отрезки, при этом используются тригонометрические функции типа вот этих

float angular_travel = ATAN2(rvec.a * rt_Y - rvec.b * rt_X, rvec.a * rt_X + rvec.b * rt_Y);

вычисление угла поворота дуги, затратная операция кстати, но она хоть один раз выполняется ..

а далее дуга разбивается на отрезки и на каждый отрезок вычисляется его конечная точка

 #if N_ARC_CORRECTION > 1

      if (--arc_recalc_count) {

        // Apply vector rotation matrix to previous rvec.a / 1

        const float r_new_Y = rvec.a * sin_T + rvec.b * cos_T;

        rvec.a = rvec.a * cos_T - rvec.b * sin_T;

        rvec.b = r_new_Y;

      }

      else

    #endif

    {

      #if N_ARC_CORRECTION > 1

        arc_recalc_count = N_ARC_CORRECTION;

      #endif

      // Arc correction to radius vector. Computed only every N_ARC_CORRECTION increments.

      // Compute exact location by applying transformation matrix from initial radius vector(=-offset).

      // To reduce stuttering, the sin and cos could be computed at different times.

      // For now, compute both at the same time.

      const float cos_Ti = cos(i * theta_per_segment), sin_Ti = sin(i * theta_per_segment);

      rvec.a = -offset[0] * cos_Ti + offset[1] * sin_Ti;

      rvec.b = -offset[0] * sin_Ti - offset[1] * cos_Ti;

    }

Опять же хорошо что здесь только одна операция sin и cos

А вот дальше так же как и с G1 каждый отрезок помещается в буфер планировщика, где все так же после всего этого идет расчёт ускорении и торможений, не отличающийся от G1

По поводу времени уменьшения, возможно что слайсер добавлял в какие то перемещения G1 еще и скорость перемещения, возможно скрипт убрал где то ретракты у вас...тут нужно анализировать, но вот точности все эти преобразования точно не дадут к конечному результату...так вопрос зачем это нужно ?????

07.06.2021 в 17:08
0

А вот дальше так же как и с G1 каждый отрезок помещается в буфер планировщика, где все так же после всего этого идет расчёт ускорении и торможений, не отличающийся от G1

Видимо, не совсем так.

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

Ретракты там никуда не пропадают, они только при переходе на другой слой и как были, так и остались.

Вообще рекомендую самостоятельно проверить, сравнить хоть G-code, хоть его исполнение, хоть результат печати, а потом уже думать будем.

07.06.2021 в 17:34
0

Если я вам привел код, и извините но я в нем все таки разбираюсь как никак,

Видимо, не совсем так.

 Т.е. вы хотите сказать, что код работает по другому, не так как написан :)

planner.buffer_line(destination, scaled_fr_mm_s, active_extruder);

Ну так вот эта функция вызывается из обработки G1

planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0 );

а эта из G3

здесь destanation и raw это структура с "координатами".. там немножко сложнее но не суть, как видно что G1 что G2 обе помещают конечную точку в буфер , scaled_fr_mm_s , а вот это скорость перемещения которая задается либо в команде либо запомненная из предыдущих команд.

А вот уже затем происходит обработка данного буфера для перемещения моторов, разбивка его на сегменты и просчет скоростей..


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

07.06.2021 в 18:52
0

    planner.buffer_line(destination, scaled_fr_mm_s, active_extruder);
    planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0 );



А что означает 4-й параметр?

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

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

Так наоборот, дугами печатается быстрее.

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

07.06.2021 в 20:47
0

buffer_line(const xyze_pos_t &cart, const feedRate_t &fr_mm_s, const uint8_t extruder, const float millimeters=0.0 )

функция одна, просто 4 параметр по умолчанию равен 0, это дистанция перемещения, если известно

 * rx,ry,rz,e - target position in mm or degrees

     * fr_mm_s - (target) speed of the move (mm/s)

     * extruder - target extruder

     * millimeters - the length of the movement, if known

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

08.06.2021 в 08:14
0

Здесь можно взять примеры, которые у меня получились.

08.06.2021 в 17:02
0

Хм интересно получается,

файл cyl4mm.gcode слайсер разбил окружность на отрезки длинной примерно 0,1 мм, там все отрезки разные по длине но средняя где то такая

А по умолчанию в марлин #define MM_PER_ARC_SEGMENT      1 ,дуги бъет по 1мм, что как бы довольно таки большая величина если считать что диаметр 4 мм то длинна окружности 12,566
и тут получается что он разобьет ее всего на 12 отрезков...

Чепуха какая то :)

08.06.2021 в 17:17
0

Этот я не печатал. Чисто для теста делал...

08.06.2021 в 17:37
0

А у вас вот этот параметр по умолчанию стоит

#define MM_PER_ARC_SEGMENT

или вы уменьшали его ?


08.06.2021 в 20:14
0

У меня вот так, ничего сам не менял...

#define ARC_SUPPORT                 // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
  #define MM_PER_ARC_SEGMENT      1 // (mm) Length (or minimum length) of each arc segment
  //#define ARC_SEGMENTS_PER_R    1 // Max segment length, MM_PER = Min
  #define MIN_ARC_SEGMENTS       24 // Minimum number of segments in a complete circle
  //#define ARC_SEGMENTS_PER_SEC 50 // Use feedrate to choose segment length (with MM_PER_ARC_SEGMENT as the minimum)
  #define N_ARC_CORRECTION       25 // Number of interpolated segments between corrections
  //#define ARC_P_CIRCLES           // Enable the 'P' parameter to specify complete circles
  //#define CNC_WORKSPACE_PLANES    // Allow G2/G3 to operate in XY, ZX, or YZ planes
#endif

11.06.2021 в 06:51
0

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

То есть видимо, вы как-то не так понимаете код. 

Прям самому интересно стало. Где можно исходники увидеть?

11.06.2021 в 14:26
0

Исходники ...так в прошивке они marlin

Что бы вы не искали кусок функции с комментариями моими

void plan_arc(
  const xyze_pos_t &cart,   // Destination position
  const ab_float_t &offset, // Center of rotation relative to current_position
  const bool clockwise,     // Clockwise?
  const uint8_t circles     // Take the scenic route
) {
  #if ENABLED(CNC_WORKSPACE_PLANES)
    AxisEnum p_axis, q_axis, l_axis;
    switch (gcode.workspace_plane) {
      default:
      case GcodeSuite::PLANE_XY: p_axis = X_AXIS; q_axis = Y_AXIS; l_axis = Z_AXIS; break;
      case GcodeSuite::PLANE_YZ: p_axis = Y_AXIS; q_axis = Z_AXIS; l_axis = X_AXIS; break;
      case GcodeSuite::PLANE_ZX: p_axis = Z_AXIS; q_axis = X_AXIS; l_axis = Y_AXIS; break;
    }
  #else
    constexpr AxisEnum p_axis = X_AXIS, q_axis = Y_AXIS, l_axis = Z_AXIS;
  #endif

  // Radius vector from center to current location
  ab_float_t rvec = -offset;

// вычисление радиуса, центра окружности, и длин векторов от конечной точки до центра
  const float radius = HYPOT(rvec.a, rvec.b),
              center_P = current_position[p_axis] - rvec.a,
              center_Q = current_position[q_axis] - rvec.b,
              rt_X = cart[p_axis] - center_P,
              rt_Y = cart[q_axis] - center_Q,
              start_L = current_position[l_axis];

  #ifdef MIN_ARC_SEGMENTS
    uint16_t min_segments = MIN_ARC_SEGMENTS;
  #else
    constexpr uint16_t min_segments = 1;
  #endif

  // Angle of rotation between position and target from the circle center.
  float angular_travel;

  // Do a full circle if starting and ending positions are "identical"

//Вычисление угла поворота дуги(если конечная и начальная точка в одном месте то угол поворота 360 градусов ну тут в радианах)
  if (NEAR(current_position[p_axis], cart[p_axis]) && NEAR(current_position[q_axis], cart[q_axis])) {
    // Preserve direction for circles
    angular_travel = clockwise ? -RADIANS(360) : RADIANS(360);
  }
  else {
    // Calculate the angle
    angular_travel = ATAN2(rvec.a * rt_Y - rvec.b * rt_X, rvec.a * rt_X + rvec.b * rt_Y);

    // Angular travel too small to detect? Just return.
    if (!angular_travel) return;

   //Собственно длинна окружности

const float flat_mm = radius * angular_travel,
              mm_of_travel = linear_travel ? HYPOT(flat_mm, linear_travel) : ABS(flat_mm);
 

// а вот и собственно длинна отрезка прямого жирным выделено что обычно стоит в настройках
// Start with a nominal segment length
  float seg_length = (
    #ifdef ARC_SEGMENTS_PER_R
      constrain(MM_PER_ARC_SEGMENT * radius, MM_PER_ARC_SEGMENT, ARC_SEGMENTS_PER_R)
    #elif ARC_SEGMENTS_PER_SEC
      _MAX(scaled_fr_mm_s * RECIPROCAL(ARC_SEGMENTS_PER_SEC), MM_PER_ARC_SEGMENT)
    #else
      MM_PER_ARC_SEGMENT // т.е. 1мм
    #endif
  );

//А вот собственно и вычисление количества прямых отрезков( длинна окружности / длинну сегмента)

// Divide total travel by nominal segment length
  uint16_t segments = FLOOR(mm_of_travel / seg_length);
  NOLESS(segments, min_segments);         // At least some segments
  seg_length = mm_of_travel / segments;


  for (uint16_t i = 1; i

Это не вся функции но основное что нужно для вычисления количества прямых тут есть

07.06.2021 в 23:58
3

  

  Если я вам привел код, и извините но я в нем все таки разбираюсь как никак,


Для ленивых следующим комментом сжатая версия.


Ну что же вы так. Если не знаете что там, зачем придумывать как оно работает?

Давайте не будем вдаваться в детали реализации(я устал и не хочу курить код марлина с хитрой математикой) и просто прочитаем комментарии.

Первый - "Plan an arc in 2 dimension..." и так далее.в моем вольном переводе -

Дуга разбивается на маленькие отрезки размером MM_PER_ARC_SEGMENT (по-умолчанию 1мм) в будущем авторы кода надеются, что больше слайсеров будут использовать G2/G3. Сравним с отрезками в слайсере - G2 получает очко.

Далее

" Vector rotation by transformation matrix: r is the original vector ..."

(Я немного схалтурил и перевел часть гугл транслейтом и "вычитал" )

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

От себя добавлю, что в большинсте случаев на AVR и подобном синус считается по таблице, точности достаточно, а производительность на порядок выше. Так это синус/косинус это чуть сложнее пары умножений.

Ошибка может накапливаться из-за особенностей представления дробных чисел, т.к. на ардуино все double переменные превращаются в float(точность снижается "в два раза" от 16 цифра после запятой, до 7, что по-моему опыту бывает заметно). Безусловно double также вносит ошибку округления, но она пренебрежимо мала в целях CNC-строения.
Ошибка накапливаемая при использовании float может превышать точность механики станка, из-за чего выполняется корректировка пути.


Пожалуй, G1 получает очко за точность... но это так... утешительное очко.


Далее описывается механизм расчета через theta_per_segment при  N_ARC_CORRECTION > 1 (по-умолчанию == 1, каждая точка расчитывается "точно")

Для дальнейшего уменьшения объема вычислений можно использовать аппроксимацию малых углов. Это приближение справедливо для всего, кроме очень маленьких радиусов и больших значений MM_PER_ARC_SEGMENT. Другими словами, при theta_per_segment больше 0.1 радиана и большим N_ARC_CORRECTION(коррекции реже), может вызывать заметную погрешность. N_ARC_CORRECTION около 25(и меньше)  достаточно, чтобы свести ошибку к минимуму. N_ARC_CORRECTION может быть порядка сотни, прежде чем ошибка станет проблемой для станков с ЧПУ на основе Arduino с одинарной точностью (т.е. начнет проявляться ошибка погрешности)
Тут хочу заметить, что не в курсе, есть ли поддержка double на SAM армах, которые стоят в DUE, но при использовании N_ARC_CORRECTION==1 я ухудшения производительности не заметил, возможно речь про платы с mega328p  на борту.
Таким образом N_ARC_CORRECTION задает количество инкрементов без пересчета координат. Тоесть если указать 100 - то корректировка будет производиться раз в 100 расчетов точки на дуге.

G2 получает очко за производительность!

Можете кричать "судью на мыло!" Дело вот в чем. Передача жикода это тоже тяжелая операция. код надо принять (привет UART и синхронизация!), потом распарсить, а что проще парсится одна строчка или 32? После чего надо это поместить в буффер команд. ("жрем оперативку" точнее гоним больший объем данных)
И теперь немного своего "ценнейшего" опыта по этой теме)
Имеется RPi4 с octoprint, плата на базе DUE и моделька с большим количеством полигонов. При печати по USB принтер переодически останавливается и ждет 2-3 секунды и так раз в 5-7 минут обязательно при печати окружностей или чуть после. Добавляем в схему ArcWelder - проблема уходит. Печатаем с карточки - 1 "фриз" на всю 2х часовую печать.


Почему? Все просто, в октопринте нет xSerial (и наверное не будет - "сложно, мы не хотим"). Это расширенное управление UART, чтобы принтер мог помахать принтсерверу, что буффер пустует и пора навалить команд или сказать "горшочек не вари". Из-за чего окта шлет команды по таймеру и иногда допускает простой, она ж не знает, что пора. Двойной и квадро размер буффера команд не помогает, можно поймать фризы на сложных модельках, реже, но можно. Потому что какой бы быстрой не была плата принтера, узким местом будет источник gcode, Поэтому да - лучше одна "тяжелая" G2, чем куча мелких G1.

Да-да, нафиг окту, даешь клиппер.

08.06.2021 в 00:01
2

а, ну да счет забыл... 2:1 в пользу G2!

хотя если так подумать... ведь это 2:0, потому что G1 не смотря на "точность" не имеет преимущества над G2/G3.

Вообщем TL:DR - дуги кажутся сложнее, но в комплексе, они эффективнее и проще, чем рой микродвижений через G1. Потому что меньше данных передается/читается с карточки, а это долго и процессоры в принтерах уже во многом 32битные с быстрыми вычислениями "плавающей точки". а ввод-вывод всегда будет медленнее вычислений.


Слушайте блоггеров, но не ретранслируйте их мнения без критического анализа и проверки их мнений. Людям свойственно ошибаться и быть необъективными.

08.06.2021 в 01:47
0

 

быстрыми вычислениями "плавающей точки".

Пример в студию, микроконтроллера с быстрыми вычислениями плавающей точки ...

 Из-за чего окта шлет команды по таймеру и иногда допускает простой, она ж не знает, что пора.

С какого перепугу она не знает ?, вообще то принтер отвечает командой "Ок", если буфер не полон, в противном случае нет такого ответа...

От себя добавлю, что в большинсте случаев на AVR и подобном синус считается по таблице, точности

Не стоит, я выше код приводил, никаких таблиц, там нету.

меется RPi4 с octoprint, плата на базе DUE и моделька с большим количеством полигонов. При печати по USB принтер переодически останавливается и ждет 2-3 секунды

У вас скорость по UART какая выставлена ? , у меня чет ничего не ждет, хотя скорости под сотку выставляю...


И повторяю специально для вас

const float cos_Ti = cos(i * theta_per_segment), sin_Ti = sin(i * theta_per_segment);

 rvec.a = -offset[0] * cos_Ti + offset[1] * sin_Ti;

 rvec.b = -offset[0] * sin_Ti - offset[1] * cos_Ti;

При N_ARC_CORRECTION > 1

Будет заменено на

const float r_new_Y = rvec.a * sin_T + rvec.b * cos_T;

 rvec.a = rvec.a * cos_T - rvec.b * sin_T;

 rvec.b = r_new_Y;

на количество этих самых N_ARC_CORRECTION

но точности это вам не добавит однозначно, хотя скорости и прибавит...


Я не утверждаю что это медленнее обработки G кода, хотя распарсить команду где нет вообще практически операций с плавающей точкой не так долго, тут больше упирается уже в скорость UART, но и его при желании задрать можно хоть до 1Mb

P/S ну хотите тешить себя что вам помогает так этот скрипт.. ну что же не буду мешать.. хозяин барин

09.06.2021 в 02:09
0

Пример в студию, микроконтроллера с быстрыми вычислениями плавающей точки ...

STM32F407 и любой другой Cortex M4F. Все семейство имеет аппаратный ускоритель floating point операций. Например, lerdge x на нем построена, есть плата от svs0724 на STM32F429 и много чего еще кастомного. Прям все платы не проверял.

С другой стороны, а что такое "быстро"? Например есть архитектура Cortex M3, там нет "аппаратного быстрого" FPU, на умножение F32 требуется около 40 циклов(тактов). За секунду условный SAM3X8E делает 84 МИЛЛИОНА тактов. Перемножение циферок в регистрах будет для него быстрее чем передача по UART. Не помню кто точно, на 120MHz работает, толи какой-то STM32, толи LPC.

С какого перепугу она не знает ?,

Да черт его знает, спросите Джину, почему она и ее комрады это так реализовали. На лицо эффект голодания по командам есть. Просто так что ли к окте прикрутили MeatPack и воют на форуме, что надо переделать работу с UART? Место в буффере есть, а команды не перекидываются.

приведу скриншот вот отсюда


Синее - это количество "событий" опустошения буфера команд. По ссылке сравнивают 4.6 и 4.7 версии куры, подозреваю, что в 4.7 детализацию по-умолчанию подняли.

Сосбтвенно на все замечания, что печать по кабелю с окты тормозит, Джина морозится, что мол, а что выхотели? печатайте с карточки. Можете заливать джикод по юарту на карту принтера или купить wifi sd-карту, будет быстро. Вопрос конечно, зачем мне тогда окта... история с xon xoff тянется годами.

У вас скорость по UART какая выставлена ? , у меня чет ничего не ждет, хотя скорости под сотку выставляю...

и 115200  и 250000 ставил. на счет второго есть сомнения, что мега328, которая в DUE используется как мост usb-uart тянет без тормозов, однако - проблема есть и так и так. Дело не в скорости, а в принципе отправки команд.

Я рад, что у вас скорости под сотку) Вопрос не в скоростях, а в соотношении количества команд к их "длине". Когда слайсеру приходит кружок из 32 сегментов, он делает 32 G1, а если там 256 точек, количество команд будет таким же. 256 малюсеньких движений. И тут наш принтер может хрюкнуть пустой очередью команд, т.к. команды мелкие, и буфер не успевает наполняться. Команды поглащаются по прерыванию кода управляющего моторами, если команды исполняются быстро, то некогда погружать новые из uart, с карты еще успевает.

 хотя распарсить команду где нет вообще практически операций с плавающей точкой не так долго

не долго. только их много и много ожидания пока хост новую даст. Для Арма нет проблемы молотить 32 битные числа даже дробные. Вы как-то уперлись в то, что G1 быстро выполняется, а накладные расходы на ее получение от источника игнориурете.

И повторяю специально для вас

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

на количество этих самых N_ARC_CORRECTION
но точности это вам не добавит однозначно, хотя скорости и прибавит...

В первую очередь - вы не совсем поняли как оно работает.   Во вторую - зависит от точности апроксимации кадом, может и добавить. fusion360 выгружает на "средней" детализации окружность 30мм диаметром с шагом ~0.9мм, это чуть точнее настройки дуг по умолчанию, а можно и чуть снизить. А другой CAD может это иначе делать и сильнее жать окружности. Все отностильно)
При этом шаг 0.9мм даст 94 команды G1, против 1 G2

P/S ну хотите тешить себя что вам помогает так этот скрипт.. ну что же не буду мешать.. хозяин барин

Вот к чему вся эта демагогия, если вам "все равно" ? Я на своем опыте проверил - печать с octo хоста при высокой детализации сопровождается простоями из-за опустошения очереди команд. Используем G2 - такого не происходит. При этом "чудесным образом" меньше артефактов. То, что у вас такого нет, это не аргумент в пользу того, что нам не нужно этим пользоваться и рассказывать об этом, это вам "не нужно" - просто пройдите мимо. А лучше присоединяйтесь к изучению феномена)

09.06.2021 в 12:48
0

STM32F407

Вот так и знал что сейчас он и будет назван..много плат на нем может подскажете ?

Вопрос не в скоростях, а в соотношении количества команд к их "длине"

И зачем мне этот букварь ?..Вам показать как печатает с окты огружность под сотку без фризов,да и более сложные вещи, скорость UART 250000, возможно действительно мост из 328 меги тупит просто...

В первую очередь - вы не совсем поняли как оно работает.

Ну да сложно понять конечно..что дуга бъется на n-ое количество отрезков по 1мм,  а вот  параметр N_ARC_CORRECTION позволяет  на заданное в нем число не использовать операцию синуса и косинуса  при расчете следующего вектора ( и в дальнейшем точек конечных ), кстати по умолчанию он 25 стоит, попробуйте его отключить, у вас же плата с FPU ..ей не нужен этот параметр

Вы как-то уперлись в то, что G1 быстро выполняется, а накладные расходы на ее получение от источника игнориурете

Вопрос в том что быстрее выполниться операции плавающей точкой ( а то и вычисления синуса и косинуса) или распарсить команду

Ладно надоел этот балаган :) каждому свое...вон кстати ТС выкладывал файлы, так там окружность 4 мм диаметром слайсер разбил на 150 отрезков, а вот marlin в принципе ее бы разбил всего на 12, вот вам и выигрыш в скорости..и естественно тут будет лучше один G2  чем 150 G1

08.06.2021 в 08:27
0

А мне всё-таки ещё интересно, эти единичные линейные команды, которые сгенерированы по G2/G3 отличаются от команд G1 или нет?

Ведь если они те же самые, то за счет чего может получиться уменьшение времени печати детали при использовании дуг, которое у меня получилось? По логике, если отрезки стали короче, то время печати должно увеличиться, т.к. на коротких участках голова будет успевать разгоняться до меньших величин.

09.06.2021 в 00:16
0

Не буду кривить душой, после беглого чтения исходников мне стало "в лом" уж  очень специфичный код. Ответить точно я не могу, мне кажется, что G0/G1 и G2/G3 создают в планере одинаковые данные для кода, управляющего шаговиками. Скорее всего, я упускаю какие-то детали, возможно там есть хитрость с feedrate. Например, планнер/обаботчик прерывания шаговиков при обработке позиций от G2 иначе работает с ускорениями. Грубо говоря при пачке G1 каждый раз идет ускорение-замедление, а при обработке G2 цикл ускорения-замедления выполняется один раз.

09.06.2021 в 06:54
0

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

07.06.2021 в 18:49

Комментарий удалён

07.06.2021 в 18:51

Комментарий удалён

08.06.2021 в 06:19
0

В настройке марлина в секции "// G2/G3 Arc Support" в файле Configuration_adv.h которые если подкрутить еще увеличат качество поверхностей.

#define ARC_SUPPORT // Disable this feature to save ~3226 bytes

#if ENABLED(ARC_SUPPORT)  

Ну например увеличить число сегментов  интерполяции для окружности.

В прошлом посте я вам указал что команды G2/G3 не творят чудес, они лишь перекладывают работу слайсера на микроконтроллер.  Вот тут и кроется ответ почему 1 команда G2/G3 в принтере будет работать минимум как 25 команд G1 при дефолтных 24 сегментах на интерполяцию ))) 


По поводу выводов. Мне ваша логика рассуждения доставляет. Тут вы пишите что 

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

в предыдущем посту вы пишите что 

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

Так давайте определимся. Т.е. по вашей логике если взять окружность из 24 сегментов которую построил слайсер 25 командами G1,   займет больше времени для выполнения МК и из-за чего могут быть лаги.Но при этом рассчитать в 32 битном флоате на 8битном МК  эти же 25 кусочков а потом их вывести уменьшит вероятность возникновения лагов?  

Если так , то у меня на этом все)))


P.S. Раньше G2/G3 были как раз и отключены из-за малой вычислительной мощности 8 битных ядер. На Cortex-M3 расчёт флоатов тоже не особо приятен из-за отсутствия аппаратной поддержки работы  c этим типом данных. Но 32 битные регистры и частоты ядра 70-120 мгц уже делают приемлемым даже софтовую работу с плавающей точкой. Более современные же ядра Cortex-M4F как на STM32F407 помимо еще больших частот имеют аппаратную поддержку флотов в виде блока FPU. Но повторюсь даже Cortex-M3 который тратит на одну операцию с плавающим числом на десятки больше тактов для расчёта в принтере будет достаточно.


А то что при плохих STL плагин позволяет добиться лучшего качества печати, ну так по сути получается эффект замыливания граней. Если взять за базу то что перед нами круг, и мы все преобразуем в круг, то круг будет напечатан идеально.Если это был круг то идеально.А если это был квадрат или треугольни, а напечатался круг ?Ну круг то идеальный.А модель искажена ))) Поэтому и получается что при допустимых настройках в работе плагина  видимый результат не имеет УАУ эффекта.А при настройках с УАУ эффектом что-то нормальное кроме круга напечатать не выйдет. 

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


В общем я к тому что G2/G3 это хорошо, но это никакое не чудо. А просто перенос одних вычислений с ПК в МК, с той лишь разницей что с G1 в слайсере вы будете видеть реальное движение головы экструдера, с G2/G3 вы отдаете это на откуп софту принтера. Уменьшение размера файла это конечно хорошо, но с 32 битными платами никаких лагов и быть не может. Поток команд сильно ниже чем скорости печати.По крайней мере для систем где печатает сам принтер. Если принтером управляет клипер тут уже другое. Тут лаги могут быть из-за малой скорости работы UARTа к примеру, и большого потока команд, могут появится лаги.Но ведь ничего не мешает поднять со 112килобод до 500 или даже 1 мегабода скорость обмена.



08.06.2021 в 08:01
0

Так давайте определимся. Т.е. по вашей логике если взять окружность из 24 сегментов которую построил слайсер 25 командами G1, займет больше времени для выполнения МК и из-за чего могут быть лаги.Но при этом рассчитать в 32 битном флоате на 8битном МК эти же 25 кусочков а потом их вывести уменьшит вероятность возникновения лагов?

Если я правильно понимаю, то лаги возникают при чтении команд с карты. И актуально это для сенсорных экранов. У Соркина есть целая статья про это, и из-за этих лагов он в каждом стриме и обзоре топит за использование экранов 12864.

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

И в данном случае, у меня подразумевался именно поток команд между картой и процессором.

Вообще, то что файл сильно уменьшается, это скорее побочный эффект работы этого плагина, а не основное предназначение. Если это кому-то пойдёт на пользу, то почему бы и нет?

А то что при плохих STL плагин позволяет добиться лучшего качества печати, ну так по сути получается эффект замыливания граней. Если взять за базу то что перед нами круг, и мы все преобразуем в круг, то круг будет напечатан идеально.Если это был круг то идеально.А если это был квадрат или треугольни, а напечатался круг ?Ну круг то идеальный.А модель искажена ))) Поэтому и получается что при допустимых настройках в работе плагина  видимый результат не имеет УАУ эффекта.А при настройках с УАУ эффектом что-то нормальное кроме круга напечатать не выйдет.

Это какие настройки надо сделать, чтобы треугольник в круг превратить?

С другой стороны, я с трудом себе представляю деталь, где на круглой поверхности требуется наличие 100-500 граней. Но даже если такое требуется, плагин всегда можно отключить.

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

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

08.06.2021 в 12:04
0

Если я правильно понимаю, то лаги возникают при чтении команд с карты.

на 8битных мегах на его любимом Ender 3 c платами Creality3D V1 ?

он в каждом стриме и обзоре топит за использование экранов 12864.

Потому что цветной экран никакого функционала или удобства использования не добавляет. И в принципе с этим тяжело поспорить. Это для продажи. А не для удобства. 


08.06.2021 в 14:21
0

Я не спец по лагам. Может потому, что с одной стороны принтер не позволяет печатать на очень больших скоростях с приемлемым для меня качеством, а с другой - потому что не использовал очень высокую детализацию. Но если тема так или иначе звучит, то почему бы не упомянуть про неё? К тому же я написал достаточно осторожно, что это не "обязательно всех спасёт", а "может помочь в этой ситуации". Но это лучше проверять тем, у кого эти лаги есть. В чём проблема-то? Пусть люди проверят, посмотрят на результаты.

Про экраны здесь не очень хотелось обсуждать. У меня сейчас BTT TFT35-E3. Вроде работает без нареканий. На нём кое-что удобнее делать в сенсорном режиме, а кое-что в режиме 12864. Было бы лучше совместить лучшие функции от них, но понимаю, что это малореально.

09.06.2021 в 02:13
0

Если я правильно понимаю, то лаги возникают при чтении команд с карты. И актуально это для сенсорных экранов.

не совсем так. Читать с карты в целом не долго. там все же SPI. А вот если экран шлет команды по UART могут быть задержки. У меня с карты, которая напрямую к проце подключена лагов нет, а по usb от окты были.

09.06.2021 в 06:46
0

Собственно, у меня это и написано. Сенсорные экраны обычно по UART и подключаются

08.06.2021 в 17:51
1

>А если это был квадрат или треугольни, а напечатался круг ?Ну круг то идеальный.А модель искажена )))

Два маленьких нюанса. Во-первых, скрипт ищет дуги с заданным допуском, и квадрат в круг не превратит. Если этот квадрат имел не микроскопические размеры… Откуда начинается забавное во-вторых. Слайсер пишет команды для перемещения сопла. Но у выдавленного пластика на это есть собственное поведение. Он сам сглаживает и стягивает углы. Задав печать квадрата четырьмя G1, вы именно квадрат не получите при всём желании — только нечто скруглённое. Ради прямых углов придётся выгибать линии в обратную сторону, типа звёздочки. 

Пример с другой стороны: опция "многодыры" (polyholes). Заменяет маленькие вертикальные круглые отверстия в модели на многоугольники, чтобы получить в итоге относительно правильный проходной диаметр. Вместо дырочки, скукожившейся иногда до полной непроходимости. Процесс печати такого отверстия выглядит забавно: вот больший (внутренний) периметр, он откровенно квадратный. А вот в нём меньший (внешний). В коде он тоже квадратный. А на пластике — почти идеальный круг. Самая кривая его часть не углы теоретического квадрата, а неизбежный шов.

>Уменьшение размера файла это конечно хорошо, но с 32 битными платами никаких лагов и быть не может. Поток команд сильно ниже чем скорости печати.

Было бы верно, будь команды сразу скомпилированы и выполнялись без лишних раздумий. Но G-код ещё надо сначала прочитать/принять и распознать. А это труднее, чем выдавать сигналы на перемещение сразу изнутри программы. Наблюдаемая 2560 на описанных кучкой G1 окружностях определённых размеров явно тормозит и задумывается, на G2/G3 проходит их с обычной скоростью. Возможно, здесь число команд ещё автоматически подгоняется под физическое время печати. Через G1 число отрезков на круг одинаково, а их длина и частота пропорциональны диаметру. Дугами же отрезки наоборот имеют один размер и печатаются одинаково легко, а от диаметра зависит их количество. Да, в маленькой окружности отрезков будет очень мало, но это сгладится уже помянутыми свойствами пластика.

09.06.2021 в 01:00
0

Через G1 число отрезков на круг одинаково, а их длина и частота пропорциональны диаметру

Нее..специально смотрел код, как ни странно слайсер круг разбивает не на одинаковые отрезки..а бог знает по какому принципу, а вот G2/3, круг как раз разобьет на равное число отрезков, длинной 1мм, странно тут другое 1мм вроде должно быть заметно...а имено эта настройка стоит в marlin...

09.06.2021 в 02:17
0

слайсер вообще не знает, что у вас там круги, если в нем нет эвристики. Ни один из бесплатных .которыми я пользуюсь (кура, slic3r, Repetier (та же кура)) не умеют такого. 

STL формат так сказать "облако точек". а облаком точек невозможно описать круг, это всегда будет многоугольник. Пока CAD программа превращает круг в "облако" с достаточно мелким шагом - это не страшно с точки зрения "точности".

09.06.2021 в 02:18
0

Да, в слайсере есть ограничения на отрезки бесконечно малой длины. Но не явные. Например — минимальное перемещение по E.

Заметно оно будет с очень тонким соплом и очень медленной печатью. 24 сегмента по 1 мм это окружность диаметром 6 мм же. Однако интересно было бы поставить в прошивке минимальный отрезок дуги видимой глазом величины и посмотреть как она будет малые радиусы делить.

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

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

Get over here!

Проблема ретракта в 3D печати. Почему ретракт работает не всегда?

Самосвал и экскаватор

Обновления для лазерного гравера под поворотную ось

Значок "Космические рейнджеры"

Записки страйкболиста. Как я товарищу рацию чинил.