Вышел VX2.1 Опции

[fill]

Описания изменений

[dmitry-tomsk]

Описания изменений

Вот хорошо бы они ещё такую утилиту придумали, чтобы взять exel файл с базой моих компонентов нажать кнопку и раз - созданы все parts как в файле, а ещё все параметры в один строковый атрибут типа my notes. А то если есть в файле сто параметров сидеть все сто в property definition editor каждый раз прописывать, чтобы не было non-common property косяков?
В общем не хочется иметь дубляжа с dxdatabook.

[fill]

Вот хорошо бы они ещё такую утилиту придумали, чтобы взять exel файл с базой моих компонентов нажать кнопку и раз - созданы все parts как в файле, а ещё все параметры в один строковый атрибут типа my notes. А то если есть в файле сто параметров сидеть все сто в property definition editor каждый раз прописывать, чтобы не было non-common property косяков?
В общем не хочется иметь дубляжа с dxdatabook.

Не понял, задачи. Подробнее опишите процесс. Зачем вообще затаскивать доп. атрибуты? Почему нельзя просто записать значения в уже существующие? Почему каждый раз прописывать параметры?

[dmitry-tomsk]

Не понял, задачи. Подробнее опишите процесс. Зачем вообще затаскивать доп. атрибуты? Почему нельзя просто записать значения в уже существующие? Почему каждый раз прописывать параметры?

Ну скажем есть база компонентов в excel. В dxdatabook перенести - 2 минуты делов. Но потом ведь требуется для каждого part number свой part делать в центральной библиотеке. А если их в файле тысячи? Потом parts lister при создании бом требует, чтобы все свойства (поля базы) были прописаны в property definition editor, а то он их просто не видит. Потом для резисторов одни атрибуты, для конденсаторов другие, для ис - третьи. Все придётся перечислять в ЦБ, чтобы включить в бом. А можно один атрибут my notes, куда для резисторов - корпус, мощность, допуск, для конденсаторов - диэлектрик, напряжение, допуск к примеру. Тогда в ЦБ только один атрибут нужен (part label как раньше), а не кучу разных.

[fill]

Ну скажем есть база компонентов в excel. В dxdatabook перенести - 2 минуты делов. Но потом ведь требуется для каждого part number свой part делать в центральной библиотеке. А если их в файле тысячи? Потом parts lister при создании бом требует, чтобы все свойства (поля базы) были прописаны в property definition editor, а то он их просто не видит. Потом для резисторов одни атрибуты, для конденсаторов другие, для ис - третьи. Все придётся перечислять в ЦБ, чтобы включить в бом. А можно один атрибут my notes, куда для резисторов - корпус, мощность, допуск, для конденсаторов - диэлектрик, напряжение, допуск к примеру. Тогда в ЦБ только один атрибут нужен (part label как раньше), а не кучу разных.

1. Что понимается под словами "перенести в dxdatabook"?
2. У резисторов, конденсаторов и т.д. есть уже встроенный в ЦБ набор системных атрибутов которые обычно используются для разработки. Т.е. если и нужны вам лично какие-то дополнительные, то их раз два и обчелся. Если в сторонней БД 20 колонок с данными это же не значит что все данные из всех колонок надо тащить на схему.Перечислите пожалуйста все атрибуты которые вам нужны для генерирования BOM, например для резистора, конденсатора.
И даже если вам надо добавить 10-ток собственных новых атрибутов, это делается быстрее чем я потратил на написание этого текста. И делается всего лишь один раз.
Из того что вы уже написали, вот как можно к примеру привязать ваши слова к системным атрибутам:
корпус=Cell Name
мощность= Power Dissipation
допуск= Tolerance
В конфигурации dxdatabook прописывается - взять значение из колонки "корпус" и разместить на схему атрибут "Cell Name" с этим значением и т.д.

3. Любой нормальный табличный редактор имеет функции объединения данных из разных столбцов, т.е. даже в excel можно сформировать колонку с нужным вам перечислением значений, взятых из других колонок (например функция СЦЕПИТЬ для текстовых полей).
4. Можете сами написать скрипт который будет автоматом генерировать PDB, но у меня сразу возникает вопрос по каким критериям он должен это делать, ведь помимо внешнего имени Part Number у него еще и внутренность должна быть (символ, ячейка, таблица пинов). Т.е. например он должен понять что нужно взять какой-то существующий PDB, скопировать его, присвоить новое имя Part Number взятое из какой-то колонки импортируемой таблицы. Т.е. есть куча неопределенности, ответ на который есть только у вас. Т.е. написать универсальную утилиту вряд ли возможно, т.к. у каждого свое понимание как это все должно быть организовано.

[dmitry-tomsk]

4. Можете сами написать скрипт который будет автоматом генерировать PDB, но у меня сразу возникает вопрос по каким критериям он должен это делать, ведь помимо внешнего имени Part Number у него еще и внутренность должна быть (символ, ячейка, таблица пинов). Т.е. например он должен понять что нужно взять какой-то существующий PDB, скопировать его, присвоить новое имя Part Number взятое из какой-то колонки импортируемой таблицы. Т.е. есть куча неопределенности, ответ на который есть только у вас. Т.е. написать универсальную утилиту вряд ли возможно, т.к. у каждого свое понимание как это все должно быть организовано.

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

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

[fill]

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

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

На сайте пользователей ментора есть Advanced Library Editor тыц, одна из его функций
[attachment=104527:2016_12_...18_33_30.png]


И еще, похоже из "вашей оперы":
In DMS, the mapping object associates one or more symbols with one or more cells. DMS provides the capability to define generic mappings and associate multiple components to the same mapping. For example, a generic mapping may associate the symbol “resistor” with the cell “0603”. Many components may reference this mapping, so all of the component part numbers use the same symbol and cell.
The Central Library Part Editor does not support generic mappings. In the Part Editor, each part number has its own mapping. If many parts use the same symbol and cell the mapping is repeated for each part. When a Central Library is loaded into DMS, each part number will be loaded as a unique mapping, even if the result is a lot of duplicate mappings. This is not nearly as efficient as using generic mappings.
Т.е. в xDM Library есть понятие Component который имеет уникальный номер (в терминах ЦБ это аналогично Part Number) и Mapping File (в терминах ЦБ это аналогично файлу PDB). Component-ы могут ссылаться на один Mapping File. Т.е. в БД можно создать один файл привязки символа и корпуса для всех резисторов 0603 и множество Component с уникальным набором значений атрибутов. При извлечении Production Library из xDM Library, по идее, должна сформироваться ЦБ со всей этой кучей PDB под каждый резистор.