[vpd 0]

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

 

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

 

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

 

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

[vitan 2]

Вот и получается, что разваливается эта стройная система с базой.

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

Лишнее подтверждение - Ваши же слова:

В общем, проблема упирается в то, что в схеме компонентам нужно задавать свойства для формирования спецификаций, которые будут выводиться через BOM. И вот копировать свойства по разным компонентам не очень удобно, потому что часто возникают ляпы с несоответствием. Например, стоит в схеме 10 резисторов 1Ком 5%, а в свойстве PE3_Name, которое у меня используется для наименования в спецификации, стоит для 8 резисторов "Резистор 0603 1Ком 5%", а для еще двух "Резистор 0603 1.5Ком 5%", причем второй вариант может возникнуть неожиданно в процессе коррекции схемы: Value поменяют, а PE3_Name - забудут. Глазами такое довольно трудно выискивать, когда деталей много. В итоге в спецификацию попадут неправильные данные.

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

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

 

Кстати, по поводу BOM variants. Все оказалось немного мрачнее, чем я думал. Оказывается, что BOM Variants - это надстройка над CIS, и в версии OrCAD PCB Editor все эти фичи недоступны, поскольку там Capture без CIS. Ну и вот CIS я пока не использовал. Видимо, придется его осваивать, или искать другие пути для описания вариантов исполнения.

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

[vpd 0]

А чем плохо такой вариант реализовать:

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

2. На этапе импорта IDF в MCAD пристегиваем к нему созданный BOM, чтобы в модель попадали только те детали, которые описаны в BOM, а не все вообще из IDF.

 

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

[Old1 0]

...

2. На этапе импорта IDF в MCAD пристегиваем к нему созданный BOM, чтобы в модель попадали только те детали, которые описаны в BOM, а не все вообще из IDF.

 

...

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

[vpd 0]

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

 

[vitan 2]

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

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

[vpd 0]

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

[vitan 2]

И даже в конкретном BOM ее нет.

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

 

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

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

[vpd 0]

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

[vitan 2]

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

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

 

Ознакомился с возможностями солида по разработке вариантов. Приятно удивлен. Они чуть ли не на порядок выше, чем у самого продвинутого менторовского менеджера вариантов от EE7.9. Понятно, что сравнение не очень корректное, т.к. САПРы немного для разных задач, но все же. Создание вариантов очень сильно развито.

Конкретно для оформления исполнений сборки нужно создать таблицу в экселе. В ней можно указать и наличие\отсутствие и замену компонентов в исполнениях. При наличии этой таблицы солид тут же формирует всевозможные виды и чертежи по исполнениям.

Остается техническая проблема - создать эту таблицу. Конкретно у меня есть другая таблица (из моего схематика, DxD), но она, к сожалению, в другом формате. Т.е. нужно просто иметь некий конвертер.

Может, есть у кого готовое?

[vpd 0]

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

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

 

Остается техническая проблема - создать эту таблицу. Конкретно у меня есть другая таблица (из моего схематика, DxD), но она, к сожалению, в другом формате. Т.е. нужно просто иметь некий конвертер.

Может, есть у кого готовое?

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

 

[vitan 2]

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

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

[Uree 1]

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

А в чем Вы его создавать будете?

 

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

variants.lst.txt

[Old1 0]

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

Вот пожалуйстаVariants.rar

 

Это все для связки Concept HDL - PCB Editor предназначено.

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

[Uree 1]

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