Объединение чертежа и модели

[Владимир Владимирович]

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

P.S. Ничего личного

[Жень-Шень:)]

Идея объединения чертежа и модели в одном файле имеет рациональное зерно с точки зрения документооборота, но если посмотреть с другой стороны, то при достижении, к примеру, объема файла 3D сборки нескольких Мегабайт и + к этому добавить объем 2D чертежа, работа с таким файлом в плане скорости будет очень проблематичной.

[Yurok]

Давайте спросим тех кто уже работает по такому принципу. Может коллеги имеющие опыт работы с Tflex лучше осветят этот вопрос?У них помоему есть возможность все хранить в одном файле.

[chelkar]

А может в UG у кого-то есть опыт? Как оно, когда все в одном файле, от модели до ЧПУ?

[Sinus]

Идея объединения чертежа и модели в одном файле имеет рациональное зерно с точки зрения документооборота, но если посмотреть с другой стороны, то при достижении, к примеру, объема файла 3D сборки нескольких Мегабайт и + к этому добавить объем 2D чертежа, работа с таким файлом в плане скорости будет очень проблематичной.

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

[Sinus]

Похоже рядом обсуждаются 2 схожие темы.

ну так подход должен быть один!!! а то - если так, а если эдак... как говорит В.С. Черномырдина "где достал там и чешет" 

и потом - все в мире несовершенно. меня в пот бросает от мысли что не дай бог повреждение файла и у меня пропадет не одна деталь (или ее чертеж) а все добро одним махом

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

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

[Фанат Компаса]

А с автоматической спецификацией (созданием объектов спецификации в дет. и сборках) лучше вообще не работать по крайней мере до V9(в ней говорят что-то улучшилось) теоретически функция вроде удобная, но практически - жуть, нахлебались!

А какие еще бывают спецификации кроме автоматических? Уточните если не трудно, просто чтобы на одном языке объясняться?

[Фанат Компаса]

Похоже рядом обсуждаются 2 схожие темы.

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

ну так подход должен быть один!!! а то - если так, а если эдак... как говорит В.С. Черномырдина "где достал там и чешет" 

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

и потом - все в мире несовершенно. меня в пот бросает от мысли что не дай бог повреждение файла и у меня пропадет не одна деталь (или ее чертеж) а все добро одним махом

это один из доводов объединить ВСЕ в один файл, все равно при сохранении сборки сохраняются входящие в нее детали, а вот путаницы меньше будет. А так получается после сбоя открываешь сборку, в одних деталях проведены изменения в других нет, в сборке понятно модель последствий ядерного взрыва, что откуда восстанавливать непонятно, проще все из bak'ов восстановить. Или иногда бывает в сборке уже исправленная деталь, а в окне детали старая версия и как сохранить нужную поди-догадайся. Хотя, если подумать, объединение модели и чертежа, скорее дело вкуса, стиля работы и производительности машины,т.к. при правильном стиле работы можно поддерживать порядок и в большом количестве файлов, просто неудобно это, много лишних операций.

[DGroot]

Очевидно к обсуждаемой здесь теме имеют непосрественное отношение изменения №8 стандарта ГОСТ 2.102 и № 1 ГОСТ 2.106.

Например из изменения №8 стандарта ГОСТ 2.102

Примечания:
1. Если электронная модель изделия (детали, сборочной единицы) однозначно определяет все
необходимые для соответствующего вида документа данные, то ей присваивают код документа согласно таблице 3.
2. Если необходимо совместное использование электронной модели изделия (детали, сборочной
единицы) и чертежа, то чертежу присваивают код документа согласно таблице 3, а электронной модели изделия присваивается соответственно код "МД" или "МС"....."

Из изменения №1 стандарта ГОСТ 2.106

Совмещение спецификации с электронной моделью не допускается

Меня интересуют отклики на изменения к указанным Выше ГОСТам и способы реализации изложенных в этих изменениях требований.
Один из методов реализации я васказал по http://forum.ascon.ru/index.php/topic,8578.0.html

[Фанат Компаса]

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

[DGroot]

Фанат Компаса - значит конструктор - человек который должен понимать, что в документообороте  участвуют не столько программно связанные файлы, сколько логически (информационно) связанные различные документы, описывающие техпроцессы изготовления изделия. При этом эти документы должны индивидуально корректироваться по извещениям. Вот с этих позиций я и пытаюсь расматривать ситуацию, сложившуюся в 3-х мерном моделировании  и связанном с ним документообороте, вследствии последних изменений в ГОСТах на ЕСКД и появления  ГОСТ 2.051 - ГОСТ 2.053.
Кстате загляни сюда
http://forum.ascon.ru/index.php/topic,8646.new.html#new

