[Voyager 0]

Всем добрый день.

 

Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю

[SII 0]

В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым. А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? Вопрос пока больше академический: просто, вводя датафлэшку от Atmel, увидел, что она не только в 8-ножечном SOIC существует, но ещё и в ряде других корпусов с иным числом контактов. Получится ли в этом случае обойтись одним компонентом (чтобы на принципиальной схеме размещать именно его, а уже при размещении на плате выбирать нужный тип корпуса) или же придётся делать несколько компонентов с одинаковым символьным обозначением, но разными корпусами?

[Frederic 0]

Всем добрый день.

 

Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю

попробуй попровести дорожку например GND от элемента до плейна GND через via

после этого зальется

 

В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым.

да

 

А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)?

нет

 

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

нет

 

или же придётся делать несколько компонентов с одинаковым символьным обозначением, но разными корпусами?

да

тем более в зависимости от корпуса PartNumber совершенно другой

 

[vitan 2]

А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)?

 

нет

Вот ведь!

Три дня мне все доказывали необходимость ЦБ, и этот пример был чуть ли не основным, а тут уже "нет"!

 

Вот исходный пост на эту тему и мое мнение ниже. Получается, что cioma противоречит Frederic-у...

 

Уважаемые экспедиторы (в смысле, те, кто разводит в Exp)! Просветите уж меня, беднягу! Я тут "докопался" к этой ЦБ не просто так. Я вижу, что Exp обладает хорошими инструментами в плане разводки, и мне не хотелось бы терять возможность разводить в Exp на стороне и получать высококачественные проекты. Но для этого мне надо понять, как мне вести мою собственную библиотеку. Пока я этого не понимаю и вижу, что при наличии БД будет только хуже (см. выше).

 

В моем опросе кто-то один уже успел отметиться во втором пункте (где DxD-iCDB-Exp + DxDataBook).

Особенно хотелось бы услышать мнение этого человека.

Ну и остальных прошу голосовать активнее!

[Frederic 0]

Вот исходный пост на эту тему и мое мнение ниже. Получается, что cioma противоречит Frederic-у...

противоречия нет

вентиль 2-or-no возможно использовать во многоих компанентах с различными корпусами и распиновкой

НО в одном компаненте не возможно провести одновременно упаковку с SOIC16 и BGA20 с номерами ног А1, В1.....

тем более в PartNunber уже прописан необходимый корпус

 

[vitan 2]

противоречия нет

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

[Uree 1]

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

 

Приглашаю использовать Concept HDL от Cadence. Там это базовая возможность: один(несколько) символ(ов) - несколько упаковок - несколько корпусов, все это в рамках одного библиотечного компонента(там это называется cell). Кол-во ограничено фантазией создателя и способностью контролировать свое детище. Выбор символа/футпринта происходит автоматом при выборе соответствующего Part_Number при вставке в схему.

Правда vitan как-то объяснял, что все это ерунда, потому что не БД:) Ну видимо вопрос вкуса - мне ЭТО нужнее чем база...

[vitan 2]

Правда vitan как-то объяснял, что все это ерунда, потому что не БД :) Ну видимо вопрос вкуса - мне ЭТО нужнее чем база...

Вы знаете, я уже придумал, как использовать и концепт и БД одновременно. Сейчас пока руки не доходят до реализации, но это не важно. Учитывая трудности с ментором в последних релизах, я еще подумаю о переходе на концепт, но это уже в другом топике, а то меня тут заклюют еще ненароком. :)

Сорри за офтоп, конечно.

[Uree 1]

Ок, тогда переходите в правильную ветку и там обсудим, куда и главное зачем(!) цеплять к телеге пятое колесо:)

[vitan 2]

Ок, тогда переходите в правильную ветку и там обсудим, куда и главное зачем(!) цеплять к телеге пятое колесо :)

Ну давайте.

Но что-то мне подсказывает, что переходить мне не захочется...

[fill 2]

Всем добрый день.

 

Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю

 

Поищите - уже не раз подробно обсуждалось.

В 2007 отдельно генерируются только негативные плейн. Если в Plane_Assignments стоит Dynamic и в DC включено Plane Data и Fill\hatch , то заливки позитивов отображаются автоматом.

[fill 2]

