Так а что же? Про 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.

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

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

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

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

Ну зачем же такие громкие заявления - только падсом) Да нет, не только) Хотя на данный момент конкретно в аллегро работать не приходилось, но кто знает

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

Съев собаку (и кучу другой живности) на библиотеках DxD-Exp соглашусь с vitan: мне удобнее всего было бы хранить символы, посадочные и распиновку (соответствие имени вывода символа номеру пада посадочного) в отдельных текстовых файлах. Есть менеджер библиотек или нет - не важно, чтоб просмотреть символ и посадочное есть соответсвующие редакторы. Такой способ хранения ооочень здорово автоматизируется скриптами, что повышает скорость создания новых компонентов, уменьшает возможность ошибки вследствие человеческого фактора и улучшает целостность данных, ибо автоматом можно запустить кучу проверок для всех элементов.

Кстати, знаю как минимум одну большую контору в Нидерландах, которая почти так и ведет либы DxD-Exp: символы пока еще текстовые, cell и part экспортируют в hkp, все это под контролем версий итп. Любота! Если б в DxD-Exp это все грамотно реализовали при этом не убивая того, что уже было сделано грамотно (rest in peace ViewDraw ;( ) - совсем бы хорошо было.

Ну я же и не говорю, что без нее совсем никак Можно работать конечно, я не спорю. Для настоящих "гуру" видимо так действительно удобнее.


А можно поподробнее? В чем повышение скорости создания?


Есть подозрение, что я знаю о какой конторе вы говорите

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

Так это не мы решили, а ментор там решает. То, что описываю я и cioma - тоже по сути центральная библиотека. Она даже более центральная, чем та, что ментор предлагает, ибо она участвует в жизни не только создателей ПП, а вообще всего предприятия. Т.е это легко вписывается в общие процессы, т.к. нету этого специфического редактора ЦБ, а вместо него нормальная СУБД и контроль версий.
Кстати, у ментора есть на этот счет более грамотное решение под названием dms. Это наиболее правильный подход.

Ну, DMS - это еще тот монстр, там уж точно шаг влево-шаг вправо (от генеральной линии ментора) - расстрел



Вот надо создать проц на 1000 ног, скармливаете скрипту csv c названиями, номерами и типами выводов, а он генерит смиволы с как минимум правильными размерами, ориентацией атрибутов итп. Потом слегка руками поправили - и готово.



Название из 4 букв, перавая "A"

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


Ну скажите уж и остальные три буквы!

Ага, вот только СУБД должна быть обязательно Oracle (если не изменяет память)



SML

Нет, сейчас они туда уже включают сервер Postgre тоже. Вроде бы, и для остальных тоже есть возможности, не проверял. Да и Oracle имхо не проблема, а наоборот, хорошо...

Именно))
Что ж, раз гуру говорят "да", значит такой способ работы с либами действительно хорош.

Господа,

Необходимо развести процессор память(DDR2), подскажите пожалуйста, как настроить Router
чтобы все проводники были одинаковой длины, и как запустить autorouter...

Заранее большое спасибо!

Видео

Возник тривиальный вопрос, на кот я не смогу найти ответ - а как выделить группу неиспользуемых пинов на процессоре, например? цепи Net0 по аналогии с Exp в PADS нет, может есть какая-нибудь хитрая примочка?)

Здравствуйте! Подскажите пожалуйста почему в DXD когда на схеме выделяется УГО Decal Browser не находит для него посадочное место, если я через симбол эдитор->tools->pads decal browser задал для этого УГО посадочное место. В чем может быть проблема? актуально для WinXP SP3 и WIN7/ весь проект и library лежит на флэхе, программа на С. Было замечено что после переустановки программы все в порядке и все отображается некоторое время а потом снова появляется эта проблема. Есть ли взаимосвязь? Может что-то сам не то сделал. Заранее спасибо!
Нажмите для просмотра прикрепленного файла

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

До layout я пока не дошел... Может проблема еще в том что Databook не настроен для проекта...с ним я пока тоже не работал.

Начал разбираться с Databook...В нарисованной схеме имеются несколько конденсаторов для которых одно УГО и несколько посадочных мест...При назначении одного УГО одним посад. местом остальные кондеры принимают тот же вариант посадочного места( но должен быть другой). Моя попытка разобраться в этом непорядке с Databook оказалась не успешной. меня интересует следующее:
1. правильно ли я понимаю чтобы присвоить посадочные места нужно самому вручную создавать таблицу Microsoft access, где будут прописаны все возможные пары УГО-Посадочное место компонентов необходимые для моего проекта?
2. Или же есть возможность непосредственно в Databook осуществить замену PKG_Type интересующего меня УГО ? ( что-то наподобие нового компонента в таблице с тем же УГО но с др. PKG_Type)
3. А возможен ли вариант просто пройтись по всем УГО на схеме и каждому в Properties задать необходимый PKG_Type ? Не будет ли потом конфликта с Databook при передаче в Layout ?
Сколько GUIDE я не читал, но так и не разобрался, надеюсь на вашу помощь! Заранее спасибо!

