Че-то я не понял. Если у Вас уже 5368 штук, то в чем трудности? Вы же так уже работаете. Или Вам это не нравится, и хотелось бы иметь один девайс?

Да, я серьезно предлагаю создавать на каждую деталь свою модель. Я не вижу в этом какой-то странности. Ни у кого не вызывает вопросов создание двух моделей на два разных винта длиной 3 мм и 4 мм. Другой вопрос, что способы создания могут быть разными, что можно нарисовать параметризованную заготовку, это все понятно. Важно, чтобы в конечном счете каждый тип объектов (НЕ ПУТАТЬ С ЭКЗЕМПЛЯРАМИ) реального мира (резистор) имел свою модель. Иначе все моделирование будет просто не соответствовать действительности, это же очевидно!

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

Ничего я так не работаю... У нас вообще резисторы(и все мелкие СМД-компоненты) в 3D модели не участвуют. Я думал это станет понятно из краткого описания технологии, которое я раньше приводил.
Просто Вы предлагаете на все девайсы создать свои модели. А на самом деле девайс это сумма свойств компонента - и электрических и механических. И вот на всю эту пачку в 5 с лишним тысяч штук резисторов достаточно десятка моделей в MCAD-e. Потому как механически они идентичны.

Ну тогда у Вас есть шанс начать работать сразу по-нормальному (если вдруг решите их тоже моделировать).


Еще раз повторяю. Загляните в даташит на обычные керамические конденсаторы. Увидите различие по высоте. Будете и дальше спорить, что они механически идентичны? Если будете делать что-нибуль типа мобильника, сразу все вылезет боком. Это наиболее наглядный пример, есть много других отличий. Так что "идентичность" - это упрощение процесса моделирования, которое может привести к неадекватным результатам. И лично я не вижу никаких трудностей называть модели по имени компонента в ECAD, а не по имени футпринта. И копировать файлик мне не трудно. В общем, я для себя вопрос с моделями закрыл. Надо думать про исполнения.

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



А с чего Вы взяли, что я считаю, что у конденсаторов с разной высотой одинаковый футпринт? Помимо контактных площадок в package symbol входит также шейп в классе place bound top, который имеет атрибуты высоты, и они могут отличаться для разных компонентов. Соответственно, файлы psm будут разные, свойство PCB Footrpint, и IDF получится разный, и итоговая 3D-модель. Нет тут никакого упрощения. Я в качестве примера приводил два резистора 0603, у них размеры не зависят от номинала.

А вот скажите, у конденсаторов одного типоразмера бывают, кроме номинала, еще тип диэлектрика (штук 5 типов вполне распространены: C0G, NPO, Y5V, X5R, X7R), еще с десяток ходовых рабочих напряжений, еще как минимум три градации точности (5, 10, 20%), итого - не менее 150 вариантов сочетаний. Сколько моделей для этого многообразия нужно сделать? Почему Вы только в номинал уперлись?

Здесь надо понимать, что в общем случае, то, что создается в аллегро, это не футпринт. Это уже тоже трехмерная модель (если указаны высоты и прорисованы границы). Так что аналогия прямая: Вы вынуждены создавать разные модели (футпринты). В аллегро Вы это делаете для отработки электрической составляющей проекта, а в MCAD Вы точно так же будете отрабатывать механику. При этом у Вас не будет описанных выше проблем.
В общем, ситуацию можно разрисовать в виде следующей схемы данных.
Вы предлагаете хранить (организовать) модели в следующем виде:
DEVICE <----> FOOTPRINT <----> 3D_MODEL.
Я же говорю, что более правильно так:
DEVICE
|<----> FOOTPRINT
|<----> 3D_MODEL
Кому приходилось создавать базы данных сразу понятно, что 3D_MODEL связана с DEVICE, но не с FOOTPRINT.

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

ЗЫ. C0G и NP0 - одно и то же...

