[Uladzimir 65]

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

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

 

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

Механизм Add Suplier Links это позволяет

[LeonY 0]

Есть. При создании базы указываются ссылки на 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 это позволяет", только я не понял, чем это может помочь в данной ситуации.

[Uladzimir 65]

100% адекватных замен" почти не бывает

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

есть в проекте компонент 7404 в корпусе DIP14, взят из библиотеки, все класс. Я, как разработчик, решаю, что меня в данном проекте также устроит 5404, 74HC04 и 74ACT04.

под условным обозначением компонента присобачить TextBox и в нем написать чего угодно (очень плохой)

согласен. Это не дает ничего для автоматического формирования BOM

в текстовых полях компонента написать чего мне хочется и сделать их Visible (плохой).

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

 

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

Правда она хороша, когда разнообразных замен немного

 

[LeonY 0]

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

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

согласен. Это не дает ничего для автоматического формирования BOM

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

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

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

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

Правда она хороша, когда разнообразных замен немного

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

[Uladzimir 65]

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

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

Ни сам компонент ни его футпринт, ни модели для симуляции не меняются.

Но возможно этого и достаточно.

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

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

 

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

 

 

Add Suplier Links позволяет ввести несколько ссылок на взаимозаменяемые элементы.

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

[LeonY 0]

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

Ни сам компонент ни его футпринт, ни модели для симуляции не меняются.

Но возможно этого и достаточно.

 

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

Это уже что-то. Сейчас начну задавать глупые вопросы:

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

 

    U1
+---------+
|         |
|         |
|         |
|         |
+---------+
abc123xyz
nkt785sdf-01
za0445fd

 

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

 

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

 

Ref |    Manuf.          |    Manuf.            |Comp.      |Qty.    |
Des |    PN              |                      |#          |        |
___________________________________________________________________
U1   abc123xyz            TI                    01123       1
     nkt785sdf-01         Fairchild Semi        56783
     za0445fd             LT                    90871
___________________________________________________________________

 

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

 

 

Add Suplier Links позволяет ввести несколько ссылок на взаимозаменяемые элементы.

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

 

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

 

[Uladzimir 65]

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

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

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

Будет, но такой:

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

 

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

 

[Буратино 0]

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

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

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

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

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

 

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

 

Либы должны смотреться так:

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

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

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

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

[Uladzimir 65]

Либы должны смотреться так:

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

Либы футпринтов как можно более структурированные но, как можно меньше в кол-ве.

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

 

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

2. Тоже с футпринтом.

3. Хранение библиотек-- разветвленное дерево папок.

 

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

[jkrieger 0]

2 Буратино

Если речь идет об общей библиотеке компонентов, то нужно определиться с целями.

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

 

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

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

 

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

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

 

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

 

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

принять "правила игры".

 

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

 

 

 

2 Master of Nature

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

 

 

UPD:

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

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

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

[Буратино 0]

Владимир, я считаю это вариант не очень правильный.

1. Дублирование информации (и достаточно массивоное кстати по объему дублирование)по схемным элементам,

2. Перспектива потерять целостность графики УГО компонента, ведь при таком подходе вариантов начертания резисторов будет до 1000 штук: кому-то ножки подлинее, кому-то змейка вместо прямоугольничка, кто-то линию красным кто-то черным поведет. Незя!

3. Невозможность контроля за кмпонентами, так как не будет центра в котором сосредоточена возможность проверки элемента/ов

4. Отсутствие возможности проводить групповые операции

5. Сложная структура дерева компонентов и массивное их физическое хранение.

6. Трудности с распространением информации, и синхронизацией.

7 Архивные срезы не представляю себе как делать!?

можно продолжать..

 

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

 

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

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

 

Jack Krieger, поймите необходима основа, фундамент для создания большой базы, но на песках дома не строят!

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

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

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

[Uladzimir 65]

1. нету дублирования.

2 Резистор как был один (для 2 выводов) для схемы так и остался один, нет необходимости множить

3. Какие ограничения контроля? открыл библиотеку с одним компонентом и контролируй, что хочется

4. Вот это самое лучшее. групповые операции в библах до добра не доводят. Тем более, что там оптом делать, если они проверенные?

5. Дерево- как кому нравится. Клавное за корень взял-- и все дерево в руках :)

6. Тут не трудности-- а легкости. Меняется только измененные маленькие библиотеки, а не одно на сотнимегобайт, при добавлении одного компонента. То же и синхронизацией.

7. Срезы архивные можно, но зачем? Ради боязни потери пры последних компонентов--- так их с базы и скачаь можно

 

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

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

 

что для УГО всех компонентов должна быть одна единственная библиотека

 

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

Ох как приятно по сети ее каждый день синхронизировать :(

 

 

 

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

Да нет, просто там, где за пакет платят деньги-- это редко востребовано.

Из моих знакомых ТАМ только 2 используют похожее.

Наиболее продвинутые это тут, на форуме :)

 

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

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

 

[Буратино 0]

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

Допустим у Вас есть несколько компонентов: Транзистор, резисторы разного номинала и типоразмера и трансформатор. Как вы планируете организовать хранение, обработку и обмен данными в своем варианте?

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

[Uladzimir 65]

1 1 библа с УГО транзистора

2. 1 библа с УГО резистора

3. 1. Библа с УГО трасфортматора.

4 сколько разных посадочных мест столько и библиотек под Footprint транзисторв резисторв трансформаторав

5. 1 или несколько баз для разных номиналов, проитзводителее и прочего

[Krys 2]

Принцип "сделать общую базу шоб надергать оттуда себе" отвергаю сразу

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

 

Так у пользователей не будет резона ее наполнять

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

 

 

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

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