Обратите внимание: и тут и там экспортирование есть. Вычитаем. У меня экспорт тоже делается одним движением. Остается: а) копирование файлов или б) подключение нового пути поиска (по выбору). ЦБ (или локальная библиотека) сформирована и подключена. Я пользуюсь вариантом а) обычно (стараюсь). А в вашем случае что? Надо еще а) компоненты из этой промежуточной ЦБ перекинуть в основную (подозреваю, что это может затянуться на два дня) или б) просто работать. Но тут самое интересное! Вы опять не сказали, возможно ли в варианте б) работать с БД и не переключаясь на нетлист? Точнее, возможно ли поместить туда новые компоненты из БД, как в примере про серию конденсаторов? Уверен, что нет.

Выход один - создавать их руками. Это мне не нравится.

 

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

Я вообще могу ничего никуда не экспортировать, а редактировать прямо в базе платы. Как и экспортировать прямо в основную ЦБ - но обычно это не делаю чтобы не бороться с проблемами несовместимости моего представления о компонентах со сторонними представлениями, и т.к. ЦБ не дает создавать того бардака который обычно я вижу в случае импорта так называемых библиотек OrCAD или PCAD, когда в их библиотеках встречается куча элементов с одинаковыми именами но разными номерами пинов, количеством пинов, именами пинов - я обычно импортирую весь этот винигрет в специально созданную временную ЦБ.

 

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

 

Видео

Попробуйте повторить показанное и посчитайте кол-во ваших шагов в маршруте нетлиста и файликов.

Там же показан и запуск одного из редакторов (редактирования компонента) изнутри базы платы (это чтобы было понятнее про экспорт и его необходимость).

Возможно также заметите (если захотите) что использовано два разных способа выбора компонента для размещения на схему, при этом на плату попадает один и тот же компонент (PDB) но с разными параметрами. И возможно также заметите что в БД намного больше компонентов (резисторов) чем в ЦБ, и тем не менее это не мешает ими воспользоваться.

 

Ага, спасибо. Итак, если нету этой инфы, то каюк.

Вывод: ЦБ - это просто новый способ хранения информации о номерах выводов. Ничего более не дает (все остальное - мишура).

Объясните теперь, пожалуйста, зачем этот способ был создан, и чем он так более прогрессивен, нежели хранение в символах?

 

Символ использован во множестве компонентов:

В каждом из компонентов свои номера пинов, например:

 

В вашем случае наплодите символов под каждый такой компонент.

Если нужно будет изменить что-то внутри символа, то мы изменим в одном месте и это коснется всех компонентов, вам придется редактировать каждый.

Также заметьте, что в БД под каждый такой компонент вам придется ввести по 3 строчки.

[vitan 2]

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

Извините, пожалуйста, но я уже третий раз повторяю: Я ПРОБОВАЛ. И слушаю я очень внимательно, видимо, в отличие от Вас (Вы первые два раза, очевидно, не услышали).

 

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

Стоп, получается, возможно поправить проект в Exp, не имея ЦБ? Трудно было сразу об этом сказать???

 

Видео

Попробуйте повторить показанное и посчитайте кол-во ваших шагов в маршруте нетлиста и файликов.

Там же показан и запуск одного из редакторов (редактирования компонента) изнутри базы платы (это чтобы было понятнее про экспорт и его необходимость).

Не надо говорить загадками. Скажите прямо, что Вы хотите продемонстрировать. Я могу воспринять и без подобных экспериментов, мне некогда и не на чем их проводить.

 

Как и экспортировать прямо в основную ЦБ - но обычно это не делаю чтобы не бороться с проблемами несовместимости моего представления о компонентах со сторонними представлениями, и т.к. ЦБ не дает создавать того бардака который обычно я вижу в случае импорта так называемых библиотек OrCAD или PCAD, когда в их библиотеках встречается куча элементов с одинаковыми именами но разными номерами пинов, количеством пинов, именами пинов - я обычно импортирую весь этот винигрет в специально созданную временную ЦБ.

Это понятно, Вы могли бы и не расписывать. Я бы на Вашем месте делал бы точно так же, мы ведь не об этом говорим!

 

Символ использован во множестве компонентов:

В каждом из компонентов свои номера пинов:

В вашем случае наплодите символов под каждый такой компонент.

Я так и думал, что будет приведен подобный пример.

Разберем его подробнее.

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

Вы говорите: надо будет плодить УГО и потом по-отдельности расставлять пины. А у Вас, мол, все доступно из единого места.

