cioma


Я лично прикрутил MySQL. Законной лицензии на MS Access нет и не будет: он нам попросту не нужен, и покупать резона нет. Есть лицензионный MS SQL Server, но, во-первых, он стоит на конторском сервере, а связь из дома (где я почти всю работу работаю) не шибко устойчивая, а во-вторых, это надо вникать в работу с ним, а с MySQL я пускай очень поверхностно, но уже знаком. Вот и развернул сервер у себя на компе. С PADS'ом, когда его мучил, работало без каких-либо проблем; сейчас уже создал и прикрутил базу к ЦБ, но пока ещё не настроил: занимаюсь упорядочиванием самой ЦБ

Кстати говоря, я посмотрел на структуру учебной ODBC-базы и увидел, что Part Number в ней не является уникальным. Получается, если добавляем на схему какой-нибудь, например, конденсатор, выбирая его по параметрам (ёмкость, напряжение, точность), то Part Number из соответствующей строки ODBC-базы с этими параметрами будет использоваться для поиска компонента уже в ЦБ, где Part Number уникален?

vitan
Соглашусь, что синхронизатора как "защиты от дурака" действительно не хватает. Хотя надеюсь, что MG со временем всё ж доведёт подобные мелочи до ума

Ещё один попутный вопрос возник. Когда создаю посадочное место (Cell), надо ли что-то делать в слое Placement Obstruct? Его назначение пока не совсем понятно, но впечатление такое, что в нём чертится замкнутый контур, внутри которого находится компонент, а другие компоненты не смогут вторгаться в эти границы. И, кстати, каково точное назначение контура в Placement Outline?


ADD. Попытался связать раздел библиотеки компонентов ЦБ с таблицей ODBC-базы: Insert Table на имени раздела, далее в появившемся окошке New напротив поля выбора Data Source (DSN), в открывшемся окне Data Source Manager -- Add и выбор моей ODBC-библиотеки (она подключена и работает). Вроде всё в порядке, имя библиотеки появляется в списке Data Source Names. Однако, когда нажимаю OK, в поле DSN этого имени нет, т.е. база как бы не выбралась. С чем это может быть связано?..

все хорошо описано в тренингах, в часности в Library Manager
Placement Obstruct – области, предотвращающие размещение других компонентов. Атрибуты включают сторону платы и ограничение по высоте.
Placement Outline – это посадочное место ячейки. У каждого контура может быть высота и расстояние до платы, которые используются при DRC. Для обозначения областей ячейки с разной высотой или расстоянием до платы может использоваться несколько контуров. Если не задано ни одного контура размещения, то он сгенерируется автоматически в виде прямоугольника, включающего в себя все контактные площадки в слое монтажа и сборочный контур. Сборочные контуры должны быть замкнутыми.

Local PDB создается и является, однако, частью проекта платы, но футпринты берет из ЦБ. В этом случае внутри ЦБ не нужны никакие PDB и символы, и она "вырождается" в "просто сборище футпринтов". Однако, если в ЦБ есть таки PDB (можно и без символов), и его имя соответствует имени компонента из нетлиста, то для этого компонента Local PDB не создается, предпочтение отдается PDB из ЦБ.
Что вам так не нравится ЦБ? по мне дак наоборот, очень удобно, все в одном месте, гораздо лучше, чем, например, в оркаде.

Гм. Давайте тогда проясним. Я всю жизнь считал, что PDB - это Project Data Base, и что она формируется при использовании DxD+Exp по технологии CDB. Т.е. PDB - это как бы CDB для конкретного проекта. Я правильно понимаю?
Если да, то вопрос: как может PDB быть внутри ЦБ?

При этом отдельный случай, вроде бы, состоял в том, что при использовании нетлиста, а не CDB, при упаковке все равно создавалась некая Local PDB (очевидно, потому что EXP не может совсем без PDB). Правильно?
Если правильно, то получается, что при работе с нетлистом УГО я могу-таки хранить в виде файлов на диске без ЦБ, а футпринты вынужден запихивать все-таки в ЦБ (я просто не помню, давно дело было). В этом случае такая ЦБ мало чем отличается от файлов на диске, ну можно сказать, что она вырождается в сборище футпринтов.

