Библиотеки компонентов PCB Editor, Как удобнее хранить символы уникальных фирменных компонентов? Опции

[Hoodwin]

Вот какая тема в фоне всплыла. В каждом изделии периодически встречаются детали, имеющие нестандартные корпуса. Это разнообразные индукторы, фирменные разъемы, субблоки питания, микросборки и т.п. На один проект их можно легко запихнуть в локальный подкаталог symbols проекта. Но потом, когда возникает их повторное использование в других проектах, приходится такие компоненты копировать в каталог с локальными символами нового проекта. Ну и начинает свербить мысль, что правильнее их все таки оприходовать в единую иерархию библиотек. И вот хочу спросить, как лучше это организовать?

В голову идут такие варианты:
1. Сделать некий единый каталог , куда класть символы с префиксом фирмы, например SUMIDA_CDRH74.dra, или TRACO_TEN40.dra. Плюсы в том, что в настройки путей в аллегро достаточно включить один этот каталог.
2. Сделать много каталогов по именам производителей. Путей будет много, но компоненты будут простые: .../SUMIDA/CDRH74.dra. Зато каталоги компактные а не одна большая помойка, но настроек путей много. И приходится повторять эти пути на всех машинах, куда разворачивается архив с библиотеками.

Может еще варианты есть? И есть ли у кого опыт, что реально удобнее?

[vitan]

У меня символы хранятся по папочкам с префиксами имен согласно IPC7351. Эти папочки потом связываются с общей центральной библиотекой (там лежат УГО, параметры и т.п.), но это уже другая тема.
Так вот, раньше я работал непосредственно с этой библиотекой (подключал все пути один раз). Теперь я предпочитаю иметь полностью локальную библиотеку для символов проекта. Она находится в отдельной папочке, без дальнейшего деления на подпапки. Там лежат все символы. Так аллегро быстрее их ищет.
Т.е. в центральной библиотеке у меня путь lib/allegro/ind/SUMIDA_CDRH74.dra, а локально символ лежит в /project/symbols.
Первоначально копировал всю структуру каталогов в локальную папку проекта и перестраивал пути поиска (автоматом, ессно), но понял, что лучше для быстроты просто свалить все в кучу (тоже автоматизированно).

В общем, иерархия символов у меня сделана по классам из IPC, потом на основе этого можно легко сделать деление их на аллегровские классы (IC, DISCRETE...).
Но мне тоже интересно, какие у кого есть варианты еще?

ЗЫ. По производителям делить считаю неправильным, ибо производитель может выпускать сильно разные детальки, которые в одну папочку пихать не надо.

[Hoodwin]

Не совсем понял, зачем копировать "структуру каталогов в локальную папку проекта"? Символы же и так копируются в brd файл. Можно выгрузить какой-то один, подправить и заменить, но плодить копии библиотечных символов на диске - это, по-моему, неправильно.

Еще вопрос: что такое префиксы имен IPC и какая именно от них польза? Мне вот не очень пока нравится идея раскладывать все компоненты по тысяче папочек и править конфиги.

[Uree]

У меня организована в общем-то минимальная структура:
physical - корпуса микросхем, без деления на подвиды, все подряд - BGA, QFN, SOIC, SOP, SOT, D2PAK...
physical/connectors - понятно, коннекторы, все
physical/discrete - все корпуса, имеющие от 2х до 4х выводов - резисторы. конденсаторы, дроссели/биды/комон-чоки, диоды-транзисторы
physical/misc - все, что не укладывается в предыдущие категории - трансформаторы, кварцы, LCD-экраны, тестпойнты, монтажные отверстия, ВЧ полосовые фильтры, диплексеры-триплексеры, кнопки, холдеры, термопрокладки, док. символы(лого, quality label, ROHS etc.), что-то еще, уже не помню что...
physical/shield - экраны
physical/padstack - падстэки
physical/shape - шейпы для падстэков.

Более подробное деление по обсуждению признали бесмысленным.
Названия футпринтов сделаны на основе рекомендаций IPC, поэтому такой структуры уже хватает, чтобы быстро отыскать любой нужный компонент. Да и никаких тормозов при плэйсменте/апдейте в РСВ эдиторе не заметно.

[vitan]

Не совсем понял, зачем копировать "структуру каталогов в локальную папку проекта"? Символы же и так копируются в brd файл. Можно выгрузить какой-то один, подправить и заменить, но плодить копии библиотечных символов на диске - это, по-моему, неправильно.

