[vpd 0]

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

 

 

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

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

 

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

 

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

 

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

 

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

На самом деле правда жизни совсем другая:

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

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

eCAD_converter_manual.pdf

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

[vitan 2]

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

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

 

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

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

 

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

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

 

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

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

[vpd 0]

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

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

 

Добро? :rolleyes:

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

[vitan 2]

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

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

 

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

 

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

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

 

 

Вот в приведенном выше документе есть ссылки на стандарты IDF версия 2.0 и 3.0.

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

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

Сорри пока вдаваться в особенности IDF не буду, не вижу смысла. Вот, если придется писать конвертер...

 

 

 

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

 

Добро? :rolleyes:

Зло. :)

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

[vpd 0]

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

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

[dead_cell 0]

Я сказал, что с обратным преобразованием (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 2]

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

[vpd 0]

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

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

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

 

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

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

 

 

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

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

 

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

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

 

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

Никто не знает, что у кейденса есть на эту тему?

 

 

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

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

[vpd 0]

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

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

 

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

 

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

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

 

 

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

 

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

 

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

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

[vitan 2]

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

Ну, не знаю, я изначально не хочу просто быть в чем-то ограничен.

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

 

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

 

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

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

[vpd 0]

Ну, не знаю, я изначально не хочу просто быть в чем-то ограничен.

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

 

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

Вот откройте страницу 16, переведите содержимое таблички record 2, и скажите мне, чего Вам еще там не хватает?

[vitan 2]

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

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

Тут говорили про SolidWorks, вроде бы, там тоже самое, поправьте, кто знает?

[dead_cell 0]

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

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

 

а вот еще для размышлений :)

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

 

[vpd 0]

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

CAPACITANCE
RESISTANCE
TOLERANCE
POWER_OPR
POWER_MAX
THERM_COND
THETA_JB
THETA_JC
Other

 

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