roboforum.ru

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

Все случается впервые, так и у меня седня впервые забился экструдер. В общем-то все банально - деталь с очень большой площадью, на каком-то слое отлепился угол, чуток поднялся, когда экструдер пытался печатать на этом куске - сопло ходило вплотную по пластику и, естественно, не могло продавить пластик, подающий болт стесал пластик с этом месте напрочь. Соответственно, после этого еще около 40 минут пластик ездил вместе с экструдером и тихо-мирно грелся. Видимо, чуток перегрелся и таки сгорел там =) Это, кстати, еще одна причина почему, блин, надо следить за печатью, а не раз в пару часов заходить - посмотреть как там оно.
Таки рассказываю по секрету, как бороться с забитым экструдером. Есть два пути, для простых случаев и для запущенных случаев. Мне помог простой вариант =)
Он заключается в общем-то в том, чтобы разобрать нафик экструдер, оставить горячую часть, включить ее нагрев, и надежно ухватив ее плоскогубцами за какую-нибудь не хрупкую часть - начать обрезанной(иначе она острой частью продавит пластик в центре и в пластике же застранят) зубочисткой продавливать через барабан. Первые несколько мм - самые сложные, ибо надо собственно продавить сам засор. В теории, после этого можно собирать и все должно работать. Я все же решил прочистить как следует, поэтому повторял процедуру пока пластик не перестал экструдироваться.
Собственно, это может не помочь. Тогда можно использовать вариант для запущенных случаев - надо разобрать и горячую часть тоже, забрать сопло, кинуть его в банку с ацетоном (или другим растворителем) на несколько минут.
После любого из описанных выше вариантов - надо не забыть почистить подающий болт от остатков стесанного пластика, иначе он работать тоже не будет. Вот, в общем-то, и все.

Всегда знал, что 3д печать не для чайников (типа меня)
Я на своем гравировано-фрезерном станке только чрез год начал что-то точить.
Когда привез его домой, подключил, воткнул гравировальную фрезу за 1200р. Сказал челу: "Смотри как надо платы точить", и через 10 см. фреза сломалась
А настроек в фрезерном меньше чем у вас
В общем если брать 3д станок, то надо брать к станку в нагрузку или hudbrog или FireFly

Добавлено спустя 6 минут 11 секунд:
опс, забыл что к фрезерному станку надо изучать заточное и шлифовальное дело, на что много ушло времени...

