ЭСИ

[Ruslan 266]

Все достаточно просто.

Есть два варианта:

1. Система PDM грузит всю информацию по составу вообще по шапке файлов, где содержится нужная информация.

2. Открывается Символьное представление (Дерево сборки, параметры, без геометрии). Или создается предварительно пользовательское представление отвечающее условиям необходимого отчета.

тебе надо полностью перепроектировать в ProE сборку из 1000и деталей).

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

Хоть в массо-габаритном виде, но с полным составом.

[AnTe 1]

Ещё один вопрос, заход с другого конца!!

А никто не пробовал, как основную базу для ЭСИ, использовать "дерево построения", в какой-нибудь CAD-системе??

т.е. получать спецификации напрямую как отчёты из этого дерева, в идеале отказавшись от СП совсем, как и допускается в ГОСТах?

Изменено 16 июня 2008 пользователем AnTe

[Странник 6]

Все относительно просто и хорошо, когда процесс создания ЭСИ совпадает с моментом начала работ над совершенно новым изделием...

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

Из ACAD в SolidWorks "поднять" элементы не очень сложно, а вот без "живой" прорисовки изделие умрёт, это уже опыт.

Все достаточно просто.

Есть два варианта:

1. Система PDM грузит всю информацию по составу вообще по шапке файлов, где содержится нужная информация.

2. Открывается Символьное представление (Дерево сборки, параметры, без геометрии). Или создается предварительно пользовательское представление отвечающее условиям необходимого отчета.

А связи между документами как создавать?

"Обозначение" и "Наименование", "Первичное применение", количество вхождений и т.д. и т.п. так просто в шапку не загонишь.

Да и графически дерево рисовать тоже очень и очень спороно.

Врядли что лучше реального ЭЦМ устроит все заинтересованные стороны.

[Ruslan 266]

А связи между документами как создавать?

"Обозначение" и "Наименование", "Первичное применение", количество вхождений и т.д. и т.п. так просто в шапку не загонишь.

В смысле?