Ну и что? Плодить - это в моем случае копировать файлы. Секунда.

Расставлять пины. Хотите сказать, что у Вас есть секретный способ выставить распиновку одновременно для всех приведенных Вами в примере компонентов? Слабо верится. А если нет, то Вам так же придется по очереди тыкать в компонент и править распиновку. Затраты времени, как минимум те же.

Поэтому, когда Вы говорите:

Если нужно будет изменить что-то внутри символа, то мы изменим в одном месте и это коснется всех компонентов, вам придется редактировать каждый.

Вы немного лукавите. Я правлю не компоненты, а новое УГО, при этом пользуюсь я тоже одним и тем же редактором, т.е. у меня тоже унифицированный доступ с помощью одних и тех же средств.

 

Странно, что Вы не привели пример с УГО разъема (один пин), о котором я сам же и говорил. Вот там применяемость может быть гораздо шире.

 

Но, если вернуться к главному вопросу, получается, что только из-за этого и была создана ЦБ? Чтобы просто не копировать файлы с УГО по диску? Очень спорное решение. Если бы у меня был выбор между такой возможностью экономии и хранением в виде файлов, я бы выбрал файлы, т.к. их можно обрабатывать гораздо более широким набором софта, а не только редактором ЦБ.

Или есть еще причины?

[fill 2]

1. К сожалению, по вашим репликам видно обратное - если бы действительно нормально попробовали, то не задавали бы элементарных вопросов.

2. Ну видимо из за внимательного чтения вы и пишете

Примерно так же. Из платы экспортируются посадочные места и описания компонентов, правятся и обновляются.

"

На мое

"В случае Exp я просто открою плату и выберу Setup>Part_Editor и в открывшемся окне редактора компонентов увижу все компоненты этой платы, и смогу их редактировать, для посадочных мест Setup>Cell_Editor ...

А затем еще начинаете разглагольствовать о двойном импорте\экспорте - я где нибудь об этом говорил?

3. В показанных PDB распиновка делается всего один раз, только для одного символа - остальные пользуются той же таблицей автоматом. Т.е. я ввожу один раз вы 3.

Кроме того при вводе в левой колонке отображаются все не присвоенные номера с корпуса, поэтому:

- сразу вижу какие номера еще остались в списке слева

- не могу сделать ошибку и дважды ввести один и тот же номер

- могу просто выбрать номера в списке слева (сразу все или группу) и скопом присвоить - перетащить слева направо.

4. Все время говорите о двойной работе при этом никак не можете точно сформулировать в чем же она заключается.

Я вам уже несколько раз пытался объяснить простую вещь:

- рисуете символ (без атрибутов) и корпус (если его нет)

- вводите PDB в который импортируете этот символ и корпус (при этом если на символе есть номера пинов, то таблица соответствия заполнится автоматом этими номерами) заполняете\дополняете таблицу соответствия номеров.

- в БД вводите атрибуты (или вводите их в PDB - как хотите) - в данном случае нужны только те атрибуты которые нужны вам для поиска по параметрам и оформления BOM.

Все, ну и где здесь двойная работа?

Не хотите так работать как мы, так продолжайте через нетлист, какие проблемы?

5. Опрос затеянный вами покажет только то, что большинство пользователей перешедших с DC\DV продолжают пользоваться тем же набором средств какие у них были раньше и разбираться с дополнительными не будут - ибо проще работать так как привыкли ранее. Причем у них проблема противоположна вашей - все атрибуты внутри ЦБ и для них первоначальное создание БД является только дополнительной работой (все атрибуты из ЦБ надо перетащить в БД).

Новые тоже зачастую открываю LM и делая ЦБ по тренингам, начинают считать что и так всего получаемого внутри ЦБ пока им достаточно.

Собственно говоря, проблема заключается только в том, что если бы кто-то заполнил им БД и на протяжении некоторого времени помог в работе с ней, то через некоторое время считали бы что без БД плохо.

[Frederic 0]

..................................

vitan, плиз сделай видео желательно с голосом (минут 5....15) как у тебя протекает процесс

догадываюсь, что fill имеет полное представление о сути беседы, но многие которые работают только в ЦБ (в том числе я) не понимают о чем идет речь

 

иначе вам с fill надо перенести беседу в другое место и с :beer: для полного взаимопонимания