[AlexN 0]

Хм. По существу что-то можете сказать?

 

извиняюсь :bb-offtopic:

с таким же успехом можно докопаться - а зачем нужна винда. В линухе всё лучше.

или, зачем инжектор, карбюратор и так справляется.

[vitan 2]

или, зачем инжектор, карбюратор и так справляется.

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

Хотите сказать, что наличие ЦБ улучшает производительность труда, избавляет от ошибок и т.п.?

Я Вам говорю: нет, и даже наоборот.

 

Почитайте пост 1868.

 

Повторяю, она только снижает эффективность моей работы (ПРИ НАЛИЧИИ БД), т.к.:

1. мне надо туда вносить данные. Это потеря времени. Сопровождается ошибками при конвертации.

2. Данные эти должны повторять их в БД.

3. Автоматической синхронизации с БД нет. Различия надо как-то отслеживать, либо вручную, либо писать кучу прог и скриптов и три года их отлаживать.

4. Результаты лежат в ЦБ в бинарном виде. Нигде более, кроме Exp не используются и не подлежат обработке простейшими скриптами проверки файлов.

 

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

[Frederic 0]

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

работаю только с ЦБ и проблем НЕТ !!!

что там в ЦБ такое настраиватся, что разводка затягивается ???

поясните

 

если новый элемент то так и так его надо делать, и символ и посадочное и упаковку провести

[vitan 2]

поясните

Ух. Что-то утомился я уже пояснять. Неужели три предыдущие страницы не читали?

 

если новый элемент то так и так его надо делать, и символ и посадочное и упаковку провести

Надо. И упаковывать надо. И УГО надо. Только в ЦБ класть не надо.

 

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

[fill 2]

. Могу поспорить на бочку пива, что при прочих равных условиях я начну разводить быстрее просто потому, что у меня не будет лишней операции по внесению корпусов в ЦБ. Я просто возьму их из файла.

 

А в файле они появились из воздуха?

Вы сделали их в каком то редакторе и сохранили в этот файл.

Мы сделали в редакторе встроенном в LM и сохранили соотвественно в эту открытую ЦБ.

Кол-во операций как минимум одинаково.

Вы говорите "возьму их из файла" - мы говорим система сама возьмет из ЦБ.

[cioma 0]

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

 

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

[vitan 2]

А в файле они появились из воздуха?

Вы сделали их в каком то редакторе и сохранили в этот файл.

Мы сделали в редакторе встроенном в LM и сохранили соотвественно в эту открытую ЦБ.

Кол-во операций как минимум одинаково.

Вы говорите "возьму их из файла" - мы говорим система сама возьмет из ЦБ.

Т.е. редактор посадочных мест встроен в ЦБ и без нее мне посадочное место не отредактировать? Интересно...

А что делать, если мне пришел со стороны экспедишеновский файл, а мне надо на его основе сделать новую версию девайса, кое-что подправиви в компонентах? Опять старая песня? Экспортировать во вновь созданную персонально для этого случая ЦБ и там править?

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

Если кто еще не понял: я хочу сказать, что все те действия, которые я могу делать в ЦБ я могу делать и без нее. Иначе я бы не имел кучу готовых проектов. Единственное, что эти проекты выполнены не в Exp.

Просто Вы не хотите признать, что Exp не работает без ЦБ по чисто историческим причинам, этот факт не имеет под собой каких-либо других причин.

А про эффективность работы при наличии БД я уже сказал, она только снижается. Жаль, что ментор этого не понимает.

Fill, а Вы можете привести какую-нибудь статистику, сколько юзеров работает в DxD-DxDB-iCDB-Exp, DxD-iCDB-Exp и DxD-netlist-Exp? Интересно было бы посмотреть... Понятно, что это не говорит не обо всем, но тем не менее...

 

Или забацать опрос? Точно, наверно, так и сделаю.

 

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

Ну вот, хоть кто-то понимает! :)

 

Это дает огромную универсализацию библиотеки, ибо один и тот же символ можно использовать в коспонентах с разной распиновкой.

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

[AlexN 0]

to vitan

 

"не работал, не понимаю, читать не хочу, но осуждаю, всё неправильно"

дискуссия не имеет никакого практического смысла.

[vitan 2]

"не работал, не понимаю, читать не хочу, но осуждаю, всё неправильно"

дискуссия не имеет никакого практического смысла.

Вы откуда такой вывод сделали? Поработал, не понравилось. Просто давно дело было, спросил кое-что для освежения памяти.

А Вы пробовали отказаться (с Вами-то есть о чем поговорить, или Вы теоретик, только с другой стороны)?

 

Создал опрос. Не проходите мимо! :)

[fill 2]

to vitan

 

"не работал, не понимаю, читать не хочу, но осуждаю, всё неправильно"

дискуссия не имеет никакого практического смысла.

 

Согласен - человек не попробовал сам другой вариант работы, и при это категорически не согласен с теми кто много лет работает по другому пути.

 

