Доброго времени! Наткнулся на темы, где обсуждалась идея выкладывать 3D модели, библиотеки и прочие вкусности в открытый доступ, но так ничего там и не было вроде решено...
Предлагаю создать проект библиотеки, залить ее на какой либо SVN сервер и дружно ее дополнять новыми компонентами, 3D моделями и прочим.
Отписываемся за и против

Я, за, но
1. Я не нашел толковой доки как вообще с SVN работать в альтиуме. Так чтобы по-шагам, и так чтобы было очевидно что оно вообще надо, для тех кто системами контроля версий не пользовался вообще.
2. Часто компоненты создаются "под себя", под свое производство, или вообще, если я не собираюсь использовать АЦП в AVR, то зачем мне его рисовать?
3. Совместимость с ГОСТом. Кому-то это важно, а кому-то нет.

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

1. Зачем это ему? Денег от этого больше будет?
2. Очень смешно.
3. Утопия.

Единственный вариант, это просто поднять SVN, кто хочет, пользуется, кто не хочет, не пользуется.

Возможно, это даже излишне. Небольшая проверка (самим библиотекарем, конечно, не помешает, но без фанатизма. Почему? Потому что, например, меня жизнь научила не верить штампам типа "проверено, мин нет!". Я не поставлю в свой проект компонент, не проверив его лично. Даже если компонент брался из библиотеки, которую ведёт "правильный" библиотекарь у нас на работе. Мало ли что он там наглючил. Все компоненты надо проверять лично. Иначе можно вляпаться. А свалят всё на разработчика. Всегда есть отмазка "должен был проверить, убедиться...".

... А вообще, я где-то на этом форуме видел пользователя, у которого в подписи была ссылка на его сайт. Там уже реализуется такая идея с библиотеками. Если найду - сюда кину. Или он сам увидит, объявится.


Владимир всё правильно говорит, порядок не помешает.
1. Не всё делается ради денег. Например, мы тут FAQ пишем сообща... Да и сам модератор трудится бесплатно.
2. Скорее данный пункт большая утопия, чем п. 3 :)
3. Данный пункт затормозит обновление компонентов в библиотеке, пока пройдут все проверки... Типа "не куплю тебе фотоаппарат, пока не научишься фотографировать". Можно просто какой-то рейтинг сделать - сколько людей юзали данный компонент, какие были недостатки.

1 больше не будет, но без порядка--- только свалка. посто тоже что куча мегабайт родных библтотек
2 Может и смешно. Но сделайте опрос-- все (те кто работает постоянно) любят свои подходы, даже в мелочах. и мзменить их почти не возможно
3 Утопия. У меня несколько SVN библиотек от разных людей. Все они разные. и ими для себя не пользуюсь. Более того, практически и для создателей тоже не беру элементы, достаточно из проекта растирожировать

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

А может кто-то опишет, в картинках и на русском как с SVN в альтиуме работать?

да как и с базой данных. Отличие только в способе хранения данных, а не работе.
в 2008 летом писал.

Имхо, идеален был бы аналог www.3dcontentcentral.com , только для библиотек пакета "икс". Правильно?

Я про "по шагам". Начиная от создания проекта, создание интегрейтед лайбрали, экспорт всего этого в SVN, коммиты, как свети две версии итд.

Идея, конечно, интересная.
Остался вопрос за реализацией.
Попробую с вышеуказанной библиотекой поработать.
Если получится, то этот проект можно взять за основу.

Так вот откуда 27 посещений в день, а я-то думал =)

Я очень рад, что вам небезынтересны идеи некой общей библиотеки, разрабатываемой и наполняемой целым коммьюнити. Мне кажется из этого могло бы что-нибудь получиться. Собственно для этого и был создан проект Common Altium Library.

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

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

Итак, попробую поделиться своими соображениями по проекту 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

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

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

1. Можно. Но тогда это "даташит " должно быть прописано в библиотеке. А если ссылка не на даташит?
2. В частности. Никаких прелестей. Просто там в текстом написан тип компонента и ОСНОВНЫЕ параметры. Как правило этого и достаточно, чтоб вводить затем для параметров отдельные поля
3. Хватит--- просто ссылка тоже на уникальный заводской номер. По нему уже можно подключить любые складские параметры
4. смю 2


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