Это первое, что мне не понравилось. Не понравилось потому, что одной из главных причин перехода на DxD в свое время была его возможность работать с разными системами разводки "одновременно". Тогда мы часто отдавали разводку на сторону (эх, были времена ). Кто-то разводил в экспедишене, кто-то в падсе, а кто-то в аллегро. А ЦБ только для экспедишена. А её надо поддерживать, заботиться и все такое. На это времени нету, особенно глядя на другие редакторы PCB, которые спокойно обходятся без этой ЦБ. Вместо это силы тратятся на поддержку БД, что я считаю гораздо более правильным.

вообще то PDB это компаненты, которые получаются из Symbol и Cell


что значит ее поддерживать?

ЦБ DxD по сравнению с Pcad (в другом пакете не работал) небо и земля

Да, PDB это Part data Base, PDB= Symbol + Cell

Согласен с предыдущим оратором - с ЦБ гораздо удобнее...

Ага. Т.е. это просто другое название ЦБ (не имеет отношения к проекту, а вот Local PDB - это как раз база проекта?).


Ну вести ее, заносить туда все эти компоненты, УГО, символы, прописывать свойства. Если основная информация по этим вещам уже ведется в БД, то встает вопрос, зачем делать одно и то же два раза, причем только для Exp?

Нет. ЦБ - это целая библиотека. PDB - это в терминах пикада - компонент. Т.е. ссылка на символ, футпринт, свойства (properties).

Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

1. Посмотрите на рисунки и возможно начнете понимать структуру маршрута.

2. PDB - это сокращенное название компонента (Part Number).

PDB может быть полным, т.е. содержать ссылки на символ(ы), ячейку(и) и таблицу соответствия логических пинов физическим.
И не полным:
а) символ и таблица есть, а ячейки нет
б) ячейка и таблица есть, а символа нет
Неполный вариант а) используется для упаковки схемы без передачи ее на плату
Неполный вариант б) для создания платы на основе нетлиста, т.е. без схемы (DxD или DC).

Кроме того он может быть "сверх полным" - это когда к нему добавили еще и полный набор дополнительных атрибутов (типа Value и т.д)

Любая плата в Exp создается на основе ЦБ, т.к. из нее считывается:
- шаблон платы (layout template)
- стеки площадок (padstack)
- посадочные места (cell)
- компоненты (PDB)
Поэтому любая ЦБ обязана содержать все эти элементы - ну или как минимум шаблон, а падстеки и ячейки в принципе можно загрузить из сторонних файлов или создать внутри проекта платы (в локальной библиотеке). Но вариант работы с полноценной ЦБ намного удобнее, т.к. при прямой аннотации в локальную библиотеку платы автоматом считаются все нужные по списку соединений компоненты, ячейки, падстеки. Заметьте символы не считываются, они нужны только упаковщику схемы для проверки правильности применения символов для компонента.

Компонент (PDB) может содержаться в ЦБ, а может и отсутствовать - зависит от маршрута работы.

DxD-netlist-Exp:
Набора PDB нет в ЦБ. Т.к. файл со всеми нужными PDB создается упаковщиком из схемы и затем загружается в плату (в локальную библиотеку).
Неудобство: нужно всю упаковочную информацию с помощью набора атрибутов прописать на символах схемы.

DxD-iCDB-Exp:
Весь набор PDB в ЦБ. Упаковщик использует один единственный атрибут (Part Number) для поиска нужного PDB в ЦБ и считывания оттуда всей информации об упаковке и доп. атрибутах. И загружает эту информацию на схему (номера пинов + доп. атрибуты).

Соответственно получается в случае нетлиста значения доп. атрибутов нужно обязательно хранить в сторонней базе данных (DxDataBook).
В случае iCDB имеем два возможных варианта:
а) атрибуты внутри PDB.
б) атрибуты в сторонней базе данных.

Ах, вот оно что! Теперь все понятно. Кстати, не находите, что чересчур громкое название для компонента?

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


