БД-библиотеки для Altium Designer

Говорят, «обещанного три года ждут». Что ж, я постарался выполнить обещание чуть быстрее =)
И представляю на ваш суд статью о своем опыте работы с БД-библиотеками в Altium Designer.

Всем интересующимся добро пожаловать под кат.

Вступление

Для работы с компонентами в Альтиуме есть как минимум три пути:

Первый — хранить условные графические обозначения (символы) в библиотеках SchLib, посадочные места (футпринты) — в PcbLib.
При этом схема строится из символов, к ним вручную привязывается футпринт, после чего схема передается в PCB редактор.
Этот подход требует минимум усилий для создания и поддержания библиотек — чего там, символов много не будет, на схеме все резисторы одинаковы, только подписи меняй; футпринов тоже не сильно много. Однако само проектирование (привязывание футпринтов и моделей, изменение номиналов и надписей) занимает огромное количество времени. Подход, имхо, хорош для малых проектов, и в случае где нет необходимости в стандартизованой КД.

Второй подход — хранение компонентов в интегральных (или интегрированых) библиотеках. Тут к каждому компоненту уже при создании можно привязать футпринт, модель, добавить кучу параметров, отражающих его свойства и т.д.
При проектировании таким методом останется лишь расставить компоненты по схеме, соединить их, и можно сразу же передавать дальше, в PCB-редактор. Облегчается генерирация BOM (перечня элементов), спецификации и других сопутствующих документов. Это немаловажно при работе над большими проектами, если вы хотите чтобы хоть кто-нибудь после вас смог разобраться в нем. Кроме того есть еще один огромный плюс — транспортабельность таких библиотек, ведь компоненты в них уже «готовы к употреблению».
Из минусов, наверное, можно отметить громоздкость интегрированых (или интегральных) библиотек. Нет, места они занимают немного, но вот поддерживать единообразие такого зверинца становится уже трудно. Ведь когда ваша компонентная база разростется, вы наверняка будете разбивать свою интегральную библиотеку на несколько (по типам, или производителям, или еще как-то). И обязательно гле-нибудь закрадутся ошибки, например, в одном из параметров вместо точки была поставлена запятая, или в одной библиотеке у вас светодиод будет нарисован с окружностью, а в другой — без оного (да, я понимаю, что пример надуман, но проблема существует). Мелочь, конечно, но иногда кажущаяся мелочь может привести к печальным последствиям. Для исправления этих ошибок вам придется открыть Altium и вручную искать, а затем править необходимые параметры.
Хотя, с другой стороны это, наверное, самый распространенный подход в организации компонентной базы.

Ну и третий вариант, это использование Database Libraries (я к сожалению не знаю правильного и красивого перевода этого словосочетания на русский язык, потому буду использовать самопальный термин «БД-библиотеки»).
В случае с БД-библиотеками компоненты хранятся как и в первом случае в «разобранном виде»: символы, футпринты и модели лежат в библиотеках .SchLib, .PcbLib и .mdl/.ckt соответственно. Однако есть и отличие — БД, где хранятся параметры компонентов (такие как номинал, максимальный ток и напряжение и проч., проч., проч.). И благодяря этим параметрам при перетаскивании компонента на схему «на лету» производится его «сборка».
Получается, что БД-библиотеки совмещают в себе преимущества двух первых подходов организации компонентов: с одной стороны все разнообразие символов и футпринтов сведено к минимуму, с другой — на схему перетаскивается готовый компонент с максимумом информации о нем, привязанными футпринтами и моделями.
Кроме того появляется возможность интегрировать БД в систему складского и бухгалтерского учета. Но это важно скорее для организаций, нежели не для рядового разработчика.
Платой за это является бОльшая сложность организации такой библиотеки, и наверное плохая транспортабельноть (хотя сильно сложного тут ничего нет).

Впрочем, статья не претендует на объективное сравнение различных подходов, все вышенаписанное — лишь моё ИМХО. Просто, как вы уже могли догадаться, мне слишком понравились БД-библиотеки ;-) Давайте же, наконец, посмотрим как они устроены.

Теория


