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


Поиск  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1 2 След.
Методология проектирования, Обсуждаем способы проектирования в ТФ.
 
Обойдусь без вступительного слова.
Здесь продолжение темы из "Вопросов начинающего".
Цитата
Андрей Мальчук написал:
Однако, накал страстей)
Методологию проектирования в флексе можно условно разделить на 2 направления:
1. Гибридная методика проектирования, по Алексею Плотникову - для тех, кому нужно что-то сделать, не углубляясь в нюансы параметризации и не сильно заморачиваться) Данная методика хорошо изложена в обучающих материалах и подходит для быстрого старта. Широко используется создание РП по граням, проецирование на РП ребер и пр. элементы не безопасной привязки к 3Д геометрии.
2. Продвинутая методика проектирования, по Алексею Чекмазову - для тех, кому нужна стабильность модели, возможность предсказуемой параметрической модификации в широком диапазоне значений. Определённо требует понимание того, что делаешь и понимание результата этих действий. Выбор разработчиков библиотек, мини-САПР и пр.Выбор той или иной методики проектирования обуславливается опытом, знаниями и задачами, стоящими перед разработчиком. Но всегда стоит помнить и понимать, что проект может править другой человек, и важно, чтобы он смог оперативно разобраться всех хитросплетениях мысли автора)
p.s. с Хабра:Правил собственный код 9-ти летней давности. Как же я страдал (((...
Если говорить именно о проектировании, то я за комбинированный метод, начинается работа в сборке, из которой затем выгружаются фрагменты. Если предполагается кинематика, то лучше такие фрагменты делать изначально в файле и вставлять в сборку. Также, если сложные фрагменты, которые при выгрузке из сборки могут терять геометрию, то делаю снизу-вверх. Но в основном, когда надо быстро накидать концепцию сборки, делаю способом сверху-вниз.
По-поводу продвинутой методики проектирования "имени Алексея Чекмазова" это слишком громко сказано. Но согласен с тем, что конструирование снизу-вверх возможно, когда хорошо представляешь, что хочешь получить в итоге, и конечно, в таком случае надо говорить не о прокетировании, а о конструировании изделия.

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

ps. С Хабра. Если человек правил код, наверное имелось ввиду разбирался с переменными? А если бы переменных было меньше, только самые основные и очевидные и в одном файле, а не в трёх, может и страданий было бы меньше?

Изменено: ВладиславКМВ - 19.01.2018 22:07:24
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
ВладиславКМВ, проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней: потерю геометрии и высокие шансы встречи с рекурсией. Это не недостатки самого метода, а скорее ограничения в его текущей реализации, в 15м каде.
Цитата
ВладиславКМВ написал:
По-поводу продвинутой методики проектирования "имени Алексея Чекмазова" это слишком громко сказано.
нет) Вы просто не занимались созданием библиотечных элементов, вроде тех, над которыми работал я: когда, казалось бы - тривиальная задача создания колена или тройника, затягивается не на одну неделю из-за того, что нужно реализовать универсальный общий случай, а не ряд частных.
и основная проблема - вырождение геометрии при некоторых значениях из рабочего диапазона. Вот тогда и приходит понимание, что рекомендации Алексея не брюзжание, а практический опыт по набитым ранее шишкам. Потому, что это работает)
Дабы не быть голословным: в приложении пример, можете по-изучать, поиграться и, попробовать реализовать по-своему. Кстати, на этом примере хорошо видны плюсы и минусы многотела ( по сути - частного случая проектирования сверху-вниз )
Чтобы лучше было понятно: под методикой Алексея понимается набор правил при проектировании, который основан на более глубоком понимании работы када. Например: не строить 3Д пути по 2Д путям. Вот казалось бы: почему? А причина в том, что в в кадах, по 15й включительно, 2Д пути - это полилинии, т.е. продукт аппроксимации кривой отрезками, с некоторой точностью. Вы можете в этом легко убедиться сами: постройте окружность и измерьте ее длину. А потом создайте по этой окружности 2Д путь и измерьте его длину. Значения после запятой будут отличаться. Вроде не критично, до тех пор, пока не станет задача проектирования лопаток винтов или турбин.
Цитата
ВладиславКМВ написал:
С Хабра.
речь шла про программирование, про стиль написания кода, рефакторинг и про прогресс человека в этом деле) это про то, что, чем больше ты над собой работаешь, в профессиональном плане, тем сильнее понимаешь, на сколько корявыми были твои начальные проекты)
Изменено: Андрей Мальчук - 19.01.2018 10:33:23
Практика - критерий истины (с)
 
