ECAD <-> MCAD, снова вопрос новичка в cadence Опции

[lazarev andrey]

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

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

спасибо.

[Hoodwin]

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

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

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

[lazarev andrey]

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

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

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

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

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

Сообщение отредактировал lazarev andrey - Feb 28 2011, 14:04

[Uree]

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

[Hoodwin]

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

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

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

[Nixon]

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

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

[lazarev andrey]

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

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

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

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

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



Сообщение отредактировал lazarev andrey - Mar 1 2011, 06:18

[vitan]

формат IDF проталкивает ВЕСЬ проект и механики или электроники

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

[Hoodwin]

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

Эскизы прикрепленных изображений

 

[vitan]

Кто-то Вас обманул...

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

[Hoodwin]

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

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

[vitan]

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

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

[Hoodwin]

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

Эскизы прикрепленных изображений

 

[vitan]

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

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

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

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

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

[lazarev andrey]

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

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


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

[Hoodwin]

а если не секрет, чем плохо сделать простой сборочник в PCB Editor'е? там не хватает функционала?

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

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

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

[Old1]

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


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

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

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

[vitan]

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

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

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

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

В Soilid Works можно сделать сборочник с позиционными обозначениями (ПО) почти автоиатически. ПО добавляются к электрическим компонентам в 3D-сборке как примечания, одним нажатием кнопки.

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

[lazarev andrey]

Правда ИМХО если нужна монтажная схема для монтажников, то быстрее ее сделать средствами PCB Editora...

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


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

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

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


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

[Old1]

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

Да

И какую конкретно кнопку нажимать?

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

[Hoodwin]

Old1

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


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

[vitan]

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

Если сравнивать с КОМПАС, то сделать каждому объекту атрибуты с ПО - нет проблем. Проблема в том, чего хочет vitan - встроить этот текст прямо в 3D модель, так чтобы при построении вида он туда попадал. Я пока не очень представляю как это сделать.

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

[Hoodwin]

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

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

Сообщение отредактировал Hoodwin - Feb 3 2012, 08:40

[Old1]

2 Hoodwin

А скажите, я правильно понимаю, что эти функции входят в Solid как некое дополнение-расширение-опция? Отдельно оплачиваемая при заказе.

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

2. Естественно, чисто монтажная 2D-схема может быть и в PCB Editor сделана, но вот хотя бы рамку с основной надписью к ней сделать было бы правильно. Это дисциплинирует и конструкторов, и исполнителей.

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

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

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

[vitan]

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

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

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

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

давно руки чешутся написать скрипт на skill который бы конвертировал русский текст в графику, да все руки не доходят...

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

[Hoodwin]

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 их расположение относительно платы. Потом ставлю эти детали на плату и фиксирую, а уже потом начинаю все прочее ставить.

[vitan]

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

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

Я пока непосредственно в схеме исполнения ни разу не делал. даже хуже, просто вручную их делал, путем копирования файлов спецификаций.

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

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

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

[Hoodwin]

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

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

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

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

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

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

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

Сообщение отредактировал Hoodwin - Feb 3 2012, 13:27

[vitan]

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

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

Что-то я не могу найти в хелпе, как работать с исполнениями во flat design'е. Имеется ввиду instances vs occurances или что-то иное?

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

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

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

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

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

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

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

[Old1]

...Что-то я не могу найти в хелпе, как работать с исполнениями во flat design'е. ...

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

[Hoodwin]

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

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

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

Интересно. В принципе, есть стандарт IPC7351, в котором прописано, что как должно быть ориентировано. Я бы при разработке ковертера ориентировался на него (чувствую, придется )

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

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

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

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

Код

; Протокол работы библиотеки импорта IDF
; от 03.02.2012, 18:29:00

I: Добавлен каталог библиотеки D:\Libs\KOMPAS\Models\Allegro\quad\_complist.cat
I: Добавлен каталог библиотеки D:\Libs\KOMPAS\Models\Allegro\soic\_complist.cat
I: Добавлен каталог библиотеки D:\Libs\KOMPAS\Models\Allegro\basic\_complist.cat
I: Прочитан основной IDF файл
I: Прочитан IDF файл библиотеки
I: Общее количество компонентов - 242
I: Компонент VT3 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент VT7 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент VT12 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент VT16 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент DD3 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент DD2 (SOIC-8) связян с моделью D:\Libs\KOMPAS\Models\Allegro\soic\SOIC8.m3d
I: Компонент NOREFDES (SIT) объявлен как немонтируемый
I: Компонент C22 (CAPV_D10_H11_P5) связян с моделью D:\User\vpd\SIT\TurnStile-RF\Model\Components\CAPV_D10_H19_P5.m3d
I: Компонент C21 (CAPV_D10_H11_P5) связян с моделью D:\User\vpd\SIT\TurnStile-RF\Model\Components\CAPV_D10_H19_P5.m3d
I: Компонент LS1 (LS_D12_H10XP7M6) связян с моделью D:\User\vpd\SIT\TurnStile-RF\Model\Components\LS_D12_H10.m3d
I: Компонент R20 (SMR0805) связян с моделью D:\Libs\KOMPAS\Models\Allegro\basic\SMR0805.m3d
I: Компонент R24 (SMR0805) связян с моделью D:\Libs\KOMPAS\Models\Allegro\basic\SMR0805.m3d
I: Компонент ZQ2 (QSMD_FT34A) связян с моделью D:\Libs\KOMPAS\Models\Allegro\basic\QSMD_FT34A.m3d
...
I: Компонент X2 (TB-09A) связян с моделью D:\User\vpd\SIT\TurnStile-RF\Model\Components\TB-09A.m3d
I: Компонент X1 (BH-14) связян с моделью D:\User\vpd\SIT\TurnStile-RF\Model\Components\BH-14.m3d

; Конец протокола

Сообщение отредактировал Hoodwin - Feb 3 2012, 14:28

Эскизы прикрепленных изображений

 

Прикрепленные файлы

 eCAD_converter_manual.pdf ( 327.37 килобайт ) Кол-во скачиваний: 569

 

[vitan]

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

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

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

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

1. Конвертер дурацкий - но компас тут ни при чем. Конвертер - это add-on, который подключен через стандартный COM API к ядру компаса. Его писали другие люди и потом АСКОН взял это в распространение и поддержку.

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

Вот я мануал от своего приложил, как это выглядит по процедуре.

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

[Hoodwin]

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

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 будет ограничено.

Добро?

Сообщение отредактировал Hoodwin - Feb 6 2012, 08:22

[vitan]

vitan, вот скажите, Вы собственный труд (и его результаты) относите к категории отечественного или буржуйского?

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

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

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

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

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

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

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

Добро?

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

[Hoodwin]

Ну вот сравните 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 такие пользователи продвинутые, что делают себе модели. Но я вот сомневаюсь, что это зависит от продукта, скорее, от культуры проектирования и наличия оплачиваемого рабочего времени на ее поддержание.

Сообщение отредактировал Hoodwin - Feb 6 2012, 09:30

[lazarev andrey]

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

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

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

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

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

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

[vitan]

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

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

Одни делают начало координат любого компонента в центре его симметрии, другие - в центре симметрии КП первого пина.

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