Хватит одного поля.
А туда можно писать либо номенклатурный номер, либо адрес в виде
[<стеллаж>,<ячейка>]
либо кому как удобнее.

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

Для основной подсказки используется параметр 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.

1. Хм... в резисторах в поле Package типоразмер итак указан в дюймовых обозначениях. Если вы за Part Number, то там сейчас там внесено то же что и в Manufacturer Number.
2. какой шрифт считать стандартным? Arial? И не лучше ли, если я выложу рядом шрифты ГОСТ, которые в библиотеке используются?
3. за это замечание спасибо. попробую выставить. хотя когда я хотел установить выравнивание надписей от центра, у меня не получилось. все равно влево выравнивались надписи.

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

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

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

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

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

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 я не знал. Разберусь где их менять и поправлю.


Library path и Footprint Path считаю лишним. Пути для поиска моделей задаются в свойствах библиотеки.
Designator идет из УГО. Разве нужно его дополнительно задавать?

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

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

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

Для наполнения библиотеки: держатели SIM-карт (3 типа)
Схемное обозначение требует переработки.
Привожу его для простоты применения посадочных мест (назначение выводов)
Дополнительно загружаю отдельные STEP-модели.

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

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

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

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

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

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

Вот только еще такая интересная деталь: есть компоненты частично-совместимые (блоки питания, драйверы 232, память и т.п.).
в том числе созданные под pin-to-pin, но с урезанием возможностей.
Для них разработчик уже сам должен решать степень совместимости данных компонентов для изделия.

Могу еще такой пример привести: DS3231, DS3232, DS32B35
У первой мсх ног меньше, но она может использоваться вместо двух других, если нужны только часы.
В то же время, чтобы использовать вместо второй - первую или третью нужно изначально заложить увеличенный футпринт.

Есть. При создании базы указываются ссылки на 100% адекватную замену.

остальное только в схеме. Так как где-то замена допустима, а где-то ни как, и это может знать только разработчик
Механизм Add Suplier Links это позволяет

Не понял...

"100% адекватных замен" почти не бывает, поэтому возможные замены всегда остаются на совести разработчика. Давайте отвлечемся от их 100%-ности (Игра "найди 10 отличий").

"остальное только в схеме" - что-бы это значило? Если речь идет о "грубом ломании" - то это неинтересно, тут и идей никаких не надо. Поясню что именно я имею ввиду под "грубым ломанием" - есть в проекте компонент 7404 в корпусе DIP14, взят из библиотеки, все класс. Я, как разработчик, решаю, что меня в данном проекте также устроит 5404, 74HC04 и 74ACT04. При "грубом ломании" я вижу 2 способа отобразить это на схеме (один плохой, второй очень плохой): под условным обозначением компонента присобачить TextBox и в нем написать чего угодно (очень плохой) или в текстовых полях компонента написать чего мне хочется и сделать их Visible (плохой). На распечатаной схеме все будет OK, при этом CAD нифига не будет знать о моих глубоких измышлениях и во все Downstream Tools & Docs будут передаваться параметры только оригинального 7404 (как пример Downstream Tools можно привести симуляцию в HyperLynx или Spice, куда благополучно будут передаваться неправильные модели для всех компонентов кроме одного. Ну а про документы и говорить не стоит - в перечень элементов пойдет только один, тот самый 7404, все остальное будет проигнорировано, расчеты потребления, надежности неверны и т.д и т.п.).

"Механизм Add Suplier Links это позволяет", только я не понял, чем это может помочь в данной ситуации.

Ну пассивные элементы (резисторы) почти всегда

согласен. Это не дает ничего для автоматического формирования BOM
получше. Только писать самому в исключительных случаях, а добавлять параметры через Add Suplier Links

Ну про третий вы забыли. он требует больших затрат времени. Опция Variant. Она лучшая из всего. И в последней версии пакета получила большее развитие в удобстве работы с ней.
Правда она хороша, когда разнообразных замен немного

