Странник

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

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

Допустим, имеется электронная КД на изделие АБВГД.00.00.000, состоящее из 8000 компонентов. Все модели и построенные с них чертежи полностью прошли процедуру утверждения, снизу до верху. Эта электронная КД попадает в руки другой команды, например, КБ передаёт свою продукцию на серийный завод и как всегда начинается коррекция.

Очевидно, что с внесением, хотя косметической правки, в какую ни будь деталь АБВГД.04.01.013 по законам CAD должны будут перестроиться и все сборки, в которые эта деталь входит, включая и АБВГД.00.00.000. Каждый из этих документов нужно будет снова сохранить в PDM, с изменение контрольной суммы и появлением новой итерации. То есть потребуется ещё раз пройти круг согласований, по каждому изменившемуся документу. С точки зрения WORKFLOW это будет не слабый «ротор» ибо количество таких процедур на каждом более высоком уровне сборочных единиц будет расти едва не в геометрической прогрессии. Ни дать, ни взять – стратегическая ловушка. :surrender:

Вопрос: какой есть опыт борьбы с этим «весёлым» эффектом?

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


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


Знакома мне эта проблема :g:

Ужо не первый год с 3D кувыркаемся. А если ещё и заимствований в проектах дофига, то вот обновлять-то придётся до самой верхней сборки, при том не по одному родителю, а по всей применяемости узла (детали) на любом уровне.

Вот такой вот взрыв получается :blink:

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


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

linde, ничего против вас лично не имею, но вынужден провести методичный "обстрел" вашей позиции.

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

<{POST_SNAPBACK}>

АБВГ.00.00.000 это вообще то до 9900000 деталей и 10000 сборочных единиц. Положительно, не пренебрегайте 4 уровнями вложений.

Ну пусть у нас из 8000 компонентов оригинальны 3000. На каждый оригинальный компонент приходится по 10 изменений за 20 лет ЖЦИ, в среднем. Каждая правка тянет за собой 4 уровня. Очень грубо 3000*10*4*7/(20*360*5)=23,33 изменения в день. А ведь это всё ИИ, между прочим. То есть весь отдел общих видов только и делает что непрестанно бегает по предприятию - собирает подписи, все 20 лет.

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

<{POST_SNAPBACK}>

Знаю знаю, помнится сам на этом форуме рассказывал самолётчикам как это делается с крыльями...

Кроме того, информация о вложениях не хранится в виде иерархических связей типа часть - целое.

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

<{POST_SNAPBACK}>

Во... давно я этого признания ждал.

Итак, далее функциональной сборки народ с CATIA и ENOVIA не идёт, спрашивается а как же тогда КД делается?

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

<{POST_SNAPBACK}>

С этими понятно, но КД то откуда берётся?

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

Естественно под CAD системой я имею в виду CATIA v5.

А под системой PDM – ENOVIA.

<{POST_SNAPBACK}>

Без комментариев.

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


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

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

<{POST_SNAPBACK}>

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

По ходу конструкторской проработки средней паршивости детальки (допустим, как раз какого ни будь стыковочного шпангоута) могут появиться до сотни итераций и 5...7 версий в PDM и вовсе не факт, что самой правильной будет именно сотая итерация седьмой версии. Где механизм исключающий попадание в функциональную сборку (ЭЦМ) одной версии, а в производство другой?

Забудьте о КД – достаточно цифрового макета с различными представлениями. Впрочем, никто не мешает прилинковать объект с чертежом к парт референс ENOVIA

<{POST_SNAPBACK}>

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

Исключите покупные изделия, исключите случаи, когда есть необходимость только внести изменения в чертежи или спецификации, не затрагивая 3D моделей. Со сборками до 1000 инстансев на разных уровнях проблем не будет и не используя ENOVIA.

<{POST_SNAPBACK}>

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

Сборка на 1000 с небольшим компонентов у меня как раз типовой тестовый пример, по производству прошла и проблем с нею было столько, что если бы в PDM не лежала...

Разумеется, это был случай когда начальство делало "подставу" за "подставой", однако факт имеет место быть.

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

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


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

Структура изделия может быть отображена в дереве проектов. Это один из самых простых способов.

Не забывайте, что необходимо много структур.

Одно дерево - для производства

Другое представление - для сборки

Третье - для транспортировки

<{POST_SNAPBACK}>