Пикантность в том, что в IDF выдается именно, точка вставки, а в файл pick and place - точка автопозиционирования, а они, скажем, у Layout указываются независимо, поэтому стандарт IPC тут не спасет.

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

постоянно встречаются проекты, в которых можно встретить компоненты, оформленные в соответствии с модой очередного этапа.

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

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

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

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

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

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

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

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

[Hoodwin]

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

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

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

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

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

Эскизы прикрепленных изображений

 

[vitan]

Да дело не только в точке, но и в ориентации.

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

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

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

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

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

Я еще могу себе представить, что механик выдаст требование, сместить что-то куда-то на расстояние от Р1 до Р2. Но вот чтобы он Вам в IDF что-то сам двигал - это вообще как-то диковато выглядит. Ну разве что Вы с ним до трассировки будете перетягивать.

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

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

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

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

[Hoodwin]

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

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

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

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

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

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

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

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

Сообщение отредактировал Hoodwin - Feb 6 2012, 11:40

[vitan]

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

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

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

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

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

[Hoodwin]

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

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

[vitan]

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

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

[lazarev andrey]

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

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

[Hoodwin]

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

Код

CAPACITANCE
RESISTANCE
TOLERANCE
POWER_OPR
POWER_MAX
THERM_COND
THETA_JB
THETA_JC
Other

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

[vitan]

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

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

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

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

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

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

[Hoodwin]

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

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

[vitan]

А почему именно не устраивает?

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

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

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

То, что Вы там иллюзии питаете насчет дополнительных свойств в стандарте 3.0, то вряд ли Allegro что-то экспортирует, во всяком случае я ничего такого не вижу пока. Да и честно сказать, список прописанных в стандарте свойств не такой уж густой:

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

[Hoodwin]

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

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

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

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

[vitan]

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

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

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

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

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

[Hoodwin]

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

Мы топчемся нова на месте. Еще в самом начале привели два варианта решения:
1. Сборочный вид платы полностью (с контурами платы, рефдесами и т.п.) оформляется в Аллегро, после чего экспортируется в MCAD, где есть форматка и прочие прелести оформления по ЕСКД.
2. Сборочный вид делается через построение вида 3D модели, а рефдесы экспортируются в DXF отдельно, только текст. Затем они импортируются и накладываются на проекцию, и править нужно небольшое число текста, который где-то на что-то наполз. Хотя такого не будет. Я Вам даже картинку для этого приводил выше. Все как в пустоту кануло.

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

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

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

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

Неправда в том, что Компас не поддерживает свойства. Все он поддерживает, просто в них нет никакой острой необходимости.

Вы как-то лихо перескочили с IDF на IDX. А откуда Вы будете его получать, позвольте спросить?

[vitan]

Все как в пустоту кануло.

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

Неправда в том, что Компас не поддерживает свойства. Все он поддерживает, просто в них нет никакой острой необходимости.

Я так не говорил. Я сказал, что конвертер их не создает. Хотя, для меня, как для юзера это одно и то же в конечном счете. Не помогает САПР, вот и все. Хотя должен бы.

Вы как-то лихо перескочили с IDF на IDX. А откуда Вы будете его получать, позвольте спросить?

Не поверите, из аллегро. Строчкой ниже в менюшке.

[Hoodwin]

так, оно еще только появилось в 16.5. У меня этого вообще пока нет. ИМХО, слишком сложно это пока для типовых случаев. Лучше отслеживать изменения в PLM системе.

[vitan]

так, оно еще только появилось в 16.5. У меня этого вообще пока нет. ИМХО, слишком сложно это пока для типовых случаев. Лучше отслеживать изменения в PLM системе.

Вот уж не знаю. Хотите сказать, что проще организовать в PLM (это еще если она есть) процессы итераций между разработчиками, чем просто передавать файлик туда-сюда, в котором хранится вся история? Очень сомневаюсь.
Некоторым по многу лет не удается наладить и процессы покрупнее, типа выпуска комплекта КД, не то, что там общение между отдельными разработчиками внутри конторы...
А если нету PLM, что делать?
Но я думаю об IDX в надежде, что там расширены возможности и нормальные MCADы его нормально поддерживают. Например, пресловутые рефдесы там нормально передаются (надеюсь). О процессе обмена и итерациях я могу пока не очень беспокоиться, ибо у меня и так пока все важные моменты этапы в жизни файлов под контролем CVS.

[Hoodwin]

ой, это глюк браузера

Сообщение отредактировал Hoodwin - Feb 6 2012, 14:36

[Hoodwin]

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

В принципе, наверное, на роль простой PLM может сгодиться и система контроля версий, которая поддерживает задания. Я вот использую с некоторых пор Perforce, там есть нечто такое, называются Jobs. Это когда менеджер может дать задание исполнителям, и их правки в дальнейшем идут в контексте этого задания и в конечном итоге завершают его с определенным статусом. Но все же perforce довольно дорогой и не дружит с ЕСКД. Ранние версии вообще и с кириллицей в именах файлов не дружат.

Сообщение отредактировал Hoodwin - Feb 6 2012, 14:38

[vitan]

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

Я, в принципе, не против такого решения, но это пока для меня недостижимо, к сожалению. Пока только MCAD-ECAD, и что-нибудь типа IDF, но обязательно с полным набором возможностей. По крайней мере компас отлетает сразу. Кстати, Вы видели как потом оформляется спецификация? Из bom-файла (бредятина, зачем он нужен?) импортируется строка с компонентами, указано количество и список рефдесов. Так вот, в спецификацию попадает название, количество, и всегда только один (первый) рефдес. Не по ГОСТу-с...

[Hoodwin]

1. Да я уже определился, у меня ЛОЦМАН стоит Осваиваю потихоньку. Мне он нужен, как замена электронного архива, который ранее был на perforce. Он не просто файлы хранит, он еще видит те метаданные, которые используются в ЕСКД (в штампах), умеет по ним искать, отчеты строить и т.п. Вот это мне хочется освоить, потому что выпиливать спецификации вручную занудно.

2. Как спецификация оформляется, я видел. Это косяк в ГОСТе Но в штатном конвертере не вполне удобно сделано. В принципе, можно настроить стиль спецификации, чтобы оно строчки объединяло, но проблема в том. что их нужно руками в мультистроку превращать, а то это нечитаемо.

[vitan]

1. Да я уже определился, у меня ЛОЦМАН стоит

Сочувствую. Подсадили Вас конкретно. Пробовал, смотрел, не понравилось, как и компас. Вот серч интермеховский другое дело. Ну да ладно.

2. Как спецификация оформляется, я видел. Это косяк в ГОСТе Но в штатном конвертере не вполне удобно сделано. В принципе, можно настроить стиль спецификации, чтобы оно строчки объединяло, но проблема в том. что их нужно руками в мультистроку превращать, а то это нечитаемо.

Как это косяк в ГОСТе? Все там правильно, если компонентов 150, то перечисляются все. И ничего, что много места занимает. А вот R1 в количестве 150 штук, вот это косяк. Причем косяк компаса.
Про объединение строк я не понял, у меня после загрузки бома все компоненты уже сгруппированы, несгруппированный бом просто не грузится. Т.е. шансов исправить никаких.