ну это мы уже обсудили - совместимость оставим разработчику...

и не только BOM. про симуляцию я уже писал, и этот путь скажется отрицательно на всех Downstream операциях

а можно подробней про Add Suplier Links - как это может решить проблему???

Не решение!!! я имею ввиду случай, когда замена компонента не порождает новый Variant, т.к. все замены "равноценны", и что именно ставить не есть проблема разработчика, а производства, точнее - снабженцев

Для симуляции надо думать. Формально это дает только автоматический ввод ссылок на название компонента, производителя, поставщика и т.п. что доступно в базе Suplier.
Ни сам компонент ни его футпринт, ни модели для симуляции не меняются.
Но возможно этого и достаточно.

Если замены равнозначны -- Add Suplier Links достаточно.

Но вот вариант например замены LDO подстраиваемого стабилизатора с двумя резисторами, на LDO стабилизатора на фиксированное напряжение с одним резистором 0 Ом в обратной связи и вторым не устанавливаемым-- только через варианты


Add Suplier Links позволяет ввести несколько ссылок на взаимозаменяемые элементы.
При этом порождаются куча параметров, таких как Supplier 1, Supplier Part Number 1, Vendor 1, Supplier Part Number 1 и так далее. При формировании Bom видна замена, если она допустима

Это уже что-то. Сейчас начну задавать глупые вопросы:
- можно ли получить на схеме (автоматом, внеся "праильные" Links) с помощью Add Suplier Links что-то подобое? :



где U1 - элемент; abc123xyz, nkt785sdf-01, za0445fd - эквивалентные замены (предполагаем, что SCH Symbol & PCB Footprint одни и те же для всех замен)

- будет ли генерироваться автоматически BOM, похожий на картинку ниже?:





ну это типичный пример Variant

Сам текст можно. Графическое расположение только автомат установки относительно изображения. Соответственно может текст "налезть" на иное графическое изображение-- то есть просматривать, и в случае необходимости редактировать положение надписей нужно

Будет, но такой:
Ref | Manuf. | Manuf. |Comp. |Qty.| Manuf.1 | Manuf. 1 |Comp. 2 | Manuf. 2 | Manuf.2 |Comp. 2 |
Des | PN | |# | | PN | | | PN | |# |
___________________________________________________________________
U1 abc123xyz TI 01123 1 nkt785sdf-01 Fairchild Semi 56783 za0445fd LT 90871

Сделать такой как на картинке-- это макрос в экселе

Если речь идет об общей библиотеке компонентов, то нужно определиться с целями. Как мне показалось цель в том, чтобы ускорить и облегчить разработку PCB. Это самое главное и ценное в подобном проекте. То есть, нужны компоненты, футпринты, схемные изображения новых/отсутствующих элементов на схемах/платах. Необходимо экономить время на создание элементов! Правильно я понимаю задачу?
Если так. то для того чтобы все это ожило и работало необходимо чтобы такая база подходила всем, и что самое главное чтобы люди могли базу наполнять. Не без участия заинтересованых и контролирующих лиц естесна.
Уже сам факт наличия лишней для пользователя информации (например инфа для симуляции, склады, остатки, ссылки на даташиты и т.д.) может отпугнуть половину гипотетических пользователей. А вторая половине не сможет дождаться готового решения в связи с критически противоречивыми требованиями к такой системе, а также сложностями в реализации.
И поэтому я считаю, что правильно делать базу компонентов с минимальным "обвесом" и откатаной возможностью импорта экспорта компонента/схематика/футпринта.
В идеале такая программа должна конектится к базе в интернете.

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

Либы должны смотреться так:
Для схемных обозначений всего одна библиотека, так как нет необходимости по тридцать раз перерисовывать npn транзистор, а также для удобной групповой перерисовки всех компонентов под стандарты предприятия.
Либы футпринтов как можно более структурированные но, как можно меньше в кол-ве. Строго регламентировать схемные изображения и модели футпринтов. Вплоть до толщины линии. Опять же в сл. крайней необходимости можно будет в групповом режиме менять свойства моделей. Но в целом общий знаменатель быть обязан. Если все это будет смотреться как парламент Украины, в минуты голосования по важным законопроектам, то дела не будет. Факт.
Связывается и распространяется все это в формате DbLib, а на месте может быть перепаковано в интегрированные библиотеки при необходимости либо по привычке.

