Я бы даже сказал, сюда...

Всё это хорошо, но те базы и библиотеки, что можно посмотреть (включая SampleLib), весьма неполноценны, что ли...

В частности, "вызывает интерес вот какой ещё разрез". Если использовать только ЦБ, без БД, то для одного компонента (Part) можно указать несколько посадочных мест (Cell): одно основное и более-менее произвольное число дополнительных (правда, требуется, чтобы у них было одинаковое число выводов, совпадала нумерация и отображение логических выводов символа на физические выводы любого посадочного места). В таком случае при установке символа на принципиальной схеме нет жёсткой привязки к конкретному посадочному месту: после передачи проекта в Expedition в процессе расстановки компонентов по плате можно выбирать любое из предусмотренных посадочных мест. Скажем, если для резистора заданного номинала, точности и т.п. заданы Cell'ы 0402, 0603 и 0805, то по умолчанию предлагается одно из них, но прямо в Expedition можно выбрать и любое из двух других. В SampleLib же (как и в библиотеке и базе у cioma) компоненты жёстко привязаны к корпусам; даже Part Number'ы содержат прямое указание на то, какой корпус используется. В такой ситуации, надо полагать, для замены корпуса необходимо сначала поменять компонент в DxDesigner, затем заново упаковать и аннотировать в Expedition, что явно менее удобно, чем при использовании альтернативных Cell'ов, заданных прямо в ЦБ. В связи с этим возникает вопрос: можно ли обеспечить такое же удобство для связки ЦБ+БД? Думается, что да (во всяком случае, я не вижу причин, почему бы этому не работать, ну и собираюсь проверить на практике). Однако сразу же всплывает второй вопрос: а откуда DxDesigner, Expedition, CES и т.д. берут необходимые значения свойств, связанных с взаимосвязью между компонентами, символами и посадочными местами: всегда из ЦБ или же сначала смотрят БД, и лишь при отсутствии там необходимой информации обращаются к ЦБ? В первом случае, который мне представляется более вероятным, поля БД типа Footprint и т.п. служат исключительно для поиска и "документирования", но реальное посадочное место не задают. Однако тогда возможна ситуация, когда Expedition позволяет для компонента использовать корпус, который в реальности для данного номинала не предусмотрен. Например, находящийся в ЦБ обобщённый компонент "конденсатор" состоит из стандартного символа и посадочных мест 0402, 0603, 0805, 1206 и 1210. Конкретный номинал существует лишь для некоторых из этой группы посадочных мест. Тогда при поиске по номиналу в DxDatabook мы получим группу строк (записей из БД), в столбце Footprint которых будут указаны все реально возможные корпуса для данного номинала (предполагается, что БД заполнена правильно). Однако при установке такого компонента в Expedition будет возможность выбрать любой из Cell'ов, заданных в ЦБ, т.е. без учёта того, существует таковой для данного конкретного компонента или нет, поскольку информация об упаковке, а значит, и о Cell'ах, находится только в ЦБ. Так ли это на самом деле и есть ли возможность ограничить Expedition выбором лишь допустимых посадочных мест, не увязывая их жёстко с Part Number'ами, а соответственно, не заставляя для замены посадочного места изменять принципиальную схему, меняя один компонент на другой?

Пытался связать ЦБ с БД и наткнулся на непонятную проблему. После создания конфигурации DxDatabook в Library Manager и входе в её редактирование (окошко Configure) оказывается невозможным связать разделы ЦБ с таблицами. Стою на имени раздела, нажимаю Add Table, появляется одноимённое окошко, в котором надо указать Data Source (DSN) и Table Name. Выпадающий список для DSN пуст. Нажимаю рядом кнопку New, открывается новое окошко, Data Source Manager. В нём можно благополучно добавить новый DSN для выбранного источника (на скриншоте выбрана моя база; там же присутствует база от SampleLib). Однако после нажатия OK в окошке Add Table поле Data Source (DSN) по-прежнему будет пустым, т.е. источник не добавляется. Соответственно, невозможно добавить и таблицу из этого источника.

Точно так же дело обстоит и в SampleLib: там DxDatabook уже сконфигурирована, т.е. разделы ЦБ связаны с таблицами БД. Однако добавить новую связь и т.п. невозможно.

DSN Expedition системный или пользовательский? Проверьте, там рекомендуют делать системные...
А вообще похоже просто на глюк...

Был пользовательский, сделал системный, но с тем же результатом... Что глюк -- похоже на то, но вот как его лечить?..

Вот.
Доведет эта ЦБ до ручки!


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


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

Посадочные места не должны являться параметром компонента. Если Вы так сделаете, то компонент станет абстрактным, а не реальным. Ни один САПР ПП не рассчитан на это, все они работают с реальной геометрией, что есть глубоко правильно.