ПДМ да и сам САПР находит все нужные файлы (имена файлов уникальны), перечисленные в шапке (с указанием типа вхождения (подавленные, включенные и т.п. и количества).

Что касается пользовательских параметров в шапке, то для этого в ПроЕ существует функция Designate (Отметить) где можно отметить необходимые параметры и элементы. После этого они будут в шапке файла.

То есть достаточно нормально настроенного шаблона.

Именно так это реализовано в ПроЕ для работы с ПДМ.

Да и графически дерево рисовать тоже очень и очень спороно.

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

[suslad 1]

Ещё один вопрос, заход с другого конца!!

А никто не пробовал, как основную базу для ЭСИ, использовать "дерево построения", в какой-нибудь CAD-системе??

т.е. получать спецификации напрямую как отчёты из этого дерева, в идеале отказавшись от СП совсем, как и допускается в ГОСТах?

Идея не нова. Все с этого начинают. Подход верный -- так сегодня многие и поступают -- однако у него есть и слабое место -- что делать хотя-бы с разделом "Документация"? Пользовать "пустышки"? А что тогда делать с реальными документами? Пусть валяются где попало?

[Странник 6]

В смысле?

ПДМ да и сам САПР находит все нужные файлы (имена файлов уникальны), перечисленные в шапке (с указанием типа вхождения (подавленные, включенные и т.п. и количества).

Что касается пользовательских параметров в шапке, то для этого в ПроЕ существует функция Designate (Отметить) где можно отметить необходимые параметры и элементы. После этого они будут в шапке файла.

То есть достаточно нормально настроенного шаблона.

Именно так это реализовано в ПроЕ для работы с ПДМ.

Положительно, нужен словарь межкадовских терминов.

Что понимается под шапкой файла?

Лучше если скринчик показать.

В смысле?

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

И девочка-оператор (у которой образование-ПТУ) потребует полнокровного рабочего места CAD?

Или конструктор засядет на работу из серии "дятел"?

Нет уж, либо надо строить настоящий ЭЦМ, либо автоматизировать формирование ЭСИ с помощью EXCEL и html.

Второе актуально когда есть куча старой КД в бумажном или ACAD виде, ибо такие докУменты можно подцепить к вновь созданной ЭСИ, потом же всё одно надо будет ЭЦМ строить.

P.S. ещё раз посмотрите последнее сообщение вот тут

<noindex>http://fsapr2000.ru/index.php?showtopic=2...20&start=20</noindex>

[Ruslan 266]

Положительно, нужен словарь межкадовских терминов.

Что понимается под шапкой файла?

Нужен.

Под шапкой файла, понимается начало файла, где лежит в легкодоступном виде(фактически в текстовом) нужная информация. То есть ПДМ даже подымать файл не надо, а только прчесть заголовок.

И девочка-оператор (у которой образование-ПТУ) потребует полнокровного рабочего места CAD?

И чем она будет заниматься? Что полная модель, такого места не потребует? Если не использовать ПДМ и генерировать нужные документы будет не конструктор, то тоже проблем не вижу. Думаю девочке можно повесить инструкцию, какие кнопки нажимать (всего лишь две дополнительные).

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

при этом народ согласен терять огромную часть возможностей модели, сборки (каринка справа вверху), чертежа (каринка слева внизу), и даже согласен на несколько дополнительных шагов в построении ЭЦМ (каринка справа внизу)?

О каких потерях идет речь? Ну потеря возможности размножения по ссылочному массиву. Не смертельно.

[Странник 6]

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

ИМХО, если внедряемая система требует постоянного участия операторов по обезьяньим работам, то это не автоматизация вовсе, но диверсия... тем более если на таковое нужно будет подсаживать высококласснейших сотрудников. Да и лицензия на приличный CAD тоже не 5 копеек стоит.

Если имеет место классическая печальная ситуация перехода с бумаги и 2D чертилок в полнокровный параметрический CAD и производственную АСУ, то врядли есть что лучше связки EXEL-html, но проектировщику всё одно ЭЦМ потребуется... это ж функционально тож самое что компоновочная прорисовка, только на качественно более высоком уровне.

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

[Ruslan 266]

Так и я о том что девочка-оператор не нужна.

Кстати, для той же ЭСИ важны стандартные элементы сборк

А данные о них никуда не денутся.

Опять же, в деталях останутся только 3 стандартные плоскости

В ПроЕ вообще нет такого понятия.

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

И потом, что мешает передать и плоскости, это такаяже геометрия, как и все остальное.

Кроме того, не будет возможности импорта размеров (параметрических) в чертёж из модели.

Вопрос в том а собственно зачем? Чертежи же оформляются на полные модели или упрощенные представления.

Вставка с потерей параметризации служит для совсем других целей.

[Странник 6]

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

2. Смысл "подрыва" в фиктивном укорочении дерева проектирования, а тут надо ещё и рабочие плоскости, оси, точки (в SolidWorks это называется справочной геометрией) импортировать... это ж считай таж самая параметризация, да ещё ссылочная. И так выигрыш в быстродействии спорен, а тут ещё множественный контекст.

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

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

Таким образом, полнокровные ЭЦМ и ЭСИ возможно создать только с параметризованными моделями, а методы "взыва" и "EXCEL-html" неизбежно приводят к появлению дятлообразных работ на постоянной основе и лавинообразному нарастанию числа ошибок. Всё в полном соответствии со вторым началом термодинамики, кстати сказать.

[Ruslan 266]

Жаль что я не учитель и не могу объяснить нормально, так что бы мы поняли друг друга.

1. Автопривязка в ПроЕ в принципе есть, но я ей не пользуюсь. Выбираешь метиз, а ПроЕ анализирует размер геометрии и при подходящих условиях присоединяет.

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

2. Справочная геометрия подчиняется тем же законам что и остальная и ничего за сабой не тянет.

3. ПОтери ассоциативности нет.

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

[AnTe 1]

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

я сам с трудом представляю, как можно отчёт, т.е. ЗАПРОС в БД оформить и отслеживать, как документ, пусть он и содержит реквизитную часть.

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

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

По моему в определении нет ни слова о необходимости включения в конкретную ЭСИ всех уровней иерархии..

Но если ЭСИ выполнять когда необходимо (при передаче на сторону) по "удобной отработанной технологии" - то какие проблемы? Даже легче все уровни иерархии воткнуть (настройка отбора меньше).

Ну вообще да. Я под ЭСИ в какой-то момент начал понимать один-единственный документ, который подписывают все :) теперь понимаю, как ЭСИ на колесо и ЭСИ на мост, содержащий это самое колесо - два разных документа!

[AnTe 1]

По поводу электроных моделей согласен - см. примечаниях к таблице 4 ГОСТ 2.102-68 изм. 8. , а вот насчтет необязательности спецификации при наличии ЭСИ помоему Вы погорячились.

В ГОСТ 2.102 в примечаниях к таблице 3 указано, что Спецификацию, ВС, ВД, ВП, ВИ, ДП, ПТ, ЭП, ТП, ВДЭ, ЗИ, ВЭ и др. при выполненнии автоматизированным способом следует получать, при возможности, в форме отчета из электронной модели. И никаких указаний о необязательности спецификации.

п 2.2. после изменения выглядит так:

За основные конструкторские документы принимают:

для деталей - чертёж детали, и (или) ЭМИ

для сборочных единиц, комплексов и комплектов - спецификацию, и (или) ЭСИ

СП почти всегда содержит определенный набор данных, не содержащийся в ЭСИ,

Почему?? Ведь ЭСИ - это как раз то, что придумают его разработчики. Что мешает включить в ЭСИ, как минимум, ВСЮ информацию из СП? О том, что можно дополнить полезной, я пока не упоминаю....

ps сейчас, наверное, савсэм "чайниковский" вопрос задам... :)

