Технические требования для покупки САПР ТП

[leo-kaleta 0]

Мне не все понятно с объектом "проточка" - правильно ли на схеме указаны атрибуты 20;50? Может быть, должно быть "14,40"?

В принципе, нотация интуитивно понятно, есть какие-то отдаленные элементы сетей Петри. Есть ли ее точная формализация?

Задается ли связь узлов графа с элементами формы детали?

В обозримом будущем я посмотрю, есть ли соответствующие ентитя в AP240.

Да, это ошибка.

Исправил, повторяю все шаги.

1-й шаг.

2-й шаг

3-й шаг

4-й шаг

5-й шаг

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

[PeterShilnikov 1]

Да, это ошибка.

Замечательно! Значит, я хоть что-то в этом понимаю, если сумел обнаружить неувязочку.

Показано, что 3D элементы можно вводить с помощью 2D схемы. Иногда это быстрее и удобнее (но не всегда).

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

А по поводу того, что я обещал - загляну на днях повнимательнее в AP240, и напишу о своих мыслях.

[leo-kaleta 0]

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

А разводку печатных плат тоже в 3D проектировать? Это как? Объясните, пожалуйста.

[PeterShilnikov 1]

А разводку печатных плат тоже в 3D проектировать? Это как? Объясните, пожалуйста.

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

[leo-kaleta 0]

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

По своему опыту - аэродинамические конструкции, рамы, фрезерные детали, ориентаторы предметов, сложные компоновки надо проектрировать в 3D. Печатные платы, панели, компоновку приборных досок надо проектировать в 2D. Штампы, насосы, опоры - всё, что ближе к схемам, лучше проектировать в 2D.

[PeterShilnikov 1]

По своему опыту - аэродинамические конструкции, рамы, фрезерные детали, ориентаторы предметов, сложные компоновки надо проектрировать в 3D. Печатные платы, панели, компоновку приборных досок надо проектировать в 2D. Штампы, насосы, опоры - всё, что ближе к схемам, лучше проектировать в 2D.

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

[leo-kaleta 0]

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

Кажется в этом споре мы сейчас найдём истину.

Совершенно с Вами согласен. Даже, когда вводится информация в 2D, параллельно должна формироваться 3D модель. Отсюда следует - САПР должна обеспечивать проектанту свободу выбора: хочешь - работаешь в 2D на разноцветных графических слоях, хочешь - работаешь в 3D, хочешь - переходишь из режима 3D в 2D, и наоборот любое количество раз. Во всех случаях получаешь ОДИН результат - 3Dмодель, связанную с многочисленными видами сборочного чертежа, подсборок, чертежей деталей, спецификаций и многими другими очень полезными 2Dдокументами.

[VOleg 228]

Кажется в этом споре мы сейчас найдём истину.

Совершенно с Вами согласен. Даже, когда вводится информация в 2D, параллельно должна формироваться 3D модель. Отсюда следует - САПР должна обеспечивать проектанту свободу выбора: хочешь - работаешь в 2D на разноцветных графических слоях, хочешь - работаешь в 3D, хочешь - переходишь из режима 3D в 2D, и наоборот любое количество раз. Во всех случаях получаешь ОДИН результат - 3Dмодель, связанную с многочисленными видами сборочного чертежа, подсборок, чертежей деталей, спецификаций и многими другими очень полезными 2Dдокументами.

Привет, спорщикам.

Опять перебираете.

Если конструктор перешел в 3Д - то просто смешно от него требовать что-то в 2Д. Это. сев в Мерседес, начать искать двигатель спереди - ну по привычке, как в Запорожце - хоть и та и другая - иномарки - для Питерцев, конечно!

...

Кстати, по поводу заусенцев - я уже на форуме выкладывал цитату из ГОСТ - "заусенцы снимаются ВСЕГДА! Вопрос только в том, что если в чертеже явно задана фаска для снятия заусенцев или нет... Это описывает ГОСТ ОДНОЗНАЧНО!

...

Теперь по спецификации - раз уж здесь ее всуе упомянули... так вот с 2010 Солида - СП является составной частью 3Д модели! так что она теперь не относится к 2Д явлениям...

...

Теперь к САПР-ТП - она создает инструкцию (с эскизами) для РАБОЧЕГО - а не для кандидата технических наук!

[PeterShilnikov 1]

Псев в Мерседес, начать искать двигатель спереди - ну по привычке, как в Запорожце -

А разве у Mercedes двигатель не спереди?

Теперь к САПР-ТП - она создает инструкцию (с эскизами) для РАБОЧЕГО - а не для кандидата технических наук!

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

- СП является составной частью 3Д модели! так что она теперь не относится к 2Д явлениям...

