Voyager 0 2 марта, 2012 Опубликовано 2 марта, 2012 · Жалоба Всем добрый день. Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SII 0 2 марта, 2012 Опубликовано 2 марта, 2012 · Жалоба В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым. А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? Вопрос пока больше академический: просто, вводя датафлэшку от Atmel, увидел, что она не только в 8-ножечном SOIC существует, но ещё и в ряде других корпусов с иным числом контактов. Получится ли в этом случае обойтись одним компонентом (чтобы на принципиальной схеме размещать именно его, а уже при размещении на плате выбирать нужный тип корпуса) или же придётся делать несколько компонентов с одинаковым символьным обозначением, но разными корпусами? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Frederic 0 2 марта, 2012 Опубликовано 2 марта, 2012 · Жалоба Всем добрый день. Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю попробуй попровести дорожку например GND от элемента до плейна GND через via после этого зальется В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым. да А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? нет Вопрос пока больше академический: просто, вводя датафлэшку от Atmel, увидел, что она не только в 8-ножечном SOIC существует, но ещё и в ряде других корпусов с иным числом контактов. Получится ли в этом случае обойтись одним компонентом (чтобы на принципиальной схеме размещать именно его, а уже при размещении на плате выбирать нужный тип корпуса) нет или же придётся делать несколько компонентов с одинаковым символьным обозначением, но разными корпусами? да тем более в зависимости от корпуса PartNumber совершенно другой Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? нет Вот ведь! Три дня мне все доказывали необходимость ЦБ, и этот пример был чуть ли не основным, а тут уже "нет"! Вот исходный пост на эту тему и мое мнение ниже. Получается, что cioma противоречит Frederic-у... Уважаемые экспедиторы (в смысле, те, кто разводит в Exp)! Просветите уж меня, беднягу! Я тут "докопался" к этой ЦБ не просто так. Я вижу, что Exp обладает хорошими инструментами в плане разводки, и мне не хотелось бы терять возможность разводить в Exp на стороне и получать высококачественные проекты. Но для этого мне надо понять, как мне вести мою собственную библиотеку. Пока я этого не понимаю и вижу, что при наличии БД будет только хуже (см. выше). В моем опросе кто-то один уже успел отметиться во втором пункте (где DxD-iCDB-Exp + DxDataBook). Особенно хотелось бы услышать мнение этого человека. Ну и остальных прошу голосовать активнее! Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Frederic 0 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба Вот исходный пост на эту тему и мое мнение ниже. Получается, что cioma противоречит Frederic-у... противоречия нет вентиль 2-or-no возможно использовать во многоих компанентах с различными корпусами и распиновкой НО в одном компаненте не возможно провести одновременно упаковку с SOIC16 и BGA20 с номерами ног А1, В1..... тем более в PartNunber уже прописан необходимый корпус Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба противоречия нет Ну, тогда этот аргумент в споре про необходимость ЦБ не засчитывается, т.к. ровно то же самое я постоянно делаю и без нее. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uree 1 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба В центральной библиотеке можно при формировании компонента (Part) сопоставить одному символу несколько посадочных мест (Cell), если соответствие логических и физических выводов остаётся одинаковым. А можно ли это сделать, если означенное соответствие зависит от вида посадочного места (и, в частности, если число выводов у разных посадочных мест для одного и того же компонента различается)? Приглашаю использовать Concept HDL от Cadence. Там это базовая возможность: один(несколько) символ(ов) - несколько упаковок - несколько корпусов, все это в рамках одного библиотечного компонента(там это называется cell). Кол-во ограничено фантазией создателя и способностью контролировать свое детище. Выбор символа/футпринта происходит автоматом при выборе соответствующего Part_Number при вставке в схему. Правда vitan как-то объяснял, что все это ерунда, потому что не БД:) Ну видимо вопрос вкуса - мне ЭТО нужнее чем база... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба Правда vitan как-то объяснял, что все это ерунда, потому что не БД :) Ну видимо вопрос вкуса - мне ЭТО нужнее чем база... Вы знаете, я уже придумал, как использовать и концепт и БД одновременно. Сейчас пока руки не доходят до реализации, но это не важно. Учитывая трудности с ментором в последних релизах, я еще подумаю о переходе на концепт, но это уже в другом топике, а то меня тут заклюют еще ненароком. :) Сорри за офтоп, конечно. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uree 1 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба Ок, тогда переходите в правильную ветку и там обсудим, куда и главное зачем(!) цеплять к телеге пятое колесо:) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 3 марта, 2012 Опубликовано 3 марта, 2012 · Жалоба Ок, тогда переходите в правильную ветку и там обсудим, куда и главное зачем(!) цеплять к телеге пятое колесо :) Ну давайте. Но что-то мне подсказывает, что переходить мне не захочется... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 4 марта, 2012 Опубликовано 4 марта, 2012 · Жалоба Всем добрый день. Возможно, этот вопрос покажется простым, но я пока не смог его решить. В версии 2005 заливку можно было генерировать с помощью меню Plane Parameter Processor. В версии 7.9 эта кнопка осталась, но после нажатия на кнопку Apply заливка не генерируется. Объясните, пожалуйста, последовательность действий для генерации плэйн - может я что-то не так делаю Поищите - уже не раз подробно обсуждалось. В 2007 отдельно генерируются только негативные плейн. Если в Plane_Assignments стоит Dynamic и в DC включено Plane Data и Fill\hatch , то заливки позитивов отображаются автоматом. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 4 марта, 2012 Опубликовано 4 марта, 2012 · Жалоба Обратите внимание: и тут и там экспортирование есть. Вычитаем. У меня экспорт тоже делается одним движением. Остается: а) копирование файлов или б) подключение нового пути поиска (по выбору). ЦБ (или локальная библиотека) сформирована и подключена. Я пользуюсь вариантом а) обычно (стараюсь). А в вашем случае что? Надо еще а) компоненты из этой промежуточной ЦБ перекинуть в основную (подозреваю, что это может затянуться на два дня) или б) просто работать. Но тут самое интересное! Вы опять не сказали, возможно ли в варианте б) работать с БД и не переключаясь на нетлист? Точнее, возможно ли поместить туда новые компоненты из БД, как в примере про серию конденсаторов? Уверен, что нет. Выход один - создавать их руками. Это мне не нравится. Трудно говорить с человек уже давно сделавшим какие-то выводы и не слушающим собеседников. И приводящий некие измышления про операции, занимающие у меня несколько минут, как операции на несколько дней кропотливого труда. Попробуйте для начала, а уж потом делайте конкретные выводы с цифрами. Я вообще могу ничего никуда не экспортировать, а редактировать прямо в базе платы. Как и экспортировать прямо в основную ЦБ - но обычно это не делаю чтобы не бороться с проблемами несовместимости моего представления о компонентах со сторонними представлениями, и т.к. ЦБ не дает создавать того бардака который обычно я вижу в случае импорта так называемых библиотек OrCAD или PCAD, когда в их библиотеках встречается куча элементов с одинаковыми именами но разными номерами пинов, количеством пинов, именами пинов - я обычно импортирую весь этот винигрет в специально созданную временную ЦБ. Во-первых, поиск по подпапкам еще никто не отменял. Это я к тому, что подключать можно тоже один раз. Но это все мелочи, не понимаю, как Вы можете приводить их в качестве оправдания существования ЦБ. Вы можете ответить мне на пост, где я писал о реальном снижении скорости работы и проблемах на этом пути? Вот это было бы конструктивно, а так похоже уже на какой-то извращенный холивар, кому как папочки быстрее подключать. Видео Попробуйте повторить показанное и посчитайте кол-во ваших шагов в маршруте нетлиста и файликов. Там же показан и запуск одного из редакторов (редактирования компонента) изнутри базы платы (это чтобы было понятнее про экспорт и его необходимость). Возможно также заметите (если захотите) что использовано два разных способа выбора компонента для размещения на схему, при этом на плату попадает один и тот же компонент (PDB) но с разными параметрами. И возможно также заметите что в БД намного больше компонентов (резисторов) чем в ЦБ, и тем не менее это не мешает ими воспользоваться. Ага, спасибо. Итак, если нету этой инфы, то каюк. Вывод: ЦБ - это просто новый способ хранения информации о номерах выводов. Ничего более не дает (все остальное - мишура). Объясните теперь, пожалуйста, зачем этот способ был создан, и чем он так более прогрессивен, нежели хранение в символах? Символ использован во множестве компонентов: В каждом из компонентов свои номера пинов, например: В вашем случае наплодите символов под каждый такой компонент. Если нужно будет изменить что-то внутри символа, то мы изменим в одном месте и это коснется всех компонентов, вам придется редактировать каждый. Также заметьте, что в БД под каждый такой компонент вам придется ввести по 3 строчки. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 4 марта, 2012 Опубликовано 4 марта, 2012 · Жалоба Трудно говорить с человек уже давно сделавшим какие-то выводы и не слушающим собеседников. И приводящий некие измышления про операции, занимающие у меня несколько минут, как операции на несколько дней кропотливого труда. Попробуйте для начала, а уж потом делайте конкретные выводы с цифрами. Извините, пожалуйста, но я уже третий раз повторяю: Я ПРОБОВАЛ. И слушаю я очень внимательно, видимо, в отличие от Вас (Вы первые два раза, очевидно, не услышали). Я вообще могу ничего никуда не экспортировать, а редактировать прямо в базе платы. Стоп, получается, возможно поправить проект в Exp, не имея ЦБ? Трудно было сразу об этом сказать??? Видео Попробуйте повторить показанное и посчитайте кол-во ваших шагов в маршруте нетлиста и файликов. Там же показан и запуск одного из редакторов (редактирования компонента) изнутри базы платы (это чтобы было понятнее про экспорт и его необходимость). Не надо говорить загадками. Скажите прямо, что Вы хотите продемонстрировать. Я могу воспринять и без подобных экспериментов, мне некогда и не на чем их проводить. Как и экспортировать прямо в основную ЦБ - но обычно это не делаю чтобы не бороться с проблемами несовместимости моего представления о компонентах со сторонними представлениями, и т.к. ЦБ не дает создавать того бардака который обычно я вижу в случае импорта так называемых библиотек OrCAD или PCAD, когда в их библиотеках встречается куча элементов с одинаковыми именами но разными номерами пинов, количеством пинов, именами пинов - я обычно импортирую весь этот винигрет в специально созданную временную ЦБ. Это понятно, Вы могли бы и не расписывать. Я бы на Вашем месте делал бы точно так же, мы ведь не об этом говорим! Символ использован во множестве компонентов: В каждом из компонентов свои номера пинов: В вашем случае наплодите символов под каждый такой компонент. Я так и думал, что будет приведен подобный пример. Разберем его подробнее. Вы показали УГО для элемента ИЛИ. Сколько таких элементов будет в ходу на предприятии? Не много, поверьте. Обычно даже вводят специальные ограничительные перечни по элементной базе. Это первое. Вы говорите: надо будет плодить УГО и потом по-отдельности расставлять пины. А у Вас, мол, все доступно из единого места. Ну и что? Плодить - это в моем случае копировать файлы. Секунда. Расставлять пины. Хотите сказать, что у Вас есть секретный способ выставить распиновку одновременно для всех приведенных Вами в примере компонентов? Слабо верится. А если нет, то Вам так же придется по очереди тыкать в компонент и править распиновку. Затраты времени, как минимум те же. Поэтому, когда Вы говорите: Если нужно будет изменить что-то внутри символа, то мы изменим в одном месте и это коснется всех компонентов, вам придется редактировать каждый. Вы немного лукавите. Я правлю не компоненты, а новое УГО, при этом пользуюсь я тоже одним и тем же редактором, т.е. у меня тоже унифицированный доступ с помощью одних и тех же средств. Странно, что Вы не привели пример с УГО разъема (один пин), о котором я сам же и говорил. Вот там применяемость может быть гораздо шире. Но, если вернуться к главному вопросу, получается, что только из-за этого и была создана ЦБ? Чтобы просто не копировать файлы с УГО по диску? Очень спорное решение. Если бы у меня был выбор между такой возможностью экономии и хранением в виде файлов, я бы выбрал файлы, т.к. их можно обрабатывать гораздо более широким набором софта, а не только редактором ЦБ. Или есть еще причины? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fill 2 4 марта, 2012 Опубликовано 4 марта, 2012 · Жалоба 1. К сожалению, по вашим репликам видно обратное - если бы действительно нормально попробовали, то не задавали бы элементарных вопросов. 2. Ну видимо из за внимательного чтения вы и пишете Примерно так же. Из платы экспортируются посадочные места и описания компонентов, правятся и обновляются." На мое "В случае Exp я просто открою плату и выберу Setup>Part_Editor и в открывшемся окне редактора компонентов увижу все компоненты этой платы, и смогу их редактировать, для посадочных мест Setup>Cell_Editor ... А затем еще начинаете разглагольствовать о двойном импорте\экспорте - я где нибудь об этом говорил? 3. В показанных PDB распиновка делается всего один раз, только для одного символа - остальные пользуются той же таблицей автоматом. Т.е. я ввожу один раз вы 3. Кроме того при вводе в левой колонке отображаются все не присвоенные номера с корпуса, поэтому: - сразу вижу какие номера еще остались в списке слева - не могу сделать ошибку и дважды ввести один и тот же номер - могу просто выбрать номера в списке слева (сразу все или группу) и скопом присвоить - перетащить слева направо. 4. Все время говорите о двойной работе при этом никак не можете точно сформулировать в чем же она заключается. Я вам уже несколько раз пытался объяснить простую вещь: - рисуете символ (без атрибутов) и корпус (если его нет) - вводите PDB в который импортируете этот символ и корпус (при этом если на символе есть номера пинов, то таблица соответствия заполнится автоматом этими номерами) заполняете\дополняете таблицу соответствия номеров. - в БД вводите атрибуты (или вводите их в PDB - как хотите) - в данном случае нужны только те атрибуты которые нужны вам для поиска по параметрам и оформления BOM. Все, ну и где здесь двойная работа? Не хотите так работать как мы, так продолжайте через нетлист, какие проблемы? 5. Опрос затеянный вами покажет только то, что большинство пользователей перешедших с DC\DV продолжают пользоваться тем же набором средств какие у них были раньше и разбираться с дополнительными не будут - ибо проще работать так как привыкли ранее. Причем у них проблема противоположна вашей - все атрибуты внутри ЦБ и для них первоначальное создание БД является только дополнительной работой (все атрибуты из ЦБ надо перетащить в БД). Новые тоже зачастую открываю LM и делая ЦБ по тренингам, начинают считать что и так всего получаемого внутри ЦБ пока им достаточно. Собственно говоря, проблема заключается только в том, что если бы кто-то заполнил им БД и на протяжении некоторого времени помог в работе с ней, то через некоторое время считали бы что без БД плохо. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Frederic 0 4 марта, 2012 Опубликовано 4 марта, 2012 · Жалоба .................................. vitan, плиз сделай видео желательно с голосом (минут 5....15) как у тебя протекает процесс догадываюсь, что fill имеет полное представление о сути беседы, но многие которые работают только в ЦБ (в том числе я) не понимают о чем идет речь иначе вам с fill надо перенести беседу в другое место и с :beer: для полного взаимопонимания Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться