Так а что же? Про expedition, наверно, не надо говорить, с этим понятно. Непонятно, что за _схемотехнический_ реюз в виде блоков? Чем это отличается от иерархии схем?


Да ничего особенного... Я не знаю, как сейчас это называется в 2007, поищите в хелпе что-то типа "using array components". В 2005 есть атрибут array (не думаю, что его в 2007 убили), он задает количество компонентов. Можно задать два числа через запятую, тогда будет двумерная конструкция. Правила подключения цепей при этом тоже в хелпе есть.

Связка схемы и разведенного блока.
Посмотрю.

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

Почему же, по-моему как раз сейчас PADS не хватает нормального библиотечного редактора, привязанного к DxD. Упростит работу, сделает более понятным маршрут проектирования...а то новые пользователи, открывая PADS сразу же в недоумении озираются - а где же менеджер библиотек.

Ну, я не новый пользователь, да и в PADS не работаю. Но все равно не нравится мне это.
У меня разводка в аллегро, и менеджер библиотек мне никакой не нужен. А на нем все держится. Вот и не нравится.
Да и потом, зачем новым пользователям этот менеджер? Пикадовские привычки? У меня, вот, лежат отдельно УГО, отдельно футпринты (файликами в каталогах на диске), и чего там менеджерить?

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

Вы, возможно, удивитесь, но такой подход встречается не только в больших корпорациях, но и в маленьких и средних фирмах, в т.ч. и в России. Только от этого вопрос не перестает существовать: что там менеджерить? Что за целостность? Имеется ввиду, что видно, какому УГО какой футпринт соответствует и нельзя просто так удалить используемое УГО, например? Это можно спокойно обеспечить применением реляционной СУБД, благо DxD с ней может нормально работать. Но эта задача сама по себе не очень актуальна. Библиотека - это просто некий базовый материал, который позволяет ускорить работу, но не более. Т.е. она - не самоцель. Получается, что менеджер нужен только тем, кому он удобен. Т.е. если он не удобен (или не особо нужен), то должна быть возможность спокойно работать без него. А такая возможность, наоборот, исчезнет скоро, видимо.

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

Да и вообще довольно странно - вы говорите, что в PADS не работаете - как можно судить о перимуществах/недостатках его конкретных реализаций?

Ну мы же, вроде, как о DxD в основном говорим, а не о PADS в целом.


Оно-то, на первый взгляд хорошо, но только на первый. По порядку.
1. Быстрый доступ из одного места. Ровно то же самое можно сказать и о папочках с файликами, верно?
2. Видна структура компонента. Да, но зачем ее видеть? Нет, правда, для чего?
3. Удобство работы в редакторе. Да, в редакторе не удобно. Формирование длиннющих атрибуов, свапируемость и прочее легко подвергается автоматизации и унификации сторонними средствами. Возможно, в редакторе ЦБ тоже будет поддержка скриптов и т.п., но я не об этом, а о независимости от средств разработки. Кроме того, в редакторе нет возможностей, которые есть в DxDatabook. Это тоже напрягает.

Ну не знаю как вам, а мне удобнее выбирать корпус/символ видя его вживую, а не ориентируясь только на название файла. Вот есть у меня два корпуса типо SOIC - один с термопадом, другой без оного. Называться они могут как угодно, если наличие этого самого термопада не указано в названии вы узнаете о том, что он есть только открыв компонент в редакторе. В менеджере библиотек это будет видно сразу на предпросмотре. Кроме того, сразу видно какому компоненту присвоен какой символ и ячейка - легко выполнять проверку компонентов. При отсутствии ЦБ для того, чтобы это увидеть нужно будет "копать", это ненаглядно и ведет к возможным ошибкам.


О маршруте DxD-PADS, я бы сказал. Ибо как раз в нем существует много неудобств, связанных с отсутствием нормльного механизма объединения символов и декалов в цельные компоненты.


А кто запрещает пользоваться и тем, и другим одновременно? Вроде бы никаких проблем с этим.

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

Тут не неприятие. Дело в том что DxDesigner используется в качестве средства ввода схем не только в связке с PADS и Expedition. И само собой для других пакетов центральная библиотека не нужна - все равно посадочные места будут в другом формате. Т.е. используется чистый нетлист, как и сейчас с PADS. Ожидать что Mentor сделает ЦБ и для Allegro несколько наивно, скорее наоборот - прибьет нетлист вообще.

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


Это лишняя трата времени. Толку и пользы от этого никакого.


Ничего оно не ярое. Я уже давно спокойно отношусь ко всем этим выкрутасам писателей софта. Все равно никуда от них не деться. Отчасти поэтому я большое внимание уделяю вопросам независимости и абстракции от софта. Помогает, знаете-ли...
Ну а ментору можно только пожелать сохранить все возможности, которые были раньше по интергации с другими фирмами и не убивать это.
Я так думаю, что основная причина перехода на новую идеологию была в том, чтобы сделать САПР, который позволяет в реальном времени работать нескольким людям над одним проектом. Типа, такого ни у кого нет, а мы будем круче всех и т.п. А выходит, что при этом вылезают проблемы с интеграцией. Ну, если прибьют нетлист, будем смотреть, не ментором единым...
ЗЫ. Правда, fill тут упоминал, что есть некий релиз IND (типа independent). В нем даже менеджер вариантов работает для нетлиста. Скажите, в PADS случайно не этот релиз используется? Т.е. в евойном (падсовском) DxD работает менеджер вариантов?

Мне почему-то кажется, что на нетлист это никак не повлияет - все равно ЦБ для PADS будет очень серьезно отличаться от ЦБ для экспедишна, суть только в том, что сведут воедино символы, парты и декалы. А реализация связки ДхД с падс останется примерно такой же на мой взгляд.

Никогда им не пользовался, честно говоря, но по-моему в DxD-PADS он реализован. Тут приводили линк на видео для реюз - на том же ресурсе есть видео для VM.

Сообщение отредактировал ClayMan - Nov 9 2011, 13:30

Ага, на экспедишен тоже не повлияло. Нетлиста может просто не стать как такового, понимаете?

Может и не стать, понимаю) Но пока ведь никто не говорит об отмене нетлиста, просто ЦБ прицепят для падс) К тому же всегда можно остаться на старой версии DxD, в ней то нетлист уже никуда не денется))

Мы просто смотрим на вопрос с разных сторон - вы боитесь потери нетлиста, я же просто рад возможному наличию ЦБ для PADS