Привет Всем! У меня есть одно УГО двухконтактного коннектора и несколько топологических посадочных мест разных коннекторов которые являются двухконтактными.)))
Как правильнее сделать библиотеку коннекторов:
1. Оставить одно УГО и с ним связать несколько посадочных мест? (рис.1)
2. Для каждого посадочного места создать свой файл *.schLib в котором разместить одно и тоже УГО?

Достоинство первого способа - это не придется создавать копии одних и тех же условно графических изображений. А недостаток певого способа - как на схеме отобразить наименование выбранного посадочного места?
Или всё таки правильнее работать вторым способом? Подскажите пожалуйста....

1/ Не достаток первого-- каждый раз ломать голову, а тот ли Footprint на PCB, или ни правильно выбрал из имеющихся
2. Недостаток второго- раздутые библиотеки
Переходите на библиотеки в виде баз-- отсутствует недостаток первого и второго

Лично мне больше нравится выриант, когда каждому конкретному элементу соответствует определЁнное УГО с набором посадочных мест для данного элемента. Результат: из библиотеки на схему (Э3) Вы ставите тот элемент, который Вам нужен, а затем уже по плате корректируете ему посадочное место - выбором.
Например, резистор С1-4-0,125:
1. одно УГО по ГОСТ только для данного резистора (для некоторых элементов УГО может быть и не одно, например оптопара или транзистор; плюс я ещЁ для каждого элемента стараюсь и параметры ввести (предельные температуры, пределы сопротивления, ТКС и т.д.)).
2. 9 (девять, это не опечатка) посадочных мест; по 3 штуки: на горизонтальное расположение, на вериткальное с ориентацией налево и направо.

Скажите, как бы вы поступили с моем случае, т.е с коннекторами?

Ну так я и советую на Библиотеку в виде базы переходить.
В библиотеке УГО 1 изображение для всех соединителей скажем на 20 контактов
В библиотек посадочных мест-- столько посадочных мест, сколько вы используете
конкретный элемент находится в базе и содержит
1. Только ссылку на УГО из первой библиотеки
2.Только на конкретное посадочное место из второй библиотеки
3. куча текстовых параметров для авто заполнения перечня и т.п. (включая номер по производителю и имя самого производителя, сведения о поставщике, наличия на складе ......) , которые присущи конкретному типу соединителя.
Вот в базе и размножайтесь. Там хранится только текстовая информация и раздутия библиотек не происходит

Вы имеете в виду Database Library?

В частности

+1

-1.
Когда то я тоже был на той позиции -- жизнь отучила

+1
В Альтиуме библиотеки в виде баз - хороший вариант. К хорошему быстро привыкаешь.

Особенно если склад автоматизированный...

"Вопрос номера":
В Альтиуме можно к одному УГО привязать несколько футпринтов, например, atmega8 может быть TQFP, а может быть DIP. Соответственно, номера пинов в обоих случаях разные.
Как сейчас делаю я: в пинах УГО поля DisplayName и Designator заполняю одинаково, например, ADC6, а уже в настройках футпринтов, в таблице Pin Map прописываю, что для DIP ADC6=17, а для TQFP=32 (к примеру). Все ок, работает хорошо, только одно НО: В схемах не видно реальные номера пинов, очень неудобно потом при наладке и ремонте устройств. Может быть можно сделать так, чтобы поле DisplayName каждого пина автоматически заполнялось из PinMap?

Можно, но не нужно этим злоупотреблять.
Формально можно подключать только один тип для разных условий монтажа.
для DIP и TQFP следует использовать собственные УГО

Не согласен с Вами: если один УГО для одного футпринта, зачем тогда вообще нужна таблица Pin Map?
Скажем, XC9536 выпускается в PLCC44 и TQFP44. По-факту они pin-to-pin совместимые, но нумерация пинов отличается, т.к. у TQFP первый пин в углу, а у PLCC по-середине. Рисовать из-за этого 2 разных компонента ИМХО как-то неправильно.

