Возник вопрос о грамотном создании библиотек, с последующим удобством пользования.
1. Разбиваем элементы на группы и создаём для каждой группы свою библиотеку.
Неудобство в том, что одинаковые посадочные площадки приходится расталкивать по разным библиотекам.
2. Делаем все элементы в одной библиотеке.
Неудобно! Куча компонентов, как в ней не сломать шею....?

1. Не надо пользоваться интегрированными (*.intlib) библиотеками. Делаете общую (или общие) библиотеку (-и) футпринтов и отдельные библиотеки компонентов.

Первый вариант полюбому! Ибо черт ногу сломит действительно во втором варианте.
Мало того, у меня каждая библиотека интегрированная. Т.е. библиотека футпринтов для каждой бибиотеки, а не одна для всех. Но
это ИМХО. В этом варианте свои преимущества.

у меня библиотеки формируются так:
в каждой папочке библиотека посадочных мест и уго)

у меня не первый и не второй вариант
1. по группам библиотеки только для схем
2. по группам библиотеки посадочных мест
3. База в Access по типам элементов со ссылками на компоненты из библиотеки для схем и футпринты библиотек посадочных мест + парметры типа оминалов, продавцов и т.п.

Огласите список преимуществ, пожалуйста.
Всегда считал, что интегрированная либа - гемор.
И просто влюбился в раздельные либы (футпринты в своих файлах, схематики в своих, компоненты с ссылками на футпринт и схематик в своих).

Например BGA от какой-нибудь производителя взять. Во-первых в стандартных библиотеках такого может не быть, даже если есть там, то наверняка есть рекомендации самого производителя микросхем, ими и пользуюсь. Поэтому получается этот футпринт имеет отношение только к одному УГО. Зачем его в общую библиотеку пихать и приписывать где-нибудь в описании, что этот футпринт для такой-то микросхемы, чтобы не забыть что это вообще такое.
Короче, процент повторно исользуемых футпринтов мал у меня. Поэтому смысла нету особого не вижу.
Т.е. преимущество в том, что нет необходимости группировать и правильно называть футпринты, на это силы и время уйдет. Проще сделать копипаст, потом проверить и возмножно подредактировать в соответствии с рекомендациями или, например, длиной ножек у данного SOT-23 для конкретной микросхемы. А так многе уже сгруппировано как нужно: для чипов - там футпринты в своей библиотеке и больше нигде не исользьуются. Для разъемов тоже самое. Светодиоды все разные, смысла тоже нету.



Не понял. футпринты в pcblib, схематики в schlib, а "компоненты с ссылками на футпринт и схематик" - это ведь и есть intlib?

У меня также как у xlive сделано на картинке. Внутри папки - проект библиотеки, библиотека УГО, библиотека футпринтов для данной группы, и интегрированная библиотека для этой группы.

..................
Вообще я не знаю зачем интегрированная библиотека нужна. Ведь в schlib уже есть ссылка на футпринт и если библиотека футпринтов на своем месте, то она intlib не нужен. Из schlib нормально вставляются компоненты на схему :

Нет *.DbLib со сылкой на файл Access

Для меня нет понятия "стандартная библиотека".
А вот например корпус какой-нить (пусть и БГА) каждый производитель так и норовит применить к целому семейству микросхем. И когда заказчеги просят поставить следующий в семестве камень, не приходится увеличивать количество футпринтов.
Ну а про стандартные Soic8/16/20 Dip8/14 Sot23-3/5/6 и т.д. и т.п. я вообще молчу.

Ясно. Именно это - куча одинаковых футпринтов с разными именами, я считаю недостатком.
Сопровождать трудно, исправления вносить - вообще повесишься...

Это не в Альтиуме.
И у меня и компоненты разделены по семействам в разные файлы, и футпринты по типам, и символы ГОСТовые по семействам. Всё в своих файлах.

Вот это кажется самый оптимальный вариант. Вот только где бы достать примеры создания библиотеки такого типа.
Родной мануал - это долго. Хотелось-бы пример создания нескольких компонент, чтобы общий смысл уловить, а вот за подробностями и в мануал не грех слазить.

Почитайте у Прановича. У него чтото похожее описано. По крайней мере общий подход и принципы.

Оно самое. Годовой давности. Водички конечно уже немножко утекло, мелочи какието смылись, но принцип остался

Почитал... Не понял идеологию такой библиотеки и приемущества.
Как в такой библиотеке происходит связь номеров контакных площадок с пинами УГО?
Почему такая библиотека не является проектом? Её что правильно пристраивать к рабочему проеку?

Попробую рассуждать.
Я создаю библиотеки УГО по группам. Это удобно при поиске нужного типа УГО.
Я создаю библиотеки посадочных площадок по группам. Это удобно при поиске нждного типа ПП.
Я создаю файл базы данных в котором создаю таблицы по группам (резисторы, конденсаторы, операционники...),
в каждой таблице я прописываю необходимые параметры, и после импорта, получаю рабочую библиотеку.
Всё вроде-бы красиво, за исключением правильности соответствия выводов на УГО и ПП.
Что с этим делать и вообще я правильно изложил принцип?

Соответствие прямое. Как в УГО так и в ПП. В AD всё проще чем в PCade.

Все так

делайте названия Pin УГО и PAD ПП одинаковыми и проблемы отпадут

Поумолчанию совпадающие имена Pin и pad подключаются друг к другу.

Если они не совпадают, а хочется. Или наоборот совпадают, а не хочется

в SCHLib или SCHDOC для конкретной подключенной модели ( при двойном клике) и ли в момент подключения новой модели Footprint есть кнопка Pin MAP/ Там можно изменить наpначение PIN и PAD




Ой черт тяжело без пистолета.
Выписывайте книгу Алексея Сабунина. там должны быть в кратце описано это, и многое другое.
я уж кажется по 10 кругу это пишу.

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

Ну так я ведь писал. При использовании базы используйте библиотеки где у элементов названия PIN и Pad совпадают.
В чем проблема та.
Выеденного яйца не стоит

Пусть будет так!