База данных CIS и полиморфизм компонентов, или как структурировать CIS Опции

[Hoodwin]

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

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

[Tahoe]

Например, вот был раньше Layout и просто Footrint, а потом добавили Аллегро, и надо теперь уже в базе иметь два свойства - Layout PCB Footrint и Allegro PCB Footrint.

А можно полюбопытствовать, зачем? Особенно учитывая идеологию Аллегро, где схематик на 99% отвязан от footprint. Оставшийся 1% это лишь "рекомендуемый" footprint, который может вообще отсутствовать в схематике.

[vitan]

Советую Вам не пользоваться возможностями редактора CIS, а подготавливать необходимые виды (таблицы) средствами СУБД. При этом Вы никогда не столкнетесь с проблемами при изменении структуры БД, точнее, эти проблемы не отразятся на работе схемотехников. Конкретно по организации хранения свойств компонентов можете посмотреть ветку про БД в разделе альтиума, я там приводил картинки со структурой для SQL Server. Там приведена не самая совершенная структура, но для начала очень даже сгодится. Сейчас же я продвигаю организацию хранения свойств для компонентов наподобие того, как это сделано в SharePoint, это имхо наиболее продвинутый вариант...

[Hoodwin]

Почти ничего не понял из написанного
Вроде бы конкретные вопросы задал про организацию таблиц, а не про редактор.

[vitan]

Почти ничего не понял из написанного
Вроде бы конкретные вопросы задал про организацию таблиц, а не про редактор.

Попробую прояснить.
Дело в том, что в редакторе ограничена функциональность. Точнее, использование редактора не дает Вам возможности нормально оперировать внутренностями базы. Возможности редактора предназначены в первую очередь для тех, кто далек от практики построения больших баз данных, для тех, кто хочет быстро получить результат, не вдаваясь в детали и в теорию.
Поэтому я советую им не пользоваться.
Возможности связи таблиц друг с другом - это, конечно, хорошо, но Вы должны знать, что связывание таблиц (как говорят в мире БД - создание отношений) гораздо более правильно делать внутри самой БД, а не в каком-то внешнем редакторе. Это позволит наладить нормальное хранение информации, распределенной по сущностям в виде таблиц (с контролем целостности данных), а также, что наверное, самое важное, нормально исполнять запросы к БД. Одним из типов таких запросов в нашем случае будет запрос на отображение библиотеки компонентов - списка однотипных компонентов с одинаковыми названиями свойств.
Касаемо организации свойств. Вы правильно понимаете, что повторение одних и тех же свойств в таблицах вызовет проблемы. Но решать это надо путем правильной организации таблиц и связей между ними, т.е. схемы данных. Правильный подход следующий: определяете сущности, которые Вы хотите учитывать в БД, и создаете для них справочники (таблицы). Затем связываете таблицы отношениями. Самое главное здесь - понять, какие именно будут сущности. Важность этого трудно переоценить. Лично я советую Вам для начала создать следующие:
- электронный компонент;
- УГО;
- футпринт;
- корпус;
и далее по теме топика:
- тип свойства электронного компонента;
- значение свойства электронного компонента;
- единица измерения.
Для каждого из них будет своя таблица в БД. Попробуйте связать их отношениями, наполнить данными и подключить к схематику. Когда получится, гарантирую, что о редакторе CIS в части связывания таблиц Вы забудете.

А можно полюбопытствовать, зачем?

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

[Hoodwin]

vitan, ну вот опять Вы мне про редактор... Я вообще о другом тему поднял исходно. Попробую объяснить в терминах С++. Вот смотрите, есть несколько объектов следующей структуры:

Код

struct Resistior
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
   string power;
   string tolerance;
};

struct Capacitor
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
   string voltage;
   string dielectric;
   string tolerance;
};

struct Inductor
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
   string current;
   string dc_ohm;
   string tolerance;
};

struct Connector
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
   string curcuits;
   string orientation;
};

struct IC
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
   string some_ic_parameter;
};

Как видим, довольно приличное число полей идентично для разных типов данных, и лишь незначительное количество отличается. В концепции объектно-ориентированного программирования принято такие структуры оформлять в виде наследования:

Код

struct BasicComponent
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
};

struct Resistior : public BasicComponent
{
   string power;
   string tolerance;
};

struct Capacitor : public BasicComponent
{
   string voltage;
   string dielectric;
   string tolerance;
};

struct Inductor : public BasicComponent
{
   string current;
   string dc_ohm;
   string tolerance;
};

struct Connector : public BasicComponent
{
   string curcuits;
   string orientation;
};

struct IC : public BasicComponent
{
   string some_ic_parameter;
};

Это не просто отражает суть структуры, а делает удобным развитие базы в будущем. Например, допустим, что в ТЗ есть требование спроектировать устройство под расширенный температурный диапазон. И теперь мы хотим формализовать применимость компонентов по такому критерию, то есть, мы хотим для всех компонентов добавить в качестве базовых свойств минимальную и максимальную температуры. В случае простой системы таблиц мы должны в каждую таблицу добавить два параметра. В случае иерархии с наследованием нам достаточно внести изменение только в базовую счасть - struct BasicComponent:

