[vpd 0]

Что-то ничего там нет:

 

C:\Cadence\SPB_16.3\tools\capture\vendor>dir

Содержимое папки C:\Cadence\SPB_16.3\tools\capture\vendor

28.05.2010  11:50    <DIR>          .
28.05.2010  11:50    <DIR>          ..
07.05.2009  23:39         1 252 034 mgc_interface.pdf
17.11.2009  00:43            28 672 orAliasRot.dll
17.11.2009  00:51            45 056 orhier_rep.dll
17.11.2009  00:46         7 073 792 orLayToAllegroTrans.dll
17.11.2009  00:46           528 384 orLibCorrectionUtil.dll
17.11.2009  00:47           106 496 orMentorDll.dll
17.11.2009  00:48           532 480 orPushOccPropTool.dll

 

?

[Old1 0]

Что-то ничего там нет:

 

C:\Cadence\SPB_16.3\tools\capture\vendor>dir

Содержимое папки C:\Cadence\SPB_16.3\tools\capture\vendor

28.05.2010  11:50    <DIR>          .
28.05.2010  11:50    <DIR>          ..
07.05.2009  23:39         1 252 034 mgc_interface.pdf
17.11.2009  00:43            28 672 orAliasRot.dll
17.11.2009  00:51            45 056 orhier_rep.dll
17.11.2009  00:46         7 073 792 orLayToAllegroTrans.dll
17.11.2009  00:46           528 384 orLibCorrectionUtil.dll
17.11.2009  00:47           106 496 orMentorDll.dll
17.11.2009  00:48           532 480 orPushOccPropTool.dll

 

?

Посмотрел у себя в версиях 16,3 и 16,5 - есть ... может быть дело в лицензиях. Вот на всякий случайvendor_bmp.rarв архиве пиктограммы, что лежат у меня в tools\capture\vendor попробуте распаковать у себя...

 

[vpd 0]

да нет, 16.3 у меня самый что ни на есть лицензионный стоит. Странно...

 

А откуда оно тогда картинки то берет?

 

Может дело в том, то в той версии Capture нет CIS? Кстати да, об этом я и не подумал :)

[alexa1973 0]

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

Ну, например, берем bench.mdb и видим, что таблица резисторов и конденсаторов по набору свойств почти совпадают. Строго говоря, все свойства, необходимые для CIS вообще совпадают, а некоторые физические свойства могут отличаться: у резисторов указывается мощность, а у конденсаторов - напряжение.

Мне такая организация не очень нравится. Хотелось бы иметь возможность в будущем вносить изменения в структуру базы данных. С большой вероятностью таковые изменения коснутся базового объекта, а не какого-то отдельного класса компонентов. Например, вот был раньше Layout и просто Footrint, а потом добавили Аллегро, и надо теперь уже в базе иметь два свойства - Layout PCB Footrint и Allegro PCB Footrint. при нынешней организации придется в каждой таблице прописывать новые поля, а так можно только в одной таблице прописать.

 

Я правильно думаю, что можно создать таблицу типа basic_cis, а потом во вкладке relational database прописать ее в качестве связанной таблицы для всех типов компонентов? И тогда в качестве связующего поля останется только part number? Или CIS использует для работы основную базу, а связанные только для просмотра свойств, и вся идея рушится?

 

Ты все правильно понял. Данные с Relational Tables не переходят в схему через Transfer to Design, их можно увидеть через поиск и вывести в BOM. Можешь глянуть этот youtube. Выруби звук если мешает

 

[vpd 0]

Судя по этому видео получается, что даже список альтернативных компонентов (manufacturer:part number) можно вывести в BOM.

 

К сожалению, вообще тема relational database недостаточно раскрыта в документации. Что и с какой целью нужно подключать к обычным таблицам? Есть ли что-нибудь вроде best practices по этому поводу?