[PeterD 0]

1. Есть атрибут Part Number это уникальный номер компонента. Второго такого номера не может быть ни в ЦБ ни вообще в мире.

В ЦБ вы создаете Part в котором ссылаетесь на применяемый символ(ы), посадочное место(а) и формируете таблицу соответствия пинов.

В данном случае Part=Part Number.

Когда в редакторе схемы, в окне DxDatabook, вы выбираете закладку CL (внизу) и закладку Part View (вверху), в таблице отображается список разделов компонентов, которые есть в данной ЦБ. При раскрытии раздела, вы видите компоненты, хранящиеся в данном разделе. Выбрав конкретную строчку с компонентом, система лезет в ЦБ и по Part Number считывает из соответствующего Part значение символа и посадочного места, по которым уже берет графическое изображение соответствующего символа (из символьных разделов) и посадочного (из разделов Decal).

 

2. БД является надстройкой к выше перечисленному. В ней хранятся только значения атрибутов компонентов. Соответственно, в таблицах обязательно есть атрибут по которому можно установить соответствие между данными в таблице и компонентами в ЦБ. Обычно это атрибут Part Number. Т.е. если в БД есть например строчка со значением PN_001 в колонке Part Number, то при выборе такой строчки в DxDatabook (в закладке Search) система возьмет все данные атрибутов из соответствующей таблицы БД, а также выполнит все действия описанные в п1 по поиску компонента PN_001 в ЦБ. Т.е. в данном случае происходит считывание и размещение на схему данных из двух источников (БД и ЦБ).

Заметьте также что DxDatabook имеет возможность настройки подключения к БД. Т.е. необязательно название колонки в таблице = название атрибута. Вы можете в таблице назвать колонку PN, но в конфиг. файле DxDatabook написать что PN=Part Number, т.е. на схему разместится атрибут Part Number со значением из колонки PN. Также можно указать какие колонки в БД не надо обрабатывать (отображать\размещать\проверять\аннотировать), т.к. они например нужны снабженцам но не вам.

fill спасибо большое, приходит понимание. Правильно я понимаю что в ЦБ это все хранилище то есть нет смысла делать отдельную ЦБ от проекта к проекту т.к нельзя подключить две ЦБ в проект. К примеру есть ЦБ с пассивными компонентами и операционными усилителями, для одновременного применения в проекте совершенно

необходимо чтобы в ЦБ находились и пассивные компоненты и операционные усилители т.е. нельзя сразу подтянуть две раздельных

центральных библиотеки в один проект. Еще раз спасибо за терпение.

 

[fill 2]

fill спасибо большое, приходит понимание. Правильно я понимаю что в ЦБ это все хранилище то есть нет смысла делать отдельную ЦБ от проекта к проекту т.к нельзя подключить две ЦБ в проект. К примеру есть ЦБ с пассивными компонентами и операционными усилителями, для одновременного применения в проекте совершенно

необходимо чтобы в ЦБ находились и пассивные компоненты и операционные усилители т.е. нельзя сразу подтянуть две раздельных

центральных библиотеки в один проект. Еще раз спасибо за терпение.

 

К проекту подключается только одна ЦБ.

В ЦБ есть возможность создавать разделы для группировки определенных типов символов\посадочных\компонентов.

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

Доступность\выбор компонентов можно также регулировать через различные конфигурации DxDatabook. Например создать конфигурацию где видны только компоненты определенной фирмы или типа исполнения или ...

[PeterD 0]

К проекту подключается только одна ЦБ.

В ЦБ есть возможность создавать разделы для группировки определенных типов символов\посадочных\компонентов.

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

Доступность\выбор компонентов можно также регулировать через различные конфигурации DxDatabook. Например создать конфигурацию где видны только компоненты определенной фирмы или типа исполнения или ...

Спасибо fill огромное за помощь.

[PeterD 0]

Подскажите пожалуйста не могу разобраться, при добавлении компонента из БД с помощью "Add new component with all Properties" компонент добавляется но нет номеров пинов, они скрыт, если добовлять "Add new component only with common Properties" на символе отображаются номера пинов но соответственно свойства компонента только из ЦБ. Как сделать чтобы номера пинов символа были видны. Спасибо.

 

[fill 2]

Номера добавляются если они выбраны в поле Slot.

[PeterD 0]

Друзья продолжаю разбирается с PADS, вот такой вопрос при создании своего компонента в PADS Decal при работе с Pad Stacks Properties слоя маски пасты и припоя не добавляются автоматически т.е. их приходится добавляться в ручную и потом конфигурировать. Я не до шёл еще до вывода Гербера для производства. Но на мой взгляд это делать достаточно утомительно, может есть более правильный и простой или этого вовсе можно не делать?

 

[Gorby 6]

при создании своего компонента в PADS Decal при работе с Pad Stacks Properties слоя маски пасты и припоя не добавляются автоматически т.е. их приходится добавляться в ручную и потом конфигурировать. Я не до шёл еще до вывода Гербера для производства. Но на мой взгляд это делать достаточно утомительно, может есть более правильный и простой или этого вовсе можно не делать?

 

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

 

Но в жизни бывают и другие случаи, поэтому идеологически правильным выглядит явное указание вырезов в маске и пасту в падстеке. Но это заморочно. Но позволяет контролировать каждую индивидуальную площадку. При этом при формировании герберов указываем, что геометрию вырезов брать именно из SolderMask и PasteMask, а не объект PAD из слоя ТОР.

 

Трюк: если не задан, то копируется с площадки меди, а вот если задан - то с сответствующего слоя. Но бывает, выреза и не надо, а оно его само с меди ставит. Трюк заключается в том, что ставим наличие выреза в слое маски, но его диаметр делаем 0 или 0,001мм. Таким образом получим закрытую площадку - выреза в маске не будет. Иногда полезно для VIA.

