Объясните пожалуйста что за странности с метрической сеткой в Symbol Editor . Символ сделанный в ИОД открваем в SE всё в порядке размер пина 5 мм шаг 5 мм всё как мне надо. Начинаю сам символ рисовать в SE размер пина округляет до 5.080 мм хотя ставлю ровно 5 мм. да и шаг сетки вроде както пересчитывает... Версия ментора 7.9 update 4 . Мне казалось что проблема с сеткой решена!?

Установите соответствующее значение Precision=High для данного символа.

Работает! СПАСИБО!!!

Теперь понятно. Спасибо!

Еще вопрос: правильно ли я понимаю, что на вкладке Noise Rules в CES мы можем промоделировать наводку одного проводника на другой. Но ведь это все более наглядно было бы сделать в HyperLynx?

Формулируем правила наводок (в виде правил параллелизма или абсолютной величины наводки), которые должна выдержать Exp (за счет встроенного упрощенного счетного ядра).

Полноценное моделирование проводим в HL.

Спасибо.

Еще вопросы:

1) что такое слой buildup, как он в Setup Parameters задается и какое отношение он имеет к переходным micro Vias?

2) В Setup Parameters есть возможность использования калькулятора - не совсем понятно, как он работает - по ширине трассы определяет сопротивление целого слоя и скорость распространения сигнала?

3) Извиняюсь за offtop: Есть ли (пусть на английском) тренинг по DxDesigner для Expedition EE7.9?

данные попадают из CES, в CES удобнее считать и работать


fill уже сообщал что им запретили на англицком распространять тренинги

Есть книга The HDI Handbook First Edition - в ней все это подробно описано.


Нажмите для просмотра прикрепленного файла

Подскажите,пожалуйста, чем отличается отверстие buidup от laminate (при создании MicroVias)?

Как известно, многие микросхемы, имея полностью одинаковую логическую организацию, выпускаются в разных корпусах с различной нумерацией выводов. Создавая в центральной библиотеке компонент (Part), можно связать физические выводы его посадочного места (Cell) и логические из его символа. Можно создать несколько компонентов, у которых будет одинаковый символ, но разные посадочные места и разная связь между физическими и логическими выводами. А теперь вопрос: получится ли номера физических выводов, соответствующих использованному в данном проекте компоненту в конкретном корпусе, передать в процессе разработки в DxDesigner, чтобы они отображались на принципиальной схеме? Если да, то как это делается?

ADD. Уже сам разобрался методом научного тыка. Tools->Package, затем выделить ножки нужных компонентов и поставить галку для значений Pin Number.

Возник такой вопрос. При создании нового посадочного места (Cell) необходимо указать тип площадки (Padstack) для каждого вывода. Когда их немного, особых проблем нет. А что делать, когда ног сотни? В окне Place Pins для каждого вывода приходится указывать площадку для каждого вывода индивидуально, что долго, нудно и т.д. Есть ли способ указать их оптом для всех выводов вообще или для определённой их части?

есть
1.выделить все с помощью кнопки с крестиками
2.стандарно через contr (shift) + ЛКМ необходимые для редактирования

Спасибо, помогло.

Что-то не могу врубиться, как указать эквивалентность не просто выводов, а пар выводов. Например, имеем преобразователь уровней на 8 линий, у которого 8 пар "вход-выход" и линии управления (типа разрешения выхода и определения направления). Понятное дело, что переставлять его "каналы" можно свободно: логически они полностью равноправны. Однако, поменяв местами входы, необходимо таким же образом менять и выходы. Вот и не пойму, как описать такую эквивалентность.

здеся

возможно ли к Cell Editor'у прикрутить какой нибудь скрипт, генерирующий отчёт о координатах всех пинов, относительно выставленного origin'a
или вообще это можно сделать в проекте?

спасибо.

Хочу спросить, как правильно решить такую задачу.

Имеется физический компонент, например, 9-контактный разъём D-Sub. Для него создан cell и некий базовый symbol, которые вместе объединены в part. Всё хорошо, всё работает. Теперь возникло желание прикрутить к этому же part'у несколько других символов -- для разных случаев стандартного использования такого разъёма (RS-232, RS-485, CAN). Но проблема в том, что у таких специализированных символов зачастую меньше девяти контактов. Соответственно, не удаётся привязать дополнительные символы к уже существующему part'у, если число выводов у них не совпадает с заданным изначально. Не удаётся и выставить типы выводов индивидуально для каждого символа.