Я все понял, кроме этой фразы. Что же, без полноценной ЦБ при прямой аннотации компоненты, ячейки и падстеки не считываются? Т.е. Local PDB формируется на основе этих внешних файлов, а не напрямую их ЦБ? И чем это так не удобно? Тем, что в файлах проперти все не прописаны? Так мы же их из DxDataBook берем!

Опять вы ничего не поняли:
1. PDB+набор атрибутов это тот же компонент который вы получаете в случае DxDatabook. Просто у вас атрибуты хранятся в сторонней базе, а у большинства внутри компонента (PDB).

2. Полноценной подразумевает наличие этих элементов (PDBs, cells, padstacks) внутри ЦБ. Тогда они и считываются напрямую из ЦБ при прямой аннотации. Если же их нет в ЦБ то откуда должна программа аннотации их импортировать? Только из неких сторонних файлов (о которых я и упомянул). Причем делать это придется вручную через функцию импорта внешних данных, при этом загрузите кучу не нужного для этого конкретного проекта мусора или придется долго точно выбирать при импорте, какие конкретно нужны PDBs, cells, padstacks для импорта.

Хорошо, спрошу иначе.
Вот, человек работает с ЦБ и не понимает, зачем нужна БД:

Непонимание логично, т.к. Вы сами говорите, что:

Охотно верю, если в ЦБ все будет прописано, то, действительно все ОК. Только непонятно, что тов. SII даст использование DxDatabook, окромя тех самых кнопочек, и замены компонентов оптом. Т.е. какие еще атрибуты надо хранить в БД, и почему нельзя для этого использовать ту же ЦБ?

С другой стороны я работаю через нетлист.
Вы говорите:

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

Но затем Вы говорите:

Я думаю: отлично! У меня уже есть сторонняя БД, использую-ка я ее! Оказывается, что нужна еще и ЦБ, т.к. без неё Exp не работает.

Вот и получается: у кого нет БД, используют ЦБ. У кого есть БД, вынуждены вести еще и ЦБ. Зачем? Ведь Вы же сами сказали:

Если его нет в ЦБ и все создается само в Local PDB, зачем тогда ЦБ??? Чтобы Exp заработал? Замкнутый круг.


В конце концов, давайте спросим народ. Кто-нибудь работает одновременно с БД и ЦБ? В чем смысл и реальные плюсы такой работы? Какие параметры компонентов Вы храните в БД, а какие в ЦБ? Почему именно так?

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

Если ничего из перечисленного не надо, то она не нужна.



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

Уточните. Я могу вообще не открывать ЦБ, PDB, iCDB (и прочие бэ ), а брать и вводить атрибуты прямо в БД, что, действительно удобнее, особенно, когда есть клиент, а не таблица аксесса, прилинкованная к той же ЦБ?
Вряд ли! Иначе уже давно бы так делали. И никакого синхронизатора не надо было бы, т.к. не было бы самой ЦБ.
Т.е. ЦБ нужна. Скажите, пожалуйста, зачем?

Где по вашему хранится информация о графике посадочных мест, падстеков?

НУ!!! Я же этого и хочу, пусть так и будет. Только где здесь место для ЦБ?!


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

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

Хорошо пусть хранится где то просто в неких файлах на диске. Ну и как понять где что хранится, какие редакторы на что можно запустить, как взаимосвязаны все эти файлы?
Например я удаляю посадочное место, а может оно где-то используется? Я добавляю новый компонент\символ\ячейку, а может он уже где-то есть? Я изменяю имя пина на символе\ячейке, а может это приведет к конфликту, т.к. этот символ\ячейка применен в других компонентах? и т.д.
В ЦБ это все автоматически отслеживается.
Открыв ЦБ в LM я сразу вижу всю структуру данной ЦБ, сколько и каких разделов, сколько в каждом разделе элементов, как эти элементы связаны с другими элементами, сразу могу открыть их на редактирование в соответствующем редакторе и т.д. У меня может быть несколько ЦБ с разным содержанием и разными правилами.
Подключив конкретную ЦБ к проекту я фактически сразу определяю доступные для проекта данные и правила. Поменяв на другую ЦБ я фактически сразу переопределяю доступные для проекта данные и правила. В случае отдельных файлов придется подключать каждый по отдельности или изобретать некие конфиг. файлы содержащие списки, т.е. пойдем как раз в сторону создания ЦБ чтобы все это как-то упорядочить.