vitan, но вот опять Вас в женскую логику понесло... Я с Вами не спорю, что 3D-модель - привязана к device, а не футпринту. Я возражаю против Вашего заявления, что два резистора 0603 с разным сопротивлением должны иметь разные 3d-модели (в разных файлах). Базе данных с перечнем свойств - да, а размножению моделей бездумному - нет. Снова топчемся на месте...

Просто в IDF, по которому строится модель, как правило, только футпринт передается в нормальном виде для всех компонентов. Поэтому именно имя футпринта может использоваться для ассоциации с файлом модели. К сожалению, Part number обычно передается кривой (devtype), хотя это хорошая идея - сделать возможность мэппинга модели по part number в качестве исключения из правил по футпринту. Приделаю к своему конвертеру потом.

Проблема не в том, что device - это совокупность большого числа разных атрибутов, записанных в базу данных. проблема в том, всякое ли произвольное сочетание этих атрибутов является device-ом? А если не произвольное, то кто заполнит эту базу данных всеми реально допустимыми сочетаниями? Сколько на это нужно времени? Что делать, если я, например, 5 лет работал без MCAD, создал базу, и потом решил, что еще модели надо добавить. Базы переделывать? Что делать, если у меня часть моделей, хранящихся в базе, сделана в старой версии ПО, а новые я сделал в новой версии, и теперь в старой их не посмотреть (не совместимы форматы). Мне нужно всюду переустанавливать САПР на новую версию? Или всюду сохранять модели в старой? Или сохранять в форматах всех версий?

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

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

Всей этой мути при использовании базы просто нет. Компоненты проверяются по базе и все свойства аннотируются в схему автоматически, и никому не надо ничего там помнить и подправлять.
Последний (в смысле больше не буду приводить) пример насчет разных моделей резисторов и конденсаторов. Конденсаторы отличаются по цвету, а резисторы - надписями. Первое - хоть и смешно на первый взгляд, но может использоваться, например при оптическом контроле. Ну и показать заказчику как Old1 тоже не стыдно. Надписи на резисторах можно тоже использовать для контроля. И для создания сборочника тоже. Некоторые делают сборочники, где вместо номиналов так и написано: 103, 102 и т.п., т.е. трехбуквенный код. Мне тоже нравится.


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

А чем плохо такой вариант реализовать:
1. Любым способом создаем BOM-ы разных исполнений. Можно через CIS BOM Variants, но в принципе не обязательно. Главное - получить файл с перечнем компонентов и их заданных свойств.
2. На этапе импорта IDF в MCAD пристегиваем к нему созданный BOM, чтобы в модель попадали только те детали, которые описаны в BOM, а не все вообще из IDF.

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

Искал восможность сделать это штатными средствами и пока не нашел

В принципе, можно поддержать такое с помощью IDF-фильтра, который просто выкидывал бы из секции placement все записи о компонентах, refdes которых не попадает в множество, описанное в файле BOM. Фильтрованный IDF вполне можно скормить штатным средствам. Если интересно, то могу такое реализовать, парсер IDF у меня в конвертере есть, BOM у Cadence бывает и текстовый, так что тоже можно его легко зачитать.

Имхо это путь неправильный. В этом случае придется много раз импортировать IDF (по числу исполнений). Меня напрягает уже при количестве 2. Поэтому надо найти, как к сборке, в которой есть всё, присовокупить инфу о применяемости делатей по исполнениям, а потом на основе этого в MCAD создавать варианты.

Ну так в IDF вообще нет информации об исполнениях. И даже в конкретном BOM ее нет. Так что по-любому придется какое-то подобное действие совершать многократно. У меня вот сборка на 500 деталей строится секунд 5-15 в полностью автоматическом режиме. Даже если требуется переделка (моделей не хватило и т.п.), то все последние настройки конвертер помнит через реестр, поэтому повторный запуск - это всего три клика мышкой. Я думаю, что это наименьшее зло.

Ошибаетесь, есть. Это имя файла, например.


Нет, это не наш метод. У Вас если исполнений будет 20 штук, то так и будете мышкой двигать полдня?

