Перейти к публикации

ЭМД и чертёж одновременно


Рекомендованные сообщения

Что происходит, при внедрении электронных моделей изделия?

цитирую ГОСТ 2.102, из п 2.2:

...

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

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

...

Во-первых, непонятно, для чего оставлен союз "и".

Подразумевается, что в некоторых случаях деталь может иметь два основных конструкторских документа?

Тогда вопрос, что писать в разделах спецификации, где по ГОСТ 2.106 требуется запись обозначения основного конструкторского документа.

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

Может, кто сталкивался с такой ситуацией?

:wallbash:

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


Что происходит, при внедрении электронных моделей изделия?

цитирую ГОСТ 2.102, из п 2.2:

...

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

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

...

Во-первых, непонятно, для чего оставлен союз "и".

Подразумевается, что в некоторых случаях деталь может иметь два основных конструкторских документа?

Тогда вопрос, что писать в разделах спецификации, где по ГОСТ 2.106 требуется запись обозначения основного конструкторского документа.

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

Может, кто сталкивался с такой ситуацией?

:wallbash:

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

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

Советую почитать мой диалог на эту тему тут <noindex>http://forum.ascon.ru/index.php/topic,8578...4.html#msg45404</noindex>

а дальше двигайтесь по ссылкам внутри диалога

Судя по всему, участница диалога Marianna является программистом, имеющим отношение к созданию системы САПР Компас. Так во всяком случае мне показалось.

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

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

Рассмотрим следующую ситуацию (извините за подробности).

КБ в течение длительного времени (до 1997 года) разрабатывает КД (на бумаге) в состав которой входят чертежи деталей и чертежи сборок. Архив документации - бумажный.

В какой-то исторический момент начинается проектирование КД в электронном виде, программными средствами типа AUTOCAD, PCAD т.е. двухмерное проектирование чертежей с последующей распечаткой на бумагу и сдачей в тот же бумажный архив.

В 1997 году создается электронный архив (файловый архив) документации и вся КД (включая электронные топологии печатных плат из PCAD) сдается в него. (Интересно, но ведь электронные топологии печатных плат - это тоже в некотором роде электронные модели).

На следующем этапе КБ приобретает систему 3-х мерного параметрического проектирования - ProE. Часть конструкторов, освоившая это ПС, начинает использовать эту систему по всем правилам, т.е. разрабатывать эл. модели и параметрические чертежи (CAD-документы). Но ни имея возможности их хранить в электронном архиве (правила формирования файлового архива не предусматривали сохранения параметризации), вынуждена хранить в электронном архиве только "фотографии" этих чертежей в виде файлов *.ps или (*.pdf). Небольшая часть конструкторов, использующая ProE, доводила до ума чертежи в Autocade (теряя параметризацию). Остальная часть КБ по прежнему сидела в Autocade целиком. Примерно за 10 лет на локальных машинах конструкторов скопилось большое количество 3-х мерных моделей с чертежами, имеющих бесценную значимость, с риском полной утраты этих "исходников". В ситуации текучести кадров это могло привести к катастрофической ситуации.

В 2006 году организация покупает систему PLM Windchill, которая обеспечивает поддержку параметризации. С 2006 - по 2007 год создаются условия, которые должны позволить начать полноценную разработку CAD-документов с последующим их хранением в электронном архиве.

В 2006 году выходят ГОСТы, устанавливающие требования к документам в электронном виде и электронным моделям в частности. В 2008 году разрабатываются нормативные документы предприятия, регламентирующие общие требования и порядок разработки документов в электронном виде с учетом системы Windchill.

С момента выхода выше названных ГОСТов возникает проблема, как обеспечить их полноценное внедрение.

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

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

Вопрос 1 – Система обозначения. ГОСТ 2.102 указывает, что модели детали должны иметь код – МД, а модель сборки – ЭСБ.

Вопрос 2 – Что считать основным документом. ГОСТ 2.102 допускает считать основными документами – СП и чертеж детали.

Вопрос 3 – Первичная применяемость. Очевидно первичной применяемостью Эл. модели детали должен быть чертеж детали, а Эл. модели сборки – спецификация изделия.

В результате получаем:

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

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

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

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

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

Очевидно, выход будет таков.

Принимается решение - считать ранее созданные модели составной частью соответствующих чертежей ( т.е. агрегированный документ – в терминологии ГОСТ 2.051) и храниться за одним обозначением. Любое изменение модели или чертежа для таких документов должно сопровождаться заменой соответствующего чертежа или модели одновременно.

Вопрос 6. Что делать, если в архиве лежит чертеж детали (Autocad) без модели, а конструктор решает создать электронную сборку с применением этой детали ?

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

разработчике. (А кудаж он от нее денется ?)

Вроде все довольно стройно и понятно.