Элементарно! Если мы используем БД для компонентов, то никаких проблем использовать ее же для падстеков и прочего. Причем, само хранение можно организовать либо в файлах на диске, либо в файлах, закачанных внутрь СУБД (т.н. BLOB). Кстати, тот же ментор спокойно делает это в DMS.


Вы говорите о целостности данных. В любой СУБД это понятие гораздо более развито, чем в этой несчастной ЦБ. По сути, ЦБ в этом смысле и есть СУБД с сильно урезанной функциональностью. Поэтому снова тот же вопрос, но по-другому: зачем одновременно использовать две ипостаси одного и того же? Ладно бы сказали: либо ЦБ, либо СУБД (своя или DMS, не важно). Но нет, прикрутили дополнительно к ЦБ еще и СУБД и заставляют делать двойную работу, мотивируя удобством!

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


Да более того!
Вы говорите, что при упаковке создается эта Local PDB. Т.е. она есть принадлежность проекта. Вопрос: зачем беспокоиться о конфликтах и о том, что что-то будет удалено снаружи, кога упаковка уже прошла и мы спокойно разводим?
Я с аллегро работаю ровно так же: перед началом трассировки подгружается нетлист и компоненты (из файлов на диске, ессно). Как только они попадают в плату, они там сохраняются, и аллегро уже не шарится по библиотекам в поисках. Это логично и нормально, так работают многие программы. Exp не исключение, очевидно (т.к. есть Local PDB). Кэширование сильно облегчает жизнь, это ясно всем.
Так вот: я могу спокойно поменять в библиотеке все, что хочу, и связи в т.ч., но в моем текущем проекте все останется как было. И только, если захочу, нажму "обновить".
Т.о. ведение структуры и отслеживание целостности библиотеки - тоже нечто вроде самоцели, только уже для библиотекаря. А в реальности, будь там хоть все связано по рукам и ногам, но где-то закралась ошибка, то придется переделывать все проекты с ошибкой. А ЦБ - это не результат проекта, а всего лишь мера для повышения эффективности работы. Только в данном случае, оказывается, что не повышения, а понижения.

1. И при этом в DMS есть понятие Production Library - т.е. из DMS генерируется ЦБ которая и подключается к Exp.
2. В вашем случает проще остаться работать через нетлист.
Хотя внести PDB в ЦБ тоже не проблема, достаточно импортировать генерированный при упаковке (в варианте нетлиста) файл PDB.hkp в ЦБ. И получится что эти компоненты внесены в ЦБ (второй раз этого делать уже не надо). Ну а создавать посадочные места и падстеки в любом случае надо в ЦБ.
Зато при работе через CDB вам не придется на каждый новый символ\компонент добавлять:
DEVICE (Part Number)
#
PARTS
SIGNAL
PINSWAP
PKG_TYPE
HETERO
HETERO_SYMNAME

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

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


Нет уж, погодите! Получается, что для меня все преимущества iCDB перекрываются проблемой ведения ЦБ? Всё, тупик?


О, да! Только этот процесс займет еще три дня, а толку ноль: у меня и раньше было все, чтобы упаковаться и начать разводить.


Вы так и не ответили, почему так сделано? Почему Exp не читает непосредственно из файлов, как аллегро?


Да ну? А что же придется? Наматывать мышкой километры, нажимая кнопки в окошках, и вводя туда ту же информацию.
Ой, не факт, что это мне больше понравится!

Потому что считать\исправить одну ссылку гораздо проще чем сотню.

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

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

если вам нужны только cell - ну заведите ЦБ c только cell/
абстракции можете считать, что ЦБ - это просто удобный каталог для хранения. Ну или просто оболочка для менеджирования.
гораздо удобнее простого файлового менеджера.
Там нет ничего такого кардинально лишнего, что уменьшало бы производительность труда.

нееее, fill само спокойствие

Хм. По существу что-то можете сказать?