Э нет, так дело не пойдёт

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

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

Чтобы внести изменения в такие эл. документы необходимо пройти несколько процедур.

Так как изменение затрагивает интересы многих пользователей системы PDM, то необходимо согласовать с ними возможность внесения изменения. Для этого необходимы процессы workflow.

<{POST_SNAPBACK}>

Естественно, без Workflow говорить не о чем, но ведь стадии появления полностью утверждённой ЭД нужно ещё добиться, а это по определению итерационный процесс. На одной одноранговой сборке тут не вылезешь, если всю потребную КД не выдал какой ни будь "дядя". А "дяде" этому придётся непременно делать декомпозицию общего на частные, дабы озадачить смежников.

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

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

<{POST_SNAPBACK}>

Вполне согласен, именно движение по ЖЦИ, этим занимается PLM.

Однако очевидно, что мы с вами говорим о разных инженерных задачах: один о прямой, другой об обратной. Когда идёт прямая, то ураган изменений неизбежен и именно по иерархической структуре изделия.

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


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

neskolko wospominanij o pravilax, kak meniajut detal'ki/komponenti.

pravilo 1: esli FFF(Form, Fit, Fuction) ne izmenilos' - sosednie detalki ne nado trogat'

pravilo 2: moduli v strukture dolgni bit' takie - chto pri izmenenii wnutri modulia bes izmenenij ego 'interface' parametrov drugie moduli trogat' ne nado.

pravilo 3. esli nado chto to kardinalno meniat' - to prosto diadia iz zecha pod takim ne podpishetsia - tut nado 'koordinazionnuju' gruppu imet' - inache smegniki (w ili wne organizazii) mogut obidetsia :)

pravilo 4. esli ne 1,2,3 - pora meniat' rabotu ibo bardak :))))

goscha

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


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

pravilo 1: esli FFF(Form, Fit, Fuction) ne izmenilos' - sosednie detalki ne nado trogat'

pravilo 2: moduli v strukture dolgni bit' takie - chto pri izmenenii wnutri modulia bes izmenenij ego 'interface' parametrov drugie moduli trogat' ne nado.

pravilo 3. esli nado chto to kardinalno meniat' - to prosto diadia iz zecha pod takim ne podpishetsia - tut nado 'koordinazionnuju' gruppu imet' - inache smegniki (w ili wne organizazii) mogut obidetsia :)

pravilo 4. esli ne 1,2,3 - pora meniat' rabotu ibo bardak :))))

<{POST_SNAPBACK}>

Хорошие правила.

Только "электронная железка" этих правил может и не признавать. :smile:

Вот пример из собственной практики, несколько изменённый разумеется :rolleyes:

Жалкие 3 детали АБВГ.01.02.001 Лепесток, АБВГ.01.02.002 Пружина, АБВГ.01.02.003 Корпус.

А тянутся из них: 2 х АБВГ.01.02.001 = АБВГ.01.02.010 Губки; АБВГ.01.02.010 + АБВГ.01.02.002 = АБВГ.01.02.020 Контакт; 36 х АБВГ.01.02.020 + АБВГ.01.02.003 = АБВГ.01.02.030 Розетка... далее эта АБВГ.01.02.030 войдёт в АБВГ.01.02.050 Жгут, тот в АБВГ.01.02.000 Блок электрический. Далее АБВГ.01.00.000 Отсек электро-механический и, наконец АБВГ.00.00.000 Изделие. Итого: 7 уровней входимости, то есть 7 последовательных моделей и чертежей сборочных единиц, включая общую сборку. :unsure:

Ну допустим внутри КБ крутились на одноранговых сборках пока не дошли до этапа предъявления заказчику, вроде всё ужо работало и утвердили легко, потом предали на завод :doh:

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

Все 4 правила будут соблюдены, "дёрнется" только АБВГ.01.02.003 Корпус и совсем чуть-чуть АБВГ.01.02.001 Лепесток, на бумаге не пришлось бы не менять даже АБВГ.01.02.010, а вот в CAD все 7 уровней вверх "посыплются" и вполне объективно. :wallbash:

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


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

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

