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

здеся

Вопрос к топикстартеру: а какую базу данных для DxDB используете? Ну или планируете использовать?

Если не нужен параллельный доступ нескольких библиотекарей, и количество компонентов в районе тысяч, то даже одним обычным .csv файлом можно обойтись. И редактировать его в Calc или Excel.

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

Они и не будут возникать при грамотно построенной работе.
Добавил Part Number, переключился в таблицу и ввел его атрибуты. Это ведь все равно надо делать где-то, не в таблице так в PDB.
А ЦБ вы не ведете только по тому что не работаете в Exp. Иначе без ЦБ никуда не деться - посадочные места и т.п. где то же должны создаваться\хранится.

А если добавить сначала в базу, то это уже неграмотно разве? Нет, тут все-таки не хватает некоего синхронизатора.


Как? А что, просто по нетлисту с EXP уже нельзя работать? Чтобы футпринты просто файлами лежали? Я припоминаю, что можно было, а при упаковке создавалась некая Local PDB. Но это же не ЦБ!

cioma


Я лично прикрутил MySQL. Законной лицензии на MS Access нет и не будет: он нам попросту не нужен, и покупать резона нет. Есть лицензионный MS SQL Server, но, во-первых, он стоит на конторском сервере, а связь из дома (где я почти всю работу работаю) не шибко устойчивая, а во-вторых, это надо вникать в работу с ним, а с MySQL я пускай очень поверхностно, но уже знаком. Вот и развернул сервер у себя на компе. С PADS'ом, когда его мучил, работало без каких-либо проблем; сейчас уже создал и прикрутил базу к ЦБ, но пока ещё не настроил: занимаюсь упорядочиванием самой ЦБ

Кстати говоря, я посмотрел на структуру учебной ODBC-базы и увидел, что Part Number в ней не является уникальным. Получается, если добавляем на схему какой-нибудь, например, конденсатор, выбирая его по параметрам (ёмкость, напряжение, точность), то Part Number из соответствующей строки ODBC-базы с этими параметрами будет использоваться для поиска компонента уже в ЦБ, где Part Number уникален?

vitan
Соглашусь, что синхронизатора как "защиты от дурака" действительно не хватает. Хотя надеюсь, что MG со временем всё ж доведёт подобные мелочи до ума

Ещё один попутный вопрос возник. Когда создаю посадочное место (Cell), надо ли что-то делать в слое Placement Obstruct? Его назначение пока не совсем понятно, но впечатление такое, что в нём чертится замкнутый контур, внутри которого находится компонент, а другие компоненты не смогут вторгаться в эти границы. И, кстати, каково точное назначение контура в Placement Outline?


ADD. Попытался связать раздел библиотеки компонентов ЦБ с таблицей ODBC-базы: Insert Table на имени раздела, далее в появившемся окошке New напротив поля выбора Data Source (DSN), в открывшемся окне Data Source Manager -- Add и выбор моей ODBC-библиотеки (она подключена и работает). Вроде всё в порядке, имя библиотеки появляется в списке Data Source Names. Однако, когда нажимаю OK, в поле DSN этого имени нет, т.е. база как бы не выбралась. С чем это может быть связано?..

Сообщение отредактировал SII - Feb 29 2012, 19:59

все хорошо описано в тренингах, в часности в Library Manager
Placement Obstruct – области, предотвращающие размещение других компонентов. Атрибуты включают сторону платы и ограничение по высоте.
Placement Outline – это посадочное место ячейки. У каждого контура может быть высота и расстояние до платы, которые используются при DRC. Для обозначения областей ячейки с разной высотой или расстоянием до платы может использоваться несколько контуров. Если не задано ни одного контура размещения, то он сгенерируется автоматически в виде прямоугольника, включающего в себя все контактные площадки в слое монтажа и сборочный контур. Сборочные контуры должны быть замкнутыми.

Local PDB создается и является, однако, частью проекта платы, но футпринты берет из ЦБ. В этом случае внутри ЦБ не нужны никакие PDB и символы, и она "вырождается" в "просто сборище футпринтов". Однако, если в ЦБ есть таки PDB (можно и без символов), и его имя соответствует имени компонента из нетлиста, то для этого компонента Local PDB не создается, предпочтение отдается PDB из ЦБ.
Что вам так не нравится ЦБ? по мне дак наоборот, очень удобно, все в одном месте, гораздо лучше, чем, например, в оркаде.

Гм. Давайте тогда проясним. Я всю жизнь считал, что PDB - это Project Data Base, и что она формируется при использовании DxD+Exp по технологии CDB. Т.е. PDB - это как бы CDB для конкретного проекта. Я правильно понимаю?
Если да, то вопрос: как может PDB быть внутри ЦБ?

