Путь в 3D печать своими руками

На 8 битах можно даже лучше сапог напечатать viewtopic.php?f=25&t=104#p2775 , если всё правильно собрано и настроено. Так что выводы в том тесте явно притянуты за уши.
Собственно, я не настаиваю на применении 8-битной электроники, но пытаюсь предостеречь начинающих принтеростроителей от возможных проблем с настройкой 32-битной. Так же прошу обратить внимание, что на этом сайте 8-бит описано подробнейшим образом https://3deshnik.ru/blogs/akdzg/nastroj ... d-printera , а по 32-битам пока всё гораздо скромнее https://3deshnik.ru/blogs/tag/32-bita .

Vladik писал(а): ↑

04 май 2017, 02:04

Glueer писал(а): ↑

03 май 2017, 20:21

Как считаете электроника сильно влияет просто сейчас выбираю между 8 и 32 битной

Это зависит от скорости, на которой Вы собираетесь печатать. Скорее всего, разница будет видна где-то со скорости 60-80 мм/сек и выше. Если есть возможность, финансовая в первую очередь, покупать готовые решения на 32 бита, то, на мой взгляд, это лучший выбор.

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

Для дельты, да, 32 бита однозначно полезны. Но это не принтер, а шоу-хрень какая-то.

А объясните, что не так с Дельтой? А то у меня все друзья ее хотят, а я им не могу аргументировать, почему Спринтер лучше!

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

Так у некоторых уже работает и они счастливы.

Вот и отлично! Главное - чтобы владельцы были счастливы. Но не думаю, что в этой теме надо разводить холивар на почве сравнения H-Bot - дельта. Вроде, ответ и так должен быть очевиден.

Shaman писал(а): ↑

04 май 2017, 10:30

Разница может проявиться на сложных моделях и большой скорости.

На сколько я понимаю, сложность модели в данном контексте определяется количеством изменений направления движения головы принтера за единицу времени. Т.е. любой овал - это сложная модель.
И кроме зависаний из-за расчетов, на скоростях выше 60 мм/сек, за одно прерывание выдается 2 или 4 шага, что приводит к неравномерности следования этих импульсов, что тоже можно трактовать как "зависания".

Vladik писал(а): ↑

04 май 2017, 13:21

На сколько я понимаю, сложность модели в данном контексте определяется количеством изменений направления движения головы принтера за единицу времени. Т.е. любой овал - это сложная модель.
И кроме зависаний из-за расчетов, на скоростях выше 60 мм/сек, за одно прерывание выдается 2 или 4 шага, что приводит к неравномерности следования этих импульсов, что тоже можно трактовать как "зависания".

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

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

Мне кажется, Вы не правы. Проблема не в опустошении буфера высокоуровневых команд загружаемых из файла. Каждая из них преобразуется прошивкой в последовательность управляющих сигналов Step на шаговые двигатели. При печати это наиболее значимый код, который выделен в прерывание, т.е., с некоторой натяжкой, выполняется в реальном времени. Подготовкой же этих команд для двигателя занят математический блок прошивки, который преобразует координаты и скорости из G-кода. Если этот блок не успеет обсчитать движение головы, то как раз и произойдет "зависание". И чем чаще голова должна менять направление, тем больше загружен работой математический блок, и тем выше вероятность, что он не успеет подготовить очередную порцию команд для моторов.
С другой стороны, чем выше скорость, тем чаще мы должны вызывать прерывание для формирования сигнала Step. Но у контроллера есть ограничение, которое в данной прошивке обходится с помощью формирования двух и четырех шагов на одно прерывание. И в этом варианте возможны пропуски и неравномерность движения головы, что может вызывать артефакты печати. Поэтому гарантировано чистая программная печать возможна до 60 мм/сек, с большой вероятностью чистая программная печать возможна до 120 мм/сек.
Я думаю, что мы этого не замечаем из-за того, что реальная скорость головы редко достигает этих пределов, даже если в слайсере установлена такая скорость. Кроме того, что стенки обычно печатаются на меньшей скорости, так еще и разгон не происходит мгновенно, а длинных прямых деталей навряд ли печатается много.

Да, я действительно не понимаю, что там считать, для перемещения между точками практически в двухмерном пространстве. Для примера, на таком же процессоре работает контролер дрона, который тоже управляет 4мя двигателями, но получает данные от кучи сенсоров и успевает обсчитать это все в реальном времени. Почему у принтера проблемы - понять мне тут трудно. Видимо потому что он не летает!

Alxlm писал(а): ↑

04 май 2017, 18:26

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

Но это и не промышленный процессор.
Максимальная частота вращения этих двигателей 3000 оборотов в минуту, т.е. 50 в секунду, в шагах это 10000 в секунду для полного шага, или 32000 шагов в секунду для 1/32 микрошага. У нас 4 мотора с суммарной максимальной скоростью 128000 шагов в секунду. А для максимальной частоты прерывания микроконтроллера установлено ограничение в 40 кГц. Так что моторы побеждают количеством.

Согласен! Против математики не попрешь.

Alxlm писал(а): ↑

04 май 2017, 18:45

Да, я действительно не понимаю, что там считать, для перемещения между точками практически в двухмерном пространстве. Для примера, на таком же процессоре работает контролер дрона, который тоже управляет 4мя двигателями, но получает данные от кучи сенсоров и успевает обсчитать это все в реальном времени. Почему у принтера проблемы - понять мне тут трудно. Видимо потому что он не летает!

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