уважаемые гуру Cadence.
интересует вопрос о взаимодействии продуктов Cadence с механическими САПРами.
интересует сам процесс, кто что использует, насколько удобен процесс.
я так понимаю, что основная масса остановилась на связке с IDF файлами.
у ментор есть решения свои, но это ментор.
у нас в данный момент стоит вопрос выбора САПРа для электронщиков и один из вопросов это взаимосвязь с механическим САПРом.
со стороны механики ProE и меняться уже не будет.

может быть есть какие то сторонние производители? слышал про NEXTRA от MECADTRON, но пока не совсем разобрался как это взаимодействует.

спасибо.

Не совсем понял, что фиксировано, а что нужно варьировать.

Лично я использую КОМПАС-3D. Купил у АСКОНа библиотеку конвертации IDF в модели, но потом разочаровался в ней, взял SDK и написал свой конвертер. Строит модели собранной платы за пару десятков секунд. Пример такой сборки я выкладывал в соседней теме.

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

фиксирован MCAD это ProE.
имеется в виду сам процесс толкания некоего файла (файлов) между САПРами механическим и электронным в плане контура платы, расстановки разъемов и прочих критичных компонентов. насколько я понимаю большинство остановилось на idf формате. у ментора появился некий новый формат и поддерживается (idx формат).

появление нового формата файлов обмена между механикой и электроникой и поддержка этого формата ментором (ну они как бы сами его и разработали с ProE-шниками) в данный момент перевешивает весы выбора САПРа в сторону ментора. хочется понять как взаимодействуют разработчики электроники под Cadence-ом с конструкторами механики. вот.
(просто мы то сами под PCad-ом остановились на IDF, но хочется узнать про новые тенденции).

Ну если главный критерий выбора САПР проектирования ПП это используемый интерфейс обмена с механиками - даже не знаю, что сказать... Т.е. что там позволяет САПР внутри по организации библиотек, ведению проекта, составлению схемы, плэйсменту/трассировке и выводу в файлы для завода(напоминаю - это ГЛАВНОЕ его предназначение) - это все не критично? Браво! Таких аргументов давно не слышал

1. А чем плох стандартный IDF?
2. Что такого придумал ментор, чего нельзя достичь при помощи IDF?
3. Принимается ли в рассмотрение такой аргумент, что софт для проектирования вообще стоит денег, и это отражается на выборе?

И какие вообще задачи решать предлагается с помощью механической САПР?

У меня пока были задачи компоновки платы (разъемов) с учетом внешнего корпуса, например, как разместить разъем-розетку RJ-45 промышленного Ethernet на плате, если вилка фиксируется не сама по себе, а вмонтирована в герметичный кожух разъема, который надевается на монтажную раму на стенке прибора. При этом размещение платы внутри корпуса может варьироваться, и это приводит к изменению свеса розетки с каая платы, так как корпус литой и стенка имеет небольшой уклон в 2 градуса по отношению к основанию. Механический САПР позволяет все это сначала отмоделировать, а затем уже получить конкретные данные о размещении разъема на плате, а ставлю я его вручную, указывая координаты x и y, а потом - fix.

Ничем не плох IDF. Более того, это единственный способ двусторонней связи MCAD<->ECAD. Все остальное (собственная генерация STEP представления платы и т.п.) это от лукавого. Смотреть 3D модели плат в ECAD бессмысленное занятие.

2 Hoodwin - нет смысла расставлять компоненты указывая вручную их координаты, если ваш ECAD может импортировать IDF обратно, после размещения компонентов в MCAD. В моем случае связка PADS <-> ProE|Solidworks работает безукоризненно, причем в ProE у механиков имеется уже база нормальных 3D моделей большинства компонентов - можно и презентации делать (особенно красиво смотрится когда еще и cabling сделан).

не надо утрировать. нигде этого не было написано в моем посте. в данный момент как раз ведется исследование обоих САПРов cadence и mentor graphics. лично мне симпатизирует именно cadence из за capture CIS потому как ну очень мощно реализована работа с базами данных. но встал такой вопрос, если cadence поддерживает ТОЛЬКО IDF, от будем пробовать ТОЛЬКО IDF для взаимодействия с MCAD. я в Cadence новичок, поэтому и спросил у гуру, возможно у кого то есть реальный опыт толкания некоего формата (idf, ..., ...,) между ECAD САПР и MCAD САПР вопрос только в этом.


формат IDF проталкивает ВЕСЬ проект и механики или электроники и он НЕ ПЛОХ.
в данный момент у МЕНТОРА разработан механизм взаимодействия несколько иной, там передаются через внешний модуль только изменения (изначально передается таки idf файл) и эти изменения обрабатываются как события, которые конструктор ECAD ну или MCAD может принять или отклонить. это очень существенная разница. я не говорю лучше это или хуже простого обмена idf файлами, я просто спрашиваю у кого какой опыт. есть вот такой опыт у Cadence (нашел на сайте презентацию)и вот такой опыт у mentora
на мой взгляд конечно проблема немного надуманная, но если представить себе что работают несколько человек над одним проектом изделия (например два механических инженера и один от электроники) то как согласовать изменения со стороны механики и электроники? если люди занимаются этим, то наверное такая проблема есть (хотя за деньги можно таких проблем навыдумывать).
и кстати презентации что у кадэнс что у ментора примерно в одно и тоже время были.