ВладиславКМВ, проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней:..... а еще и аппаратные средства ограничены. Столкнулся с ограничение метода сверху-вниз, стенд простой: гидростанция - стол, на столе сменные комплекты испытания Г/А, и обычные шланги РВД, проложить их лучше сверху-вниз, (в контексте сборки, а не по направлению :) ), но на 3... 5 РВД машина тормозит и теряет геометрию. Хотя прокладка рукавов-проводов-трубопроводов само просится. но ой потом вся работа на смарку.
 
Цитата
Андрей Мальчук написал:
Дабы не быть голословным: в приложении пример, можете по-изучать
В сборке нет фрагментов.
Цитата
Андрей Мальчук написал:
Вы просто не занимались созданием библиотечных элементов, вроде тех, над которыми работал я
У меня есть библиотечные элементы - кухонные модули, я их конструировал, т.е. собирал снизу вверх, т.к. простая и понятная задача, нет совместной модификации геометрии для составных частей (за редким исключением, типа угловых модулей и их столешниц), а есть только модификация размеров, которые я делаю через переменные.
Я говорю о том, что есть более сложные задачи, чем создание известных библиотечных элементов.
Вот прилагаю свою сборку. Скажите, каким бы способом вы собирали такую сборку с учётом того, что делалась она не по чертежам, а по изображениям (причём аксонометрическим), но с необходимостью последующего уточнения формы и размеров?
Цитата
Шурик написал:
ВладиславКМВ , проектирование сверху-вниз, при всём его видимом удобстве и простоте, таит в себе ряд подводных камней:
Думаю, я у себя тоже нашёл бы не один пример, когда выбор способа пр. сверху-вниз был неудачным. Я же не утверждаю, что этот способ универсальный и единственно правильный. Я просто хочу сказать , что противоположная безальтернативная точка зрения неверна.
Не буду приводить примеры сложных работ типа проектирования производственного оборудования, причём в качестве прототипа у которого картинки из интернета и краткое описание для потребителей, Которое, если бы я делал строго снизу-вверх с соблюдением всех правил передачи параметров из сборки, да ещё со всеми возможными вариантами (а их было как минимум два да по каждому узлу) то делал бы не 7 месяцев, а гораздо дольше и, возможно, сломал бы голову .
Возьмём очень простое изделие (см. приложение), сборка из четрёх деталей. Каким бы способом вы его проектировали с учётом тех же данных, что и у меня, т.е. картинка и примерный размер головной сборки?
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
Цитата
ВладиславКМВ написал:
В сборке нет фрагментов.
Фрагменты сделал внутренними
Цитата
ВладиславКМВ написал:
Скажите, каким бы способом вы собирали такую сборку с учётом того, что делалась она не по чертежам, а по изображениям (причём аксонометрическим), но с необходимостью последующего уточнения формы и размеров?
Снизу-вверх. Создал бы прототип с, условно говоря - разметкой сборки в 3Д, использовал бы этот прототип для создания фрагментов, и в последствии - сборки. Тут больше вопрос привычки)
Когда я делал свою библиотеку - у меня были изделия и некие правила, которые предстояло "узаконить". Ни чертежей, ни картинок, ни техпролцессов не было. Точнее, оно то вроде и было, но ни разу не соответствовало действительности.
Был каталог продукции, в котором в таблицах, ошибка на ошибке) А в новом каталоге, волевым решением учредителя были изменены некоторые габаритные размеры. Вот только таблицы, значения которых после этого "поехали" - никто исправлять не стал)
Видели бы Вы по каким "креативам" мне приходилось работать))) На их фоне рисунки или картинки - это чертежи с техпроцессами)
Изменено: Андрей Мальчук - 22.01.2018 12:05:13
Практика - критерий истины (с)
 
ВладиславКМВ, вот Вам ещё пример сборки сверху-вниз) Юмор, я думаю, поймут все)
Изменено: Андрей Мальчук - 22.01.2018 18:17:15 (заменил файлы)
Практика - критерий истины (с)
 