Внутри БД все довольно тривиально. Каждая таблица — отдельная библиотека, каждая запись (строка) — компонент, каждое поле (колонка) — параметр компонента.



Параметры компонента можно разделить на три группы: идентификатор, зарезервированные параметры и параметры общего назначения.

Идентификатор это одно (простой идентификатор) или несколько полей (сложный идентификатор), по которым Altium находит и идентифицирует компонент. Сразу стоит отметить, что со сложными идентификаторами Altium работает крайне криво, и потому использовать их не рекомендуется. Естественно идентификатор является обязательным.

Зарезервированные параметры это параметры, при нахождении которых Altium заполняет форму свойств компонента, например символ, футпринты, модель, тип и т.д.



Полный список зарезервированных параметров можно подсмотреть в официальной документации: Using Components Directly from Your Company Database.
Отмечу, что обязательным среди них является только Library Ref — имя символа УГО (иначе вы не увидите список компонентов в библиотеке Altium). Остальные зарезервированные параметры добавляются по мере необходимости.

Все остальное, что не попало под первые две категории — попадает в третью и привязывается к компоненту в виде текстового параметра:



Эти текстовые параметры вы можете отобразить на схеме, выносить в BOM, использовать для поиска и т.д.

Информация
Вообще Altium при импорте из БД все параметры интерпретирует как текст, даже если в таблице они имеют целочисленный тип или тип даты/времени. И это, к сожалению, делает невозможным параметрический поиск по библиотеке в Altium Designer.

Конечно, у меня нет официальной информации от компании Altium как именно происходит взаимодействие с БД, но немалое количество экспериментов и чужих статей дают основания полагать, что оно осуществляктся посредством языка SQL.

Итак, первое что нужно сделать Altium Designer'у — отобразить список компонентов, находящихся в библиотеке. Для этого Altium отправляет SQL запрос примено следующего содержания:

‘SELECT [Part Number] FROM Transistors’.

В ответ получает огромный список значений, содержащихся в поле «Part Number» таблицы «Transistors», и выводит этот список на панели Library. Конечно, запрос может изменяться в зависимости от того как вы настроили панель Library.

Далее Altium'у необходимо «собрать» компонент, на который вы перетащили на схему, чтобы отобразить его символ, футпринт и параметры.

Когда будете создавать свой ".DbLib" файл обратите внимание на опцию, где указано что-то вроде: «Where [Part Number] = '{Part Number}'». Это и есть тот запрос, по которому будут извлекаться данные о компоненте. Допустим, что используется именно такой запрос, и на схему был помещен компонент с идентификатором «КТ315». Тогда для получения его параметров отправляется запрос:

‘SELECT * FROM Transistors WHERE [Part Number] = 'КТ315'’.

Движок БД возвращает значения всех полей для записи, у которой поле «Part Number» = «КТ315». Что делать с текстовыми параметрами более менее понятно, а вот с зарезервированными не очень. Тут и начинается магия…

Как уже говорилось ранее, «запчасти от копмонентов» хранятся отдельно, а в БД — лишь ссылки на них. Чтобы собрать крмпонент Altium должен найти все эти «запчасти».

В идеальном случае в БД хранятся ссылки с указанием абсолютного пути к файлам с символами, футпринтами и моделями. Тогда нет неоднозначности, и Altium сможет собрать компонент, главное чтобы файлы с «запчастями» были на месте.

Однако, указание абсолютных путей не обязательно, а иногда даже нежелательно. Например, если вы захотите переместить свою библиотеку, то вам придется изменить все пути в БД — не очень то удобно.

В этом случае в БД можно указывать относительные пути к файлам с «запчастями». Тогда Altium высчитает пути файлов относительно расположения ".DbLib" файла и дальше алгоритм сводится к предыдущему методу.

Но есть еще одна возможность, на мой взгляд, самая интересная — можно вообще не указывать какие-либо пути в БД. Ведь база данных хранит информацию о компонентах, а не о структуре папок на вашем компьютере, верно?

Что же делать Altium'у? Раз о путях ничего не известно, то Altium попробует найти «запчасти» сам. Алгоритм поиска примерно следующий. Допустим нам нужен символ. Сначала ищется файл с таким же именем как и имя символа. Если такого файла нет, то поиск продолжается во всех файлах ".SchLib", пока не встретится символ с нужным именем.

