[vpd 0]

Здравствуйте, коллеги!

 

Имеется следующая проблема с экспортом IDF из OrCAD PCB Editor.

 

2. При построении в Компас-3D компонентам принято задавать наименование, чтобы было легче ориентироваться в сборке. Так вот, пока мы работали с файлами IDF, созданными в layout, то в них в поле Part Number выводилось свойство Value компонента. Так что в Компасе в дереве построения сборки можно было увидеть что-то типа "R14: 1K 1%". И это было удобно, в сборке можно было ориентироваться даже без схемы под рукой. А теперь вот решили попробовать с новым оркадом, и выяснилось, что в IDF попадает совсем другая информация. Что-то вроде свойства Source Package. И гадость в том, что это свойство может быть одинаковым для множества компонентов с разными номиналами, например, для конденсаторов. Например, смотрим записи про одинаковый компонент C24:

--

у Layout Plus:

SMC0603_C24 "0.01UF" C24

1025.000000 855.000000 270.00 BOTTOM PLACED

у PCB Editor:

SMC0603_C24 C-SMALL C24

1025.0 855.0 0.0 270.000 BOTTOM PLACED

--

Как видим, в одном случае было 0.01UF, а стало C-SMALL. И это C-small повторяется вообще для всех конденсаторов, нарисованных на схеме с помощью одного символа. И в итоге в дереве сборки в Компасе мы увидим "C24: C-SMALL", так что будет совершенно ничего не разобрать.

 

Вопрос заключается в том, можно ли перенастроить все так, как было в OrCAD Layout Plus. В идеале - вообще научить его транслировать в IDF любое свойство из capture, указанное пользователем.

 

[vpd 0]

Неужто никто IDF не пользует?

[shurila 0]

Неужто никто IDF не пользует?

IDF пользую, но в приложении к связке SolidWorks + CircuitWorks 9. Более подробно у меня на сайте.

Для уменьшения базы компонентов , CircuitWorks 9 настроен таким образом, что номинал (поле value) не учитывается (т.е. элементы в одинаковых корпусах выглядят одинаково).

При этом из Layout Plus и PCB Editor все идентично.

Компас-3D не пользовал.

 

В идеале - вообще научить его транслировать в IDF любое свойство из capture, указанное пользователем.

Во всяком случае для IDF 2.0 и IDF 3.0 такой возможности не видел.

[vpd 0]

Ура, хоть кто-то использует :-)

 

Судя по приведенным данным на сайте, проблема, описанная мной, в CircuitWorks 9 не решена. Дело не в том, что элементы выглядят одинаково, это определяется соответствием футпринт-модель. Дело в том, какое наименование получает компонент в дереве сборки. На картинках Ваших этого не видно, так как ни один из плюсиков на рис.3 не раскрыт.

 

Но вообще, абсолютно не важно, чем там строится модель, Солидом, Компасом или еще чем то. Суть именно в содержании самого IDF. В случае IDF от PCB Editor я просто не наблюдаю там "интересных" данных, из которых можно было бы построить информативное наименование компоненту.

 

PS: Ссылку посмотрел, вспомнил все проблемы обычных конвертеров из IDF в отношении ориентации моделей. Дело в том, что у меня конвертер IDF в 3D-модель собственного производства, он иначе ориентирует компоненты, что позволяет экономить много времени. Суть такая. Пользователь берет модель и создает в ней локальную систему координат (ЛСК), плоскость XOY которой ориентирована так же как и плоскость футпринта в библиотеке OrCAD. Далее конвертер сам находит эту ЛСК по имени ('MTG') и крутит компонент.

[Old1 0]

Ура, хоть кто-то использует :-)

 

Судя по приведенным данным на сайте, проблема, описанная мной, в CircuitWorks 9 не решена. Дело не в том, что элементы выглядят одинаково, это определяется соответствием футпринт-модель. Дело в том, какое наименование получает компонент в дереве сборки. На картинках Ваших этого не видно, так как ни один из плюсиков на рис.3 не раскрыт.

 