Код

struct BasicComponent
{
   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   int  min_temperature;
   int  max_temperature;
   ...
};

Собственно, пример футпринта тоже был взят для иллюстрации именно развития базовых свойств компонента по мере усложнения набора применений БД. Но, - оказался неудачным, поэтому я не буду его далее обсуждать.
Мое мнение заключается в том, что гораздо более вероятно, что если в будущем потребуются какие-либо изменения в структуре таблиц, то они будут относиться к базовым свойствам (базовому классу в терминологии ООП), а не к частным. Конечно, частные свойства наследованных классов тоже могут меняться, но это будет носить менее регулярный характер. Ну, например, тонкопленочные резисторы тоже можно характеризовать предельным напряжением пробоя в пленке, и этот параметр будет важен для высокоомных резисторов. А для подавляющего большинства т.н. general purpose резисторов такой параметр обычно остается вне внимания проектировщика. Как вариант, можно пытаться добавить этот параметр в таблицу резисторов.

Итак возвращаюсь к исходной проблематике. Реализовать такое наследование средствами БД можно с помощью related tables. Для этого придется правда в таблице наследованных свойств повторить какое-нибудь ключевое уникальное свойство. Тогда структура таблицы резисторов будет выглядеть примерно так:

Код

struct BasicComponent
{
   unsigned long   UID;  // УНИКАЛЬНЫЙ НОМЕР БАЗОВОГО КОМПОНЕНТА

   string part_number;
   string part_type;
   string footprint;
   string package;
   string value;
   ...
};

struct Resistior : public BasicComponent
{
   unsigned long   UID;  // УНИКАЛЬНЫЙ НОМЕР БАЗОВОГО КОМПОНЕНТА

   string power;
   string tolerance;
};

И тогда получается, что для каждого компонента можно построить полный набор свойств, однозначно выбранных из двух таблиц.
Проблема заключается в том, можно ли такому научить CIS?
Или, если более точно сформулировать. Может ли CIS использовать поля связанных таблиц для настройки переноса данных между БД и проектом? Или настройка относится только к главной таблице, а привязанная используется только CIS explorer для просмотра вспомогательных свойств, вроде cost, availability И т.п.?

[vitan]

Зря вы не хотите послушать. Лекция про наследование лишняя, я Вам то же самое пытаюсь объяснить с самого начала. Только вы хотите это сделать в редакторе, а я Вам говорю, что это делать надо в СУБД.

[Hoodwin]

В каком редакторе? Речь о настройках взаимодействия CIS с базой данных.

[vitan]

В том, в котором Вы собираетесь прописывать связанные таблицы. Который вызывается нажатием кнопки редактирования .dbc.

[Hoodwin]

Так я вообще-то хотел прописывать таблицы в каком-нибудь Microsoft SQL Server Management Studio. Но все равно, где бы они ни были созданы и связаны, их нужно правильно настроить для взаимодействия с CIS. Все что я хочу выяснить, так это то, умеет ли CIS работать со связанными таблицами в Part Managere, то есть, когда часть важных свойств находится в связанной таблице. насколько я понимаю, если у меня таблица Resistors содержит только ссылку на стандартные свойства в таблице стандартных свойств, то при попытке написать для нее SELECT с указанием выборки по любому стандартному свойству сервер откажется, сказав что таких свойств в таблице resistors нет. И для правильного поиска нужно будет либо View создать и там искать, либо писать более сложный select, вроде "найти все такие записи в таблице Resistors, у которых в связанных с ними основных данных свойство X равно Y".

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

Эскизы прикрепленных изображений

 

[vitan]

Если коротко: делайте View на каждую библиотеку. Там все будет видно.

[Hoodwin]

Сегодня поднял сервер, импортировал в него тестовую базу из Access, настроил сетевой доступ, SQC ODBC dat source, получил в итоге работу с CIS.
Потом создал простейшие две таблицы и объединил их при помощи View. В целом работает, так что можно ничего не мутить в настройках relational database у CIS. Нужно только грамотно таблицы создать.

Есть еще несколько вопросов.
1) Почему-то когда пытаюсь Save Query в CIS Explorer (вкладка Query), то capture вылетает с ошибкой.
2) Можно ли как-нибудь настроить тип поля voltage, tolerance и т.п., чтобы при поиске компонентов capture сравнивал числовое значение, а не строковое. Например, реши поискать конденсаторы по критерию voltage >= 60V, так получил только 63V, а 100V в список не попало, то есть он делал сравнение строк посимвольно.
3) Добавил в таблицу колонку Min_Temperature. Получил забавный эффект. Если в поисковом запросе написать Min_Temparature < -20, то оно показывает даже те компоненты, у которых этот параметр в точности равен -20. К чему бы это? В базе тип поля указан int.
4) Можно ли как-то пометить оригинальные таблицы в базе, чтобы их не путать с View при настройке CIS?