Ну и читаем документацию на PADS Layout - там специально таблица приведена - приоритеты при создании графики маски и пасты.

 

>>Я не до шёл еще до вывода Гербера для производства.

А вот зря. Это очень просто и легким движением руки вы уже сможете увидеть превью выходного слоя AS-IS. Очень помогает в понимании того, как и что подключать для вывода в гербер.

 

Удачи.

[PeterD 0]

Друзья спасибо за ваши ответы. Продолжаю терзать PADS подскажите не могу разобраться на этапе создания элемента почему нельзя к нему добавить 3D модель, перерыл весь "хелп", но нашел только путь добавления из PADS Layout, а на этапе создания элемента в PADS Decal иконки импорта не активны и хелпе ни намека на возможность добавления модели.

 

[Gorby 6]

перерыл весь "хелп", но нашел только путь добавления из PADS Layout

 

Ну потому наверное, что такая идеология:

3D модели сопоставляются компонентам НА ПЛАТЕ [а не в библиотеке , на бронепоезде или на танке].

Что очень логично - закончили разводку платы (ну или насыпали элементов) - и каждому ТИПУ декали поставили в соответствие 3D модель.

Эти модели и это соответствие хранятся в своей собственной локальной директории.

Таким образом 3D присутствует, но не мешает. Вот Вы хотели бы все степ-модели иметь внутри файла платы? Вот и я не хочу. Вот их там и нет.

[ClayMan 0]

Вообще говоря логичнее и правильнее - как раз наоборот, привязывать 3D модель на этапе библиотеки. Тогда будет единообразие и надежность, т.к. при создании библиотек их обычно проверяют. А если насыпать на плате по месту, то будет кто во что горазд - на выходе одни и те же компоненты в разных платах будут иметь разные модели, далеко не всегда корректные.

[PeterD 0]

При создании элемента с нескольким "Юнитами" в одном корпусе можно ли заставить упаковщик, расставлять RefDes как U1.1, U1.2 и т.п. иначе получается не очень удобно на мой взгляд. К примеру, вот два транзистора n-p-n и p-n-p в SOIC8 он их обозначил как VT1, а хочется VT1.1 и VT1.2.

 

 

При создании не стандартной Decal часто на ней требуется поставить Via и медью что ни будь изобразить (Altium разрешает ставить Via) здесь же приходится добавлять Terminalю Затем при упаковки с символом Я делаю их Unused, на сколько это нормально или есть какие то другие способы. Вот к примеру PCB антенна имеет 21 Terminals хотя реально нужен только один.

Изменено 18 июля, 2017 пользователем PeterD

[Gorby 6]

примеру, вот два транзистора n-p-n и p-n-p в SOIC8 он их обозначил как VT1, а хочется VT1.1 и VT1.2.

 

При создании не стандартной Decal часто на ней требуется поставить Via и медью что ни будь изобразить (Altium разрешает ставить Via) здесь же приходится добавлять Terminalю

 

1 - что-то Вы не так делаете. Секции именуются VT1-A, VT1-B.. в PADS Logic. В DxDesigner не знаю какие правила.

 

2- антенну скорее надо бы делать не компонентом, а прямо на плате, сохранить в библиотеку Reuse. И потом пользовать. Ведь ей не сопоставлен никакой реальный (покупной) компонент.

 

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

 

Остается только гадать, почему VIA нельзя использовать в компоненте. Может, иная сущность, отличается от PIN во многих аспектах.

 

 

 

[fill 2]

При создании элемента с нескольким "Юнитами" в одном корпусе можно ли заставить упаковщик, расставлять RefDes как U1.1, U1.2 и т.п. иначе получается не очень удобно на мой взгляд. К примеру, вот два транзистора n-p-n и p-n-p в SOIC8 он их обозначил как VT1, а хочется VT1.1 и VT1.2.

 

От изображения номера вентиля отказались еще в прошлом веке, т.к. во всем мире это считается избыточной и не нужной информацией - нужны только номера пинов. Номера вентилей ранее нужны были только для ручного отслеживания заполнения корпусов, теперь эта информация доступна автоматом в файле UnusedGates.txt. Кроме того, U1.1 в нетлисте будет интерпретироваться как пин 1 компонента U1.

[Gorby 6]

От изображения номера вентиля отказались еще в прошлом веке, т.к. во всем мире это считается избыточной и не нужной информацией - нужны только номера пинов. Номера вентилей ранее нужны были только для ручного отслеживания заполнения корпусов, теперь эта информация доступна автоматом в файле UnusedGates.txt. Кроме того, U1.1 в нетлисте будет интерпретироваться как пин 1 компонента U1.

 

Ну как сказать, в вентиле пинов может быть и 400. При разбиении FPGA, например. И без явного показывания какой именно вентиль перед тобой бывает тяжко.

[fill 2]

Ну как сказать, в вентиле пинов может быть и 400. При разбиении FPGA, например. И без явного показывания какой именно вентиль перед тобой бывает тяжко.

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

Чтобы понять все ли я символы данной микросхемы разместил на схеме мне достаточно заглянуть в файл UnusedGates.txt, а не пытаться сканировать глазами всю схему на предмет, а все ли они присутствуют. А при использовании IOD и этого бывает не нужно, т.к. он сам создает подсхему на которую "выбрасывает" все символы данной FPGA.

Попробуйте ответить на вопрос какую конкретно полезную информацию дает вам отображение на схеме номера вентиля. Ну увидели вы номер 2 например и что?