Попробовал применить его для отправки конструктору, чтобы он оформил сборочник на модуль.
Оказывается, там не передаются позиционные обозначения.
Как быть, есть ли такой формат? Или плохо смотрел?

Кто-то Вас обманул... Вот смотрите, построенная модель через IDF. Я при вставке сделал именование компонента по форме %refdes: %value. Как видите, вполне все читаемо. В принципе, в компасе реально с компонентами и объекты спецификации связывать, тогда можно в полученной модели "исключить из расчета" некоторые детали (видуально), и автоматически получить корректную спецификацию.

Тааак! Спасибо, разберемся.
Скажите, а можно ли в полученной модели автоматически красиво расположить рефдесы, чтобы потом сделать сборочник?

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

Вообще модель - сугубо 3D-шная сущность. Можно потом делать на чертеже ее различные виды и делать обычные выноски. Можно автоматизировать это процесс через SDK, я думаю, но не уверен, что это будет красиво смотреться. Я обычно делаю сборочник в 2D, и рефдесы пишу внутри контура корпуса. Правда это иногда требует увеличения для их прочтения.

Спасибо. А можете объяснить по-быстрому, как надо создавать из этой полученной из IDF модели двумерный сборочник? Видимо, там надо включить вид сверху и начать двигать текст, если надо, да? Сам текст исходно отображается рядом с компонентами? На Вашем скриншоте этого не видно... Просто наш конструктор говорит, что не знает (?), а мне компас ставить некогда, да и не зачем по-большому счету.

Ну создавать то его просто: создать 2D-документ - чертеж, да построить на нем вид платы, сверху или снизу. Но на этом лафа закончится. Тексты придется писать вручную на этом виде. Они конечно будут привязаны к системе координат вида и при смещении вида будут сдвигаться вместе с ним, но придется вручную все подписывать. По ЕСКД так нужно делать выноски и потом в спецификации прописывать, что есть что. Как вариант, можно попробовать всосать обозначения из DXF, полученного из гербера. Кстати, вот, попробовал на именно этой плате. Взял специально тот фрагмент, на который в предыдущей картинке стрелка показывала. Как видно, синие толстые линии - это основные линии (по ГОСТ), обозначающие контуры деталей, а тонкие черные (и из ниж же надписи) - это наложенный DXF, полученный из гербера. В данном случае у меня гербер был сборочный, потому там контура тоже есть, и они немного с моделями расходятся. Но их, конечно, можно убрать и сделать именно слой только с обозначениями, которые наложить на проекционный вид. И вдобавок, можно будет на виде выноски рисовать со ссылками на спецификацию, для всяких прочих деталей, которые не маркируются позиционным обозначением.

Ну вот, а так все хорошо начиналось...
Вопрос: почему подписывать надо вручную? Вы же показали первый скриншот, на котором выделен компонент слева в списке, и он же подвечен в 3D. Т.е. связь есть. Нету самого текста, что ли? Наверно, это имелось ввиду, когда мне первый раз сказали, что нет рефдесов...


Не думаю, что это хороший вариант. Привязки-то в нем не будет (текста рефдесов к контурам компонентов).

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

а если не секрет, чем плохо сделать простой сборочник в PCB Editor'е? там не хватает функционала? или просто это будет конструктор-механик? слоев для сборки (ASSY, и прочих) там море.


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

Так Вы попробуйте оформить его по ЕСКД? Ну хотя бы просто вставить в форматку и подписать. И тут выяснится, что PCB Editor не умеет писать ГОСТовскими шрифтами, не знает русского языка, не умеет скрывать немонтируемые компоненты (у меня, например, почти в каждом изделии найдется набор деталей, который ставить не нужно; точнее таких наборов много, и они зависят от спецификации). Кроме того, при такой схеме разработки спецификацию на изделие приходится делать, например, через BOM, полученный из схемного редактора, и возникает задача синхронизации сборочного чертежа и спецификации.

Когда я делаю 3D модель, то могу (в КОМПАС-3D) автоматом сделать по ней спецификацию, поскольку каждый объект модели может иметь ассоциированные с ним объекты спецификации (как простой классической спецификации, так и ведомости покупных и перечня элементов). И вот, если в конкретном исполнении что-то на плату не ставится, то я нахожу в 3D модели этот компонент, исключаю его из расчета, и это автоматически ведет к устранению из всех спецификаций записей про этот компонент. Таким образом, удается свести задачу построения взаимоувязанных документов КД к исправлению всего одного основного документа - 3D-модели, с минимальным риском где-то чего-то недоглядеть.

Конечно, можно взять PCB Editor и правильно настроить сборочные виды в нем, потом экспортировать их в DXF, потом импортировать это в какой-нибудь механический CAD, поддерживающий форматы оформления ЕСКД и русские шрифты. Но тогда:
1. Любое отклонение от 2D будет уже сложной задачей. Например, вид сбоку или изометрический вид, необходимый для правильного монтажа выводных компонентов. Придется это выносить в другой документ, лишь увеличивая число сущностей, за которыми надо уследить при обновлениях.
2. Синхронизация сборочного вида и спецификации становится муторной задачей: вручную удалять из спецификаций строчки, или править количество однотипных деталей в ведомости покупных; вручную удалять графическое изображение компонентов и их рефдесов на сборочном чертеже. Все это чревато ошибками или трудоемко.