[Hoodwin]

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

В общем, в итоге я творчески переработал требования ГОСТ, и получилось вот нечто такое, что меня устраивает и производство тоже устраивает на все 100%. Спецификация стала удобным и самодостаточным документом, который наконец-то отразил требования и конструктора (обозначения, быстрый поиск в электронном виде), и производства (точное наименование, наличие свинца), и бухгалтерию (возможные аналоги).

Сообщение отредактировал Hoodwin - Feb 7 2012, 10:26

Эскизы прикрепленных изображений

 

[vitan]

Кнопок будет несколько...

Попробовал в действии. Результат превзошел все ожидания. Компас отдыхает, просто небо и земля.
Но все равно есть вопросы.

Скажите, а есть ли возможность расставить рефдесы в точности так, как это делает ciruitworks? Ведь при импорте они отлично вписываются внутрь компонентов, размер шрифта менять не надо, и двигать 3000 позиций тоже.

[Old1]

...
Скажите, а есть ли возможность расставить рефдесы в точности так, как это делает ciruitworks? Ведь при импорте они отлично вписываются внутрь компонентов, размер шрифта менять не надо, и двигать 3000 позиций тоже.

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

[vitan]

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

Ура, нашел!
Надо все сделать как по инструкции, т.е. создать примечания в circuitworks, потом создать чертеж из модели, а потом вставить в него рефдесы, но не с помошью автопозиции, а командой вставка-элементы модели. Там в фильтре выбратьпимпочку с буквой "А" (Заметки) в группе "Примечания", выбрать вид, на который будет добавляться (иначе добавится везде, даже на видах сбоку) и выполнить операцию. Потом можно выделить все и оптом поменять размер шрифта, раположение надписей будет повторять его в circuiworks.
Останется только немного подвигать в местах, где не нравится, но это уже не сравнить с геморроем по ручному двиганию в аллегро и компасе, конечно.
Old1, спасибо, что подвигли меня на это дело, все никак не собраться было. Теперь начну осваивать новую область (MCAD).

[Old1]

Ура, нашел!
Надо все сделать как по инструкции, т.е. создать примечания в circuitworks, потом создать чертеж из модели, а потом вставить в него рефдесы, но не с помошью автопозиции, а командой вставка-элементы модели. Там в фильтре выбратьпимпочку с буквой "А" (Заметки) в группе "Примечания", выбрать вид, на который будет добавляться (иначе добавится везде, даже на видах сбоку) и выполнить операцию. Потом можно выделить все и оптом поменять размер шрифта, раположение надписей будет повторять его в circuiworks.
Останется только немного подвигать в местах, где не нравится, но это уже не сравнить с геморроем по ручному двиганию в аллегро и компасе, конечно.
Old1, спасибо, что подвигли меня на это дело, все никак не собраться было. Теперь начну осваивать новую область (MCAD).

vitan, и Вам спасибо, теперь процедура создания монтажных схем и рисунков в SW стала выглядеть более гармонично. Кстати в SW 2012 появилась возможность работы с форматом idx, который недавно упоминался в этой теме. Попытался даже сделать двусторонний обмен данныими ECAD->MCAD->ECAD через idx, но все закончилось падением allegro 16.5s014 при импорте idx на последней стадии... вот такие дела.

[vitan]

Кстати в SW 2012 появилась возможность работы с форматом idx, который недавно упоминался в этой теме. Попытался даже сделать двусторонний обмен данныими ECAD->MCAD->ECAD через idx, но все закончилось падением allegro 16.5s014 при импорте idx на последней стадии... вот такие дела.

Я пока не пробовал в аллегро, но из него в солид все работает, причем даже быстрее, чем с IDF.

[Hoodwin]

А картинки то будут, на что это похоже?

[vitan]

А картинки то будут, на что это похоже?

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

[Hoodwin]

Да ладно, я не требую картинку со 100% настоящих моделей, мне интересно как это делает SW, а у меня его нет. 3 или 4 страницы исписали про выбор MCAD, и в итоге даже не видно, на что похож результат.

Попытался даже сделать двусторонний обмен данныими ECAD->MCAD->ECAD через idx, но все закончилось падением allegro 16.5s014 при импорте idx на последней стадии... вот такие дела.

Old1, а у меня вот какой вопрос, Вы целиком готовый проект так прогоняли, или только начальную стадию, когда расстановка критичных деталей есть, а разводки еще нет?
реально ли начать проект в MCAD, нарисовав в нем с нуля плату и вставив некоторые компоненты? ну, например, так:
1. рисуем контур платы, выдавливаем на заданную толщину.
2. Добавляем модели разъемов, охлаждаемых компонентов и т.п., настраиваем им refdes, имена футпринтов (?)
3. Добавляем модели радиаторов/крепежа, делаем их привязку к охлаждаемым компонентам.
4. Сохраняем сборку, вставляем ее в сборку изделия в корпусе
5. В большой сборке выстраиваем привязки разъемов платы к стенкам корпуса, привязки радиаторов к стенкам/вентиляторам/термотрубкам и т.п., после чего компоненты сами двигаются по плате и встают на места в соответствии с компоновкой всего блока.
6. Возвращаемся в сборку платы, експортируем ее в IDX (IDF).
7. Создаем новый проект в Аллегро и импортируем IDF. При этом все детали, поставленные вручную в MCAD автоматом расставляются на плате.

Вот так можно?

Особенно будет весело восстанавливать привязки, когда будет делаться обратный переход ECAD->MCAD.

[Old1]

Да ладно, я не требую картинку со 100% настоящих моделей, мне интересно как это делает SW, а у меня его нет. 3 или 4 страницы исписали про выбор MCAD, и в итоге даже не видно, на что похож результат.



Old1, а у меня вот какой вопрос, Вы целиком готовый проект так прогоняли, или только начальную стадию, когда расстановка критичных деталей есть, а разводки еще нет?
реально ли начать проект в MCAD, нарисовав в нем с нуля плату и вставив некоторые компоненты? ну, например, так:
1. рисуем контур платы, выдавливаем на заданную толщину.
2. Добавляем модели разъемов, охлаждаемых компонентов и т.п., настраиваем им refdes, имена футпринтов (?)
3. Добавляем модели радиаторов/крепежа, делаем их привязку к охлаждаемым компонентам.
4. Сохраняем сборку, вставляем ее в сборку изделия в корпусе
5. В большой сборке выстраиваем привязки разъемов платы к стенкам корпуса, привязки радиаторов к стенкам/вентиляторам/термотрубкам и т.п., после чего компоненты сами двигаются по плате и встают на места в соответствии с компоновкой всего блока.
6. Возвращаемся в сборку платы, експортируем ее в IDX (IDF).
7. Создаем новый проект в Аллегро и импортируем IDF. При этом все детали, поставленные вручную в MCAD автоматом расставляются на плате.

Вот так можно?

Особенно будет весело восстанавливать привязки, когда будет делаться обратный переход ECAD->MCAD.

В MCAD назначать refdes и имена футпринтов? По моему это перебор. ИМХО MCAD под это либо совсем не заточен, либо плохо заточен.
Когда требуется привязка к железу работаю так:
-в аллегро создаю плату и на нее набрасываю все или только требующие привязки к железу компоненты (на данном этапе не важно)
-генерю IDF
-втаскиваю IDF в circutworks, перед построением модели выбираю нужные для выполнения задачи компоненты и элементы платы (например полигоны place keepout и т.п.)
-строю модель электронного блока
-вставляю и привязываю электронный блок в сборку более высокого уровня (где уже есть например корпус)
-двигаю требующие привязки электронные компоненты, и заодно если нужно редактирую железо (например пробиваю в корпусе отверстия под разъемы и т.п.)
-сохраняю сборку и втаскиваю измененную модель электронного блока назад в circutworks, сохраняю в IDF-формате
-делаю импорт измененного IDF в аллегро, в результате чего компоненты на плате меняют свое положение в соответствии с изменениями в SW.

[vitan]

Да ладно, я не требую картинку со 100% настоящих моделей, мне интересно как это делает SW, а у меня его нет. 3 или 4 страницы исписали про выбор MCAD, и в итоге даже не видно, на что похож результат.

Пожалуйста, сделал на радостях.
1. Просто окрыли IDX кнопкой open. Больше ничего не нажимали.

2. Отправили в солид, вставили примечания.

3. Сделали сборочник. Уменьшили шрифт, чтобы смотрелось нормально. Чуть-чуть подвинули оптом, т.к. вставилось не по центру копмпонентов.


Все! Вот это, я понимаю, автоматизированное проектирование.

Вот так можно?

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

[Hoodwin]

Old1, спасибо, в целом близко к тому, что я себе представлял. С поправкой на то, что все-таки "запевать" должен ECAD.

Не совсем понял, circuitworks - это отдельная программа, что ли? Не кусок (plug-in) солида?

vitan
Вот с точки зрения сборочного вида у Вас плата довольно простая, на ней почти все детали крупные. Но вот с конденсаторами C4* уже видно, что текст не вписывается в контуры и не так повернут. Поэтому при более плотной плате придется все же много делать вручную. В этом смысле аллегро лучше тем, что там я в библиотеке могу назначить правильное расположение и размер сборочного текста, и в 90% случаев он будет правильно сформован в проекте всего устройства. Подправлять придется редко.

[vitan]

Не совсем понял, circuitworks - это отдельная программа, что ли? Не кусок (plug-in) солида?

Кусок солида. Фактически, конвертер, как у компаса, только гораздо более навороченный.

Вот с точки зрения сборочного вида у Вас плата довольно простая, на ней почти все детали крупные. Но вот с конденсаторами C4* уже видно, что текст не вписывается в контуры и не так повернут. Поэтому при более плотной плате придется все же много делать вручную. В этом смысле аллегро лучше тем, что там я в библиотеке могу назначить правильное расположение и размер сборочного текста, и в 90% случаев он будет правильно сформован в проекте всего устройства. Подправлять придется редко.

А мне нравится, я именно так и хотел. Чтобы весь текст был горизонтальный. И одного размера. Это пожелание мне высказывали все монтажники, с которыми я когда-либо работал. Имхо это не лишено смысла. Попробуйте сами попаять. При постоянном рыскании глазами по чертежу важно, чтобы глаза не напрягались. Этому помогает одинаковый размер шрифта и ориентация. Ну и ренамбер сверху вниз, слева направо. Единственное, наезжает на мелкие компоненты типа тех же 0402, но монтажник уже сказал, что и так хорошо. Но это я подумаю как обыграть. Тупо уменьшить размер шрифта на худой конец, все равно все идет в масштабе и увеличивается. Зато сколько дурной работы по двиганию текста в аллегро исчезает! Я знаю, что есть скрипты, которые делают и поворот текста, и вписывание, но это все не то, ибо потом путь этому только в гербера-dxf и т.п.

[Old1]

Old1, спасибо, в целом близко к тому, что я себе представлял. С поправкой на то, что все-таки "запевать" должен ECAD.

Пожалуйста. Согласен...а разве я утверждал обратное?

[vitan]

Что ж, аппетит приходит во время еды.
Кто-нибудь знает, как делать в солиде сборки для вариантов исполнения (на основе IDF\IDX, понятно)?

[Hoodwin]

А мне нравится, я именно так и хотел. Чтобы весь текст был горизонтальный. И одного размера. Это пожелание мне высказывали все монтажники, с которыми я когда-либо работал. Имхо это не лишено смысла. Попробуйте сами попаять.

Вы меня за кого-то не того держите... Я вообще все свои платы на стадии образцов паяю сам. За исключением тех, у которых много BGA и им нужно трафаретное нанесение пасты и большое общее оплавление. Поэтому проблематику сборочного вида с точки зрения монтажника и контролера ОТК я себе представляю. Так вот, счастье монтажника не в ориентации рефдесов. Для монтажника вообще идеально, чтобы там номиналы были написаны.

Что касается упорядоченности по рефдесам слева направо сверху вниз, то это удобство тоже не для монтажника, а для ремонтника. А разница между ними большая. Монтажник собирает плату целиком, ему неудобно рыться в 10 коробочках или ленточках при пайке кучи конденсаторов по питанию, например. Он берет и высыпает перед собой много компонентов с одним номиналом, и его задача припаять их на нужные места. Ему эти рефдесы вообще неинтересны, они всегда не по порядку, либо на плате, либо в перечне элементов, если выбирать только один конкретный номинал. Поэтому я всегда делаю сборочник (гербер) и с рефдесом, и с номиналом. Беда только в том, что это уж слишком мелко. Думаю вот перейти на два варианта сборочника, один только с рефдесами, другой только с номиналами. Это в целом дает увеличение мелких текстов более чем вдвое. Но исторически получилось именно на одном, потому что Layout не умел делать сборочный вид иначе, там не было отдельных классов.
В отличие от монтажника ремонтник смотрит в схему, находит неисправные элементы и задача найти их на плате. Конечно, при упорядоченной маркировке на плате искать удобнее. Но в этом случае еще проще поискать в электронном виде, имея PDF со сборочным видом, на котором ищется любой рефдес текстовым поиском. Можно и в аллегро искать, если это свой проект.

[vitan]

Для монтажника вообще идеально, чтобы там номиналы были написаны.

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

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

Согласен, хорошая идея. Я тут, кстати, давно затеваю некую систему по улучшению поиска компонентов на сборочнике и на плате (в соседней ветке). Если есть мысли - велкам.

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

[Hoodwin]

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

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

Номиналы у меня с ходу через IDX не передались. Видимо, никто об этом при создании стандарта не думал.

Реально можно передать в IDF свойство PART_NUMBER (взамен стандартного devtype), которое назначается в схеме каждому компоненту. Это свойство можно назначить руками как угодно, в том числе скопировать туда номинал. Кстати, в OrCAD Layout именно свойство Value и передавалось в IDF, и как правило оно и было номиналом.

Интересно, что ж они все сборочники в ECADах рисуют?

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

