[Uladzimir 68]

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

 

В ближайшее время я постараюсь вернуться к работе над библиотеками. И для начала хочется уменьшить размер БД, оптимизировав длину полей и их количество.

 

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

 

Feature (32) - тип элемента для перечня ("Резистор", "Микросхема"...)

Part Number (32) - уникальное имя компонента. ключевое поле (обязательное)

Manufacturer Number (32) - наименование из даташита (без типа упаковки)

Description (256) - описание из даташита

Manufacturer (64) - производитель

HelpURL (256) - ссылка на даташит

Package (16) - корпус (предпочтительно JEDEC)

Pin Count (4) - количество выводов (пока не знаю зачем)

Comment (256) - примечание для перечня

Library Ref (32) - имя символа УГО, находящегося в одноименном файле (обязательное)

Footprint Ref (32) - имя футпринта, находящегося в одноименном файле

Footprint Ref 2 (32) - дополнительный футпринт

Footprint Ref 3 (32) - еще один

Component Type (16) - пока не знаю что это. по умолчанию "Standard"

Mode (16) - вид (mode) УГО, по умолчанию "Normal"

Sim File (128) - имя файла со SPICE-моделью (не должно быть обязательным, но без него не работает)

Sim Model Name (32) - имя SPICE-модели (обязательное для симуляции)

Sim Description (64) - описание SPICE-модели

Sim Kind (16) - вид SPICE-модели (обязательное для симуляции)

Sim SubKind (32) - подвид SPICE-модели (обязательное для симуляции)

Sim Spice Prefix (2) - префикс SPICE-модели (обязательное для симуляции)

Sim Netlist (256) - список цепей SPICE-модели (обязательное для симуляции)

Sim Port Map (64) - мапинг выводов УГО и SPICE-модели

Sim Parameters (256) - параметры SPICE-модели

Sim Excluded Parts (256) - исключенные из симуляции модули

 

Далее идут поля параметров, присущих конкретному типу элемента (для резисторов "Value", "Tolerance", "TC"; для диодов "Current", "Voltage" и т.п...). Размер думаю будет 16.

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

 

Также в некоторых базах введены колонки с альтернативными значениями, например Alt Value для пассивных элементов. В них находятся те же значения, что и в Value (номинал), но десятичные отделены запятой вместо точки. Предназначен для отображения на схемах.

 

Поле Alt Manufacturer Number используется для отображения в панели Library в Альтиуме. Там хранятся более привычные наименования (пока только для пассивных компонентов).

То есть, выбирая и устанавливая на схему резистор "CR0603 3,9kOhm±2%", в перечне мы получим запись с указанием партнамбера "Резистор RC1608G392CS, SAMSUNG" (насколько я понимаю при закупке нужно именно наименование компонента как оно у производителя).

Или другой пример: ставим "FT232RL, SOIC", в перечне получим "Микросхема FT232RLD, FTDI"

 

Возможность вести учет по этим базам также рассматривалась, но была отложена на

будущее потому как я не сталкивался с этим. Но если делать, то стоит делать сразу.

Подскажите какие поля для этого нужны какой длины и типа?

не хватает:

1. Если есть ссылка, должно быть и пале например Datasheet? означающее что это. Тогда ссылку можно открыть прямо из схемы. кстати ссылок тоже может быть не одна

2. Не ссылок на номер каталога и каталожный номер,

3. нет ссылки но номер в хранилище (в складе)

4. По параметрам-- это лишнее для каждого отводить собственное поле. Вы не обобщите все параметры для всех компонентов. Тем паче если различаются например по частотной характеристики или иным динамическим параметрам. Достаточно одного краткого описания short Description Посмотрите пример на DigiKey

[jkrieger 0]

не хватает:

1. Если есть ссылка, должно быть и пале например Datasheet? означающее что это. Тогда ссылку можно открыть прямо из схемы. кстати ссылок тоже может быть не одна

2. Не ссылок на номер каталога и каталожный номер,

3. нет ссылки но номер в хранилище (в складе)

4. По параметрам-- это лишнее для каждого отводить собственное поле. Вы не обобщите все параметры для всех компонентов. Тем паче если различаются например по частотной характеристики или иным динамическим параметрам. Достаточно одного краткого описания short Description Посмотрите пример на DigiKey

1. даташит и так можно открыть прямо из схемы по нажатию клавиши F1 или из контекстного меню References - Help

2. какие каталоги вы имеете ввиду? digikey? я просто не пользовался ими и не знаю в чем их прелесть.

3. ну это по видимому к складскому учету имеет отношение. хватит ли одного поля?

4. параметры останутся. я не ставил задачу втулить в базу все параметры. лишь некоторые. об этом мы с вами уже говорили где-то в соседних ветках. если вы их не используете, то можно отключить в DBLIB файле.

[TOREX 0]

3. ну это по видимому к складскому учету имеет отношение. хватит ли одного поля?

 