Так вот, исходя из всех посылов, если использовать 3D модель как отражение последнего состояния изделия (т.е. производить обновления файлов перезаписью) то вроде как обойдетесь малой кровью, а если обновление производить в новую версию 3D модели, то тут без регламента работы в конструкторском отделе не обойтись, я так думаю :g: . И, естественно, если с перезаписью делать будете (т.е. по простому), то никакой Вам истории развития изделия, и много здесь всё таки подводных мин кроется. Но об этом если хотите отдельно могу рассказать, т.к. на них я уже натыкался :rolleyes:

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


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

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

<{POST_SNAPBACK}>

С удовольствием послушаю.

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

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


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

С удовольствием послушаю.

Ну вот некоторые из них, которые выявились именно на практике:

Бюро А предложено подготовить изменения в узле АБВ.3445.300.020. Специалист бюро А проводит эти изменения либо в контексте АБВ.3445.300.000 (т.к. это узел разрабатывается в его бюро и поэтому он имеет на него права), либо отдельно в АБВ.3445.300.020, но затем, открывая АБВ.3445.300.000 для обновления и проверки того, как изменения отразились на родительской сборке. Допустим всё в порядке и теперь гл. конструктор (здесь я не имею ввиду должность, хотя всё может быть) открывает изделие АБВ.3445.000.000 для обновления и проверки, того как изменения отразились на данном изделии. Если всё ОК, т.е. не выявилось никаких коллизий (исходя из анализа геометрии, прочностных расчётов и динамической имитации), то он даёт добро на проработку КД (чертежей с 3D модели) и подготовки соответствующего ИИ, что, естественно, не занимает много времени при проектировании в 3D (! заметьте это только конструкторская проработка изменения конструкции в рамках отдела, согласование в других подразделениях и технологический контроль идёт уже традиционным способом с использованием ИИ, нового чертежа и новой 3D модели как дополнение). Если же не ОК, то - специалисту на доработку.

! Более того, если узел АБВ.3445.300.000 имеет более одной применяемости (если отследить это не возможно, то используемая система - это совсем не PDM :smile: ), то разработчик изменения должен оповестить всех ответственных (читай - имеющих права), в чьих изделиях применяется его узел. Т.е. допустим, тот же гл. конструктор проверяет ещё изделия АБВ.3445.000.000-01, АБВ.3445.000.000-05! При таком раскладе ОК должен поступить со стороны каждой применяемости иначе, предложение по изменению снова на доработку.

Ну вот, вроде всё хорошо, и при использовании одноверсионного подхода получается и неудобств практически не видно, за исключением того, что если где-то что-то в каком-то десятом изделии не срастется (и из-за этого вдруг, вообще, принято решение не проводить такое изменение по техническим ограничениям), то надо отматывать все действия назад для узла АБВ.3445.300.020, используя CAD-систему. А потом опять обновлять по всей применяемости вверх всё-всё, чтобы восстановить исходное состояние! А если проектировать в новых версиях, то достаточно просто удалить их :smile: . Опять же это легко выявить по применяемости новой версии узла АБВ.3445.300.020, применяемости, соответственно, новых версий его родителей АБВ.3445.300.000 и т.д. и т.п.

Теперь развиваем тему дальше...

Есть у нас бюро CAM, где технологи ЧПУ-шники компилят программы по 3D моделям. И вот дошла очередь до разработки программы на какую-нибудь АБВ.3445.300.023. Технолог берёт её самую из PDM. Но это-то уже не та самая АБВ.3445.300.023, которая утверждена, а та, которую конструктор бюро А уже успел поменять (но изменение правда ещё в процессе согласования, см. выше), т.к. принят одноверсионный способ работы! Естественно, заставлять CAMщика сравнивать 3D модель с утверждённым чертежом - бред, что если они разные, он же не будет дорабатывать 3D модель под чертёж :wallbash: Поэтому технолог должен быть уверен, что если он берёт 3D модель из PDM, то она актуальна на данный момент, а значит он может выполнять свою работу. Поэтому без многоверсионной работы в этом случае не обойтись, при этом среди множества версий 3D модели одной номенклатуры, должна быть одна ГЛАВНАЯ, т.е. с которой сделан утверждённый чертеж. Таким образом, все пользователи данной информации (CAM-технологи, технологи, технологи-конструктора оснастки и т.д. и т.п.) могут идентифицировать для себя эту версию. Можно ещё и статусы для этих версий навернуть :wink: , т.е. если версия в разработке, то смотреть-то её можешь, но использовать в работе - на свой страх и риск, а если утверждена, то знай, она в состоянии запрещающем редактирование, поэтому можешь работать с ней.

