Цитата
(у резисторов, например, каждый номинал каждого типоразмера, каждой точности, каждой мощности имеет отдельный библиотечный элемент), кажется слишком неудобным.
Вы совершенно правы, мне так тоже неудобно. Поэтому мне и удобнее, когда есть одно УГО - резистор, а остальное берётся из заданых в базе данных ТКС, допуск, типоразмер, номинал, статус компонента и т.д. УГО и посадочное место - это тоже поля в базе дынных. Поиск потом тоже ведётся по базе данных по тем же параметрам. Добавить параметр в базу данных - тоже довольно просто. При этом, у меня не вызвало затруднений настрочить perl'овый скрипт, который добавит параметр в библиотеку УГО KiKad'а. Но то, что в базе данных получается само собой - структурированность по типу, и т.п. в KiCad надо продумывать заранее и включать в компонент. Можно даже использовать для этого существующую базу данных, но для этого надо уметь с ними работать уже не на уровне пользователя (с чем, повторюсь, у меня справлялся монтажник). Но при этом возникает проблема с тем, что данные начинают хранится во множестве мест, и их нужно как-то консолидировать.
Это что касается связи с базой данных.
Теперь зачем она:
1. Чтобы разработчик брал компоненты только из базы данных. Чтобы он не мог создать и поместить в схему непроверенный элемент. А-то мне уже попадались в копеечных схемах 100pf СВЧ конденсаторы по $2 в партиях и шестимесячным сроком поставки. Тут к KiCad'у претензий нет, кроме необходимости двойной работы (хоть её можно и автоматизировать) - подобное можно сотворить в любом CAD'e просто вручную переписав номинал/part number в схеме.
Суть в том, чтобы сделать так, что разработчику пойти по правильному пути - сделать запрос человеку, работающему с библиотекой, было
удобнее, чем быстренько наваять компонент, поменяв у него параметры на нужные сейчас, тем самым решив сиюминутную задачу и наплодив проблем и лишней работы в будущем. Это можно сделать легко теми же скриптами.
2. Из этой же базы данных берутся сведения для базы данных изделий, что сильно облегчает жизнь при поддержке производства, внесении изменений. Собственно, здесь основная проблема в том, что KiCad плодит локальные библиотеки в директории проекта. (gcc же не создаёт локальные копии библиотек в директории проекта, и как-то работает). То есть, опять нарушается принцип единого источника данных, который в этот раз уже так легко не решается.
В общем-то это всё на сегодня совершенно чуждые KiCad'у парадигмы (и он от этого не плохой, я его не ругаю, как тут некоторые думают). И он в этом, конечно, не одинок. Без этого, разумеется, можно работать (но по-другому), это, естественно, можно обойти, починить (но с этим уже не справится монтажник).
Если я не прав - поправьте. Буду только рад, если на свет выплывут мои заблуждения.
Цитата
Под Linux собирается надёжно.
Спорно: именно под Linux и не собралось. И причиной - именно плохая документированность этого процесса. Я знаю, что если бы мне это было нужно, я бы собрал, как это сделали тысячи других людей. Но это требует большей вовлечённости в процесс, чем должно. Об этом, кстати, пишу не только я, но и немало пользователей из-за рубежа, которые тоже, как я решили попробовать KiCad.
Цитата
И в вашей ситуации наверное больше подошёл бы Mentor Xpedition
Для домашнего пользования (первая причина, по которой я обратил внимание на KiCad) он у меня не окупится в обозримом будущем. Да и если мне придётся разворачивать процесс разработки на новом месте (вторая причина, по которой я решил посмотреть KiCad), то Xpedition там с большой долей вероятности будет overkill. Хотя с этим инструментом я знаком.
Цитата
Повторяю вопрос иначе: Какой смысл в пустой библиотеке?
Такой же, какой и в пустой схеме, и в пустом проекте. Но пустые схему и/или проект я создать могу. Но это вкусовщина.
А вот невозможность открыть тул по созданию библиотек - вот это уже не вкусовщина, а явная дурость (которая, правда, имеет свой костыль для обхода - это первое, чему я научился в KiCad).