Естественно, поиск ведется не по всем файлам на компьютере, а только в тех папках, о которых «знает» Altium. Это папки, указанные в настройках и в ".DbLib" файле. Приоритет имеют папки, указанные в ".DbLib".



Впрочем, в следующем разделе будет показано как это работает именно этот способ, посмотрите — будет понятней.

Практика


Первое что нам понадобится — это собственно база данных. По-умолчанию Altium Designer предлагает подключить в качестве БД ".xls" или ".mdb" файл. Но при желании можно подключить практически любую БД через ODBC драйвер, например MySQL или даже текстовые файлы в формате CSV. Так что выбор движка БД непринципиален, вы можете использовать то, что вам нравится (что у вас уже есть).

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

Во-первых, стоит обратить внимание на такой вопрос как: «Что считать идентификатором компонента?». Идентификатор компонента должен быть уникальным, а значит первое что приходит на ум — автоинкрементируемое числовое поле (индекс). Данное поле будет всегда уникальным и не требует определения при добавлении нового компонента.

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

Самым «кошерным» вариантом, по моему мнению, является идентификация компонента по комбинации двух параметров — «наименование производителя» и «наименование компонента». Ведь у одного и того же производителя не может быть два компонента с одинаковыми названиями (хоть мне говорили, что и такое бывает, но мне в это слабо верится).

Однако, в статье уже упоминалось, что со сложными идентификаторами Altium работает криво (у меня иногда некорректно собирался компонент).

Эта проблема была решена вводом в таблицу уникального поля «Part Number», которое хранит в себе производителя и наименование компонента разделенные точкой, например: «NXP Semiconductors.BC546A». Размер таблицы немного увеличился, но не думаю, что это станет проблемой.

Информация:
Совсем не обязательно выделять для этого отдельное поле в таблице. В случае с MS Access можно создать Запрос, который склеивал бы нужные поля «на лету», и использовать Запрос вместо Таблицы. Оригинальную же таблицу можно скрыть в настройках ".DbLib".

Во-вторых, нужно определиться какие параметры вы хотите привязывать к различным категориям компонентов. Это укажет сколько таблиц с различными наборами параметров необходимо создать в БД. Впрочем, если вам в компоненте важны только символ и футпринт, то вполне сгодится и одна цельная таблица. где будет храниться все подряд, при желании ее можно будет разделить запросами на несколько библиотек.

Однако, в моем случае нужно было привязывать не только символы/футпринты, но и модели для симуляции, а также основные параметры компонентов — для того, чтобы их можно было группировать по интересующим меня в данный момент характеристикам. Исходя из этих данных у меня получилась примерно такой набор таблиц:

  • Capacitors
  • Inductors
  • Resistors
  • Diodes
  • Transistors
  • ICs
  • Connectors
  • Mechanical
  • Miscellaneous

Не буду останавливаться на мелочах, посмотреть шаблон БД можно в аттаче в конце статьи. Для создания базы данных я воспользовался MS Access 2007 (ну что под рукой было) и создал базу данных в формате MS Access 2000 (Altium прекрасно работает и с форматом 2003, а вот 2007 как-то часто отваливался у меня, но допускаю, что это из за кривизны моих рук).

Далее нужно создать структуру папок для библиотеки. Сейчас моя библиотека еще очень маленькая и сказать насколько удобно будет то или иное решение при масштабировании сказать сложно. Пока что я ограничился тремя папками: «symbols», «footprints» и «models», а БД и файл ".DbLib" хранятся в корневой папке.

Ну и напоследок нам потребуется ".DbLib" файл. Создается он просто: «File» > «New» > «Library» > «Database Library».



Далее необходимо выбрать тип БД (Excel или Access), указать путь к файлу БД и нажать кнопку «Connect». Или же можно нажать кнопку «Build» и при помощи мастера подключить любимую СУБД.

После этого, если все было сделано правильно вы должны увидеть в панели слева список таблиц и запросов в БД. «Лишние» таблицы можно отключать, чтобы не отображались в панели «Library».



