Интересно, есть ли альтернативный способ создания баз данных компонентов (Parts) в Part Editor'e? Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... Неужели нельзя автоматизировать этот процесс?

Для начала надо понять что конкретно автоматизировать. Вбивать значения в любом случае где-то все равно придется. Проще это сделать в базе данных, которая подключается к ЦБ - DxDatabook

А зачем их набивать в ЦБ? ИМХО мартышкин труд. Их эффективнее вбивать в Value прямо в DxD.

Автоматизировать создание рядов элементов, к примеру. Ведь значения номиналов все равно стандартные и обозначения их (номиналов) тоже стандартные.
А разве не нужны точные PartNumber'ы для того, чтобы потом BOM составить? (Я, конечно, недавно работаю с ЕЕ, да и проектированием печатных плат раньше не занимался, но разве для производства платы не потребуется BOM?)

Блин, когда же вы все научитесь грамотно и полно формулировать свои мысли . На таким образом поставленный вопрос я могу просто ответить - выберите строчку с введенным ранее Part_Number и скопируйте нажав на соответствующую иконку. Далее в появившейся строчке копии, измените значение Part_Number и нужный параметр - например Value (если остальные параметры совпадают).

Извините, fill, если разгневал.

Проблема заключается в том, что для элементов с высокой точностью номиналов (к примеру для ряда E96) уж больно много значений PartNumber и соответствующих Value приходится вводить вручную. Следует отметить, что все значения номиналов (ряды номиналов) стандартные и способы маркировки элементов (то есть код, определяющий номинал, почти всегда входящий в PartNumber и иногда наносимый на сам элемент) тоже стандартные.

Вопрос: Нет ли средства автоматизации создания серии элементов с номиналами из одного из стандартных рядов и с заданным способом маркировки?

Заранее спасибо.

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

PSS. Так достаточно полно?

Открою секрет - никто не требует чтоб "PartNumber" в Central Library и manufacturing partnumber совпадали (даже частично). "PartNumber" - это по сути уникальный идентификатор связывающий symbol, cell и pinmapping. Всё! Никаких value, tolerance итп в Part задавать не надо (хотя система это позволяет). Атрибуты типа value итп берете из DxDataBook. В итоге получаем наиболее универсальную и generic библиотеку.

Тут основная путаница изза того что ментор скрестил ежа с ужом (Design Capture и DxDesigner + куски Design Architect) и в итоге получили как минимум 3 library frow - атрибуты в символах (от DxDesigner), свойства в part (от Design Capture), атрибуты во внешней таблице (DxDataBook).

В большинстве случаев даже вредны, так как практически вся пассивка, например, взаимозаменяема у разных производителей, важны лишь параметры. А Part Number-ы - не важны. А если важно - что тут резистор именной этой фирмы и именно этого типа - вот его отдельно и обозначить. Можно через тот же Value указав не номинал, а конкретный part number. Хотя, конечно, все зависит от системы, принятой на предприятии. Если снабженцы - просто девочки, что сказали, то и купят, это одно. А если например главный инженер совмещает со своей основной работой подбор комплектации для закупки - совсем другое. И вот в этом втором случае - точный PartNumber для каждого резюка значительно хуже, чем просто R 0805 110 Ом 1% 0.25W, указанные в аттрибутах символа в DxD. Только представьте себе, сколько лишней работы будет по поиску замены - найти этот партнамбер, скачать доку, подобрать по параметрам такой же, да еще и непонятно, какие параметры важнее, а какие пофигу.

А с третьей стороны - просто потом сделать BOM-огенератор (хоть на automation, хоть в экселе, кому как нравится), который все аттрибуты преобразует в part number-ы нужного производителя. Если уж приспичит именно такой вид BOM. Но в самой либе все равно хватит по одному компоненту на один комплект символ+паттерн.

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



