Поищите - уже не раз подробно обсуждалось.
В 2007 отдельно генерируются только негативные плейн. Если в Plane_Assignments стоит Dynamic и в DC включено Plane Data и Fill\hatch , то заливки позитивов отображаются автоматом.

Трудно говорить с человек уже давно сделавшим какие-то выводы и не слушающим собеседников. И приводящий некие измышления про операции, занимающие у меня несколько минут, как операции на несколько дней кропотливого труда. Попробуйте для начала, а уж потом делайте конкретные выводы с цифрами.
Я вообще могу ничего никуда не экспортировать, а редактировать прямо в базе платы. Как и экспортировать прямо в основную ЦБ - но обычно это не делаю чтобы не бороться с проблемами несовместимости моего представления о компонентах со сторонними представлениями, и т.к. ЦБ не дает создавать того бардака который обычно я вижу в случае импорта так называемых библиотек OrCAD или PCAD, когда в их библиотеках встречается куча элементов с одинаковыми именами но разными номерами пинов, количеством пинов, именами пинов - я обычно импортирую весь этот винигрет в специально созданную временную ЦБ.



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



Символ использован во множестве компонентов:
Нажмите для просмотра прикрепленного файла
В каждом из компонентов свои номера пинов, например:
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

В вашем случае наплодите символов под каждый такой компонент.
Если нужно будет изменить что-то внутри символа, то мы изменим в одном месте и это коснется всех компонентов, вам придется редактировать каждый.
Также заметьте, что в БД под каждый такой компонент вам придется ввести по 3 строчки.

Извините, пожалуйста, но я уже третий раз повторяю: Я ПРОБОВАЛ. И слушаю я очень внимательно, видимо, в отличие от Вас (Вы первые два раза, очевидно, не услышали).


Стоп, получается, возможно поправить проект в Exp, не имея ЦБ? Трудно было сразу об этом сказать???


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


Это понятно, Вы могли бы и не расписывать. Я бы на Вашем месте делал бы точно так же, мы ведь не об этом говорим!


Я так и думал, что будет приведен подобный пример.
Разберем его подробнее.
Вы показали УГО для элемента ИЛИ. Сколько таких элементов будет в ходу на предприятии? Не много, поверьте. Обычно даже вводят специальные ограничительные перечни по элементной базе. Это первое.
Вы говорите: надо будет плодить УГО и потом по-отдельности расставлять пины. А у Вас, мол, все доступно из единого места.
Ну и что? Плодить - это в моем случае копировать файлы. Секунда.
Расставлять пины. Хотите сказать, что у Вас есть секретный способ выставить распиновку одновременно для всех приведенных Вами в примере компонентов? Слабо верится. А если нет, то Вам так же придется по очереди тыкать в компонент и править распиновку. Затраты времени, как минимум те же.
Поэтому, когда Вы говорите:

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

Странно, что Вы не привели пример с УГО разъема (один пин), о котором я сам же и говорил. Вот там применяемость может быть гораздо шире.

Но, если вернуться к главному вопросу, получается, что только из-за этого и была создана ЦБ? Чтобы просто не копировать файлы с УГО по диску? Очень спорное решение. Если бы у меня был выбор между такой возможностью экономии и хранением в виде файлов, я бы выбрал файлы, т.к. их можно обрабатывать гораздо более широким набором софта, а не только редактором ЦБ.
Или есть еще причины?

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