[DGroot]

Marianna (предшествующее сообщение см. http://forum.ascon.ru/index.php/topic,8578.msg45404.html)

Насчет ссылки ГОСТ говорит

Прошу указать какой ГОСТ  и лучше цитатой из него.

Marianna, Вы сами себе противоречите, утверждая, с одной стороны, что некий ГОСТ требует присутствия в документе (чертеж детали) ссылки на другой документ (модель детали), и тут же
говорите о том, чо это неверно. (Я, ссылаясь на ГОСТ 2.102, лишь указал на то, что его содержание
подводит нас к необходимости привести на поле чертежа ссылку).
Очевидно, тем самым, Вы пытаетесь подвергнуть сомненение требование ГОСТа. Это Ваше право.
Вы утверждете, что правильнее в ссылке, в чертеже детали, указывать не на обозначение модели, как документа (АБВГ.123456.789МД), а имя файла содержащего этот документ. Позвольте не согласиться с Вами.
Во первых, только обозначение документа является тем атрибутом, который однозначно определяет документ в объеме архива (будь он бумажный или электронный - это неважно).
Во вторых, наилучший способ наименования файлов с документами - это имя жестко
ассоциированное с обозначением документа.
Например для сборочного чертежа, имеющего обозначение АБВГ.123456.789СБ имя  файла  должно
быть ABVG#123456#789SB.drw.
Дополнительными атрибутами в имени файла должны быть порядковый номер файла в перечне файлов, содержащих документ и номер изменения данного документа. Таким образом окончательно имеем
ABVG#123456#789SB_1_0.drw.
ABVG#123456#789SB_2_0.drw.
где _1 - порядковый номер файла в перечне файлов
      _0 - номер изменения данного документа.
Такое правило присвоения имен файлам позволяет создать электронный архив с помощью распределения файлов по соотвтствующим папкам (не нужна даже специализированная PDM
система). Подобную практику мы ввели ровно 10 лет тому назад и с успехом ее использовали до
настоящего времени, пока не появилась возможность приобрести полноценную систему PDM.
Но даже в ней мы посчитали целесообразным сохранить такой принцип наименования файлов. Это
позволяет не вводить дополнительных ссылок в виде имен файлов ни в спецификации, ни в любые другие документы.
Marianna, Вы утверждаете, и с этим нельзя не соласиться, что САПР в котором осуществляется проектирование модели и построение чертежа осуществляет связь с чертежом через системную
область файла, содержащего модель. Это позволяет обеспечить ассоциативность модели и четрежа.
Как в рамках САПР, так и в PDM системе. Тем самым Вы ставите по сомнение необходимость присутствия ссылки на модель на поле чертежа.
Но позвольте. Во первых, в производстве технолог или рабочий держит в руках чертеж на бумаге и
если в чертеже не будет ссылки на модель, то откуда они будут знать о ее наличии. В реальном
процессе проектирования используется разноуровневые САПРы типа Pro/E и AutoCAD, и далеко не
все изделия (детали) требуют их проектирования в САПРах высокого уровня, а значит на чертеже
детали , спроектированном в AutoCAD ссылки на модель может не быть по причине ее отсутствия модели. К этому можно добавить, чо большенство САПРов высокого уровня постоены таким
образом, что в необходимых случаях не требуют обязательной разработки 3-х мерной модели с
последующей генерацией чертежа, а допускают его создание без разработки модели.
Например при проектировании деревянной тары из брусков врядли Вы будете ее разрабатывать в
виде 3-х мерной модели т.к. иначе Вам потребуется создавать чертеж бруска-детали. В то время кк
он "выпиливается" в соответствии с указанием, приведенным в спецификации в разделе Материалы.

Что касается контроля изменений
Я полностью разделяю Ваше мнение по поводу Вашей цитаты

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

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

Что значит

.........документ - модель должен быт указан в извещении явно .........

Т.е. Вы согласны, что модель должна иметь свое собственное обозначение - АБВГ.123456.789МД,
отличное от обозначения чертежа детали.

.........у изменного электронного документа появится новая версия (в бумажном - литера)........

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

[Marianna]

Уважаемый DGroot

Все рекомендации ,что я описывала, даны для организации управления электронным инженерным  документооборотом с ПРИМЕНЕНИЕМ PDM.
Вы пишете что 10 лет занимались практикой хранения документов в файловом хранилище (по папкам), возможно проще оказалось наследовать в ПДМ исторически устоявшиеся принципы. Я же стараюсь донести ло пользователей современные методические подходы при создании системы управления инженерными документами с использованием ПДМ.
Далее попытаюсь разъяснить моменты, которые вызвали у вас вопросы по моему предыдущему посту

Marianna (предшествующее сообщение см. http://forum.ascon.ru/index.php/topic,8578.msg45404.html)
Прошу указать какой ГОСТ  и лучше цитатой из него...

Вы сами себе противоречите, утверждая, с одной стороны, что некий ГОСТ требует присутствия в документе (чертеж детали) ссылки на другой документ (модель детали), и тут же
говорите о том, чо это неверно. (Я, ссылаясь на ГОСТ 2.102, лишь указал на то, что его содержание
подводит нас к необходимости привести на поле чертежа ссылку).
Очевидно, тем самым, Вы пытаетесь подвергнуть сомненение требование ГОСТа. Это Ваше право.

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

Неверна ваша интерепретация ГОСТа на требование ссылок электронного документа модель (в бумажном представлении он не существует) на бумажный документ чертеж. Как вы видите из цитаты, ГОСТ требует ссылки на документы преобразованные друг в друга(Например, электронный докумет чертеж детали (векторный оригинал) ->бумажный документ чертеж детали (подлинник))
Говоря о внешних ссылках, я вела речь только об ЭЛЕКТРОННЫХ документах!! а они ссылаются друг на друга автоматически (внешние ссылки пишутся средствами САПР).

Вы утверждете, что правильнее в ссылке, в чертеже детали, указывать не на обозначение модели, как документа (АБВГ.123456.789МД), а имя файла содержащего этот документ. Позвольте не согласиться с Вами.
Во первых, только обозначение документа является тем атрибутом, который однозначно определяет документ в объеме архива (будь он бумажный или электронный - это неважно).
Во вторых, наилучший способ наименования файлов с документами - это имя жестко
ассоциированное с обозначением документа.
Например для сборочного чертежа, имеющего обозначение АБВГ.123456.789СБ имя  файла  должно
быть ABVG#123456#789SB.drw.
Дополнительными атрибутами в имени файла должны быть порядковый номер файла в перечне файлов, содержащих документ и номер изменения данного документа. Таким образом окончательно имеем
ABVG#123456#789SB_1_0.drw.
ABVG#123456#789SB_2_0.drw.
где _1 - порядковый номер файла в перечне файлов
      _0 - номер изменения данного документа.
Такое правило присвоения имен файлам позволяет создать электронный архив с помощью распределения файлов по соотвтствующим папкам (не нужна даже специализированная PDM
система). Подобную практику мы ввели ровно 10 лет тому назад и с успехом ее использовали до
настоящего времени, пока не появилась возможность приобрести полноценную систему PDM.
Но даже в ней мы посчитали целесообразным сохранить такой принцип наименования файлов. Это
позволяет не вводить дополнительных ссылок в виде имен файлов ни в спецификации, ни в любые другие документы.

                   НИ В КОЕМ СЛУЧАЕ не стоит менять ИМЕНА файлов!!! Это стандартная ошибка всех кто переходит с файлового хранения на хранение в ПДМ!
Объясню:
1. Принимаем, что имя файла однозначно соответствует имени документа. Рекомендуется максимально использовать возможности САПР, и не использовать необрабатываемые спецсимволы,как показано в примере. Скорее всего в том архиве использовалалсь закладка в ахив документов архивариусом с переименованием. При использовании ПДМ, интегрированой с САПР, закладка файла может осуществляться разработчиком на самой ранней стадии разработки. Поэтому пусть все делается автоматически нажал "сохранить " в САПР, файл сохранился прямо в ПДМ.
2.Ни в коем случае НЕЛЬЗЯ в имени файла указывать номер изменения!! ИМЯ файла не должно меняться никогда.
Во-первых, изменения документов в ПДМ поддерживаются совершенно иначе - механизмом версионности;
во-вторых, если вы изменили имя файла, входящее по внешеней ссылке в другой файл (например чертеж детали, а по ссылке этот файл связан с документом спецификация, который не меняется), то у вас все эти ссылки нарушаться и при открытиии документа в САПР комплект (сборка)  рассыплется. Именно такие примеры были приведены выше в данном топике.
3. порядковый номер файла мы разрешаем ставить только для листов сканированного документа. ,т.е. где внешние ссылки друг на друга отсутствуют как понятие.
4. вывод имени файла  на бумажном чертеже несет еще и проверочную нарузку статуса. Если там выведен полный путь "ресурса архива", то документ распечатан из архива - можно верить 100%, а если "мои документы/Сидоров/мой проект.." - то совсем другое отношение к этой бумаге - и неизвестно идентично ли это тому что сдано в архив.

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

При наличии ПДМ (архив+ инженерный документооборот) предполагается, что ВСЕ пользователи инженерной документации имеют возможность работы с системой в различных режимах. Автоматизировать только работу архивариуса, как Вы понимаете, на современном этапе экономически не выгодно.
Таким образом информация о наличии нового чертежа, техпроцесса, программы для ЧПУ, появится в системе, а значит дойдет до пользователя, в режиме оповещения об изменении или рассылке документа РАНЬШЕ, чем он получит бумажный чертеж. Как правило, в инструкциях мы пишем: "если вам пришел бумажный документ - проверьте его регистрацию в системе и статус в котором он находится". Еще вариант: задание исполнителю приходит по почте с уже прикрепленной ссылкой на документ в ПДМ системе.

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

Несомненно данное правило лежит в организационной плоскости. Будем считать это вырожденым случаем. 
Хотя если изменилась модель детали , то документ "Программа для станка с ЧПУ" тоже может измениться
А при изменении технологии выпускается новая версия технологического документа. Связь технологических документов и констукторских в ПДМ системе, а также отслеживание их изменений  - это наверно тема отдельного разговора.

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

.........  Т.е. Вы согласны, что модель должна иметь свое собственное обозначение - АБВГ.123456.789МД, отличное от обозначения чертежа детали.

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


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

[DGroot]

Уважаемая Marianna
Перевел диалог как Вы и просили на http://forum.ascon.ru/index.php/topic,8699.0.html

[Sinus]

Предложение старое. Хочется возродить его к жизни. Данной темы не нашел.

Предлагаю сделать 3D модель и чертеж в одном файле.

Это предложение перекрывает кучу мелких предложений:
- Синхронизация не нужна все в одном файле
- Поиск чертежа модели не нужен
- Проблема как назвать модель, а как чертеж отпадает, есть единое имя
- Сократиться количество файлов удобно (для поиска)
- Подключать к спецификации надо меньшее количество файлов в два раза!
- Утверждать начальством и чертеж и модель сразу (и электронно подписывать тоже при желании или возможности)
- Быстрое переключение с работы с чертежом на модель и обратно
-Технические требования и неуказанная шероховатость окажутся и в 3D тоже.


Возможные минусы с их разоблачением:
- Увеличение времени открытия файлов (спорно, возможно время уменьшится синхронизация ведь не нужна между 3D и чертежом)
- Увеличится объем файлов (дискетами ведь пользуемся, правда? Так что тоже не проблема).
- Если вылетит компас, то потеряется и чертеж и модель! (а если завтра конец света?)
- Займем все память компьютера! У меня и так все тормозит. (не аргумент, смените офисный компьютер на графическую станцию!)

[dersuyzala]

Опередили Вы меня, я сам хотел такую тему создать.
Я ЗА и руками и ногами. Не нахожу ни одного аргумента против.

[Андрей Владимирович]

+1

[Starik]

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

[Urik]

Предложение старое. Хочется возродить его к жизни. Данной темы не нашел...

-1
Это было гораздо лучше. И вашим, и нашим, так сказать.
http://forum.ascon.ru/index.php/topic,8584.msg45459.html#msg45459
А еще неплохо бы учитывать и такие трудности:
http://forum.ascon.ru/index.php/topic,9336.msg50076.html#msg50076

[dersuyzala]

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

И что мешает?

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

Способов немеренно.
1. PDF.
2. Ни кто не говорит отменять файлы чертежей. Просто должна быть возможность создать чертёж в одном файле с моделью. Ну и конечно возможность выгрузить чертёж в отдельный файл.
3. А как Вы покажете заказчику чертёж без модели? Будете разрушать виды?