[vitan]

Сегодня поднял сервер, импортировал в него тестовую базу из Access, настроил сетевой доступ, SQC ODBC dat source, получил в итоге работу с CIS.
Потом создал простейшие две таблицы и объединил их при помощи View. В целом работает, так что можно ничего не мутить в настройках relational database у CIS. Нужно только грамотно таблицы создать.

Отлично. Труды мои не пропали зря.

2) Можно ли как-нибудь настроить тип поля voltage, tolerance и т.п., чтобы при поиске компонентов capture сравнивал числовое значение, а не строковое. Например, реши поискать конденсаторы по критерию voltage >= 60V, так получил только 63V, а 100V в список не попало, то есть он делал сравнение строк посимвольно.

А в базе тип указан числовой?

4) Можно ли как-то пометить оригинальные таблицы в базе, чтобы их не путать с View при настройке CIS?

Обычно таблицы используют для справочников и приписывают им префикс guide_.
А вьюхи я Вам советую называть по называнию схемотехнических библиотек.
У меня, например, на картинке они в правой колонке.

[Hoodwin]

Отлично. Труды мои не пропали зря.

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

А в базе тип указан числовой?

Не, для voltage тип указан не числовой а varchar. Но ведь Value обрабатывается ведь правильно, даже больше того, понимает единицы измерения и умеет по ним сравнивать, например, что 0.1uF > 470pF. И таких типов в принципе много: напряжение (конденсаторы, резисторы), ток (индуктивности), сопротивление (индуктивности), точность (все) и т.п.

Обычно таблицы используют для справочников и приписывают им префикс guide_.

да дело не только в префиксе, вообще хочется лишние таблицы в CIS не показывать.
Надо поизучать, может быть их можно как-то скрыть от пользователя CIS, но показать администратору базы и прочим библиотекарям.

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

Я не совсем понял, Вы в CIS Explorer видите, например, IC_LOGIC\IC_LOGIC_BUFFERS, а не Logic\Buffers?
В общем нет никакой проблемы назвать вьюхи удобными названиями, скорее проблема в том, чтобы не показывать CIS'у никаких других названий, начиная от системных таблиц и заканчивая своими же вспомогательными.

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

[vitan]

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

Ну, лиха беда - начало... А что такое дефицитка?

Не, для voltage тип указан не числовой а varchar. Но ведь Value обрабатывается ведь правильно, даже больше того, понимает единицы измерения и умеет по ним сравнивать, например, что 0.1uF > 470pF. И таких типов в принципе много: напряжение (конденсаторы, резисторы), ток (индуктивности), сопротивление (индуктивности), точность (все) и т.п.

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

да дело не только в префиксе, вообще хочется лишние таблицы в CIS не показывать.
Надо поизучать, может быть их можно как-то скрыть от пользователя CIS, но показать администратору базы и прочим библиотекарям.

Вы кого имеете ввиду под пользователем CIS? Схемотехник ничего другого и так не увидит, он будет выбирать компоненты из окошка в оркаде. А человеку, редактирующему конфигурацию CIS, можно просто объяснить, что все, что с префиксами guide_, например, не твоё.

Я не совсем понял, Вы в CIS Explorer видите, например, IC_LOGIC\IC_LOGIC_BUFFERS, а не Logic\Buffers?

Я в CIS уже не работаю (давно дело было). У меня в схематике виден просто линейный список библиотек, одна из которых называется IC_LOGIC_BUFFERS.
Но если привести эту картинку к CIS, то будет так: IC\LOGIC\BUFFERS, т.е. в виде дерева, а не просто линейный список (фактически - левая колонка, а не правая).

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

О, да. Поначалу меня тоже напрягало. Сейчас у меня уже около 70 библиотек, и новых почти не появляется. Один раз поработал пару дней, и теперь наслаждаюсь. Плюс, в новых версиях ментор (у меня ментор) наконец-то перешел на организацию описания связи библиотек с БД в виде XML, так что это теперь при желании это можно автоматизировать. Вот бы сразу бы еще это сделали, так вообще бы песня была бы.
Так что из этого следует только лишь обычная кривость\непродуманность софта (ладно, специально для Вас: отдельной части софта ), но никак не необходимость одной таблицы на все случаи жизни. Этой одной таблицей вся функциональность БД усыхает до уровня простой библиотеки, а то и еще пониже.

[Hoodwin]

Ну, лиха беда - начало... А что такое дефицитка?