Теперь далее... чтоб совсем жизнь мёдом не казалась :smile:

Пока бюро А готовит свои изменения (см. выше), в бюро Б возникла потребность проводить изменения в узле АБВ.3445.100.050. То, что описывалось ранее имеет место быть и здесь. Т.е. конструктор бюро Б меняет АБВ.3445.100.050, обновляет АБВ.3445.100.000... пока всё штатно, но только до тех пор пока эти изменения не встретятся в одном изделии АБВ.3445.000.000.

Так вот, если использовать одну единственную версию, то в случае возникновения коллизий в АБВ.3445.000.000 причин не найдешь! А если, несколько версий, то получается:

а) ГЛАВНАЯ версия изделия АБВ.3445.000.000

б) версия изделия АБВ.3445.000.000 с изменением от бюро А

в) версия изделия АБВ.3445.000.000 с изменением от бюро Б

и гл. конструктор может сделать для себя

г) версия изделия АБВ.3445.000.000 с обеими изменениями

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

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

ИТОГО: на стадии конструкторской разработки (конструкторской подготовки изменения) не обойтись без многоверсионности.

Ну и ещё... если версии 3D модели имеются и хранятся в системе, то если надо, можно получить информацию о том, как выглядело изделие n-цать месяцев назад. Например, для анализа возможности использования в качестве зап. частей комплектующих после их усовершенствования в конструкции n-месячной давности... но это уже из области PLM-изма... т.е. размечтался я :blink:

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


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

Более того, если узел АБВ.3445.300.000 имеет более одной применяемости (если отследить это не возможно, то используемая система - это совсем не PDM ), то разработчик изменения должен оповестить всех ответственных (читай - имеющих права), в чьих изделиях применяется его узел. Т.е. допустим, тот же гл. конструктор проверяет ещё изделия АБВ.3445.000.000-01, АБВ.3445.000.000-05! При таком раскладе ОК должен поступить со стороны каждой применяемости иначе, предложение по изменению снова на доработку.

<{POST_SNAPBACK}>

Вопрос: почему неприменно от каждой?

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

Разве что изделие сопоставимо по сложности с корабликом, тонн на 45000 водоизмещения... и строются они серией из 12 штук, с очень большим разнесением по времени. И то, если наше АБВГ.00.00.000 разрабатывалось специально на новый "Варяг" и пленённые красотою нашего изделия разработчики старенького, хотя и однотипного "Варвара" решили прописать его и к себе, то уж свою варварскую волю пусть нам навязывать не изволят. Если им так критичны посадочные места, то нехай пишут своё ТЗ и платят дополнительные деньги - подумаем как их горю помочь.

Есть у нас бюро CAM, где технологи ЧПУ-шники компилят программы по 3D моделям. И вот дошла очередь до разработки программы на какую-нибудь АБВ.3445.300.023. Технолог берёт её самую из PDM. Но это-то уже не та самая АБВ.3445.300.023, которая утверждена, а та, которую конструктор бюро А уже успел поменять (но изменение правда ещё в процессе согласования, см. выше), т.к. принят одноверсионный способ работы! Естественно, заставлять CAMщика сравнивать 3D модель с утверждённым чертежом - бред, что если они разные, он же не будет дорабатывать 3D модель под чертёж

<{POST_SNAPBACK}>

Вопрос: а почему бы не разделить понятие модели на конструкторскую, рассчётную и технологическую?

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

Потом сравним их художества с ТЗ и кое что им накрутим, если что не так. Естественно, программа для ЧПУ должна писаться именно с технологической модели, со всеми её уклонами и прочими индивидуальными на каждом конкретном техпроцессе атрибутами.

Приёмка же по конструкторским чертежам или даже моделям.

Т.е. связывать внедрение одного усовершенствования с внедрением другого нельзя!

ИТОГО: на стадии конструкторской разработки (конструкторской подготовки изменения) не обойтись без многоверсионности.

<{POST_SNAPBACK}>

А вот тут самое интересное - почему нужно проектировать строго по иерархической системе, с чётко выделенным институтом ТЗ для каждого последующего нижнего уровня агрегатов. Пусть уж будут описаны чётко габариты, ИМХ, часть функционала, стыковочные места и перечень всякого рода елементов каждому вслед идущему. Средствами CAD разумеется. Чтобы бюро Б получило "по шапке" ещё прежде, чем "рубится" не в свои объёмы. Кстати, вот тут контексты и рождаются.