В том и дело, что могу, но не хочу. Понимаете, можно до бесконечности наворачивать уровни абстракции, лишь бы от этого была польза. Уже третий день пошел, а никто из прочитавших доки, в т.ч. и Сам fill так и не смог мне внятно ответить на простой вопрос: ЗАЧЕМ НУЖНА ЦБ? Особенно при работе с БД.

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

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

Нет, секундочку. У инжектора другие потребительские качества. Всем это понятно.
Хотите сказать, что наличие ЦБ улучшает производительность труда, избавляет от ошибок и т.п.?
Я Вам говорю: нет, и даже наоборот.

Почитайте пост 1868.

Повторяю, она только снижает эффективность моей работы (ПРИ НАЛИЧИИ БД), т.к.:
1. мне надо туда вносить данные. Это потеря времени. Сопровождается ошибками при конвертации.
2. Данные эти должны повторять их в БД.
3. Автоматической синхронизации с БД нет. Различия надо как-то отслеживать, либо вручную, либо писать кучу прог и скриптов и три года их отлаживать.
4. Результаты лежат в ЦБ в бинарном виде. Нигде более, кроме Exp не используются и не подлежат обработке простейшими скриптами проверки файлов.

Вывод. Работа по подготовке к разводке затягивается непонятно из-за чего. В реальности это вылилось у меня в то, что в Exp мы больше просто не разводим, точнее, не отдаем тем, кто в нем разводит. Долго они своих коней запрягают свои ЦБ настраивают.

работаю только с ЦБ и проблем НЕТ !!!
что там в ЦБ такое настраиватся, что разводка затягивается ???
поясните

если новый элемент то так и так его надо делать, и символ и посадочное и упаковку провести

Ух. Что-то утомился я уже пояснять. Неужели три предыдущие страницы не читали?


Надо. И упаковывать надо. И УГО надо. Только в ЦБ класть не надо.

Попробуйте поработать в PADS (в старом, в новый тоже уже лепят это чудо) или в аллегро. Там нет ЦБ. Могу поспорить на бочку пива, что при прочих равных условиях я начну разводить быстрее просто потому, что у меня не будет лишней операции по внесению корпусов в ЦБ. Я просто возьму их из файла.

А в файле они появились из воздуха?
Вы сделали их в каком то редакторе и сохранили в этот файл.
Мы сделали в редакторе встроенном в LM и сохранили соотвественно в эту открытую ЦБ.
Кол-во операций как минимум одинаково.
Вы говорите "возьму их из файла" - мы говорим система сама возьмет из ЦБ.

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

Соглашусь, что хранение этой информации в ЦБ не есть оптимальным, но это связано с историческими причинами. Конечно, было бы значительно удобнее и универсальнее, если бы распиновку тоже можно было хранить в сторонней БД, а не в ЦБ. Но мне кажется, что ментор врядли будет тратить на это время.

Т.е. редактор посадочных мест встроен в ЦБ и без нее мне посадочное место не отредактировать? Интересно...
А что делать, если мне пришел со стороны экспедишеновский файл, а мне надо на его основе сделать новую версию девайса, кое-что подправиви в компонентах? Опять старая песня? Экспортировать во вновь созданную персонально для этого случая ЦБ и там править?
Обратите внимание, что ЦБ повсюду фигурирует как некое промежуточное звено, которое явно просится быть сокращенным. Потому что, если бы были файлы (со всеми их плюсами), то был бы этот же редактор, только встроенный в Exp.
Если кто еще не понял: я хочу сказать, что все те действия, которые я могу делать в ЦБ я могу делать и без нее. Иначе я бы не имел кучу готовых проектов. Единственное, что эти проекты выполнены не в Exp.
Просто Вы не хотите признать, что Exp не работает без ЦБ по чисто историческим причинам, этот факт не имеет под собой каких-либо других причин.
А про эффективность работы при наличии БД я уже сказал, она только снижается. Жаль, что ментор этого не понимает.
Fill, а Вы можете привести какую-нибудь статистику, сколько юзеров работает в DxD-DxDB-iCDB-Exp, DxD-iCDB-Exp и DxD-netlist-Exp? Интересно было бы посмотреть... Понятно, что это не говорит не обо всем, но тем не менее...