Это раньше я копировал файлы и структуру. Теперь копирую только файлы.
Символы копируются в brd тогда, когда они на нее выставлены. А чтобы их выставить нужно указать пути. Поэтому я и копирую вначале символы из ЦБ. Если нужно немного поправить какой-то символ, то я это делаю тут же, в локальном каталоге, а не в ЦБ. При этом не возникает задержки, связанной с проверками перед тем, как положить в ЦБ. По завершении проекта для повторного использования символы, в т.ч. поправленные, отправляются обычным путем в ЦБ, проверяются, фиксируются, выкладываются и т.п.

Еще вопрос: что такое префиксы имен IPC и какая именно от них польза? Мне вот не очень пока нравится идея раскладывать все компоненты по тысяче папочек и править конфиги.

Ну там, RES, CAP, SOIC... Их там много. Конфиг править не приходится, его один раз надо просто создать.

В общем, у меня примерно то же, что у Uree, но в локальном виде, в ЦБ иерархия детализирована. При этом ЦБ непосредственно для работы не используется, а служит неким исходным источником.

[Uree]

Vitan, я так понимаю Ваша ЦБ - это менторовская библиотека для работы с DxD. Правильно? Если да, то почему Вы вообще так работаете - схема в менторе, библиотека, включая футпринты, там же, а платы в Аллегро, да еще и в древней версии? Куча дополнительных-ненужных телодвижений на мой взгляд... Это даже не вспоминая о Вашей БД

ЗЫ Hoodwin, решил посмотреть на Ваш пример с Sumida. Так в нем же ничего уникального нет Дроссели в таком корпусе, с такими размерами выпускает куча фирм. Равно как и другие типоразмеры. На самом деле действительно уникальными являются корпуса например DC-DC преобразователей, или тех же Э/М экранов, которые разрабатываются под проект. А все остальное можно почти не сомневаться, найдется у нескольких производителей. Да, названия будут разными, но корпус - такой же. Потому и удобно пользоваться уникальными префиксами для футпринтов. Указал префикс IND, перечислил его размеры и можно не обращать внимания от какого производителя этот футпринт оказался в библиотеках. Потом, добавляя новый компонент, достаточно пробежаться глазами по списку уже имеющихся корпусов(файлов в соответствующем каталоге), чтобы определить есть ли футпринт подходящих размеров. И либо вписать его название в описание нового компонента, либо взять ближайший по габаритам и отредактировать, записав с новым именем и новыми размерами в этом имени.

[Hoodwin]

Uree

По поводу уникальности. Ну, это смотря как считать. Я в этом отношении эстет. Раз уж начали обсуждать про SUMIDA CDRH74, то я и продолжу на этом примере. Вот смотрите, у каждого дросселя есть три размера. Потом, при равных габаритах у них может быть разная форма, а я всегда воспроизвожу форму в сборочных слоях 1:1 по номинальным размерам. Кроме того (и что более важно), у SMD индукторов от разных производителей могут быть разные формы выводов. У CDRH74, например, узкие выводы, а у других могут быть во всю ширину квадратика. Универсальный футпринт с широкими КП - плохо, потому что при автоматическом монтаже компонент может начать плавать и крутиться на припое, задевая соседей. Правильные КП не дают ему такой возможности. Плюс к этому, как я заметил, существует некоторое оптимальное соотношение общей площади КП и площади самого вывода компонента. Весь припой, который компонент выдавливает из под вывода, идет на образование миниска вокруг него. если контакт слишком мал по сравнению с КП, то просто не хватит олова на миниск, оно растечется по КП. С учетом специализации формы КП и формы компонента возникает и форма линий маркировки в слое шелкографии.

В итоге, мне проще назвать компонент SUMIDA_CDRH74, чем давать ему длинное имя по выдуманной классификации, в которой он будет единственным своего рода представителем. Если придется переходить на индукторы другой фирмы, то так и впишем в их названии - EPCOS_xxxx, или BOURNS_xxxx, или MURATA_LQHxxx, например. И подредактируем параметры, сохранив как отдельный символ.

Потом, все же есть еще и такой момент. SUMIDA не заявляла, что корпус соответствует какому-то там стандарту, JEDEC и т.п. То есть, унификация с корпусами компонентов иных фирм - это, получается, произвол. С какой стати у других производителей ровно то же самое?

[vitan]