Собственно, желание засунуть несколько разных символов в один part возникло из-за того, что сам физический компонент всегда один и тот же, меняются лишь его логические функции. При заказе комплектующих и сборке, понятное дело, смотрят на физический компонент, а не на его назначение, а вот на принципиальной схеме лучше видеть обозначение, соответствующее требуемым от компонента функциям (т.е., если это разъём для RS-232, то видеть "табличный" разъём с именами сигналов RS-232, если CAN -- то его разъём и т.д., ну а при генерации списка комплектующих или там при передаче в Expedition видеть уже физические разъёмы). По этой причине и не хочется создавать отдельные part'ы для разных логических функций одного и того же компонента. Как посоветуете поступать в подобных случаях?

как уже выше написано, в любом случае для отдела комплектации необходимо иметь наименование 9-контактный разъём D-Sub - DB9M или DB9F
но кто мешает использовать символьный элемент с 9 ногами который имеет несколько вариантов изображения у которых в схеме не используются часть ног и с разным функционалом ног.
да, придется у всех символов функционал пина обозначить просто текстом и устоановить соответствие в таблице пинов Name=PinNumber и PinType=Analog

Ну, мешать-то никто не мешает, просто, ИМХО, на схеме красивше выглядит более лаконичное изображение, где неиспользуемые ноги отсутствуют в принципе... Но, раз это невозможно, сделаю несколько символов с неиспользуемыми ногами, как рекомендуете

Тем временем возникла ещё пара вопросов, и оба снова связаны с символами. Во-первых, я хотел настроить генерацию Ref Des'ов вида DD4.1 или чего-нибудь ещё в этом духе для символов, которые упаковываются по несколько штук в один корпус. Однако после изучения документации сложилось ощущение, что сделать это сколько-нибудь простыми средствами невозможно, и все символы, относящиеся к одному корпусу, будут после упаковки иметь одинаковые Ref Des'ы. Я прав, или есть-таки способ решить эту задачу?

Ну и второй вопрос. В DxDesigner есть средство замены символов (Edit -> Replace Symbol... или то же самое в контекстном меню при выделении символа). Однако оно, судя по моим экспериментам и содержанию диалогового окошка, работает только с заранее выделенными символами. Нет ли аналогичного механизма, позволяющего заменить все символы с определённым Part Number на символы с другим Part Number? Мне это однажды понадобилось, когда влепил серию неправильных конденсаторов (не на то напряжение), и пришлось достаточно долго и нудно их заменять на правильные.

Этот механизм называется DxDataBook

здеся

Хоть убейте, не пойму, как с помощью DxDataBook можно заменять одни компоненты на другие...



Значит, предчувствия меня не обманули... Жаль, конечно, но не смертельно: пока идёт разработка, "правильные" Ref Des не очень-то и нужны, ну а в чистовой можно и ручками подписать.

Вы привели пример, когда меняли кучу конденсаторов на другие напряжения.
Замена в DxDatabook делается путем переноса из базы нужных свойств в схему. В данном случае достаточно было бы (в пределе) заменить свойство VOLTAGE. Этот процесс называется аннотацией атрибутов в схему,точнее, прямо в УГО.
Вы спросите: что делать, если у меня для каждого VOLTAGE свой компонент? Правильно, у меня то же самое.
В этом случае заменяется не одно свойство у УГО, а сразу несколько, в т.ч. и DEVICE. В результате перед упаковкой компонент превращается в другой.
Проверку и замену любых свойств можно делать для любых компонентов, в т.ч. для группы предварительно выбранных компонентов и вообще для всех сразу в схеме.

Тааак... А это работает с центральной библиотекой? Ведь, судя по документации, "нормальное" использование DxDatabook предполагает создание конфигурационного файла, в котором в качестве источника данных для неё указывается какая-либо ODBC-база, а не центральная библиотека, ну а если проект базируется на ЦП, то DxDesigner сам увязывает DxdDatabook с библиотекой, но при этом мало что доступно. Или я жутко туплю?

Тут я в свое время затевал тему, почитайте. Хотя в ней так и не ответили на заглавный вопрос... Но про ЦБ там рассказывали.