Или забацать опрос? Точно, наверно, так и сделаю.


Ну вот, хоть кто-то понимает!


А такую ли уж огромную? Сколько у Вас таких символов, если не секрет? На ум приходит разве что УГО разъема, выполненное одним пином... Но ведь и скопировать файл под другим именем - секунда, а назначать новую распиновку - ровно столько же, что и в ЦБ... Не очень убедительно получается.

to vitan

"не работал, не понимаю, читать не хочу, но осуждаю, всё неправильно"
дискуссия не имеет никакого практического смысла.

Вы откуда такой вывод сделали? Поработал, не понравилось. Просто давно дело было, спросил кое-что для освежения памяти.
А Вы пробовали отказаться (с Вами-то есть о чем поговорить, или Вы теоретик, только с другой стороны)?

Создал опрос. Не проходите мимо!

Согласен - человек не попробовал сам другой вариант работы, и при это категорически не согласен с теми кто много лет работает по другому пути.

vitan - успокойтесь, в Exp вшит редактор PDB, cell и padstack. Так что можете редактировать в локальной библиотеке платы без наличия каких либо привычных вам отдельно стоящих файликов - редакторы запускаются изнутри ExpeditionPCB и видят только то что было когда-то загружено в локальную библиотеку этой платы.
Отдельный вопрос возникнет если вы захотите поменять схему соединений, внеся новые компоненты и соответственно переупаковать- здесь возможны разные варианты. Для меня проще создать новую ЦБ и импортировать туда все что нужно - решается за 10 минут. Вы видимо будете набивать все компоненты по новой в БД - это ваш выбор.


Кстати, не могли бы вы описать последовательность действий в случае Allegro. Вот я получил файл *.brd и как теперь увидеть\отредактировать его компоненты\посажочные места? В случае Exp я просто открою плату и выберу Setup>Part_Editor и в открывшемся окне редактора компонентов увижу все компоненты этой платы, и смогу их редактировать, для посадочных мест Setup>Cell_Editor ...
А в Allegro?

Расставим точки. Чтобы быть категорически не согласным, нужно видеть то, с чем ты не согласен. Я же просто не понимаю. Не буду повторять лишний раз, что именно. Это первое.
Второе: повторяю, этот вариант я пробовал. И мне он не понравился именно двойной работой. Я от него быстро отказался и почти забыл, пока тут не началось...


Отлично, я и так спокоен, ибо я давно не имею дела с Exp. Но что я слышу? Оказыватется, не обязательно запускать редактор футпринта из LM!
Самодостаточность ЦБ становится еще более очевидной! Точнее, она не нужна без Exp, a Exp не работает без нее. Я эту ситуацию не критикую, пожалуйста, работайте на здоровье, так во многих САПРах. Но когда есть БД со всеми необходимыми атрибутами мне становится непонятно, ЗАЧЕМ она нужна.


Ага. Т.е. это возможно? Возможно поменять компоненты и сделать новую плату без ЦБ, имея только БД, и не переключаясь на нетлист? Помните, в 2005 было так, что однажды включивши CDB назад уже не выключишь...


Примерно так же. Из платы экспортируются посадочные места и описания компонентов, правятся и обновляются. После правки у меня два варианта: или положить поправленный компонент в мою ЦБ (которая на основе файлов) и обновить компоненты в плате оттуда, либо просто подключить в аллегро новый путь поиска (каталог, в котором лежит экспортированный и поправленный компонент) с приоритетом выше, чем каталог моей ЦБ. И обновить опять же.

Стоп, откуда взялась БД вы же получили только проект в Exp?
И предположим тот кто рисовал этот проект не использовал БД, а все нужные атрибуты вводил внутри PDB, а вашей БД таких компонентов нет. В символы схемы не встроены атрибуты упаковки. Ну и что тогда? Как схему упаковывать то собираетесь?

Как откуда? Я же говорю: сижу, работаю. База рядом шуршит. Приносят. Говорят, поправь маленько, тут и так все стандартное, надо быстро сделать и КД выпустить. Хорошо, говорю, давайте (КД-то я умею быстро генерить благодаря той же базе). Беру проект и...