Но ведь сборка это более механическая операция, чем электрическая, по крайней мере финальная сборка с прикручиванием винтиков... Получается, надо как-то оформлять пайку и установку компонентов в ECAD, а остальное в MCAD. Т.о. финальный чертеж все равно будет делать механик. Значит, ему нужен инструмент для вставки в свой чертеж некоего вида, на котором красиво оформлена пайка (т.е. из ECAD). Получается, что опять кроме герберов такого инструмента нету. Замкнутый круг, прямо!

Механик точно так же может вставить в чертеж внешний DXF, полученный из гербера, где уже все проставлено как надо, а остальные виды,скажем, изометрические сделает по 3D модели, и никаких рефдесов там уже не будет.

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

В Компасе, кстати, для этого есть подсистема спецификаций. Она позволяет внедрять объекты спецификации прямо в 3D-модели. Объект спецификации - это просто как бы отдельная строка из таблицы спецификации. так вот, если к документу-спецификации подключить файл модели сборки, то в нее автоматически попадают все объекты спецификации всего того, что в сборке есть. При этом спецификация может содержать и вручную набитые строки. Они при подключении сборки не удаляются, а объединяются. При переделке сборки, изменении ее состава, спецификация автоматически обновляется. Таким образом, задача определения состава спецификации более-менее решаема, несколько хуже обстоит с причесыванием внешнего вида. Во-первых, длинные строки текста нужно вручную разбивать на подстроки. Например, C1, C2, C5, C11, C32 ..., - если будет слишком длинно, то все равно будет напечатано на одной строке со сжатием текста до нечитаемого состояния. Нужно руками бить на группы по несколько рефдесов и вставлять перевод строки. Во-вторых, как Вы уже заметили, примечание не относится к категории полей, которые могут отличаться для разных компонентов одного типа, поэтому перечислить в этой графе позиционные обозначения нельзя. В третьих, даже если настроить слияние строк в графе обозначения, то можно получить при слиянии текст типа C1 C2 C3 C4 C5 C6 C7, но получить вариант C1...C7 - нельзя. С другой стороны, при поиске в PDF строки C6 она в первом случае всегда найдется, а во втором - не факт, может попасть и под сокращенную запись.

К сожалению, АСКОН, похоже, не очень хочет развивать работу со спецификациями в рамках Компаса, хотя я им писал об удобстве этой подсистемы и о возможностях ее развития для проектирования, не только для приборостроения, но и для машиностроения. Они, по-видимому, пытаются копировать подходы solidworks, и делать так, что спецификация есть просто некий автоматизированный отчет, полученный на основе документов-моделей путем генерации отчета. И они уповают на то, что, мол генерация отчетов - более гибкая схема, можно настраивать, откуда брать данные и какие, и как их группировать. Но при этом их тех.поддержка вообще не смогла ответить на вопрос, как ко всей этой гибкости добавить к моей спецификации те самые вручную введенные объекты, вроде описания самой печатной платы (не приходит из BOM), строк описания прочих документов на сборку - Э3, ПЭ3, ВП, ГЧ, и т.п. из раздела "Документация". Ну и еще некий облом в том, что отчеты они собирались вынести из Компаса и реализовать в Лоцмане, а это уже далеко не на одного разработчика замах.

Old1, доводилось ли Вам оформлять спецификацию через 3D-модели, и как в SW решается проблема перевыпуска спецификаций при изменении схемы/платы, оформлении документации на новые исполнения изделия с незначительными отклонениями от предыдущих.

Сообщение отредактировал Hoodwin - Feb 10 2012, 14:22

[vitan]

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

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

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

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

Гораздо хуже обстоит дело со спецификациями.

По идее надо сгружать бом в базу (PDM) и потом использовать для генерации СП и прочего.
Тогда все детали будут браться из единого источника.

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

Если основной источник данных для СП - не бом, то проблем нет. Надо, чтобы бом был только одним из поставщиков информации, а разработка СП велась бы "поверх" него.

[vitan]

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

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

[Uree]

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

Таки да, руками не паяют. И сборочников не делают. Полный Pick&Place и ассембли в ПДФе. Последнее "на всякий случай". Если вопросов не возникает, его даже не открывают.

А ручной труд как раз не в ответственных случаях используется, а только когда не получилось все "заточить" под автомат.
Чаще всего это специфические разъемы, ЭМ-экраны, электролиты странной ориентации и т.п. Тогда на линиях садятся китайцы и каждый добивает свои один-два компонента в состав платы. И им абсолютно не нужен полный чертеж платы, они знают только и исключительно свои пару компонентов. Полную конструкцию платы знает технолог, который техпроцесс расписывает. А у него исходная инфа тот же BOM и Pick&Place.
СМД устанавливается автоматом и в печке запекается, выводные компоненты другим автоматом, откусываются выводы, загибаются, плата прикрывается защитной маской снизу и едет на волну. Чаще всего руками устанавливаются некоторые выводные компоненты перед пайкой волной, потому как нет автоматов, которе смогли бы их установить на плату.

[Олежик]

Здравствуйте.
Посдкажите пожалуйста, как сделать так, чтобы при заливке земли (copper pour) толщина соединения между собственно заливкой и пином был потолще ? На данный момент у меня заливка соединяется с пинами тончайшими "волосками".

[Uree]

В свойствах шейпа, на вкладке "Thermal Relief Connects" измените параметр "Use Fixed Thermal Width" на желаемый.

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

[Old1]

Old1, доводилось ли Вам оформлять спецификацию через 3D-модели, и как в SW решается проблема перевыпуска спецификаций при изменении схемы/платы, оформлении документации на новые исполнения изделия с незначительными отклонениями от предыдущих.

Доводилось, но очень давно и всего пару раз, причем на небольшой неэлектронный узел. Использовал стороннюю прогу SWR-Спецификация, она интегрируется с SW и позволяет генерить спецификации по ГОСТ. Мало что осталось в памяти, но вспоминается, что при изменении сборки просто по новой генерил спецификацию и все изменения вносились автоматом, в общем для моих целей было нормально.

[vitan]

Попробовал импортнуть IDX в аллегро. Вначале все рухнуло. Поставил 15 хотфикс, и полегчало! Даже компоненты двигаться начали. Но иногда все равно падает.
Остаются некоторые непонятки по методологии работы с IDX, точнее с реализацией её в солиде. Я начал с ECAD и включил там галочку baseline. Сгенерил IDX, построил модель, подвинул компонент, отправляю обратно. Тут мне солид создает еще два файла в дополнение к уже имеющемуся .idx с названиями что-то типа mcad_baseline.idx и mcad_change1.idx. Непонятно, зачем это? Ведь изменения должны, как я понял, помещаться в исходный файл, и там отслеживаться...
И еще почему-то не передаются механические символы, ни туда, ни сюда. А в IDF передавалось.

На тему оформления. Тут как раз сломался мобильник, сижу, починяю. Так вот, там среди доков есть и некий "сборочник" (из CAM350 экспортнули, видно по заголовкам). И там как раз дав экземпляра, один с рефдесами, а второй с номиналами. Прям как в воду глядим...

[Old1]

Попробовал импортнуть IDX в аллегро. Вначале все рухнуло. Поставил 15 хотфикс, и полегчало! Даже компоненты двигаться начали. Но иногда все равно падает.
Остаются некоторые непонятки по методологии работы с IDX, точнее с реализацией её в солиде. Я начал с ECAD и включил там галочку baseline. Сгенерил IDX, построил модель, подвинул компонент, отправляю обратно. Тут мне солид создает еще два файла в дополнение к уже имеющемуся .idx с названиями что-то типа mcad_baseline.idx и mcad_change1.idx. Непонятно, зачем это? Ведь изменения должны, как я понял, помещаться в исходный файл, и там отслеживаться...
И еще почему-то не передаются механические символы, ни туда, ни сюда. А в IDF передавалось.

У меня падает Аллегро и с 15 хотфиксом при импорте mcad_change1.idx в этом файле, как я понял, хранятся последние изменения в MCAD которые нужно принять или отклонить в ECAD...

[Hoodwin]

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

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

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

Если основной источник данных для СП - не бом, то проблем нет. Надо, чтобы бом был только одним из поставщиков информации, а разработка СП велась бы "поверх" него.

Ну вот это все общие слова. Хорошо бы их наполнить конкретикой. То есть, в чем конкретно вести разработку спецификации?

[vitan]

Ну вот это все общие слова. Хорошо бы их наполнить конкретикой. То есть, в чем конкретно вести разработку спецификации?

В том софте, который позволяет взять из базы состав изделия и оформить его по ГОСТу. В составе PDM, которые для России, обычно этот софт есть. Например, в Лоцмане, я видел какой-то программный модуль, но точно не скажу, давно было. В интермеховском серче есть программа AVS. Ну и никто не запрещает использовать что-то стороннее. Например, tdd. Или вообще свое написать. Но учет состава всего изделия должен быть в базе PDM, никак не в ECAD или MCAD.

У меня падает Аллегро и с 15 хотфиксом при импорте mcad_change1.idx в этом файле, как я понял, хранятся последние изменения в MCAD которые нужно принять или отклонить в ECAD...

А что будет, если я в ECAD их отклоню, а потом в MCAD предложат новый вариант? Типа change2 будет? А если я в ответ захочу не просто отклонить, а откорректировать свое, то уже со стороны ECAD будет change1? Тут и запутаться недалеко...

[Hoodwin]

А ручной труд как раз не в ответственных случаях используется, а только когда не получилось все "заточить" под автомат.
Чаще всего это специфические разъемы, ЭМ-экраны, электролиты странной ориентации и т.п. Тогда на линиях садятся китайцы и каждый добивает свои один-два компонента в состав платы. И им абсолютно не нужен полный чертеж платы, они знают только и исключительно свои пару компонентов. Полную конструкцию платы знает технолог, который техпроцесс расписывает. А у него исходная инфа тот же BOM и Pick&Place.
СМД устанавливается автоматом и в печке запекается, выводные компоненты другим автоматом, откусываются выводы, загибаются, плата прикрывается защитной маской снизу и едет на волну. Чаще всего руками устанавливаются некоторые выводные компоненты перед пайкой волной, потому как нет автоматов, которе смогли бы их установить на плату.

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

Именно поэтому я опытные образцы предпочитаю собирать сам. Даже я еще не знаю на 100%, все ли получилось гладко, все ли номиналы были выбраны правильно, все ли документы правильно сформировались, все ли новые футпринты оказались удачны в смысле пайки. Часто перед полной сборкой я собираю только все источники вторичного питания и проверяю, что хотя бы на холостом ходу и под статической нагрузкой все напряжения в норме. И лишь потом доставляю все дорогие детали. Отдавать такое паять посторонним - это почти полностью все шишки словить от человеческого фактора. А после того, как все задышало и завелось, встает вопрос о серии, которую уже гораздо надежнее поручить автомату.

В том софте, который позволяет взять из базы состав изделия и оформить его по ГОСТу. В составе PDM, которые для России, обычно этот софт есть. Например, в Лоцмане, я видел какой-то программный модуль, но точно не скажу, давно было. В интермеховском серче есть программа AVS. Ну и никто не запрещает использовать что-то стороннее. Например, tdd. Или вообще свое написать. Но учет состава всего изделия должен быть в базе PDM, никак не в ECAD или MCAD.

Это только кажется, что просто ответить на первый вопрос. Задаю следующий:
2. Каким образом согласовать то, что написано в спецификации (на сборку) с ее сборочным чертежом, который мы делаем все же в MCAD?

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

И еще один:
3. Допустим, залили некий исходный BOM в некую базу в PDM. Потом внесли туда еще новые элементы, которые не пришли из BOM (см. выше). Потом создали спецификацию по ГОСТ. Красота. Потом вдруг сообразили, что BOM поменялся. Спрашивается: как выгрузить из базы все, что было в старом BOMe, загрузить все из нового, но не трогать то, что добавили руками?

Доводилось, но очень давно и всего пару раз, причем на небольшой неэлектронный узел. Использовал стороннюю прогу SWR-Спецификация, она интегрируется с SW и позволяет генерить спецификации по ГОСТ. Мало что осталось в памяти, но вспоминается, что при изменении сборки просто по новой генерил спецификацию и все изменения вносились автоматом, в общем для моих целей было нормально.

1. Как эта программа дружит с потребностью добавить в спецификацию, например, раздел Документация? Очевидно, если спецификация генерируется автоматически по сборке, то данные этого раздела в сборке отсутствуют, и их придется вставлять вручную. Или можно из пристегнуть в виде некоторой заготовки?
2. Что делать, если после генерации спецификации по существу (в полном составе), Вы видите, что она выглядит некрасиво: где-то текст еле втиснулся в клетку, где-то, наоборот, перенос на новую строку двух знаков от целого слова, где-то запись из двух строк разбилась на две разных страницы и было бы желательно добавить где-нибудь между разделами пустую строку?

Специфика электронных узлов заключается в том, что компоненты сборки, имеющие абсолютно одинаковые файлы 3D-модели, могут иметь совершенно разные объекты спецификации. Ну, например, резистор 0603 может быть и на 1Ком, и на 100Ком, а модель одинакова. Поэтому объекты спецификации хранить в моделях уже нельзя, нужно держать их в сборке, но хранить связь с экземплярами модели. Классическая машиностроительная сборка не такова: как правило, каждая деталь имеет свою уникальную форму (модель), объект спецификации однозначно связан с этой моделью и даже физически хранится в файле модели. Аналогия со сборкой электронного узла возникает там, где применяется какой-нибудь стандартный крепеж. В этом случае также используется одна модель и объект спецификации ставится прямо в сборку.

Сообщение отредактировал Hoodwin - Feb 13 2012, 09:47

[vitan]

Это только кажется, что просто ответить на первый вопрос. Задаю следующий:
2. Каким образом согласовать то, что написано в спецификации (на сборку) с ее сборочным чертежом, который мы делаем все же в MCAD?

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

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

И еще один:
3. Допустим, залили некий исходный BOM в некую базу в PDM. Потом внесли туда еще новые элементы, которые не пришли из BOM (см. выше). Потом создали спецификацию по ГОСТ. Красота. Потом вдруг сообразили, что BOM поменялся. Спрашивается: как выгрузить из базы все, что было в старом BOMe, загрузить все из нового, но не трогать то, что добавили руками?

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