При этом отдельный случай, вроде бы, состоял в том, что при использовании нетлиста, а не CDB, при упаковке все равно создавалась некая Local PDB (очевидно, потому что EXP не может совсем без PDB). Правильно?
Если правильно, то получается, что при работе с нетлистом УГО я могу-таки хранить в виде файлов на диске без ЦБ, а футпринты вынужден запихивать все-таки в ЦБ (я просто не помню, давно дело было). В этом случае такая ЦБ мало чем отличается от файлов на диске, ну можно сказать, что она вырождается в сборище футпринтов.

Это первое, что мне не понравилось. Не понравилось потому, что одной из главных причин перехода на DxD в свое время была его возможность работать с разными системами разводки "одновременно". Тогда мы часто отдавали разводку на сторону (эх, были времена ). Кто-то разводил в экспедишене, кто-то в падсе, а кто-то в аллегро. А ЦБ только для экспедишена. А её надо поддерживать, заботиться и все такое. На это времени нету, особенно глядя на другие редакторы PCB, которые спокойно обходятся без этой ЦБ. Вместо это силы тратятся на поддержку БД, что я считаю гораздо более правильным.

вообще то PDB это компаненты, которые получаются из Symbol и Cell


что значит ее поддерживать?

ЦБ DxD по сравнению с Pcad (в другом пакете не работал) небо и земля

Да, PDB это Part data Base, PDB= Symbol + Cell

Согласен с предыдущим оратором - с ЦБ гораздо удобнее...

Ага. Т.е. это просто другое название ЦБ (не имеет отношения к проекту, а вот Local PDB - это как раз база проекта?).


Ну вести ее, заносить туда все эти компоненты, УГО, символы, прописывать свойства. Если основная информация по этим вещам уже ведется в БД, то встает вопрос, зачем делать одно и то же два раза, причем только для Exp?

Нет. ЦБ - это целая библиотека. PDB - это в терминах пикада - компонент. Т.е. ссылка на символ, футпринт, свойства (properties).

1. Посмотрите на рисунки и возможно начнете понимать структуру маршрута.

2. PDB - это сокращенное название компонента (Part Number).

PDB может быть полным, т.е. содержать ссылки на символ(ы), ячейку(и) и таблицу соответствия логических пинов физическим.
И не полным:
а) символ и таблица есть, а ячейки нет
б) ячейка и таблица есть, а символа нет
Неполный вариант а) используется для упаковки схемы без передачи ее на плату
Неполный вариант б) для создания платы на основе нетлиста, т.е. без схемы (DxD или DC).

Кроме того он может быть "сверх полным" - это когда к нему добавили еще и полный набор дополнительных атрибутов (типа Value и т.д)

Любая плата в Exp создается на основе ЦБ, т.к. из нее считывается:
- шаблон платы (layout template)
- стеки площадок (padstack)
- посадочные места (cell)
- компоненты (PDB)
Поэтому любая ЦБ обязана содержать все эти элементы - ну или как минимум шаблон, а падстеки и ячейки в принципе можно загрузить из сторонних файлов или создать внутри проекта платы (в локальной библиотеке). Но вариант работы с полноценной ЦБ намного удобнее, т.к. при прямой аннотации в локальную библиотеку платы автоматом считаются все нужные по списку соединений компоненты, ячейки, падстеки. Заметьте символы не считываются, они нужны только упаковщику схемы для проверки правильности применения символов для компонента.

Компонент (PDB) может содержаться в ЦБ, а может и отсутствовать - зависит от маршрута работы.

DxD-netlist-Exp:
Набора PDB нет в ЦБ. Т.к. файл со всеми нужными PDB создается упаковщиком из схемы и затем загружается в плату (в локальную библиотеку).
Неудобство: нужно всю упаковочную информацию с помощью набора атрибутов прописать на символах схемы.

DxD-iCDB-Exp:
Весь набор PDB в ЦБ. Упаковщик использует один единственный атрибут (Part Number) для поиска нужного PDB в ЦБ и считывания оттуда всей информации об упаковке и доп. атрибутах. И загружает эту информацию на схему (номера пинов + доп. атрибуты).

Соответственно получается в случае нетлиста значения доп. атрибутов нужно обязательно хранить в сторонней базе данных (DxDataBook).
В случае iCDB имеем два возможных варианта:
а) атрибуты внутри PDB.
б) атрибуты в сторонней базе данных.

Ах, вот оно что! Теперь все понятно. Кстати, не находите, что чересчур громкое название для компонента?

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


Я все понял, кроме этой фразы. Что же, без полноценной ЦБ при прямой аннотации компоненты, ячейки и падстеки не считываются? Т.е. Local PDB формируется на основе этих внешних файлов, а не напрямую их ЦБ? И чем это так не удобно? Тем, что в файлах проперти все не прописаны? Так мы же их из DxDataBook берем!