На схеме и на на PCB Все должно соответствовать PDF на компонент. Иначе это ввод в заблуждение тех, кто будет разбирать Ваши схемы, обслуживать и ремонтировать изделии
Значит на схеме должны быть имена (номера) PIN, соответствующие обозначению PAD.
то есть даже в Вашем случае нужно делать альтернативное изображение. это по трудоемкости тоже что создание нового УГО


Это отдельная тема для разговора

Глянул библиотеки от альтиума, там отдельные компоненты даже для разных спидгрейдов
Все-таки, было бы здорово, если бы номер пина на УГО автоматически брался из Pin Map

Поддерживаю. Единственное, что имена выводов на схеме и имена выводов посадочного места могут иметь, во-первых, текстовое обозначение, во-вторых, они могут не совпадать одно с другим. Как в такой ситуации правильно поступать?

это не проблема. именуйте как хочется. Единственно не работает инкремент при создании компонента
плиз, приведите PDF хоть одного компонента, где они не совпадают

Ситуация только одна: когда в посадочном месте есть PAD, которые крепежные или не используются (обычно соединители), а в УГО не хочется или наоборот нужно их отобразить.

Но и в этом случае никто не мешает их назвать одинаково.

Я один раз столкнулся в составном соединителе, где разные части имели нумерацию с 1.
Но и там просто добавляется номер секции соединителя

Виноват, не учёл, что речь идёт именно о PDF. Я в том сообщении подразумевал, что во многих (ну или некоторых) библиотечных компонентах (выполненных не в чётком соответствии с PDF) наблюдается несоответствие имени вывода УГО и посадочного места.
Именно на этот случай и требуется Pin Map. Иначе, получается, она не нужна?

Так текстовое название вывода (Pin Name) Может быть любым. А вот Designator должен четко соответствовать посадочному месту .

Вот тогда получается, что Designator в УГО не нужен. А в Pin Map будет сопоставление Pin Name (точнее оно называется Display Name) на УГО и Designator в футпринте.

Designator в УГО нужен, чтобы при чтении схемы быстро поставить в соответствие вывод у микросхемы на схеме с выводом на корпусе.

Говорилось, что десигнатор с футпринта напрямую определяет номер вывода на схеме (это типа мечта такая).
А соответствие устанавливается между десигнатором у футпринта и именем вывода у УГО.

Поскажите плз как в базе данных библиотек прописать правильно путь в Library Path и Footprint Path? Немного поясню, я создал базу данных компонентов из уже существующих и установленных библиотек с расширением *.IntLib, в итоге получил файл с DBLib.MDB. В этом файле Library Path и Footprint Path содержат строчки Libraries\Оптопары.SCHLIB и Libraries\Оптопары.PcbLib. Решил просто поэкспериментировать с созданием компонента в базе данных, создал в Оптопары.PcbLib футпринт TSOP65P640X110_HS-20N. Ну и скопировав в базе строчку рабочего компонента, решил просто поменять футпринт, вписав TSOP65P640X110_HS-20N в нужные места. К сожалению, результат меня не обрадовал. Новый компонент появился доступным для установки в проекте, но нужный футпринт у него я так и не увидел. Долго думал, ломал голову, пока не догадался в Library Path и Footprint Path указать полный путь к нужному файлу (D:\Work\...\Оптопары.PcbLib). Вот после этого у компонента появился нужный футпринт. Отсюда вопрос, как нужно вписать правильно путь, чтоб не только я мог использовать данную базу? И второй вопрос, чтоб изменения произведенные в базе вступили в силу, необходимо после сохранения самой базы, отключить DBLIB.DBLib от проекта, и проинсталлировать заново. Так и должно быть?

Сделайте файлы SchLib и PcbLib доступными по сети и укажите сетевой, а не локальный путь к ним.