Там лишь упоминается о том, что DxDatabook используется и с ЦБ -- а это я и сам знаю, ведь именно оттуда беру компоненты, когда принципиальную схему создаю. Однако про "продвинутые" функции типа замены свойств там ничего нет. В общем, похоже, что это работает только при использовании списка цепей...

Не понял, Вы уже работаете с databook?
Выделите компонент, сделайте verify. В окошке databook ткните на найденный компонент (если он найдется, конечно) правой кнопкой и нажмите remove all conditions. Выберите новый компонент, тот, на который надо заменить. Нажмите Annotate unique.

Так нету Verify для компонента. Есть такой пунктик в меню Tools, но он проверяет всю схему целиком или какой-то её иерархический кусок (насколько я понял; могу ошибаться, ибо пока не вникал). А так, чтобы щёлкнуть на компоненте и сказать ему Verify -- такого нет. Есть в контекстном меню пунктик Load into DxDataBook, но он невыберабельный (серенький).

Это кнопка в окне databook, она открывает новую вкладку для проверки компонентов по базе.
Вы не ответили, у Вас сам databook есть и настроен?

DxDatabook есть, поскольку компоненты выбираются из него. Настраивать он не настраивался, поскольку он запускается автоматически самим DxDesigner'ом, если последний работает с ЦБ. Вот путь к ЦБ прописывается в свойствах проекта.

Ну а кнопки такой в DxDatabook нету. Прикладываю скриншот его открытого окна: там разделы моей ЦБ, и всё.

Понятно. Это в 2007 всё объединили под именем DxDatabook.
Кнопка есть, она на Вашем скриншоте слева третья сверху. И четвертая еще для проверки всего проекта.
Чтобы она заработала, нужно открыть конфигурацию из файла .dbс (попробуйте по правой кнопке). После этого должны появиться новые вкладки и должна заработать эта кнопка. Файл .dbc и саму базу возьмите для начала из менторовских примеров на диске.

Так ведь .dbc задаёт конфигурацию DxDataBook для работы с базой данных ODBC, а ЦБ ими не пользуется, она всё сама организует. Поэтому и DxDataBook благополучно работает после того, как в свойствах проекта указан путь к ЦБ -- но работает только верхняя из тех кнопок, New Search Window.

Собственно, можно взять, как Вы советуете, готовый .dbc файл, но это же включит ту самую БД ODBC, что несовместимо с центральной библиотекой, насколько могу судить. Хотя попытка не пытка, попробую...

С чего это такие выводы? Вам же показали скриншот работы одновременно с ЦБ и БД.

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

Если я указываю учебную конфигурацию (.dbc), но свою ЦБ, то через кнопочку Show CL View я вижу именно свою ЦБ, а New Search Window даёт доступ к библиотекам-таблицам БД ODBC (MS Access в данном случае, но это роли не играет: в PADS я уже успел убедиться, что нормально и MySQL работает -- лишь бы драйвер ODBC был). Но возникает вопрос: а можно ли нормально работать, имея и пополняя свою ЦБ, но при этом используя "левую" (учебную, например) базу ODBC, содержимое которой мне лично совершенно не нужно? Ведь никакой синхронизации между ними, понятное дело, в такой ситуации не будет...

ADD. Уже проверил. Размещать компоненты из моей ЦБ можно, но все эти проверки неработоспособны: они рассчитывают найти данные в ODBC-базе, а там их, естественно, нет. Ну а вести параллельно две базы -- это чистый мазохизм. В общем, странно как-то это дело организовано...

Для понимания присходящего нужно всегда помнить, что маршрут DxD-Exp есть сборная солянка купленых ментором продуктов, которые присобачены друг к другу с помощью молотка, мата и поллитры

Вследствие этого есть несколько способов разработки библиотек:

- Symbol - графика символа, распиновка и свойства (properties) хранятся в файле символа (e.g. sym.1, sym.2 etc). Это наследие Viewlogic ViewDraw.

- Central Library - графика символа хранится в файле символа, распиновка и свойства хранятся в разделах деталей (part, файлы *.pdb) в Central Library. Это наследие Veribest Design Capture (если не ошибаюсь).

- DxDataBook - графика символа хранится в файле символа, распиновка хранится в разделах деталей в Central Library, а свойства хранятся в базе данных к которой стыкуется DxDesigner через DxDataBook. DxDataBook появился у Viewlogic, а ментора скрестил его с Central Library.