В крайнем случае можете сделать несколько альтернативных посадочных мест каждому компоненту, например, по нормам IPC (L, N, M). Или еще бывают отдельные случаи, когда, например, светодиод с ногами можно впаять прямо, а можно с загибом.
Это будет нормальное использование САПР по назначению, а не так, как Вы придумали.

to SII

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

Если говорить только про это, то, думаю, сие не вызовет проблемы, просто BOM надо формировать не по "голому" Part Number, а по связке Part Number + Cell (вроде как это можно настроить, но не проверял).



Если уж так ставить вопрос, то доведёт БД, а не ЦБ -- последняя работает сама по себе великолепно. Вот в PADS, где её нет и есть только "голая" БД, я натрахался предостаточно. Собственно, это и стало основной причиной, почему я решил-таки сосредоточиться на Expedition (и пилить шефа взять именно его, несмотря на раз в 5 более высокую цену: оно того стоит).



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



Это есть глубоко неправильно, поскольку САПР ПП имеют два уровня: уровень принципиальных схем и уровень самой платы. Первый никак не привязан к "геометрии" и не должен быть к ней привязан (хотя бы потому, что на этапе разработки схемы не всегда известно, какие конкретно компоненты будут использоваться). Использование альтернативных посадочных мест, собственно, и отвязывает уровень схем от этой самой "геометрии".

Другое дело, что в существующих САПРах поддержка такой "развязки" может быть не реализована должным образом или вообще отсутствовать. Более того, она, скорей всего, именно что сделана криво, и попытка использовать имеющиеся возможности типа альтернативных корпусов в ЦБ Expedition чревата возникновением ошибок. В идеале же САПР не только должна давать возможность выбирать корпуса для компонентов в процессе их установки на плату, но и позволять штатным образом, а не через известное место, создавать несколько различных плат для одной и той же принципиальной схемы, совершенно не меняя последнюю. Например, в процессе отладки схемы можно использовать крупные SMD-резисторы и конденсаторы, микросхемы в SOICах или вообще в DIPах, ну а для серии перевести всё на какие-нибудь 0402 и BGA, чтобы уменьшить массу и габариты.

В общем, вопрос про альтернативные корпуса остаётся открытым -- хотя бы в теоретическом плане (делать так на практике или нет, пока не знаю; сейчас ЦБ у меня жёстко привязывает компоненты к корпусам, хотя для интереса я и попробовал альтернативные и убедился, что сам по себе механизм работает).

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

Вот именно.
В схеме Вы можете отвязаться от геометрии.
И ментор предоставляет такую возможность.
Для этого используется команда annotate generic.

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


Так что это правильно. Annotate generic Вам в помощь.

А вот создать несколько разных плат при одной схеме (совершенно одинаковой) можно только вручную. В этом случае проекты схемы и платы будут просто не связанными, т.к. информации для разных вариантов будет просто неоткуда взяться. Думаю, Вас этот вариант не интересует.
Единственно возможный способ здесь - создать заготовку схемы с generic-компонентами, а при создании вариантов ПП делать новый эеземпляр схемы с unique-компонентами.

Схема работы, про которую Вы говорите, характерна для MCAD. Там имеет смысл параметризировать геометрию. Но этам это делается потому, что Вы разрабатываете эту геометрию. А в САПР ПП вы не разрабатываете само посадочное место, Вы его заимствуете из внешних чертежей.

тогда вам надо использовать старый добрый Pcad4.5
там вообще не было компанентов, только sym и prt
а sym имел атрибут prt=...... , где можно было прописать все что пожелаешь для прохождения операции упаковки

хотя это от ручной работы не освобождало как и от кучи ошибок от из=за этого

В этом смысле работа без ЦБ от пикада недалеко ушла. Но применение базы позволяет-таки нормально работать и прописывать корпуса автоматически на уровне схемы...
А применение ЦБ... Ну Вы мое мнение знаете.

Поставил Expedition на другую машину, где отродясь продуктов MG не было. Однако описанная мною ранее проблема с ЦБ + БД никуда не исчезла: не удаётся связать разделы ЦБ с таблицами, и всё тут. Цитирую своё предыдущее описание:



Никаких умных мыслей ни у кого нет?

Если бы у меня появились такие же проблемы, то начал бы искать где. Пока я вижу все таблицы из 6-ти запущенных у меня баз.

Ну, я тоже вижу таблицы, если они прицеплены к базе заранее -- как это имеет место быть с учебной ЦБ (SampleLib2007, если память не отшибло). Но вот прикрутить новые таблицы не получается...

И даже новую таблицу из базы SampleLib2007 не получается? Может, у Вас с правами доступа что-то понаделано?