Ух, в общем последние два дня делал противоестественное. Мне таки сильно не нравится, что прошивка мейкербота - изначально морально устаревшая, и не умеет такой клевой штуки как ускорение и опережающий анализ gcode'а. На самом деле еще кучу всего не умеет, но но фик с ним. А еще с хостом общается по бинарному протоколу, который никто кроме RepG не умеет.
На всякий случай, что это такое. Есть такое понятие - feed rate, т.е. фактически скорость движения головки печатающей. Не сложно догадаться, что чем он выше - тем больше скорость печати. Что мешает его поднять? Инерционность, в первую очередь. Т.е. невозможно разогнать большую массу до большой скорости моментально. И еще сложнее - ее потом остановить с этой скорости. Я пробовал играться с высокими скоростями, и, собственно, бот при этом прыгает по столу со страшной силой и частенько скипает шаги. Как с этим бороться? Увеличивать скорость плавно, и, соответственно, плавненько замедляться перед концом движения. Что такое опережающий анализ gcode'а? Это, в общем-то, как и подсказывает название, анализ команд, идущих за текущей, чтобы понять, а нужно ли замедляться перед концом текущей команды. Т.е., скажем, если мы сейчас рисуем заполнение квадрата прямыми линиями, то в конце команды мы получаем изменение направления движения на обратное, что требует полной остановки и, соответственно, замедления перед ней. А если у нас меняется угол движения на несколько градусов - то можно особо и не тормозить, а продолжать лететь со страшной силой.
Я уже писал раньше, на мейкерботовском железе работает только одна кастомная прошивка - sjfw. Она эти две фичи умеет. И я ее даже пробовал ставить, но огреб тогда бесконечную кучу проблем, и, в общем и целом, она у меня напрочь не завелась. Но хочется ведь... В общем у меня тогда были два глобальные проблемы с ней:
1) Постоянно сыпались ошибки взаимодействия с контроллером экструдера
2) На все команды оно реагировало с опозданием в одну команду (т.е. кликаешь в контрол-панели двигать вправо - ноль реакции, после этого кликаешь что угодно еще - двигает вправо)
Ну, я ж задрот со стажем, так что беру с гита исходники sjfw и makerbot G3Firmware и начинаю изучать часть про протокол экструдера. BTW, как ни странно, описание этого протокола взаимодействия существует: https://docs.google.com/document/previe ... Pz9Amh0Hb4 Просто закопано оно было далеко =) Что интересно, оказалось что ultimaker полгода назад рассматривали возможность использования этого протокола у себя, не знаю чем закончилось правда. В общем-то визуально выглядит так, будто все должно работать, хотя код у sjfw пипец насколько грязный. Но есть ограничение по тому, насколько часто можно слать в экструдер команды, и видимо я в него слегка и упирался.
Так что можно считать что первая проблема обходима, а вот со второй ничего не сделаешь, если не начинать отладкой заниматься. Так что встает вопрос - надо собрать прошивку из исходников. В общем-то дело не хитрое, подниял вмварь, поставил туда свежую ubuntu, поставил из репозториев пакеты avr-gcc и avr-libc, пробую собрать sjfw - выдает ошибку на delay.h.
Как оказалось, в версии 1.7.1 avr-libc поменялся принцип работы функций из delay.h, и теперь они не умеют получать переменные значения задержек в качестве параметра. До этого правда я долго прыгал с бубном, но ок, мелкое исправление исходников, и ура, они собираются. Правда, еще небольшое копание в makefile'е, и отключение поддержки bluetooth'а и lcd экрана, а заодно сборка сразу с настрйоками пинов под gen4 оборудование. В общем у меня появляется hex файлик =) Следующий вопрос - как его прошить.
До этого я обновлял прошивки мейкербота через интерфейс replicatorg, и как-то все работало. В этом случае не прокатывает - ибо он берет прошивки тока со специально подготовленных репозиториев. Копаюсь в RepG, нахожу там avrdude, есть подозрение, что прошивают они именно им. Еще чуток копания - и ура, оно прошивается.
Ну, беру kliment printrun, он же в народе известен как Pronterface. К принтеру он подключается, подозрительно, но описанных ранее двух проблем нет - на экструдер контроллер не ругается и команды из контрол-панели исполняет сразу. Пробую впилить в него ранее порезанный файлик от slic3r'а с калибровочным кубиком (оный у меня на repg+G3fw работает), запускаю - получаю страшный флуд в логи о несовпадении CRC.
Где-то читал что sjfw умеет advanced crc, который поддерживается только его собственным хостом. Изучаю исходники, нахожу командочку, как его можно отключить (заодно выясняю как он парсит GCODE'ы), отключаю, пробую - не работает.
Ладно, нахожу в исходниках куски закомменченые по выводу отладочной информации - пришедшего и подсчитаного CRC, раскоменчиваю, компилю, прошиваю, пробую подключиться - пронтерфейс ругается. Оказывается, host ожидает вполне себе соответствующих протоколу ответов от слейва(принтера), а когда тот начинает в интерфейс срать всякую отладочную информацию - отваливается. Еще изучаю, выясняю что host нормально воспринимает ответ от принтера в формате:
xx [line number to resend] [T:93.2 B:22.9] [C: X:9.2 Y:125.4 Z:3.7 E:1902.5] [Some debugging or other information may be here]
В общем-то подробностей нет и именно так оно почему-то не пашет. Но легко обманывается, и не сильно ругается на формат
anyinfowithnospaces: number
По крайней мере критичных ошибок оно у него не вызывает. Допиливаю вывод дебаг информации, оказывается что подсчитанный crc какой-то, а полученный - всегда 0.
В этот момент я задумываюсь, где там вообще crc, в исходниках с g-code'ом его нету. В общем курение доков подсказывает, что передается это так:
N123 [G Code] *123
Где цифра после N - номер строки, после * - сам CRC
Т.к. в моем .gcode этого нету, то предпологаем что шлет это сам host, и шлет где-то неправильно (или прошивка неправильно обрабатывает, что вероятнее). Впиливаю в прошивку вывод полученной команды (все начинает бесстыдно глючить, но можно пережить), зато вижу что приходит команда с номером строки, без CRC в конце. Что обидно, в wiki на reprap.org пишут про номер строки и црц: You can leave both of these out - RepRap will still work, but it won't do checking. You have to have both or neither though.
Т.е. тут Pronterface слегка нарушает стандарт. Но дальнейшее изучение исходников sjfw подсказывает, что оно вполне может пережевывать номер строки, без CRC.
И тут меня осеняет - у меня в коде инициализации, нагенереным в RepG стоят комментарии вида:
( **** begin homing **** )
И он звездочку оттуда воспринимает как начало CRC. Долго ругался матом, убрал, наступило чудо - он таки начал жрать gcode'е. Правда при этом совершает кучу хаотических движений, и пока я успел вырубить блок питания, продрал соплом слой каптона, алюминиевой фольги и маски на плате. Благо движение было вдоль дорожек платы, и он их не порвал, а просто оголил.
Выясняю дальше. SJFW не умеет homing команд. Принципиально. Типа как они не нужны. Поэтому мне впервые в жизни(а я ведь говорил раньше, все когда-то бывает впервые) пришлось поизучать по-человечески g-code.
В общем как сейчас делается homing у меня (и, как я понимаю, в большинстве реализаций как-то аналогично). Алгоритм примерно такой:
0) Задать температуру платформы и экструдера, без ожидания ее достижения)
1) Включаем относительное перемещение
2) Быстро-быстро поднимаем головку на бешеное расстояние (типа метр), аналогично двигаем против осей X и Y. Цель - упереться в endstop'ы - огранечители осей
3) Выполняем обнуление текущих координат (G92 X0 Y0 Z0 E0)
4) Отодвигаем по всем осям на 5 мм от краев (если не обнулить до этого координаты, то не отработает, т.к. будет считать что программные координаты еще в метре в глубину)
5) Меееееедленно двигаем в сторону краев на 10 мм. Опять таки, до endstop'ов. Это делается чтобы очень ровно поймать момент срабатывания концевых датчиков, а не пролететь его на большой скорости. И не ждать очень долго, если бы двигали все координаты с самого сначала медленно.
6) Задаем этой точке какие-то координаты (можно нули - но тогда надо в слайсере задать координаты центра стола. лично я заранее померял координаты центра стола и задаю точку эндстопов - как смещенную на эти координаты.
7) Включаем использование абсолютного перемещения (абсолютных координат)
Двигаемся в какую-то точку ожидания (в моем случае это 0,0,50)
9) Ждем когда все нагреется до нужных температур
10) Начинаем печатать =)
Конкретный код потом покажу, он дома лежит.

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

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

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