У нас используются два поля "Стелаж" и "Ячейка"

[Uladzimir 68]

1. даташит и так можно открыть прямо из схемы по нажатию клавиши F1 или из контекстного меню References - Help

2. какие каталоги вы имеете ввиду? digikey? я просто не пользовался ими и не знаю в чем их прелесть.

3. ну это по видимому к складскому учету имеет отношение. хватит ли одного поля?

4. параметры останутся. я не ставил задачу втулить в базу все параметры. лишь некоторые. об этом мы с вами уже говорили где-то в соседних ветках. если вы их не используете, то можно отключить в DBLIB файле.

 

1. Можно. Но тогда это "даташит " должно быть прописано в библиотеке. А если ссылка не на даташит?

2. В частности. Никаких прелестей. Просто там в текстом написан тип компонента и ОСНОВНЫЕ параметры. Как правило этого и достаточно, чтоб вводить затем для параметров отдельные поля

3. Хватит--- просто ссылка тоже на уникальный заводской номер. По нему уже можно подключить любые складские параметры

4. смю 2

 

У нас используются два поля "Стелаж" и "Ячейка"

А у меня комната, шкаф, полка, ящик

У каждого свое. Лучше как писал в п.3. А остальные пусть сами через аксеес подключают, как у них принято

[masterofnature 0]

У нас используются два поля "Стелаж" и "Ячейка"

Хватит одного поля.

А туда можно писать либо номенклатурный номер, либо адрес в виде

[<стеллаж>,<ячейка>]

либо кому как удобнее.

[masterofnature 0]

Однако у меня достаточно слабая квалификация собственно в разработке РЭА. И я не могу предусмотреть многие ньюансы, которые необходимы, чтобы библиотеки были правильными и удобными. Мне очень хотелось бы услышать ваше мнение, ваше видение этой задачи.

Дошли руки посмотреть ваши библиотеки.

Пока посмотрел только резисторы и сразу пара замечаний (если кто возражает, пусть поправят).

- типоразмер корпуса лучше указывать в привычной системе (0805, 1206).

- designator и прочий текст лучше писать стандартным шрифтом

- выравнивание текста делайте от УГО. В частности, для текста под УГО, лучше поставить Top, а не Bottom. В этом случае, при замене шрифта, он не будет наползать на УГО.

 

[masterofnature 0]

1. Если есть ссылка, должно быть и пале например Datasheet? означающее что это. Тогда ссылку можно открыть прямо из схемы. кстати ссылок тоже может быть не одна

Для основной подсказки используется параметр HelpURL

Это может быть ссылка на любой документ, который можно открыть в АД, включая PDF, HTML и простой текстовый документ.

(PDF открываются во внешнем просмотрщике)

 

При этом в контекстном меню компонента появляется Reference -> Help

Для дополнительных документов используются пары параметров ComponentLink:

ComponentLink<n>Description

ComponentLink<n>URL

Появляются там же: Reference-> [ComponentLink<n>Description]

 

Например:

ComponentLink1Description = Embedded &Tools

ComponentLink1URL = Embedded_Tools.pdf

 

появится Reference -> Embedded Tools

при этом 'T' - будет "горячей клавишей".

 

Что касается расположения файлов, возможны:

- абсолютный путь