Но вообще, абсолютно не важно, чем там строится модель, Солидом, Компасом или еще чем то. Суть именно в содержании самого IDF. В случае IDF от PCB Editor я просто не наблюдаю там "интересных" данных, из которых можно было бы построить информативное наименование компоненту.

 

PS: Ссылку посмотрел, вспомнил все проблемы обычных конвертеров из IDF в отношении ориентации моделей. Дело в том, что у меня конвертер IDF в 3D-модель собственного производства, он иначе ориентирует компоненты, что позволяет экономить много времени. Суть такая. Пользователь берет модель и создает в ней локальную систему координат (ЛСК), плоскость XOY которой ориентирована так же как и плоскость футпринта в библиотеке OrCAD. Далее конвертер сам находит эту ЛСК по имени ('MTG') и крутит компонент.

Да используют и многие... В IDF-файле PCB Editor -a кроме прочего содержится свойство Devtype компонента, которое состоит (по крайней мере у меня) из ИмениСимволаВCapture_ИмениФутпринта_СвойстваValue. Этот самый Devtype содержит номинал компонента и виден в дереве, что в Компасе, что в SW.

[inter_pro 0]

Имеется следующая проблема с экспортом IDF из OrCAD PCB Editor.

2. При построении в Компас-3D компонентам принято задавать наименование, чтобы было легче ориентироваться в сборке. Так вот, пока мы работали с файлами IDF, созданными в layout, то в них в поле Part Number выводилось свойство Value компонента.

Нужно помнить, что этот редактор для OrCAD чужой, поэтому здесь с полями текстовыми может быть нестыковка. Вообще PCB Editor по умолчанию берет в IDF поле PART NUMBER, но для интереса посмотрите что записано в этом поле в редакторе OrCAD Capture...

В самом PCB Editor есть настройка Setup>Preferences (см. рис.), и там можно задать параметр idf_ignore_part_nimber, после этого в IDF будет идти поле Device Type, которое по содержанию вам должно подойти...

[vpd 0]

Да используют и многие... В IDF-файле PCB Editor -a кроме прочего содержится свойство Devtype компонента, которое состоит (по крайней мере у меня) из ИмениСимволаВCapture_ИмениФутпринта_СвойстваValue. Этот самый Devtype содержит номинал компонента и виден в дереве, что в Компасе, что в SW.

 

Уважаемый Old1, я не совсем понимаю, что такое devtype. Вот спецификация IDF 3.0. Там есть раздел 3.12, в котором, собственно, и написано, что описание размещения компонента состоит из двух строк, первая из которых дает общее описание компонента, а вторая - собственно размещение. Общее описание состоит из трех полей - Package name, Part number и Reference designator. Package name - это реально имя футпринта, Reference - это позиционное обозначение в схеме. ДЛя описательной части остается только part number, сопоставление которого каким-то реальным свойствам компонентов в схеме или проекте ПП и есть загадка для меня. Вот что тогда такое devtype? Откуда он берется и как попадает в IDF, где настраивается?

 

 

Нужно помнить, что этот редактор для OrCAD чужой, поэтому здесь с полями текстовыми может быть нестыковка. Вообще PCB Editor по умолчанию берет в IDF поле PART NUMBER, но для интереса посмотрите что записано в этом поле в редакторе OrCAD Capture...

Так я вот написал, что получил в итоге в IDF вообще какие-то C-SMALL, а это было свойство source package в исходной схеме. Правда, справедливости ради надо сказать, что этот IDF был получен не из родного проекта PCB Editor, а был предварительно переведен из проекта layout с помощью транслятора. Может, это транслятор так насолил? Запузырил в dev type всякую ерунду, и теперь она в IDF.

 

 

Да, и вот еще добавление. Реальный Part Number - это такая замысловатая штука может быть, что сразу и не сообразишь. Например, вот у какой-нибудь MURATA есть конденсатор 0603 X7R 0.1мкФ 25В, так он будет выглядеть как-нибудь так: GRM188R71E104KA01. Попробуй тут догадаться, что это такое, глядя на это в дереве модели. Пока все эти грабли обойдешь и поймешь, как правильно надо было свойства компонентов заполнять, чтобы удобно работалось, уже столько проектов сделается неправильно... Было бы здорово как-нибудь научить его на лету заполнять IDF из каких-нибудь правильных полей.