Вопрос 7. А зачем Ведомость электронных документов. В ГОСТ 2.102 дается указание при каких условиях она разрабатывается. Из этих указаний сдедуют противоречивые вопросы.

а) Какой службой будет востребована эта ведомость ?

б) Если все документы на изделие выполнены в электронном виде - зачем эта ведомость ?

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

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

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

Вроде все довольно стройно и понятно.

Вопрос 7. А зачем Ведомость электронных документов. В ГОСТ 2.102 дается указание при каких условиях она разрабатывается. Из этих указаний сдедуют противоречивые вопросы.

а) Какой службой будет востребована эта ведомость ?

б) Если все документы на изделие выполнены в электронном виде - зачем эта ведомость ?

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

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

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

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

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

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

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

Как раз эл.модель и нужна для изготовления, т.к ЧПУ-программист использует модель для написания программы изготовления детали. И для него важно знать о всех изменениях эл. модели.

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

Архив просто так ничего не должен....

Архив принимает от конструктора не что и как попало, а только на основании соответствующих документов - извещений об изменении. Разработчик в архив cдает не файлы , а документы. Файл - это лишь способ упаковки документа (это то же самое, если бы в архив бумажные документы принимались в папках). А в извещениях вы должны ссылаться на обозначения документов, а не на наименование файлов.

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

Тут уж как говорится "из песни слова не выкинешь" - судьба у спецификации и чертежа детали такая. Они призваны быть основными документами т.к. в абсолютном большестве случаев без этих докуменов сегодня обходиться не удается.

.....А учет моделей лучше делать другими способами.

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

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

Архив просто так ничего не должен....

Да я, в общем-то, не говорил, что просто так. Канечно, должны быть правила.

Разработчик в архив cдает не файлы , а документы.

Здесь я не могу согласиться. Разработчик должен "сдавать" в архив именно файлы. Как результат своей работы. Я бы воспользовался другой аналогией. Файлы - это аналог бумажных листов документов. Один документ может состоять из нескольких файлов, из одного файла. Но файлы гибче. Один файл может включать несколько документов. Кроме того, файл, вообще, может не быть Документом. Например, файл модели, по которому идет изготовление прототипа или файл PCB для изготовления печатной платы.

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

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

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

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

Здесь я не могу согласиться. Разработчик должен "сдавать" в архив именно файлы. Как результат своей работы.

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

Конечно, теоретически это возможно решить каким-либо приказом, чтобы модели актуальные клали или ещё что. Но на практике это сложно сделать, да и вообще, привычная деятельность конструктора привязана к выпуску документов.

Напомню о вопросе нормоконтроля, к моделям!

Как раз эл.модель и нужна для изготовления, т.к ЧПУ-программист использует модель для написания программы изготовления детали. И для него важно знать о всех изменениях эл. модели.

Да, и это к вопросу, что же первичней. В 102м ГОСТе написано "или" (второй вопрос, зачем там союз "и" оставлен). Тем более, если деталь используется без чертежа - так ЭМИ детали и есть основной документ.

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

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

Мы покамест решили возникшую проблему так:

если на деталь выпущен и чертёж, и модель - то в раздел "Детали" заносится обозначение чертежа, а в раздел "Документы" - обозначение модели, в порядке записи, согласно 2.106, с кодом "МД".

При использовании модели без чертежа, её обозначение, согласно тому же 2.106, заносится в "Детали", по месту основного конструкторского документа, в графе "зона" - зона, в "примечание" - доп.код по 2.102 "3D"

но "что-то здесь не так".... :g:

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

Мы сделали немного по-другому.

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

в который может входить все и модели и чертежи и другие документы

(схемы, перечни, программы проверок и т.д.)

Если речь о файлах T_Flex, то там чертеж и модель - в одном файле

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

................. Разработчик должен "сдавать" в архив именно файлы. Как результат своей работы.

Тут позвольте уже не согласиться мне (И это видимо принципиальный спор.)

ГОСТ 2.051 заменяет слово файл на понятие "Информационная единица - Файл или набор файлов , рассматирваемый как единое целое". Под "единым целым" угадывается как раз документ со всеми присущими ему реквизитами - Обозначением , наименованием , номером изменения (версия) и именем файла в том числе.

Например у нас до внедрения системы Windchill существовал файловый архив.

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

Пример - Наименование файла, содержащего сборочный чертеж ДНИЯ.123456.789СБ, со вторым изменением, изготовленного в программе AUTOCAD

UGAS&123456&789SB_1_2_15.dwg

где:

UGAS&123456&789SB - обозначение документа — полное обозначение, присвоенное документу в соответствии с ГОСТ 2.201, ГОСТ 19.103 или ГОСТ 3.1201 с заменой буквенной части обозначения на символы латинского алфавита в соответствии с таблицей транслитерации.