для анализа возможности использования в качестве зап. частей комплектующих после их усовершенствования в конструкции n-месячной давности... но это уже из области PLM-изма... т.е. размечтался я

<{POST_SNAPBACK}>

Это точно, мечтать всегда было вредно.

Таковыми способностями хвалятся представители DSR, что CATIA продают, но какие ими проповедуются подходы - обсуждалось выше.

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


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

Вопрос: почему неприменно от каждой?

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

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

Так вот в свете этого, если Вы проведёте изменения АБВ.3445.300.000, но не проверите АБВ.3445.000.000-01 и АБВ.3445.000.000-05, а проверите только для АБВ.3445.000.000, а клиенты Вашего заводика заказали на следующий квартал АБВ.3445.000.000, АБВ.3445.000.000-01, АБВ.3445.000.000-02, АБВ.3445.000.000-03, АБВ.3445.000.000-04. То, если изделия АБВ.3445.000.000-01, АБВ.3445.000.000-05 соберуются - это будет просто удача :surrender: !!!

В большинстве случаев придётся воспользоваться напильником и кувалдой :wallbash: и сборщики не раз Вас вспомнят хорошими словами. Вот так, кстати, и рождаются ПИ. Или вот ещё вариант: отложить конкретно эти узлы АБВ.3445.300.000 на склад на случай вдруг кто-нибудь АБВ.3445.000.000 закажет. Но это уже, сами понимаете, замарозка средств на складе и просаживание всех сроков по заказу АБВ.3445.000.000-01 и АБВ.3445.000.000-05 и пени кап-кап-кап :surrender: и дозаказ материалов и мат на планерках. А виноваты именно КОНСТРУКТОРА, потому что не отследили применяемость!!!!

Теперь по поводу "сделает копию со своим обозначением" - да, для конструктора это действительно хорошее решение :rolleyes: , НО новая деталь (сборка) тянет за собой её технологическую проработку, организационную подготовку её производства - растягиваются сроки её постановки на производство (увеличиваются денежные затраты, если, не дай бог, кто-то спроектирует такую же пресс-форму и начнёт её изготавливать). Здорово получается, не правда ли?

Вобщем, далеко ходить не надо. Посмотрите на опыт TOYOTA, у которой широта ассортимента построена во многом на разных сочетаниях одних и тех же компонентов. Т.е. множественная применяемость!!! По сути, 10 клиентов покупают разные модели и в разных комплектациях, но когда это сваливается в то, что надо изготовить по-компонентно, то это просто партия одних и тех же деталей из 10 штук. Понятно, что 10 одинаковых на станке даже ЧПУ сделаются гораздо быстрее, чем 10 разных, т.к. исключаются хотя бы даже затраты времени на переналадку инструментов и загрузку в память другой программы! Вобщем экономию на масштабах производства - это Вы в учебниках по экономике и организации производства прочтёте и ещё в технологии машиностроения :smile:

А если у Вас грамотный нормоконтролер на предприятии работает, то Ваши изыски с компонентами-клонами он просто не пропустит и будет прав :g:

Вопрос: а почему бы не разделить понятие модели на конструкторскую, рассчётную и технологическую?

Ну я, вообще-то, прежде говорил только про конструкторскую. Естественно, что расчётчик где-то что-то упростит, технолог дорисует и скруглит. Упор был сделан именно на то, что технолог возьмет конструкторскую модель, но уже совсем не соответствующую КД!!!

А вот тут самое интересное - почему нужно проектировать строго по иерархической системе, с чётко выделенным институтом ТЗ для каждого последующего нижнего уровня агрегатов.

Я вроде такого не говорил, но раз уж зашла об этом речь, то как тогда проектируете Вы?

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

Проектируете изделие -> перечень агрегатов определили в виде простейших геометрических фигур и их количества, места состыковки и габариты. Проектируете агрегаты -> перечень его узлов определили в виде простейших геометрических фигур и их количества, места состыковки и габариты. ---- Метод сверху вниз.

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

Узлы прорисованы - теперь собираем узлы в агрегаты ---- Метод снизу вверх