На самом деле это вопрос решаемый индивидуально на каждом предприятии- кому какой процесс больше нравится.
Если используется DxDataBook и создана корпоративная база данных, то все решается достаточно просто - разработчик выбрал конкретный Part_Number с нужными ему параметрами (воспользовавшись для поиска и вставки DxDataBook)и сгенерировал BOM, далее при обработке BOM в отделе закупки выяснили что этому Part_Number есть несколько аналогов. Вариантов реализации поиска аналогов несколько, например доп. столбец в базе с перечислением аналогов или даже сам DxDataBook можно использовать для такого поиска - например Видео в котором показано, что выбрали компонент в DxDesigner, загрузили его атрибуты в DxDataBook и система нашла его в базе (или не нашла если ручки шаловливые ранее ввели неправильное значение одного из параметров ), далее убрали несколько условий (Part_Number и посадочное место) и система показала что в базе есть 3 компонента с аналогичными параметрами, выбрали аналог и присвоили его значения в схему - соответственно и схема будет соответствовать тому что пойдет на закупку и новый измененный BOM.

Есть, два способа.
Первый способ, выучить язык Perl, написать скрипт, который генерит из вашего текстового файла (в принципе с файла любого формата с информацией о деталях) hkp файлы для Parts, затем закодировать с помощью DataConvert и импортировать в библиотеку.
Второй способ не учить Perl, сделать таблицу в Excel, затем отформатировать таблицу в формате DxDatabook и пробросить эту таблицу в Access.
После чего останется вбить в Library Manager вручную детали с упрощенными названиями или даже цифрами, так чтобы они соотвествовали ключевому полю деталей DxDatabook.
В библиотеке будет минимальный набор данных, а основная информация для BOM уже браться из DxDatabook.
Может сумбурно написал, но когда копнете DxDatabook, все станет понятно.

Хороший способ. Иодным дизайнерам, правда, не подойдет - некуда мышкой тырцнуть Не понятно только, почему именно Perl? Я вот, к примеру, предпочитаю Emacs Lisp. И макросы используемого текстового редактора пока еще никто не отменял.

Зачем такие сложности? DxDatabook напрямую к Excel (и даже к CSV) может подключаться (через соответствующий ODBC-драйвер системы). Это во-первых. А во-вторых PartNumber в Central Library не обязан соответствовать "ключевому полю деталей DxDatabook". Как раз наоборот - такое соответствие убьет всю универсальность. "Ключевое поле" (uniqueID) в DxDB должно быть уникальным для каждой строки в таблице (не считая поля symbol). Как правило строка соответствует конкретному manufacturer partnumber или ordercode. Но у разных строr может (и зачастую должен) быть одинаковое поле DEVICE (которое мапируется на PartNumber).

Чтоб все это понять рекомендую просто потратить время на чтение всей документации в DxD-Exp, относящейся к теме. Иначе на пальцах слишком сложно объяснять, имено изза того что есть несколько путей библиотек.

А по поводу языка - рекомендую Python

А Вы конкретный вопрос задайте, ибо в общих чертах я описал, а если с подробностями - то получится статья "Как нам обустроить библиотеки DxDesigner-Expedition?", на которую времени нет
Для CSV есть text ODBC driver, думаю от него и стоит плясать. У нас на паре тысяч компонентов он работает нормально. Чтобы стало понятно по UniqueID - читайте все доки в \docs\pdfdocs\ (это не шутка - я сам так сделал чтоб разобраться) + supportnet, если доступ есть.

1. В документации все подробно изложено.
2. Возьмите ЦБ C:\MentorGraphics\2007.7EE\SDD_HOME\standard\examples\SampleLib2007 в которой все сконфигурировано и сделана база SampleLib.mdb которую можно изменить как в Access так и в Base (OpenOffice) или как видите и в самом LM. На этой ЦБ все как раз видно - можно разобраться методом научного тыка (как раз для тех кто не любит читать документацию).
Нажмите для просмотра прикрепленного файла
3. Подключение всегда через ODBC, поэтому пункты для разных источников данных отличаются только на этапе формирования User Data Source в диалоге администрирования ODBC.
4. Нажмите для просмотра прикрепленного файла

