Новости

Тут и там за смешные деньги нам предлагают купить печатную плату, которая уже оснащена всем необходимым. Здравый смысл такого подхода понятен: не нужно тратить приличное количество денежных знаков, не нужно разбираться с программным обеспечением (в интернете полно готовых библиотек и руководств на все случаи жизни), не нужно ДУМАТЬ. Так позиционируют данные решения те, кто их продает. Но при ближайшем рассмотрении становятся очевидны сложности в использовании оборудования такого рода. Печатные платы, которые предлагает рынок, сделаны зачастую с несоблюдением даже элементарных канонов разработки электронных узлов. Программное обеспечение «из коробки» на поверку и при детальном анализе вводит в ступор, – код очень тяжело портировать и (что особенно неприятно) почти невозможно модернизировать. При попытках оптимизировать его работу, из монитора начинает раздаваться оглушающий «грохот» сыпящихся костылей. Многолетний опыт изучения (добровольного и не очень) способностей «китайской» электроники, убедил в одном: никогда не разрабатывать свои изделия на подобных печатных платах. Конечно, речь идет в первую очередь о том, что называется «Arduino», и выстроенной вокруг этого слова экосистеме.

Идея использовать Arduino (равно как и остальной AliExpress) прочно сидит в голове любого потенциального заказчика, и очень серьезно портит жизнь тем, кто действительно способен что-то «разрабатывать». Оговоримся, что мы убрали из рассмотрения толпу студентов 1-2 курса, которые предлагают вам разработать устройства абсолютно любой сложности за неделю и несколько десятков тысяч. А из-за таких вот «разработчиков» заказчик идет искать дальше, где бы в итоге ему разработать столь желанную железяку. И у него округляются глаза когда он, пришедший после пары таких студентов к тем, кто занимается разработкой профессионально слышит ценник, на порядок отличающийся от озвученного ранее, да и сроки уже далеко не «на следующей неделе».

Написанное выше можно считать просто криком души обоснованием затраченных усилий. Теперь к делу.

С чего обычно начинается любая разработка? – с повода. В какой-то момент, уже имея немалый опыт работы с промышленным оборудованием в области 3D печати и вдоволь намучавшись с некачественным персональным оборудованием, мы решили, что «пора». Пора сделать что-то, что будет работать на уровне тех самых промышленных шкафов, но все еще стоить денег, доступных небольшому частному бизнесу и простым смертным, собирающимся заняться 3D печатью. Допустим, клиент хочет купить оборудование и начать решать собственные производственные проблемы, не вникая в тонкости работы купленной техники.

Такие пользователи не хотят сидеть напротив своего принтера и смотреть за процессом нанесения слоев. Не хотят ловить момент, когда все уже отлипло от стола и пора перезапускать печать. Им неинтересно, как модернизировать механизм экструдера так, чтобы он наконец перестал клинить и соскребать с филамента верхний слой. Они не хотят понимать, почему в очередной раз принтер просто взял и закончил печать на 99%, которые на поверку оказались восьмьюдесятью. Да и калибровать стол через одну печать желания такой пользователь не имеет решительно никакого. Он просто хочет нажать кнопку и уйти, а потом забрать свою деталь. А если он её не получил, считать код ошибки с экрана позвонить в техническую поддержку и дождаться тех, кто устранит проблему в соответствии с четким техническим регламентом. И, наконец, далеко не все обладатели 3д принтеров хотят быть постояльцами тематических форумов с подробным рассмотрением вопросов исправления проблем только что купленного оборудования.

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

Мы начали с составления функциональной схемы будущего принтера. Несмотря на то, что за плечами уже имелось достаточное количество разработанной техники совершенно разного направления, промышленным оборудованием заниматься нам еще не приходилось. Кроме того, предыдущий опыт сыграл с нами довольно злую шутку, и вместо копирования архитектуры со «старших братьев», мы стали делать все так, как делаем всегда. В основе концепта, как и обычно в наших проектах, лежало интеллектуальное управление двигателями – нужно было иметь вменяемую обратную связь по току в фазах моторов, четкое представление о том, сделан в итоге шаг или нет, пошло ли что-то не так в процессе попытки сделать шаг. Было очевидно, что моторы не должны «петь». С учетом этих требований и разрабатывался модуль привода. Заказали. Спаяли. Запустили. Написали под него ПО и протестировали. Работает. Идем дальше.

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

