Я не люблю травить печатные платы. Ну не нравится мне сам процесс возни с хлорным железом. Там напечатай, тут проутюжь, здесь фоторезист проэкспонируй — целая история каждый раз. А потом еще думай, куда бы слить хлорное железо. Я не спорю, это доступный и простой метод, но лично я его стараюсь избегать. А тут случилось у меня счастье: достроил я фрезер с ЧПУ. Тут же появилась мысль: а не попробовать ли фрезеровать печатные платы. Сказано — сделано. Рисую простенький переходник c завалявшегося esp-wroom-02 и начинаю свой экскурс во фрезеровку печатных плат. Дорожки специально сделал мелкими — 0,5 мм. Ибо если такие не выйдут — то и ну нафиг эту технологию.
Тут нужно маленькое отступление. Есть несколько путей, как из cad’а получить набор gcode’ов для фрезеровки печатной платы. На мой взгляд, они расходятся в зависимости от того, какой САПР вы пользуетесь. Если вы любитель Eagle — то под него существуют специализированные и хорошо интегрированные решения: PCB-GCode, возможность напрямую открывать BRD-файлы в chilipeppr. К сожалению, не так давно Autodesk поменяла политику лицензирования орла, и теперь он уже не так сильно нравится сообществу (можно посмотреть мнение одного видного представителя сообщества).
Так как лично я делаю печатные платы раз в пять лет по большим праздникам — мне для проектирования вполне хватает KiCAD. Для него специализированных удобных решений я не нашел, но есть более универсальный путь — с использованием gerber-файлов. В этом случае все относительно просто: берем pcb, экспортируем нужный слой в gerber (никаких зеркалирований и прочей магии!), запускаем pcb2gcode — и получаем готовый nc-файл, который можно отдать фрезеру. Как всегда, реальность — злая зараза и все оказывается несколько сложнее.
Получение gcode из gerber-файлов
Итак, как получить gerber-файл, я особенно описывать не планирую, я думаю, это все умеют. Дальше нужно запустить pcb2gcode. Оказывается, он требует примерно миллион параметров командной строки, чтобы выдать что-то приемлемое. В принципе, документация у него неплохая, я ее осилил и понял, как получить какой-то gcode даже так, но все же хотелось казуальности. Потому был найден pcb2gcode GUI. Это, как подсказывает название, GUI для настройки основных параметров pcb2gcode галочками, да еще и с предпросмотром.
Собственно, на этом этапе получен какой-то гкод и можно пробовать фрезеровать. Но пока я тыкал в галочки, выяснилось, что дефолтное значение заглубления, которое предлагает этот софт, — 0,05 мм. Соответственно, плата должна быть установлена во фрезере как минимум с точностью выше этой. Я не знаю, у кого как, но у меня рабочий стол у фрезера заметно более кривой. Самое простое решение, что пришло в голову, — поставить на стол жертвенную фанерку, отфрезеровать в ней карман под размеры плат — и она окажется идеально в плоскости фрезера.
Для тех, кто уже хорошо владеет фрезером, эта часть неинтересна. После пары экспериментов я выяснил, что фрезеровать карман обязательно нужно в одном направлении (например, подачей на зуб) и с захлестом хотя бы процентов на тридцать. Fusion 360 мне предложил сначала слишком маленький захлест и ездил туда-сюда. В моем случае результат получился неудовлетворительный.
Учет кривости текстолита
Выровняв площадку, я поклеил на нее двустороннего скотча, положил текстолит и запустил фрезеровку. Вот результат:
Как видно, с одного края платы фреза практически не задевает медь, с другого — слишком углубилась в плату, при фрезеровке пошли крошки текстолита. Посмотрев внимательно на саму плату, я заметил, что она изначально неровная: слегка выгнутая, и, как ты с ней ни мучайся, какие-то отклонения по высоте будут. Потом, кстати, я посмотрел и выяснил, что для печатных плат толщиной более 0,8 мм допуск ±8 % считается нормальным.
Первый вариант борьбы, приходящий в голову, — автокалибровка. По логике вещей — чего уж проще, плата омедненная, фреза стальная, приделал один проводок к меди, другой к фрезе — вот тебе готовый щуп. Бери да строй поверхность.
Мой станок управляется grbl’ом на дешевом китайском шилде. У grbl есть поддержка щупа на пине A5, но вот специального разъема на моей плате почему-то не выведено. Внимательно рассмотрев ее, я все же обнаружил, что пин A5 выведен на разъем SPI порта (подписанный как SCL), земля там тоже рядом есть. С этим «датчиком» одна хитрость — провода нужно переплести между собой. Во фрезере крайне до фига наводок, и без этого датчик будет постоянно давать ложные срабатывания. Даже после переплетения продолжит, но сильно-сильно реже.
Итак, датчик собран, тестером проверен, дальше важный вопрос — как проверить в grbl, что все в порядке и я не сломаю единственный гравер. Немного гугления показало, что ему нужно отправить команду G38.2 Z-10 F5.
Команда говорит: начинай спускаться вниз вплоть до –10 по Z (абсолютная это или относительная высота — зависит от режима, в котором сейчас прошивка). Спускаться будет очень медленно — со скоростью 5 мм/мин. Это вызвано тем, что сами разработчики не гарантируют, что спуск остановится ровно в момент срабатывания датчика, а не чуть позже. Поэтому лучше спускаться медленно, чтобы все остановилось вовремя и не успело уйти в плату по самое не балуйся. Лучше всего первый тест проводить, подняв голову на высоту сильно больше 10 мм и сбросив систему координат. В таком случае, даже если все не сработает и вы не успеете дотянуться до кнопки E-Stop’а, фреза не будет запорота. Можно провести два теста: первый — ничего не делать (и по достижении –10 grbl выдаст «Alarm: Probe Fail»), второй — пока оно едет вниз, чем-нибудь замкнуть цепь и убедиться, что все остановилось.
Дальше надо найти метод, как, собственно, промерить матрицу и исказить gcode как нужно. На первый взгляд, у pcb2gcode’а есть какая-то поддержка autoleveling’а, но поддержки именно grbl’а нет. Там есть возможность задать команды запуска пробы руками, но с этим надо разбираться, а мне, честно говоря, было лень. Пытливый ум мог бы заметить, что у LinuxCNC команда запуска пробы совпадает с командой grbl. Но дальше идет непоправимое различие: все «взрослые» интерпретаторы gcode’а сохраняют результат выполненной пробы в машинную переменную, а grbl просто выводит в порт значение.
Легкое гугление подсказало, что есть еще довольно много разных вариантов, но мне на глаза попался проект chillpeppr:
Это система из двух компонентов, предназначенная для игры с железом из вебни. Первый компонент — Serial JSON Server, написанный на go, запускается на машине, подключенной непосредственно к железке, и умеет отдавать управление последовательным портом по вебсокетам. Второй — работает у вас в браузере. У них есть целый фреймворк для построения виджетов с каким-то функционалом, которые потом можно засовывать на страничку. В частности, у них уже есть готовый workspace (набор виджетов) для grbl и tinyg.
И у chillpeppr’а есть поддержка autoleveling’а. Да еще и с виду он сильно удобнее UniversalGcodeSender’а, которым я пользовался до этого. Ставлю сервер, запускаю браузерную часть, трачу полчаса на то, чтобы разобраться с интерфейсом, загружаю туда gcode своей платы и вижу какую-то фигню:
Посмотрев в сам gcode, который генерирует pcb2gcode, вижу, что он использует нотацию, когда на последующих строках не повторяется команда (G1), а даются только новые координаты:
G00 X1.84843 Y34.97110 ( rapid move to begin. )
F100.00000
G01 Z-0.12000
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
F200.00000
X1.84843 Y34.97110
X2.64622 Y34.17332
X2.69481 Y34.11185
X2.73962 Y34.00364
X2.74876 Y31.85178
X3.01828 Y31.84988
X3.06946 Y31.82249
X3.09684 Y31.77131Судя по тому, что chilipeppr показывает только вертикальные движения, он видит строку G01 Z-0.12 здесь, но не понимает все, что идет после F200. Нужно переделывать на explict нотацию. Конечно, можно руками поработать или напилить какой-нибудь post-processing скрипт. Но никто еще не отменил G-Code Ripper, который среди прочего умеет бить сложные команды gcode’а (типа тех же дуг) на более простые. Он же, кстати, тоже умеет по матрице autoprobe’а искривлять gcode, но встроенной поддержки grbl’а опять нет. Зато можно сделать тот самый split. Мне вполне подошли стандартные настройки (разве что в конфиге пришлось заранее поменять единицы измерения на mm). Результирующий файл начал нормально отображаться в chilipeppr:
Дальше запускаем autoprobe, не забыв указать расстояние, с которого опускать пробу, и ее глубину. В моем случае я указывал, что надо опускать с 1 до –2 мм. Нижняя граница не так важна, ее можно поставить хоть –10, но я бы не советовал: пару раз неудачно выставил начальную точку, с который надо запускать пробу, и крайние точки оказывались за пределами платы. Если заглубление больше — можно и гравер сломать. А так просто ошибка. От уровня верхней границы напрямую зависит то, как долго он будет промерять поверхность. В моем случае реально плата почти никогда не уходила за пределы 0,25 мм вверх или вниз, но 1 мм как-то надежнее. Жмем заветную run и бежим к фрезеру медитировать:
А в интерфейсе chilipeppr появляется потихоньку промеренная поверхность:
Здесь надо обратить внимание, что все значения по Z умножены на 50, дабы лучше визуализировать получившуюся поверхность. Это настраиваемый параметр, но 10 и 50 хорошо работают, на мой взгляд. Я достаточно часто сталкиваюсь с тем, что какая-то одна точка оказывается сильно выше, чем можно от нее ожидать. Лично я связываю это с тем, что датчик ловит-таки наводки и дает ложное срабатывание. Благо chilipeppr позволяет выгрузить карту высот в виде json’ки, ее можно руками после этого поправить, а потом руками же загрузить. Дальше жмем кнопку «Send Auto-Leveled GCode to Workspace» — и в перце уже загружен поправленный гкод:
N40 G1 X 2.6948 Y 34.1118 Z0.1047 (al new z)
N41 G1 X 2.7396 Y 34.0036 Z0.1057 (al new z)
N42 G1 X 2.7488 Y 31.8518 Z0.1077 (al new z)
N43 G1 X 3.0183 Y 31.8499 Z0.1127 (al new z)
N44 G1 X 3.0695 Y 31.8225 Z0.1137 (al new z)
N45 G1 X 3.0968 Y 31.7713 Z0.1142 (al new z)В код добавлены перемещения по Z, которые должны компенсировать неровность поверхности.
Выбор параметров фрезеровки
Запускаю фрезеровку, получаю вот такой результат:
Тут видно сразу три момента:
- Проблема с неровностью поверхности ушла: прорезано (точнее, процарапано) все практически на одну глубину, нигде нет пропусков, нигде не заглубился слишком сильно.
- Заглубление недостаточное: 0,05 мм явно не хватает для этой фольги. Платы, кстати, какой-то неизвестный зверь с AliExpress, толщину меди там не указали. Слой меди бывает разный, наиболее распространенные — от 18 до 140 мкм (0,018—0,14 мм).
- Явно видны биения гравера.
Про заглубление. Подобрать то, насколько глубоко надо опускать гравер, несложно. Но есть специфика. Конический гравер имеет в проекции форму треугольника. С одной стороны, угол сведения к рабочей точке определяет, насколько инструмент тяжело сломать и как долго он проживет, а с другой — чем больше угол, тем шире будет рез при заданном заглублении.
Формула расчета ширины реза при заданном заглублении выглядит так (нескромно взята с reprap.org и исправлена):
2 * penetration depth * tangens (tool tip angle) + tip widthСчитаем по ней: для гравера с углом 10 градусов и точкой контакта 0,1 мм при заглублении 0,1 мм мы получаем ширину реза почти 0,15 мм. Исходя из этого, кстати, можно прикинуть, какое минимальное расстояние между дорожками сделает выбранный гравер на фольге выбранной толщины. Ну и еще, даже если вам не надо очень маленьких расстояний между дорожками, слишком глубоко фрезу опускать все равно не стоит, так как стеклотекстолит очень сильно тупит фрезы даже из твердых сплавов.
Ну и тут есть еще смешной момент. Допустим, у нас есть две дорожки, отстоящие друг от друга на 0,5 мм. Когда мы прогоним pcb2gcode, он посмотрит на значение параметра Toolpath offset (насколько отступать от дорожки при фрезеровке) и фактически сделает между дорожками два прохода, отстоящие друг от друга на (0,5 – 2 * toolpath_offset) мм, между ними останется (а скорее всего, сорвется) какой-то кусочек меди, и будет это некрасиво. Если же сделать toolpath_offset большим, чем расстояние между дорожками, то pcb2gcode выдаст warning, но сгенерирует только одну линию между дорожками. В общем случае для моих применений это поведение более предпочтительно, так как дорожки получаются шире, фреза режет меньше — красота. Правда, может возникнуть проблема с smd-компонентами, но маловероятно.
Есть выраженный случай такого поведения: если задать очень большой toolpath_offset, то мы получим печатную плату в виду диаграммы Вороного. Как минимум — это красиво ;) На эффект можно посмотреть на первом скриншоте из pcb2gcode, что я давал. Там показано, как она будет выглядеть.
Теперь про биения гравера. Это я их зря так называю. Шпиндель у меня неплохой вроде и так сильно, конечно, не бьет. Тут скорее кончик гравера при перемещении изгибается и прыгает между точками, давая вот ту странную картину с точечками. Первая и основная мысль — фреза не успевает прорезать и потому перепрыгивает. Легкое гугление показало, что народ фрезерует печатные платы шпинделем на 50к оборотов со скоростью примерно в 1000 мм/мин. У меня шпиндель дает 10к без нагрузки, и можно предположить, что резать надо со скоростью 200 мм/мин.
Результаты и вывод
Учтя все это, промеряю новый кусок текстолита, запускаю фрезеровку и получаю вот такой результат:
Верхняя ровно так, как вышла из фрезера, нижняя — после того как провел по ней обычным точильным камнем пару раз. Как видно, в трех местах дорожки не прорезались. В целом по всей плате ширина дорожек плавает. С этим еще надо разбираться, но у меня есть предположение, в чем причина. Сначала я крепил плату на двусторонний скотч, и она достаточно часто отходила. Потом в паре мест прихватил еще краями головок саморезов. Вроде держаться стала лучше, но все равно немного играет. Подозреваю, что в момент фрезеровки она прижимается к площадке и из-за этого, собственно, не прорезается.
В общем, перспективы у этого всего есть. Когда процесс отработан, построение матрицы высот занимает минут пять-семь, потом непосредственно фрезеровка — пару минут. Вроде можно экспериментировать дальше. Зато можно потом сверловку делать на том же станке. Еще прикупить заклепок, и будет счастье! Если тема интересна, то могу написать еще одну статью про сверловку, двусторонние платы и пр.