Да уж...
Дефицитка (или ведомость дефицита материалов) - это такой документ, который отражает потребности в пополнении склада комплектующих с целью обеспечения производства заданного количества изделий готовой продукции. У нас пока используется построение сего документа на базе 1С:Производство, но там это реализовано несколько убого, из-за чего полноценного развития не получило. Причины такие:
1. Дефицитка от 1С не учитывает такого понятия как аналоги компонента. В результате склад может ломиться от деталей, а попадет в дефицит.
2. Насколько я помню, аналоги в 1С указываются в справочнике материалов, что вообще-то в отношении электроники неверно. Аналоги должны указываться в спецификации конкретного исполнения изделия, хотя и могут быть указаны в справочнике материалов, если действительно полные аналоги. Например, возьмем конденсатор по питанию X7R 0.1мкФ 25В 10%. Если он у меня стоит в цифровой схеме с напряжением 5В, то я могу считать его аналогом и конденсатор с напряжением и 10В, и 50В. А если он стоит в цепях источника питания на 24В, то мне вообще нужен только на 50В конденсатор. Или, другой вариант: можно ли считать аналогами свинцовую и бессвинцовую версию одной и той же микросхемы? По функциональности и собираемости на современных линиях - безусловно да, а по выполнению директивы ROHS - безусловно нет.
3. Дефицитка в простом виде не отслеживает динамику поступлений комплектующих. Если мы вчера сформировали дефицитку по деталям изделия А исполнения 1, после чего заказали их кратно катушкам, упаковкам, блистерам и т.п., а сегодня мы получили заказ на исполнение 2, в котором львиная доля деталей совпадает с исполнением 1, то сколько надо докупить? Реально можно заново начать строить дефицитку, указав в ней уже два вида изделий, и потом вычтя из общей суммы то, что уже заказано. Но это довольно быстро ведет к путанице, а бронирования деталей нет.
4. У нас со временем сложилась ситуация, когда бухгалтерия стала отказываться вставлять в нормативы изделия всякие дешевые детали вроде резисторов и конденсаторов, мотивируя это тем, что они в сумме не тянут и на 3% в себестоимости комплектующих, но при этом очень сильно затруднен учет их остатков, ну и вообще возни с ними много, а толку мало. Ну и в итоге из нормативов они стали исчезать, а при приходе катушки сразу списываются ввиду небольших цен. И вроде если для бух.учета такое упрощение вполне катит, то для обеспечения производства - совершенно не катит!

В общем, надо искать иные способы точного учета компонентов.

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

Ну поле Value носит чисто OrCAD-овскую семантику, и я не хочу ничего в нем менять. Если мне будут нужны другие функции от базы, то я создам другие поля по мене необходимости. Здесь важно именно то, что Capture понимает, что Value - размерная величина и даже умеет понимать размерность. Если сделать value типа float, то размерность пропадет, а номинал станет неудобоваримым. Придется всегда помнить, по какому эталону размерности создана каждая база. Вопрос, как то же самое распространить на Voltage, Tolerance, Power, Current, и прочие физические параметры.

Вы кого имеете ввиду под пользователем CIS? Схемотехник ничего другого и так не увидит, он будет выбирать компоненты из окошка в оркаде. А человеку, редактирующему конфигурацию CIS, можно просто объяснить, что все, что с префиксами guide_, например, не твоё.

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

Но если привести эту картинку к CIS, то будет так: IC\LOGIC\BUFFERS, т.е. в виде дерева, а не просто линейный список (фактически - левая колонка, а не правая).

Так CIS выстраивает дерево в соответствии с полем Part_Type. Но первый уровень иерархии он называет по имени таблицы в базе. Поэтому если таблица называется IC_LOGIC_BUFFERS, она и будет так смотреться в иерархии. Вот если таблица будет называться Misc, а внутри будет раздел компонентов с Pаrt_Type = IC\Logic\Buffers, то тогда да, в СIS Explorer увидим иерархию \\Misc\IC\Logic\Buffers

[vitan]

В общем, надо искать иные способы точного учета компонентов.

А что, обязательно покупать именно столько, сколько указано в этой дефицитке? Обязательно после производства иметь пустой склад? Если нет, то непонятно, зачем эта дефицитка нужна.... Есть же ВП!

Ну поле Value носит чисто OrCAD-овскую семантику, и я не хочу ничего в нем менять.

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

Если мне будут нужны другие функции от базы, то я создам другие поля по мене необходимости. Здесь важно именно то, что Capture понимает, что Value - размерная величина и даже умеет понимать размерность. Если сделать value типа float, то размерность пропадет, а номинал станет неудобоваримым.

Тут мне трудно сказать, не увидев своими глазами, но опять попахивает кривизной софта. Будем знать (я подумываю о возвращении к CIS).

Придется всегда помнить, по какому эталону размерности создана каждая база. Вопрос, как то же самое распространить на Voltage, Tolerance, Power, Current, и прочие физические параметры.

Ну, здесь никаких проблем. У меня все единицы измерения с системе СИ. Конкретно по Вашему списку: В, х100%, Вт, А. Ну и т.д, в том числе и Фарады (без дольных префиксов). Дольные и кратные расставляются в схематике (ментор позволяет, слава Богу), ну и когда надо при экспорте из БД другими средствами. Зато полная совместимость и определенность.

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

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