1 - идентификатор файла — целое число, уникальное внутри перечня файлов, содержащих один документ (имеет значение от 1 до 99);

2 - номер изменения документа — (имеет значение от 0 до 99);

15 - код формата файла — цифра, учитывающая наименование программного продукта в котором спроектировани документ и его версию.

dwg - расширение файла

Реквизитная часть записывалась в отдельный файл, правила формирования которого жестко определялись СТП.

Таким образом в Арихив предъявлялся документ в виде набора фалов.

Эти правила действовали как для конструкторской так и для программмной и технологической документации.

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

Трансляция файлового архива в архив под Windchill только подтвердила нашу правоту т.к. позволило произвести эту операцию без каких либо проблем.

Кроме того, файл, вообще, может не быть Документом. Например, файл модели, по которому идет изготовление прототипа или файл PCB для изготовления печатной платы.

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

Документ "Данные проектирования" печатных плат представляет собой совокупность файлов

ХХХХХ.pcb - Файл, содержащий БДП

* ssf - Файл связей описаний контактных площадок с БДП

ps zip - Файл, содержащий описания параметров контактных площадок и отверстий

predrill.tol - Файл, содержащий перечень диаметров отверстий;

ХХХХХ.txt - Текстовой файл, содержащий информацию о технических характеристиках ПП и определяющий особенности БДП

ХХХХХ.rem - Файл, содержащий перечень диаметров отверстий и их количество

Вся эта группа файлов подвергается архивированию. И в виде файла-арихива сопровождаемая файлом с реквизитной частью отправляется в арихив.

По таким же принципам работают и программисты, разрабатывающие программную документацию по законам ЕСПД и технологи с ЕСТД.

Может быть можно воспользоваться "Ведомостью документов на носителях данных"?

Ведомостью документов на носителях данных - это не что иное как ведомость электронных документов (ГОСТ 2.102)

И свое отношение к ней я уже высказывал ранее.

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

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

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

Да, и это к вопросу, что же первичней. В 102м ГОСТе написано "или" (второй вопрос, зачем там союз "и" оставлен). Тем более, если деталь используется без чертежа - так ЭМИ детали и есть основной документ.

По поводу союза "и" вспоминается детский стишок.

"А и Б сидели на трубе.

А упала.

Б пропала.

Кто остался на трубе ? :g:

Могу вполне допустить, что союз "И" в ГОСТ 2.102 (п.1.2) при описании того, что такое основные документы для детали и сборочных единиц употребим при условии уже описанном мною ранее. Т.е при условии когда чертеж детали и ее эл. модель рассматирваются как составные части одного документа (т.е. имеют одно обозначение и версию на двоих). Соответственно их замена, в этом случае, всегда должна осуществляется одновременно.

Тоже справедливо и для спецификации и электронной структуры изделия.

Кстате это подтверждается высказыванием Елены

Если речь о файлах T_Flex, то там чертеж и модель - в одном файле

- т.е. это один документ.

P.S.

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

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

P.S.

Елена, расшифруйте ДСЕ. Если речь об электроной структуре изделия - то понятно.

Не совсем понятно! Если речь идёт о структуре сборки - то понятно.

А с изделием - масса вопросов. В том же ГОСТ 2.053, на ЭСИ, прописано, что ЭСИ должно быть настолько полно, что из него, в виде отчёта можно получить спецификацию! т.о. в ЭСИ лежит гораздо больше чем банальные детале-сборочные-единицы.

Осюда, ещё вопросы:

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

в который может входить все и модели и чертежи и другие документы

(схемы, перечни, программы проверок и т.д.)

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

Если речь о файлах T_Flex, то там чертеж и модель - в одном файле

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

Как даются ссылки на позиции в сборочном чертеже?

Если это так - Елена, никаких "подводных камней" не выплывало? Просто мы пытаемся двинуть ту же идею, конструкторы не желают сопровождать два отдельных документа. Хоть бы для виду его в один запихать!

И ещё вопросик - в вашей схеме работы, чертёж всегда выполняется в T-flex? Не находятся ли спешащие, которые дорабатывают его в каком-нибудь автокаде, разрывая связь с моделью?

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

Если документ создается в T-Flex, то нет нужды где-то еще дорабатывать

У нас - архив - это БД. Файлы закачиваются прямо в поле БД,

в другом поле сохраняется имя исходного файла

Ограничений на имена файлов - нет (за исключением длины). Сохраняем без префикса

Все остальное - по структуре изделия.

Все остальное - по структуре изделия.

Просто к каждому обозначению элемента структуры - закладочка с комплектом документов.

Помещают документы - либо разработчикм, либо ОТД

Авторство фиксируется автоматически с указанием даты (именем входящего в систему).

