Странник

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

126 posts in this topic

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

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

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

Share this post


Link to post
Share on other sites


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

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

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

Share this post


Link to post
Share on other sites

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}>

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

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

<{POST_SNAPBACK}>

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

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

<{POST_SNAPBACK}>

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

<{POST_SNAPBACK}>

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

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

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

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

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

<{POST_SNAPBACK}>

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

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

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

<{POST_SNAPBACK}>

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

Share this post


Link to post
Share on other sites

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

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

Бюро А предложено подготовить изменения в узле АБВ.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:

Share this post


Link to post
Share on other sites

Более того, если узел АБВ.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 продают, но какие ими проповедуются подходы - обсуждалось выше.

Share this post


Link to post
Share on other sites

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

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

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

Так вот в свете этого, если Вы проведёте изменения АБВ.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:

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

Share this post


Link to post
Share on other sites

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

<{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 ТЗ (можете назвать их теоритическими моделями или чертежами, деталями привязок или ещё как) каждый более или менее функционально самостоятельный модуль уже стоит строго на своём месте и так с самого верха до самого низа. Когда нужно создать модификацию производится копирование с изменением обозначения, хотя это и не простая процедура.

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

Share this post


Link to post
Share on other sites

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

<{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 и начать «доводку», с неизбежным изготовлением новых литьевых форм и прочей технологической радости?

Share this post


Link to post
Share on other sites

Проходит некоторое время, заказчик №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:

Share this post


Link to post
Share on other sites

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

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

<{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. Представляете себе что значит понятие "натурные испытания"?

Share this post


Link to post
Share on other sites

По порядку

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.

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

:clap_1::clap_1::clap_1:

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

Всё верно.

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

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

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

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

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

<{POST_SNAPBACK}>

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

<{POST_SNAPBACK}>

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

<{POST_SNAPBACK}>

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

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

<{POST_SNAPBACK}>

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

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

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

<{POST_SNAPBACK}>

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

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

<{POST_SNAPBACK}>

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

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

<{POST_SNAPBACK}>

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

--

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.



  • Сообщения

    • qieb111
      Features
      P/N: P1022
      Nonin 9000N disposable neonate/adult(<3kg/>40kg) SpO2 sensor
      Latex free
      0.9m PVC cable
      CE/ISO 13485 FSC FDA
      Packages: non-sterilization, individual package with instruction

      Photos

      Compatibility
      Nonin

      Specifications
      Safety: IEC 60601-1-1 approved, conformity with MDD 93/42/EEC and EN9919:2005
      Patient sizes: Neonate/Adult
      Ambient temperature: 0 to 40℃ (32 to 104℉)
      Relative humidity: 15% to 95%
      Measurement technology: Tri-wavelength LEDs & photo detector
      LED wavelength: 660nm/880nm/905nm
      SpO2 accuracy: ±3 (70-100%); Unspecified (0-69%)
      Pulse rate range: 20-250bpm
      Pulse rate accuracy: ±3 (20-250bpm)

      Payment
      We accept payment via TT (Telegraphic Transfer) and L/C. For small orders of samples, it's acceptable by Western Union and PayPal.

      Shipment
      We offer as many shipping options as possible, including DHL,UPS, TNT, FedEx, EMS, etc.China Disposable SpO2 Sensor
      website:http://www.spo2cables.com/patient-monitor-accessories/disposable-spo2-sensor/
    • ДОБРЯК
      Чтобы выполнять роль зеркала нужно понимание того как решается контактная задача, а у тебя роль попугая или обезьянки, которая кривляется. ) В данной теме. Ты прежде чем давать советы как моделировать и решать контактные задачи сам пойми как программа автоматически меняет пятно контакта.  Начни с простой задачи контакт узел - узел. Потом разберись с контактом узел - конечный элемент. Потом пойми как учитывается сила трения в пятне контакта. Ведь с одной стороны узлы контактируют, а с другой могут скользить друг относительно друга. Почитай лучше хелп, чем тратить время на пустой треп и кривляния. ) И только после этого ты сможешь объяснить, что тебе автоматически нарешал черный ящик с названием Ансис или Абакус.  И сможешь объяснить правильно ли ты сделал математическую модель. А пока только кудах-тах-тах слышно с твоей стороны. Видимо хотел увеличить количество просмотров данной темы. )))  
    • Udav817
      С листовыми я уже заметил один подвох. Нельзя много раз прыгать туда-сюда с синхронки в обычную и обратно. Потом какие-то грани просто перестанут двигаться. И управляющие размеры на них не всегда работают. Видимо какой-то нюанс я не уловил ещё. Но в целом да, с листовыми удобно. Надо немного сдвинуть полку - ты не заморачиваешься с размерами в эскизе, просто грань двигаешь, а тело само добавится/убавится и развёртка перестроится.
    • emre007
        I want to process here angled but I could not do which command I should use  
    • EVGENY1325
      Добрый день господа.  Кто может поделится постом,станок SVL-850 стойка FANUC oi-md, так- же имеется дополнительная ось.
    • Ветерок
      Идея была несколько иной. Поставить их вдоль друг друга и давить одним концом навстречу, прилагая к обоим одинаковый момент. И смотреть в какую сторону от середины будет прогибаться.
    • pechkin624
      Вот про это даже не знал.Милл тогда помогите найти.
    • chatjokey
      Я не среднестатистический житель России. Могу ответить сразу. Не позволительная. Они работают по 12 часов. Впрочем как и я. Но если есть огромное желание, как у меня, то для них будет менее напряжно по бюджету сделать такой трип. Т. Е. У них среднестатистический житель может себе это позволить при желании. У нас нет. Япошек и китайцев туристов в Питере нынче полно. Туристический сезон открыт! 
    • Kelny
      Как вариант использовать штатный инструмент, некорректная работа которого в некоторых старых версиях и породила всякого рода макросы на тему:  
    • piden
      Ок, ок. Публика предупреждена на счет ну или вечер...