Так CIS выстраивает дерево в соответствии с полем Part_Type. Но первый уровень иерархии он называет по имени таблицы в базе. Поэтому если таблица называется IC_LOGIC_BUFFERS, она и будет так смотреться в иерархии. Вот если таблица будет называться Misc, а внутри будет раздел компонентов с Pаrt_Type = IC\Logic\Buffers, то тогда да, в СIS Explorer увидим иерархию \\Misc\IC\Logic\Buffers

Это детали, лично мне не составит труда сделать именно IC\Logic\Buffers. Я просто для начала Вам хотел показать простую систему (линейную), а потом более сложную. Ну вы и сами уже все поняли.

[Hoodwin]

А что, обязательно покупать именно столько, сколько указано в этой дефицитке? Обязательно после производства иметь пустой склад? Если нет, то непонятно, зачем эта дефицитка нужна.... Есть же ВП!

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

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

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

Value при закупках?! Если честно, ни разу об этом не слыхал. Для закупок мы имеем либо пару Manufacturer:Part Number, либо на худой конец Description, точнее специальное поле для заполнения спецификации по ЕСКД, которая отражает общие свойства компонента, по которым его можно запрашивать у поставщиков, например "конденсатор керамический 0603 X7R 0.1uF 25V 10%". В некоторых случаях общение с поставщиками затрудняется, если вместо обобщенного наименования им выдать, скажем, Part Number от MURATA.

Тут мне трудно сказать, не увидев своими глазами, но опять попахивает кривизной софта. Будем знать (я подумываю о возвращении к CIS).

Меня семантика Value устраивает на 100%. Скорее интересно, как это обобщить на произвольные размерные величины.
Кривизна софта совсем в другом. Я как-то назвал таблицу по-русски "Конденсаторы". И она даже появилась в списке таблиц, я все настроил для нее, сохранил конфигурацию, и началось. При попытке снова запустить CIS Configuration Cаpture вылетает. Не переваривает русские буквы в имени таблицы. Не знаю, может в новых версиях что-то изменилось, но в 16.2 так.

У меня все единицы измерения с системе СИ. Конкретно по Вашему списку: В, х100%, Вт, А. Ну и т.д, в том числе и Фарады (без дольных префиксов). Дольные и кратные расставляются в схематике (ментор позволяет, слава Богу), ну и когда надо при экспорте из БД другими средствами. Зато полная совместимость и определенность.

Так с явным указанием единицы измерения еще большая определенность Система СИ, конечно, хорошо, но я в Фарадах записывать номиналы не хочу. Например, в машиностроении приняты миллиметры и ставятся без указания "мм". И ничего. По мне так лучше 0.1uF, а не 1e-7 какие-нибудь.

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

Я почитывал ту переписку в соседнем форуме в 2010 году про затею сделать некую общественную базу через текстовый data source, распространяемый по http, но идея, боюсь, утопична. если уж делать базу, то не только для целей рисования схем. И это расходится с концепцией read-only свойств. Я уже не говорю, что это все заживет при довольно сильной унификации библиотек УГО, футринтов, моделей MCAD, и т.п., чего на самом деле и в помине нет.

Это детали, лично мне не составит труда сделать именно IC\Logic\Buffers. Я просто для начала Вам хотел показать простую систему (линейную), а потом более сложную. Ну вы и сами уже все поняли.

Да вот я тут думаю, что если уж пошла технология наследования свойств через view, то, может можно вообще все таблицы сверстать в несколько View (вообще один), в которых через Part Type развести иерархию.

А как Вы наполняете базу, если не секрет? Каковы основные принципы? Компонентов же много. Будешь прописывать в базу вообще все, что в природе есть, так жизни не хватит ее наполнить. Будешь наполнять только тем, что на складе есть, так тогда непонятно, что делать, когда хочется в схему ставить новые номиналы. С другой стороны, если вносить про все детали, то можно какой-нибудь скрипт написать, который сразу для всех компонентов создает нужные записи, например, прописывает все резисторы 0603 5% от конкретного производителя в базу, заполняя все поля автоматически. Но скрипт нужно с умом писать уметь, и на него плохо ложатся микросхемы. Но в любом случае, если работать через CIS, то нужен инструмент доступа к базе, который всегда под рукой и простой как молоток. Я даже не представляю пока, на основе чего он должен быть.

[vitan]

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

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

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

Ну да, обычное дело. Но и тут дефицитка эта как бы ни причем...

Value при закупках?! Если честно, ни разу об этом не слыхал. Для закупок мы имеем либо пару Manufacturer:Part Number, либо на худой конец Description, точнее специальное поле для заполнения спецификации по ЕСКД, которая отражает общие свойства компонента, по которым его можно запрашивать у поставщиков, например "конденсатор керамический 0603 X7R 0.1uF 25V 10%". В некоторых случаях общение с поставщиками затрудняется, если вместо обобщенного наименования им выдать, скажем, Part Number от MURATA.

