Выпуск релиза KiCAD 6.0
Новость, конечно, не совсем про робототехнику, но, согласитесь, иметь возможность быстро набросать прототип платы управления, не прибегая к монструозным проприетарным EDA, всегда ценна. Новость действительно достойна внимания, так как выпуск мажорного релиза - это в KiCAD нечастое явление. Предыдущая версия 5.0 была выпущена ещё в 2018 году.
Среди улучшений можно отметить:
- повышение удобства интерфейса для бесшовного переключения между редактором схем и редактором плат
- возможность создавать классы цепей для более удобного присвоения правил
- поддержка многосигнальных шин для упрощения иерархического проектирования
- гибкий настраиваемый редактор плат
- обновлённый визуализатор внешнего вида платы с возможностью задавать параметры освещения и трассировку лучей
- новая система правил проектирования (design rules), позволяющая задавать сложные логики проверки для отдельных классов цепей и слоёв печатной платы
- переход с XSLT на Python для написания скриптов; сам Python API претерпел значительные изменения и теперь не использует SWIG
- полная поддержка русского языка (ну и вообще с локализацией у них всё круто благодаря одной компании из числа контрибьюторов)
- ну и, конечно, вагон и тележка мелких изменений/исправлений/улучшений
Подробный перечень изменений
Разработчики уже собирают средства на разработку версии 7.0. На данный момент собрано уже 40 из 50 тыс. долларов. По своим затратам из фонда команда публикует небольшие отчёты.
#kicad #opensource #eda
Новость, конечно, не совсем про робототехнику, но, согласитесь, иметь возможность быстро набросать прототип платы управления, не прибегая к монструозным проприетарным EDA, всегда ценна. Новость действительно достойна внимания, так как выпуск мажорного релиза - это в KiCAD нечастое явление. Предыдущая версия 5.0 была выпущена ещё в 2018 году.
Среди улучшений можно отметить:
- повышение удобства интерфейса для бесшовного переключения между редактором схем и редактором плат
- возможность создавать классы цепей для более удобного присвоения правил
- поддержка многосигнальных шин для упрощения иерархического проектирования
- гибкий настраиваемый редактор плат
- обновлённый визуализатор внешнего вида платы с возможностью задавать параметры освещения и трассировку лучей
- новая система правил проектирования (design rules), позволяющая задавать сложные логики проверки для отдельных классов цепей и слоёв печатной платы
- переход с XSLT на Python для написания скриптов; сам Python API претерпел значительные изменения и теперь не использует SWIG
- полная поддержка русского языка (ну и вообще с локализацией у них всё круто благодаря одной компании из числа контрибьюторов)
- ну и, конечно, вагон и тележка мелких изменений/исправлений/улучшений
Подробный перечень изменений
Разработчики уже собирают средства на разработку версии 7.0. На данный момент собрано уже 40 из 50 тыс. долларов. По своим затратам из фонда команда публикует небольшие отчёты.
#kicad #opensource #eda
git для не-софтовых проектов
Начиная с какой-то версии KiCad сохраняет все файлы проекта как текстовые в виде псевдокода на Lisp-подобном языке или в нотации S-выражений. В git такое удобно версионировать, можно просмотреть что конкретно поменялось. На скрине пример git diff файла проекта PCB, где немного подвинули посадочное место.
#git #scm #kicad
Начиная с какой-то версии KiCad сохраняет все файлы проекта как текстовые в виде псевдокода на Lisp-подобном языке или в нотации S-выражений. В git такое удобно версионировать, можно просмотреть что конкретно поменялось. На скрине пример git diff файла проекта PCB, где немного подвинули посадочное место.
#git #scm #kicad
👍15
KiCad как система проектирования электрических схем общего назначения
Когда мы разрабатывали намотчик, возникла идея описать электрическую схему станка не в рандомной рисовалке, а непосредственно в KiCad, где мы разрабатываем другие электрические схемы устройств. В случае удачного исхода эксперимента можно было бы описать подобным образом что-то по-сложнее - например, робота-манипулятора.
Разумеется, для систем разного масштаба существуют свои инструменты - для микросхем уже давно существуют языки описания аппаратуры и никто там принципиальные схемы не рисует по понятным соображениям, однако ту же простую электроустановку или даже схемы электропроводки здания вполне могут быть описаны той же или похожей нотации (граф из узлов-компонентов и рёбер-соединений), в которой это делается с печатными платами, не плодя лишних зависимостей и не прибегая к таким монстрам как EPLAN. Тем более, что в KiCad существует возможность создавать иерархические проекты.
Довольно быстро возникла проблема, что для формирования BoM-листа из проекта такой установки необходимо каким-то образом явно задавать кабель. Дело в том, что линии или рёбра графа в EDA символизируют собой электрическое соединение с около-нулевым сопротивлением, имплементированным в конструкции печатной платы в виде медного полигона/дорожки определённой толщины. Эти дорожки являются некой фигурой умолчания и не включаются в перечень комплектующих. Даже сама плата без компонентов не фигурирует в перечне по умолчанию. Кабель же нужно учитывать и включать явно в схему, чтобы он попал в закупочную ведомость. В противном случае высок шанс про него забыть. Помимо этого, кабель может быть нестандартным - с какими-нибудь перекрёстными соединениями вместо простых шлейфоподобных соединений (как в случае соединения шагового двигателя и контроллера в станке), поэтому в ходе экспорта документации нужно формировать для него отдельный чертёж, чтобы на производстве всё сделали правильно.
Если выделить такой кабельный коннектор в подпроект, то для формирования его BoM-листа нужно оформить оба разъёма на концах кабеля в виде отдельных компонентов, а также расположить на каждой из линий соединения ещё один компонент (можно в виде кастомного 0-резистора), отражающий позицию кабеля определённых характеристик (цвет, толщина, сплав). Тогда перечень комплектующих для такого соединителя будет сформирован корректно. В общем, решение не столь изящно как хотелось бы, но вполне может работать, особенно если придумать интеграцию с какой-нибудь CAD-системой.
Экспериментальный проект находится в git-репозитории Намотчика в отдельной ветке.
#hardware #kicad #winder
Когда мы разрабатывали намотчик, возникла идея описать электрическую схему станка не в рандомной рисовалке, а непосредственно в KiCad, где мы разрабатываем другие электрические схемы устройств. В случае удачного исхода эксперимента можно было бы описать подобным образом что-то по-сложнее - например, робота-манипулятора.
Разумеется, для систем разного масштаба существуют свои инструменты - для микросхем уже давно существуют языки описания аппаратуры и никто там принципиальные схемы не рисует по понятным соображениям, однако ту же простую электроустановку или даже схемы электропроводки здания вполне могут быть описаны той же или похожей нотации (граф из узлов-компонентов и рёбер-соединений), в которой это делается с печатными платами, не плодя лишних зависимостей и не прибегая к таким монстрам как EPLAN. Тем более, что в KiCad существует возможность создавать иерархические проекты.
Довольно быстро возникла проблема, что для формирования BoM-листа из проекта такой установки необходимо каким-то образом явно задавать кабель. Дело в том, что линии или рёбра графа в EDA символизируют собой электрическое соединение с около-нулевым сопротивлением, имплементированным в конструкции печатной платы в виде медного полигона/дорожки определённой толщины. Эти дорожки являются некой фигурой умолчания и не включаются в перечень комплектующих. Даже сама плата без компонентов не фигурирует в перечне по умолчанию. Кабель же нужно учитывать и включать явно в схему, чтобы он попал в закупочную ведомость. В противном случае высок шанс про него забыть. Помимо этого, кабель может быть нестандартным - с какими-нибудь перекрёстными соединениями вместо простых шлейфоподобных соединений (как в случае соединения шагового двигателя и контроллера в станке), поэтому в ходе экспорта документации нужно формировать для него отдельный чертёж, чтобы на производстве всё сделали правильно.
Если выделить такой кабельный коннектор в подпроект, то для формирования его BoM-листа нужно оформить оба разъёма на концах кабеля в виде отдельных компонентов, а также расположить на каждой из линий соединения ещё один компонент (можно в виде кастомного 0-резистора), отражающий позицию кабеля определённых характеристик (цвет, толщина, сплав). Тогда перечень комплектующих для такого соединителя будет сформирован корректно. В общем, решение не столь изящно как хотелось бы, но вполне может работать, особенно если придумать интеграцию с какой-нибудь CAD-системой.
Экспериментальный проект находится в git-репозитории Намотчика в отдельной ветке.
#hardware #kicad #winder
GitLab
Files · 7-kicad_machine_sch · Robossembler / ЧПУ станки и оборудование / Robossembler Winder · GitLab
Намоточный станок для изготовления роторов/статоров. Зеркало: https://forge.robossembler.org/robossembler/motor-wire-winder
👍5
EDA, системная инженерия и IEC 81346
Задача с проектированием кабеля в KiCad заставила задуматься о том как в существующих инструментах разработки правильно описывать такого рода интерфейсы в проектах сложной много-составной электроники (роботах). Одной из мета-моделей для таких описаний служит системная инженерия и связанные с ней косвенно стандарты разработки. Например, ISO/IEC 81346, предписывающий правила обозначений для электротехнических систем с поправкой на множественность описаний для одних и тех-же физических объектов (multi-view). Для каждого компонента/системы стандарт выделяет, по меньшей мере, три вида описания: функциональное (как работает: функциональные блоки, порты, потоки), конструктивное (из чего собрано: бом-лист, модули и интерфейсы) и пространственное (где размещается: координаты и габариты мест размещения). Каждое из описаний представляет собой структуру типа дерево (breakdown structure), с декомпозицией по частям/целым. В новой версии стандарта 2022 года было добавлено разбиение по типу, в учебниках Анатолия Левенчука по системному мышлению добавляются также разбиения по стоимости и работам.
Для простоты мы пока остановимся на трёх базовых видах разбиений и попробуем отразить их на KiCad. Функциональным описанием является принципиальная схема, которая определяет количество, тип, номиналы компонентов и их соединения/порты. Однако, в чертёж принципиальной схемы добавляется также и информация о кодах производителей (manufacturer part number, MPN) и типах интерфейсов компонент (в случае с печатной платой это посадочные места - 0603, 1210, SOIC-8), что формально относится к конструктивному описанию (из чего собирается и как соединяется физически). Уже это делает затруднительным гибкое версионирование такого рода описаний - поставщики и их компоненты могут регулярно меняться из-за ситуации на рынке, что по идее должно приводить только к обновлению закупочных позиций, не затрагивая основной чертёж, но разработчики вынуждены вносить изменения в принципиальную схему без существенных на то оснований. В свою очередь, проект топологии печатной платы .kicad-pcb содержит в себе информацию как о количестве и типах посадочных мест, которые размещаются на плате, так и о размещении.
Так вот, возвращаясь к нашему кабелю, можно предположить, что интерфейсом между шаговым двигателем и портом на плате контроллера является сам кабель (как говорит нам принципиальная схема). Но это будет ошибкой, как я писал выше - тут теряется сам физический модуль кабеля, который не так уж и примитивен - он имплементирует два интерфейса - со стороны двигателя и со стороны контроллера, состоит из следующих подмодулей: разъём для двигателя, провода 1...N, разъём для контроллера, между которыми будут реализованы механические контактные интерфейсы, которые также могут быть не столь просты, как кажется на первый взгляд.
А в случае с печатной платой всё ещё интереснее: "голая" печатная плата имплементирует N интерфейсов (посадочных мест) и в попыке описать модули для этих интерфейсов в EDA возникает вторая фигура умолчания: припой. Да, припой никак не упоминается в проекте печатной платы, однако для точного моделирования он необходим - в больших изделиях он может влиять на конечный вес, не говоря уже о том, что про него надо не забыть и включить в закупочные ведомости! Так вот каждый интерфейс на печатной плате (как модуле) сделан не для самих электронных компонентов, а для припоя - то есть интерфейсом тут является химическое соединение медной плёнки и оловянно-свинцового сплава (как также модуля) с одной стороны и соединение припоя и ножек компонента с другой.
#iso #iec #kicad
Задача с проектированием кабеля в KiCad заставила задуматься о том как в существующих инструментах разработки правильно описывать такого рода интерфейсы в проектах сложной много-составной электроники (роботах). Одной из мета-моделей для таких описаний служит системная инженерия и связанные с ней косвенно стандарты разработки. Например, ISO/IEC 81346, предписывающий правила обозначений для электротехнических систем с поправкой на множественность описаний для одних и тех-же физических объектов (multi-view). Для каждого компонента/системы стандарт выделяет, по меньшей мере, три вида описания: функциональное (как работает: функциональные блоки, порты, потоки), конструктивное (из чего собрано: бом-лист, модули и интерфейсы) и пространственное (где размещается: координаты и габариты мест размещения). Каждое из описаний представляет собой структуру типа дерево (breakdown structure), с декомпозицией по частям/целым. В новой версии стандарта 2022 года было добавлено разбиение по типу, в учебниках Анатолия Левенчука по системному мышлению добавляются также разбиения по стоимости и работам.
Для простоты мы пока остановимся на трёх базовых видах разбиений и попробуем отразить их на KiCad. Функциональным описанием является принципиальная схема, которая определяет количество, тип, номиналы компонентов и их соединения/порты. Однако, в чертёж принципиальной схемы добавляется также и информация о кодах производителей (manufacturer part number, MPN) и типах интерфейсов компонент (в случае с печатной платой это посадочные места - 0603, 1210, SOIC-8), что формально относится к конструктивному описанию (из чего собирается и как соединяется физически). Уже это делает затруднительным гибкое версионирование такого рода описаний - поставщики и их компоненты могут регулярно меняться из-за ситуации на рынке, что по идее должно приводить только к обновлению закупочных позиций, не затрагивая основной чертёж, но разработчики вынуждены вносить изменения в принципиальную схему без существенных на то оснований. В свою очередь, проект топологии печатной платы .kicad-pcb содержит в себе информацию как о количестве и типах посадочных мест, которые размещаются на плате, так и о размещении.
Так вот, возвращаясь к нашему кабелю, можно предположить, что интерфейсом между шаговым двигателем и портом на плате контроллера является сам кабель (как говорит нам принципиальная схема). Но это будет ошибкой, как я писал выше - тут теряется сам физический модуль кабеля, который не так уж и примитивен - он имплементирует два интерфейса - со стороны двигателя и со стороны контроллера, состоит из следующих подмодулей: разъём для двигателя, провода 1...N, разъём для контроллера, между которыми будут реализованы механические контактные интерфейсы, которые также могут быть не столь просты, как кажется на первый взгляд.
А в случае с печатной платой всё ещё интереснее: "голая" печатная плата имплементирует N интерфейсов (посадочных мест) и в попыке описать модули для этих интерфейсов в EDA возникает вторая фигура умолчания: припой. Да, припой никак не упоминается в проекте печатной платы, однако для точного моделирования он необходим - в больших изделиях он может влиять на конечный вес, не говоря уже о том, что про него надо не забыть и включить в закупочные ведомости! Так вот каждый интерфейс на печатной плате (как модуле) сделан не для самих электронных компонентов, а для припоя - то есть интерфейсом тут является химическое соединение медной плёнки и оловянно-свинцового сплава (как также модуля) с одной стороны и соединение припоя и ножек компонента с другой.
#iso #iec #kicad
👍6
В заключении про KiCad, системную инженерию и ISO/IEC 81346
Зачем так заморачиваться (спросит среднестатистический схемотехник)? Вроде бы вменяемых оснований для этого нет, но, если вы предпринимаете попытку полностью автоматизировать какие-либо технологические процессы, то неизбежно будете иметь дело с Парадоксом Поланьи. Этот парадокс заключается в том, что запрограммировать и автоматизировать задачу достаточно трудно, если нет полностью описанного процесса. На примере выше мы выяснили, что некоторые компоненты могут задаваться неявно, что усложняет точное моделирование с использованием системно-инженерной мета-модели. В данном случае EDA является заложником специализированности под определённую технологию производства многослойных печатных плат.
Но, не смотря ни на что, KiCad может представлять собой полигон для генерации системно-инженерных описаний по некоторым причинам:
- находится между доменами CAD и ПО, вынужден учитывать механические и программные интерфейсы;
- в нём представлены три ключевых разбиения, есть трассировка функций в конструктив с последующим переходом в 3D;
- начиная с версии 6 все исходники хранятся в текстовом формате в лиспо-подобном синтаксисе. Это делает удобным их прямую программную обработку.
Интеграция с PLM может быть реализована с помощью программных коннекторов, которые будут разбирать нативные форматы файлов KiCad-а и преобразовывать их в системно-инженерную модель во внешней БД, с которой также будут работать и другие специализированные САПРы. Да, это более сложный путь, который затрагивает вопросы семантической интероперабельности большого количества инструментов, но только он даст столь нужную гибкость в условиях непрерывно меняющихся технологических платформ, когда предстоит разрабатывать электрические устройства и топологии на каких-то иных физических принципах: например, с использованием печатных графитовых проводов, биохимических и оптических компонентов, новых аппаратных платформ для вычислителей.
Из альтернатив KiCad'у в подобного рода задачах один из подписчиков в комментариях привёл Open source ПО QElectroTech или QET, который позиционируется в качестве инструмента для разработки сложных промышленных электрических схем. Помимо принципиальных схема, в ней также можно проектировать сантехнику, геотермальные системы, кондиционирование, компоновку, гидравлику, пневматику, системы умного дома, ПИД-регуляторы, фотоэлектрические системы, схемы водоснабжения бассейнов и многое другое (скрины). Коллекция компонентов содержит более 8000 символов и в качестве системы обозначений применяется в том числе ISO 81346. Проект живой - несмотря на то, что основатели ушли в 2013, спустя 8 лет после начала, QET продолжает активно разрабатываться. Будем пробовать.
#kicad #qet #systems
Зачем так заморачиваться (спросит среднестатистический схемотехник)? Вроде бы вменяемых оснований для этого нет, но, если вы предпринимаете попытку полностью автоматизировать какие-либо технологические процессы, то неизбежно будете иметь дело с Парадоксом Поланьи. Этот парадокс заключается в том, что запрограммировать и автоматизировать задачу достаточно трудно, если нет полностью описанного процесса. На примере выше мы выяснили, что некоторые компоненты могут задаваться неявно, что усложняет точное моделирование с использованием системно-инженерной мета-модели. В данном случае EDA является заложником специализированности под определённую технологию производства многослойных печатных плат.
Но, не смотря ни на что, KiCad может представлять собой полигон для генерации системно-инженерных описаний по некоторым причинам:
- находится между доменами CAD и ПО, вынужден учитывать механические и программные интерфейсы;
- в нём представлены три ключевых разбиения, есть трассировка функций в конструктив с последующим переходом в 3D;
- начиная с версии 6 все исходники хранятся в текстовом формате в лиспо-подобном синтаксисе. Это делает удобным их прямую программную обработку.
Интеграция с PLM может быть реализована с помощью программных коннекторов, которые будут разбирать нативные форматы файлов KiCad-а и преобразовывать их в системно-инженерную модель во внешней БД, с которой также будут работать и другие специализированные САПРы. Да, это более сложный путь, который затрагивает вопросы семантической интероперабельности большого количества инструментов, но только он даст столь нужную гибкость в условиях непрерывно меняющихся технологических платформ, когда предстоит разрабатывать электрические устройства и топологии на каких-то иных физических принципах: например, с использованием печатных графитовых проводов, биохимических и оптических компонентов, новых аппаратных платформ для вычислителей.
Из альтернатив KiCad'у в подобного рода задачах один из подписчиков в комментариях привёл Open source ПО QElectroTech или QET, который позиционируется в качестве инструмента для разработки сложных промышленных электрических схем. Помимо принципиальных схема, в ней также можно проектировать сантехнику, геотермальные системы, кондиционирование, компоновку, гидравлику, пневматику, системы умного дома, ПИД-регуляторы, фотоэлектрические системы, схемы водоснабжения бассейнов и многое другое (скрины). Коллекция компонентов содержит более 8000 символов и в качестве системы обозначений применяется в том числе ISO 81346. Проект живой - несмотря на то, что основатели ушли в 2013, спустя 8 лет после начала, QET продолжает активно разрабатываться. Будем пробовать.
#kicad #qet #systems
👍12