Интересно, есть ли альтернативный способ создания баз данных компонентов (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, все станет понятно.

Сообщение отредактировал baken - Dec 1 2009, 09:50

Хороший способ. Иодным дизайнерам, правда, не подойдет - некуда мышкой тырцнуть Не понятно только, почему именно 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. На этой ЦБ все как раз видно - можно разобраться методом научного тыка (как раз для тех кто не любит читать документацию).
[attachment=38952:DxDataBook_ODBC.png]
3. Подключение всегда через ODBC, поэтому пункты для разных источников данных отличаются только на этапе формирования User Data Source в диалоге администрирования ODBC.
4. [attachment=38946:ODBC.png]

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