А затем еще начинаете разглагольствовать о двойном импорте\экспорте - я где нибудь об этом говорил?
3. В показанных PDB распиновка делается всего один раз, только для одного символа - остальные пользуются той же таблицей автоматом. Т.е. я ввожу один раз вы 3.
Кроме того при вводе в левой колонке отображаются все не присвоенные номера с корпуса, поэтому:
- сразу вижу какие номера еще остались в списке слева
- не могу сделать ошибку и дважды ввести один и тот же номер
- могу просто выбрать номера в списке слева (сразу все или группу) и скопом присвоить - перетащить слева направо.
4. Все время говорите о двойной работе при этом никак не можете точно сформулировать в чем же она заключается.
Я вам уже несколько раз пытался объяснить простую вещь:
- рисуете символ (без атрибутов) и корпус (если его нет)
- вводите PDB в который импортируете этот символ и корпус (при этом если на символе есть номера пинов, то таблица соответствия заполнится автоматом этими номерами) заполняете\дополняете таблицу соответствия номеров.
- в БД вводите атрибуты (или вводите их в PDB - как хотите) - в данном случае нужны только те атрибуты которые нужны вам для поиска по параметрам и оформления BOM.
Все, ну и где здесь двойная работа?
Не хотите так работать как мы, так продолжайте через нетлист, какие проблемы?
5. Опрос затеянный вами покажет только то, что большинство пользователей перешедших с DC\DV продолжают пользоваться тем же набором средств какие у них были раньше и разбираться с дополнительными не будут - ибо проще работать так как привыкли ранее. Причем у них проблема противоположна вашей - все атрибуты внутри ЦБ и для них первоначальное создание БД является только дополнительной работой (все атрибуты из ЦБ надо перетащить в БД).
Новые тоже зачастую открываю LM и делая ЦБ по тренингам, начинают считать что и так всего получаемого внутри ЦБ пока им достаточно.
Собственно говоря, проблема заключается только в том, что если бы кто-то заполнил им БД и на протяжении некоторого времени помог в работе с ней, то через некоторое время считали бы что без БД плохо.

vitan, плиз сделай видео желательно с голосом (минут 5....15) как у тебя протекает процесс
догадываюсь, что fill имеет полное представление о сути беседы, но многие которые работают только в ЦБ (в том числе я) не понимают о чем идет речь

иначе вам с fill надо перенести беседу в другое место и с для полного взаимопонимания

Неужели? Я копирую файлик вместе с распиновкой (она внутри) и она точно так же по умолчанию повторяет исходную.


Пожалуй, единственное ускорение. Но и то - решаемо при обработке текста.


Как где? А создать запись в БД для данного компонента? А вести ее потом по жизни и проверять правильность введенных свойств. И, самое, главное, поддерживать соотвествие ЦБ и БД друг другу?


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


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


Это чуть ли не главная мысль во всей дискуссии. Думаю, все дружно начинают поворачивать головы в сторону ментора... А в ответ - тишина...


Это для меня сложно, надо ставить рекордер, и куда-то выкладывать. У меня нет интернета на рабочем месте. Плюс, самое главное, непонятно, что снимать на видео. Как создаются символы? Ровно так же, как и при CDB. Только там на пинах надо расставить атрибуты "#", значения которых - это номера пинов в корпусе.


Пожалуй, Вы правы. Очевидно, этим путем пользуюсь я один, и это больше никому не интересно, кроме fill-а (и то не знаю, в какой мере).

И при этом еще должны изменить имя файлика и т.д.
В рассмотренном варианте у нас: 3 символа и 17 PDB
У вас 51 символ и 51 файлик распиновки.
Т.е. у вас ЦБ пухнет на глазах, у нас остается компактной.


Большинство пользователей как раз воротит от того что нужно, что-то где-то еще "допиливать".



Запись в БД это список атрибутов, какая разница где их вводить в БД или PDB, если вводить все равно нужно? Количество вводимых полей одинаково. Время введения тоже. Т.к имя Part Number как правило не изменяется в процессе работы, да и удаляют вряд ли, то что тут поддерживать, соответствие чего с чем?



Я уже расписал все возможные варианты. Начните работу и все.



На предыдущей странице я уже приводил исчерпывающий список пунктов.
Я сам долго работал без БД, и начал ей пользоваться только тогда когда потребовался более расширенный поиск по параметрам (простой и так есть в CL View), и основное - возможность подключить datasheet к компоненту чтобы щелчком мыши по символу компонента или строчке в DxDatabook вызывать файл с описанием компонента - надоело лазить по папкам в поиске документации компонентов.

У этого есть и обратная сторона. Я могу поправить УГО только для одного компонента, например, исправить ошибку, или улучшить вид, а вы - нет, будете править всё.