какие-то совсем некрасивые погрешности округления value - совсем нехило DxD пересчитывает!! как обычно у индийских програмеров плоховато с устным счетом. Или у них value тоже в дюймах и при пересчете туда-сюда накапливается погрешность? Или в пинтах каких-нибудь?

Так это ж наверно, с учетом паразитарных

кстати, интересно, если в строке поиска задать =100nF, DxD найдет 100.0000011686nF - формально не должен, если только это не погрешности отображения на экране. Может быть кто-нибудь попробует?

Глюк конечно, как обойти:
в конфигурации на отображение поменять формат вывода вручную на %.3f (предлагаемые из списка %.f, %.10f, %.16f приводят к этой ерунде).
И перезапустить DxD.

В списке ошибка - там %f вместо %.f
Если поставите вручную %.f тоже получите искомый результат.

ошибка не просто в списке (хоть и в списке тоже) - неужели при увеличении количества знаков дробной части величина должна меняться - ведь в базе четко задано (например 0.0000001 а не 0.000000100000186). Или это "типа компиляторы кривые"?
И зачем там в списке вообще 10 знаков после запятой и тем более 16 знаков после запятой? Ну да ладно. Мелочи, но какие-то .. как в известном фильме "все это так непрофессионально..." (Мюллер, "17мгн. весны")

Это не компиляторы кривые - это реализация кривая. Они используют формат с плавающей запятой (float) для хранения значений. А теперь попробуйте представить 0.0000001 в двоичной системе - это бесконечная дробь (как 1/3 в десятичной системе), отсюда и получаем реальное значение, что хранится в базе равным 0.000000100000186. Возможно, со стороны пользователя это можно обойти если хранить значения как integer c единичным значением, соответствующим малой величине (например 1 мкОм, для резисторов)

а я почему-то раньше думал, что float - это мантисса (целое число с довольно большой разрядностью) и порядок (тоже целое). по идее в нашем случае мантисса это типа 100000000 (а не 1000001186) а порядок - ...ну сами прикиньте. В противном случае ракеты вообще летать не должны - погрешность просто дикая (на мой взгляд).

исследуем дальше. Собственно все ясно. Скорее всего, представление value в DxD - плавающее с двойной точностью. А в sampleLib.mdb - плавающее с одинарной точностью. При изменении типа поля value в sampleLib.mbd на двойную точность все это и имеем.
Итог: при создании своей базы данных желательно использовать для value тип данных "двойное с плавающей точкой". Тогда артефакты исчезнут.

в этом случае дробная часть не отображается совсем (посмотрите, вместо 3.3uF отображается 3uF)

Согласен.

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

Я извиняюсь, но можно для тех, кто на бронепоезде?
Если у меня microsoft sql server, то какой тип данных ставить? Перепробовал все, что можно, но в каждом варианте свои проблемы.
При этом с access-ом все хорошо.
Нужно, чтобы нормально отрабатывала функция automatic magnitude, и при этом хранимые числа были от 0,000000000000001 (1фемто) до "как можно больше".

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

можно, только поиск по "больше-меньше" работать не будет

почему? Просто у строк критерии "больше-меньше" другие, сравниваются коды первых отличающихся символов. Да и я не уверен, что поиск по "больше-меньше" актуален. Тут ведь нужен всегда вполне определенный номинал, и как правило из заранее извесного ряда.

Плюс еще вот что... Я например в номинале храню "разновидности" микросемы - например компонент TPS6220x, а номинал - TPS62207