Агрегаты прорисованы - теперь собираем изделие ---- Метод снизу вверх.

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


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

Есть у нас бюро CAM, где технологи ЧПУ-шники компилят программы по 3D моделям. И вот дошла очередь до разработки программы на какую-нибудь АБВ.3445.300.023. Технолог берёт её самую из PDM. Но это-то уже не та самая АБВ.3445.300.023, которая утверждена, а та, которую конструктор бюро А уже успел поменять (но изменение правда ещё в процессе согласования, см. выше), т.к. принят одноверсионный способ работы! Естественно, заставлять CAMщика сравнивать 3D модель с утверждённым чертежом - бред, что если они разные, он же не будет дорабатывать 3D модель под чертёж Поэтому технолог должен быть уверен, что если он берёт 3D модель из PDM, то она актуальна на данный момент, а значит он может выполнять свою работу. Поэтому без многоверсионной работы в этом случае не обойтись, при этом среди множества версий 3D модели одной номенклатуры, должна быть одна ГЛАВНАЯ, т.е. с которой сделан утверждённый чертеж.

<{POST_SNAPBACK}>

Для этого существуют стадии жизненного цикла. Пока модель, откорректированная конструктором, не будет согласована, она не попадет на стадию жизенного цикла с которого будет доступна ЧПУ-шникам. Такая методика доступна даже в самых простых PDM-системах (буржуйских) -- например в том же Pro/INTRALINK.

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


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

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

<{POST_SNAPBACK}>

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

С одной стороны просматривается не маленький завод, с другой тоже не слабое КБ. Отсюда и разница в подходах.

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

Вобщем экономию на масштабах производства - это Вы в учебниках по экономике и организации производства прочтёте и ещё в технологии машиностроения

<{POST_SNAPBACK}>

Ох уж эта мне экономия...

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

А если у Вас грамотный нормоконтролер на предприятии работает, то Ваши изыски с компонентами-клонами он просто не пропустит и будет прав

<{POST_SNAPBACK}>

Кстати, нормоконтроль не должен брать на себя слишком уж много.

Ибо ломать амбиции заводчан тоже будет нормоконтролёр или как?

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

Ну я, вообще-то, прежде говорил только про конструкторскую. Естественно, что расчётчик где-то что-то упростит, технолог дорисует и скруглит. Упор был сделан именно на то, что технолог возьмет конструкторскую модель, но уже совсем не соответствующую КД!!!

<{POST_SNAPBACK}>

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

Я вроде такого не говорил, но раз уж зашла об этом речь, то как тогда проектируете Вы?

<{POST_SNAPBACK}>

Вот теперь не поняли меня.

В начале ветки Linde говорил про одноранговую сборку как панацею от всего....

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

<{POST_SNAPBACK}>

Ну а...

ИТОГО: на стадии конструкторской разработки (конструкторской подготовки изменения) не обойтись без многоверсионности.

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

<{POST_SNAPBACK}>

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

Ну а сам я проектирую именно так, как и описано далее по посту.

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

Можно так и утвердить всё дерево, только уже снизу-вверх, но вот последующий поток коррекций нижнего уровня представляется просто убойной силой, или есть таки противодействие?

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


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

А если у Вас грамотный нормоконтролер на предприятии работает, то Ваши изыски с компонентами-клонами он просто не пропустит и будет прав

<{POST_SNAPBACK}>

Пардон, что 2 сообщения подряд.

Допустим, изделие АБВГ.00.00.000 изначально проектируется с прицелом на глубокую модернизацию, иначе говоря, создание множества модификаций удовлетворяющих меняющимся в зависимости от множества факторов требованиям заказчика. Программа выпуска изделия – 10000 штук. Далее предположим, что некий сложный функциональный модуль таки приходится брать из вне, при чём уже готовый. Что получается?

В состав АБВГ.00.00.000 вносится внешний элемент QWE-07.00.000, серийная продукция фирмы QWE. В граничащим с ним отсеке АБВГ.01.00.000 предусматривается выделенный переходник АБВГ.01.01.000 и изделие успешно идёт по итерационному циклу, вплоть до серийного производства.