Правильный вопрос. Только Вы предлагаете вводить не "или-или", а "и". Об этом и речь.


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

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



Мне непонятно, откуда Expedition берёт величину 0.254 мм. Дело в том, что я везде определил промежутки в 0,2 либо 0,4 мм. Последние -- на двух внутренних слоях, на которых только земля и питание, а разводки как таковой нет. Перерыл вроде всё, но так и не нашёл, в чём дело...

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



Я уже устал повторять ИЛИ. Где вы видели И в моих ответах по данному поводу?



Ну так тогда вам надо говорить не о DxDatabook а о DMS - это абсолютно другой уровень работы с БД. И DxDatabook в данном варианте уже будет только неким дополнительным инструментом доступа к DMS.

Спасибо, все получилось.

Вы не находите, что именно эти примеры делаются в файлах путем простой замены всех файлов копированием поверх старых? Безо всяких ЦБ...


В ЦБ и в БД. Хотите сказать, что я могу просто добавить в БД (но не в ЦБ) и у меня все получится (в смысле отправить на разводку)?



Зачем это? Разве в этом случае Exp сможет обойтись без ЦБ? Разве я смогу выставить на схему компонент (хранящийся весь в DMS через DxDatabook) и отправить его в Exp без создания этой ЦБ? Или без ЦБ не получится, но она будет создана автоматом для данного проекта?

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

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



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

Итак, вернитесь назад посмотрите на рисунок и поймите что топологическому редактору нужно получить откуда-то:
1. нетлист
2. описание компонентов - PDBs
3. описание ячеек использованных в компонентах- cells
4. описание стеков площадок использованных в ячейках - padstacks

Теперь сформулируйте что из этого вы получите из вашей БД через DxDatabook и как будете получать остальное.



Я уже говорил ранее, В DMS есть функция генерации "Производственных библиотек", т.е. ЦБ которые можно сформировать хоть под каждый проект.

Можно обойтись и просто хорошим файловым менеджером. Лично мне еще пока ни одного скрипта не потребовалось написать.


Давайте прекратим. Я не вижу способа совсем избавиться от ведения ЦБ при работе с CDB. Вы его тоже не говорите.


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

Обратил внимание на такую деталь. Если компонент (Part) создаётся из символа и посадочного места, причём из первого извлекается информация о "вентилях" (Gate), то ноги земли и питания получают атрибуты типа соответственно Power и Ground. Однако, если формировать эти самые "вентили" вручную (например, чтобы сформировать "сложновентильный" компонент без отрисовывания кучи символов, которые сами по себе использоваться не будут), то выставить такие типы ног невозможно: имеются входы, выходы и всякие прочие, но никак не земля-питание. С чем это связано и можно ли как-то обойти, кроме как рисовать символы и брать информацию о "вентилях" из них?

ADD. Мне удалось обойти эту проблему следующим способом. Рисую нормальный символ (какой будет использоваться на схемах), посадочное место, создаю компонент. После этого удаляю "вентиль", содержащий логические ноги, и оставляю только "вентили", содержащие питание и землю, после чего уже вручную создаю новые "логические вентили", заполняю их ногами и т.д.

Тем не менее, остаётся в силе вопрос: а возможно ли прямо в Part Editor'е указывать для ног типы Power и Ground?

А зачем вам вообще нужны данные типы пинов? И зачем вообще пины питания\земли вносить в логическую часть - т.е. в пины обычно присутствующие на символах схемы?
У вас же есть спец. закладка "Supply & NC" где можно просто ввести имя цепи и перечислить все ее номера пинов.
Тип пина нужен только для управления - кем станет данный пин в топологии соединений - Source, Load или Terminal - больше ни для чего.

Сначала надо разобраться что на самом деле означают эти типы Power и Ground. Есть подозрение, что они используются только в проверках ERC и только в специфических случаях (FPGA? IOD?). Появились эти типы недавно, и, например, я их не использую.



Многие инженеры, включая меня, предпочитают видеть все пины на схеме (explicit). Если что-то скрыто (implicit), то может быть весьма неудобно при отладке. Так что оба варианта имеют право на существование.