Специфика электронных узлов заключается в том, что компоненты сборки, имеющие абсолютно одинаковые файлы 3D-модели, могут иметь совершенно разные объекты спецификации. Ну, например, резистор 0603 может быть и на 1Ком, и на 100Ком, а модель одинакова.

Это специфика не электронных узлов, а Вашего понимания. Не может быть одинаковых моделей на 1 кОм и 10 кОм. Уберите это "упрощение", и все встанет на свои места. Отличия есть, например в тексте маркировки (102 и 103). Можно его не рисовать, если лень, я особо не агитирую за это. Но две разные модели делать надо, ибо это две разные сущности.

[Hoodwin]

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

1. Пока что все, что сказано в этом топике про SW, что про IDF, что про спецификацию, выглядело таким образом, что все эти фичи достигаются пристегиванием к SW внешних вспомогательных программ. Поэтому убеждения нужно применять с осторожностью, вполне может статься, что сам по себе SW ничего не поддерживает, а только втягивает то, что дают конвертеры/генераторы.
2. Мало создать исполнение в MCAD, нужно поддерживать его связь со спецификацией. Такую связь, при которой Вам потребуется исправлять только один источник, чтобы получить согласованную пару документов, а не заниматься вручную правкой двух отчетов из одного далекого предка: 1) dsn -> pcb -> idf -> 3d-model; 2) dsn -> bom -> pdm -> спецификация. Я уже не говорю об объеме документации, который необходимо изучить, чтобы это стало возможным, а также стоимости всего потребного ПО, которую Вы просто игнорируете в своих рассуждениях.

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

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

Это специфика не электронных узлов, а Вашего понимания. Не может быть одинаковых моделей на 1 кОм и 10 кОм. Уберите это "упрощение", и все встанет на свои места. Отличия есть, например в тексте маркировки (102 и 103). Можно его не рисовать, если лень, я особо не агитирую за это. Но две разные модели делать надо, ибо это две разные сущности.

vitan, у Вас интересная особенность доводить здравые начинания до абсурдного конца. Я Вас уверяю, никто не будет плодить копии моделей только из-за того, что у них есть разные объекты спецификации. На сегодня 90% пользователей болтается между вопросом делать ли 3D модели или оставить призмы и не париться. Попробуйте сделать все модели для какого-нибудь своего проекта, и мы вернемся к вопросу о том, сколько сил и времени разумно потратить на подготовку моделей.

[vitan]

1. Пока что все, что сказано в этом топике про SW, что про IDF, что про спецификацию, выглядело таким образом, что все эти фичи достигаются пристегиванием к SW внешних вспомогательных программ. Поэтому убеждения нужно применять с осторожностью, вполне может статься, что сам по себе SW ничего не поддерживает, а только втягивает то, что дают конвертеры/генераторы.

Ну вот какая разница, плагин это или нет не пойму, хоть убей. Для пользователя все равно, если только плагин не совместим с разными САПРами (а такого я еще не видел).

2. Мало создать исполнение в MCAD, нужно поддерживать его связь со спецификацией. Такую связь, при которой Вам потребуется исправлять только один источник, чтобы получить согласованную пару документов, а не заниматься вручную правкой двух отчетов из одного далекого предка: 1) dsn -> pcb -> idf -> 3d-model; 2) dsn -> bom -> pdm -> спецификация. Я уже не говорю об объеме документации, который необходимо изучить, чтобы это стало возможным, а также стоимости всего потребного ПО, которую Вы просто игнорируете в своих рассуждениях.

Правильно, об этом и речь. Если состав изделия, включая исполнения будет вестить в PDM, а MCAD будет поддерживать отображение компонентов в зависимостиот исполнения, то технология генерации чертежей\моделей по исполнениям ничем не отличается от технологии генерации СП и прочих отчетов, о которых я выше написал.

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

Для Вас, может, и общие, а для меня - частные. Я это делал в том же серче (давно, правда). Убеждать Вас в правильности этой идеологии я долго не буду. Удивительно только это слышать от человека, который сам же работает в PDM...

vitan, у Вас интересная особенность доводить здравые начинания до абсурдного конца. Я Вас уверяю, никто не будет плодить копии моделей только из-за того, что у них есть разные объекты спецификации. На сегодня 90% пользователей болтается между вопросом делать ли 3D модели или оставить призмы и не париться. Попробуйте сделать все модели для какого-нибудь своего проекта, и мы вернемся к вопросу о том, сколько сил и времени разумно потратить на подготовку моделей.

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

[Hoodwin]

Ну вот какая разница, плагин это или нет не пойму, хоть убей.

Да, есть разница. Помните, у Райкина: "К пуговицам претензии есть?" Плагин - это как правило внешняя программа, написанная другими разработчиками, и она не может выпрыгнуть за пределы API, предоставленного разработчиком основной системы. Точно также, как allegro не поддерживал IDX до 16.5 (и не ясно еще когда он перестанет наконец падать при работе), точно также и в API SW могут быть затыки по синхронизации данных.

Правильно, об этом и речь. Если состав изделия, включая исполнения будет вестить в PDM, а MCAD будет поддерживать отображение компонентов в зависимостиот исполнения, то технология генерации чертежей\моделей по исполнениям ничем не отличается от технологии генерации СП и прочих отчетов, о которых я выше написал.

Может быть когда-нибудь и будет, через несколько лет, но вот по факту ничего такого в Компасе, например, нет. А вот Компас спецификация уже несколько лет как есть и вполне работает со сборками. Без всяких PDM и PLM.

Для Вас, может, и общие, а для меня - частные. Я это делал в том же серче (давно, правда). Убеждать Вас в правильности этой идеологии я долго не буду. Удивительно только это слышать от человека, который сам же работает в PDM...

Я не написал нигде, что я работаю в Лоцмане, я написал, что я его поставил и пока что его настраиваю. Он довольно сложный и вдобавок требует для работы Windows Server 2003 и выше, а у нас до недавнего времени стоял домен на Windows Server 2000, и там его было не развернуть. На все эти вещи времени не хватает сразу.

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

Да, да, весьма утопично. Примерно как думать, что на валяющиеся на полу грабли можно ведь и не наступать никогда, пусть себе лежат. Рано или поздно к Вам придет понимание, что в моделях неплохо бы отразить еще одну новую сущность, и тогда Вы в полном объеме насладитесь обилием копий, которые надо будет подправить. В свободное время будете раздавать справки молодым конструкторам, чем на самом деле отличается модель резистора 0603 1Ком 5% из каталога проекта 1, от такой же модели проекта 2.

[vitan]

Да, да, весьма утопично. Примерно как думать, что на валяющиеся на полу грабли можно ведь и не наступать никогда, пусть себе лежат. Рано или поздно к Вам придет понимание, что в моделях неплохо бы отразить еще одну новую сущность, и тогда Вы в полном объеме насладитесь обилием копий, которые надо будет подправить. В свободное время будете раздавать справки молодым конструкторам, чем на самом деле отличается модель резистора 0603 1Ком 5% из каталога проекта 1, от такой же модели проекта 2.

