Официальный форум российского программного комплекса T-FLEX PLM


Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1 2 След.
Стандарт предприятия, Электронная модель изделия
 
Добрый день, уважаемые форумчане.
Столкнулся с необходимостью написания стандарта предприятия про электронную модель изделия. Этот стандарт призван повысить качество создания 3Д моделей (например, отсутствие ошибок в окне диагностики) а так же, "узаконить" автоматическое создание 2Д чертежа с 3Д модели (автоматическое создание проекция, видов, разрезов, сечений, простановка размеров...). Может быть кто-то пробовал создавать подобный нормативный документ, с удовольствием рассмотрел бы ваши наработки в качестве примера. Так же буду благодарен за любые советы и пожелания на данную тему.
P.S. Заранее извиняюсь, если создал тему не в соответствующем для нее разделе.
 
Давно задумываюсь о подобном, но до дела пока не дошло. Я думаю, что универсального СТП, которое было бы приемлемо для любого предприятия, просто нет, так как каждое предприятие имеет свои особенности. Если у Вас длительный период поддержки разработок или часто новые чертежи, модели, спецификации создаются на основе ранее разработанных (или к этому стремитесь), а так же, если часто модели (детали) заимствуются в другие изделия, то в качестве одного из основных могу предложить правило: "не привязываться к геометрии 3D тел, кроме тех случаев, когда нельзя иначе добиться желаемого результата". Из этого правила вытекают другие: "не использовать черчение на гранях", "не собирать 3D сборки с привязкой по ребрам, вершинам...". Рекомендую, в этом случае, во всех документах с 3D моделью в качестве "основной ЛСК привязки" использовать ЛСК с одним и тем же именем, например, "ЛСК_0". На счет, "чистоты окна диагностики" - это правильно. Рекомендую регламентировать и структуру хранения электронной документации - поможет избежать многих проблем: хранить всю электронную документацию на одном локальном диске одного компьютера, документы (модели) относящиеся к одному изделию необходимо хранить внутри одной папки, т.е. не делить, например, на папку "Детали" и "Сборки"... Структура папок для хранения данных должна быть такой, чтобы в дальнейшем не было переименования папок и их перемещения, иначе возможны потери фрагментов. Есть еще вариант хранения данных, предлагаемый Сергеем Максимовым - создание библиотек... Возможно, у Вас DOCs, в нем вроде с этим проще... Рекомендую запретить создание копий документов, кроме как для резервного хранения. Т.е. если нужно использовать модель в качестве заимствованной, то не нужно ее копировать в папку с другим изделием. Если в документе имеется таблица исполнений, то опять же не нужно создавать на каждое исполнение свою копию файла, нужно просто правильно параметризовать модель. Для подобных документов не рекомендую создавать ВНЕШНИЕ переменные, непосредственно управляющие размерами модели - для этого безопаснее использовать номер исполнения, либо конфигурации модели.

P.S. Если разрабатывается СТП, то должен быть орган, контролирующий его выполнение, иначе "грош ему цена".
Изменено: Brom25 - 06.01.2010 00:25:50
Кто ищет - тот всегда найдет!
 
to Brom25, спасибо за внимание к теме!
"длительный период поддержки разработок ... часто новые чертежи, модели, спецификации создаются на основе ранее разработанных ...., часто модели (детали) заимствуются в другие изделия" - это про нас.
По поводу сборок не совсем понял, Вы рекомендуете собирать сборки, привязывая все детали к одной ЛСК и затем их перемещая в нужное место?

В данный момент все наработки хранятся на ПК конструкторов, существует огромное количество копий одних и тех же документов...полный бардак.
С целью навести порядок, придумал такой план действий:
- конструктора приводят свои наработки в соответствие с СТП, который будет разработан;
- наработки переносятся на сервер, и храняться там. Надеюсь, это позволит избежать проблемм, связанных со структурой хранения.
 
Цитата
antoshka пишет:

По поводу сборок не совсем понял, Вы рекомендуете собирать сборки, привязывая все детали к одной ЛСК и затем их перемещая в нужное место?

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

Цитата
antoshka пишет:

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

В свое время тоже столкнулся с подобным. Если у Вас много отделов, и в каждом свой локальный бардак, то я рекомендую разделить задачу переноса всех рабочих документов на сервер на две части: 1. переброска всех данных внутри каждого отдела на выбранный компьютер, с последующим разгребанием "мусора"; 2. непосредственный переброс данных от каждого отдела на сервер.
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Рекомендую регламентировать и структуру хранения электронной документации

Важное дополнение: рекомендую при сохранении документов в имени файла указывать децимальный номер - как параметр, отвечающий за уникальность документа.

PS Не плохо бы задуматься о приобретении T-Flex DOCs.
Кто ищет - тот всегда найдет!
 
Замечание по поводу ЛСК действительно актуально, спасибо, я его учту.
По поводу уникальности документов, наше предприятие является автомобилевыпускающим, документация кодируется по, так называемой, "автомобильной нормали". Это обеспечивает уникальность шифра каждого разработанного документа. С этим проблем нет.
PS: DOCs предприятие приобрело, пару лет назад, еще до меня на этом предприятии. По непонятным причинам его не внедрили и особой заинтересованности у руководства в его внедрении я сейчас не наблюдаю.
У нас предприятие не большое, полтора десятка конструкторов, которые работают в одной комнате, чуть меньше технологов, которые «сидят» в соседней комнате…
Действительно ли оправданным будет внедрение DOCs в нашем случае? Одно дело использовать его просто как электронный архив документации (который, как мне кажется, можно организовать и без DOCs), другое – как полноценную систему документооборота
 
Цитата
Антон Владовский пишет:

Действительно ли оправданным будет внедрение DOCs в нашем случае?

В Вашем случае, вероятно, нет смысла. Можно и без DOCs, если все грамотно организовать.
Кто ищет - тот всегда найдет!
 
Цитата
Антон Владовский пишет:

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

Я тут подумал - одно дело когда речь идет о приобретении T-Flex DOCs, а другое дело, когда он уже куплен. Если его рассматривать хотя бы только как электронный архив документации, то он более подходит, так как в нем имеются уникальные инструменты для работы с документами T-Flex CAD. Например, T-Flex DOCs позволяет определять список сборок, в которых в качестве фрагмента используется тот или иной фрагмент. В файловой системе такую информацию обычными методами получить не удастся. Да и, на сколько мне известно, переносить(переименовывать) файлы можно без потери ссылок. Так что есть смысл подумать на эту тему, тем более, что неизвестно какой инструмент T-Flex DOCs Вам спонадобиться "завтра", т.е. это и как задел на будущее.

PS На нашем предприятии уже достаточно долго идет внедрение T-Flex DOCs 2010, но по причине отсутствия полнофункциональной версии объекта внедрения я не могу говорить наверняка о всех прелестях T-Flex DOCs.
Кто ищет - тот всегда найдет!
 
Я тоже задумывался над тем, что бы использовать DOCs, как электронный архив. Конечно же, привлекает возможность создания разнообразной отчетной информации о составе изделия. Но есть сомнения, насколько эффективно мы сможем его использовать, не прибегая к помощи опытных программистов, которых нет в наличии.
Не знаю, правильно ли я принял решение, но для начала разберемся с бардаком в документации, создадим обычный электронный архив. А затем можно и в DOCs его конвертировать.
При любой форме организации электронного архива, не совсем понятен вопрос проведения изменений в документации и выпуска извещений. Как у вас решен этот вопрос?
 
Цитата
Антон Владовский пишет:

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

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

Цитата
Антон Владовский пишет:

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

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

Цитата
Антон Владовский пишет:

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