Для этого существует кнопочка Reconnect, которую вы можете увидеть открыв сам файл DbLib из списка файлов проекта. Учтите, что в исходном состоянии кнопка называется Connect. Если подключение к базе данных установлено, то кнопка деактивируется и подписывается при этом Connected. Она снова становится активной, если произошли какие-то изменения в БД или в настройках.

Тут у нас немного другая система. Работаем через контроль версий. У каждого рабочего места есть своя локальная копия файла, при чем путь к нему у каждого свой. Поэтому хотелось бы конечно сохранить идеологию, и как то предусмотреть возможность указания относительного пути к файлу (как например в IARе пишется путь к файлам проекта $PROJ_DIR$\..\..\Source\Projects\BDIO\Modules\CAN\)


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

Возможно вам нужна SVNLib. Посмотрите ссылку в этой ветке форума.

Кстати проверил только что. После внесения изменений Reconnect так и не повился, пытался править и в самом Альтиуме, и напрямую через Аксесс.


думал будет немного проще

Решил проблему Оказалось все достаточно просто, надо было всего лишь прописать в Library Path и Footprint Path Оптопары.SCHLIB и Оптопары.PcbLib, без указания Libraries\. И все сразу запахало

Измените Source of Connection и снова вернитесь к исходным настройкам (достаточно пару раз щелкнуть по Radio-Button).

Так, для справки: файл базы данных и DBLib где находятся относительно папки Libraries ?

Вот именно я сам не понял на какой стадии Libraries\ вообще появляется, так как папки такого и в помине нет. Файл базы данных и DBLib находятся в d:\Work\AltiumLib\DB Library\.

Зато появилась новая проблема На этапе когда начал править базу данных, и удалять приставку Libraries\ со всех путей столкнулся с проблемой, когда Аксесс говорит что "Слишком большая длина записи", аналогично и когда пытаюсь править через альтиум. А возникло это на строчке с резисторами, в котором одному УГО соответствует аж 45 различных посадочных мест. Ткаим образом получается, что база данных резисторов создалась благополучно, а редактировать ее нет возможности, уткнулись в ограничения самой базы данных? хотя я считаю данное предположение смешным. Видимо что то делаю не так. Я бы грешил конечно бы на Альтиум, если бы не проводил все изменения в Аксессе. Может кто сталкивался с этим, а то не охота как разделять библиотеку резисторов на группы из нескольких контактных площадок.

Сам же и отвечаю: относительные пути прописываются от местоположения файла DBLib
А вообще, в файле содержится параметр "LibrarySearchPath=", вот только получить доступ к нему из самого AD у меня не получилось.
Да и с назначением пока не разобрался...

Цитата отсюда:

В переводе:

А добраться до них просто. Открываем в Altium файл .DbLib, вызываем меню Tools -> Options, и на вкладке Symbol & Model Search Paths можно править эти самые пути. Если вы при подключении .xls или .mdb установили галочку Store Path Relative to DbLib, то и пути к папкам тоже будут добавляться относительные.

В ближайшее время постараюсь написатькак создавались библиотеки для проекта Altium Common Library и с какими трудностями пришлось столкнуться.

+1, вот оно оказывается где было. А я все никак понять не мог, ну откуда же он пути эти знает. Теперь все встало на свои места. Остался только одни вопрос, как быть с теми элементами которые имеют большое кол-во посадочных мест как в случае с моими резисторами, где одному УГО соответствуют 46 различных футпринтов. Ну не дает редактировать строчку базы ни Альтиум ни Аксесс, где содержится такое большое ко-во параметров, все время выдает ошибку "Слишком большая длина записи".

Для этого стоит вам нужно создать в таблице (Access, Excel) колонки с названиями Footprint Ref n, где n - порядковый номер 2 - 255.

На самом деле настоятельно рекомендую внимательно прочитать эту и другие статьи на сайте Altium.