Ух! Если для Вас проблема создавать каждой сущности свою модель, то тогда тут действительно могут быть сложности с организацией. В чем проблема, Вы же создаете в ECAD для каждого резистора разную модель? Так же и тут. Не надо про какие-то мифические грабли. Если видите конкретную проблему (что конкретно такого нового надо будет отразить, что вызовет трудности), то так и говорите. Если пока не видите, то тогда и бояться не надо, а надо просто сделать. А сделать это, действительно, не трудно (скопировать и имя поменять).

Начал подключать модельки в солид. Столкнулся с вышеописанной проблемой привязок и ориентации. Плохо владею солидом, подскажите, кто знает, как проще всего создать модель (.sldprt) и повернуть в ней импортированный из STEP объект? Два дня кручу, но он никак не хочет ориентироваться как надо.

[Олежик]

В свойствах шейпа, на вкладке "Thermal Relief Connects" измените параметр "Use Fixed Thermal Width" на желаемый.

Спасибо, всё исправилось !

[Old1]

Ух! Если для Вас проблема создавать каждой сущности свою модель, то тогда тут действительно могут быть сложности с организацией. В чем проблема, Вы же создаете в ECAD для каждого резистора разную модель? Так же и тут. Не надо про какие-то мифические грабли. Если видите конкретную проблему (что конкретно такого нового надо будет отразить, что вызовет трудности), то так и говорите. Если пока не видите, то тогда и бояться не надо, а надо просто сделать. А сделать это, действительно, не трудно (скопировать и имя поменять).

Вообще-то необязательно для однотипных сущностей создавать индивидуальные 3Д-модели. Для объектов имеющих идентичные геометрические параметры вполне можно использовать одну и ту-же 3Д-модель. В SW Библиотека компонентов Circuitworks позволяет это сделать.

Начал подключать модельки в солид. Столкнулся с вышеописанной проблемой привязок и ориентации. Плохо владею солидом, подскажите, кто знает, как проще всего создать модель (.sldprt) и повернуть в ней импортированный из STEP объект? Два дня кручу, но он никак не хочет ориентироваться как надо.

Подвинуть и повернуть деталь можно при помощи операции Вставка->Элементы->Переместить/Копировать...

[Hoodwin]

Ух! Если для Вас проблема создавать каждой сущности свою модель, то тогда тут действительно могут быть сложности с организацией. В чем проблема, Вы же создаете в ECAD для каждого резистора разную модель? Так же и тут.

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

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

Конкретно проблема в том, что Вы можете ассоциировать между собой 3D-модели и футпринты. То есть, если у Вас резисторов 0603 в схеме десяток разных номиналов, но у всех футпринт (свойство PCB Footprint) задан одинаковый, то и модель у всех будет одна. Просто потому, что мэппинг моделей так работает. Копировать и имена менять идея дурацкая. Попробуйте, Вам быстро надоест это занятие.

Вообще-то необязательно для однотипных сущностей создавать индивидуальные 3Д-модели. Для объектов имеющих идентичные геометрические параметры вполне можно использовать одну и ту-же 3Д-модель. В SW Библиотека компонентов Circuitworks позволяет это сделать.

А vitan не считает их однотипными, у него каждый резистор - это личность Вот только непонятно, зачем такое городить.

Сообщение отредактировал Hoodwin - Feb 13 2012, 20:38

[Old1]

1. Как эта программа дружит с потребностью добавить в спецификацию, например, раздел Документация? Очевидно, если спецификация генерируется автоматически по сборке, то данные этого раздела в сборке отсутствуют, и их придется вставлять вручную. Или можно из пристегнуть в виде некоторой заготовки?
2. Что делать, если после генерации спецификации по существу (в полном составе), Вы видите, что она выглядит некрасиво: где-то текст еле втиснулся в клетку, где-то, наоборот, перенос на новую строку двух знаков от целого слова, где-то запись из двух строк разбилась на две разных страницы и было бы желательно добавить где-нибудь между разделами пустую строку?

Специфика электронных узлов заключается в том, что компоненты сборки, имеющие абсолютно одинаковые файлы 3D-модели, могут иметь совершенно разные объекты спецификации. Ну, например, резистор 0603 может быть и на 1Ком, и на 100Ком, а модель одинакова. Поэтому объекты спецификации хранить в моделях уже нельзя, нужно держать их в сборке, но хранить связь с экземплярами модели. Классическая машиностроительная сборка не такова: как правило, каждая деталь имеет свою уникальную форму (модель), объект спецификации однозначно связан с этой моделью и даже физически хранится в файле модели. Аналогия со сборкой электронного узла возникает там, где применяется какой-нибудь стандартный крепеж. В этом случае также используется одна модель и объект спецификации ставится прямо в сборку.

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

[Hoodwin]

Кстати, по поводу BOM variants. Все оказалось немного мрачнее, чем я думал. Оказывается, что BOM Variants - это надстройка над CIS, и в версии OrCAD PCB Editor все эти фичи недоступны, поскольку там Capture без CIS. Ну и вот CIS я пока не использовал. Видимо, придется его осваивать, или искать другие пути для описания вариантов исполнения.

В общем, проблема упирается в то, что в схеме компонентам нужно задавать свойства для формирования спецификаций, которые будут выводиться через BOM. И вот копировать свойства по разным компонентам не очень удобно, потому что часто возникают ляпы с несоответствием. Например, стоит в схеме 10 резисторов 1Ком 5%, а в свойстве PE3_Name, которое у меня используется для наименования в спецификации, стоит для 8 резисторов "Резистор 0603 1Ком 5%", а для еще двух "Резистор 0603 1.5Ком 5%", причем второй вариант может возникнуть неожиданно в процессе коррекции схемы: Value поменяют, а PE3_Name - забудут. Глазами такое довольно трудно выискивать, когда деталей много. В итоге в спецификацию попадут неправильные данные.

[vitan]

Подвинуть и повернуть деталь можно при помощи операции Вставка->Элементы->Переместить/Копировать...

О!!!! На третьи сутки дошло! Оказывается, перемещение в пространстве задается несколькими объектами типа "переместить". Я-то думал, что нужен только один... Ну наконец-то все получилось.

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

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

Конкретно проблема в том, что Вы можете ассоциировать между собой 3D-модели и футпринты. То есть, если у Вас резисторов 0603 в схеме десяток разных номиналов, но у всех футпринт (свойство PCB Footprint) задан одинаковый, то и модель у всех будет одна. Просто потому, что мэппинг моделей так работает.

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

Копировать и имена менять идея дурацкая. Попробуйте, Вам быстро надоест это занятие.

Извольте обосновать. Ярлыки навешивать каждый может.
Попробовал, понравилось. Модели создаются влет, за 5 минут получил кучу моделей для разных номиналов. Не разрисовывал, конечно, но сам факт.

А vitan не считает их однотипными, у него каждый резистор - это личность Вот только непонятно, зачем такое городить.

Вы в курсе, что конденсаторы, например 0402, имеют разную высоту при одинаковом футпринте. Понимаете, куда Ваше упрощение может Вас завести?

[Uree]

Извольте обосновать. Ярлыки навешивать каждый может.

Можно я попробую? У меня в библиотеках только на резистор создано 5368 девайсов. Это без резисторных сборок. Остальных компонентов-девайсов тоже достаточно. Вы серьезно предлагаете на все создавать индивидуальные модели?