Vitan, я так понимаю Ваша ЦБ - это менторовская библиотека для работы с DxD. Правильно? Если да, то почему Вы вообще так работаете - схема в менторе, библиотека, включая футпринты, там же, а платы в Аллегро, да еще и в древней версии? Куча дополнительных-ненужных телодвижений на мой взгляд... Это даже не вспоминая о Вашей БД

ЦБ - это все вместе. По отношению к данному топику это хранилище символов, поэтому, думаю, я имею право участвовать.
О каких лишних движениях Вы говорите? О том, что я символы копирую в папку с проектом перед началом работы?
Кстати, они у меня не для ментора, а для аллегро.

Uree
В итоге, мне проще назвать компонент SUMIDA_CDRH74, чем давать ему длинное имя по выдуманной классификации, в которой он будет единственным своего рода представителем. Если придется переходить на индукторы другой фирмы, то так и впишем в их названии - EPCOS_xxxx, или BOURNS_xxxx, или MURATA_LQHxxx, например. И подредактируем параметры, сохранив как отдельный символ.

Ну эдак можно и до резисторов с конденсаторами опуститься, у 0603 разных производителей тоже могут отличаться пады.
Зависимостями пайки от размеров выводов как раз и занимались в IPC, наработали опыт, выпустили стандарт. Ну так и воспользуемся же им!
Префиксы по имени производителя тоже предусмотрены в стандарте, но это, очевидно, сделано в тех случаях, где накопленного опыта не хватило для стандартизации, либо стандартизация сильно затруднена (вот, например, VREG - регуляторы напряжения. Их может быть столько вариантов, что нет смысла что-то стандартизировать).

[Hoodwin]

Ну эдак можно и до резисторов с конденсаторами опуститься, у 0603 разных производителей тоже могут отличаться пады.

Ну в маразм то не надо впадать! Если производитель пишет, что его компонент формата 0603, значит так тому и быть - пускай символ будет стандартный. А если не пишет ничего, то с какой стати его комбинировать с другими компонентами, про которые их производитель ничего не пишет? Главное, вот делать мне потом нечего, как сидеть и думать, подходит ли символ IND_<длина><ширина><высота><форма><размеры КП>... под конкретный дроссель CDRH74...

Зависимостями пайки от размеров выводов как раз и занимались в IPC, наработали опыт, выпустили стандарт. Ну так и воспользуемся же им!

Ну не томите уже, распишите, как по стандарту должен называться символ футпринта для CDRH74, а я подивлюсь.

[Uree]

Ладно, не думайте, подходит или нет. Никто вроде бы не заставляет. Рисуйте сразу каждому компоненту свой корпус. Хотя подумать - оно для мозгов полезно... разминает, так сказать
Суперподробной информации о корпусах мы в названии не пишем. Найти по нему хватит инфы, а дальше и открыть, посмотреть, проверить "подходящесть" нетрудно. Не подходит - редактирование и запись с новым именем, возможно таким же, как уже имеющееся плюс индекс, если основные размеры совпадают. Но как раз таких случаев не помню. Это только в падстэках стандартная ситуация. Там изрядная часть совпадает именами но с разными индексами.
Я написал как мы делаем. Если Вы считаете, что ваша собственная методика лучше, то вряд ли мы изменим это мнение.
А IPC почитайте, вдруг что интересное придумаете.
 IPC_7351___PCBL_Land_Pattern_Naming_Convention.pdf ( 76.08 килобайт ) Кол-во скачиваний: 1054

[Hoodwin]

Ага, спасибо! Вот глядим в стандарт и видим:

Inductors, Miscellaneous ................................................................................
...............................................IND_Mfr.’s Part Number

Ну то есть, конкретно в случае CDRH74 символ должен называться IND_SUMIDA_CDRH74, как я понял.

[vitan]

А если не пишет ничего, то с какой стати его комбинировать с другими компонентами, про которые их производитель ничего не пишет?

Чтобы случайно не понаделать кучу одинаковых футпринтов под разными именами.

Ну то есть, конкретно в случае CDRH74 символ должен называться IND_SUMIDA_CDRH74, как я понял.

Нет, IND_CDRH74.
Однозначно, есть еще буквы после 74, например, номинал. Полный партнамбер, в общем.

[Uree]

А я сразу писал - "...Названия футпринтов сделаны на основе рекомендаций IPC". Это все-таки не ГОСТ, чтобы ему тупо следовать. Никто не мешает развить его в меру своего разумения. Вот мы и развили, так, как считаем удобным. И знаете, почти два года использования - и никаких проблем с этой системой. А размер библиотеки уже около 300МБ, и это только футпринтов. Так что работает такая система, даже не сомневайтесь.