В databook я никогда не работал, но по идее вы должны иметь базу данных в access со всеми необходимымми параметрами для набора элементов (для конденсаторов это наверняка значение вольтажа, емкости, типоразмер, возможно материал диэлектрика), кот затем вы указываете в databook при выборе элементра для установки на схему. Ну и само собой вы должны иметь в библиотеке полный набор decal'ов для всех пассивных элементов (0402, 0603 и тд). Более подробной информации не дам, сам не пользуюсь этим.


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

Viper89
1. Да, точнее, Вам нужно каким-либо образом хранить в базе эти соответствия (не обязательно в таблице). При этом надо знать, в каком формате это должно быть, про PADS я не знаю, но, например, для Аллерго это перечисление всех альтернативных корпусов через запятую, заключенное в скобки.
2. Да, нужно предварительно сделать Load, а затем Annotate для конкретного компонента. Замена будет сделана в схеме, для работы с базой нужен отдельный клиент. Databook из нее может только читать.
3. Да, но нужно конкретизировать. Если у Вас компоненты имеют помимо УГО некий отличительный атрибут типа партнамбера, то - да, безусловно. Если нет, то лучше для этого использовать не Databook, а просто редактор свойств.

ClayMan и vitan благодарю за оперативный ответ) Сегодня попытался создать нетлист и перейти непосредственно к layout, вылезли непонятные 2 ошибки при создании нетлиста...

1)pcb: Warning 5720: Check Schematic1.err for VIEWBASE messages
pcb: Error 5709: Could not open schematic Schematic1
pcb: Note 5626: Summary of pcb1.err
Status 0, Notes 1, Warnings 1
Errors 1, Failures 0, Fatals 0, Internals 0

2)viewbase: Error 222: Error - Could not find WIR file SCHEMATIC1.1.


в Error datashite вот что пишется по поводу первой
PCB-5709
Message: Could not find ViewPlace database for [object].
Cause: The ViewPlace database required for the specified object could not be found.
Solution: If the object is a board, there is no design.brd file in the brd directory. Use the
-CreatePlacementData option in the command line to create a board
database.
If the object is a shape, the symbol shapes cannot be found in the viewplac.ini
search order. Check your viewplac.ini file.( видимо какого-то database не хватает...не ясно какого, попробовал через командную строку проделать-в итоге output пишет что-нет такой команды)
Кто-нибудь сталкивался с этим?) что я забыл сделать?) по поводу второй ошибки ничего не нашел...

Ладно, видимо никто не встречался с этой проблемой...пытаюсь сам разобраться ...и назрел вот такой вопрос -что такое WIR файл и откуда он берется? и каковы могут быть причины того что его нет в положенном месте?

Это файл, содержащий список цепей (для каждого листа отдельный файл). судя по скриншоту у Вас новая версия (2007), там этих файлов, вроде бы, уже нет (они есть в старых 2005). Чтобы они появились в 2005 достаточно было нажать save+check, но такой кнопки уже больше нет...
Отсутствовать они могут, потому что, например, проект был скопирован без них и его пытаются открыть на другой машине (из другого каталога).

а у меня возник следующий вопрос - я пытаюсь добавить блок reuse в уже существующую плату с компонентами. т.е. по сути мне нужно перенести разводку/расположение с одного проекта в другой - задача классическая. однако поскольку для данной платы уже существуют все компоненты для модуля, кот я пытаюсь подтянуть из reuse, сам реюз вставляется отдельным новым блоком компонентов, кот в схеме нет. есть ли какой-то способ не добавить новые компоненты а обновить существующие из reuse файла?

Понятно...Vitan,a есть ли в менторе решение аналогичное файлу .alt P-CAD, может вовсе не обязательно рисовать электрические схемы, а достаточно создать посадочные места и загрузить подобный файл в Layout?

может, keyin netlist?

с keyin netlist пока не сталкивался. я имею ввиду написать этот нетлист самому, согласно электрической схеме, чтобы не заниматься рисованием в DXdesigner и начать работу уже непосредственно в Layout.

Давно хочу забить на все и начать вместо схемы писать на VHDL, например. Не проверял пока напрямую возможность отправки VHDL в разводку, но уверен, что там у ментора все в порядке. Жаль, что нету времени освоить, да и убедить начальство перейти на такую технологию тоже будет непросто.
Хотя уже не раз тут обсуждали, что у схем нет будущего... Но пока есть настоящее.

Чето Вы тут загнули Хотел бы я увидеть внятное описание на каком либо языке нормальной смешанной схемы, с процом, но и с питаниями, клавиатурами, радиомодулями и т.п. Для чистой цифры - возможно и чисто описательный подход, для смеси - имхо не реально.

А в чем трудности? Создаются компоненты, а потом соединяются, так же, как и на схеме. Какая разница, аналоговый он, цифровой, или радио?

Ну-ну...

Глубокомысленно, ничего не скажешь.
Да, кстати, возникла идея, как побороть обязательность схемы. Ее надо просто сгенерить! Т.е. не рисовать, а после окончания разводки сделать backannotate в чистую схему.
Единственное, надо научиться генерить еще и УГО. Но с этим трудностей уже меньше...

С генерацией УГО как раз никаких проблем. Это уже и сейчас реализовано.
А со схемами такое впечатление, что сложных Вы никогда не рисовали.

команда Make Like Reuse