Цитата
Андрей Мальчук написал:
Снизу-вверх. Создал бы прототип с, условно говоря - разметкой сборки в 3Д, использовал бы этот прототип для создания фрагментов, и в последствии - сборки. Тут больше вопрос привычки)
Возможно, да, привычки. К плохому привыкают также, как и к хорошему. Я обойдусь без переменных, а в вашем случае без переменных не обойтись. Но такой труд напрасный, т.к. сборка имеет только одно исполнение. Один раз отработать все четыре фрагмента на одном эскизе и зафиксировать в выгруженных деталях. И всё.
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
ВладиславКМВ, тогда проще сделать многотелом и не заниматься выгрузкой тел. Если работа разовая - тогда проще многотелом делать.
Смотрели пример из поста №6?
Практика - критерий истины (с)
 
Цитата
Андрей Мальчук написал:
тогда проще сделать многотелом и не заниматься выгрузкой тел. Если работа разовая - тогда проще многотелом делать.
А чертежи деталей или модели для СЧПУ?
Цитата
Андрей Мальчук написал:
Смотрели пример из поста №6?
Смотрел, но юмора не понял. В дереве две детали, а в сцене одна? В чём шутка?
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
Цитата
ВладиславКМВ написал:
В дереве две детали, а в сцене одна? В чём шутка?
скорее всего это сделали новой опцией на теле "деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный =(
Т.о. нужно пользоваться "деталь - выгрузить".
 
Цитата
SaprOnOff86 написал:
"деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный
А можно поподробнее про "неоднозначности" ?
 
SaprOnOff86, в точку)
Практика - критерий истины (с)
 
Цитата
SaprOnOff86 написал:
ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный =
Понятно, я пока не пользовался, не было нужды.
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
Цитата
SaprOnOff86 написал:
сделали новой опцией на теле "деталь-создать", ранее она еще называлась "доработка" - сразу совет, ни при каких условиях этой опцией не пользоваться, результат всегда неоднозначный
Так кто-нибудь раскроет эту страшную тайну? Что в этой функции не так? Что там всегда неоднозначно получается? Я пару раз пробовал и все было вроде бы нормально.
 
Цитата
B_S_V написал:
Что в этой функции не так? Что там всегда неоднозначно получается?
На некоторых простейших примерах все получается, но на других примерах уже нет: попробуйте сделать кубик, рассеките его пополам, и из одной из половин выгрузите в деталь. Как только у выгружаемые тел в деталь остается какая-то топологическая зависимость - результат выгрузки приходится самостоятельно анализировать... Справедливости ради нужно сказать другие системы это либо вообще не умеют(NX в том числе: преобразование тела в файл с автоподстновкой в сборку, с поддержкой истории построения), либо тоже не ахти как.
 
Цитата
SaprOnOff86 написал:
попробуйте сделать кубик, рассеките его пополам, и из одной из половин выгрузите в деталь.
А если выгружать из сборки целые тела, а не их части? Или адаптивные фрагменты?
 
Цитата
B_S_V написал:
А если выгружать из сборки целые тела, а не их части? Или адаптивные фрагменты?
если тела после выгрузки "не оставят" родителей в файле сборки, то все более-менее ожидаемо.
Ну и адаптивные фрагменты тоже выгружаются стабильно.
 
Спасибо.
 
Цитата
SaprOnOff86 написал:
NX в том числе: преобразование тела в файл с автоподстновкой в сборку, с поддержкой истории построения
Поясните. В NX выгружается всё и подстановку делает и с деревом и без дерева. Единственное, часть ненужную скрыть в телах надо будет это если с построениями выгружать. А так выгрузит и оставит в сборке изначальные построения если нада, или удалит если не нада. Потом можно связать сборку с деталировкой путём замены к примеру базового элемента, что в ТФ сделать нельзя. На данном этапе развития NX в плане работы со сборками намного мощнее чем TF. Покажите что не умеет NX, я такого не знаю.
 
Sila Musli, ну коллеги, работающие в НХ, сообщили что выгрузить дерево построения нельзя, если не сложно можете опровергунть видео-показом?
1. нарисовать куб
2. поставить отверстие
3. рассечь куб по оси отверстия
4. выгрузить тела в файлы
5. поменять отверстие(не прямым моделированием) в разных файлах.
6. показать сборку из "полукубиков" с разными диаметрами отв.
Страницы: 1 2 След.