[inter_pro 0]

Так я вот написал, что получил в итоге в IDF вообще какие-то C-SMALL, а это было свойство source package в исходной схеме. Правда, справедливости ради надо сказать, что этот IDF был получен не из родного проекта PCB Editor, а был предварительно переведен из проекта layout с помощью транслятора. Может, это транслятор так насолил? Запузырил в dev type всякую ерунду, и теперь она в IDF.

я так понял, вопрос закрыт?

для интереса, раз уж этот проект еще и импортирован был, что показано в поле PART NUMBER в редакторе Capture?

 

Было бы здорово как-нибудь научить его на лету заполнять IDF из каких-нибудь правильных полей.

так не бывает! лучше научиться правильно заполнять соответствующие поля свойств элемента!

 

Обычно делаем два поля

Part Number = 0603 X7R 0.1мкФ 25В

Manufacture Part Number = GRM188R71E104KA01

причем первый делается в БД, путем сложения соответствующих полей

[vpd 0]

я так понял, вопрос закрыт?

Как же закрыт, только-только открыт :-)

 

для интереса, раз уж этот проект еще и импортирован был, что показано в поле PART NUMBER в редакторе Capture?

Вот весь список свойств из capture, извините, что несколько длинно выглядит, но я выделил главное, как мне думается.

COMPFIXED NO

COMPGROUP 0

COMPHEIGHT 0.000

COMPKEY NO

COMPLOC [1025.000,855.000]

COMPLOCKED NO

COMPROT 90

COMPSIDE BOT

DECOUPLER NO

Designator

FPLIST

Graphic C-small.Normal

ID

Implementation

Implementation Path

Implementation Type <none>

Location X-Coordinate 340

Location Y-Coordinate 250

Manufacturer MURATA

MEMORY NO

Name I151896

Package 0603

Part Number GRM188R71H103KA01

Part Reference C24

PCB Footprint SMC0603

Power Pins Visible 0

Primitive DEFAULT

Reference C24

Source Library C:\WORKS\ORCAD\PROJECTS\MORS5\ELEMENTS.OLB

Source Package C-small

Source Part C-small.Normal

Tolerance 10%

Value 0.01uF

 

так не бывает! лучше научиться правильно заполнять соответствующие поля свойств элемента!

 

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

 

Во-вторых, должен сказать, что Capture в поставочном варианте вообще не передает в нетлист (формата MNL) свойство Part Number. Его для этого надо как-то в дебрях ini описать, да еще и пробел на _ заменить. Так что я и говорю, что пока научишься все правильно делать, успеешь несколько проектов сделать неправильно.

 

В сухом остатке: меня вполне бы устроила возможность вывода в IDF значения свойства Value, благо оно видно в PCB Editor'e само.

Изменено 29 июля, 2010 пользователем Hoodwin

[inter_pro 0]

Запузырил в dev type всякую ерунду, и теперь она в IDF.

В проектах, сделанных в OrCAD, в поле dev type содержится нечто похожее на правильный Part Number, и там в частности есть Value, обычно так все и делают...

[Old1 0]

Уважаемый Old1, я не совсем понимаю, что такое devtype. Вот спецификация IDF 3.0. Там есть раздел 3.12, в котором, собственно, и написано, что описание размещения компонента состоит из двух строк, первая из которых дает общее описание компонента, а вторая - собственно размещение. Общее описание состоит из трех полей - Package name, Part number и Reference designator. Package name - это реально имя футпринта, Reference - это позиционное обозначение в схеме. ДЛя описательной части остается только part number, сопоставление которого каким-то реальным свойствам компонентов в схеме или проекте ПП и есть загадка для меня. Вот что тогда такое devtype? Откуда он берется и как попадает в IDF, где настраивается?

Попытаюсь прояснить этот вопрос.