Ну дык сами же пишете: 0.1uF. Это разве не value? И разве оно не участвует в закупках?
А... Понял, у Вас это забито еще и в некий доп. дескрипшен. Такие методы хранения информации мы не используем. Это как минимум дублирование, да еще и формируемое вручную наверняка. Плюс отдельно хочу заметить, что эта параметрическая форма записи не дает гарантии покупки правильного конденсатора (это мы недавно обсуждали уже).

Меня семантика Value устраивает на 100%. Скорее интересно, как это обобщить на произвольные размерные величины.

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

Кривизна софта совсем в другом. Я как-то назвал таблицу по-русски "Конденсаторы". И она даже появилась в списке таблиц, я все настроил для нее, сохранил конфигурацию, и началось. При попытке снова запустить CIS Configuration Cаpture вылетает. Не переваривает русские буквы в имени таблицы. Не знаю, может в новых версиях что-то изменилось, но в 16.2 так.

О, это я уже и за кривизну перестал считать за годы...

Так с явным указанием единицы измерения еще большая определенность Система СИ, конечно, хорошо, но я в Фарадах записывать номиналы не хочу. Например, в машиностроении приняты миллиметры и ставятся без указания "мм". И ничего. По мне так лучше 0.1uF, а не 1e-7 какие-нибудь.

Ну да, я же говорю, в схематике задается. И при экспорте задается. Но никак не в базе, и ни в коем случае не в виде текста типа "156Ом"!

Я почитывал ту переписку в соседнем форуме в 2010 году про затею сделать некую общественную базу через текстовый data source, распространяемый по http, но идея, боюсь, утопична. если уж делать базу, то не только для целей рисования схем. И это расходится с концепцией read-only свойств. Я уже не говорю, что это все заживет при довольно сильной унификации библиотек УГО, футринтов, моделей MCAD, и т.п., чего на самом деле и в помине нет.

Да, я там чуть ли не в первом посте сказал, что все заглохнет. Но зато там были полезные идеи и для меня тоже. И неважно, что я же их сам и высказывал, в основном. Без обсуждения они бы не возникли просто.
А что за концепция read-only свойств?

Да вот я тут думаю, что если уж пошла технология наследования свойств через view, то, может можно вообще все таблицы сверстать в несколько View (вообще один), в которых через Part Type развести иерархию.

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

А как Вы наполняете базу, если не секрет? Каковы основные принципы? Компонентов же много. Будешь прописывать в базу вообще все, что в природе есть, так жизни не хватит ее наполнить. Будешь наполнять только тем, что на складе есть, так тогда непонятно, что делать, когда хочется в схему ставить новые номиналы. С другой стороны, если вносить про все детали, то можно какой-нибудь скрипт написать, который сразу для всех компонентов создает нужные записи, например, прописывает все резисторы 0603 5% от конкретного производителя в базу, заполняя все поля автоматически. Но скрипт нужно с умом писать уметь, и на него плохо ложатся микросхемы. Но в любом случае, если работать через CIS, то нужен инструмент доступа к базе, который всегда под рукой и простой как молоток. Я даже не представляю пока, на основе чего он должен быть.

Я вношу в базу компоненты, которые юзаю в схемах. Никаких упреждающих компонентов и пачек резисторов не вношу. Обычно все так и работают...
Сами операции по внесению и редактированию делаются в самописаном клиенте. Скриншоты, кстати, из него. Добавление пока сделано в виде виндозного мастера, но грядут улучшения типа копирования на основе и др. Затем компоненты обычно отправляются на проверку соседу. Для этого развернута система workflow и написан процесс. Он исполняется, и если все ок, то проставляет в базе галочку "проверено". Во вьюхи для схематика попадают только такие компоненты, в клиенте видно все. Как-то так.

[Hoodwin]

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

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

Нет, Description - это крайний случай, указывается поставщику для предложения аналогов. Он не дублирует Value (номинал). Value- это вообще ущербное понятие, слишком много в ECAD на него завязано, и слишком трудно в него вложить все функции, которые нужны от свойств компонента. Поэтому я дублирую некоторые поля, зато получаю простые правила их применения в разных случаях.

А что за концепция read-only свойств?

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

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

Ну вот есть мысли накалякать морду на php, кое-какой опыт работы с другими базами на SQL через тонкий клиент есть, и в целом это довольно быстрый способ развития сервисов базы, не только для CIS.

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

Кстати, в CIS с помощью View в SQL можно запросто сделать классификатор с множественным вхождением одного компонента в несколько веток классификатора, сохранив при этом единственный источник исходных данных, избежав ручного дублирования. Не знаю, как насчет CSV, но думаю, что со статическими таблицами такое будет невозможно. Но это так, вспомнилось по мотивам того обсуждения в 2010 году.

[vitan]

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

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

Нет, Description - это крайний случай, указывается поставщику для предложения аналогов. Он не дублирует Value (номинал). Value- это вообще ущербное понятие, слишком много в ECAD на него завязано, и слишком трудно в него вложить все функции, которые нужны от свойств компонента. Поэтому я дублирую некоторые поля, зато получаю простые правила их применения в разных случаях.