Проходит некоторое время, заказчик №1 покупает поэтапно своих 10000 изделий, но говорит: всё хорошо, однако теперь надо бы расширить возможности системы, тогда я ещё 5000 штук куплю. Выливается же дело в объявление конкурса на замену QWE-07.00.000 агрегатом с подобными функциями, но работающим на иных физических принципах. Предположим, конкурс выигрывает старинный конкурент фирмы QWE - фирма RTY, со своим, опять же серийным, RTY-13.00.000. Правда обводы и стыковочные места у этого RTY-13.00.000 несколько иные. Приходится делать специальный переходник АБВГ-А.01.01.000, а вместе с ним и отсек АБВГ-А.01.00.000. В итоге получается новая модификация АБВГ-А.00.00.000, примерно на 75…80% унифицированная с АБВГ.00.00.000, но обладающая качественно более высокими характеристиками. И бегут уже за АБВГ-А.00.00.000 заказчики №№2,3,4,5, и каждый из них просит по 3000 изделий. Заказчик же №6 хочет 5000 штук АБВГ.00.00.000 по сходной цене, как устаревающих.

Всё бы хорошо, но вот опытная партия АБВГ-А.00.00.000 выходит не натурные испытания, которые безпристрасно показывают недостаточность некоего отсека АБВГ.05.00.000 для выполнения во всех внешних условиях технических требований к новой модификации изделия. Самое интересное, недостаточно на не много, но если «дожать», то QWE-07.00.000 начинает «пошаливать» на другом пределе диапазона рабочих параметров. А конкуренты меж тем не дремлют. Вот и получается, что подправишь АБВГ.05.00.000 под АБВГ-А.00.00.000 – потеряешь быстрый заказ на 5000 изделий АБВГ.00.00.000, не подправишь – потеряешь заказы 17000 изделий АБВГ-А.00.00.000 в перспективе. Сможете предложить выход лучший, чем таки сделать клон с АБВГ.05.00.000, обозвать его АБВГ-А.05.00.000 и начать «доводку», с неизбежным изготовлением новых литьевых форм и прочей технологической радости?

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


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

Проходит некоторое время, заказчик №1 покупает поэтапно своих 10000 изделий, но говорит: всё хорошо, однако теперь надо бы расширить возможности системы, тогда я ещё 5000 штук куплю. Выливается же дело в объявление конкурса на замену QWE-07.00.000 агрегатом с подобными функциями, но работающим на иных физических принципах. Предположим, конкурс выигрывает старинный конкурент фирмы QWE - фирма RTY, со своим, опять же серийным, RTY-13.00.000. Правда обводы и стыковочные места у этого RTY-13.00.000 несколько иные. Приходится делать специальный переходник АБВГ-А.01.01.000, а вместе с ним и отсек АБВГ-А.01.00.000. В итоге получается новая модификация АБВГ-А.00.00.000, примерно на 75…80% унифицированная с АБВГ.00.00.000, но обладающая качественно более высокими характеристиками. И бегут уже за АБВГ-А.00.00.000 заказчики №№2,3,4,5, и каждый из них просит по 3000 изделий. Заказчик же №6 хочет 5000 штук АБВГ.00.00.000 по сходной цене, как устаревающих.

Все это от недостаточной жесткости унификационного контроля.

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

Есть хороший термин, называется взаимозаменяемость деталей и сборочных единиц. Соблюдайте это ограничение и вносите любые изменения, улучшающие технические характеристики. :rolleyes:

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


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

Все это от недостаточной жесткости унификационного контроля.

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

<{POST_SNAPBACK}>

Читать то внимательно умеете?

Предположим, конкурс выигрывает старинный конкурент фирмы QWE - фирма RTY, со своим, опять же серийным, RTY-13.00.000. Правда обводы и стыковочные места у этого RTY-13.00.000 несколько иные.

<{POST_SNAPBACK}>

Вы ставите на своё изделие уже серийный (!) агрегат со стороны, да ещё и работающий на иных физических принципах и хотите что бы под ваши замороки кто то подстраивался? А о том, что вы только ДОПОЛНИТЕЛЬНЫЙ ЗАКАЗЧИК и есть ещё основной владелец со своими собственными требованиями никак догадаться нельзя было? Собственно, это ж всё азбучные истины.

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

<{POST_SNAPBACK}>

А что значит 75-80% унификации представляете себе?

Итак, был приведён пример модульной конструкции изделия с 2 вариантами мотивации изменений:

1. когда мы не хозяева "куска", как в случае с QWE-07 и RTY-13

