134 сообщения в этой теме

ID: 1   Опубликовано: (изменено)

По ГОСТ 2.053, ЭСИ - это "Конструкторский документ, содержащий состав сборочной единицы, комплекса или комплекта и иерархические отношения (связи) между его составными частями и другие данные в зависимости от его назначения."

ДЭ (Документ Электронный), по ГОСТ 2.051 - это "Документ, выполненный как структурированный набор данных, создаваемых программно-техническим средством."

По ГОСТам конструкторских документов, каждый документ должен быть завизирован кучей подписей, например, обязательны - разработчик и н.контр.

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

Может, кто-нибудь использовал ЭСИ, как ДОКУМЕНТ, а не как 'удобную' базу данных? Или, хотя бы имеет представление о том, как это сделать?

Лично у меня постоянно возникают какие-то сложности. Убился ГОСТы читать, не нахожу ответов на многие вопросы. Вот, например:

1. ЭСИ на нулевую сборку (автомобиль), и на подсборку (мост) - это два разных документа? т.е. Существует "ЭСИ на автомобиль" и "ЭСИ на мост автомобиля"? Или ЭСИ существует только для всего изделия? В таком случае, сколько же подписей должно стоять в его реквизитной части?

2. Как сохраняется конкретная версия документа? Всю БД слить на диск (скопировать в другое место)? Либо ГОСТ позволяет, чтобы используемая компьютерная система динамически строила ЭСИ, каждый раз, в зависимости от запроса "версии"?

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах


ID: 2   Опубликовано: (изменено)

Попытаюсь отчасти сам ответить на свои же поставленные вопросы. Вот, что нашёл в ГОСТ 2.051, про Документы Электронные (ИЕ = "Информационные Единицы"):

4.5 ДЭ подразделяют на простые, составные и агрегированные в зависимости от состава и способа

организации содержательной части:

- в простом ДЭ содержательная часть реализована в виде одной ИЕ;

- в составном ДЭ содержательная часть реализована в виде нескольких ИЕ, связанных друг с дру-

гом ссылками, как правило, определяемыми применяемым форматом данных;

- в агрегированном ДЭ содержательная часть реализована в виде нескольких ИЕ, информационно

связанных друг с другом;

4.6 ИЕ в ДЭ могут образовывать сложные иерархические структуры, имеющие совмещенные рекви-

зитные части и общие описания составляющих компонентов. При многократном использовании компонен-

тов допускается применение ссылок*.

Да, в комментарии к пункту сказано, что "активные ссылки" зачем-то должны быть организованы по какому-то ИСО 8879, похоже это SGML, в общем, что-то вроде более известного XML. Зачем - непонятно. Ну да ладно, похоже, что это частности.

В следующем пункте запрещают, и одновременно разрешают применение ссылок в утверждённом документе:

4.7 Если в документе используются ссылки, то при выпуске документа все ссылки должны быть

заменены на соответствующее им содержание. В составном и агрегированном документах, если его фор-

мат требует наличия ссылок, допускается оставлять ссылки при условии, что целостность таких ДЭ обес-

печивают программно-технические средства*.

Пытаемся переложить на практику.

Положим, у нас есть файлы, т.е. ИЕ, лежащие в одной папке :) каждый файл-ИЕ содержит полный состав этой ИЕ, == ссылки на другие файлы-ИЕ, а так же необходимую дополнительную информацию для ИЕ.

таким образом, получаем, что за ЭСИ, скажем, "автомобиля" можно взять весь этот набор файлов, указав "стартовую" ИЕ, которая в базе под номером 0000. За ЭСИ "моста" - ИЕ моста, и все файлы, участвующие при построении дерева программными средствами....

Вот и ответ на первый вопрос.

Ответ на второй вопрос - сохранив где-нибудь эту кучу файлов, определив доступ к ним, - автоматически сохраняем все участвующие в процессе документы-ЭСИ.

Единственное сомнение пока вызывает переход к базе данных. База данных обычно основана не на файловой системе, т.о., можно сказать, что вся куча файлов-ИЕ находятся в одном файле. Но в том же ГОСТ 2.051 прописано, что