Главное четко представить, КАК РАЗБИРАТЬСЯ С БАРДАКОМ? Как разобраться с лишними копиями документов, произвести реструктуризацию данных и чтобы при этом не "развалились" сборки и не потерялись фрагменты? Эта задача с моей точки зрения очень сложна. Просто так поудалять лишнии копии на каждом локальном компьютере не получиться, так как на каждом компьютере может быть, например, только один файл какого-либо документа, а в сумме с каждого компьютера их как раз полтора десятка и все могут быть разными вплоть до того что были не скопированы с другого компьютера, а созданы с нуля. Подумайте, что произойдет со сборками если всю электронную документацию разом перебросить на сервер - потеря ссылок. Если перебрасывать постепенно, то можно столкнуться с другой проблемой. Для примера: Вы создаете новую сборку на сервере и Вам необходимо вставить фрагмент, который еще не переброшен на сервер - что делать в этом случае? - вставлять с локальной машины, перебрасывать документ со всеми связанными документами (изделием как минимум), с тем условием, что Вы не знаете какие сборки и из каких изделий используют данный фрагмент, или сделать очередную копию файла и, может быть, входящих фрагментов на сервере? В общем, я думаю так - информационное пространство должно быть единым и не делимым, т.е. работать одновременно и на сервере и на локальных машинах, скорее всего, не получится - перебрасывать нужно разом. Если разом перебросить, то будте готовы очень долгое время заниматься поиском потерянных фрагментов.
Изменено: Brom25 - 07.01.2010 20:42:04
Кто ищет - тот всегда найдет!
 
Да, про маршруты движения документации (возможно, ошибаюсь в терминологии) я знаю. Я имел в виду несколько другую проблему. Например, есть сборочная модель и ассоциативно связанный чертеж. Конструктор выпускает извещение об изменении, в котором локально указывает в каком месте, что необходимо изменить (например, межосевое расстояние отверстий). Проводить изменения в документации обязан корректор. Получается, что корректору необходимо изменить чертеж. Но изменить отдельно чертеж, не затрагивая модели нельзя, иначе нарушиться ассоциативность модели и чертежа. Следовательно, корректор должен провести изменения в модели, затем проконтролировать изменения, которые произойдут с чертежом. Это довольно трудоемко, для корректора и требует неплохих навыков работы с системой. А если таких навыков у корректора нет, и вообще уровень компьютерной грамотности низкий?
Номенклатура выпускаемых изделий у нас не велика.
Разбираться с бардаком планирую примерно по такой схеме.
По головным спецификациям изделий назначить ответственных конструкторов, которые выберут одну из многочисленных копий и приведут ее в соответствие с бумажным утвержденным вариантом КД. При этом необходимо будет сохранить все фрагменты, входящие в сборку в одну папку. Затем эту папку переместить на сервер.
Главное, сделать все синхронно, чтобы архив был полностью наполненным. Только потом можно начинать с ним работать.
 
Цитата
Антон Владовский пишет:

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

