Только начал осваивать PADS. Поглядел уроки, более-менее их повторил, ну а дальше решил сделать для начала свой набор шаблонов проектов, прицепить к ним свои форматки и т.д. и т.п. Судя по документации, пользовательские шаблоны являются обычными prj-файлами и должны лежать в каталоге %WDIR%\templates\dxdesigner\netlist; стандартные шаблоны лежат в %SDD_HOME%\standard\templates\dxdesigner\netlist. WDIR настроен правильно, каталоги в Dashboard'е смотрятся без проблем, однако стандартные шаблоны DxD у меня успешно видит, а мои собственные -- не желает ни в какую. Если стандартные удалить или ещё как спрятать, то вообще никаких шаблонов не остаётся, и он не позволяет создать новый проект. Никто с таким не сталкивался?

Если свои ложите в %SDD_HOME%\standard\templates\dxdesigner\netlist тоже их не видит?
Если видит, то явно что-то не то с WDIR.

Поэкспериментировал и разобрался, в чём причина.

Я создавал свой шаблон с именем default.prj. Поскольку в системе существует стандартный шаблон с таким именем, я, чтобы точно знать, что DxD "видит" именно мой шаблон, а не стандартный, просто переименовывал весь стандартный каталог templates. В результате DxD вообще никаких шаблонов не видел, хотя WDIR была абсолютно корректной, а мой default.prj лежал в правильном каталоге. Теперь же я не стал переименовывать весь стандартный templates, а переименовал лишь находящийся в нём стандартный default.prj. После этого DxD сразу стал видеть все три других стандартных шаблона, а также мой default.prj.

В общем, впечатление такое, что DxD, если не обнаруживает стандартный каталог templates, просто прекращает поиск шаблонов, хотя логичнее выглядело бы продолжение просмотра каталогов, определённых в WDIR.

Появился новый вопрос. Создал базу данных, подключил её таблицы к DxDatabook через ODBC (каждой таблице соответствует своя библиотека -- резисторы, конденсаторы и т.д.). Но таблицы, естественно, пустые. Насколько понимаю, для создания некоего библиотечного (не локального для проекта) компонента нужно создать его схемное обозначение и посадочное место, сохранить их в соответствующих каталогах, а затем заполнить строку соответствующей таблицы необходимой информацией (в частности, поля SYMBOL и PKG_TYPE должны содержать имена файлов схемного обозначения и посадочного места). Так вот, имеется ли в PADS некое штатное средство, чтобы заполнять таблицы БД, или же это возможно сделать только сторонними средствами?

Сторонними. По-хорошему надо делать нормальную базу, и писать для нее нормального клиента, как обычно для любой информационной системы.

Спасибо. Предчувствия меня не обманули. В качестве СУБД MySQL использую; клиента на досуге как-нибудь слеплю... Интересно, правда, почему MG некое штатное средство не сделает? Доступ же есть к базе через ODBC, так почему не дать возможность добавлять записи, редактировать поля и т.п.?..

Это как бы не того направления софт, вот и нету. И правильно, имхо. Базы у всех разные, универсального клиента не сделать.
Есть еще более мощное решение под названием DMS, но там нету поддержки PADS по умолчанию. А добавлять там можно.

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

Ещё один вопрос назревает, причём не столько к PADSу привязанный, сколько "вообще". В разработке плат я чайник, причём почти пустой (занимался давным-давно в ДОСовском P-CAD, в первой половине 1990-х, причём исключительно под ручное сверление-рисование-травление), ну а тут мне надо добиться подготовки чертежей и всего такого прочего под машинное производство плат, а затем и под машинную сборку. Просто нарисовать в редакторе геометрию посадочных мест, понятную человеку -- не проблема. Но для станков же надо определять правильным образом контактные площадки, слои и т.д. и т.п. (я пока даже не знаю толком, что им нужно). Не посоветуете, где и что можно почитать вообще про то, как и что следует описывать, какая информация для чего предназначена и т.п. вещи? Конечно, можно до определённого предела тупо повторять вещи из учебника к PADS'у, но хочется всё делать понимая, почему именно так, а не иначе, ну и т.д.

Станкам как бы все равно, они железные.
По посадочным местам читайте IPC-7351. По слоям - делайте симметричную структуру с полигонами земли и питания (для МПП), насчет остального сразу связывайтесь с производством и спрашивайте у них все параметры, толщины, зазоры и т.п.

Сделал первую разводку (страшную на вид, плюс несколько связей формально не разведено -- но в данном конкретном случае и не требуется; просто, вероятно, надо по-иному несколько было принципиальную схему рисовать), но при передаче в производство проблемы: написали, что не получается подобрать параметры сверловки с теми параметрами, с которыми экспортировал (в PADS Layout через File-CAM). Не подскажете, как правильно этот самый экспорт организовывать? В архиве на всякий случай прикладываю pcb-файл.

PADS страдает тем, что в заголовке Excellon файла не указывает Unit и формат (в основном это и не требуется - большинство CAM программ верно распознают и импортируют его). Поэтому в сопроводиловке нелишним будет указать что, например, файл сверления сделан в дюймах и формат данных 2.4

Полазив по тематическим разделам сервиса Mentor Ideas окончательно убедился в том, что корпоративная политика MG никогда не позволит PADS вырости в по-настоящему сильный инструмент для разработки п/п. Оно, наверное, и понятно. Все самые критичные и глобальные недоработки награждены статусом "вне обсуждения" (rule area, работу и димнамическую заливку planes, объединение или по крайней мере унификацию возможностей router и layout). Множество довольно очевидных недоработок все еще находятся в стадии "рассмотрения". Жаль, инструмент довольно привлекательный...пока не сталкиваешься с необходимостью сделать сложный проект, где вылазят все прелести падса.

Именно так все и обстоит. Продукт, изначально имевший практически одинаковые возможности с Expedition, задвинули на второй план (хотя надо отметить что это еще неплохо - boardstation вообще прибили).
С точки зрения маркетинга это тоже спорное решение - более гибким лицензированием Expedition добились бы большего охвата при меньшем геморрое. Отсюда можно сделать простой вывод - купили PADS в довесок к DxDesigner'у, что делать с ним не знают и поэтому тихо его убивают.

А обещанная со следующей версии поддержка центральной библиотеки в PADS не может свидетельствовать о том, что оба маршрута постепенно сливаются в один? И кстати, если будет ЦБ, означает ли это, что библиотеки компонентов у PADS и Expedition станут одинаковыми?

И попутно возник вопрос как раз по библиотекам. И в базе данных, отображаемой в DxDataBook, и в файлах символах есть свойство PKG_TYPE; вроде как имеют или могут иметь место и другие дублирования. Спрашивается, а надо ли это? Если соответствие между компонентом, его символьным обозначением и физическим воплощением устанавливается именно записью в базе данных, то зачем тот же PKG_TYPE в файле символа?

Поддержка ЦБ была анонсирована (как я помню) на август 2008. Воз и ныне там.