Согласен. Ну еще и для некоторых проверок ERC (ViewDRC), хотя для меня они вторичны.

Не внимательно читаете исходный вопрос :
Т.е. этих пинов на схеме все равно не будет.

Ну, они почти всегда бывают на символах аналоговых микросхем. Кроме того, сейчас многие цифровые МС работают при сильно разных напряжениях, и фиксировать лишь одно из них не хочется. А вариант с указанием VCC может не пойти, если используются схемы с разными напряжениями, каждое из которых формируется своим источником. В общем, хотя в основной логической части им делать нечего, зачастую всё ж нужно их отображать. (Хотя питания с фиксированным напряжением, например, 3,3 В, я прячу: нечего загромождать схему, если нет реальной нужды).



Про вкладку осведомлён, но не пользовался ей в силу перечисленного выше. Точней, пользовался, но только для фиксированных напряжений.

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

Кстати, такой вопросик. А можно ли в символе формировать скрытые выводы? Т.е. в файле символа они есть, но не отображаются? Мне бы они были полезны для того, чтобы одному и тому же посадочному месту (конкретно -- 9-контактным разъёмам D-Sub) можно было сопоставить разные символы с разным числом видимых выводов (полный RS-232, сокращённый RS-232, RS-485, CAN, просто 9-контактный разъём). Делать разные компоненты, ИМХО, не слишком хорошо, ведь в списке комплектующих (BOM) указываются подлежащие заказу Part Number, а для всех этих случаев реально надо приобретать одно и то же, меняется лишь логическое назначение...

Закончил, наконец, разводку платы (интересно, она хотя бы частично работать будет? ) ). Но тут внезапно появился ещё один вопрос. Где-то то ли слышал, то ли читал, что для машинной сборки надо размещать на плате реперные точки. Вот хотелось бы узнать, во-первых, что они из себя должны представлять (просто кружочки металла или ещё что), во-вторых, куда и сколько их ставить (вроде бы три-четыре по краям, причём несимметрично, а также по паре у каждой крупной микросхемы, особенно BGA), а в-третьих, как их надо оформлять в Expedition?

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

Подскажите, пожалуйста, как в CES изменить иерархию цепи - childs автомат назначил неправильно, как их сделать одиночными цепями?
И может кто знает почему у меня expedition вылетает если начинаю разводить или править трассы с широкими проводниками (0.5 мм если все остальные 0.1)?

Галочка Analog - вся электрическая цепь разбивается на физические.
Или убрать Series на последовательном резисторе\конденсаторе.

Спасибо!

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

Setup Parameters>Via Definitions
галочка Skip

Спасибо, теперь неиспользуемые КП он удаляет, но при этом полигон не обужает на этом слое ...

Padstack Processor еще запустите.

Сори за ламерство, все менюшки обглазел - в упор не вижу (EE2007.6) такого, ткните плиз носом в этот Padstack Processor.

Edit>Modify>Padstack Processor

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

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

Ну, неиспользуемые площадки всеравно полезно удалять, для снижения паразитной ёмкости via. Но зазор не трогать.

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

Вам сюда: http://electronix.ru/forum/index.php?showtopic=100226

Я бы даже сказал, сюда...

Всё это хорошо, но те базы и библиотеки, что можно посмотреть (включая SampleLib), весьма неполноценны, что ли...

