Оформление чертежей Solidworks

[Shvg 67]

5. Соорудил бы (заказал) анализатор геометрии, чтобы код по классификатору автоматом подставлял

<{POST_SNAPBACK}>

Это наверное тяжеловато, да и нужно ли?

На очень длинные имена в Sw есть ограничение. Я с этим один раз столкнулся, вроде как в SW2005.

Оптимально - плагин к TotalCommander'у.

<{POST_SNAPBACK}>

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

[Странник 6]

Дальше РАЗВИЛКА. Можно

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

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

<{POST_SNAPBACK}>

Мне тоже вполне симпатична идея забивать всё в свойства документа, а имя файла получать автоматически, тем паче что SWR-PDM 3.0 при создании нового файла сразу выкидывает табличку заполния свойств, при чём всех прописанных в шаблоне. Мало того, и шаблон чертежа у нас настроен так, что никаких атрибутов в нём вообще заполнять не надо - всё потребное будет считано из модели.

Однако, все контекстные ссылки SolidWorks ищет именно по названию файла.

Хорошо это или плохо можно спорить много, но переломить эту реальность неизмеримо труднее, чем забить в той самой таблице $PRP:"SW-File Name". Правда разработчикам SWR-PDM пришлось бы ради этого научить своё детище распознавать эту переменную и обходить создаваемую ею ловушку для структуры изделия (бо таких обозначений будет ровно столько, сколько в хранилище деталей и сборок), но это всёравно легче чем

5. Соорудил бы (заказал) анализатор геометрии, чтобы код по классификатору автоматом подставлял

<{POST_SNAPBACK}>

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

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

P.S. обратите ещё раз внимание на сообщение №463.

Изменено 24 сентября 2006 пользователем Странник

[Nikona 7]

Мне тоже вполне симпатична идея забивать всё в свойства документа, а имя файла получать автоматически, тем паче что SWR-PDM 3.0 при создании нового файла сразу выкидывает табличку заполния свойств, при чём всех прописанных в шаблоне. Мало того, и шаблон чертежа у нас настроен так, что никаких атрибутов в нём вообще заполнять не надо - всё потребное будет считано из модели.

<{POST_SNAPBACK}>

Мне тоже. Только работая без PDM, задаем имя документов моделей по структуре:

Обозначение_Наименование_Суффикс.

Причем Суффикс пишем по необходимости (зеркально, версия и т.п.).

Когда структура модели изделия устаканилась и пора переходить к документации

Заполняем свойства моделей. Редактор свойств имеет кнопку переноса инфы из имени файла в свойства Обозначение и Наименование, отсекая суффикс.

Остается, при наличии конфигураций, добавить из списка -01, -02 и т.д. На всё это тратятся секунды, не считая секунд выбора из базы нужной марки или сортамента материала.

Основную надпись чертежа в ручную не редактируем, там все из модели.

Лишь по необходимости, в свойства чертежа тем же редактором добавляем Код и Вид документа.

Поэтому пробежка редактором по свойствам моделей несопоставимо мала с тем марафоном, который преодолеваешь на пару с СОЛИДом при модернизации имеющегося проекта.

[Странник 6]

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

<{POST_SNAPBACK}>

Хм, а ведь "наименования" иногда бывают и позаковыристие чем, например, вот это: "Блок питания и преобразования".

Nikona, ваш редактор свойств уже реально работает и не вызывает никаких нареканий?

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

[Nikona 7]

Хм, а ведь "наименования" иногда бывают и позаковыристие чем, например, вот это: "Блок питания и преобразования".

<{POST_SNAPBACK}>

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

Ну можно и не включать Наименование в имя файла. Редактор будет считывать только Обозначение (все зависит от настройки маски).

Работает реально. Как весной был выложен на форуме (и у Хулиоса), с тех пор и пользуемся, пока проблем не было.

[ber2004 23]

а это контексты и контексты.

<{POST_SNAPBACK}>

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

Как весной был выложен на форуме (и у Хулиоса), с тех пор и пользуемся

<{POST_SNAPBACK}>

Какой именно редактор? Их же там три...

[RoK13 0]

....В шаблонах у меня этого нет. Свойства добавляются макросом. ....

<{POST_SNAPBACK}>

а каким именно? его выкладывали?

[Nikona 7]

Какой именно редактор? Их же там три...

<{POST_SNAPBACK}>

Редактор YS PropertyEditor (автор Юрий)

А на форуме он выложен в теме: Очередной редактор свойств

[Leon 433]

а каким именно? его выкладывали?

<{POST_SNAPBACK}>

Своим собственным макросом

http://fsapr2000.ru/index.php?show...071&st=560#

Генератор форматок (макрос Master) на предыдущей странице той темы

Прочитал 167 страниц новых ГОСТов, голова как у слона стала

[RoK13 0]

Своим собственным макросом

http://fsapr2000.ru/index.php?show...071&st=560#

Генератор форматок (макрос Master) на предыдущей странице той темы

<{POST_SNAPBACK}>

Огромное спасибо за макрос!!!

[Странник 6]

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

<{POST_SNAPBACK}>

Как же не хорошо хвастаться...

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

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

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

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

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

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

Разумеется, это методика для больших профи.

В кратце примерно так, а подробнее сказать не могу, собственность предприятия.

[ber2004 23]

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

Очень ценный пост, но не отвечает на вопрос...

