[Буратино 0]

Ничего не понял:(

Владимир, как именно вы выбираете и вставляете на схему компоненты из DBLib? Какое именно окно в этот момент у вас открыто?

Я работаю с окном Librares, при этом в списке выбрана именно DBLIb.

 

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

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

 

Я стараюсь быть как можно предметнее в этой дискуссии. Владимир, какая разница "лапастый" компонент или нет, речь о том сколько занимает места либа с 10ю одинаковых компонентов и сколько 10 отдельных с таким -же компонентом.

Хорошо, я проверю сам. Дело в том, что это оч. важно а особенно на данном этапе обсуждения.

Изменено 21 сентября, 2010 пользователем Буратино

[Uladzimir 73]

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

Возможно. Не заметил. Возможно разветвленность не достаточная :)

Я тоже за хранение даташитов локально, рядом с базой.

Полезное дело. Из доступных мне--- так и делается. Как правило для специфических компонентов

Рассмотрим строение одной БД (например транзисторы).

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

В ней есть таблица корпусов Packages с полями:

Я бы только таблицу с симуляцией отдельно давал. уж больно она специфическая и не так востребовано,

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

Замечательно

3. Возможно (пока не реализовал), облегчится добавление нового компонента в базу через форму.

Очень сильно облегчится :) пользуюсь

 

Ничего не понял :(

Владимир, как именно вы выбираете и вставляете на схему компоненты из DBLib? Какое именно окно в этот момент у вас открыто?

Я работаю с окном Librares, при этом в списке выбрана именно DBLIb.

 

и я также

[Буратино 0]

 

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

 

 

и я также

 

а путь к корневой папке прописываете тут?

Когда тащите компонент на схему нет тормозов?

Правильно ли я понял, что в самих таблицах Акцесса/екселя у Вас нет никаких путей?

Изменено 21 сентября, 2010 пользователем Буратино

[jkrieger 0]

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

Я почему так предлагаю. В случае разделения по разным базам в АД библиотеки выглядят как Reistors - Axial, Resistors - SMD, Transistors - NPN, и т.п как на картинке.

Мне кажется, что так больше степень свободы при выборе компонента, нежели чем если будет ACL- Transistors, ACL - Resistors. Кто как считает?

 

Я бы только таблицу с симуляцией отдельно давал. уж больно она специфическая и не так востребовано,

Вы тоже считаете что симуляция невостребована?

 

[Uladzimir 73]

Я почему так предлагаю. В случае разделения по разным базам в АД библиотеки выглядят как Reistors - Axial, Resistors - SMD, Transistors - NPN, и т.п как на картинке.

 

Мне кажется, что так больше степень свободы при выборе компонента, нежели чем если будет ACL- Transistors, ACL - Resistors. Кто как считает?

 

 

Вы тоже считаете что симуляция невостребована?

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

Достаточно в строке поиска набрать типа 0805-- и список в окне резко ограничивается.

А так окно с перечнем табличных библиотек за горизонт улетит.

Но все виды нужно ограничится максимум 2 десятками таблиц

 

Симуляция востребована. Но она нужна в 1% случаев.

 

а путь к корневой папке прописываете тут?

Когда тащите компонент на схему нет тормозов?

Правильно ли я понял, что в самих таблицах Акцесса/екселя у Вас нет никаких путей?

 

Нет. тут прописываются ссылки на просто библиотеки, база из которых частный случай

Открываете ссылку на базу *.DbLib

Tool/Option/Symbol&madrl Patch Search

 

То есть для каждой базы прописываются свои пути поиска

[Krys 2]

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

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

1. Я (имеется в виду собирательный образ таких как я) могу свободно добавлять в базу свои компоненты, которыми я в последствии буду пользоваться. Свободно - это значит без временных задержек и с минимальным гимором, по трудоёмкости сравнимым с созданием библиотек локально.

2. Естественно, что каждый компонент перед вставлением в свою схему я буду проверять, т.к. схема (и плата) - это моя ответственность полностью. Так вот, здесь я должен быть уверен, что после того, как я проверил компонент, его больше никто не изменял. А если и изменял - это должно сразу отображаться при любом обращении. Это нужно, чтобы не получилось, что после автоматического апдейта из библиотек (предполагая, что библиотека проверена) какой-либо компонент изменился, и всё встало раком. После каждого апдейта из общей библиотеки нет желания всё сверять заново.

 

[masterofnature 0]

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

Требования противоречат друг-другу.

 

Предлагаю: Есть один (или несколько) ответственный библиотекарь.

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

 

Вы же, для уменьшения ожидания, можете сделать следующее:

сделать уго, футпринт, связать их локально и вставить в схему.

их же отправляете к библиотекарю на проверку.

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

[Uladzimir 73]

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

Но вот в основной базе и самих библиотеках следует иметь три поля. Дата модификации, кто автор, кто проверил или счетчик кто пользовался и прошло без замечаний.

Хотя может и брюзжю :)