Круто нет слов!!!

Спасибо на добром слове. Но sjfw - это децкие игры по сравнению с Marlin'ом каким-нить, жду недождусь когда себе репрап соберу =) Правда уже решил не прусу делать, а Mendel90, который сейчас nophead разрабатывает.
А вообще, тем временем, я думал на тему калибровочных кубов, и насколько они неинформативны, и как мне ща надо будет калибровать свой аппарат на новой прошивке. Что я обычно выясняю в процессе калибрации и дальнейшей настройки принтера:
1) высоту первого слоя
2) корректность настроек steps per mm для осей картезиана (X, Y, Z)
3) корректность настроек для 5d печати - т.е. параметры экструдера и пластика - диаметр пластика, количество шагов на мм пластика, etc.
4) настройки "всасывания" - т.е. наличие соплей при печати нескольких деталей.

Собственно, как можно эти параметры определить при печати обычного 20 мм кубика:
1) визуально
2) Измерить полученные размеры по всем осям. Проблем в том, что если криво настроена высота первого слоя - она сильнее, чем на высоту одного слоя, повлияет на размер по Z.
3) В общем случае - нужно делать кубик со 100% наполнением, тогда будет хорошо видно визуально. Но обычно времени и пластика жалко, а мелкие косяки на повседневной печати почти не видны. И даже в этом случае, есть возможность, что проблемы выставления по осям значения steps per mm, могут быть принято за слишком больше количество пластика в единице времени. Ну или обратное.
4) печатать несколько кубиков на одной платформе, смотреть на наличие соплей.

Проще говоря, надо напечатать как минимум 3 кубика для измерения всех параметров хоть один раз, да и те будут выяснены крайне относительно. Я тут подумал, и предлагаю вот такой вариант:

Его можно напечатать один раз и тогда описанные выше параметры можно узнать так:

1) Если (2) меньше положенного размера, а (1) - попадает в размер - то положение по Z при печати первого слоя слишком низкое
2) Меряем (5) по осям X,Y для понимания steps per mm по ним, меряем (1) для понимания по Z - т.к. даже если были проблемы с первым слоем - к этому слою они уже выправятся
3) Измеряем внутренний диаметр (3), сравниваем расхождение с рахождением по (5). Если неправильные steps per mm, то расхождение будет разное (т.к. на длинной грани ошибка накапливается), а если проблема в том, что мы подаем слишком много пластика - то экструзия выходит слишком широкой (т.к. экструдер плющит ее до заданной высоты, и она всегда правильная, но если пластика больше чем нужно - то расплющивается в стороны он сильнее), соответственно ошибка будет одинаковой для отверстия и для грани.
4) Смотрим на область (6) каждой башенки и наличие соплей между ними - если они есть, то недостаточно всасываем. Смотрим на отверстие (4), проверяем чтобы его внутренняя окружность была замкнута, если есть разрыв - то после всасывания он не восстанавливается корректно (фактически не начинает экструзию в положенном месте, почему у меня это всегда проявлялось в первую очередь на мелких деталях отдельно стоящих).

Пока это просто мысли вслух, сам еще не печатал. Заодно опробовал openscad, моей технарской натуре - крайне прикольная штука. Вот исходник этой модельки, полностью параметризованный:

Код: Выделить всё • Развернуть

base_h = 7;
base_b = 20;
peak_h = 7;
peak_b = 7;
hole1_r = 4;
hole2_r = 1.5;
difference() {
   translate(v=[0,0,base_h/2])cube (size=[base_b,base_b,base_h], center=true);
   translate(v=[-base_b/2+(base_b-peak_b)/2, base_b/2-(base_b-peak_b)/2, 0])cylinder(h=base_h+peak_h, r=hole1_r, $fn=24);
   translate(v=[base_b/2-(base_b-peak_b)/2, -base_b/2+(base_b-peak_b)/2, 0])cylinder(h=base_h+peak_h, r=hole2_r, $fn=16);
}
translate(v=[-base_b/2,-base_b/2,base_h])cube(size=[peak_b,peak_b,peak_h], center=false);
translate(v=[base_b/2-peak_b,base_b/2-peak_b,base_h])cube(size=[peak_b,peak_b,peak_h], center=false);

С удовольствием послушаю комменты, седня сваливаю в москву и проверить его на принтере раньше понедельника возможности не будет =(

я бы ещё проверил как печатается "крышка" - первый сплошной верхний слой после прореженного заполнения (контроль провисания и слипания соседних линий)

Калибровка по осям -меряем расстояние до какой то точки отсчета на принтере, напр высоту сопла над столом, расстояние до стенки, перемещаем по одной оси на какое то фиксированное значение напр на 10 -20 см, меряем, и высчитаем сколько у нас шагов на мм. Я так свою сборку проверял.

как калибровку делать - оно понятно, (кстати хорошо описана в доку по слайсеру)
задача ее проверить

а не лучше ли автоматически выставляться по столу по Z ?

а как автоматически выставлять ? математически корректировать или физически калибровать нагреваемую кровать по трем точкам ? (+2 привода)

посмотрел Mendel90, интересная конструкция, много идей правильных

зачем + 2 привода ?
параллельность плоскости стола и плоскости XOY нужно выставить один раз, перед печатью же нужно калиброваться по Z, что можно делать где нибудь в углу, где торчит из стола метка.. чтобы ниже экструдера не выносить датчик..

ну в принципе согласен, если платформа ровная.
про точность пишут так: "The bed needs to be level to within about 0.05mm for good results printing 0.3mm layers without a raft."

setar писал(а):я бы ещё проверил как печатается "крышка" - первый сплошной верхний слой после прореженного заполнения (контроль провисания и слипания соседних линий)

Ну это не от модели зависит, а от настройки слайсера. Т.е. можно просто выставить чтобы слайсер делал один solid layer и все. А проверять печать мостиков-перемычек.. ну в принципе можно, но сходу я не вижу как это впилить в ту же модель.

Aseris писал(а):Калибровка по осям -меряем расстояние до какой то точки отсчета на принтере, напр высоту сопла над столом, расстояние до стенки, перемещаем по одной оси на какое то фиксированное значение напр на 10 -20 см, меряем, и высчитаем сколько у нас шагов на мм. Я так свою сборку проверял.

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

Duhas писал(а):зачем + 2 привода ?
параллельность плоскости стола и плоскости XOY нужно выставить один раз, перед печатью же нужно калиброваться по Z, что можно делать где нибудь в углу, где торчит из стола метка.. чтобы ниже экструдера не выносить датчик..

Ну, не совсем. Параллельность стола плоскости XOY выставлять как раз приходится чаще всего, т.к. стол нагревается и чуть-чуть деформируется каждый раз, примерно через 5-7 часов печати его параллельность начинает страдать. Но вообще, действительно, про ось Z две задачи есть:
1) Параллельность стола плоскости XY
2) Правильная задача нулевой координаты экструдера по высоте над столом
Я уже какое-то время думал над пробником на оси Z, который бы перед печатью измерял каждый раз расстояние до оси. Но на самом деле смысла в этом мало, т.к. он все равно не является единым целом с экструдером, и ручной процесс измерения от конца пробника до сопла экструдера придется повторять каждый раз когда демонтируешь экструдер (а это делать иногда приходится).
С другой стороны, с помощью пробника можно достаточно неплохо решить проблему неровности стола - померяв расстояние до трех точек, вычислив плоскость стола, а потом просто повернув stl-модель так, чтобы она была ровно перпендикулярна столу (процесс поворота тоже крайне просто - это просто матричное перемножение для каждой координаты в stl'ке). После этого уже мотор по самой оси Z будет компенсировать неперпендикулярность оси Z плоскости стола. Но это надо впиливать в прошивку, плюс делать сам пробник еще.. в принципе, суммарно ничего сверх-сложного в этом нет, но нужно время заняться.