В частности, "вызывает интерес вот какой ещё разрез". Если использовать только ЦБ, без БД, то для одного компонента (Part) можно указать несколько посадочных мест (Cell): одно основное и более-менее произвольное число дополнительных (правда, требуется, чтобы у них было одинаковое число выводов, совпадала нумерация и отображение логических выводов символа на физические выводы любого посадочного места). В таком случае при установке символа на принципиальной схеме нет жёсткой привязки к конкретному посадочному месту: после передачи проекта в Expedition в процессе расстановки компонентов по плате можно выбирать любое из предусмотренных посадочных мест. Скажем, если для резистора заданного номинала, точности и т.п. заданы Cell'ы 0402, 0603 и 0805, то по умолчанию предлагается одно из них, но прямо в Expedition можно выбрать и любое из двух других. В SampleLib же (как и в библиотеке и базе у cioma) компоненты жёстко привязаны к корпусам; даже Part Number'ы содержат прямое указание на то, какой корпус используется. В такой ситуации, надо полагать, для замены корпуса необходимо сначала поменять компонент в DxDesigner, затем заново упаковать и аннотировать в Expedition, что явно менее удобно, чем при использовании альтернативных Cell'ов, заданных прямо в ЦБ. В связи с этим возникает вопрос: можно ли обеспечить такое же удобство для связки ЦБ+БД? Думается, что да (во всяком случае, я не вижу причин, почему бы этому не работать, ну и собираюсь проверить на практике). Однако сразу же всплывает второй вопрос: а откуда DxDesigner, Expedition, CES и т.д. берут необходимые значения свойств, связанных с взаимосвязью между компонентами, символами и посадочными местами: всегда из ЦБ или же сначала смотрят БД, и лишь при отсутствии там необходимой информации обращаются к ЦБ? В первом случае, который мне представляется более вероятным, поля БД типа Footprint и т.п. служат исключительно для поиска и "документирования", но реальное посадочное место не задают. Однако тогда возможна ситуация, когда Expedition позволяет для компонента использовать корпус, который в реальности для данного номинала не предусмотрен. Например, находящийся в ЦБ обобщённый компонент "конденсатор" состоит из стандартного символа и посадочных мест 0402, 0603, 0805, 1206 и 1210. Конкретный номинал существует лишь для некоторых из этой группы посадочных мест. Тогда при поиске по номиналу в DxDatabook мы получим группу строк (записей из БД), в столбце Footprint которых будут указаны все реально возможные корпуса для данного номинала (предполагается, что БД заполнена правильно). Однако при установке такого компонента в Expedition будет возможность выбрать любой из Cell'ов, заданных в ЦБ, т.е. без учёта того, существует таковой для данного конкретного компонента или нет, поскольку информация об упаковке, а значит, и о Cell'ах, находится только в ЦБ. Так ли это на самом деле и есть ли возможность ограничить Expedition выбором лишь допустимых посадочных мест, не увязывая их жёстко с Part Number'ами, а соответственно, не заставляя для замены посадочного места изменять принципиальную схему, меняя один компонент на другой?

Пытался связать ЦБ с БД и наткнулся на непонятную проблему. После создания конфигурации DxDatabook в Library Manager и входе в её редактирование (окошко Configure) оказывается невозможным связать разделы ЦБ с таблицами. Стою на имени раздела, нажимаю Add Table, появляется одноимённое окошко, в котором надо указать Data Source (DSN) и Table Name. Выпадающий список для DSN пуст. Нажимаю рядом кнопку New, открывается новое окошко, Data Source Manager. В нём можно благополучно добавить новый DSN для выбранного источника (на скриншоте выбрана моя база; там же присутствует база от SampleLib). Однако после нажатия OK в окошке Add Table поле Data Source (DSN) по-прежнему будет пустым, т.е. источник не добавляется. Соответственно, невозможно добавить и таблицу из этого источника.

Точно так же дело обстоит и в SampleLib: там DxDatabook уже сконфигурирована, т.е. разделы ЦБ связаны с таблицами БД. Однако добавить новую связь и т.п. невозможно.

DSN Expedition системный или пользовательский? Проверьте, там рекомендуют делать системные...
А вообще похоже просто на глюк...

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

Вот.
Доведет эта ЦБ до ручки!


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


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

Посадочные места не должны являться параметром компонента. Если Вы так сделаете, то компонент станет абстрактным, а не реальным. Ни один САПР ПП не рассчитан на это, все они работают с реальной геометрией, что есть глубоко правильно.

В крайнем случае можете сделать несколько альтернативных посадочных мест каждому компоненту, например, по нормам IPC (L, N, M). Или еще бывают отдельные случаи, когда, например, светодиод с ногами можно впаять прямо, а можно с загибом.
Это будет нормальное использование САПР по назначению, а не так, как Вы придумали.

