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