Хотим перейти на Orcad/Allegro.
Пока конечно мало о нем знаю (почитал по диагонали Kreig Mitzner и прочие доки).
Встал вопрос об организации центральной БД компонентов используемых в изделиях предприятия.
Как это лучше сделать для "Orcad Capture -> PCB Editor" Flow?
CIS я так понял это просто надстройка содержащая ссылки на файлы падстаков и OLB. И если это так то сложно его назвать базой данных, это просто представление данных которые валяются в виде файлов и редактирование происходит вообще не через него (может я чего-то не нашел).

Сейчас основная идея вынести файлы на сервер и там их редактировать, но возникает тогда проблема совместного доступа.
Т.е как разрешить конфликты совместного редактирования OLB файлов?
И есть ли возможность хранить данные как-то в другом виде например в БД в виде BLOB полей или таких же файлов но чтобы конфликты доступа разрешал сервер?

как я понимаю вы только решаете на какую программу перейти... с одной из целей которых будет - построение (подвязка) пути к базе данных эл-ых элементов фирмы - в данном случае лучшее решение этой задачи представлено в системе программ Altium - так что у вас еще есть время подумать какую систему покупать... советую - Altium 10... удачи

CIS-автоматически синхронизирует и выверяет данные о компонентах во внешних базах данных и базе данных проекта. CIS опции реализуют интерфейс с любой базой данных, которая удовлетворяет стандарту Microsoft’s ODBC. Возможен непосредственный доступ к данным, хранящимся в системах MRP, ERP и PLM при построении моделей компонентов. Гибкость системы позволяет нескольким пользователям осуществлять одновременный доступ к информации без взаимовлияния. Благодаря быстрому доступу, удобной системе поиска и возможности вставки компонентов в проект непосредственно из внешней базы, CIS значительно сокращает время разработки печатной платы.

Кроме того, существуют программные продукты Cadence Allegro Design Workbench и Allegro PCB Librarian

Сообщение отредактировал Alexander E - Mar 23 2011, 07:47

чтобы не плодить тут тем.

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

или надо в начале каждого проекта просто скачивать все на локальный компьютер, на котором установлен САПР?

просто, у меня не получается настроить, может не с того конца начал или вообще не так все понял.

Все какие-то общие фразы, типа наш продукт лучше и поддерживает те и те интерфейсы.

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


Какое взаимное влияние при вставке может быть? мы же открываем на чтение компонент когда его вставляем. Основная проблемма совместное редактирование одной и той же библиотеки.
И вообще крейг в книге вроде как заявляет что желательно не трогать структуру каталогов с компонентами, которая хранится локально, а как сделать чтобы пады, футпринты, olb хранились на сервере?. Сколхозить то я что нибудь могу, но хочется услышать как это сделать правильно.


Попробую почитать их мануал по этим продуктам, но из флаеров так и не понял что они реально это могут сделать.

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

Скорее это.
Вы сильно большой вопрос задали. Много писать не хочется. По частям спрашивайте лучше.

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

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

что то опять получается много

мануалов толком нет или не там ищу

Делается. У нас я так и сделал. Только это вызывает необходимость координировать совместное использование общих ресурсов. У меня, например, это делается с помощью систем контроля версий и управления процессами, которые не привязаны к каким-либо САПР вообще.
Пользователям закрыт доступ к общим ресурсам иначе чем через контроль версий, а к некоторым ресурсам еще и процесс написан. Работает.

Во. Можно поподробнее?
Я предполагал следующую схему:
1. Создать репозиторий на сервере SVN для библиотеки
2. Закоммитить туда каталог со всей фигней (футпринты, олбэшки и т д)
3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет).
4. Пользователь может локально внести изменения и закоммитить их затем на сервер.

Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??.
Нет ли проблем со служебными каталогами .svn (если кто-то использует subversion)?
Может лучше GIT?

Пытался когда то реализовать эту схему для ментора, тот вообще ругался на .svn каталоги.
Также одна из причин то чем плох альтиум для использования его с системами контроля версий это его огромные размеры файлов.

У меня есть отдельный каталог на сервере, в котором отражается текущее состояние репозитория. Каталог доступен только по чтению. Юзерам рекомендовано пользоваться им как основной центральной библиотекой. Но не запрещается пользоваться своими локальными.


Это только кажется, что удобно. Вы что делаете, когда реально возникает конфликт в текстовом файле? Скорее всего, идете и на словах общаетесь со второй стороной. При этом действия обеих сторон не формализованы. Чтобы избежать в этом бардака, применяются системы контроля процессов.


Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка SVN.

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

Была проблемма когда я запихал БД в свн. Central library воспринимал подкаталоги svn как часть этой библиотеки и выдавал всякую билеберду. DxDesigner/Expedition flow. EE 2005 вроде.

Про альтиум не знаю. Может быть. И что svn там не только для исходных текстов vhdl/c++ применяется?

В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc.

Кстати если порытся на сайте то можно и найти эти проблеммы совместимости svn и expedition http://electronix.ru/forum/index.php?showt...p;hl=Subversion

А никто и не говорил, что надо svn применять для баз данных. Это надо применять для контроля версий угошников и футпринтов. А с БД работать через ODBC или еще какой интерфейс, это да.

Да, суръёзная проблема. Тоже много думал над ней.
vitan правильно все говорит, доступ к библиотечным файлам реализуется через контроль версий.
Если репозиторий лежит в локальной сети, то Аллегру настроить непосредственно на репозиторий,
если в интернетах, то использовать локальный репозиторий.
Править же сами файлы необходимо средствами контроля версий.

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

Базой данных я назвал собственно набор угошников и футпринтов. Которые в оркаде хранятся в виде файлов в каталогах.
Это же и есть ваша база данных. И вот с ней надо работать через ODBC, а не через проводник. В нашем случае Windows explorer (если точнее Windows API для файлов) тоже является средством доступа к БД, только он разрешает проблеммы совместного доступа на уровне файлов (файл == одна запись в БД). Но проблемма в том что у оркада один файл соответвует нескольким записям.

И ещё через с оркадом можно было бы нормально работать с БД на уровне файлов, если бы перед сохранением компонента он заново загружал файл с источника (на тот случай если его уже кто-то добавил новый компонент или отредатировал ваш, пока вы правили компонент), помечал его признаком только чтения (на время сохранения), вносил изменения (разрешал конфликты если они есть) и сохранял.
Сейчас он сохраняет olb файл видимо прямо из своего ОЗУ не проверяя внесли ли в него изменения пока он был открыт у вас.

Пока работаем через расшаренную папку. Вообщем то для небольших фирм годится, но на корпоративное решение не тянет .

Кто нибудь знает Capture будет когда-нибудь под линух? или надо под HDL переходить?

Сообщение отредактировал Nemod - Jun 21 2011, 18:09