Если для всех - негодится. Всякий влезший в библу может испоканить другой компонент.

1. Каждому изображению компонента - своя библа с одним компонентом.
2. Тоже с футпринтом.
3. Хранение библиотек-- разветвленное дерево папок.

В этом случае портится только один элемент, а то и вообще реад-онли можно поставить файлам

2 Буратино

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


Категорически не соглашусь с тем, что модели для симуляции и ссылка на даташит от производителя лишние. Для меня например наличие моделей симуляции было бы одной из фишек такой базы. Что до остального, то этого не будет. Предположительно связь с "местными" базами предприятия будет осуществляться по одному из полей, скорее всего Part Number (я сейчас вижу именно таким образом).


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

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

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

Добавление компонентов я вижу через формы Access или Google Docs с последующей проверкой Библиотекарем. Я сейчас мучаю новую базу, где будет меньше лишней информации, но больше таблиц. И тут я надеюсь лично на вашу, Буратино, помощь. Вы вроде разбираетесь в MS Access.



2 Master of Nature
Не понимаю почему у вас не отображается предпросмотр. Возможно у нас где то разные настройки AD. Мне не хочется вводить поля путей к файлам. Кроме того я понял как избавиться от поля SIM File. Давайте как-нибудь разберемся с этим вопросом в ПМ.


UPD:

Полностью поддерживаю. В качестве "первой ласточки" предлагаю придерживаться соглашениям об именовании футпринтов и пинов, которые доступны на сайте AD.

Владимир, я считаю это вариант не очень правильный.
1. Дублирование информации (и достаточно массивоное кстати по объему дублирование)по схемным элементам,
2. Перспектива потерять целостность графики УГО компонента, ведь при таком подходе вариантов начертания резисторов будет до 1000 штук: кому-то ножки подлинее, кому-то змейка вместо прямоугольничка, кто-то линию красным кто-то черным поведет. Незя!
3. Невозможность контроля за кмпонентами, так как не будет центра в котором сосредоточена возможность проверки элемента/ов
4. Отсутствие возможности проводить групповые операции
5. Сложная структура дерева компонентов и массивное их физическое хранение.
6. Трудности с распространением информации, и синхронизацией.
7 Архивные срезы не представляю себе как делать!?
можно продолжать..

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

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

Jack Krieger, поймите необходима основа, фундамент для создания большой базы, но на песках дома не строят!
Без широкой поддержки пользователей которым необходимо "надергать компонентов" вы не получите плацдарм для дальнейших работ. Нужен скелет, качественный, продуманый остов, на который потом можно нанизать "мяса":) Сори, голоден аки собака (диета млин)
Немаловажным обстоятельством в работе с программой, является тот факт, что у Альтиума не все хорошо с DBLib. Есть очень серьезные траблы, при этом был бы я связан с разработчиками их можно было бы порешить в течении дня. Видимо сами создатели не до конца оценили потенциал баз данных в связке с либами и соответственно не уделили должного внимания вопросу.

1. нету дублирования.
2 Резистор как был один (для 2 выводов) для схемы так и остался один, нет необходимости множить
3. Какие ограничения контроля? открыл библиотеку с одним компонентом и контролируй, что хочется
4. Вот это самое лучшее. групповые операции в библах до добра не доводят. Тем более, что там оптом делать, если они проверенные?
5. Дерево- как кому нравится. Клавное за корень взял-- и все дерево в руках
6. Тут не трудности-- а легкости. Меняется только измененные маленькие библиотеки, а не одно на сотнимегобайт, при добавлении одного компонента. То же и синхронизацией.
7. Срезы архивные можно, но зачем? Ради боязни потери пры последних компонентов--- так их с базы и скачаь можно


Если мы имеем ввиду одно и тоже-- то как был один символ УГО так и остался