[Буратино 0]

Владимир, так в самих таблицах акцеса, нет никаких путей? Полей, в которых хранится информация о расположении УГО и футпринта- нет?

[Uladzimir 73]

можно задавать пути не посредственно в базе.

А можно не задавать, а только указать в DbLib пути, где она будет искать УГО и Footprint

 

В общем я за второй путь. Он гибче

[jkrieger 0]

2 Krys:

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

 

2 Буратино:

Ответы на многие ваши вопросы можно найти в статьях Linking a Simulation Model to a Schematic Component, и Using Components Directly from Your Company Database.

[Буратино 0]

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

Программа формирует таблицы в акцессе. на их основании строятся запросы. В Альтиум передается все с доп. информацией, по которой я строю подобие дерева в Libraries

Я веду три либы: схемную, футпринтов и DBLib. Мне так удобнее. Все компоненты делаю с нуля. Так правильнее.

 

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

 

Но для оформление моих соображений в один пакет - изложу свои взгляды с учетом поправок внесенных в этом топике:

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

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

Написанная программа сканирует это дерево и интерпретирует результаты в удобном для пользователя виде. Это дает возможность пользователю связать модели в компонент, а сама программа должна, основываясь на этих связях, построить наборы выходных таблиц/запросов для АЛьтиума. Очень важным является создание уникального и правильного ключа, для связи базы с будущим "обвесом", и в связи с этим рождается необходимость помимо моделей вести еще одну сущность - уникальный ключ компонента и связь моделей. Без этого будет необходимо для каждых скачанных компонентов заново создавать эту связь в ПО. А без ключа работа по добавлению/исправлению информации к существующим компонентам у одного автора никак не сможет быть "портирована" в базы других пользователей.

 

 

 

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

 

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

Изменено 22 сентября, 2010 пользователем Буратино

[jkrieger 0]

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

 

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

 

Больше всего меня в таком случае волнует процедура добавления компонентов. Так как вначале она будет все равно происходить локально, в свои базы. А потом добавляться вот в общую. Как избежать дублирования? Как вариант можно испльзовать в качестве ключа комбинацию полей 'Manufacturer' + 'Manufacturer Number'. Она будет всегда уникальна.

 

Какие вообще соображения на это счет?

[Uladzimir 73]

Можно.

Но в Access для ключа есть функция запрет от повтора. Я пользуюсь. Уж сколько раз хотел обозвать одинаково--не дает

Для комбинации полей такой возможности нет

 

Хотя конечно специальное поле для ключа с одной стороны избыточно

 

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

Этого следовало ожидать. сколько людей-- столько мнений.

Такие вопросы уж лет 20 постоянно поднимаются.

 

В первую очередь нужно делать не для всех, а для себя.

А уж если хорошо получится-- тут все будут подстраиваться под хорошее.

 

Среди параметров нужно думать и об автоматическом формировании перечня. Кстати не только к схеме, но самое главное к PCB

[jkrieger 0]

2 Владимир:

Да сложно ведь одному-то =) Особенно когда практики мало. Вот и хотелось как нибудь так чтоб сообща.

 

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

 

Сейчас я приведу полный перечень полей, которые будут храниться в базе. Их необходимо разделить на поля относящиеся к конкретному компоненту, поля. относящиеся к корпусу. и поля симуляции. Возможно нужно вынести в отдельную таблицу еще какие-то поля. Пока не знаю. Итак:

 

Поля компонента:

 

Manufacturer Number

Manufacturer

Description

Help URL (ссылка даташит локальный или на сайте производителя)

ComponentURL1 (на всякий случай)

ComponentURL2 (на всякий случай)

ComponentURLDescription1

ComponentURLDescription2

Comment

Component Type (объясните пожалуйста, что это такое)

Mode (на всякий случай, может не нужно)

Package - поле связано с ключом в таблице корпусов

SIM Model Name - поле связанное с ключом в таблице моделей симуляции

SIM Parameters

SIM Port Map

SIM Excluded Parts

 

Поля корпуса:

 

Package - ключ

Footprint Ref

...

Footprint Ref 4

Pin Count

Power Dissipation

Package Decription (надо ли?)

 

Поля моделирования:

 

SIM model Name - ключ

SIM Kind

SIM SubKind

SIM Spice Prefix

SIM Netlist

SIM Description

 

 

Что по вашему нужно добавить, что выбросить?

Изменено 22 сентября, 2010 пользователем Jack Krieger