3.1.8 информационная единица: Файл или набор файлов, рассматриваемый как единое целое.

То есть, если понять под словом "файл" привычные нам файлы в привычных:) операционных системах, то вроде как ИС формально не может быть частью файла базы данных.

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

То же сомнение про запросы к БД: может ли результат запроса к БД быть документом? Опять же, по упомянутому выше п 4.7, если БД обеспечивает целостность, что является необходимым условием разработки БД, - то может!

поправьте меня, если я где-то ошибся в рассуждениях

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

или всё остаётся на уровне "удобная база данных, для всех"?

буду признателен за любые ответы по этой теме!

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Мне кажется, что нужно идти от назначения и понятий: что такое документ и что такое ГОСТ?

Документ - информация, оформленная по неким правилам, обязательно содержащая реквизитную часть. Так как отчет из БД не содержит в себе реквизитов - то сам по себе документом не является.

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

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

Касательно вложенности ЭСИ - она ГОСТом неограничена, это только вопрос удобства (как я понимаю). Аналогично, ГОСТ на спецификацию допаскает раскрытие в одном документе состав подсборок. Вот и все.

Насколько же ГОСТ удобен - это совсем другой вопрос. Просто сейчас так, другого нету.

С другой стороны - стимул предприятиям разрабатывать свои стандарты и зарабатывать на продаже лицензий за их использование другими. По крайней мере мировое сообщество именно по такому пути двигается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В самом деле этот топик фактически можно назвать так:

"Вы используете PDM?"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Да мы ЭСИ создаем, как конструкторский документ, с момента внедрения PLM Windchill. Однако создавать и использовать это две разные вещи, особенно имея в виду понятие - база данных.

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

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

Внедрение АСУпр позволило автоматизированно осуществлять подготовку производства изделий.

В настоящее время, проводятся работы по переводу этой базы данных под Windchill. Т.е АСУпр и Windchill становятся компанентами единой информационной сиситемы предприятия.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

или всё остаётся на уровне "удобная база данных, для всех"?

буду признателен за любые ответы по этой теме!

Во-первых, на вопрос, поставленный в предыдущей теме. СБ-по ЕСКД так сокращенно обозначается сборочный чертеж. Что программистам легко реализовать связь позиционных обозначений сборки с ЭСИ (как сказал, кажется, Странник), далеко не факт. Ведь позиционные обозначения на СБ появляются раньше спецификации, но увязываются с ней (например, могут корректироваться из-за расположения в спецификации). Как это обеспечить в случае замены спецификации ЭСИ? ЭСИ строится на основе САПРовской модели изделия в PDM-системе. СБ получается независимо от PDM.

По поводу трактовки ГОСТов. Любой закон в любой стране можно трактовать по-разному. На этом строится вся система юриспруденции. ГОСТ это почти закон. Кстати, из-за этого "почти" его получается трактовать гораздо шире, чем любой закон. Но для законов разрабатываются сложные механизмы внедрения (использую технический термин), контроля, арбитража, наказания за нарушение и т.д. Для ГОСТов ничего этого сейчас нет. Отсюда масса недоработок в самих стандартах, сложности в их использовании и т.п. Поэтому мое мнение такое - использовать ГОСТы надо (потому что нужен общий язык), но творчески, брать от них то, что устраивает и развивать в своих СТП (СТО). Конечно, если заказчик не требует точного соблюдения. Но пока, из моего опыта, ПЗ (ВП) сами не понимают с какого конца подступиться к ГОСТам про электронные документы и, в частности, про ЭСИ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ЭСИ строится на основе САПРовской модели изделия в PDM-системе.

С этим можно отчасти поспорить.

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

СБ получается независимо от PDM.

Если уж ЭСИ строится на основе сапровской модели, то и СБ строят на основе тойже модели, а электронная модель в этом случае должна быть зависима от PDM.