Если (как у меня) модель построена без контекстов, и после сдачи в архив бумажных чертежей не редактировалась - то она НЕИЗМЕННА и идентична чертежам (кроме сборочных в части перемещений подвижных узлов и т.д.). Если с контекстами - то модель ПРОДОЛЖАЕТ ЖИТЬ насыщеной жизнью. При изменении детали привязок - и она изменяется. А бумажные чертежи (или *tiff, *.pdf) ведь остаются старыми? Я понимаю, что первые несколько итераций чертежей еще нет, но после того, как они появились, итерации-то продолжаются? Получается, что единственный способ "заморозить" сборку (+ вся деталировка) - это "заморозить" ее деталь привязок? Так она тоже несамодостаточна и тоже в контексте...

Или в определенный момент "подводится черта" и рвутся все контексты?

[Странник 6]

Очень ценный пост, но не отвечает на вопрос...

<{POST_SNAPBACK}>

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

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

Собственно здесь имеется в виду некий аналог системы ИИ, ПИ, карточек разрешения и т.п. От SWR мы этого требовали уже давно, вот в SWR-PDM 3.0 начали проявляться похожие мотивы.

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

Правда сразу должен оговориться, буржуинский софт до уровня наших стандартов и близко не дотягивает... другая у буржуинов видать жизнь.

А бумажные чертежи (или *tiff, *.pdf) ведь остаются старыми? Я понимаю, что первые несколько итераций чертежей еще нет, но после того, как они появились, итерации-то продолжаются? Получается, что единственный способ "заморозить" сборку (+ вся деталировка) - это "заморозить" ее деталь привязок? Так она тоже несамодостаточна и тоже в контексте...

Или в определенный момент "подводится черта" и рвутся все контексты?

<{POST_SNAPBACK}>

Ох уж эта мне проблема с бумажными чертежами.

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

В идеале, к которому надо стремиться, бумажный чертёж живёт только как отражение модели, посредством создания slddrw по всем канонам ЕСКД.

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

[ber2004 23]

есть понятия "документ в работе" и "утверждён"

<{POST_SNAPBACK}>

И все таки, конкретный вопрос: Если модель детали (и ее чертеж *.slddrw) имеют статус "утвержден", но при этом некоторые размеры зависят от других деталей (в т.ч. детали привязок, напр. редактирование в контексте сборки), в Вашей системе такой статус только препятствует взятию детали на редактирование? Или обеспечивает полную неизменяемость ("замораживает" текущее состояние, что равносильно разрыву контекстов)? По моим представлениям функционал SolidWorks не позволяет гарантировать неизменность детали, имеющей внешние связи, и Ваше предприятие должно непрерывно топтаться по граблям несоответствия чертежей, ушедших в цех, тем моделям, что остались на экранах конструкторов...

P.S. Что бумажная копия (=*.tiff, *.pdf) - "отражение", полностью солидарен. У нас достигнута идентичность "бумаги" и электронной версии (если нет технических ошибок). Но в архиве - "неизменные копии" *.tiff (или *.dwg). Именно потому и спрашиваю, что *.tiff не способен на самопроизвольное изменение, а *.slddrw - только так. И отражение перестанет таковым быть. У нас это соответствие - увы, на личной совести авторов, но на большой фирме должны быть формализованные процедуры, у Вас они есть?

[Leon 433]

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

<{POST_SNAPBACK}>

Хоть вопрос и не мне, но разрешите встрять. Если узел или деталь утверждены то что мешает установить им атрибут только для чтения? PDMWorks, например, делает это автоматически. Потом по хорошему не очень правильно так организовывать работу, чтобы сдавать в производство и архив детали или узлы, контекстно зависимые от других, еще не утвержденных. Лучше делить проект на самостоятельные узлы, как и писал Странник, внутри которых могут быть контекстно зависимые детали но чтобы сам узел был независимым. Его положение в общей сборке может меняться, например если он навешан на управляющий эскиз или каким-то еще из 13 способов, но геометрия его должна быть самомтоятельной. Иначе будет сложно отследить взаимовлияние узлов разных исполнителей друг на друга.

[ber2004 23]

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

<{POST_SNAPBACK}>

В том то и дело, что он писал противоположное:

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

<{POST_SNAPBACK}>

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

[Leon 433]

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

<{POST_SNAPBACK}>

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

[ber2004 23]

Если ... он выделил несколько контекстно независимых от этой сборки и друг от друга узлов

<{POST_SNAPBACK}>

Диплом за то и получен, что они контекстнозависимы...

[Странник 6]

Диплом за то и получен, что они контекстнозависимы...

<{POST_SNAPBACK}>

Контекст это средство, а тут классический способ проектирования переложен на хрупкие плечи SolidWorks.

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

<{POST_SNAPBACK}>

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

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

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

Если предположить, что в изделии состоящем из отсеков 1,2,3,4,5 разработчик куска 4 нашёл неопровержимые аргументы "отчикать" кусочек объёма от куска 5, то в многотельной детали привязок дёрнутся соответственно тела 4 и 5, но 1,2,3 останутся без изменений. Стало быть и все с этих тел снятые детали не поплывут, а в 4 и 5 по любому совершать революцию.

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

[ber2004 23]

предваряющее утверждение детали привязок

<{POST_SNAPBACK}>

Да, получается это - жизненно необходимо. А если она меняется - низовые разработчики получают сигнал о необходимости корректировки своих узлов средствами PDM или это уже оргмероприятия за пределами SW?