Не вижу ничего в этом плохого. Это вообще ноль по сравнению с тем, сколько потом еще действий нужно совершить, чтобы полностью оформить всю КД на исполнение.

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

Ознакомился с возможностями солида по разработке вариантов. Приятно удивлен. Они чуть ли не на порядок выше, чем у самого продвинутого менторовского менеджера вариантов от EE7.9. Понятно, что сравнение не очень корректное, т.к. САПРы немного для разных задач, но все же. Создание вариантов очень сильно развито.
Конкретно для оформления исполнений сборки нужно создать таблицу в экселе. В ней можно указать и наличие\отсутствие и замену компонентов в исполнениях. При наличии этой таблицы солид тут же формирует всевозможные виды и чертежи по исполнениям.
Остается техническая проблема - создать эту таблицу. Конкретно у меня есть другая таблица (из моего схематика, DxD), но она, к сожалению, в другом формате. Т.е. нужно просто иметь некий конвертер.
Может, есть у кого готовое?

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


Мне кажется, что этот вопрос неуместен в форуме для Cadence

Да, но ровно то же самое будет и кейденсом. В аллегро для вариантов используется некий файлик variants.lst (или txt, не помню точно). Кто-нибудь может выложить пример такого файлика для оценки его переносимости напрямую в солид?

А Вы хотите вручную этот файлик писать? Учитывая все варианты исполнения в нем? Вообще этот файлик - это экспорт из Variant Editor-a для втягивания в РСВ и генерации Variant Assembly. Варианты создаются на основе Package проекта. На основании данных о вариантах создаются аннотированные копии схем этих вариантов. Это все для связки Concept HDL - PCB Editor предназначено.
А в чем Вы его создавать будете?

PS Ну вот файл вариантов небольшого проекта, для примера
Нажмите для просмотра прикрепленного файла

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


А так же и для связки DE CIS - PCB Editor.

Да, конечно. Сначала написал, а после Вашего поста вспомнил что и из Capture файл вариантов генерится.

Так вот он какой, северный олень! Спасибо всем за файлики.

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

Вот создал тему, где выложил программку для фильтрации IDF. Посмотрите, может, пригодится.

Уважаемый Hoodwin! Можно узнать подробнее о Вашем конвертере IDF для КОМПАСа?

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

Хотелось бы узнать, сопоставим ли конвертер с CircuitWorks по функционалу? Хотелось бы получить сборочный чертеж блока в Компасе с проставленными RefDes, импортируя IDF из PCAD. Спецификацию планирую создавать в Search AVS. Какова стоимость конвертера и как его можно приобрести?

По поводу CircuitWorks я Вам не скажу, я с ним не работал. Конвертер делался для построения 3D модели сборки печатной платы, с основной целью ее последующего моделирования в 3D, и всех производных действий. Простановку refdes оно автоматом делать не умеет, но можно этот слой втащить через DXF из сборочного слоя ECAD. У меня всегда обозначения делаются внутри контуров компонентов, поэтому хорошо ложатся на проекционный вид платы.

По поводу условий в личную почту отписал, но что-то оно не хочет отправлять, говорит: "пользователь отключил свой ящик".

Спасибо за ответ. Вот только личного сообщения не получил. "Вам запрещено использовать личные сообщения на форуме". Можно то же самое на почту? Lokkee*bk.ru

Я читал доку на него, и могу сказать, что нет, не сопоставим.
Еще я могу сказать, что Circiutworks - это лучший конвертер, который я видел. Я последний месяц посветил изучению этой проблемы, тестил разные САПРы от кати до компаса именно на предмет связи с ECAD. Остановился именно на солиде.

Судя по всему, у Вас внедрен Search? Я давно с ним не работал, но они рекламируют, что он понимает формат многих САПР, и оттуда берет состав изделия. Он понимает файлы САПР печатных плат?

Отправил на почту.

Search у нас в процессе внедрения. Насчте многих САПР не скажу, с PCADом работает, зачитывает атрибуты из схемы.