Вот его-то я и называю строкой параметров. Пока не реализовано, к сожалению...

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

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

Ну вот есть мысли накалякать морду на php, кое-какой опыт работы с другими базами на SQL через тонкий клиент есть, и в целом это довольно быстрый способ развития сервисов базы, не только для CIS.

Я бы пошел дальше, и не стал ничего писать. В свое время написали, теперь не знаем, что с ним делать. Возьмите лучше сразу менторовский DMS, или, еще лучше, делайте все через Ваш Лоцман. Будет единый интерфейс и стиль работы со всеми объектами проектирования, с компонентами, винтиками, комплексами и т.п.

[Hoodwin]

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

Если Вы посмотрите даже на примеры у Cadence, то в простейших базах CIS у них имеется такая справочная информация, как cost и availability, которые по сути влияют на выбор компонента конструктором. Идея в том, что база компонентов должна быть единой, а уже CIS - это одно из ее применений. Когда баз становится несколько, неизбежно возникает задача их однозначного соответствия, то есть опять возвращаемся к вопросу о том, как объединить таблицы, а это уже и так делаем при помощи view для CIS.

Что касается пассива, то обычно мы в запросе указываем Manufacturer, Part Number, Description. Тогда поставщик либо ищет конкретный компонент, либо просто подбирает по описанию аналог от другого производителя и выставляет коммерческое предложение. Вопрос только в том, как это в базу должно попасть. Ну и еще бывает так, что в накладной поставщик пишет не исходный part number, а некоторый свой учетный. В этом случае тоже есть проблема у 1C, поскольку по по определению бухгалтерия ведет учет по первичным документам, то есть в данном случае приход комплектующих оформляется по накладным. А вот расход оформляется по данным из справочника нормативов, в который информация попадает из BOM, а в BOM, конечно, стоит настоящий part number от производителя. И в итоге постоянно приходится что-то где-то подправлять. Это еще одна причина отделить производственный учет от бухгалтерского.

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

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

Я бы пошел дальше, и не стал ничего писать. В свое время написали, теперь не знаем, что с ним делать. Возьмите лучше сразу менторовский DMS, или, еще лучше, делайте все через Ваш Лоцман. Будет единый интерфейс и стиль работы со всеми объектами проектирования, с компонентами, винтиками, комплексами и т.п.

Насчет Лоцман пока не уверен. Да и потом, проблема то упрется опять в то, кто и как будет заполнять кучу разнотипных таблиц в базе?
Так что на первом этапе нужна какая-то самопальная система работы с базой, а на втором - интеграция самой базы с сервисами других систем. Все же Лоцман:PLM - система для машиностроения по ЕСКД, и кто его знает, насколько ее гибкости хватит для освоения всех особенностей нынешнего приборостроения.

Ну вот, к примеру, обычная стандартная спецификация по ГОСТ 2.106 придумана для машиностроения, где сроду не было никаких маркировок позиционных обозначений (массово). Позиционные обозначения предлагается в ней писать в графе примечания, которая очень узкая. В итоге мы имеем огромную простыню пустых клеток в основных графах документа: Обозначение и Наименование. Зато в примечании перечисляются все 250 конденсаторов по питанию, хоть на несколько страниц. Это же очевидный косяк ГОСТа для приборостроения, и ничего другого пока нет. И вот из таких мелочей в целом складывается весь процесс...

[vitan]

Чего ради тогда базы разделять?

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

Насчет Лоцман пока не уверен. Да и потом, проблема то упрется опять в то, кто и как будет заполнять кучу разнотипных таблиц в базе?

А что, так много вариантов? Имхо всего парочка: либо сами схемотехники, либо (если есть) выделенный библиотекарь. Как - средствами лоцмана, так же, как и при внесении в базу других деталей (винтиков, элементов конструкции и прочего).

Ну вот, к примеру, обычная стандартная спецификация по ГОСТ 2.106 придумана для машиностроения, где сроду не было никаких маркировок позиционных обозначений (массово). Позиционные обозначения предлагается в ней писать в графе примечания, которая очень узкая. В итоге мы имеем огромную простыню пустых клеток в основных графах документа: Обозначение и Наименование. Зато в примечании перечисляются все 250 конденсаторов по питанию, хоть на несколько страниц. Это же очевидный косяк ГОСТа для приборостроения, и ничего другого пока нет. И вот из таких мелочей в целом складывается весь процесс...

Что Вы так за это переживаете-то? Ну будут там пустые клетки, Вам-то что?
Если у Вас внедрена система типа лоцмана, то явно Вы будете стремиться иметь подлинники в электронном виде. При этом Вы должны понимать, что оформление не играет роли. Все же делается на станках, а им ГОСТ не нужен. Следовательно Вы можете относиться к ГОСТам, в частности к виду спецификации, только как к оформительской процедуре. И выполнять ее на последнем этапе, и то, если надо отдать куда-нибудь на сторону, например. Я давно так работаю, никаких проблем.

[Hoodwin]