Ну и конечно же приглашаю присоединиться к разработке Database библиотек для Altium =)

Рекомендую принцип: один компонент - один футпринт.

Полностью согласен! Однако с небольшой оговоркой - некоторые компоненты предусматривают, например, вертикальную установку. Так как физически это один и тот же компонент, то считаю правильным, чтобы в базе хранилось несколько вариантов футпринтов. Другой пример - футпринты с различной плотностью монтажа у микросхем (MOST, LOW, NORMAL).

1. забыли добавит 4 пользовательский
2 для штыревых возможно горизонтальная, вертикальная и иная. Тут ноги могут быть отформованы по разному всего не учтешь, но это уже на PCB можно Pad двигать вручную, главное указать, в каком диапазоне возможно смещать PAD. Хотя при монтаже удобно, чтобы все элементы были отформованы идентично

Но вертикальную и горизонтальную можно оставить

В таблице футпринты так и расположены с порядковыми номерами от 1 до 46. Сама база библиотек резисторов открывается нормально, все посадочные места доступны. А возможности править в ручную нет В статье как раз и написано"Unlimited footprint and PCB3D model references (and paths) can be specified in a database table and mapped in the DBLib file. In the reserved names on the left, n represents a positive integer, starting from 2", что означает количество футпринтов неограниченно. В чем тогда проблема?


Для случая с резисторами и конденсаторами, с их многообразием габаритов, придется вводить боьшое кол-во компонентов. Считаю это излишним. Но это мое личное мнение. Возможно с Вами всеми и соглашусь, но чуть позже. А пока меня интересует вопрос, в чем проблема альтиума при работе с 46-ью футпринтами, и он не дает мне покоя.


Спасибо за приглашение, обязательно постараюсь принять участие

В том то и дело, что при работе через БД достаточно один раз нарисовать схемное обозначение, а потом наплодить записи типа R0805, R1206 и т.п., со ссылкой на одно и то же схемное обозначение.

А вот проблемы для случая большого количества посадочных мест - это путаница, которая потом может возникнуть.
Даже без этого - заменить один компонент в схеме на подобный несложно.
А вот проблем при генерации BOM избежать будет проще.

это уже ограничения редактора БД.
Достаточно 2-4 футпринтов с разными вариантами установки.

С этим согласен Просто я изначально пользуюсь уже до меня созданной библиотекой, и для меня стала она привычной. Теперь же когда озадачился созданием единой базы данных элементов, смотрю на это уже с другой точки зрения, и с Вами я соглашусь, что во избежания появлений различного рода пуитаниц, следует для резисторов и конденсаторов тоже разделить их по типоразмеру. Да и сам алльтиум не воспринимает иного подхода, как я уже и убедился. Всем спасибо.

чтоб отредактировать базу данных для резисторов, пришлось сконвертировать табличку в формат экселя, благо в экселе отсутсвует ограничение на длину строки, и успешно отсортировал контактные площадки по типам, создав новые компоненты резисторов для каждого типоразмера. Затем портировал обратно таблицу в аксесс. После всей процедуры, база элементов успешно заработала.

Ни у кого не тормозит Альтиум когда работаешь с элементами библиотеки организованной как база данных? У меня например добавление компонентов на печатную плату стал на порядок дольше происходить. Кстати и когда в PCB редакторе элемент на плату ставишь, тож секунды две три думает. Рабочий системник достаточно производителен, так что грешить на аппаратуру не могу. Заметил что при обращении к бибилотекам формата *.IntLib процессы практически мгновенны. В чем может быть проблема?

Интегрированные библиотеки как раз и сделаны с расчетом на уменьшение времени доступа к ним. Там все данные оптимально компонуются.
А вот обработка запросов к БД требует времени.
С другой стороны на основе DBLib можно сделать IntLib...

Sergey Makarov у меня жутко тормозил когда БД была в экселе. Перешел на аксес тормозит только при добавлении первого элемента.