Ведь в содержательной части спецификации всего семь полей? формат-зона-поз-обозначение-наименование-колво-примечание ?

[AnTe 1]

Конструктор работает с моделями, пусть и далее с ними работает, а все чертежи, ЭСИ, СП должны легко либо даже автоматически строиться с модели.

И наоборот! Всё это вместе назовём синхронизацией.

Собственно для этого ЭЦМ и нужны.

Просматривается как бы отражение события через фильтры тех или иных задач.

Какого события? В ЭМИ (электронная модель изделия) обычно содержится далеко не вся информация, что в спецификации, да и дерево построения, вроде, может отличаться? т.е. процесс получения ЭСИ из ЭМИ = "фильтрация", т.е. отбор необходимых данных + "ручной ввод", т.е. упомянутая обезьянья работа.

Идея не нова. Все с этого начинают. Подход верный -- так сегодня многие и поступают -- однако у него есть и слабое место -- что делать хотя-бы с разделом "Документация"? Пользовать "пустышки"? А что тогда делать с реальными документами? Пусть валяются где попало?

Да, пожалуй. Плюс к этому проблема с теми изделиями, которые выпущены, на которые ссылаются, но для которых не разработаны модели.

Итак, мне известно 3 способа построения ЭСИ:

1. Автоматически по полноценному ЭЦМ;

2. Частично по модели с дополнением вручную;

3. Полностью вручную.

Первый способ впечатляет. А что такое ЭЦМ? В ГОСТах нет даже рекомендации, вот, из 2.053:

4.6 ЭСИ формируется, как правило, автоматизированным способом на основе информации, храня-

щейся в ОБДИ*.

примечание к 4.6: Автоматически ЭСИ создается при проектировании изделия (сборочной единицы, комплекса, комплекта) в САПР, поддерживающих протоколы применения, например ИСО 10303-203 и, в частности, создание файла (файлов) по ИСО 10303-21. Такой файл (файлы), снабженный реквизитной частью по ГОСТ 2.104, может затем быть передан в системы управления данными об изделии, управления производством, управления эксплуатацией и т. д.

Полуавтоматически ЭСИ создается средствами системы управления данными об изделии, построенной на принципах серии стандартов ИСО 10303, поддерживающей протоколы применения и, в частности, создание файла (файлов) по ИСО 10303-21; аналогично предыдущему этот файл (файлы), снабженный реквизитной частью по ГОСТ 2.104, может затем быть экспортирован в САПР, системы управления производством, управления эксплуатацией и т. д.