to SII

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

Если говорить только про это, то, думаю, сие не вызовет проблемы, просто BOM надо формировать не по "голому" Part Number, а по связке Part Number + Cell (вроде как это можно настроить, но не проверял).



Если уж так ставить вопрос, то доведёт БД, а не ЦБ -- последняя работает сама по себе великолепно. Вот в PADS, где её нет и есть только "голая" БД, я натрахался предостаточно. Собственно, это и стало основной причиной, почему я решил-таки сосредоточиться на Expedition (и пилить шефа взять именно его, несмотря на раз в 5 более высокую цену: оно того стоит).



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



Это есть глубоко неправильно, поскольку САПР ПП имеют два уровня: уровень принципиальных схем и уровень самой платы. Первый никак не привязан к "геометрии" и не должен быть к ней привязан (хотя бы потому, что на этапе разработки схемы не всегда известно, какие конкретно компоненты будут использоваться). Использование альтернативных посадочных мест, собственно, и отвязывает уровень схем от этой самой "геометрии".

Другое дело, что в существующих САПРах поддержка такой "развязки" может быть не реализована должным образом или вообще отсутствовать. Более того, она, скорей всего, именно что сделана криво, и попытка использовать имеющиеся возможности типа альтернативных корпусов в ЦБ Expedition чревата возникновением ошибок. В идеале же САПР не только должна давать возможность выбирать корпуса для компонентов в процессе их установки на плату, но и позволять штатным образом, а не через известное место, создавать несколько различных плат для одной и той же принципиальной схемы, совершенно не меняя последнюю. Например, в процессе отладки схемы можно использовать крупные SMD-резисторы и конденсаторы, микросхемы в SOICах или вообще в DIPах, ну а для серии перевести всё на какие-нибудь 0402 и BGA, чтобы уменьшить массу и габариты.

В общем, вопрос про альтернативные корпуса остаётся открытым -- хотя бы в теоретическом плане (делать так на практике или нет, пока не знаю; сейчас ЦБ у меня жёстко привязывает компоненты к корпусам, хотя для интереса я и попробовал альтернативные и убедился, что сам по себе механизм работает).

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

Вот именно.
В схеме Вы можете отвязаться от геометрии.
И ментор предоставляет такую возможность.
Для этого используется команда annotate generic.

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


Так что это правильно. Annotate generic Вам в помощь.

А вот создать несколько разных плат при одной схеме (совершенно одинаковой) можно только вручную. В этом случае проекты схемы и платы будут просто не связанными, т.к. информации для разных вариантов будет просто неоткуда взяться. Думаю, Вас этот вариант не интересует.
Единственно возможный способ здесь - создать заготовку схемы с generic-компонентами, а при создании вариантов ПП делать новый эеземпляр схемы с unique-компонентами.

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

тогда вам надо использовать старый добрый Pcad4.5
там вообще не было компанентов, только sym и prt
а sym имел атрибут prt=...... , где можно было прописать все что пожелаешь для прохождения операции упаковки

хотя это от ручной работы не освобождало как и от кучи ошибок от из=за этого

В этом смысле работа без ЦБ от пикада недалеко ушла. Но применение базы позволяет-таки нормально работать и прописывать корпуса автоматически на уровне схемы...
А применение ЦБ... Ну Вы мое мнение знаете.

Поставил Expedition на другую машину, где отродясь продуктов MG не было. Однако описанная мною ранее проблема с ЦБ + БД никуда не исчезла: не удаётся связать разделы ЦБ с таблицами, и всё тут. Цитирую своё предыдущее описание:



Никаких умных мыслей ни у кого нет?

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

Ну, я тоже вижу таблицы, если они прицеплены к базе заранее -- как это имеет место быть с учебной ЦБ (SampleLib2007, если память не отшибло). Но вот прикрутить новые таблицы не получается...

И даже новую таблицу из базы SampleLib2007 не получается? Может, у Вас с правами доступа что-то понаделано?