Эти три пути можно мешать. Но не нужно.

Вариант DxDatabook по моему мнению наилучший (гибок, нет дублирования данных итп)

И читайте .../7.9.2EE/docs/pdfdocs/dxdb_user.pdf

cioma, дык этот документ, как прочие, читаем-с, только вот не очень помогает Создать саму БД и подключить её по ODBC к DxDataBook -- не проблема; я это успешно сделал, когда PADS смотрел, и всё работало нормально. Однако заполнять базу информацией -- это жуть, поскольку штатных средств для этого нет. Для PADS я просто создавал записи операторами SQL, но это ж извращение, а не работа, если говорить о постоянном использовании, а не реализации мелкого проектика для того, чтобы посмотреть на саму САПР. С ЦБ в этом смысле много проще и удобней: всё, что нужно, вводится штатными редакторами, вызываемыми централизованно из Library Manager; автоматически отслеживаются всякие там взаимосвязи (например, переименование контактной площадки будет отражено в посадочных местах и через них -- в компонентах), ну и т.д.

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

Ну, это Вы больно круто загнули... Это, скорей, у Вас несварение (непонимание).
Способ работы каждый выбирает сам. Главное, что они есть, в отличие от многих других продуктов других фирм.


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


У кого-то мелкие проектики, а кому-то надо отслеживать тысячи компонентов.
Здесь тоже несколько вариантов:
1. Писать свой клиент. Нормальный вариант, сейчас пока сам так работаю.
2. Поставить что-нибудь готовое. Типа DMS от того же ментора. Для продвинутых.
3. Не мучиться, и сразу интегрировать работу с базой в корпоративную PDM-систему. Для тех, у кого есть.

В общем, что выберете, то и будет.

Да понятно, что у меня оно имеет место быть: если б всё понимал, то не задавал бы вопросы, а отвечал бы на них Но это по-любому не отменяет того факта, что целый ряд ограничений носит странный, а то и откровенно нелепый характер. Если говорить про мои конденсаторы, то, казалось бы, что проще: сделай в диалоге Replace Symbol полноценный выбор диапазона замены (только выделенные либо все в проекте/плате/схеме/листе) -- и проблема решена, будет работать всегда и везде. Но такого пока нет и неизвестно, будет ли когда-нибудь... То же самое можно сказать насчёт поддержки национальных шрифтов: Unicode существует не один год и даже не одно десятилетие, если память не изменяет (вроде бы ещё в 1980-х годах появился), но о нём, похоже, и не слыхивали. Запрет пробелов в путях -- в наши дни тоже из области как минимум жуткого анахронизма. Ну и т.д.



Ага, в этом конкретном случае проще было бы, наверное, с ODBC-базой. Но вот вести её -- мучение. Писать свой клиент -- да, можно, но это ж лишние затраты времени, особенно если делать хороший, удобный клиент; да и в любом случае централизации не будет, а значит, возможно рассогласование данных в ЦБ и ODBC-базе. DMS, насколько понимаю, работает только с СУБД Oracle, что как бы предполагает размер компании-пользователя -- крупная корпорация. Для Expedition это в какой-то мере можно признать разумным, но никак не для PADS -- он-то по своей цене подходит и для небольших фирм, у которых может не быть возможности (да и реальной нужды) обзавестись Oracle, PDM или даже написать свой клиент. В общем, в этом плане у MG подход откровенно странный.

Кстати говоря, я не жалуюсь. Я просто недоумеваю, как крупная и серьёзная компания может столь безалаберно относиться к одному из основных своих продуктов. Правда, так поступает и основная масса других крупных и серьёзных компаний, и вроде бы пора привыкнуть к этому, но никак не могу

Не знаю, как сейчас, а в 2005 это есть в точности так.


Есть еще Postgre.
В конце концов, чем не устраивает работа как на скриншоте с аксессовской базой?

Приложил скриншот окошка Replace Symbol/Part. Как видим, там есть возможность замены только выделенных символов, что не всегда удобно (мне-то надо было заменить все конденсаторы, а не несколько штук).




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

Вам не удобно вписывать значения в ячейки таблицы как на картинке? Т.е. Вы уже первый уровень прошли? Но до второго (до клиента) еще не дошли? Надо двигаться. Либо туда, либо обратно.