Это вы меня спрашиваете? Нет, это я Вас первым спросил. Похоже, что никак, все-таки. Потому что ЦБ и Exp неразлучны. И никуда от ЦБ не деться, будь у меня хоть все компоненты мира со всеми их свойствами и упаковочной информацией в базе прописаны.
Для порядка ответьте, пожалуйста, что будет, если компоненты в базе таки будут (если я их туда добавлю)?

Ну наконец-то: Т.е. экспортировать элементы платы в некую папку, чтобы затем произвести еще некоторое количество действий чтобы эта папка стала видимой редакторами вы считаете простым и быстрым путем. А выполнение одной команды экспорта в ЦБ очень сложной?
Собственно говоря вы сами наконец сказали что строите свою ЦБ но только в виде структурированного набора папок, каждую папку создавая в ручную. А LM делает тоже самое, но просто сразу создает структурированной набор стандартных разделов, которые потом наполняются уже нами в ручную нужными подразделами.
Вы подключаете папки чтобы увидеть их содержание, а мы одну ЦБ чтобы увидеть все ее содержание.



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

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


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


Ага, спасибо. Итак, если нету этой инфы, то каюк.
Вывод: ЦБ - это просто новый способ хранения информации о номерах выводов. Ничего более не дает (все остальное - мишура).
Объясните теперь, пожалуйста, зачем этот способ был создан, и чем он так более прогрессивен, нежели хранение в символах?

Всем добрый день.

Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю

В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым. А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? Вопрос пока больше академический: просто, вводя датафлэшку от Atmel, увидел, что она не только в 8-ножечном SOIC существует, но ещё и в ряде других корпусов с иным числом контактов. Получится ли в этом случае обойтись одним компонентом (чтобы на принципиальной схеме размещать именно его, а уже при размещении на плате выбирать нужный тип корпуса) или же придётся делать несколько компонентов с одинаковым символьным обозначением, но разными корпусами?

попробуй попровести дорожку например GND от элемента до плейна GND через via
после этого зальется


да


нет


нет


да
тем более в зависимости от корпуса PartNumber совершенно другой

Вот ведь!
Три дня мне все доказывали необходимость ЦБ, и этот пример был чуть ли не основным, а тут уже "нет"!

Вот исходный пост на эту тему и мое мнение ниже. Получается, что cioma противоречит Frederic-у...

Уважаемые экспедиторы (в смысле, те, кто разводит в Exp)! Просветите уж меня, беднягу! Я тут "докопался" к этой ЦБ не просто так. Я вижу, что Exp обладает хорошими инструментами в плане разводки, и мне не хотелось бы терять возможность разводить в Exp на стороне и получать высококачественные проекты. Но для этого мне надо понять, как мне вести мою собственную библиотеку. Пока я этого не понимаю и вижу, что при наличии БД будет только хуже (см. выше).

В моем опросе кто-то один уже успел отметиться во втором пункте (где DxD-iCDB-Exp + DxDataBook).
Особенно хотелось бы услышать мнение этого человека.
Ну и остальных прошу голосовать активнее!

противоречия нет
вентиль 2-or-no возможно использовать во многоих компанентах с различными корпусами и распиновкой
НО в одном компаненте не возможно провести одновременно упаковку с SOIC16 и BGA20 с номерами ног А1, В1.....
тем более в PartNunber уже прописан необходимый корпус

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

Приглашаю использовать Concept HDL от Cadence. Там это базовая возможность: один(несколько) символ(ов) - несколько упаковок - несколько корпусов, все это в рамках одного библиотечного компонента(там это называется cell). Кол-во ограничено фантазией создателя и способностью контролировать свое детище. Выбор символа/футпринта происходит автоматом при выборе соответствующего Part_Number при вставке в схему.
Правда vitan как-то объяснял, что все это ерунда, потому что не БД Ну видимо вопрос вкуса - мне ЭТО нужнее чем база...

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

Ок, тогда переходите в правильную ветку и там обсудим, куда и главное зачем(!) цеплять к телеге пятое колесо

Ну давайте.
Но что-то мне подсказывает, что переходить мне не захочется...