- относительный путь от папки Help программы (например "C:\Program Files\Altium Designer Summer 09\Help\")

При этом, если используется относительный путь, то нужно применять прямые слэши '/', а не обратные '\'

 

Путь относительно местоположения рабочего файла применять нежелательно, т.к. это ненадежно.

 

Ссылка: параметры редактора схем

 

PS: Думаю это имеет смысл добавить в FAQ.

[jkrieger 0]

Дошли руки посмотреть ваши библиотеки.

Пока посмотрел только резисторы и сразу пара замечаний (если кто возражает, пусть поправят).

- типоразмер корпуса лучше указывать в привычной системе (0805, 1206).

- designator и прочий текст лучше писать стандартным шрифтом

- выравнивание текста делайте от УГО. В частности, для текста под УГО, лучше поставить Top, а не Bottom. В этом случае, при замене шрифта, он не будет наползать на УГО.

 

1. Хм... в резисторах в поле Package типоразмер итак указан в дюймовых обозначениях. Если вы за Part Number, то там сейчас там внесено то же что и в Manufacturer Number.

2. какой шрифт считать стандартным? Arial? И не лучше ли, если я выложу рядом шрифты ГОСТ, которые в библиотеке используются?

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

[masterofnature 0]

1. Хм... в резисторах в поле Package типоразмер итак указан в дюймовых обозначениях. Если вы за Part Number, то там сейчас там внесено то же что и в Manufacturer Number.

Вы видимо взяли типоразмеры из библиотек AD, а для заказа на территории России проще применять другую классификацию, в соответствии с которой типоразмер 1206 <=> 3216 в библиотеках AD. Я исхожу именно из практичности применения.

 

2. какой шрифт считать стандартным? Arial? И не лучше ли, если я выложу рядом шрифты ГОСТ, которые в библиотеке используются?

Под стандартным я подразумеваю тот, который установлен по умолчанию (FontID = 1, если память не изменяет). При добавлении компонента на схему он заменяется на установленный для схемы. Там может быть и GOST и любой другой.

 

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

Иногда у AD глючит обновление экрана для надписей. Хотя и сделано выравнивание по центру, отображаться может невесть как.

К тому же, Designator лучше смотрится, если расположен в верхнем левом углу и выравнен по левому краю.

 

PS: В списке полей для БД не увидел Designator, Library Path, Footprint Path.

[jkrieger 0]

По поводу типоразмеров. Я старался придерживаться следующей маркировки (как принято у окружающих меня специалистов):

 

1.0 mm × 0.5 mm - 0402

1.6 mm × 0.8 mm - 0603

2.0 mm × 1.25 mm - 0805

3.2 mm × 1.6 mm - 1206

 

Под стандартным я подразумеваю тот, который установлен по умолчанию (FontID = 1, если память не изменяет). При добавлении компонента на схему он заменяется на установленный для схемы. Там может быть и GOST и любой другой.

О FontID я не знал. Разберусь где их менять и поправлю.

 

В списке полей для БД не увидел Designator, Library Path, Footprint Path.

Library path и Footprint Path считаю лишним. Пути для поиска моделей задаются в свойствах библиотеки.

Designator идет из УГО. Разве нужно его дополнительно задавать?

[masterofnature 0]

Designator идет из УГО. Разве нужно его дополнительно задавать?

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

 

И в принципе надо разобраться - какие откуда параметры брать.

Те, что общие для типа компонентов - проще из самого УГО.

[masterofnature 0]

Library path и Footprint Path считаю лишним. Пути для поиска моделей задаются в свойствах библиотеки.

Почему-то без указания Footprint Path у меня при добавлении компонента на схему не отображается предпросмотр посадочного места, хотя посадочное место он находит и связывает.

Но без предпросмотра как-то некомфортно.

[masterofnature 0]

Для наполнения библиотеки: держатели SIM-карт (3 типа)

Схемное обозначение требует переработки.

Привожу его для простоты применения посадочных мест (назначение выводов)

Дополнительно загружаю отдельные STEP-модели.

SIM_CardHolder.sch.rar

SIM_CardHolder.pcb.rar

91228.rar

475530001.rar

KSI_06.rar

[LeonY 0]

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

 

Хочу задать косвенно относящийся к теме вопрос, потому что сам четкого решения придумать не могу:

Существует такое понятие как "obsolescence" (прошу прощения, но просто не представляю как это будет на русском - ну это когда компоненты, используемые в разработке с течением времени исчезают) и для предотвращения и/или снижения этого эффекта заказчики требуют предусмотреть возможные "прямые" замены. Ну как пример могу привести замету 7404 от TI на 74F04 от Fairchild или там резистор с точность 5% может быть заменен на однопроцентный. Это также облегчает производство в плане приобретения деталей, ну это как бы внутренние проблемы компании.

 

А вот проблемы с заказчиком вырастают в кошмар - сейчас опишу. Пару лет назад сдавал проект для Eurocopter. Это была довольно большая система из 2-х десятков плат. Все испытания, приемка - все прошло нормально и начались серийные поставки. А вот тут и произошел полный мрак. С момента разработки и передачи документации до собственно поставок прошло около 2-х лет. За это время детальки закупались несколько раз и отличались от того, что было исходно в документации. Эти гады расковыряли все расхождения и подняли дикий крик. Хуже того - платы из первых поставок отличались от плат из последних, что еще усилило вопли. В конце концов их удалось убедить, что технически тут все ОК. Но на доработке документации они стояли мертво. А доработка заключалась в следующем - для деталей в которых возможны замены (в основном это касалось микросхем и танталовых конденсаторов) все возможные наименования должны быть указаны на схеме и в перечне элементов. Наши системы, ни CAD, ни системы управления базами данных, не поддерживали таких возможностей. Все доработки документации пришлось делать вручную нарушая все возможные правила. Мечта...

 

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

 

Есть ли у кого-нибудь иде на этот счет???

[masterofnature 0]

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

 

Есть ли у кого-нибудь иде на этот счет???

Я тоже раздумывал на этот счет.

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

 

Вот только еще такая интересная деталь: есть компоненты частично-совместимые (блоки питания, драйверы 232, память и т.п.).

в том числе созданные под pin-to-pin, но с урезанием возможностей.

Для них разработчик уже сам должен решать степень совместимости данных компонентов для изделия.

 

Могу еще такой пример привести: DS3231, DS3232, DS32B35

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

В то же время, чтобы использовать вместо второй - первую или третью нужно изначально заложить увеличенный футпринт.