Сам не знаю, зачем процитировал. Какие САПР способны, переведу сразу на русский, "создавать файлы в SGML", когда ЭМИ по определению не содержит всей необходимой информации для ЭСИ?

Короче, - какие САПР при проектировании автоматом ведут "ЭЦМ", такую, что из неё ЭСИ получится как отчёт, автоматом?

Изменено 18 июня 2008 пользователем AnTe

[askn 0]

я сам с трудом представляю, как можно отчёт, т.е. ЗАПРОС в БД оформить и отслеживать, как документ, пусть он и содержит реквизитную часть.

Не забывайте, что ЕСКД появилась в условиях, когда вычислительной техники в общем-то не было..

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

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

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

..Я под ЭСИ в какой-то момент начал понимать один-единственный документ, который подписывают все :) теперь понимаю, как ЭСИ на колесо и ЭСИ на мост, содержащий это самое колесо - два разных документа!

Число реквизитов вообще-то не увеличивается, то есть подписывает "верхушка". А вот выпускать или нет ЭСИ на мост и колесо отдельно - зависит от разделения ответственности и пожеланий заказчика (пользователя) документации, с учетом действующих факторов. То есть решается в каждом конкретном случае.

[Елена 116]

для askn

Просто колесо - это входящая ДСЕ в изделии мост.

Подпись можно ставить и на то и на то, если ЭСИ - это БД в соответствующей структуре, привязка подписи к обозначению.

База единая, каких - два документа

ЭСИ - это вообще не отчет и бумажного аналога не имеет. А вот с ЭСИ можно программным способом формировать отчеты.

Если передавать на сторону - то это тоже БД, только сформированная запросом по головному обозначению

[Странник 6]

to Ruslan

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

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

to AnTe

1. ЭЦМ это электронно-цифровой макет изделия, то есть построеная средствами действующего на головном предприятии CAD трёхмерная модель изделия. для ЭЦМ подразумевается детализация до уровня отражения в спецификации и придание каждому из компонентов сборки соответствующих свойств: геометрии, плотности, прочности и чего ещё только позволит применяемый софт. Можете считать, что ЭЦМ=ЭМИ, если угодно.

Что важно осознавать: ЭЦМ применяется не столько для отражения существующей, сколько для формирования новой КД, именно он создаёт то самое преимущество по сравнению с бумажной технологией создания новой техники.

Тут можно выделить прямую и обратную задачи применения CAD систем:

прямая - получения чертежей и ЭСИ как отражения модели;

обратная - получение модели как отражения чертежей и спецификаций.

Сейчас народ всё более вокруг обратной вертится, но в самом деле это более свойственно технологам и расчётчикам, чем проектировщикам.

2. Рассмотрим в качестве примера события факт уничтожения немецкого самолёта марки Ю-88 советским самолётом марки P-39 в мае 1943 года, в районе устья реки Кубани.

Представляете какую различную информацию вынесут из этого факта все заинтересованные стороны, какими разнообразными документами этот факт обрастёт, сколь различны будут выводы и последствия для участников проишествия?

Подобным образом и здесь.

Конструктор создал модель на сборку АБВГ.01.02.030, в неё входит ряд моделей подсборок, деталей, покупных элементов, материалов и стандартных изделий, сама она входит в некую сборку высшего уровня. Всё это отображается в ЭСИ. На каждый из компонентов этой сборки имеется (создаётся) некий докУмент или ряд докУментов, которые привязываются к соответствующим элементам ЭСИ. Все эти модели, элементы ЭСИ, документы (чертежи, спецификации, протоколы, расчёты, служебки и т.д.) в свою очередь потребуются различныи подразделениям и деятелям, которые будут использовать их в своей работе.

3. САПР это инструмент, а ЭЦМ делают люди. Вот ЭСИ может получиться автоматом с правильно построенного ЭЦМ. CAD при этом может быть практически любым.

[AnTe 1]