В Soilid Works можно сделать сборочник с позиционными обозначениями (ПО) почти автоиатически. ПО добавляются к электрическим компонентам в 3D-сборке как примечания, одним нажатием кнопки. На плоском чертеже ПО тоже можно добавить в одно нажатие (Авто-позиция). Но есть и неудобства: по умолчанию ПО добавляются с линией выноски, потом их приходится в ручную двигать и отключать линии выноски... Правда ИМХО если нужна монтажная схема для монтажников, то быстрее ее сделать средствами PCB Editora...

И то, и другое. В аллегро нет русских букв. Да и потом, есть спец. человек.


Это понятно, просто этот формат мне видится чуть ли не единственным средством нормального (двустороннего) обмена. DXF использовали всю жизнь, но напрягает, что там все раздроблено, нет компонентов и прочих объектов уровня платы, есть только графика.
Поэтому пытаюсь на основе него наладить общение, добавить возможностей, если получится.


Скажите, речь о модели, построенной на основе IDF? И какую конкретно кнопку нажимать?

плюсую, так как это причины реальные.

мы в данный момент практикуем именно обмен данными по IDF, причем инициатор именно механик, потому что ему потом генерить модели сборок (не сборочных чертежей) и стыковать это безобразие в изделие.


что касается оформления по ЕСКД, то поковырявшись последнее время понял, что мы (отечественные разработчики) находимся в "тисках", разрабатываем изделия по стандартам импортным, в импортных САПРах, для того чтобы произвести изделие на импортном оборудовании, НО чтобы в электронно-печатном виде это было по ГОСТу. вообще караул...надо поднимать наши отечественные стандарты до уровня современных или адаптировать их под современные реалии (типа лозунг).

Да

Кнопок будет несколько...
Кратко порядок действий такой:
-в Аллегро генерим IDF;
-в Solid Works запускаем его аддон CircuitWorks и втаскиваем в CircuitWorks IDF;
-в CircuitWorks запускаем построение модели, в результате в Solid Works появляется 3D-сборка электронного блока;
-в Solid Works запускаем команду CircuitWorks->Добавить примечания в компоненты, в настройках в качестве первичного примечания выбираем Позиционное обозначение и жмем добавить; после этого на 3D-сборке появятся позиционные обозначения;
-по 3D-сборке делаем чертеж с нужным количеством видов
-выбираем нужный вид и выполняем Вставка->Примечания->Авто-позиция, в настройках позиции выбираем Ссылка компонента, на чертеже появятся позиционные обозначения на выносках, завержаем операцию;
-двигаем позиционные обозначения как нравится;
-выделяем все выноски с позиционными обозначеними и в свойствах отключаем выноски.

Old1

1. А скажите, я правильно понимаю, что эти функции входят в Solid как некое дополнение-расширение-опция? Отдельно оплачиваемая при заказе. Если сравнивать с КОМПАС, то сделать каждому объекту атрибуты с ПО - нет проблем. Проблема в том, чего хочет vitan - встроить этот текст прямо в 3D модель, так чтобы при построении вида он туда попадал. Я пока не очень представляю как это сделать. Вот я похожим занимаюсь, когда надписи на передние панели делаю, но там приходится честно делать выдавливание текста на поверхности, и он естественно на все виды попадает. Сделать эскиз, который бы попадал прямо в вид, я пока не знаю как.
2. Естественно, чисто монтажная 2D-схема может быть и в PCB Editor сделана, но вот хотя бы рамку с основной надписью к ней сделать было бы правильно. Это дисциплинирует и конструкторов, и исполнителей.


lazarev andrey
Как говорится: самое замечательное в стандартах - это богатство из выбора.
Я в общем, не вижу такой уж большой несовместимости, все упирается в трудоемкость и производительность труда. Думаю, что любой инженер, поставленный перед прайсом на софт и ознакомленный с его возможностями, сделает правильный выбор. В любом случае, я бы не стал хаять отечественный софт, и отечественную систему КД - в ней есть много хорошего, если этим умело пользоваться. К счастью, компьютеры позволили людям гораздо меньше заморачиваться над формой и больше думать над содержанием своего проекта.

Old1
Спасибо за инструкцию. А остальную КД Вы тоже в солиде делаете? По ЕСКД?


Я не то чтобы хочу, просто думаю, каким образом реализовать подписывание. Вы не сказали, Вы в компасе это делаете вручную? Почему?

Ну, скажем так. На монтажное производство я пока отдавал только гербер со сборочным слоем. Они его печатали в масштабе, достаточном для читаемости ПО и номиналов (у меня на сборочнике номиналы тоже отображаются). Пока что они особо не возмущались отсутствием штампа, скорее наоборот, там и так простыня большая, чтобы текст в 0402 читался. Когда же я делал сборочные чертежи в компасе со штампами, то на них печатная плата входила как единый сборочный узел, поэтому я там никакие выноски про отдельные компоненты уже не рисовал, а ссылался на плату целиком как элемент спецификации. При таком подходе плата как сборка - это 2Д объект, которому, как правило нужны только сборочные виды сверху и снизу, а их несложно получить и в PCB Editor.

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

2 Hoodwin

На 100% не ручаюсь, но помоему, начиная с версии Солида 2009, CircuitWorks входит в стандартный комплект поставки...

С рамкой никаких проблем, под нее в Аллегро, даже специальный класс создан Drowing Format, проблема есть с русским языком, но в моем понимании тоже решаемая, давно руки чешутся написать скрипт на skill который бы конвертировал русский текст в графику, да все руки не доходят... ну а для кого русский язык и соответствие ГОСТ-ам не принципиально, то вообще никаких проблем.

Нет, солид я использую когда нужно привязать электронику к корпусу, ну или клиентам 3D-модель девайса в боевой раскраске показать, им это нравится...

Я никак не пойму, Вы рефдесы в компасе вручную расставляете или автоматом, как Old1 в солиде?


Механической ипостастью этой проблемы я только планирую заняться. Но электрическая отработана следующим образом.
В схематике создаются варианты (у меня ментор, но оркад и концепт это тоже поддерживают). Потом генерятся отдельные бомы для каждого исполнения. В базовом исполнении уже может не быть к-л деталей, или они уже могут быть заменены на аналоги. Эти несколько бомов отдаются конструктору, а он генерит спецификации и прочее (перечень генерю я, в моем случае групповой, т.к. мне лень делать несколько по исполнениям. Ну и схему тоже я, понятно). Пока что конструктор на сборочнике не удалял неустанавливаемые детальки. Но хотелось бы. Учитывая, что обмен будет в IDF (скорее всего), я вижу потребность передавать в IDF для каждой детали еще и вариант исполнения.
Наверно, тоже придется писать конвертер...
Я знаю, что аллегро может генерить виды по исполнениям автоматом, но вопрос, что с ними дальше делать? Опять в DXF? Не хочется...


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

vitan
1. Я же написал, что не ставлю рефдесы в компасе на сборочных чертежах. Ставлю некоторое количество крупно-агрегатных выносок в ручном режиме, а подробный сборочник оставляю в виде гербера.

2. Было бы интересно узнать, как в Capture делать варианты для генераций разных BOM. Я пока непосредственно в схеме исполнения ни разу не делал. даже хуже, просто вручную их делал, путем копирования файлов спецификаций.

3. Что касается исполнений, то у меня примерно такая картина сложилась, еже во времена интеграции Layout с Компас. Сначала делаем IDF и готовим модели компонентов. Потом экспортируем BOM из схемы. BOM заряжаем в небольшой редактор, который позволяет более менее цивильно просматривать его в разных исполнениях и редактировать. Поддерживает наследование свойств из базового исполнения, групповую замену по нескольким ячейкам и т.п., примерно так же как работают все spreadsheet редакторы в capture. Ну еще хорошо бы поддерживать ECO c оригинальным BOM, но это необязательно, так как по ГОСТу на схеме напрямую номиналы писать не принято. На выходе имеем более сложный формат BOM, пригодный для работы с построителем 3D модели. Если ему скормить полученный BOM и указать исполнение, которое мы хотим строить, то он сам автоматом строит модель и создает объекты для них спецификации всех необходимых типов: простой спецификации по ГОСТ 2.106, ведомости покупных и перечня элементов. Далее, можно по модели создавать сразу сборочный чертеж, а также подключать ее к документам-спецификациям, в результате чего будут получаться готовые спецификации всех типов, которым будет нужно только заполнить штамп и небольшое количество ручных объектов в разделах документации, стандартных изделий и т.п.

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

2 all
А есть ли у кого опыт работы с IDX в механическом CAD? Я пока не очень отчетливо представляю себе, как можно из 3D модели в компасе получить даже просто IDF. Ведь надо же как-то выбрать из просто 3D моделей большой сборки такие, которые являются на самом деле компонентами одной платы. Как в общем виде узнать:
1. Какая модель описывает саму плату и как выделить ее контур?
2. Где находятся детали, каковы их позиционные обозначения, какие символы им соответствуют в ECAD?
3. Какова связь локальной системы 3D-координат, в которых заданы модели деталей, с 2D системой координат футпринтов, являющихся проекцией этих моделей на поверхность платы? Без знания этого невозможно родить IDF. Мне довольно часто приходилось применять модели разъемов, которые я брал с сайтов из производителей. И практически всегда точка привязки и ориентация 3D подели не совпадают с точкой вставки и ориентацией 2D-футпринта.
4. Что изменилось на плате, после импорта последнего IDF?

В общем, пока что я просто строю сначала просто модель основных деталей (разъемов, радиаторов и т.п.) платы, и замеряю средствами MCAD их расположение относительно платы. Потом ставлю эти детали на плату и фиксирую, а уже потом начинаю все прочее ставить.

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


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



Не понятно, Вы не делаете 3d-модель для отдельных модулей, а сразу собираете все изделие, не подразделяя на модуль, корпус и т.п.? Если есть модель модуля, то можно просто открыть ее и экспортировать стандартным конвертором...

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




Что-то я не могу найти в хелпе, как работать с исполнениями во flat design'е. Имеется ввиду instances vs occurances или что-то иное? По идеем, должно быть так. Я открываю свойства всего проекта и говорю там, что у проекта есть несколько исполнений с разными именами. Далее, в каждом месте, где есть occurance, должны появится строки с именами исполнений и я там выбираю исполнение и настраиваю его свойства. А на самом деле все не так. Исполнения можно варьировать, когда я вставляю похожие схемы как иерархические блоки внутрь большой схемы. Но при этом с точки зрения корня иерархии - сборки всего прибора - это все одно исполнение.




Не, немного не так. Когда я проектирую сверху вниз, я часто начинаю все делать как одну сборку, потому что сразу не всегда ясно, какую иерархию сборок нужно создать. Например, радиатор надо отнести к плате (как сборке), поставить в сборке внутри корпуса, или вообще сделать отдельную сборку {плата (сборка) + радиатор (деталь)}, которая в свою очередь включается в сборку {блок в сборе}. Вот никогда заранее не угадаешь чего хочешь. А компас, как назло, не умеет передвигать компоненты между сборками по иерархии, не изменяя их пространственного расположения. Я спрашивал его техподдержку, они предложили мне удалять модель в одной сборке и вставлять заново в другую. И потом заново привязки все вручную настраивать.

Кроме того, у компаса нет стандартного конвертера 3D модели в IDF. Да его и не может быть без связи с ECAD, по причине №3 из моего предыдущего поста.

Понятно, но что Вы делаете, если надо совместить слои из аллегровских герберов (с рефдесами и контурами компонентов, как я понимаю) с механической частью сборочника из компаса? А если там получится налезание чего-нибудь на что-нибудь?


Тут я не скажу, оркадом последний раз пользовался несколько лет назад.


А тут я просто не понял.


Это нормально, не нормально только, что САПР этого не умеет. Я уже давно хочу отучить конструкторов от компаса, но они сопротивляются...


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

Смотрите в OrCAD CIS User Guide -> 6 Defining and Using Groups and Subgroups и в частности Creating BOM variants for your core design...

Ну, я не был бы столь категоричен. Если Вы хотите, чтобы у нас был хороший отечественный софт, то надо им пользоваться и развивать, в том числе и через активное сотрудничество с разработчиком. Компас-3D - хорошая программа. Примерно половину моих замечаний они приняли к исполнению, правда некоторые с временным лагов в два года Но! При этом у нас был конструктивный диалог! Когда я обращался в техподдержку Cadence, например про те же шрифты (русские, true type и т.п.), то в итоге имел только авторитетные заявления, что ничего такого аллегро не поддерживает, без вообще каких-либо намеков на когда будет. У америкосов мы вообще никакой поддержки не имеем. Практическим правилом является то, что общаешься с каким-то манагером, который нифига не понимает в теме, и, что еще хуже, не понимает, где в их фирме сидят те, которые понимают. Когда вы хотите уйти с компаса, Вы должны понимать, что если вы попадете в похожую ситуацию с буржуйским софтом, то скорее всего Вам вообще ничего не светит в плане помощи, что их сроки еще больше, чем у АСКОНа.



Мимо! Это совсем про другое стандарт. К IDF отношения не имеет.



Вот, вот, я нечто похожее испытал, когда взял этот конвертер Неделю с ним уродовался, потом месяц с ними переписывался, потом взял и свой написал.
На самом деле правда жизни совсем другая:
1. Конвертер дурацкий - но компас тут ни при чем. Конвертер - это add-on, который подключен через стандартный COM API к ядру компаса. Его писали другие люди и потом АСКОН взял это в распространение и поддержку.
2. На самом деле построение сборки из ~500 компонент занимает секунд 10-15 с настоящими 3D моделями. Ну, скриншот выше Вы видели. При повторном построении когда файлы в кэше, это и вовсе секунд 5. Так что я просто строю сборки заново, меняя IDF, если что-то хочу подвинуть или убрать.
3. После того, как я АСКОНу демонстрировал свой результат, они отказались его брать на вооружение, но обещали подтянуться. Судя по рекламе, вроде бы должны были, но я больше не пробовал, поскольку у меня теперь свой есть. Теперь я не завишу от их реакции на ошибки

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

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


Это я понимаю отлично. Только что мешает взять и самим создать такое отношение. Вы же ищете пути решения вопроса, вот один из вариантов.


Ни при чем? Ни при чем он был бы, если бы в нем не было этого конвертера, не так ли?


Ну так может уже и сам конвертер выложите?

vitan, вот скажите, Вы собственный труд (и его результаты) относите к категории отечественного или буржуйского? Меня всегда в подобного рода утверждениях смущает факт выборочного неуважения к чужому труду по территориально-национальному признаку. А самое главное, я не согласен с результатами подобных измышлений "от общего к частному" применительно конкретно к Компасу-3D. Вполне добротный продукт, который создан здесь с нуля и стабильно развивается, учитывая спрос со стороны российских инженеров. Конечно, в чем-то он отстает от других продуктов, но он и стоит других денег.

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



Вот в приведенном выше документе есть ссылки на стандарты IDF версия 2.0 и 3.0.
Обратите внимание на разницу в объектных моделях этих стандартов и IPC7351. Они про разное, да, собственно, и тема IDF и IDX еще далеко не исчерпана, чтобы что-то новое городить.
Что касается меня лично, то проблема MCAD-ECAD не стоит так остро, так как я сам проектирую и плату и механику вокруг нее. Поэтому у меня пока не было итераций MCAD-ECAD-MCAD-... Я сначала в MCAD прикидываю конструктив, после чего делаю в ECAD все и потом через IDF создаю уже полноценную модель всей платы, практически автоматически.



Могу только повторить, что тот конвертер - это внешнее приложение, подцепляющееся к ядру Компас через открытый API. Никоим образом одно в другое не интегрировано. Насколько я понимаю, конвертер написан исходно партнерами АСКОН, и взят на распространение в составе комплекса решений последнего. Да, к сожалению, конвертер не оправдал моих приборостроительных ожиданий, но это не повод хаять весь продукт.




1. Чувствую, что мы уклоняемся от темы автора в сторону конвертера allegro-Компас-3D. Если действительно есть интерес к этой тематике, то предлагаю создать отдельную тему, посвященную на ECAD-MCAD вообще, а конкретно
Allegro и Компас-3D. В этой теме пусть решает ее автор.
2. Не знаю, какова тут политика модератора, но полнофункциональный конвертер я готов предоставить на возмездной основе (хотя и не так дорого, как это делает АСКОН). Если общественность и модератор не против, то я могу выложить демонстрационный вариант, в котором количество компонентов IDF будет ограничено.

Добро?

Отечественного, ясно дело.


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



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




Зло.
И во сколько Вы оцениваете очередной шаг в развитии отечественного софта?

Ну вот сравните Xilinx ISE и Altera Quartus. Или почитайте соответствующую ветку на соседнем форуме. И наш Компас покажется Вам совсем в ином свете. Не надо делать детских обобщений, короче.

Я сказал, что с обратным преобразованием (MCAD-ECAD) мне не все до конца ясно. Чтобы это проделать, нужно иметь две согласованные библиотеки моделей: одну в MCAD, вторую - в ECAD. Согласованные - это такие, в которых начало кординат в 3D модели и ее ориентация соответствуют началу координат ориентации 2D-модели. Например, одни рисуют SOIC-8 в библиотеке с ножками в виде двух вертикальных рядов, другие - в виде двух горизонтальных. Одни делают начало координат любого компонента в центре его симметрии, другие - в центре симметрии КП первого пина. Например, вся стандартная библиотека OrCAD Layout создана по второй схеме, с центром первого пина. Пикантность в том, что в IDF выдается именно, точка вставки, а в файл pick and place - точка автопозиционирования, а они, скажем, у Layout указываются независимо, поэтому стандарт IPC тут не спасет. Для построения точных 3D моделей у каждого конструктора должны быть два согласованных набора, и простое копирование только 3D не спасет. Например, я в своей практике прошел несколько этапов в осознании требований к моделям футпринтов и моделям, и постоянно встречаются проекты, в которых можно встретить компоненты, оформленные в соответствии с модой очередного этапа. Поэтому мне частенько приходится делать локальные копии стандартных моделей и подгонять их под те футпринты, которые были использованы при создании конкретного проекта ECAD.

Потом, допустим, есть просто 3D модель. в ней есть печатная плата, которая может быть задана прямо как тело в сборке, но вот как ее там распознать? Как опознать ее контур, если конструктор может вообще не задать ее как пластину.

Компоненты. В схеме у них есть позиционные обозначения. Когда мы создаем MCAD модель, то они нам в общем-то неинтересны, могут стать атрибутами или просто частью имени компонента. Но вот при обратном преобразовании как они будут попадать в IDF с его позиционными обозначениями?

Очень часто конструкторы экономят и чип компоненты в корпусе 0603 имеют общую модель и для резисторов и для конденсаторов и для индуктивностей. И как при обратном преобразовании догадаться, кто есть кто в моделях ECAD?

Вы скажете: да это уже проблемы пользователя. Хочет делать качественное преобразование MCAD-ECAD, пускай каждому компоненту сделает уникальную модель. Правильно, но тут мы отчасти возвращаемся к той самой истории, почему у АСКОНа конвертер кривой. Вот я у них спрашивал: "кто ж это в вас додумался призмы корявые рисовать в моделях?" А они мне говорят, что модели у них заказала наша отечественная оборонка, и модели им - клиентам - строить было лень, а массо-габаритные характеристики - подай, поэтому и получился конвертер с призмами, от которого мы с Вами, как особые эстеты, плюемся. Дальше - круче. Клиенты осознали некузявость призм в отдельных случаях и попросили сделать их замену на модель, когда конструкторы в нашей оборонке, наконец разродятся, и сделают себе модель. Вот и имеем это странное решение, в точности в соответствии с образом мыслей заказчика...

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

для этого мы пошли по пути формирования документа - соглашение между механиком и электронщиком о точке привязки. да, IPC тут не помогает, можно опираться только.


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

АПД. а так я вот вообще очень рад, что начали затрагивать эти оченьнна важные вопросы проектирования

Ммм... Зачем их сравнивать, ведь они обе буржуйские? А обобщение, не детское, это Вы зря. Будете спорить, что Россия лучше живет, чем на Западе? Вот и не будем.


Ну так я же и говорю, что если библиотека будет по 7351, то все будет ок.


А что, там нельзя задать как в аллегро точку в процессе генерации файла? Если нельзя, то проблема, конечно, возникает, но это частный случай Layout, верно?


У меня то же самое. Но процесс сходящийся. Уже весьма близко в пределу.


Погодите, это Вы уже про обратную конвертацию в ECAD? Вы же говорили, что у компаса конвертера нет и не может быть (хотя есть, я проверил). Или Вы про ECAD->MCAD, чтобы возникло соответствие? Если да, то, наверно, это задается в том же стиле, что и соответствие моделей компонентов...


О, да. Я с этого и начал. Плюс, я еще думаю, что рефдесы в MCAD нужны, ну хотя бы для оформления сборочника (я считаю путь через гербера убогим и неправильным).
Передавать их имхо надо через юзеровские свойства, но я пока не знаток IDF, просто сразу бросилось в глаза.


Не вижу проблем. Каждый компонент имеет название, и, даже если модели одинаковые, то названия в ECAD разные почти всегда (ну кроме случая, когда и в ECAD все одинаково, но это уже изврат).

Так сколько, все-таки, хотите, не ответили?

Ну, честно сказать, с высотой мне не очень понятно, потому что это, на мой взгляд, достаточно просто, чтобы городить из-за этого взаимодействие MCAD-ECAD. Вот у меня стандартной задачей является построение модели вырезов в корпусе (передней панели) под разъемы, например в какой-нибудь 6U панели, которая имеет очень непростое расположение относительно платы. Конечно, механик может построить эти вырезы вручную, но будет зол и может долго копаться. А так он просто собирает сборку и в контексте сборки редактирует переднюю панель (стенку), проецируя на нее эскизы вырезов заданные в моделях разъемов. И уже на чертеже потом можно проставить размеры, совершенно не задумываясь о том, как пересчитать начало координат платы в начало координат панели, которая там имеет свес с платы во все стороны.

Или вот еще пример такой, см. рисунок. Делал как-то герметичный прибор, с двумя Ethernet портами. Штука в том, что корпус литой имеет уклон боковых стенок где-то 2-3 градуса, чтобы легко доставался из формы. Вилка RJ-45 ставится на плату, но должна быть расположена на определенной глубине относительно монтажной рамы 19, которая удерживает кожух кабельного разъема с сальником. так вот, вопрос на проработку был, на какой высоте от дна корпуса крепить плату? (Под нее должен был влезть еще ETX модуль и система его теплосъема на корпус). В зависимости от высоты установки платы (за счет втулки) меняется необходимый свес вилки RJ-45 с платы, поскольку корпус расширяется кверху. Построение такой модели до того, как я сел за плату, позволило правильно расставить все основные детали, хотя, как мне кажется, в задачке с отдельным механиком нужно садиться рядом и в четыре руки прорабатывать варианты.

vitan
Да дело не только в точке, но и в ориентации. Кроме того, представьте себе какой-нибудь сложный разъем современный. Вот вы его применили, потом хотите строить модель, и тут вы понимаете, что точно построить его - это на пол-дня работы, да еще и с образцов в руках. Тогда по принципу студента вы начинаете искать путь наименьшего сопротивления и, о чудо, находите его 3D-модель (или до боли похожую) на сайте производителя. Вы ее качаете и открываете. И тут выясняется, что конструкторам было пофиг на ваш ECAD, и они его нарисовали как хотели, начало координат вообще где-то в стороне от самой модели и ориентация явно не в пользу PCB. При этому модель смотрится как моноблок, и редактированию не поддается. И чего делать будем? Конечно, эту ситуацию тоже можно преодолеть, но IPC тут не поможет.

Да, я последние посты писал про обратную конвертацию MCAD->ECAD, так как для ECAD->MCAD для меня ничего непонятного уже нет Возможно, у АСКОНа и есть обратный конвертер, но что-то мне подсказывает, что он не лучше, чем тот первый. А непонятностей в нем гораздо больше. Я поэтому тут и рассуждаю вслух про него, потому что я пока не до конца понимаю прикладной его смысл. Я еще могу себе представить, что механик выдаст требование, сместить что-то куда-то на расстояние от Р1 до Р2. Но вот чтобы он Вам в IDF что-то сам двигал - это вообще как-то диковато выглядит. Ну разве что Вы с ним до трассировки будете перетягивать.

Вы не переживайте, я про ваш вопрос не забыл. Просто я вот определяюсь, создадим мы отдельную тему или нет. Если никому больше не интересно, то я Вам в личку отвечу.

ЕМНИП, она тоже в IPC задается.


Это почему? Что, даже ноль нельзя переместить? Что-то не верится...



О, да. Там, зачем-то надо указывать сторону расположения (top\bottom) для каждого (!) компонента. Это при том, что все они уже нарисованы в 3D компасовским же конвертером. Дальше этого диалога поти у меня терпения не хватило. А Вы чего-то защищаете еще...


Ну конечно! А что тут такого, он сам подвинул как надо, а потом уж отправляет разводчику, у того все автоматом выставляется. Так и должно быть. И наоборот, разводчик может подвинуть, и отдать на проверку. Главная трудность, как я понимаю, в том, что у компонентов в IDF мало свойств. Начали с рефедесов, но и остальное, конечно, не помешает.

Вообще, конечно, я задачу вижу в немного более общем плане. Мне хотелось бы найти такой механизм взаимодействия, при котором проект передавался бы полностью, со всеми возможными атрибутами в обе стороны. Я понимаю, что для этого нужен некий суперСАПР, которого нет. Точнее, нужен некий супер-формат, который мог бы хранить в себе все нужные свойства и значения для проекта, и быть исходным для ECAD и MCAD. Некоторое время назад интересовался этим вопросом, и пришел к выводу, что этот формат - STEP. Еще пришел к выводу, что реальное внедрение его и поддержка САПРами и PDMами (не берем альтиум и прочее) произойдет только в следующей жизни, и надо думать о чем-то своем. Но, возможно, уже ситуация изменилась.
Никто не знает, что у кейденса есть на эту тему?