Все согласующие, если документ помещался с электронным согласованием -

таким же образом фиксируются.

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

По поводу союза "и" вспоминается детский стишок.

"А и Б сидели на трубе.

А упала.

Б пропала.

Кто остался на трубе ? :g:

Могу вполне допустить, что союз "И" в ГОСТ 2.102 (п.1.2) при описании того, что такое основные документы для детали и сборочных единиц употребим при условии уже описанном мною ранее. Т.е при условии когда чертеж детали и ее эл. модель рассматирваются как составные части одного документа (т.е. имеют одно обозначение и версию на двоих). Соответственно их замена, в этом случае, всегда должна осуществляется одновременно.

Тоже справедливо и для спецификации и электронной структуры изделия.

Хм... логично! :) Однако... не совсем... Типы конструкторских документов строго регламентированы, в ГОСТ 2.102. Новому документу места нет. т.о. вспоминая детскомий стишок, справедливо замечание, а что за буква то осталась (получилась)? Ни рыба, ни мясо.. Повторюсь, "ни рыба ни мясо", по терминологии ГОСТов, которые под конструкторским ДОКУМЕНТОМ понимают лишь документы, из списка в 102м.

Что и требуют нормоконтролёры.

Если я правильно понял, на предприятии у Елены работают не по ГОСТам.

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

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

Обозначаются документы естественно в соответствии с ГОСТами.

При такой организации нужды во взаимных ссылках в ЭД

и твердых копиях нет необходимости.

Оригиналы - в БД. Остальное копии.

Для пользователя имя файла все-равно скрыто и большого значения не имеет.

Предприятие работает по ГОСТам. .

Электронный архив - по программе

и в соответствии с МИ (внутренними стандартами).

У станочника - естественно УП - если это ЧПУ и твердые копии документов

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

Спасибо, Елена. Поясню, как я, наконец-то, всё понял: :)

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

И "первым" документом является основной конструкторский документ, - спецификация, на СЕ или модель+чертёж, на деталь. В принципе, можно согласиться с разъяснением на стишках, от DGroot: действительно, какая нафиг разница, какой ВИД документа. Даже если "два в одном" - обозначение у него одно, вроде как путаницы не возникнет. Вроде как...

чертеж и модель - в одном файле

Всё таки есть небольшой вопросик по данному моменту.

Про твёрдные копии. У модели её не может быть по определению. Как этот вопрос решён у вас? Что несётся станочнику? Ведь распечатывается ему не документ "модель+чертёж", а только чертёж, да или вообще, какой-нибудь вид с этого чертежа! Хотя, всё больше прихожу к мысли, что в моих рассуждениях, навеяными нашими нормоконтролёрами, имеется некоторое словоблудие, с которым (точнее, с нормоконтролем:)) необходимо бороться, а именно, примерно таким способом: "распечатанный лист - копия документа АБВГ.4342-01, сечение А (лист такой-то)". И пофигу, что в документе содержится и модель, и на самом деле бумажную копию документа получить в принципе невозможно. У вас такое примерно так и заверяют?

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

Нормоконтроль должен присутствовать в маршруте согласования

Нормоконтроль должен присутствовать в маршруте согласования

, если документ помещает разработчик

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

Про твёрдные копии. У модели её не может быть по определению. Как этот вопрос решён у вас? Что несётся станочнику? Ведь распечатывается ему не документ "модель+чертёж", а только чертёж, да или вообще, какой-нибудь вид с этого чертежа! Хотя, всё больше прихожу к мысли, что в моих рассуждениях, навеяными нашими нормоконтролёрами, имеется некоторое словоблудие, с которым (точнее, с нормоконтролем:)) необходимо бороться, а именно, примерно таким способом: "распечатанный лист - копия документа АБВГ.4342-01, сечение А (лист такой-то)". И пофигу, что в документе содержится и модель, и на самом деле бумажную копию документа получить в принципе невозможно. У вас такое примерно так и заверяют?

Если честно, то к этому моменту я вообще перестал понимать, о чем вы тут говорите.

Можно сначала. В чем проблема? Одним предложением.

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

При получении твердой копии из БД распечатывается отчет с согласующими

(ФИО, должность, дата согласования), отчет прикрепляется к документу.

Печать ОТД и отметка на документе, что без данного листа не действительно.

для инструменталки отчет с перечнем согласующих не печатаем,

достаточно печати ОТД.

У разработчиков оснастки и УП есть доступ к архиву,

где они могут взять модели для проектирования оснастки или разработки УП.

Результаты их работы помещаются тоже в архив,

но уже в раздел технологических документов

Разумеется существует связь между структурой изделия

и технологическими документами (по назначению).

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

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

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

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

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

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




×
×
  • Создать...