Поскольку спецификация - это абстрактный граф, она не имеет геометрической формы, и не относится ни к 3-мерным, ни к 2-мерным явлениям.

[leo-kaleta 0]

Хотелось бы узнать мнение VOleg и PeterShilnikov <noindex>о мехатронике</noindex>, например от фирмы Сименс. Мне кажется, что вы оба ошибаетесь, называя "моделью" 3D-макет изделия, выполненный в солидах (виртуальных твёрдых телах, если расшифровать). Модель - это больше, чем просто солиды.

[PeterShilnikov 1]

Хотелось бы узнать мнение VOleg и PeterShilnikov <noindex>о мехатронике</noindex>, например от фирмы Сименс. Мне кажется, что вы оба ошибаетесь, называя "моделью" 3D-макет изделия, выполненный в солидах (виртуальных твёрдых телах, если расшифровать). Модель - это больше, чем просто солиды.

Твердые тела образуют геометрическую форму изделия, т.е. геометрическую модель изделия. Термин "макет" появился на некоторых российских фирмах даже в нормативной документации вследствие того, что идеологи-дилетанты не поняли, что такое "Digital Mock-up" (DMU), выдернули этот красивый, на их взгляд, термин из контекста и вставили в свой контекст.

Геометрическая модель - это всего лишь одно из свойств изделия (одна из разновидностей моделей), но наиболее сложное и ответственное свойство, поскольку именно эта модель используется и для технологической подготовки, и для имитационного моделирования (simulation). Частный, но наиболее проработанный вид simulation - это прочностные расчеты, затем - тепловые. Для simulation тоже нужны модели, но со своей спецификой.

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

[leo-kaleta 0]

Уважаемый PeterShilnikov. Большое Вам спасибо за ответ, который мне очень понравился. Хотелось бы задать Вам ещё один вопрос. В моей практике был эпизод, когда пришлось сделать небольшую анимацию в Inventore. Причём это понадобилось сделать не с помощью обычных кинематических связей, а через его таблицу параметров f(X), написании небольшой программы в VBA и записи названия этой программы в строке таблицы. Убедился, что таким образом можно создать полноценный производственный мультфильм (с исчезновением и появлением предметов, движением предметов по произвольному маршруту). У нас, видимо, эту опцию используют редко, так как 3 странички HELP только на английском языке в описании API программиста. Как Вы думаете - почему ИМ это надо, а НАМ не надо?

[PeterShilnikov 1]

Уважаемый PeterShilnikov. Большое Вам спасибо за ответ, который мне очень понравился. Хотелось бы задать Вам ещё один вопрос. В моей практике был эпизод, когда пришлось сделать небольшую анимацию в Inventore. Причём это понадобилось сделать не с помощью обычных кинематических связей, а через его таблицу параметров f(X), написании небольшой программы в VBA и записи названия этой программы в строке таблицы. Убедился, что таким образом можно создать полноценный производственный мультфильм (с исчезновением и появлением предметов, движением предметов по произвольному маршруту). У нас, видимо, эту опцию используют редко, так как 3 странички HELP только на английском языке в описании API программиста. Как Вы думаете - почему ИМ это надо, а НАМ не надо?

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

Апофеоз маразма: недавно читал в ТЗ на автоматизацию пункт о том, что PDM-система должна иметь средства для обработки ПИ (Предварительных извещений об изменении). Прежде чем думать о PDM-системе, надо наладить полноценную передачу электронных моделей, тогда и смысл в работе с ПИ исчезнет. Кстати, по поводу ПИ: как-то уже давно мы пытались найти соответствия между нашими документами ЕСКД и ентитями 203 Протокола STEP, издания 1994 года. Так практически подо все документы удалось подобрать ентитя, а под ПИ - ну никак. Значит, западные разработчики еще 15 лет назад понимали, что в условиях компьютерной автоматизации это не нужно.

Можно еще много чего сказать, но это - уже для форумов с другой направленностью.

[leo-kaleta 0]

Уважаемый PeterShilnikov. Вы опять ответили очень интересно и полезно для темы.

Хотелось бы узнать Ваше мнение о следующих рассуждениях:

"Любое изделие машиностроения (Машина) состоит из Систем. Каждая Система построена по принципу матрёшки - состоит из более мелких частей. Эти технические Системы сложным образом переплетены друг с другом. Любая Машина выполняет вполне определённый набор функций. Поэтому Машину можно представить в виде функциональной схемы. Каждую функцию Машины выполняет Комбинация технических Систем или их частей. Конкретные Машины рождаются (проектируются), живут (работают) и умирают (утилизируются), а вот Комбинации, как генетический код, передаются от Машины к Машине, мутируют, развиваются, проходят эволюционный отбор. Следовательно, наиболее эффективным способом накопления технических знаний (ноу-хау), передачи их от одного поколения Производственников к другому является упаковка их внутри функциональных Комбинаций. Каждый фрагмент (каждая Комбинация Систем) этой базы знаний расположен одновременно во многих информационных объектах - 3Dмоделях, сборочных чертежах, схемах, спецификациях, технологических документах, экономических документах, отчётах, журналах отказов и прочее... Любую Машину можно проектировать, собирая её из этих Комбинаций. При этом проектировщик будет одновременно формировать весь комплект информационных объектов Машины"