Почему? На картинке же параметры приведены прямо для тех компонентов, которые есть в ЦБ. Что здесь не синхронизировано-то?

1. DxDatabook дает возможность не вводить параметры атрибутов внутри PDB, а вносить их в таблицах (что более удобно). Таблицы можно заполнять непосредственно в LM
В http://megratec.ru/data/ftp/exp_movie/new/ специально выкладывал видео как это работает. Например DxDatabook_LM.avi или LM_DxDataBook.avi
2. Там же есть несколько видео по вариантам замены компонентов - например DxD_Change_PDB.avi, DxD_change_part_DxDatabook.avi ....
Т.е. задача решается как минимум несколькими способами:
- DxDataBook
- Replace_Text - достаточно изменить значение Part Number и после Package остальные значения атрибутов заменятся на значения из PDB (если конечно установили галочку).
- Find (найти и выбрать все нужные компоненты) + Replace_Symbol (заменить все выбранные)
3. Смотрите на название видео в указанном месте - обычно по нему понятно содержание.
4. Наиболее оптимальным выглядит маршрут ЦБ+DxDataBook. т.к.
- Есть поиск по значениям атрибутов,
- Проверка соответствия значений на схеме, тем что есть в базе,
- Атрибуты проще вводить\редактировать в таблице а не в PDB Editor.
- Есть возможность подключить дополнительные данные, например datasheet



Нажмите для просмотра прикрепленного файла

fill и vitan, большое спасибо. До выделения всех компонентов с помощью Find сам я не допёр, а ведь это решило бы ту мою проблему "малой кровью", так что возьму на заметку.

Что до использования ODBC-базы -- попробую, раз её таблицы можно заполянть средствами Library Manager (я правильно сей момент понял?). А то писать свой клиент желания никакого, хоть на Дельфях это и быстро делается



По той причине, что, если ODBC-база заполняется сторонними средствами, а не через Library Manager, то последний в принципе не имеет возможности отслеживать соответствие информации в этой базе и в ЦБ. Например, из ЦБ можно удалить компонент или поменять его Part Number, ну а в ODBC-базе всё останется старое -- вот и рассинхронизация. Следить за таким придётся исключительно самому, что не шибко удобно и чревато возникновением ошибок.

На самом деле расхождение базы и ЦБ сразу отслеживается в проекте:
В DxDataBook есть два вида верификации (на один лист и на весь проект), соответственно если измените имя Part Number, то или верификация выдаст ошибку или упаковщик (смотря где произошло расхождение).

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

А видео скачал все подряд: буду изучать, ведь потенциальных вопросов много, просто решаю их по мере реальной необходимости. Например, надо будет разбираться, как правильно сделать из медного полигона радиатор, как использовать CES для контроля за разводкой цепей памяти и дифпар (мой-то случай пока что простой, всё можно и "глазуально" проконтролировать, но надо ж освоить)...

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

Да, это проблема. Она решается только клиентом. Но его надо писать, или пользовать варианты по списку выше. В общем, замкнутый круг.
Это, кстати, одна из причин, по которой я не веду ЦБ.

здеся

Вопрос к топикстартеру: а какую базу данных для DxDB используете? Ну или планируете использовать?

Если не нужен параллельный доступ нескольких библиотекарей, и количество компонентов в районе тысяч, то даже одним обычным .csv файлом можно обойтись. И редактировать его в Calc или Excel.

Ну а связь с ЦБ надо контролировать вручную, или присать свои приблуды. Хотя связь эта обычно осуществляется по единственному полю "Part Number", а потому не особо напрягает.

Они и не будут возникать при грамотно построенной работе.
Добавил Part Number, переключился в таблицу и ввел его атрибуты. Это ведь все равно надо делать где-то, не в таблице так в PDB.
А ЦБ вы не ведете только по тому что не работаете в Exp. Иначе без ЦБ никуда не деться - посадочные места и т.п. где то же должны создаваться\хранится.

А если добавить сначала в базу, то это уже неграмотно разве? Нет, тут все-таки не хватает некоего синхронизатора.


Как? А что, просто по нетлисту с EXP уже нельзя работать? Чтобы футпринты просто файлами лежали? Я припоминаю, что можно было, а при упаковке создавалась некая Local PDB. Но это же не ЦБ!