jericho 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Интересно, есть ли альтернативный способ создания баз данных компонентов (Parts) в Part Editor'e? Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... Неужели нельзя автоматизировать этот процесс? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Интересно, есть ли альтернативный способ создания баз данных компонентов (Parts) в Part Editor'e? Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... Неужели нельзя автоматизировать этот процесс? Для начала надо понять что конкретно автоматизировать. Вбивать значения в любом случае где-то все равно придется. Проще это сделать в базе данных, которая подключается к ЦБ - DxDatabook Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... А зачем их набивать в ЦБ? ИМХО мартышкин труд. Их эффективнее вбивать в Value прямо в DxD. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jericho 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба надо понять что конкретно автоматизировать Автоматизировать создание рядов элементов, к примеру. Ведь значения номиналов все равно стандартные и обозначения их (номиналов) тоже стандартные. Их эффективнее вбивать в Value прямо в DxD.А разве не нужны точные PartNumber'ы для того, чтобы потом BOM составить? (Я, конечно, недавно работаю с ЕЕ, да и проектированием печатных плат раньше не занимался, но разве для производства платы не потребуется BOM?) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Автоматизировать создание рядов элементов, к примеру. Ведь значения номиналов все равно стандартные и обозначения их (номиналов) тоже стандартные. Блин, когда же вы все научитесь грамотно и полно формулировать свои мысли :maniac: . На таким образом поставленный вопрос я могу просто ответить - выберите строчку с введенным ранее Part_Number и скопируйте нажав на соответствующую иконку. Далее в появившейся строчке копии, измените значение Part_Number и нужный параметр - например Value (если остальные параметры совпадают). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jericho 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Извините, fill, если разгневал. Проблема заключается в том, что для элементов с высокой точностью номиналов (к примеру для ряда E96) уж больно много значений PartNumber и соответствующих Value приходится вводить вручную. Следует отметить, что все значения номиналов (ряды номиналов) стандартные и способы маркировки элементов (то есть код, определяющий номинал, почти всегда входящий в PartNumber и иногда наносимый на сам элемент) тоже стандартные. Вопрос: Нет ли средства автоматизации создания серии элементов с номиналами из одного из стандартных рядов и с заданным способом маркировки? Заранее спасибо. PS. Если такого средства нет, не стесняйтесь, так и скажите, что его нет, или вы о нем не слышали, но не нужно переходить на личности и говорить, что я слишком многого хочу и т.п. PSS. Так достаточно полно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
cioma 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба Открою секрет - никто не требует чтоб "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). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 30 ноября, 2009 Опубликовано 30 ноября, 2009 · Жалоба А разве не нужны точные PartNumber'ы для того, чтобы потом BOM составить? В большинстве случаев даже вредны, так как практически вся пассивка, например, взаимозаменяема у разных производителей, важны лишь параметры. А Part Number-ы - не важны. А если важно - что тут резистор именной этой фирмы и именно этого типа - вот его отдельно и обозначить. Можно через тот же Value указав не номинал, а конкретный part number. Хотя, конечно, все зависит от системы, принятой на предприятии. Если снабженцы - просто девочки, что сказали, то и купят, это одно. А если например главный инженер совмещает со своей основной работой подбор комплектации для закупки - совсем другое. И вот в этом втором случае - точный PartNumber для каждого резюка значительно хуже, чем просто R 0805 110 Ом 1% 0.25W, указанные в аттрибутах символа в DxD. Только представьте себе, сколько лишней работы будет по поиску замены - найти этот партнамбер, скачать доку, подобрать по параметрам такой же, да еще и непонятно, какие параметры важнее, а какие пофигу. А с третьей стороны - просто потом сделать BOM-огенератор (хоть на automation, хоть в экселе, кому как нравится), который все аттрибуты преобразует в part number-ы нужного производителя. Если уж приспичит именно такой вид BOM. Но в самой либе все равно хватит по одному компоненту на один комплект символ+паттерн. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 1 декабря, 2009 Опубликовано 1 декабря, 2009 · Жалоба Извините, fill, если разгневал. Проблема заключается в том, что для элементов с высокой точностью номиналов (к примеру для ряда E96) уж больно много значений PartNumber и соответствующих Value приходится вводить вручную. Следует отметить, что все значения номиналов (ряды номиналов) стандартные и способы маркировки элементов (то есть код, определяющий номинал, почти всегда входящий в PartNumber и иногда наносимый на сам элемент) тоже стандартные. Вопрос: Нет ли средства автоматизации создания серии элементов с номиналами из одного из стандартных рядов и с заданным способом маркировки? Заранее спасибо. PS. Если такого средства нет, не стесняйтесь, так и скажите, что его нет, или вы о нем не слышали, но не нужно переходить на личности и говорить, что я слишком многого хочу и т.п. PSS. Так достаточно полно? Вот именно так и надо всегда формулировать вопрос, т.к. однозначно понятно что конкретно хочет человек добиться и в каком виде видит искомое решение. На него можно однозначно ответить - в готовом виде не существует, т.к. это было бы средство одноразового использования - сгенерил и больше не для чего использовать. В большинстве случаев даже вредны, так как практически вся пассивка, например, взаимозаменяема у разных производителей, важны лишь параметры. А 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 и система нашла его в базе (или не нашла если ручки шаловливые ранее ввели неправильное значение одного из параметров :rolleyes: ), далее убрали несколько условий (Part_Number и посадочное место) и система показала что в базе есть 3 компонента с аналогичными параметрами, выбрали аналог и присвоили его значения в схему - соответственно и схема будет соответствовать тому что пойдет на закупку и новый измененный BOM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
baken 0 1 декабря, 2009 Опубликовано 1 декабря, 2009 (изменено) · Жалоба Интересно, есть ли альтернативный способ создания баз данных компонентов (Parts) в Part Editor'e? Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... Неужели нельзя автоматизировать этот процесс? Есть, два способа. Первый способ, выучить язык Perl, написать скрипт, который генерит из вашего текстового файла (в принципе с файла любого формата с информацией о деталях) hkp файлы для Parts, затем закодировать с помощью DataConvert и импортировать в библиотеку. Второй способ не учить Perl, сделать таблицу в Excel, затем отформатировать таблицу в формате DxDatabook и пробросить эту таблицу в Access. После чего останется вбить в Library Manager вручную детали с упрощенными названиями или даже цифрами, так чтобы они соотвествовали ключевому полю деталей DxDatabook. В библиотеке будет минимальный набор данных, а основная информация для BOM уже браться из DxDatabook. Может сумбурно написал, но когда копнете DxDatabook, все станет понятно. Изменено 1 декабря, 2009 пользователем baken Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vadim 0 1 декабря, 2009 Опубликовано 1 декабря, 2009 · Жалоба Первый способ, выучить язык Perl... Хороший способ. Иодным дизайнерам, правда, не подойдет - некуда мышкой тырцнуть Не понятно только, почему именно Perl? Я вот, к примеру, предпочитаю Emacs Lisp. И макросы используемого текстового редактора пока еще никто не отменял. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
cioma 0 1 декабря, 2009 Опубликовано 1 декабря, 2009 · Жалоба Второй способ не учить Perl, сделать таблицу в Excel, затем отформатировать таблицу в формате DxDatabook и пробросить эту таблицу в Access. После чего останется вбить в Library Manager вручную детали с упрощенными названиями или даже цифрами, так чтобы они соотвествовали ключевому полю деталей DxDatabook. Зачем такие сложности? DxDatabook напрямую к Excel (и даже к CSV) может подключаться (через соответствующий ODBC-драйвер системы). Это во-первых. А во-вторых PartNumber в Central Library не обязан соответствовать "ключевому полю деталей DxDatabook". Как раз наоборот - такое соответствие убьет всю универсальность. "Ключевое поле" (uniqueID) в DxDB должно быть уникальным для каждой строки в таблице (не считая поля symbol). Как правило строка соответствует конкретному manufacturer partnumber или ordercode. Но у разных строr может (и зачастую должен) быть одинаковое поле DEVICE (которое мапируется на PartNumber). Чтоб все это понять рекомендую просто потратить время на чтение всей документации в DxD-Exp, относящейся к теме. Иначе на пальцах слишком сложно объяснять, имено изза того что есть несколько путей библиотек. А по поводу языка - рекомендую Python ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
cioma 0 6 декабря, 2009 Опубликовано 6 декабря, 2009 · Жалоба А Вы конкретный вопрос задайте, ибо в общих чертах я описал, а если с подробностями - то получится статья "Как нам обустроить библиотеки DxDesigner-Expedition?", на которую времени нет :) Для CSV есть text ODBC driver, думаю от него и стоит плясать. У нас на паре тысяч компонентов он работает нормально. Чтобы стало понятно по UniqueID - читайте все доки в \docs\pdfdocs\ (это не шутка - я сам так сделал чтоб разобраться) + supportnet, если доступ есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 7 декабря, 2009 Опубликовано 7 декабря, 2009 · Жалоба 1. В документации все подробно изложено. 2. Возьмите ЦБ C:\MentorGraphics\2007.7EE\SDD_HOME\standard\examples\SampleLib2007 в которой все сконфигурировано и сделана база SampleLib.mdb которую можно изменить как в Access так и в Base (OpenOffice) или как видите и в самом LM. На этой ЦБ все как раз видно - можно разобраться методом научного тыка (как раз для тех кто не любит читать документацию). 3. Подключение всегда через ODBC, поэтому пункты для разных источников данных отличаются только на этапе формирования User Data Source в диалоге администрирования ODBC. 4. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexN 0 8 декабря, 2009 Опубликовано 8 декабря, 2009 · Жалоба какие-то совсем некрасивые погрешности округления value - совсем нехило DxD пересчитывает!! как обычно у индийских програмеров плоховато с устным счетом. Или у них value тоже в дюймах и при пересчете туда-сюда накапливается погрешность? Или в пинтах каких-нибудь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