А вот если СБ строится сам по себе (без модели), то ЭСИ придется набивать ручками, опираясь на данные базы данных компонентов и PDM.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Совершенно согласен, что не только по модели. Более того, у нас структуры изделий (намеренно избегаю сочетания ЭСИ, поскольку это уже считаем документом) строятся совершенно независимо. Хотя есть SW, PDM-W. А структура строится "ручками", дублируется, естественно с ошибками :sad: . Это совершенно недопустимо, но пока так :wallbash: . Пэтому я сделал акцент на последовательности САПР-модель, PDM, ЭСИ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ID: 9   Опубликовано: (изменено)

Документ - информация, оформленная по неким правилам, обязательно содержащая реквизитную часть. Так как отчет из БД не содержит в себе реквизитов - то сам по себе документом не является.

Кто ж сказал, что не содержит? Просто, акцентируя внимание на содержательную часть, про реквизитную, как вроде мелочь на фоне проблем с содержательной, я умолчал:)

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

Что такое ГОСТ - стандарт, то есть правила.

..

Кстати, спасибо за рассуждения о сути ГОСТов, в голове что-то подобное было, в виде каши, а тут всё уложено, по полочкам:)

Наше предприятие интенсивно работает с различными заказчиками, смежниками, поэтому, вероятно, разумнее подойти к ГОСТам как можно ближе сразу, чем "дорабатывать напильником" потом.

С использованием ЭСИ не как документа дело тоже труба. Найдутся такие, которые не будут заполнять, или, что хуже, будут заполнять её не верно, т.к. "зарплату я получаю за выпущенный документ"

Касательно вложенности ЭСИ - она ГОСТом неограничена, это только вопрос удобства (как я понимаю). Аналогично, ГОСТ на спецификацию допаскает раскрытие в одном документе состав подсборок. Вот и все.

Тут дело ещё круче! Как следует из определения, ЭСИ непременно должна содержать "иерархические отношения (связи) между его составными частями", т.е. если вложенность ограничить, то, скажем, где в ЭСИ на автомобиль связь между колесом и гайкой? В ЭСИ должно содержаться ВСЁ!

Появляются всё те же проблемы с изменениями, обозначенными Странником в соответствующем треде: если гайку заменили - изменены не только ЭСИ колеса, но и ЭСИ моста, ЭСИ самого автомобиля! Всё заново переутверждать. :wallbash:

Во-первых, на вопрос, поставленный в предыдущей теме. СБ-по ЕСКД так сокращенно обозначается сборочный чертеж. Что программистам легко реализовать связь позиционных обозначений сборки с ЭСИ (как сказал, кажется, Странник), далеко не факт. Ведь позиционные обозначения на СБ появляются раньше спецификации, но увязываются с ней (например, могут корректироваться из-за расположения в спецификации). Как это обеспечить в случае замены спецификации ЭСИ? ЭСИ строится на основе САПРовской модели изделия в PDM-системе. СБ получается независимо от PDM.

Да, на счёт "простоты" впорос ещё тот. Позиции придётся добавлять вручную. А ведь сейчас множество средств, вроде автокадовского Mechanics, или в компасе, спецификации с позициями получаются автоматом. Вот блин предложи такую полуатоматизированную систему получения спецификций с ЭСИ.. столько воплей будет, что "работать мешаете":) Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не пойму, а что мешает получать (не вручную) ЭСИ на основе спецификации, которую конструктор все равно делает (хоть почти и автоматом)?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не пойму, а что мешает получать (не вручную) ЭСИ на основе спецификации, которую конструктор все равно делает (хоть почти и автоматом)?

О! это подход с другой стороны :) вообще говоря, с этой стороны я и подходил изначально. Проблема заключается в том, что спецификации получают в разных средах, в разных форматах (вплоть до того, что кто-то вбивает буквы в шаблонах word или excel), для того, чтобы получать информацию со спецификации, необходимо, чтобы вид был един. Сейчас в pdm если и кладут спецификации, то строго в pdf

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

Или хотя бы с учетом ее (если кому нужны позиции).

Угу, надо будет подобное реализовывать, но это уже вопрос реализации, пожалуй.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Ну если систем несколько, то не родной для ПДМ системы действительно. Можно принять единый стандарт, конвертировать спецификации в тот же Exsel, откуда можно уже поднять.