vitan - успокойтесь, в Exp вшит редактор PDB, cell и padstack. Так что можете редактировать в локальной библиотеке платы без наличия каких либо привычных вам отдельно стоящих файликов - редакторы запускаются изнутри ExpeditionPCB и видят только то что было когда-то загружено в локальную библиотеку этой платы.

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

 

 

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

А в Allegro?

[vitan 2]

Согласен - человек не попробовал сам другой вариант работы, и при это категорически не согласен с теми кто много лет работает по другому пути.

Расставим точки. Чтобы быть категорически не согласным, нужно видеть то, с чем ты не согласен. Я же просто не понимаю. Не буду повторять лишний раз, что именно. Это первое.

Второе: повторяю, этот вариант я пробовал. И мне он не понравился именно двойной работой. Я от него быстро отказался и почти забыл, пока тут не началось... :)

 

vitan - успокойтесь, в Exp вшит редактор PDB, cell и padstack. Так что можете редактировать в локальной библиотеке платы без наличия каких либо привычных вам отдельно стоящих файликов - редакторы запускаются изнутри ExpeditionPCB и видят только то что было когда-то загружено в локальную библиотеку этой платы.

Отлично, я и так спокоен, ибо я давно не имею дела с Exp. Но что я слышу? Оказыватется, не обязательно запускать редактор футпринта из LM!

Самодостаточность ЦБ становится еще более очевидной! Точнее, она не нужна без Exp, a Exp не работает без нее. Я эту ситуацию не критикую, пожалуйста, работайте на здоровье, так во многих САПРах. Но когда есть БД со всеми необходимыми атрибутами мне становится непонятно, ЗАЧЕМ она нужна. :crying:

 

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

Ага. Т.е. это возможно? Возможно поменять компоненты и сделать новую плату без ЦБ, имея только БД, и не переключаясь на нетлист? Помните, в 2005 было так, что однажды включивши CDB назад уже не выключишь...

 

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

А в Allegro?

Примерно так же. Из платы экспортируются посадочные места и описания компонентов, правятся и обновляются. После правки у меня два варианта: или положить поправленный компонент в мою ЦБ (которая на основе файлов) и обновить компоненты в плате оттуда, либо просто подключить в аллегро новый путь поиска (каталог, в котором лежит экспортированный и поправленный компонент) с приоритетом выше, чем каталог моей ЦБ. И обновить опять же.

[fill 2]

Ага. Т.е. это возможно? Возможно поменять компоненты и сделать новую плату без ЦБ, имея только БД, и не переключаясь на нетлист? Помните, в 2005 было так, что однажды включивши CDB назад уже не выключишь...

 

Стоп, откуда взялась БД вы же получили только проект в Exp?

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

[vitan 2]

Стоп, откуда взялась БД вы же получили только проект в Exp?

Как откуда? Я же говорю: сижу, работаю. База рядом шуршит. Приносят. Говорят, поправь маленько, тут и так все стандартное, надо быстро сделать и КД выпустить. Хорошо, говорю, давайте (КД-то я умею быстро генерить благодаря той же базе). Беру проект и...

 

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

Это вы меня спрашиваете? Нет, это я Вас первым спросил. Похоже, что никак, все-таки. Потому что ЦБ и Exp неразлучны. И никуда от ЦБ не деться, будь у меня хоть все компоненты мира со всеми их свойствами и упаковочной информацией в базе прописаны.

Для порядка ответьте, пожалуйста, что будет, если компоненты в базе таки будут (если я их туда добавлю)?

[fill 2]

Примерно так же. Из платы экспортируются посадочные места и описания компонентов, правятся и обновляются. После правки у меня два варианта: или положить поправленный компонент в мою ЦБ (которая на основе файлов) и обновить компоненты в плате оттуда, либо просто подключить в аллегро новый путь поиска (каталог, в котором лежит экспортированный и поправленный компонент) с приоритетом выше, чем каталог моей ЦБ. И обновить опять же.

 

Ну наконец-то: Т.е. экспортировать элементы платы в некую папку, чтобы затем произвести еще некоторое количество действий чтобы эта папка стала видимой редакторами вы считаете простым и быстрым путем. А выполнение одной команды экспорта в ЦБ очень сложной?

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

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

 

Это вы меня спрашиваете? Нет, это я Вас первым спросил. Похоже, что никак, все-таки. Потому что ЦБ и Exp неразлучны. И никуда от ЦБ не деться, будь у меня хоть все компоненты мира со всеми их свойствами и упаковочной информацией в базе прописаны.

Для порядка ответьте, пожалуйста, что будет, если компоненты в базе таки будут (если я их туда добавлю)?

 

Отвечаю: если компоненты есть, то нужно будет на схеме каким-то образом обновить\заменить символы на ваши (в которых есть вся упаковочная информация).

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

[vitan 2]

Т.е. экспортировать элементы платы в некую папку, чтобы затем произвести еще некоторое количество действий чтобы эта папка стала видимой редакторами вы считаете простым и быстрым путем. А выполнение одной команды экспорта в ЦБ очень сложной?

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

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

 

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

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

 

Отвечаю: если компоненты есть, то нужно будет на схеме каким-то образом обновить\заменить символы на ваши (в которых есть вся упаковочная информация).

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

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

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

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