KiCad и ГОСТ. Библиотека УГО
Дополняем цикл статей по УГО для различных САПР-схемотехники. В данном топике описывается процесс создания компонента УГО для KiCad.
KiCad — распространяемый под лицензии GNU GPL программный комплекс класса EDA с открытыми исходными текстами, предназначенный для разработки электрических схем и печатных плат.
Внимание! Под катом трафик!
KiCad включает в себя пять основных программ:
kicad — менеджер проектов; 
eeschema — редактор электрических схем; 
— встроенный редактор символов схем (библиотечных компонентов); 
cvpcb — программа для выбора посадочных мест, соответствующих компонентам на схеме; 
pcbnew — редактор печатных плат; 
— встроенный редактор образов посадочных мест (библиотечных компонентов); 
— 3D Viewer — 3D-просмотрщик печатных плат на базе OpenGL (часть pcbnew); 
gerbview — просмотрщик файлов Gerber (фотошаблонов); 
А также:
wyoeditor — текстовый редактор для просмотра отчётов.
bitmap2componrnt — инструмент для создания логотипа из изображения; 
Универсальный калькулятор печатных плат; 
— Русский интерфейс, справка, учебник;
Поддержка KiCad — продукта (СПО) поражает своей активностью.
Windows, Linux, FreeBSD и т.д…
— Стандартные библиотеки и отдельная сборка KiCad по стандартам ГОСТ;
Очень большое собрание библиотек:
www.kicadlib.org
Сборка KiCad по стандартам ГОСТ ЕСКД:
— Оригинальная интернациональная сборка;
— Русская сборка для Linux или Windows XP;
— Текущая стабильная версия «KiCAD GOST 4005-stable» в виде Windows exe-инсталлятора с основными GOST-патчами, автоустановкой и автоудалением, с возможностью включения en/ru-документации, библиотек компонентов lib/mod/3d и примеров применения.
— Штампы соответствующие требованиям ГОСТ (в Российской сборке);
Единственное почему то отсутствует основная надпись по форме 2а (ГОСТ 2.301-68).
— KiCad бесплатен, даже для коммерческого использования;
— Эффективные возможности трассировки;
— Всесторонняя проверка проекта;
— 3D предпросмотр платы;
Имеется возможность выгрузить список электрических цепей netlist для редактора топологии платы pcbnew или для Spice-моделирования схемы.
С этим если честно даже не разбирался.
В просторах интернета имеется куча всевозможных утилит для конвертирования данных KiCad в другие данные различных САПР. Самые популярные это KiCAD P-CAD — утилиты.
— Создание файлов для производства; 
Генерация (создание) законченных Gerber форматов, готовых к исполнению на CNC.
—Печати в редакторе корпусов;
Иногда разрабатываемое посадочное место, хочется распечатать и примерить на компоненте.
— Создание собственных библиотек;
Это основной пункт статьи, его коснемся ниже…
Недостатки (на мой взгляд):
— Интуитивно-непонятный пользовательский интерфейс;
Сразу разобраться в KiCad, следуя только подсказкам и пунктам меню, практически не возможно.
Придется перелобать несколько страниц мануалов, и наступить пару раз на грабли.
— Не удобное ручное (и автоматическое позиционирование — его фактически нет, это делается только сторонними программами);
Возвращаемся к пункту граблей.
— Отсутствие возможности представления списка компонентов в виде дерева, с строгой типизацией по функциональному назначению;
Этого я уже касался в предыдущей статье. Вот выдержка:
С этим пунктом мне честно говоря совсем не понятно. Сейчас объясню: дело в том, что сам по себе САПР, подразумевает продукт облегчающий разработку тех или иных устройств и элементов, конечно в данном случае касаемо EDA-систем. Так вот: Как можно было не реализовать список элементов схем в виде дерева? Скажете это не удобно, и не повлияло бы на производительность? Это вопрос касается собственно всех EDA-систем.
— Отсутствие печати в редакторе компонентов;
— Отсутствие возможности произвольного выбора наименования списка компонентов (по типу, номиналу, корпусу, ну и т.д) и отсутствие фильтра по компонентам;
Тоже самое, выдержка из предыдущей статьи:
Т.е. у каждого разработчика свои предпочтения, мне например удобно представлять список по наименованию и типу корпуса, кому то удобно представлять список по типу элемента (например MCU) и наименованию, ну и т.д.
Отсутствие фильтра по компонентам — скорее связанно с невозможностью реализации нормального фильтра без применения СУБД, т.к. все компоненты и посадочные места разнесены по файлам, а это уже что-то, сами понимаете.
— Отсутствие встроенного симулятора Spice-моделей;
Хотелось бы, но будет уже сложный продукт.
Создание собственных библиотек:
Нам необходим встроенный редактор символов схем (библиотечных компонентов), запускаем его следующим образом:
Вначале запускаем eeschema (редактор электрических схем), видим такую картину: 
1. Область главного меню приложения;
2. Область панели инструментов;
3. Область размерности и шага сетки редактора (настройка рабочей области).
4. Область элементов схем и перемещения по иерархии схемы.
5. Рабочая (основная) область приложения (область редактора).
Далее запускаем встроенный редактор символов схем (библиотечных компонентов), это делается путем нажатия кнопки [Редактор библиотек] 
,- в панели инструментов, редактора схем.
Видим следующий интерфейс: 
1. Область главного меню приложения;
2. Область панели инструментов;
3. Область размерности и шага сетки редактора (настройка рабочей области);
4. Область элементов компонента;
5. Рабочая (основная) область приложения (область редактора);
Далее нам необходимо выбрать рабочую библиотеку, ту библиотеку в которой мы хотим работать (создавать или редактировать компоненты).
Это делается так: на панели инструментов нажимается кнопка [Выбор рабочей библиотеки] 
, выбиваем библиотеку с которой хотим работать и нажимаем [Ок]. 
Если мы хотим создать новый компонент в этой библиотеке, тогда в панеле инструментов выбираем [Создать новый компонент] 
, если же мы хотим отредактировать существующий, тогда выбираем из панели элемент [Загрузить компонент для редактирования из текущей библиотеки] 
.
В первом случае мы видим форму в которой необходимо задать параметры компонента.
В нашем случае пусть будет [Имя компонента]: RES_0805, а <Обозначение по умолчанию]: R.
и соответственно нажимаем [Ок].
Во втором же случае у нас появится окно для выбора редактируемого компонента: 
в данном случае выбираем [Выбор с просмотром]: 
Но так как мы собираемся создать свой оригинальный компонент, то останавливаемся на первом выборе [Создать новый компонент].
Задаем параметры указанные выше (RES_0805/R), переходим в рабочую область и перемещаем элементы рабочей области, путем клика правой кнопки мыши на одном из элементов, и выбора пункта [Переместить поле] 
.
Перемещаем (расчищаем рабочую область), далее рисуем компонент используя область «4. Область элементов компонента» редактора.
Далее добавляем выводы для компонента, для этого из области «4. Область элементов компонента» редактора, выбираем элемент [Добавить вывод компонента] 
, видим такое окно: 
заполняем все параметры, жмем [Ок],- соответственно для первого и второго выводов.
Видим результат: 
Далее, чтобы сохранить компонент, выбираем [Сохранить текущую библиотеку на диске], из области «2. Область панели инструментов». Соглашаемся со всеми вопросами приложения. 
и 
.
Собственно теперь наш новый компонент в библиотеке. И готов к использованию.
Единственное позже опишу как сохранять компонент в новой (своей) библиотеке.
И коснусь нюанса масштабирования, размерности и шага сетки. т.к. в KiCad она кратна 0.0254 — 1.27 мм, а стандарты ГОСТ требуют несколько иного. В связи с чем есть подозрения, что сборка KiCad по стандартам ГОСТ ЕСКД, не соответствует таковым, в веду отклонения от пропорций компонентов, которых требуют стандарты.
правильная организация библиотек kicad
что-то запутался я с либами kicad’а. Как я понимаю, в настоящий момент зоопарк выглядит примерно так:
- *.lib — файлы с символами для схемотехнического редактора, аналог SchLib в альтиуме
- директория *.pretty с файлами *.kicad_mod — файлы посадочных мест, ссылки на которые можно указывать в *.lib
- директория *.3dshapes с файлами *.wrl — 3d-модели, на которые могут ссылаться посадочные места
Как вообще принято это дело в порядке поддерживать? То, как предлагают работать в kicad, меня просто убивает:
- lib-файлы хранятся локально, в проекте (*.pro) указываются те, что используются.
- футпринты предлагают хранить в виде ссылок на (фак мой мозг!) гитхабовские репозитории. Т.е. в стандартной поставке кикада их нет, но можно нафигачить себе локальную копию с помощью их мастера.
- 3д-модели опять же хранятся локально, хотя ссылаются на них футпринты из гитхаба.
Абзац полный. Чего хочется: такого способа организации библиотек, при котором центральным понятием был бы компонент (состоящий из символа, футпринта и опционально 3д-модели). Если уместна аналогия — то как IntLib в Altium Designer.
Может, те, кто пользуются kicad’ом расскажут или намекнут, как с этим адом бороться.
У одного символа может быть несколько футпринтов, одному футпринту могут соответствовать несколько символов.
Как у тебя дела обстоят спустя год? Разобрался:)
фигово. Завел репозиторий, на каждый компонент (символ, футпринт, 3д-модель) — своя ветка. Когда рисую какую-нить поделку — сливаю необходимые ветви.
Говно все это. До DbLib альтиумовских тут срать и срать.
Странно, видимо так и не договорился ты с ним. У меня локально одна глобальная библиотека с тремя папками components, models, package3d лежит и проблем никаких нет. А в том, что модель, компонент и футпринт не привязаны друг к другу — весьма огромный плюс зачастую. Может попробуешь на свежую голову еще раз?
еще раз. У альтиума тоже символ, футпринт и 3д-модель не привязаны друг к другу. Но есть сущность, которая их объединяет (DbLib, IntLib — кому как нравится. DbLib может вообще представлять собой линк на csv-файл, в котором прописано, какому партнамберу что соответствует).
Когда ты идешь на тот же digikey — тебе надо знать partnumber, а не мифические связки из названий символа и футпринта.
Другой пример — у меня в альтиуме есть библиотека для резисторов и конденсаторов для поверхностного монтажа. В partnumber забиты данные про номинал, размер и точность (типа RES-1k-0402-5%). И это удобнее, чем держать в голове весь ряд E96.
Понимаешь, одно дело — поделка с десятком разных типов компонентов, их можно и в голове держать. Когда их количество измеряется сотнями — волей-неволей захочешь, чтобы BOM требовал минимально редактирования.
Ты требуешь от кикада быть альтиумом и вести себя как альтиум. Не будет этого, он другой. И BOM-лист там по-другому используется. Это всё равно, что от убунты требовать быть вендой и вести себя как венда. Если нужен альтиум, пользуйся им, если хочешь пользоваться кикадом, нужно просто немного переключить мозги с привычного.
я иногда смотрю, что они с кодом творят. В общем, пока что складывается ощущение, что они движутся в никуда. Разрозненные форматы хранения данных (зачем-то для футпринтов — s-exp, для символов — текстовый велосипед), непродуманный API (который еще и ломают в два счета — а на него у меня свои «инструменты» привязаны). Питон у них — тема для отдельного баттхерта. Зачем они вообще его в таком виде туда завезли — мне непонятно. Ничего с его помощью сделать нельзя.
Вот не покидает меня ощущение, что пишут его лебедь, рак и щука.
На самом деле, когда я переползал на кикад, то первое на что я обратил внимание — это его достаточность для практически любого проекта. Да, есть некоторые сложности, но и сталкиваешься с ними не то что не каждый день, а раз в пятилетку. Во всем остальном кикад скорее подкупает тем, что в нем вполне все можно под себя сделать. Тот же вом-лист вполне может тебе выдавать и партнамбер и даже группировать по нему лист, вопрос в содержании этой информации в посадочных местах. Да, в альтиуме это сделали за тебя, а кикад требует чтоб это сделал ты. Собственно вся проблема только в этом по сути, других нет. Понимаю, не хочется заморачиваться, но опять же, есть куча очень неплохо переработанных библиотек не из кикадовского гита, никто не запрещает их использовать. Сейчас я лично привык к кикаду и понял основную проблему любого софта — привычка юзера, зачастую перерастающая в синдром утенка. Как уже сказали, нужно было просто переключить мозги и поиграться с софтом немного, все становится на свои места.
я иногда смотрю, что они с кодом творят.
Да в общем-то в порядок приводят. Иногда почему-то окольными путями, это да, но в целом картина выстраивается приближающейся к логике.
складывается ощущение, что они движутся в никуда.
У меня лично другое ощущение: они стремятся к максимальной кастомизации пользователем своего инструмента. Как говорится, добро пожаловать в мир открытого софта. Много не сделано не из-за лени разработчиков, а для того чтобы пользователь допилил это сам. И именно это самое классное, что кикадовцы не ведут меня к чему-то конкретному, по сути загоняя в рамки, а скорее дают велосипед, руль и педали крути сам куда хочешь. Пока им это удается.
непродуманный API (который еще и ломают в два счета — а на него у меня свои «инструменты» привязаны)
Было дело. Но согласись, что проблемы возникают все-таки реже. Так что я скорее вижу в этом движение в сторону именно стабильности, а не ломкости.
Питон у них — тема для отдельного баттхерта. Зачем они вообще его в таком виде туда завезли — мне непонятно. Ничего с его помощью сделать нельзя.
Не совсем тебя понял. А что именно не получается и в каком таком «не таком» виде там питон? Можешь пример какой-нибудь привести?
Да, гитхаб — это полный трешняк. К счастью, все можно скачать и локально использовать, что я и сделал.
Но все равно, лучше по максимуму футпринты и элементы хранить в директории с проектом, потому как в следующей версии может оказаться, что в «стандартных» футпринтах и либах чего-то не хватает. И опять придется рисовать. Уже напарывался на такой косяк.
А жестко связать компонент с футпринтом у тебя не получится: ведь многие вещи идут в куче разных исполнений. Особенно пассивка всякая.
Насчет 3D-моделей — на кой черт оно тебе нужно?
Зато все хранится в текстовых файлах, и ты спокойно можешь нужный функционал добавить хоть баш-скриптами!
Кстати, fped с новым способом хранения футпринтов не работает, это печально.
Насчет 3D-моделей — на кой черт оно тебе нужно?
Часто при дизайне корпуса нужно экспортировать 3D-модель платы (иногда даже с правильной высотой всех конденсаторов), чтобы посмотреть, как она входит, а если не входит, что нужно сточить и где резать отверстия для портов.
Насчет 3D-моделей — на кой черт оно тебе нужно?
Для дизайна устройства. Проектируя корпуснужно понимать что там как будет сидеть. Особенно если корпус особо выпендрежный и платы приходится делать многоэтажными. Бывало у меня такое. Для домашних поделий оно не нужно конечно, а даже при мелкой серии уже понимание нужно иметь, а при крупняке и подавно.
Да он собственно как свалка и задумывался. Первым делом выкачиваешь/генеришь то, что тебе нужно, а потом только заглядываешь периодически, не появилось ли чего интересного.
Но все равно, лучше по максимуму футпринты и элементы хранить в директории с проектом, потому как в следующей версии может оказаться, что в «стандартных» футпринтах и либах чего-то не хватает.
Черти когда собрал себе библиотеку и так и таскаю с компа на комп или на серваке держу. На гитхаб хожу раз в трехлетку поглазеть нет ли чего нового. Прямо с проектом держать библиотеку не нужно, достаточно одной глобальной. Главное сохранять бэкапить на будущее.
для меня ценность python api представлял бы, если бы на нем можно было писать интерактивные скрипты для работы с печатной платой, если бы все действия, которые я могу сделать через гуй, я мог бы выполнить и из скрипта. А получается какая-то фигня.
Например, мне хочется выполнить какие-то действия над текущим выделением, а через api к selection manager’у никак подлезть не получается — тупо не реализовано. А крестовый код, как я уже отметил, они регулярно ломают.
если бы все действия, которые я могу сделать через гуй, я мог бы выполнить и из скрипта. А получается какая-то фигня.
Да, здесь я с тобой соглашусь. Пока что, увы, все так. Просто не каждый день я стремлюсь автоматизировать трассировку плат или что-то еще, ручная трассировка как-то скорее вопрос душевного спокойствия.
С другой стороны сделай все-таки скидку для софта, который сильно младше того же альтиума, так еще и разрабатывается по сути на голом энтузиазме. Мне лично хочется верить, что кикадовцы все-таки смогут довести его до ума. На сайте они кстати весьма серьезную задачу перед собой продекларировали. Хотят полноценно встать в один ряд с альтиумом. Будем посмотреть)