Этот вывод основан на том, что при разработке СП, необходимо указывать как минимум обозначение-наименование, эти обозначения-наименования будут повторяться из сборки в сборку, зачем по десять раз набирать одно и то же? т.е. получится тот же редактор, только в профиль, да ещё плюс единая база используемых изделий

Не понял? Ведь специя получается автоматом, за исключением моментов оформительного характера. А Наименование - Обозначение вводится (должно) только один раз при создании модели.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну если систем несколько, то не родной для ПДМ системы действительно. Можно принять единый стандарт, конвертировать спецификации в тот же Exsel, откуда можно уже поднять.

Из Excel? Сложновато будет. У нас сейчас примерно такая схема и работает. Сидит целая комната девочек, которые ВРУЧНУЮ забивают данные из спецификаций, к-ые к ним приносят в бумажном виде, чтобы заполнить базу в отделе планирования....

Не понял? Ведь специя получается автоматом, за исключением моментов оформительного характера. А Наименование - Обозначение вводится (должно) только один раз при создании модели.

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

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

Да, получается, если не принять за основу ЭСИ - нужно создать: 1. редактор спецификации 2.конвертер спецификация-ЭСИ, с контролем возможных ошибок, и пр.

А если принять ЭСИ за основу - то нужно только программу для получения отчётов в форме СП.

Вообще, как понимаю, переформулировать вопрос можно следующим образом: откуда получать спецификацию, из ЭСИ или ЭМИ (Электронная Модель Изделия). По смыслу мне кажется, что СП получать однозначно из ЭСИ. т.е. из ЭМИ получить ЭСИ, а из ЭСИ уже СП :rule::flush:

ps мда, по идее, это для темы "спецификация", но, с другой стороны, по всей видимости, "спецификация" и "ЭСИ" можно хоть объединять :doh:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто ж сказал, что не содержит? Просто, акцентируя внимание на содержательную часть, про реквизитную, как вроде мелочь на фоне проблем с содержательной, я умолчал:)

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

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

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

Наше предприятие интенсивно работает с различными заказчиками, смежниками, поэтому, вероятно, разумнее подойти к ГОСТам как можно ближе сразу, чем "дорабатывать напильником" потом.

Если "напильником" - то наверное да, лучше сразу по ГОСТам. А вот если "не напильником", а по удобной отработанной технологии с малой трудоемкостью, то вряд ли сразу по ГОСТ - разумно.

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

С использованием ЭСИ не как документа дело тоже труба. Найдутся такие, которые не будут заполнять, или, что хуже, будут заполнять её не верно, т.к. "зарплату я получаю за выпущенный документ"

Тут дело ещё круче! Как следует из определения, ЭСИ непременно должна содержать "иерархические отношения (связи) между его составными частями", т.е. если вложенность ограничить, то, скажем, где в ЭСИ на автомобиль связь между колесом и гайкой? В ЭСИ должно содержаться ВСЁ!

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

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

Появляются всё те же проблемы с изменениями, обозначенными Странником в соответствующем треде: если гайку заменили - изменены не только ЭСИ колеса, но и ЭСИ моста, ЭСИ самого автомобиля! Всё заново переутверждать. :wallbash:

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

А если глубже копнуть - так и спецификация, как документ, может и не нужна вовсе?

Даже в ГОСТе (не помню номер) про виды конструкторских документов указано, что если есть электронная медель детали, чертеж на нее не является обязательным, а если есть ЭСИ, то не обязательна спецификация (в комплекте документов по ЕСКД). И наоборот.

А вот нужно ли это в каждом конкретном случае - см. договор с заказчиком. Если в договоре ни слова - то на усмотрение исполнителя (опять цитата из ГОСТ).

Другое дело, что при составлении договоров по привычке пишут "документация должна быть выполнена по ЕСКД", не принято как-то уточнять состав документации. Поэтому чтобы не нарываться на пустые конфликты, целесообразно уточнить требования у заказчика. И лучше в официальной переписке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из Excel? Сложновато будет. У нас сейчас примерно такая схема и работает. Сидит целая комната девочек, которые ВРУЧНУЮ забивают данные из спецификаций, к-ые к ним приносят в бумажном виде, чтобы заполнить базу в отделе планирования....