В нижней части окна настраивается маппинг полей БД. Описывать работу с ними сейчас не буду, все хорошо описано в документации: Mapping Database Fields to Design Parameters. Скажу лишь, что эти настройки позволяют отключать ненужные поля, если таковые есть в БД, и создавать связи между произвольными полями в БД и атрибутами компонентов Altium’а.

Вот собственно и все, осталось сохранить ".DBLib" файл, и можно будет подключить его как библиотеку и начать наполнять свою БД. Наполнение совсем не сложно, думаю достаточно привести простой пример.



Здесь вы можете увидеть поле идентификатора, производителя, краткое описание компонента (обычно беру первое предложение из даташита), очень полезный параметр «HelpURL», который позволяет вызывать даташит на компонент по нажатию клавиши «F1», наименование символа, наименование футпринта, номинал конденсатора и поля для симуляции.

Сложного ничего нет, главное не запутаться. На панели «Library» компоненты выглядят следующим образом.



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

Большие Грабли №1 Самые неприятные и больно бьющие грабли оказались в том, что БД-библиотеки не содержат механизма, позволяющего настраивать связь выводов символа и футпринта. Эта самая связь идет по десигнатору вывода — вывод «1» на схеме будет выводом «1» на футпринте, и это сильно осложняет жизнь.

Для примера возьмем биполярный транзистор: у него всего три вывода: «E», «B», «C».
На корпусе тоже три вывода, но вот порядок их может отличаться от транзистора к транзистору: EBC, BEC и т.п., всего 6 вариантов. А так как связь между выводами осуществляется по десигнатору, то в 5 случаях из 6 мы получим неправильные соединения на плате. По-хорошему, нужно было бы выполнить назначение соответствия выводов: «E»-«1», «B»-«2», «C»-«3». Но раз мы этого сделать не можем, то приходится извращаться: делать либо 6 вариантов символов, либо 6 вариантов футпринтов с разной распиновкой.

В моем случае я остановился на варианте с разными символами, то есть у меня есть символы с названиями TRANS-NPN-EBC, TRANS-NPN-BCE, и т.п., а в футпринтах нумерация выводов по-порядку — 1, 2, 3. В зависимости от того в каком порядке расположены выводы у транзистора я назначаю компоненту тот или иной символ.

Грабли №2 Следующий момент — пути поиска SPICE-моделей. Напомню, что я старался отвязаться от абсолютных путей в своей библиотеке, и в «DBLib» файле указывал пути поиска «запчастей» относительно этого самого «DBLib» файла. Вот только модели при этом «не цеплялись». Как оказалось, путь к файлам ".mdl" и ".ckt" нужно указывать не относительно «DBLib» файла, а относительно файла, содержащего символ компонента. После этого все заработало как нужно. Впрочем, о симуляции в AD я думаю мы еще поговорим отдельно.
  • +3
  • 24 декабря 2011, 14:55
  • Krieger
  • 1
Файлы в топике: libraries.zip

Комментарии (80)

RSS свернуть / развернуть
Огромное спасибо! Сам давно собирался разобраться с этими библиотеками. Ваш топик очень кстати)
0
Даа, Грабли №1, это основательная ж… па. В последней версии может исправили? Никто не в курсе?
0
У меня недавно появилась двухмесячная лицензия на AD10. Потому я сейчас с радостью тестирую последнюю версию, и нет, там с этим моментом ничего не изменилось. Правда я думаю уже и не изменится, потому как Altium сейчас продвигает еще одну очень вкусную штуку — Vaults (хранилища). Там вам и контроль версий, и комьюнити, и связь с БД вроде. Толком еще не разобрался, но выглядит очень мощно и удобно.
0
Ты на семинаре был? (У меня недавно появилась двухмесячная лицензия на AD10). Или триальную версию качнул.?
0
Был на семинаре в Москве в начале года. А прислали лицензию недавно.
0
Можешь материалы скинуть с семинара.? И ещебы лицензию.
0
Вот материалы с тест-драйва, за исключением дистрибутива Altium Designer. Много весит, и его можно скачать при желании:

А вот лицензия это не файл. Лицензия м… сетевая, через Altium Live. Так что ее дать не получится. Вы можете получить триальную лицензию, по идее будет то же самое.
0
Простите. ссылка не вставилась (
http://we.easyelectronics.ru/attachments/get/537
0
я первые грабли в общем то и не назвал бы граблями — ну небольшое неудобство. Я его правда решаю наоборот — в символ у меня один, а футпринты разные. Какая разница сколько у тебя футпринтов или символов, если ты их все равно будеш привязывать руками в таблице базы данных?
0
Да, скорее неудобство. Но согласитесь, это неудобство немного ломает красоту подхода =)
Я назвал это граблями, чтобы разработчики помнили об этом ньюансе и не накосячили на радостях. А для занесения в БД я даже мастер новых компонентов написал, так что в БД ручками вносить тоже не приходится.
0
А вот это интересно — с этого момента подробнее )
0
Поподробнее в комментарии не поместится )
К тому же я все равно планировал немного порекламировать этот проектик. Постараюсь сделать небольшой очерк.
0
Это и имелось ввиду.
0
Первых граблей не существует. Введите в поле «Designator» пина Е и тоже самое введите в свойствах «Designator» пада.
На корпусе тоже три вывода, но вот порядок их может отличаться от транзистора к транзистору: EBC, BEC и т.п., всего 6 вариантов.
Как правило (за редким исключением) в семье транзисторов для определенного типа корпуса закреплено соответствующее расположение С, В, и Е. А, вот, от типа корпуса к типу меняется. Различное расположение чаще встречается в наборах диодов, где общий анод, общий катод или анод объединен с катодом. Тут легче иметь несколько посадочных мест.
0
  • avatar
  • DVF
  • 25 декабря 2011, 16:15
Может правило и есть, но даже у одного и того же производителя (NXP) есть из него исключения.
0
Пробовал освоить SVNDBlib, но как-то очень уж с ними не удобно работать и совершенно не понятно, чего ради. В общем остался на intlib, особенно после того, как нашёл, что там есть весьма неплохая дифилка с интеграцией SVN.
0
Отличная стаття. Автору спасибо.
Грабли №1. А нельзя в качестве «Designator» указывать латинские буквы «E»,«C»,«B»?
У меня в intlib это прокатило нормально.
0
Привязка конечно сработает, но как выше упоминалось, эти самые C, B, E могут быть по разному расположены:
BC546A — www.nxp.com/documents/data_sheet/BUJ100.pdf
BUJ100 — www.nxp.com/documents/data_sheet/BC846_BC546_SER.pdf
0
ну два футпринта сделайте, что сложного то?
А потом в таблице базы данных пропишите к нужному транзистору нужный футпринт.
0
Мне не надо два футпринта. Мне нужен ОДИН футпринт соответствующий одному посадочному месту. Я должен быть уверен, что в производство пойдет именно этот единственный, проверенный нормоконтролем, а не какой-нибудь из десяти забытых клонов, заботливо вытащеным неизвестно откуда студентом-практикантом.
0
В моем случае я остановился на варианте с разными символами, то есть у меня есть символы с названиями TRANS-NPN-EBC, TRANS-NPN-BCE, и т.п., а в футпринтах нумерация выводов по-порядку — 1, 2, 3.
А тут для студентов-практикантов все прозрачно… И это при шести! вариантах УГО против двух футпринтов. Блажен, кто верует!
0
Откуда двух? Тех же шести. Комбинаторика работаетодинаково.
0
А при чем тут комбинаторика? Имеется ввиду два варианта:
1. Один символ npn (УГО) и два футпринта;
2. Шесть символов npn (УГО) TRANS-NPN-EBC, TRANS-NPN-BCE, и т.п., и один футпринт.
Или я не так Вас понял?
0
Мне непонятно почему получилось всего два футпринта в первом варианте. Ведь в общем случае у корпуса есть «перед» и «тыл», то есть порядок ног EBC не равно CBE, потому по моим расчетам футпринтов будет тоже шесть при одном УГО.
0
Если вы скопировали уже проверенный футпринт трехвыводного элемента и поменяли местами обозначение двух выводов и сохранили его под дургим именем, то что он стал неправильным? И вообще при чем тут студенты? :) пусть студенты делают свою библиотеку :)
0
А некоторое время спустя, выясняется, что у вас непропай, и вам надо подправить пады и маску. И вы начинаете грустить, потому что у вас 76 посадочных мест какого-нибудь BGA140, у которых 76 разных имен, из которых у половины вы не помните названия, а треть создавали не вы и названия вам даже неизвестны.
0
мы вообще то про трехвыводные, с BGA и прочими более-менее все одинаково.
0
А какая разница двух или трех? Суть та же. И вообще как правильно вы же и заметили ниже, для дома для семьи БД ну совсем ни к чему… А вот если на производстве с подобным подходом… То у вас все еще впереди. Поверьте мне.
0
ну разница в том что у soic dip bga нумерация выводов всегда одинаковая в паттерне — а вот если это sot-32 или to-92 то там относительно символа будут отличия — и надо или несколько символов (по вашей методе) или несколько футпринтов (по моей).
А что касается производства… за 17 лет много разного было и будет тоже еще не мало — и тут ни БД ни какие то другие либы или подходы не помогут. Поверьте мне :)
0
Нумерация выводов транзисторов тоже регламентируется стандартами IPC и потому в паттерне не отличается. А вот назначение (EBC) различается. По-моему прямая аналогия с BGA. Собственно потому я и выбрал вариант с 6 УГО и одним футпринтом.