2. когда мы хозяева, как с АБВК.01.00.000 и АБВГ.05.00.000.

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

<{POST_SNAPBACK}>

Думаете с проста оговорил наличие выделенного в отдельную сборочную единичку специального переходного узла АБВГ.01.01.000 в составе отсека АБВГ.01.00.000?

Что будет быстрее и дешевле - выдать ТЗ на новый агрегат с вашими посадочными местами и электрической схемой или сделать адаптор? Думаете на фирмах QWE и RTY бОльшей выгоды от укрупнения производства себе даже и не представлят?

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

Далее, благодаря этому самому АБВГ.01.01.000 (переделанному соответственно в АБВГ-А.01.01.000) изначально не "поплыл" ни один из отсеков начиная с АБВГ.02.00.000 (!), а было их там по крайней мере ещё 4. Ведь недостаточным на крайнем значении рабочих параметров при натурных (!) испытаниях показал себя АБВГ.05.00.000. Представляете себе что значит понятие "натурные испытания"?

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


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

По порядку

To susland

Для этого существуют стадии жизненного цикла. Пока модель, откорректированная конструктором, не будет согласована, она не попадет на стадию жизенного цикла с которого будет доступна ЧПУ-шникам. Такая методика доступна даже в самых простых PDM-системах (буржуйских) -- например в том же Pro/INTRALINK.

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

Цитата(Странник @ Jan 19 2007, 17:58 )

Цитата(BPK @ Jan 17 2007, 15:26)

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

С удовольствием послушаю.

To Странник

То есть всё равно придётся рано или поздно делать копию АБВГ.01.00.000 с индексом ДЕЖЗ и постепенно адаптировать под ДЕЖЗ.00.00.000. Технология то у каждого из них своя.

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

У Вас тяжелый случай :smile: и в любом случае цепочка " технологическая подготовка - организационная подготовка" для любого изделия, производящегося на любом из возможных заводов будет иметь место. Я-то говорил именно на экономии времени на этих двух этапах, при заимствовании. А раз разные производители, то технологию все равно придётся писать. Так что, в Вашем случае, возможно, плодить ДЕЖЗ.00.00.000 будет лучшим решением.

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

К любому вопросу надо подходить без фанатизма. Я не говорил об экономии в ущерб выходным параметрам. :smile:

Кстати, нормоконтроль не должен брать на себя слишком уж много.

Ибо ломать амбиции заводчан тоже будет нормоконтролёр или как?

Имелась ввиду одна из функций нормоконтролера по ЕСКД: ".. достижение в разрабатываемых изделиях необходимого уровня унификации.." и всё

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

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

Можно так и утвердить всё дерево, только уже снизу-вверх, но вот последующий поток коррекций нижнего уровня представляется просто убойной силой, или есть таки противодействие?

Вы моё мнение знаете :smile: . Да, поток убойной силы. Я Ваше мнение тоже хорошо понял. И понял, что в некоторых случаях клонировать компонент под другим обозначением оправданно (Прочитал все Ваши посты). Если кто-то может предложить способ лучше пусть поделиться, мне тоже будет интересно его узнать.

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

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

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


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

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

<{POST_SNAPBACK}>

Эх, кто бы только с этим спорил.

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

http://fsapr2000.ru/index.php?show...mp;#entry140451 посты №71..76, а подчинённых пиночить куда легче.

В прочем это уже несколько в сторону.

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

Например: облегчили какую ни будь деталь грамм на 50, хотя бы материал изменили, а допуска на блок установлены плюс минус 200 грамм, реально же вообще грамм на 70 всего и бегают. Центровка при этом вообще практически не дёрнется, прочие же параметры совсем ни при делах. ИИ таким образом ограничется собственно той самой деталью.

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

P.S. построение "липовой" структуры изделия непосредственно в PDM на фоне одноранговой сборки на 1000000 компонентов не предлагать.

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


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

P.S. построение "липовой" структуры изделия непосредственно в PDM на фоне одноранговой сборки на 1000000 компонентов не предлагать.

:clap_1::clap_1::clap_1:

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

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

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


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

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

<{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?

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


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

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

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

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

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

--

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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


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

Споры о том что должно произойти со сборкой при изменении входящих в нее компонентов не затихают с самого появления 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 пользователей

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



  • Реклама

  • Сообщения