[Hoodwin]

То есть, в сухом остатке имеем следующее:
1. Иерархия каталогов никак не привязана к полной классификации компонентов РЭА. Количество каталогов с библиотечными ограничено, продумано, и после этого новые каталоги не добавляются. Грубо говоря, можно было бы вообще иметь два каталога: первый для символов, названных в соответствии с IPC, второй - для legacy имен.
2. Наименования символов сделаны с учетом рекомендаций IPC, чтобы при поиске можно было классифицировать компонент и потом его с таким именем искать в общей "свалке" внутри одного из каталогов.
3. Очень специфические уникальные для изделия символы помещаем в локальный каталог проекта.

Так?

Вопрос такой. Правильно ли я понимаю, что с точки зрения allegro нет никакой разницы, сколько каталогов используется для хранения символов? Он для каждого проекта ищет сразу по всем? То есть смысл разбиения множества на несколько путей может быть только в том, чтобы оставалась возможность отключить некоторые каталоги, оставив остальные, или, наоборот, подключить "чужую" иерархию, не заливая ее в свою. Так?

[Uree]

1. Иерархия каталогов никак не привязана к полной классификации компонентов РЭА. Количество каталогов с библиотечными ограничено, продумано, и после этого новые каталоги не добавляются. Грубо говоря, можно было бы вообще иметь два каталога: первый для символов, названных в соответствии с IPC, второй - для legacy имен.

Сначала верно. А вот с двумя каталогами Вы однозначно погорячились... Разве что кол-во футпринтов будет пара-тройка сотен.

2. Наименования символов сделаны с учетом рекомендаций IPC, чтобы при поиске можно было классифицировать компонент и потом его с таким именем искать в общей "свалке" внутри одного из каталогов.

Нет при таком подходе какой-то большой свалки. Так, немножко только навалено...

3. Очень специфические уникальные для изделия символы помещаем в локальный каталог проекта.

Возможно у кого-то так. У нас никаких локальных библиотек проектов нет в принципе. Библиотека одна на всех(по своему составу). Локальны только ее копии у каждого пользователя на компе для ускорения работы со схемой/платой, потому как на сервере медленновато всё это ходит. Но это именно копии, 1:1.

Вопрос такой. Правильно ли я понимаю, что с точки зрения allegro нет никакой разницы, сколько каталогов используется для хранения символов? Он для каждого проекта ищет сразу по всем? То есть смысл разбиения множества на несколько путей может быть только в том, чтобы оставалась возможность отключить некоторые каталоги, оставив остальные, или, наоборот, подключить "чужую" иерархию, не заливая ее в свою. Так?

Кол-во каталогово - неважно, ищет по всем установленным. Только от проекта это не зависит. Установки путей глобальны для РСВ редактора, они не прописываются в файле проекта или в его окружении. Поэтому разбиение на каталоги делается только для удобства управления этими библиотеками. Ничего более.
Хотите управлять путями(быстро) - делайте настройки и сохраняйте копии env-файла с этими путями. Хотите быстро переключить - закрыли РСВ, подменили env, открыли РСВ.

[vitan]

То есть, в сухом остатке имеем следующее:
1. Иерархия каталогов никак не привязана к полной классификации компонентов РЭА. Количество каталогов с библиотечными ограничено, продумано, и после этого новые каталоги не добавляются. Грубо говоря, можно было бы вообще иметь два каталога: первый для символов, названных в соответствии с IPC, второй - для legacy имен.

Если говорить только о символах, то не привязана. Другое дело, если есть база компонентов (а не символов), вот тогда будет связь с каталогами компонентов в отношении многие-ко-многим. Количество не то чтобы ограничено, просто редко меняется (уже почти все типы применялись ранее). Каталог можно иметь вообще один.

2. Наименования символов сделаны с учетом рекомендаций IPC, чтобы при поиске можно было классифицировать компонент и потом его с таким именем искать в общей "свалке" внутри одного из каталогов.

Это одна из целей, да.

3. Очень специфические уникальные для изделия символы помещаем в локальный каталог проекта.

В ЦБ тоже неплохо бы помещать. А то потеряется.

То есть смысл разбиения множества на несколько путей может быть только в том, чтобы оставалась возможность отключить некоторые каталоги, оставив остальные, или, наоборот, подключить "чужую" иерархию, не заливая ее в свою. Так?

Смысл может быть не только в этом. Когда однотипные вещи сгруппированы в одной папке, их проще обрабатывать автоматически.