Нам необходимо было разработать материнскую плату. Первоочередной задачей здесь, отличающей нас от китайских DIYплат стояла самодиагностика и надежность. Звучит не сложно, но таит под собой темный лес проблем при проектировании, написании ПО и отладке. Нормально реализованная самодиагностика – именно то, что необходимо нам как разработчикам для обеспечения адекватной удаленной техподдержки в будущем. Это значит, что мы должны иметь полное представление о работоспособности всех узлов, входящих в состав принтера. Каждый узел должен быть частью общей системы управления, а не отдельно стоящим, пристегнутым к САУ (системе автоматического управления) по принципу «лишь бы работало». Все нагреватели, датчики, подсветки и вентиляторы должны быть предусмотрены изначально. Мы должны определять, подключен ли тот или иной узел, и своевременно замечать, когда он не в штатном состоянии или вообще отключен от системы. При этом важно учесть тот факт, что конечный пользователь может захотеть внести свои изменения в систему, и наша задача здесь не просто не предоставить ему эту возможность без серьезного вмешательства в САУ (и каких либо гарантий дальнейшей работоспособности в целом), а сделать так, чтобы даже не было необходимости этим заниматься. Опять же, подготовить плацдарм для будущего технического обслуживания – всегда крайне полезно.

В результате нами была разработана материнская плата, изображенная на рисунке:

По первоначальной задумке архитектура была основана на микроконтроллере STM32F4, работающем совместно с одноплатным компьютером RaspberryPi 3.0. В таком виде вся эта электроника и была установлена внутрь принтера. Здесь мы допустили серьезную ошибку, которая стоила большого количества времени. Дело в том, что все общение пользователя с принтером осуществляется посредством одноплатного компьютера, – в него пользователь загружает файлы для печати, он же отображает всю необходимую информацию на экране, а значит, должен быть «в курсе» всего, что происходит в принтере. По нашему плану, каналом связи между одноплатным компьютером и управляющей платой был обыкновенный UART, в который мы не пролезли.

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

1. Сервисная информация (уровни токов, напряжений, температуры).
2. Текущие координаты печатной головы, стола.
3. Новые задания на перемещения, нагрев, чистку сопел, смену сопел.

Однако, надо сказать, что большое количество данных, которое нужно протащить - не основная проблема. Основная проблема — это процесс передачи этих данных. Дело в том, что просто так передавать и принимать данные в контроллер нельзя. Велик шанс их потерять, или принять/передать их в искаженном виде, чего, конечно, допускать нельзя. По этой причине, необходимо использовать протокол, как минимум транспортного уровня, в котором реализованы подтверждения, запросы, проверки цельности пришедших/ушедших данных. В таком варианте количество «ценных» данных в единицу времени резко сокращается, а вот загруженность шины серьезно растет. В нашем случае, это вылилось в банальное ограничение скорости печати. Мы не могли печатать деталь, со скоростью выше 30 мм/с из-за «узкого» канала связи. Поэтому было решено переехать на Ethernet, а заодно, для последующего удешевления отсека электроники, перенести на эту же плату управляющую электронику драйверов шаговых приводов. Наконец, чтобы создать вменяемую сетевую архитектуру, RaspberryPi мы заменили на полноценный MiniITX ПК с двумя Ethernet разъемами. Результатом стала такая вот материнская плата следующей ревизии:

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

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

В заключение данной статьи хотелось бы сказать о том, что прямо в данный момент нашей командой прикладываются все усилия, чтобы пользователи наконец поняли, что счастье не в Arduinoи Open-Sourсe, и не ремонтопригодности купленной техники в домашних условиях, а в достижении поставленной задачи. Люди же перестали ездить на советской авто-классике, потому что лежать под машиной раз в неделю просто надоело. Так а чем же рынок промышленного оборудования отличается от авторынка? Массовостью, да и то с натяжкой. А люди-то все те же. Разработка и сервисное обслуживание – задача не пользователя, а производителя.

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