А вот с тем что БД не панацея, как и любой другой способ, я соглашусь более чем. Хотя все еще надеюсь найти методы управления своими компонентами, чтобы минимизировать косяки.
0
ОК — по выходу из отпуска попробую вашу методику с несколькими символами и одним футпринтом
И конечно удем ждать Вашу статью о мастере новых компонентов.
0
Есть заказчики, которые требуют делать по IPC, но это все же рекомендации. А, если Вас попросят отступить от этих норм, Вы откажетесь выполнять заказ?
У подхода создания нескольких УГО может быть есть некоторый плюс в том, что символ «весит» меньше, чем футпринт с step-моделью (мое предположение, так как специально это не отслеживал).
0
Ну и ладно. Мир всем :)
0
А мы на производстве и работаем.
0
Ну хорошо. А где гарантия, что когда-нибудь вы не прицепите соседнее УГО вместо нужного? Выглядит одинаково, глаз замылился. Про студентов умолчу.
И применение БД в таком ракурсе теряет смысл. Зачем нам плодить сущности, равнозначные функционально, будь то УГО или пос. место?
«И иные упали в терния, они заглушили семя, и червь съел их...»
0
Точно. Извините, словил тупака.
0
И в чем проблема по ссылкам? Это, как я и сказал, редкость и выводы зеркально отображены относительно базы (2) — копируете уже созданный футпринт, даете ему дополнительное расширение в имени и нет проблем.
0
Проблемы нет, неудобство есть. Вы решаете его клонированием футпринтов, я — клонированием символов. Результат один — работает.
Однако, для моделей симуляции, например, маппинг выводов в БД сделали. Почему не сделали маппинг выводов для футпринтов не знаю, но я считаю он бы очень помог.
0
сколько людей столько мнений — я лично маппинг не переношу с pcad2002(там было нечто подобное когда символ привязывался к патерну), было пару очень неприятных косяков.
0
А вообще подведя итог в общем то отличной и полезной для начинающих и не только статье выскажу свое мнение:
— библиотеки на основе базы данных полезны только на производстве — когда используется очень много разных типов элементов, когда надо делать КД и побыстрее;
— а для дома и семьи наиболее правильно будет использовать intlib — быстро, наглядно и удобно.
Если кто-то не согласен — можем подискутировать.
0
В общем-то так. Да и БД не намного меньше по объему получается (как казалось бы) при многократных применениях одних и тех же уго и футпринтов (ну, во всяком случае БД с описанием до 1000 компонентов).
0
Да спасибо познавательная статья, а не подскажите где можно взять футпринты для альтиума?
0
можно взять из самих библиотек альтиума Library\PCB\IPC-7350 Series, там в основной массе качественно сделанные и правильные футпринты. Можно на electronix.ru — там были — но за правильность не скажу. Вообще футпринтов IPC-7350 должно хватать за глаза.
0
Спасибо, посмотрим.
0
В альтиуме есть качественный генератор футпринтов, удовлетворяющих требованиям IPC. Но там вроде только SMT компоненты. Для остальных (очень многих) есть поиск на сайте Altium.
0
Если бы кто-то выложил 3D футпринты то было бы неплохо для всех…
0
Могу предложить для затравки code.google.com/p/altium-common-library/source/browse/?repo=acl#hg%2Ffootprints
Тут, конечно, футпринтов кот наплакал. Но если у меня появится время занться своими проектами, то они будут активно пополняться.
0
Спасибо. Посмотрим, я беру здесь но там тоже не все www.3dcontentcentral.com/default.aspx
0
О, ну тогда у меня ничего нового вы не найдете — все оттуда же =)
0
Походу там многие берут))
0
Можно еще тут, но там немного: cad-design.ru/
0
Ок. Спасибо, посмотрю. Так и самому рисовать не придется. Хотя если кто знает, вопрос — в какой среде лучше всего рисовать модели для Альтиума, я имею введу чтобы попроще была (не 3Dmax). Или может у кого опыт в этом деле есть подскажите. Заранее спасибо.
0
Можно в Компас-3D. Разобраться там не сложно (я, когда лабы делал, за вечер нарисован несколько примитивных деталей), но, на мой взгляд, какой-то он неудобный…
0
Лично я рисую в Autodesc Inventor (точнее, рисовал, когда на это свободное время было, сейчас обхожусь обычными футпринтами). Кроме хорошо продуманного юзабилити там огромный бонус в виде табличных деталей — нарисовал TQFP, составил табличку и автоматом получил TQFP32, TQFP44, TQFP64, TQFP100 и тд. Аналогично можно поступать со всякими PLS, SMD-компонентами и так далее.
0
Что-то она много весит, 17 гиктар…
0
Есть такое дело, но там большую часть объёма занимают библиотеки, которые можно не ставить, если не занимаешься конструкторской деятельностью. Сам инвентор (у меня 2011) занимает примерно 2 гига.
0
кста, мб запилишь пару уроков на тему построения корпусов в инвенторе? естественно, параметризация особенно интересует.
0
Хорошо, заявка принята =)
Когда время будет попробую написать что-нибудь, но скоро не ждите. Кстати, а почему пару? Есть какие-то конкретные пожелания?
0
пару, чтобы вводная на тему что такое и с чем едят параметрические системы моделирования, чем он такой особенный, инвентор, неплохо еще сравнить скажем, со всеми любимыми автокадами и солидами (solidworks), ну и в таком духе типа про первые шаги. а дальше уже с подробностями. в один материал — получится ну очень многа букаффф… вводная будет всем (надеюсь) полезна, т.к. в основном народ сидит или в автокадах с максами, или солиде, или еще где. лично у меня инвентор уже с месяц, а то и больше лежит. ждет пока до него доберусь поковырять, но все никак. если нужно что построить-прикинуть расположение, солид на автомате запускается…
0
ну и особенно интересно вот это:
огромный бонус в виде табличных деталей — нарисовал TQFP, составил табличку и автоматом получил TQFP32, TQFP44, TQFP64, TQFP100 и тд. Аналогично можно поступать со всякими PLS, SMD-компонентами и так далее.
0
Ага, посмотрим. Правда с солидом сравнить не смогу, ибо «не осилил» =). Автокадом тоже пользовался только в рамках университетского курса (один семестр собственно рисования и один — программирования на AutoLISP; в целом прикольно, но не актуально). У меня основными конструкторскими инструментами Инвентор и Компас3D.
Много букаф писать лень — боюсь мало кому полезно будет, все х на солиде сидят. Вон про CodeBlocks целый трактат накатал, а в итоге и десяти комментов на всех не набралось =).
0
ну, собственно говоря, я тоже на солиде уже давно и плотно сижу. как соскочил с автокада на 12-й, кажется, версии, так и все. а инвентор заинтересовал именно параметризуемостью с подачи где-то на форуме. но без пинка со стороны и дальше скорее всего буду сидеть на солиде, пока однажды не перемкнет с наличием некоторого свободного времени.
а количество комментариев к статье еще ни о чем ровным счетом не говорит — значит, статья самодостаточна и дополнительных вопросов не возникло… ;)
0
>> а инвентор заинтересовал именно параметризуемостью
Да, в общем-то, практически всё современные машиностроительные КАДы параметризуемые, просто не везде этот механизм сделан удобно. Например, когда ты накладываешь на две прямые связь «параллельность» — это уже и есть параметризация.
0
в принципе да, практически везде есть. но элементарные случаи типа параллельности, совпадения и расстояния не рассматриваем. ну вот например, я решил переделать свой лабораторник. по семисегментнику на ток и напряжение. а как сказать, что края должны быть симметрично относительно вертикальной плоскости ручки энкодера — не нашел. мб плохо искал. или, что скорее всего, где-то не дочитал. но ведь хочется более удобный доступ к таким моментам…
0
Ну почему же не рассматриваем? Привязку «симметричность» всегда можно заменить привязками «перпендикулярность»/«параллельность» и «равенство», наложенными на некий вспомогательный элемент. Или вообще тупо начертить вспомогательную окружность с центром на оси симметрии и воспользоваться привязками «параллельность» и «касание». Тут вопрос скорее эргономики.
ЗЫ: в компасе, инвенторе и автокаде привязка «симметричность» есть, про солид не скажу.
0
еще на kazus в форуме про протеус — там выкладывали много моделей.
0
Всех с наступающим Новым Годом!!!
А не могли бы ссылку где там, на казусе посмотреть, кинуть?
0
kazus.ru/forums/showthread.php?t=19361

