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

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



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






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

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

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


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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Да ладно, я не требую картинку со 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.

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

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

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


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



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

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

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

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

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



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

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

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

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

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

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


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

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

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



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



Я думаю, что они уже развратились настолько, что сборочники не рисуют, а отправляют на завод pick and place файл, точно также как Вам уже не приходит в голову оформлять шаблоны слоев в виде PDF с рамками и штампом. В худшем случае его из 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 решается проблема перевыпуска спецификаций при изменении схемы/платы, оформлении документации на новые исполнения изделия с незначительными отклонениями от предыдущих.

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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



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

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


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

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

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


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

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

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




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

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

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


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



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

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


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



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

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


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


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


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

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



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




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




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

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

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

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

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

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

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



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




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

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 - забудут. Глазами такое довольно трудно выискивать, когда деталей много. В итоге в спецификацию попадут неправильные данные.

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


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


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


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


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

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