Вот еще какие вопросы по работе с CIS средствами SQL:
1. Правильно ли я понимаю, что столбец БД, указанный конфигуратору как Part_Number (см. рисунок) - это уникальный номер компонента в базе CIS. То есть это не Part Number производителя, потому что теоретически два разных производителя могут выдать одинаковый артикул, в особенности те, кто нумерацию ведет только строками чисел. Смысл этого номера в том, чтобы CIS однозначно мог найти компонент в базе при операциях обновления свойств и т.п. Я поначалу сделал его обычным номером производителя, но сейчас вот думаю перевести его на UUID, который SQL сервер умеет генерировать.
2. Почему перестал работать preview футпринта в CIS Explorer? Вроде бы раньше работал для smdres. Сейчас не работает. Причем пути к библиотекам прописаны, если навести курсор на это поле, то пишет правильный путь к .dra, но символ не показывает.
3. Можно ли убрать из списка таблиц все системные таблицы SQL? Ну или более точно, можно ли явно показать вполне конкретные таблицы CIS? У меня сейчас для простоты всего две (View) созданы, а при этом оно из базы высасывает конфиг от 357 таблиц, в итоге этот сонфиг в XML кушает 2.4 МБ и долго обрабатывается.
4. Наряду с системными таблицами в списке также болтаются имена view, которые были раньше, но которые я уже удалил. Откуда он их берет и как удалить?
5. Можно ли как-то перенастроить связь префиксов с пиктограммами компонентов в part manager? Например по ГОСТ микросхемы принято называть с буквы D (device), а оно при этом показывает диод. А диод по ГОСТ следует маркировать VD, но такой префикс ему вообще неведом.

Почему-то можно явно настраивать только те поля базы, которые имеют тип char, varchar, int. Всякие типы вроде datetime, UUID он не импортирует. Но это удалось сделать через конвертацию данных

Сообщение отредактировал Hoodwin - Feb 29 2012, 14:01

Эскизы прикрепленных изображений

 

[vitan]

1. Правильно ли я понимаю, что столбец БД, указанный конфигуратору как Part_Number (см. рисунок) - это уникальный номер компонента в базе CIS. То есть это не Part Number производителя, потому что теоретически два разных производителя могут выдать одинаковый артикул, в особенности те, кто нумерацию ведет только строками чисел. Смысл этого номера в том, чтобы CIS однозначно мог найти компонент в базе при операциях обновления свойств и т.п. Я поначалу сделал его обычным номером производителя, но сейчас вот думаю перевести его на UUID, который SQL сервер умеет генерировать.

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

Почему-то можно явно настраивать только те поля базы, которые имеют тип char, varchar, int. Всякие типы вроде datetime, UUID он не импортирует. Но это удалось сделать через конвертацию данных

Это везде почти так. Во многих программах, работающих с базами или около них это так. Наверно, для совместимости. Меня тоже бесит, но ничего не поделаешь. Я тоже конвертирую в текст частенько.

[Hoodwin]

ну вот я тоже всегда работал по связке MANUFACTURER:PART_NUMBER, но как я понимаю, CIS не понимает, что уникальность может задаваться двумя свойствами. В других местах вроде BOM это настраивается через combined property string, но с CIS видимо оно хочет, чтобы пользователь сам следил за уникальностью.

Вообще я тоже не встречал одинаковых кодов. Но вот у немцев частенько все коды состоят из цифр, побитых на группы дефисами, но дефисы там вещь вспомогательная, как в номере телефона. Всякие там, Harting, WAGO, Phoenix Contact, Molex, Schroff - у всех код из цифр и все. Так что теоретически может быть одинаковый номер.

[vitan]

Так что теоретически может быть одинаковый номер.

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

[VladimirZ]

2. Почему перестал работать preview футпринта в CIS Explorer? Вроде бы раньше работал для smdres. Сейчас не работает. Причем пути к библиотекам прописаны, если навести курсор на это поле, то пишет правильный путь к .dra, но символ не показывает.

В Capture.ini путь изменили?

[Hoodwin]

Ну да, пути в capture.ini прописал в раздел Allegro Footprints. Так я ж говорю, оно путь до самого .dra находит, но не кажет ничего...

[Old1]

5. Можно ли как-то перенастроить связь префиксов с пиктограммами компонентов в part manager? Например по ГОСТ микросхемы принято называть с буквы D (device), а оно при этом показывает диод. А диод по ГОСТ следует маркировать VD, но такой префикс ему вообще неведом.

В папке ...\SPB_16.Х\tools\capture\vendor\ лежат bmp-пиктограммы, с именами в виде префиксов, переименуйте как нравится...

[Hoodwin]

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

Код

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]

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

Код

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 ( 2.21 килобайт ) Кол-во скачиваний: 67
в архиве пиктограммы, что лежат у меня в tools\capture\vendor попробуте распаковать у себя...

[Hoodwin]

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

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

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

[alexa1973]

Можно ли организовать базу данных 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. Выруби звук если мешает

[Hoodwin]

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

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