Убедили, я передумал. Деньги - зло, я за свободную любовь.

Я ни разу не защищал тот конвертер...


Пусть более опытные коллеги меня поправят, но я пока не осознал насущной необходимости в таком супер-софте. Меня вполне удовлетворяет вариант, когда есть исходные ТЗ, работа ECAD-конструктора, просмотр этой работы MCAD-конструктором и, скажем, скриншоты с проблемными местами, с разъяснениями, что и куда двигать. Меня лично односторонний конвертер ECAD->MCAD, который строит мою модель за десяток секунд, устраивает. Если двигать надо непримиримо долго, то два конструктора сядут и будут на бумаге калякать, пока не придут к консенсусу, после которого много двигать уже будет не нужно.




Понятно. Что ж, берегите себя, нынче много всякой заразы...

У Вас, кстати, какая версия Компаса то стоит?

Ну, не знаю, я изначально не хочу просто быть в чем-то ограничен.
Вам как имеющему опыт с IDF, вопрос: что Вы думаете по поводу использования юзеровских свойств в IDF для передачи рефдесов? Или как Вы бы сделали это, если бы Вам это было надо?


Упаси, Боже! У меня никаких версий этой заразы нету.

Вы бы хоть внутрь какого-нибудь реального IDF заглянули хоть раз, или стандарт открыли, прежде чем такое спрашивать: http://www.simplifiedsolutionsinc.com/imag...df_v20_spec.pdf
Вот откройте страницу 16, переведите содержимое таблички record 2, и скажите мне, чего Вам еще там не хватает?

Я смотрел, не думайте. Однако, конвертер компаса, будь он не ладен, из этого делает одну текстовую строку. Понимаете? Не хватает создания объектов со свойствами. Создание объектов, имеющих названия в виде конкатенации всего, что нашлось в IDF, не устраивает.
Тут говорили про SolidWorks, вроде бы, там тоже самое, поправьте, кто знает?

а зачем для IDF передача многих атрибутов? он же и создан для совместной работы разводчика и механика и все.
в чем недоработка IDF (93 год вообще то), что у него нет истории процесса обмена информацией, а вот уже в IDX есть история запросов на изменение и статусы, типа принят, отклонен с комментариями, если я не ошибаюсь.

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

А почему именно не устраивает? По мне так это очень даже правильно. В компасе можно объектам назначать свойства (аттрибуты), только это делать довольно уморительно, и, кроме того, их глазами не видно в дереве сборки. Думаю, что нечто похожее и в SolidWorks. Вы потом замучаетесь выковыривать свойства в ручном режиме если потребуется. В общем, я не вижу этому применения. в IDF, собственно, ничего такого особенного нет, кроме refdes и part number, просто по стандарту. То, что Вы там иллюзии питаете насчет дополнительных свойств в стандарте 3.0, то вряд ли Allegro что-то экспортирует, во всяком случае я ничего такого не вижу пока. Да и честно сказать, список прописанных в стандарте свойств не такой уж густой:


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

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


Да уж. Хотелось бы попробовать, но компас (гы) даже в 2012 году этого не поддерживает...


Кхм. В этом случае он может разрулить только в приказном порядке (если не вникает), а это не наш метод. И причем здесь связи ECAD и MCAD вообще?

... еще у него нет высшего образования, и вообще он в прошлом директор мебельного магазина. И вот именно ему поручено разрулить какую-то спорную ситуацию между механиком и разводчиком...
Это - да! Это - по-нашему! Конечно, все дело в правильном софте...

Вернемся еще раз к тому, с чего начали. Конструктору надо сделать сборочник на модуль. Одна из операций - расстановка рефдесов. Сейчас у него нет иного выхода, кроме как открыть на одном мониторе (если есть еще) аллегро, на другом компас и, мотая головой, передвинуть 3000 рефдесов так, как надо.
Я себе вижу при переходе на правильное взаимодействие через IDF это так, что у него появляется трехмерная сборка, в которой у каждого кубика есть свойство, которое он может выставить куда надо примерно в том же стиле, как это происходит в аллегро при расстановке асембли или шелка. Чтобы было понятно, какое свойство относится к какому компоненту. Не обязательно должна возникать линия, указывающая связь, но сама связь должна быть, и она должна давать возможность быстро понять, что к чему и куда ставить.


Про солидворкс сказали, что там все немного попроще. Про компас верю на слово.



Согласен, это аргумент. Поэтому я сразу начал искать возможность использовать IDX. Но компас у конструкторов об этом и слыхом не слыхивал. А солид его понимает?

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




Тут компас и вовсе ни при чем. Компас - это система проектирования. А PLM система у АСКОН называется ЛОЦМАН - это отдельный продукт. Я тут про него вообще ничего писать не буду, пока не началось...

Хм, а куда надо? Ночей не сплю, все фантазирую, как бы поменьше да получше работать...

Неправда в чем?



Действительно, не надо про лоцмана. Это он как раз ни при чем, мы не обсуждаем ни хранение (хотя я про STEP упомянул мельком), ни жизненный цикл. А вот MCAD, коим компас, вроде бы, является, мы обсуждаем. Так что он очень при чем в этом смысле.