Поиск по "больше-меньше" и по диапазону актуален, ибо база может использоваться не только разработчиками, но и логистами, бухгалтерами и т.п. Им может потребоваться создавать, например, запросы для оценки стоимости комплектующих и т.п.
Я лично, думаю, что в номинале нужно хранить номинал, т.е. основную характеристику компонента. У меня номиналы вообще хранятся под истинными названиями, например "Resistance" для резисторов. При аннотации в схему происхдоит замена его на VALUE.
Только вот проблема: как перевели базу на SQL SERVER, начали возникать описанные выше эффекты. Кто-нибудь использует такую же конфигурацию? Какие типы полей нужны для чисел?

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

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

Это укор ментору только в том случае, если он не поддерживает тип string в этом поле. А вообще - руководство к действию. Не надо путать разные по природе вещи - для языков программирования важен компромис по скорости обработки и занимаемому объему, а тут - эти критерии не работают. Тут важна универсальность. Не на столько велик объем этих БД, чтобы не конвертировать строки в числа в процессе обработки (сортировки, поиска и т.п.). Да и можно по ходу по мере добавления новых записей разгребать строковый полноценный value в отдельные новые (возможно скрытые) поля с числовым значением номинала, разбросом, и т.п. для ускоренной сортировки-поиска-обработки, опять же сторонними от ментора средствами работы с БД. Правда для ведения такой БД понадобится специально обученный специалист... Но я думаю, что там, где такая БД нужна в принципе, это оправдано.

Таким образом мы признаем, что в менторе реализация не очень-то правильная.
Может, все-таки кто-нибудь подобрал форматы так, чтобы не глючило? Ну никак не хочется ставить string и отказываться от automatic magnitude...

а что, sql server не поддерживает передачу double float из базы? так это может проблема его настройки или в начальной базе поле value просто float (не double)

Я согласен что string - наиболее универсальный вариант, сам его использую.
А вообще есть дикая идея написать замену DxDB с использованием automation в EE2007, с нормальной реализацией взаимодействия с базами данных. Ибо DxDB не позволяет сделать библиотеки настолько гибкими и универсальными как мне требуется. Но пока это только идея

Проверка не проходит. В схеме атрибут такой же, как в БД, но почему-то выделяется красным. Весь компонент, соответственно, тоже.


А что за гибкость нужна, если не секрет? В смысле, чем не устраивает?

Я считаю, что библиотека должна быть как можно более универсальной и наименее избыточной (данные не должны дублироваться). Из этого следует, что глобальная библиотека (от логистики до сборки и поддержки) должна остоять из нескольких уровней. Для САПР печатных плат по сути нужны 4 составляющие: symbol, landpattern, pinmapping (symbol to landpatterm) и некоторые атрибуты для отображения на схеме. Для различных симуляций нужна ссылка на модели, для логистики нужна ссылка на список взаимозаменяемых комопнентов. Причем все эти параметры могут зависеть от проекта: один и тот же компонент может требовать разных посадочных мест для разных плат, или для одного устройства значение ТКС резисторов 0603 значение имеет, а для другого нет, но символы, посадочные места и маппинг резистора в обоих случаях идентичен.
Все это и приводит к идее создания generic library (без привязки к ментору или кому-либо еще) и интерфейсов в различным САПР итп.

Это все верно и правильно, но dxdb чем Вам не угодил? Он же как раз только для схем.
Настраиваете себе библиотеки с паттернами, символами и параметрами для моделирования и занимаетесь проектированием. А параллельно остальной народ, пользуясь той же базой, делает закупки, бумажки и т.п.

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

Ну, не знаю... Мы вот, хоть и свою систему пишем, но и про DxDB не забываем.
А вообще, если деньги есть, обратите внимание на менторовский DMS, там как раз все что надо. Даже в кейденсовский концепт можно компоненты из базы вставлять. И связи, и уровни, все есть. Жаль, самого его нет.

Знаю я DMS, туда лучше вообще не соваться - засосет )
Тут основная проблема в том, что при использовании DMS пользователь должен подстраиваться под ментор, а должно быть наоборот.