[VOleg 228]

Хотелось бы узнать мнение VOleg и PeterShilnikov <noindex>о мехатронике</noindex>, например от фирмы Сименс. Мне кажется, что вы оба ошибаетесь, называя "моделью" 3D-макет изделия, выполненный в солидах (виртуальных твёрдых телах, если расшифровать). Модель - это больше, чем просто солиды.

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

Ессно - модель изделия не только красивая картинка - к красивой картинке прилагается куча свойств, таблиц, текстовых файлов и чего-еще там надо - вот все это в совокупности и называется МОДЕЛЬЮ. У меня, во-всяком случае.

Про "модные словечки" ничего не могу сказать - я ими не интересуюсь.

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

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

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

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

В общем все гораздо проще...

[PeterShilnikov 1]

Уважаемый PeterShilnikov. Вы опять ответили очень интересно и полезно для темы.

Хотелось бы узнать Ваше мнение о следующих рассуждениях:

"Любое изделие машиностроения (Машина) состоит из Систем. Каждая Система построена по принципу матрёшки - состоит из более мелких частей. Эти технические Системы сложным образом переплетены друг с другом. Любая Машина выполняет вполне определённый набор функций. Поэтому Машину можно представить в виде функциональной схемы. Каждую функцию Машины выполняет Комбинация технических Систем или их частей. Конкретные Машины рождаются (проектируются), живут (работают) и умирают (утилизируются), а вот Комбинации, как генетический код, передаются от Машины к Машине, мутируют, развиваются, проходят эволюционный отбор. Следовательно, наиболее эффективным способом накопления технических знаний (ноу-хау), передачи их от одного поколения Производственников к другому является упаковка их внутри функциональных Комбинаций. Каждый фрагмент (каждая Комбинация Систем) этой базы знаний расположен одновременно во многих информационных объектах - 3Dмоделях, сборочных чертежах, схемах, спецификациях, технологических документах, экономических документах, отчётах, журналах отказов и прочее... Любую Машину можно проектировать, собирая её из этих Комбинаций. При этом проектировщик будет одновременно формировать весь комплект информационных объектов Машины"

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

Конечно же, этим стоит заниматься, но те преимущества, которые обеспечивает компьютер:

- компактность информации, отсюда - возможность хранения бесконечного количества версий и комбинаций изделия;

- быстрота доступа к данным, их размножения и пересылки;

- быстрые точные расчеты, позволяющие выполнять имитационное моделирование изделий, включая прочностные, тепловые, аэродинамические расчеты множества вариантов.

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

[leo-kaleta 0]

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

Конечно же, этим стоит заниматься, но те преимущества, которые обеспечивает компьютер:

- компактность информации, отсюда - возможность хранения бесконечного количества версий и комбинаций изделия;

- быстрота доступа к данным, их размножения и пересылки;

- быстрые точные расчеты, позволяющие выполнять имитационное моделирование изделий, включая прочностные, тепловые, аэродинамические расчеты множества вариантов.

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

Спасибо за ответ. Если коротко Ваши слова можно интерпретировать так: "Инженерная служба на предприятии нужна. Большой Красной кнопки ещё долго не будет"

[leo-kaleta 0]

Поговорили о высоких материях и хватит. А теперь вернёмся к рутине.

Обозначения объектов.

Требование: "Одним из критериев поиска в базе данных САПР ТП должно быть обозначение объектов. Не допускается исключение этой возможности в алгоритме поиска."

Комментарий: К сожалению, даже в известных САПР, встречается эта грубая ошибка. Обозначение объекта для поиска не доступно. И это очень-очень неудобно. Если кому-то нужны конкретные примеры - напишу в личку.

[PeterShilnikov 1]

К сожалению, даже в известных САПР, встречается эта грубая ошибка. Обозначение объекта для поиска не доступно. И это очень-очень неудобно.

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

[leo-kaleta 0]

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

Думаю, что это проще делать без PDM-блокнотика, если файл называть по принципу ОБОЗНАЧЕНИЕ+НАИМЕНОВАНИЕ, как в обычной спецификации. А если покупать PDM, то с более широким функционалом. Не будем забывать о том, что есть стандартные изделия, у которых тоже есть обозначения. Некоторые изготовители ПО предоставляют библиотеки этих изделий...