В Качестве Part Number Pcb Editor (при экспорте IDF) подставляет свойство Device type. Device type заполняется при импорте нетлиста из Capture: в Device type записывается значение свойства Part_name. Part_name в свою очередь принимает значение свойства DEVICE, если оно назначено элементу на схеме, если не назначено, то Part_name будет состоять из комбинации значений свойств Source Package, PCB Footprint и свойств перечисленных разделе [ComponentDefinitionProps] файла Allegro.cfg, разделенных знаком подчеркивание, кроме того длина полученной строки ограничена 31 символом. Иными словами если в Capture у компонента на схеме свойство DEVICE чистое, то оно будет заменено строкой в виде комбинации значений свойств Part_name_PCB Footprint_Value_..., далее эта строка через нетлист попадет в PCB Editor-e в свойство Device Type, оттуда при экспорте IDF в свойство Part Number. Если же у компонента на схеме свойство DEVICE будет иметь значение, например, 10uF, то в конечном итоге при экспорте IDF оно попадет в Part Number и далее в сборку в мех. кад... Может быть объяснение несколько сбивчивое, но увы, ограничен во времени...

[vpd 0]

Да в общем то все понятно. Я так понимаю, что свойство DEVICE не имеет отношения к программе LAYOUT, а следовательно при трансляции проекта из файла MAX мы не получим правильно заполненные device type. И как следствие, не будет нормального IDF. Поскольку пока что еще не пробовал целиком проект с нуля сделать в PCB Editor, то и не знал про эти Device type.

 

Пользуясь случаем хочу уточнить смысл Device Type. Какова семантика этого поля? Где оно применяется и что в нем принято писать, если иметь ввиду, скажем, оформление конструкторской документации по ЕСКД?

 

И еще вопрос. Каков механизм перевода проекта с layout на PCB Editor, чтобы получить полноценные IDF? Через транслятор, как видно, выходит не очень. Нужно как-то после трансляции делать из PCB Editor back annotation, потом в схеме заполнять все свойства allegro, типа device, затем снова делать ECO в PCB Editor и уже после этого повторно создавать IDF? или проще можно?

[Old1 0]

...

Пользуясь случаем хочу уточнить смысл Device Type. Какова семантика этого поля? Где оно применяется и что в нем принято писать, если иметь ввиду, скажем, оформление конструкторской документации по ЕСКД?

Сложно ответить, что-либо определенное. Аллегро в состоянии поставки под ЕСКД вообще не заточен, особенно PCB Editor. Я в документации информацию из Device Type вообще не использую, но само свойство (заполненое по умолчанию) использую,например, когда на плате надо подсветить все однотипные компоненты, например, все резисторы 0603 номиналом 10кОм и разбросом 5%...

 

И еще вопрос. Каков механизм перевода проекта с layout на PCB Editor, чтобы получить полноценные IDF? Через транслятор, как видно, выходит не очень. Нужно как-то после трансляции делать из PCB Editor back annotation, потом в схеме заполнять все свойства allegro, типа device, затем снова делать ECO в PCB Editor и уже после этого повторно создавать IDF? или проще можно?

Если Вас волнуют только свойства передаваемые в IDF-файлы, то можно. Задача сводится к тому чтобы редактировать значение свойства Device type. Когда-то я это делал (чисто в познавательских целях). Напрямую через редактирование свойств это сделать нельзя. Нужно:

-сделать экспорт библиотек из проекта ( device-файлы);

-отредактировать эти device-файлы, вспоминаю,что достаточно изменить имя device-файла;

-подсунуть компоненту (компонентам) новый device-файл через команду partlogic.

IDF таким образом Вы получите, но чем это чревато в дальнейшем я предвидеть не берусь. На мой взгляд правильнее сделать так, как Вы написали. Это будет не в пример дольше, но появятся нормальные возможности для редактирования топологии платы, так как PCB Editor заточен " под нетлист" , т. е. все изменения прямые и обратные осуществляются через нетлист. Без нетлиста теоретически можно, но это уже ИМХО кустарщина...

[vpd 0]

Не прошло и полгода как у меня вроде даже получилось сделать приличный IDF.

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