Я то думал, что Вы хотите только разобрать бардак в рабочих документах, чтобы оптимизировать работу конструкторов, при этом все изменения вести по старинке - в бумаге, а оказывается еще и электронный архив вести. Если исходить из общепринятого, то получается, что конструктор не должен иметь возможность вносить какие-либо изменения в подписанную документацию. Т.е. либо после подписания файл должен стать доступным только для чтения(что не удобно для конструктора), либо файл вместе со всеми фрагментами должен быть СКОПИРОВАН в другое место на сервере, где бы он не был доступен для редактирования конструктору, но доступен для редактирования корректору. Справедливо замечено, что корректор должен обладать очень хорошими навыками работы в T-Flex. Лучше разработчика с этой задачей никто не справиться. Как это должно быть в DOCs я, к сожалению, ответить не смогу. Однако могу твердо сказать, что делать электронный архив из файлов T-Flex (хоть в DOCs, хоть в файловой системе - это большая ошибка. Аргументом здесь является нестабильность T-Flex CAD. Т.е. после выхода очередной версии T-Flex или даже очередной сборки нет гарантии, что Ваши архивные документы откроются в T-Flex CAD в неизменном виде. Если уж говорить про электронный архив, то я считаю, что это должен быть более надежный формат данных, может быть даже растровая графика...

Цитата
Антон Владовский пишет:

Номенклатура выпускаемых изделий у нас не велика.

Хорошо, если так.

Цитата
Антон Владовский пишет:

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

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

PS Перед началом всех преобразований не забудьте сделать архивные копии всех рабочих файлов по каждому компьютеру в отдельности!
Кто ищет - тот всегда найдет!
 
Архив у нас есть бумажный, параллельно хочу создать и электронный. Соответственно и изменения вести в обоих архивах.
Созданием электронного архива хочу решить такие задачи:
- разграничить права доступа к документации;
- предоставить конструктору возможность использовать наработки предшественников в качестве аналогов для новых разработок;
- конструктора оснастки смогут использовать модели изделий для проектирования оснастки.
По поводу нестабильности, согласен, нет полной уверенности, что в очередной версии все корректно откроется. Хотя, мы безболезненно «переживали» переходы на новые сборки, в пределах 10-ой версии.
Растровая графика, конечно же, штука надежная. Но какие задачи, помимо сохранности документации, можно решить, создав такой архив?
С заимствованными документами тоже не ясно как поступать. Возможно, создавать копии таких документов в каждой папке со сборкой, включающей заимствованную деталь. Параллельно вести учет таких случаев, чтобы корректор вносил изменения в каждую копию. Либо, придется немного поработать со сборками на сервере, и действительно сделать это заимствование. Т.е. на место каждой заимствованной детали в сборках вставить деталь из соответствующих папок с другими сборками.
 
Цитата
Антон Владовский пишет:

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

Никогда не рассматривал решения подобных задач в файловой системе, поэтому посоветовать ничего не могу. По моему, все что написано решаемо в DOCs. Для меня архив - это то, что не может измениться со временем без соответствующей процедуры проведения изменений, то есть то, что гарантирует сохранность документа в неизменном виде. Возможно, во время внедрения T-Flex DOCs 2010 мое мнение измениться - время покажет. В общем, я рассматриваю изменения в электронном архиве примерно таким образом: конструктор оформляет извещение об изменении и изменяет электронный документ, на который оформляется извещение, далее он создает "картинку" этого документа, которую и отправляет в архив. Если документ (картинка) еще не были вложены в архив, то ответственное лицо должно провести сравнение с бумажным носителем с предыдущим изменением. Если же документ (картинка) с предыдущим изменением уже имеются в электронном архиве, то сравнение производится уже с этой картинкой, а это гораздо проще, чем проводить сравнение с бумагой. В обоих случаях "корректор" ничего не изменяет в документе, а только лишь контролирует указанные в извещении изменения. После сравнения, "корректор" вкладывает документ(картинку) в архив с указанием в имени файла номера изменения. Важно, что при этом электронный документ (в оригинальном формате) у разработчика полностью соответствует архивному варианту, что внекотором смысле обеспечивает порядок.

Цитата
Антон Владовский пишет:

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

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

PS Мой Вам совет - поэкспериментируйте с DOCs. Может быть он Вас не устраивает из-за ограниченного количества рабочих мест, но поможет разобраться с бардаком? Может быть можно скинуть все в DOCs, разобраться с бардаком и вернуть все в приемлемом виде на сервер?
Кто ищет - тот всегда найдет!
 
Спасибо за совет! Подумаю об использовании DOCs. Немного пугает, что приобрели мы его давно, соответственно тех поддержка уже не предоставляется и на обновление версий тоже рассчитывать не приходится.
 
Очень хотелось бы "услышать" комментарии разработчиков по поводу того, как DOCs может помочь в решении обсуждаемой проблемы - корректное объединение данных. Ведь эта проблема широко распространена.
Изменено: Brom25 - 08.01.2010 16:10:32
Кто ищет - тот всегда найдет!
 
В теории DOCs все хорошо и красиво. Имеется архив-хранилище уникальных моделей (без повторений, копий). Каждая новая модель детали сразу переносится в архив. При создании сборки конструктор использует модели деталей не со своего локального ПК, а из этого хранилища. И в этом же хранилище новая сборка храниться.
Все отлично и удобно, если внедрять с первого дня работы предприятия. Но в большинстве случаев предприятие уже работало не один десяток лет до внедрения DOCs и накоплен огромный массив наработок, с множеством копий, с непонятной структурой сборок...
 
В DOCs есть понятие "Документ" отличное от привычного. Оно, всего навсего, означает карточку с атрибутами (наименование, обозначение...). Каждая такая карточка уникальна и в системе не может существовать, например, двух карточек с одинаковым обозначением. Однако, с такой карточкой может быть ассоциирован один или несколько файлов ("различные представления одного и того же документа" - как говорят разработчики, если мне память не изменяет). DOCs вроде бы умеет создавать такие карточки автоматически, при импорте данных в систему. Можно предположить, что при импорте очередной копии файла T-Flex CAD в систему к карточке просто прикрепляется новый файл. После импорта всех файлов можно просматривать все карточки и удалять те прикрепленные файлы, которые не соответствуют последней версии чертежа и нигде не используются в качестве фрагмента. Те сборки, в котрых используются фрагменты, не соответствующие последней версии чертежа, нужно будет вручную переделать на использование актуальной версии фрагмента. Не совсем только понятно, как будет автоматически создаваться карточка документа, если чертеж (CAD-овский документ) оформлен криво - тексты наложены поверх форматки или форматки раскрыты... Все же я считаю, что это надежнее и удобнее, чем в файловой системе, главное чтоб в моих рассуждениях не было ошибок и это работало по отношению к Вашей версии DOCs.
Кто ищет - тот всегда найдет!
 
Цитата
Антон Владовский пишет:

В теории DOCs все хорошо и красиво.
На первый взгляд можно уверенно сказать, что описанные Вами выше задачи с помощью T-FLEX DOCs 2010 Вы вполне сможете решить. Предыдущие версии, конечно, стоит обновить, т.к. от версии к версии совершенствуется не только сервис, но и принципы работы с данными, их организация и, как следствие, подходы к работе с системой.
При наличии значительного беспорядка в бумажно-файловом архиве Вам предстоит уделить серьёзное внимание не только технической стороне процесса перехода на электронный архив, но и разработать целый ряд организационных мероприятий. Это необходимо и для того, чтобы процесс шёл быстрее, и для того, чтобы по окончании не начать бороться с ошибочными решениями первых этапов внедрения. Я бы рекомендовал Вам привлечь к этой работе специалистов отдела внедрения компании Топ Системы. Хотя бы в качестве консультантов. На крайний случай - просто пообщайтесь с ним. Такие услуги ими оказываются и их опыт может быть Вам очень полезен.
 
Цитата
Brom25 пишет:

Не совсем только понятно, как будет автоматически создаваться карточка документа, если чертеж (CAD-овский документ) оформлен криво - тексты наложены поверх форматки или форматки раскрыты... Все же я считаю, что это надежнее и удобнее, чем в файловой системе, главное чтоб в моих рассуждениях не было ошибок и это работало по отношению к Вашей версии DOCs.
T-FLEX DOCs 2010 берёт данные о свойствах импортируемых из файлов объектов из параметров "для спецификации", которые имеются у любого чертежа T-FLEX CAD. Т.к. все остальные варианты предельно неоднозначны. Вполне возможно, что стоит провести процедуру проверки и корректного именования объектов, соединив её с отбором "правильных" копий деталей и сборок. Тогда в результате импорта в DOCs попадёт правильная (или очень близкая к правильой) структура.
А в целом Вы верно понимаете логику организации DOCs. Замечу лишь, что в DOCs 2010 появились не только более гибкие инструменты по работе со структурой файлов, но и множеств полезных нововведений по части управления составами изделий (отдельно от хранения документов в архиве).
Страницы: 1 2 След.