Просто колесо - это входящая ДСЕ в изделии мост.

Подпись можно ставить и на то и на то, если ЭСИ - это БД в соответствующей структуре, привязка подписи к обозначению.

Подпись ставится на документе. Но документ просто обязан иметь реквизитную часть...:(

База единая, каких - два документа

А как же тогда подписывать отдельно колесо, отдельно мост, ..?

[AnTe 1]

1. ЭЦМ это электронно-цифровой макет изделия, то есть построеная средствами действующего на головном предприятии CAD трёхмерная модель изделия. для ЭЦМ подразумевается детализация до уровня отражения в спецификации и придание каждому из компонентов сборки соответствующих свойств: геометрии, плотности, прочности и чего ещё только позволит применяемый софт.

Мне кажется, что это всё больше напоминает теорию :(

А вот что на практике:

Можете считать, что ЭЦМ=ЭМИ, если угодно.

Вот какая математика получается: в предыдущих постах фактически поставили равенство, ЭСИ = ЭЦМ. Скомпоновав его с последним равенством, получим. ЭСИ=ЭЦМ=ЭМИ, т.о. ЭСИ=ЭМИ, в свете чего, п 2.2. ГОСТ 2.102, выглядит немного несуразно:

За основные конструкторские документы принимают:

для деталей - чертёж детали, и (или) ЭМИ

для сборочных единиц, комплексов и комплектов - спецификацию, и (или) ЭСИ

Конечно, после отказа от определений "сборка" и "деталь", используя обобщающую "ДСЕ", вроде всё становится ясным, но, по-моему, проблема глубже:

ЭМИ, по определению, это, грубо говоря, геометрическая часть, ЭСИ - перечень.

Конструктор создал модель на сборку АБВГ.01.02.030, в неё входит ряд моделей подсборок, деталей, покупных элементов, материалов и стандартных изделий, сама она входит в некую сборку высшего уровня. Всё это отображается в ЭСИ. На каждый из компонентов этой сборки имеется (создаётся) некий докУмент или ряд докУментов, которые привязываются к соответствующим элементам ЭСИ. Все эти модели, элементы ЭСИ, документы (чертежи, спецификации, протоколы, расчёты, служебки и т.д.) в свою очередь потребуются различныи подразделениям и деятелям, которые будут использовать их в своей работе.

И всё это называется ОБДИ, или даже "система документооборота". При её создании необходимо определить упомянутые докУменты, которые будут использоваться, схему их хранения, доступы к ним., и пр.

А, в разговорах об ЭСИ, ЭМИ и пр. - мы, как раз обсуждаем эти докУменты, которые в системе документооборота будут функционировать.

3. САПР это инструмент, а ЭЦМ делают люди. Вот ЭСИ может получиться автоматом с правильно построенного ЭЦМ. CAD при этом может быть практически любым.

Возьмём Catia, в ней Product-Product-..-Part. Головная сборка, типа Product содержит подсборки, так вплоть до деталей. Это и представляет собой ЭМИ. Полноценную ЭСИ с неё, даже с условием обязательного заполнения доп. полей, получить проблематично. А для того, чтобы саму модель получить автоматом с правильно построенного ЭЦМ, - для этого этот правильно построенный ЭЦМ нужно где-то взять, создать. А где? Как?

Заполнить сначала ЭСИ, затем с неё получить ЭМИ? Или в ЭМИ наброски накидать, с неё - ЭСИ? Или одновременно, (синхронизация), разрабатывается ЭСИ и ЭМИ, при этом есть возможность проводить постоянную синхронизацию, мониторинг соответствия?

Изменено 18 июня 2008 пользователем AnTe

[AnTe 1]

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

То есть, после щенячьей радости от того, что на экране, как это всё наглядно и удобно, появляется жестокая реальность в главном вопросе "а что же (и как?!) здесь будем подписывать?".

Если нечётко ответить на этот вопрос, то сразу возникает шквал ещё не менее суровых вопросов в форме

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

Поэтому вопрос я и пытаюсь найти, как можно более чётче сформулировать ответ, на главный вопрос :(