Если я соберу все свои УГО -- библа вырастет мег этак наверно под 50.
Ох как приятно по сети ее каждый день синхронизировать




Да нет, просто там, где за пакет платят деньги-- это редко востребовано.
Из моих знакомых ТАМ только 2 используют похожее.
Наиболее продвинутые это тут, на форуме


Зачем придумывать. Нужно придерживаться того, как LP Wizadr делает

Владимир, специфика интернет общения, накладывает определенные тени на смысловые линии собеседника. Я прошу прощения, если не верно Вас понял, и если можно ответьте на уточняющий вопрос:
Допустим у Вас есть несколько компонентов: Транзистор, резисторы разного номинала и типоразмера и трансформатор. Как вы планируете организовать хранение, обработку и обмен данными в своем варианте?

1 1 библа с УГО транзистора
2. 1 библа с УГО резистора
3. 1. Библа с УГО трасфортматора.
4 сколько разных посадочных мест столько и библиотек под Footprint транзисторв резисторв трансформаторав
5. 1 или несколько баз для разных номиналов, проитзводителее и прочего

А если я лично для себя и своих разработок согласен только на вариант "надёргать". И по разным соображениям (в т.ч. "по идеологическим убеждениям") не готов "пользоваться базой как основной"? Тогда я пролетаю? А сколько таких как я? Я думаю, такой строгий принцип оттолкнёт огромный процент людей от пользования базой. А тогда для кого вообще стараться? Для узкого круга "спецов"?

Давайте ещё и рейтинг введём, как на torrent трекерах. Там рейтинг вынуждает наполнять.


Ну это Вы слишком строго. Альтруизм должен быть альтруистичным до конца.

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

Давайте обсудим эту разницу в подходах,
Что даст разделение библиотек для компонентов? Какие плюсы? Мне нравится в этой идее простота распространения компонентов на чисто физ. уровне, ведь в таком случае будет передаваться только тот компонент в котором нуждается разработчик, но мне не ясно как он (разработчик) будет интегрировать в свою базу полученные файлы? Также не ясно почему Вы говорите о том ,что групповые операции зло, ведь благодаря такой возможности можно будет привлечь пользователей, которым нужен ГОСТ, другие стандарты в изображении графики УГО/начертания футпринта! (я имею в виду возможность менять параметры моделей для всей(всех) компонентов одновременно)
Где и как вести дерево компонентов? Средствами файловой системы, либо все библиотеЧки свалены в одну/несколько папок а в самой программе ведется иерархия компонентов?
Как и откуда компоненты будут стаскиваться на схему?

+1

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

Для ГОСТ, если нужно -- делать альтернативные изображения. Никто не мешает.
Хотя честно говоря в большинстве случаев годятся общие

Как кому нравится. Деревья могут не совладать, Можно и в кучу свалить.
Главное чтоб изображения (файлы) не дублировались
Файлы прекрасно находятся, если указана опция поиска в папке, и во всех вложенных папках.
При этом в записях базы ничего менять не нужно

Если работа ведется через базу данных, то не имеет значения в скольки файлах находятся УГО - в одно или в -дцати. Но с точки контроля целостности и контроля версий - проще синхронизировать, если в каждом файле по одному УГО (футпринту), не надо мучаться и сравнивать каждый компонент - достаточно сравнить, например, время создания.

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

Поэтому предлагаю такой вариант заполнения полей:
HelpURL - относительная ссылка на основной datasheet к источнику с определенной структурой
ComponentLink1URL - ссылка на страничку на сайте изготовителя/разработчика данного компонента.
ComponentLink2URL - ссылка на основной datasheet на оф.сайте (если есть)

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

+1 +1 +1 По всем пунктам

В принципе согласен. Только назначение ComponentLink1URL ComponentLink2URL поменял бы местами. Главное все же даташит

Ну без разницы платный бесплатный-- все равно качать. а таких хранилищ в инете достаточно

Тут вопрос не в платности, конечно, а в том, чтобы простую структуру размещения документации можно было сделать, чтобы без труда ее дублировать на локальном компьютере, не пользуясь поднятием локальных серверов и правкой HOSTS