C наступающим Новым годом!!!
Удачи, счастья. здоровья и интересных статей в Новом году!
0
Спасибо, посмотрим.
0
В Компас-3D я посмотрел но что-то не нашел экспорт в Step файл. Из формата .3DS тоже не удалось получить Step. Пришлось открывать в Rhino4 .3DS-кие модели (с форума kazus.ru/forums/showthread.php?t=19361 ) и потом полностью перерисовывать поверху моделей, только после этого можно было сохранить в степе.
0
Чтобы получить из Компаса STEP модели надо свои труды «Сохранить как», только там STEP203, не поддерживает цвета; и экспортированная в STEP сборка в Altium не влезет. STEP214, который с цветами, поддерживает FreeCAD, я туда свою сборку LQFP48 из Компаса импортировал через IGES, там уже настраивал цвета и, выделив все элементы сборки в дереве модели, экспортировал в STEP214.
0
Насчет «Сохранить как» юмор я понял, только наверное у меня Компас урезанный, пришлось разбираться с Rhino4 там поддерживает и STEP 214 и 203 (импорт не нужен ) + открывает 3DS.

Примерно так.
0
Я бы скинул, кому интересно и степ, только не знаю как прицепить файл.
0
Можно ли сделать библиотеку на основе БД доступной по сети с сервера? В Альтиуме есть вариант установки локально и с Vault. А мне нужен удаленный доступ.
0
Вроде никто не мешает положить файл БД в расшаренную папку. Но сам не проверял. Я немного допилил систему и храню БД под системой контроля версий. Очень удобно для корпоративной работы: и история изменений есть и расшарена. Если интересно то могу статейку написать.
0
А если мне доступен ip-адрес и порт и я работать с этим сервером? Такое возможно?
0
Видимо мы друг друга не совсем поняли. У вас сервер в локальной сети?
0
Нет. В глобальной. В интернете. Я хочу иногда из дома работать, а для этого нужно подключиться к серверу, который находится в офисе.
0
Нет, по порту можно только если вы будете использовать вместо Access баз данных MySQL или MSSQL.
Постараюсь скоро описать как у меня получилось решить этот вопрос.
0
Нет, по порту можно только если вы будете использовать вместо Access баз данных MySQL или MSSQL.
Не совсем понимаю как это реализовать. Вот например, я сделал библиотеку на MySQL. А Альтиум все равно при установке библиотеки предлагает выбрать путь локально либо в сетевой папке.
Постараюсь скоро описать как у меня получилось решить этот вопрос.
О, спасибо, было бы очень круто.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.