[vitan 2]

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

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

 

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

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

 

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

[vpd 0]

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

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

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

 

 

Номиналы у меня с ходу через 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 решается проблема перевыпуска спецификаций при изменении схемы/платы, оформлении документации на новые исполнения изделия с незначительными отклонениями от предыдущих.

Изменено 10 февраля, 2012 пользователем Hoodwin

[vitan 2]

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

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

 

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

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

 

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

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

Тогда все детали будут браться из единого источника.

 

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

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

[vitan 2]

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

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

[Uree 1]

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

 

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

 

А ручной труд как раз не в ответственных случаях используется, а только когда не получилось все "заточить" под автомат.

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

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

[Cavalryman 0]

Здравствуйте.

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

[Uree 1]

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

 

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

[Old1 0]

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

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

[vitan 2]

Попробовал импортнуть IDX в аллегро. Вначале все рухнуло. Поставил 15 хотфикс, и полегчало! Даже компоненты двигаться начали. Но иногда все равно падает.

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

И еще почему-то не передаются механические символы, ни туда, ни сюда. А в IDF передавалось.

 

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

[Old1 0]

Попробовал импортнуть IDX в аллегро. Вначале все рухнуло. Поставил 15 хотфикс, и полегчало! Даже компоненты двигаться начали. Но иногда все равно падает.

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

И еще почему-то не передаются механические символы, ни туда, ни сюда. А в IDF передавалось.

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

[vpd 0]

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

 

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

 

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

 

 

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

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

 

[vitan 2]

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

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

 

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

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

[vpd 0]

А ручной труд как раз не в ответственных случаях используется, а только когда не получилось все "заточить" под автомат.

Чаще всего это специфические разъемы, ЭМ-экраны, электролиты странной ориентации и т.п. Тогда на линиях садятся китайцы и каждый добивает свои один-два компонента в состав платы. И им абсолютно не нужен полный чертеж платы, они знают только и исключительно свои пару компонентов. Полную конструкцию платы знает технолог, который техпроцесс расписывает. А у него исходная инфа тот же 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Ком, а модель одинакова. Поэтому объекты спецификации хранить в моделях уже нельзя, нужно держать их в сборке, но хранить связь с экземплярами модели. Классическая машиностроительная сборка не такова: как правило, каждая деталь имеет свою уникальную форму (модель), объект спецификации однозначно связан с этой моделью и даже физически хранится в файле модели. Аналогия со сборкой электронного узла возникает там, где применяется какой-нибудь стандартный крепеж. В этом случае также используется одна модель и объект спецификации ставится прямо в сборку.

Изменено 13 февраля, 2012 пользователем Hoodwin

[vitan 2]

Это только кажется, что просто ответить на первый вопрос. Задаю следующий:

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

 

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

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

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

 

И еще один:

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

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

 

 

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

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

[vpd 0]

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