А сохранить электрнную спецификацию в промежуточный формат, который понимает ПДМ, уже трудно?

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

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

Второе вообще не понял. обозначение-наименование вводится только один раз.

1. редактор спецификации 2.конвертер спецификация-ЭСИ, с контролем возможных ошибок, и пр.

Все это уже есть в системе CAD, да и конвентер нужен только в случае если ПДМ система не может поднять нужные данный из не родной для нее системы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Даже в ГОСТе (не помню номер) про виды конструкторских документов указано, что если есть электронная медель детали, чертеж на нее не является обязательным, а если есть ЭСИ, то не обязательна спецификация (в комплекте документов по ЕСКД). И наоборот.

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

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

- автоматизация оформления КД;

- автоматизация подготовки производства.

Таким образом мы получаем три обязательных конструкторских документа: чертеж детали, СП и ЭСИ :g:

Остается решить ряд вопросов:

1 Согласно ГОСТ 2.102 ЭСИ есть конструкторский документ, а коли так эначит должен иметь свой КОД документа, однако согласно таблицы 3 его нет (значит обозначение ЭСИ такое же как у СП), но согласно табицы 4 ЭСИ имеет дополнительный код "ЭС", который должен быть указан в реквизитной части документа (т.е. согласно ГОСТ 2.051-2006 присваивая обозначеие ЭСИ в системе PDM я должен вместо УЖАС.123456.789 указать УЖАС.123456.789ЭС ??).

2 Должен ли конструктор, оформляя СП на изделие, с момента разработки ЭСИ, вводить ее обозначение и наименование в СП в раздел Документация? (непонятно как работает "дополнителный код")

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

3 Как корретировать ЭСИ (через извещение? - абонет который использует данные ЭСИ ведь должен получить информацию о ее замене), ведь не всякая корректировка СП может быть связана с корректировкой ЭСИ или это неотвратимо?

4 Должна ли версия СП совпадать с версией ЭСИ?

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

Возможно ответ на поставленные вопросы лежит в процессе оформления ведомость электронных документов. :g:

Изменено пользователем DGroot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Если смотреть определения ЭСИ и спецификации, а также п. 2.2 указанного стандарта, кажется, написано однозначно.

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

Это, по моему, и есть ключевой вопрос.

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

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

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

Но тенденции и темпы развития, как мне кажется, все очень скоро изменят.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В другой ветке

<noindex>http://fsapr2000.ru/index.php?showtopic=2...mp;#entry209794</noindex>

пользователь Ruslan сделал интересное заявление, близкое к тематике этого топика.

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

Когда ЭСИ уже есть, то каждый раз загружать всю модель может и не надо, но как эту структуру изначально получить?

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

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

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

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

Каким же образом можно получить ЭСИ без геометрии и не прибегая к обезьяноподобной работе операторов?

Как ни крути, а хотя бы пустые элементы (подсборки, детали и т.п.) в CAD дереве проекта расставлены быть должны.

Набить вручную спецификацию, например, посредством WORD и через какой ни будь транслятор получить ЭСИ в PDM?

Всё одно на лицо обезьянья работа и очень широкое поле для последующих неприятностей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все относительно просто и хорошо, когда процесс создания ЭСИ совпадает с моментом начала работ над совершенно новым изделием, когда все детали - новые и все проектирование осуществляется по правилам тандема CAD-PDM (Иным руководителям, принимающим решения о внедрении CAD-PDM все процессы по их внедрению видятся в радужном свете).

Все проблемы начинаются тогда, когда Вы имеете большой задел деталей на бумажном носителе или в электронном виде, но в каком-нибудь AUTOCADe, а проектирование ЭЦМ надо осуществлять в ProE. Или того хуже Вы 10 лет проектировали в ProE, сдавая в архив только "фотографии" чертежей в формате PDF, а ЭЦМ хранили локально, не имея возможности (не организовав) их хранить в файловом архиве. При этом 90% всех новых разработок базируются на ранее созданном заделе деталей (и денег на перепроектирование никто давать не торопится - попробуй объясни заказчику, что для того чтобы "жить красиво и счастливо" в PDM, тебе надо полностью перепроектировать в ProE сборку из 1000и деталей).

