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

Изменения в подсборках.


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

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

<{POST_SNAPBACK}>

Всё верно.

Только в данном случае разговор скорее о особой процедуре.

То есть получив в свою АБВГ.01.00.010 новые модели деталей АБВГ.01.00.001 и АБВГ.01.00.002 ответственное лицо проводит проверку по набору заданных параметров и далает заявление о "вписывании" в рамки ТЗ, что документируется и если что не так - отвечает по полной. Тем самым новые итерации по этому изменению автоматически наследуют свои утверждения. Может смотрится и неожиданно, но без такого инструмента уже ведущий конструктор по блоку просто закрутится как пропеллер, с 0 на выходе. :wallbash:

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

Не знаю уж, есть ли тут что новое для мира САПР, однако прошу любить и жаловать. :rolleyes:

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

<{POST_SNAPBACK}>

При условии чёткой проверки требованиям высшей сборки это не "баг", а "фича", как мне думается.

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


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

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

Не знаю уж, есть ли тут что новое для мира САПР, однако прошу любить и жаловать.

Предложение-то хорошее, однако, при открытии верхней сборки (ну мало ли зачем потребуется :wink: ) с новой итерацией в нижних уровнях, не будет ли CAD каждый раз доканывать вопросами а-ля "модель такая-то совсем не такая как раньше, обновиться?" :smile:

И ещё вопросик: как тогда открыть 3D модель с предыдущей i-k итерацией, если с тех пор k изменений многих компонентов нижнего уровня коснулись?

PDM-то PDM-ом он хоть какие файлы куда хочешь подсунет, но вот CAD-то матюгается если с последнего открытия чего-то внутрях изменилось. Да ещё и две версии одновременно никак не посмотришь и не оценишь какая лучше.

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

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

<{POST_SNAPBACK}>

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

Кстати, http://fsapr2000.ru/index.php?showtopic=14174

хоть и пространно, но к вопросу о согласовании вообще...

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

В CAD всё равно обновится вся цепочка, но может кто слыхал таки о способах не потерять при этом утверждающие галочки Workflow?

<{POST_SNAPBACK}>

Пока единственное, что в голову приходит (по аналогии с "бумажной" практикой):

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

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

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

Пока единственное, что в голову приходит (по аналогии с "бумажной" практикой):

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

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

<{POST_SNAPBACK}>

Вариант, но не пройдёт... похоже потребна революция в подходах к CAD вообще.

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

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

Собственно, вопрос: а нужно ли утверждать (с заказчиком, соисполнителями и проч. любителями дорогого коньяка) КАЖДУЮ итерацию или только некоторые? По крайней мере в опытном производстве очевидно: соорудили сырую документацию, утвердили, начали изготавливать... И началось...Потом все правим, и снова утверждаем, относительно готовый комплект, а не каждый листик.

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

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

Кстати, опять получается, что утверждаем не рабочий материал , а копию или первоисточник (прототип). Видимо модель - это "белок", а подписывали-то всегда "кальки". Да? Нет? Может быть?

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

нужно определиться, ЧТО ИМЕННО мы согласовываем и утверждаем.

<{POST_SNAPBACK}>

иными словами говоря

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

<{POST_SNAPBACK}>

Вот это и есть революция в САПР.

со сборки делать копию в многотельную деталь и утвердить ее как ГЧ. На любом этапе суем сборку внутрь этой ГЧ-детали...

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

<{POST_SNAPBACK}>

Вот тут начинается новое качество, ведь одно дело если

утверждать мастер-деталь (компоновочный эскиз и т.п.)

<{POST_SNAPBACK}>

и совсем иное если тут же должны быть ИМХ, да ещё и с определёнными допусками. А ведь потребуется добавить ещё и потребный для отсека кусок функционала изделия.

утверждаем не рабочий материал , а копию или первоисточник (прототип).

<{POST_SNAPBACK}>

Скажем так: утверждаем ТЗ на изделие, в котором и прописываем все потребные для идентификации принципиальных и непринципиальных изменений. Непринципиальное изменение смело можно игнорировать уже на следующем уровне вхождений.

Стало быть нужен инструмент для создания ТЗ в электронном виде, это скорее всего и будет та самая мастер-модель, но с подцепленной функциональностью, то есть ИМХ, кинематикой, электрикой,.... и что ещё кому потребно.

Интересно, сможет ли хоть один из ныне известных CAD так глубоко интегрироваться с CAE?

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

Посмотрим, что скажут рассчётчики и иже с ними...

вот здесь:

http://fsapr2000.ru/index.php?show...mp;#entry142657

:wink:

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

инструмент для создания ТЗ в электронном виде

Интересно, можно ли к модели как-то присобачить список утверждаемых параметров?

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

Был бы списочек - и видно, что царапины в списке нет. И усё.

--

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

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

Интересно, можно ли к модели как-то присобачить список утверждаемых параметров?

А почему нельзя?

Ведь пишем же ТТ на сборчных чертежах, или ТУ, даже не огромные изделия и ничего.

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

Это очень трудная задача, но отважиться можно.

А, например, целостность покрытия должна оговариваться в стандартах и иных НД.

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

Нет, тут работает другое: проектирование ведётся сверху вниз, а утверждение снизу вверх.

То бишь сперва мы однозначно утвердим составные части, а уж потом их савокупность.

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

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

Распространяя основной принцип внесения изменений (ГОСТ 2.503) получаем, что следует при движении с каждого нижнего уровня к верхнему использовать 3D-макромодели, то есть в сборку верхнего уровня не перекачивать весь состав сборки нижнего уровня, а использовать "склеенную" неделимую макромодель.

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

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

Распространяя основной принцип внесения изменений (ГОСТ 2.503) получаем, что следует при движении с каждого нижнего уровня к верхнему использовать 3D-макромодели, то есть в сборку верхнего уровня не перекачивать весь состав сборки нижнего уровня, а использовать "склеенную" неделимую макромодель.

Нереально говорите, можно сказать даже несерьёзно.

При проектировании КД только формируется, как и ЭСИ...

это ж вам не серийное производство с литерой О1. :no:

Ссылка на сообщение
Поделиться на других сайтах
  • 2 месяца спустя...
Горбушин Даниил

Споры о том что должно произойти со сборкой при изменении входящих в нее компонентов не затихают с самого появления 3д-сборок.

Я давно для себя определился с тем как должно быть в идеале при связке CAD+PDM:

1. Мы вносим изменения в компоненты сборки. Здесь возможны варианты:

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

б) Измения касаются СЕ в которые входит компонет. Насколько мне известно - в данном случае проводят изменения и по СЕ верхнего уровня. Далее все как в варианте А.

2. Вся проблема в логике работы CAD и PDM. Когда данный вопрос прорабатывался по связке Компас+Лоцман. Предлагалось 3д-модели и 3д-сборки на все новые ДСЕ сохранять под старым именем, а старые версии перименовывать согласно номеру версии (1, 2 ... 25, ... 30). При открытии сборок достаточно было бы перестроить сборку, чтобы все изменения были отражены.

3. Большой вопрос касаемые действия измений (то, каких изделий касаются изменния) натыкался на контекстность входимостей ДСЕ. Например деталь АБВ.002.34.556 входит в сборку АБВ.002.34. Сборка АБВ.002.34 входит в сборку АБВ.002 и в сборку АСД.013. На деталь есть изменения, но они касаются только изделия АСД.013. Здесь натыкаемся на зависимость изменений, т.к. для изделия АСД.013 будет использоваться версия 3 детали АБВ.002.34.556, но для изделия АБВ.002 версия 2 детали АБВ.002.34.556.

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

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

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

Проблемы нет пока соблюдается ЕСКД.

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

Правило д.б. такое - не нравится ЕСКД - разработайте и УТВЕРДИТЕ стандарт предприятия (и не надо ничего обсуждать работников под роспись ознакомили и будет счастье).

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

Правило д.б. такое - не нравится ЕСКД - разработайте и УТВЕРДИТЕ стандарт предприятия (и не надо ничего обсуждать работников под роспись ознакомили и будет счастье).

На СТП далее ворот предприятия не уедешь, хорошо ещё если покупатель только матчастью и интересуется. :g:

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

На СТП далее ворот предприятия не уедешь, хорошо ещё если покупатель только матчастью и интересуется. :g:

А мне кажется что это, хотя и не без недостатков, все же более естественный путь. Все же весь мир пробивает дорогу в будущее корпоративными стандартами. Это потом некоторые в ISO превращаются :rolleyes:

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

На СТП далее ворот предприятия не уедешь, хорошо ещё если покупатель только матчастью и интересуется

Есть третий путь - отраслевой стандарт - собираете комиссию с 5 предприятий - и вперед.... (есть еще - на заборе, но....)
Ссылка на сообщение
Поделиться на других сайтах

А по мне, так всё должен софт позволять, хотя бы ради этого программистам пришлось бы много поптеть. :throw:

И побиться об стену головою. :wallbash:

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

А по мне, так всё должен софт позволять

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

Сам процесс создания стандарта предприятия все поставит на свои места особенно после проверки хотябы в "ТестСПб". Я у них 3 стандарта согласовывал - они по каждому пункту мне столько нарушений нашли и каких именно конкретно стандартов и каких именно пунктов. И все в письменном виде. Очень удобно. Люди в стандартах как в своей квартире разбираются, а я как ни пыжусь следить - не уследить (хоть и по должностной инструкции положено - а где время взять?). А они за 3 дня сделали мне то, что я и за год бы не разобрался. Прямо по их списочку ГОСТики собрал - ознакомился - исправил и все (2000 заплатил за консультацию).

Поэтому важно - если решили отойти от ГОСТ (пожалуйста, никто не запрещает) - подготовили проект стандарта, отправили на проверку - откорректировали и живи спокойно.

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

Поэтому важно - если решили отойти от ГОСТ (пожалуйста, никто не запрещает) - подготовили проект стандарта, отправили на проверку - откорректировали и живи спокойно.

Выше по топику приводятся примеры, всё более из жизни с жёстким НК и ВПЗ.

То бишь без нарушений правил ЕСКД.

Важно что бы у софта крыша не ехала при этом.

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

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




  • Сообщения

    • gudstartup
      если конус хороший в том числе и на оправке и усилие зажима соответствует норме то ничего там болтаться не будет это что касается оправки а инструмент все равно может отгибать
    • Gorich
      @gudstartup Большое спасибо...что уделили мне время...решил проблему...нашел там  вот такое: Ввел команду m22...и магазин уехал на свое место...и дальше все аработало!
    • Gorich
    • Viktor2004
      это усилие зажима пружин. А как при вращении там болтается конус чем померить?
    • gudstartup
      при помощи тестера  например такого это самый простой по простому попытайтесь выдрать оправку ломиком!
    • gudstartup
    • TVM
      Для общего развития интересовался. И на предложение, спроектировать крышечку - там все просто, не ведусь. 
    • Gorich
    • Нанософт разработка
      Одним из эффективных способов осуществления строительного надзора является использование результатов лазерного сканирования с построением 3D-моделей, что дает наиболее полную информацию о строительных объектах с привязкой к пространственным, инфраструктурным и центральным инженерным коммуникациям. Институт «Сибгипробум», активно работающий над совершенствованием мониторинга и созданием цифровых двойников, использует комбинацию технологий «Платформа nanoCAD + ReClouds» как бесшовную инженерную среду для проектирования и для работы с облаками точек. Комплексную поддержку при внедрении программных решений предоставила компания «Бюро САПР» – премьер- и фокус-партнер компании «Нанософт» по направлениям «Конструкции», «Инженерия» и «Землеустройство».   О компании АО «Сибгипробум» – институт, на протяжении 65 лет специализирующийся в области проектирования предприятий лесной и целлюлозно-бумажной промышленности, объектов глубокой химико-механической переработки древесины, а также разрабатывающий проекты экологических и энергетических объектов. В проектной деятельности институт активно использует технологии лазерного сканирования и информационного моделирования. Исходная ситуация ·        Отсутствие возможности оперативного повсеместного контроля строительства на промплощадке. ·        Отсутствие актуальной трехмерной модели объекта, которую в дальнейшем можно было бы сопоставить с облаком точек. ·        Сжатые сроки, которые не позволяли создать трехмерную модель. Задачи цифрового мониторинга ·        Поиск изменений между отчетными периодами. ·        Подсчет объемов монтажа. ·        Поиск пространственно-временных коллизий. Сравнение облака точек в двух отчетных периодах на графике строительства – S-кривой. Красным подсвечено то, что изменено (это было сделано на другой платформе)   Оптимальное технологическое решение можно выбрать в зависимости от степени сложности точечной задачи в рамках цифрового мониторинга. Продемонстрируем это на конкретных примерах. Прикладная задача 1: проверка проектного положения монтируемого оборудования и конструкций. Выбранная технология: Платформа nanoCAD для совмещения 2D-чертежей с облаком точек. Алгоритм работы технологии: загрузка исходного облака точек формата LAS в nanoCAD импортом NPC → создание удобной ПСК для сравнения облака точек в нужном ракурсе → копирование чертежа и совмещение по «точкам доверия» (например, по колоннам здания) → создание сечения → поиск отклонений. Полученный прикладной результат: разрез на определенной отметке показал отклонение по колоннам здания, из-за чего стена построена «криво». Благодаря этим данным авторский надзор перепроверил расчетные значения и скорректировал решения. В результате эту стену пришлось укреплять дополнительными металлоконструкциями. Плюсы и минусы технологии Плюсы: Минусы: ·        не требуется трехмерная модель; ·        простая технология, которую может освоить каждый; ·        низкие требования к аппаратному обеспечению; ·        низкая стоимость контроля проектных решений без выезда на площадку. ·        трудозатратно, если требуется проверить несколько разных разделов в одной точке; ·        проверка происходит в рамках одного сечения; ·        каждый раз в новом месте проверки требуется совмещение чертежа и облака точек.     Поиск отклонений в конструкциях путем совмещения 2D-чертежей с облаком точек в Платформе nanoCAD   Прикладная задача 2: анализ деформации оборудования – цилиндрической печи. Выбранная технология: ReClouds для сравнения облака точек печи с ее 3D-моделью. Алгоритм: загрузка исходного облака точек (в формате LAS) и цилиндра, выполненного в виде 3D-солида, равного диаметру печи → совмещение 3D-моделей → использование команды ReClouds Сравнение → побор опытным путем радиуса отклонения (вылет точки от нормативного положения) → создание градиентного графика отклонений → поиск отклонений. Полученный прикладной результат: выявлены отклонения трубы от нормативного положения: вмятина и провисание. Наглядный способ проинформировать проектировщиков и строителей, на какие участки следует обратить внимание, чтобы принять решения о ремонте, частичной или полной замене. Эффективность использования ReClouds ·        Автоматизация обработки данных 3D-сканирования. ·        Работа в знакомой инженерной среде с интуитивно понятным интерфейсом. ·        Высокая скорость работы. ·        Минимум финансовых и аппаратных ресурсов. ·        Интеграция со специализированными решениями. ·        Гибридность используемых технологий: Платформа nanoCAD и ReClouds позволяют одновременно работать с 3D-моделью, 2D-чертежом и облаком.                                         Анализ деформации цилиндрической печи с помощью ReClouds. Справа красным и зеленым цветом подсвечена сама труба   Отклонения трубы от эталонного 3D-солида: слева видна вмятина, справа – провисание трубы Мнение пользователя Павел Владимирович Коротких, главный специалист – руководитель группы отдела по цифровизации инженерных процессов и данных, АО «Сибгипробум»   «Когда геополитическая ситуация обострилась и были введены санкции, перед нашим институтом, как и перед предприятиями многих других отраслей, встала задача импортозамещения.   Много где возникали сложности, но было очень отрадно знать, что базовое инженерное ПО нам есть чем заменить. Этим ПО стала Платформа nanoCAD, которая оказалась намного большим, чем просто скопированный зарубежный продукт.   Из стандартного функционала хотелось бы отметить, во-первых, Диспетчер чертежа, который позволяет удобно осуществлять менеджмент чертежей; а, во-вторых, базовые операции при работе с облаками точек: импорт/экспорт, настройки визуализации, подрезку, сечения и т.д.   Использование ReClouds – вертикального приложения к Платформе nanoCAD – дало нам расширенные возможности взаимодействовать с облаками точек, при этом оставаясь в единой инженерной среде.   Обнадеживает активное развитие продуктов со стороны разработчика и неуклонно растущее комьюнити пользователей».   О компании «Нанософт» «Нанософт» – российский разработчик инженерного ПО: технологий автоматизированного проектирования (CAD/САПР), информационного моделирования (BIM/ТИМ) и сопровождения объектов промышленного и гражданского строительства (ПГС) на всех этапах жизненного цикла, а также сквозной цифровизации всех процессов в производстве. Миссия компании – формирование условий для массового оснащения российского рынка лицензионными, качественными и доступными отечественными программными продуктами. «Нанософт» помогает своим заказчикам достичь импортонезависимости в области инженерного ПО и нацелена на развитие собственных технологий в фокусе реальных потребностей. Это позволяет гарантированно защитить критически важную ИТ-инфраструктуру, что особенно актуально сейчас, когда западные вендоры уходят с рынка, замораживают поставки ПО и техническую поддержку. Все программные продукты компании включены в Единый реестр российских программ для электронных вычислительных машин и баз данных. Официальный сайт: nanocad.ru.  
    • Raven
      Спасибо всем кто, ответил Проблема была в том что в БД свойство было строковое не массив, хотя в бизнес-моделере свойство с таким же именем было массивом типизированых ссылок.
×
×
  • Создать...