Отчасти нас спасает то, что большой объем СП мы создавали в программном средстве собственной разработки, в котором выходные данные представляли по сути именно ЭСИ, что позволило с некоторыми огрехами сконвертировать. при переходе в PDM. соответствующие ЭСИ, но они в ряде случаев требуют редактирования, а значит дополнительных затрат.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

В смысле?

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В смысле?

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

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

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

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

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

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

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

В смысле?

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Нужен.

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для askn

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

to Ruslan

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

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

to AnTe

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменено пользователем AnTe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!


Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.


Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу



  • Сообщения

    • ЮлияТ
      То есть экспорт в DXF "точнее" и таких проблем в общем-то не возникает? Прислушалась к Вашему совету и буду поступать именно так. По остальному - поняла и попробую.)  
    • Plumber
      В таком случае из SW сразу делаете DXF и отправляете на резку. DWGEditor не совсем родственник, это как бы за уши притянутый сосед и когда я с ним пытался работать (это было давно) мне не понравилось, сейчас ему на смену пришел DraftSight, но его я еще не щупал. Для работы с DWG/DXF предпочитаю AutoCAD, не обязательно самый последний. Это значения не имеет, можно вообще в эскизах не делать скруглений, а после вытяжки/вырезки углы обработать фичером скругление/фаска - в чертеже результат будет одинаков, а в модели править будет удобнее. Надо попробовать, если нельзя то программа сообщит о минимально возможном значении
    • ЮлияТ
      @Plumber , благодарю от всей души за обстоятельный ответ.   Может ли задание касательности на стыке дуг и прямых в эскизе вручную предотвратить разрыв контуров при экспорте в DFX или DWG? В моем случае к углам применялась команда "Инструменты эскиза" - "Скругление", а не построение с нуля с использованием прямых и дуг через три точки, поэтому вручную касательность не задавала во избежание переопределенности эскиза.  Не понимаю откуда берутся незамкнутые контуры, если "вытянутая бобышка" проходит на ура и перекладывание файлов из формата в формат (SLDPRT - SLDDRW - DWG) происходит среди "родственников" (SW-DWGEditor), а не в сторонних CADах...  Где их корежит?   Из "Справки":   Параметры экспорта файла DXF/DWG Соединение конечных точек   Включить соединение  Устраняет зазоры между конечными точками линий, если значение зазора превышает установленное.   Можно ли установить значение "0" и этим в принципе исключить вероятные проблемы с незамкнутыми контурами?       PS. Просто еще один CAD в мой комп уже не влезет - его просто разорвет от повышения внутричерепного давления, а Солид и так достаточно хорош и дружелюбен, чтобы из-за проверки его выходного файла на корректность ставить еще одного монстра... Да и файлы используются только для отправки на резку.
    • valeo-ua
      да все верно товарищ просит библиотечную деталь можно сохранить отдельным файлом модели  
    • valeo-ua
      ну да. в настройках по умолчанию включены различные автопривязки. надо их проверить - может слетели?
    • Клиент
      Русская комедия "7 дней с русской красавицей", в свое время из-под полы продавалась, богата на такого рода юмор.
    • BSV
      Требуется изготовление партии деталей гнутых из проволоки диаметром 1мм. Проволока нержавейка или пружинная. Количество первой партии 10 тыс шт.
    • Kirill_sch
      нет, в этом окне такой строки нет. Странно просто что раньше все работало. если открываю старые проекты то там все норм. Выпускаю программу там м0. Но когда делаю новый проект то вот такая хрень. пост один и тотже. Даже с твоим пробовал который ты кидал.
    • Di-mann
      Вы бы формат уточнили. Библиотека это не кучка файла всей номенклатуры метизов, метизы в виде файлов библиотечных элементов не копируются.  Вообще лучше библиотеку поставьте. 
    • Di-mann
      А разве там не листовой металл?  Вообще кидать ссылки на мебели не очень хорошо... Большинство местных их даже смотреть не будут и я в т. ч. . Архивируйте и кидайте сюда модель а не ссылку.