Да нет здесь ни какой рекурсии и быть не может по определению.
Рекурсия была в построениях. Я, не знаю почему, но не применяю привязку по 2 узлам. Считаю проще по узлу и углу. По крайней мере в предыдущих версиях это делалось быстрее при включенной опции дискретного поворота.
Павел Перфильев пишет: Рекурсия была в построениях.
Изначально речь шла о переменных . Да, проблема оказалась в способе указания целевых точек для вектора привязки фрагмента. Но считаю, что таких "ограничений" в функционале TF быть не должно, это, как модно нынче, говорить "двойные стандарты" какие-то. С двухмерной геометрией на таком уровне работать не приходилось, в трехмерке с этим проще. В общем здесь "специфика", которую познаешь только на своем опыте.
Я понимал ситуацию несколько шире. Фрагмент зависит от сборки , и в свою очередь фрагмент влияет на элементы сборки. Я таких моментов стараюсь не допускать. У меня в практике правда ничего подобного давно и не встречалось. Опыт подобных ситуаций лет так 5-7 назад. Но в сое время установил для себя определенные правила и их придерживаюсь. В методах работы с TF я достаточно консервативен. Есть отработанные приемы, обеспечивающие нужный результат - ими и пользуемся. Конечно, если что-то интересное в функционале появляется, позволяющее работать более эффективно, включается в арсенал приемов.
Курсовой проект по ДМ Нужно правильно организовать компоновочный чертеж редуктора. Чертеж по 3D модели по ряду причин использовать не желательно. Есть параметрические 3D прототипы (библиотечные элементы) основных деталей с учетом возможных исполнений, с соответствующими 2D профилями. Возникла идея 2D компоновку реализовать в виде конструктора из 2D профилей 3D деталей путем вставки фрагментов на плоскость чертежа, а очертания корпуса привязать к размерам фрагментов с учетом их пересчета под данные сборки (тип редуктора, мощность, передаточное отношение, скорость вращения) плюс некоторые вспомогательные величины (зазоры, болты и пр.), остальная математика забита в файлах фрагментов. Но столкнулся с некоторым неудобством привязки построений в сборке к размерам фрагментов. На мой взгляд, правильнее было бы работать по технологии «сверху-вниз», описав всю математику в одном документе компоновки, а профили деталей создавать в контексте сборки. Но приходится работать с тем, что есть. Может кто еще чего посоветует.
Лет 12 назад занимался подобным на кафедре и именно по ДМ и именно в TF. Мое видение методики таково. Работа с 2D. №D на данном этапе лишнее. Да красивые картинки можно получить, но оформление чертежей, да и созлдание моделей достаточно трудоемко и в рамках КП по времени явно не уложиться, даже если заниматься со студентами дополнительно (у нас на кафедре в свое время было что-то типа клуба по интересам для своиих студентов, кто выпускался по кафедре. Так там самые сильные и 3D баловались) Обязательно необходимо наличие библиотек типовых 2D моделей элементов передач, но я бы делал их без оформленных чертежей - студент сам оформляет чертеж. Работа по принципу "снизу-вверх". На мой взгляд редуктор - классический пример изделия , которое собирается из типовых деталей и на этом примере надо прививать идеологию использования готовых параметорических моделей. Возможно чертеж корпуса редуктора имеет смысл делать в контексте сборкит. Но надо быть крайне осторожным. Все таки у студента как правило еще недостаточно опыта и если в случае ошибок вся сборка развалится, а сроки сдачи жмут, то можно напрочь отбить интерес к CAD. Использование параметрических библиотек может позволить в рамках курсового прорабатывать несколько вариантов , отличающихся по разбивке передаточных чисел по ступеням, по термообработке и т.п. Проводил в свое время подобные эксперименты с сильными студентами - получается здорово. Неплохо еще расчетные пргораммы использовать. Именно в КП по ДМ можно показать все прелести автоматизированного проектирования.
Вопрос несколько глупый, но сам разобраться с наскока не смог. При вставке сборочной единицы в сборку, фрагменту автоматически присваивается атрибут "внутренний" со всеми вытекающими последствиями, а изменить его на тип "из файла" не получается. В опциях напротив строки "Создать внутренний фрагмент" стоит галочка и изменить ничего нельзя. Это наблюдается только для одного элемента сборки, все остальные в порядке, использовался один и тот же прототип, никаких дополнительных настроек не делал. Что может быть и как от данной неприятности избавиться? Рисунок *.jpg Дополню: При вставке окончательной сборки в другой файл, ей также назначается автоматом атрибут "внутренний". Ребята спасайте...
Я этот вопрос поднимал уще год назад. И воевал с техподдержкой, дошел до самого верха( выше не куда было идти). Ничего не решено. Сказали- виноват Билл Гей..тс. Хотя в 10-ке таких закидонов не было. http://www.tflex.ru/vhodnaforum/read.php?FID=10&TID=1230&MID=1 Здесь в "Большие сборки " все написано. Поэтому приходится все дерево ручками проходить и перевставлять (переопределять) фрагменты как внешние. Причем объем сборки критичен. См. выше.
Уважаемые форумчане! Подскажите каким образом откорректировать разворот текстуры на 90 гр. Занимаюсь проектированием мебели, по умолчанию направление текстуры вдоль длинного размера, так оно и надо, однако иной раз нужно наоборот. Пытался подставить переменную в поле "Поворот" в разделе "Материалы", но поле видит только цыфру, как быть.
Что-то ничего не происходит, может важна запись столбиком а не строкой (если столбиком, то ентером не выходит), может это нужно делать в паре с переменной ? И если это работает, тогда нужно в каждой текстуре это прописать, а как управлять поворотом, проще !?
1. Запись в строчку или столбиком - без разницы (для информации переход на новую строку комбинация клавиш Ctrl-Enter) 2. А где Вы смотрите изменения? Эти изменения видны только после рендера (я предполагаю, что именно об этом идет речь, так как в 3D окне текстуры не ахти как выглядят и для мебельщиков слабовато - на мой взгляд по крайней мере) 3. Важно как располагается плоскость детали в пространстве - потому как положение текстуры определяется относительно системы координат модели (вроде так, уточнить можно по справке к PovRay). Поэтому в определенных ситуациях и не надо поворачивать текстуры, а если поворачивать, то относительно одной из осей x, y или z - можно и поэкспериментировать и посмотреть что получается.
Добрый день. Работа с 2D моделями. При построении сборки использовался механизм "снизу верх", при этом геометрия фрагментов изменялась по переменным сборки. Каким образом осуществить обновление геометрии фрагмента в его исходном файле по данным из сборки? Операция "деталировка" создает копию документа, при чем не связанную со сборкой и исходным фрагментом.
Я постоянно использую фрагменты, параметры которых в сборке задавал через переменные. В конечном итоге пришел к следующей методе. Имеется библиотека параметрических моделей (например стоек), там есть все необходимые переменные. Когда необходимо использовать фрагмент в сборке, открываю его, задаю значения переменных, снимаю признак внешней переменной, сохраняю фрагмент под нужным именем (стойка Ст1, стойка Ст2 и т.п.) и уже его вставляю в сборку. В этом случае полностью уверен, что изготовленная по чертежу конструкция будет именно тех размеров, которые нужны. И сборка пересчитывается легче-меньше фрагментов, имеющих переменные, изменяемые в сборке. Естественно при этом имеется и огромная куча фрагментов, параметры которых в сборке можно менять - на них не выпускается отдельно документация и вся необходимая информация по ним попадает в СП.
Как то суть ускользает. Не совсем понял, но в чем принципиальное отличие от операции "Деталировка"? При использовании деталировки исходный фрагмент один (на него можно оформить всю необходимую документацию). В сборке, при выполнении деталировки, данные фрагмента с сохранением всех параметрических связей и с требуемыми значениями переменных сборки выгружается в отдельный файл, который будет содержать уже окончательный документ со всем оформлением. По сути, мы получаем полный аналог исходного фрагмента, но требуемой геометрии. Однако в данном случае, как и в вашем описании для исходных фрагментов, данные геометрии статичны, и любое изменение сборки приводит к необходимости повторять процедуру, причем изменения приходиться отслеживать вручную. Вот при сборке "сверху- вниз" геометрию выгруженных деталей можно обновлять, причем связь двухсторонняя. Почему бы опционально не реализовать нечто подобное и при сборке "снизу-вверх", не по умолчанию, а по желанию пользователя, дабы не увеличивать требования к ресурсам когда этого не нужно. Просто необходимость что-то изменить часто возникает на уже готовой сборке. В этом случае ручная правка всех фрагментов (или переопределение), а их может быть не один десяток, очень трудоемка, да и риск ошибки великоват.
Сборку "сверху-вниз" не использую по многим причинам. Одна из главных - практически все фрагменты мои, в том числе и на которые формируются чертежи - как правило типовые изделия. В этом случае быстрее и проще именно "снизу-вверх". И надежнее. Никогда не забуду, как потерял результат месячного труда - рассыпалась сборка водогрейного котла, созданная методом "сврху-вниз". Хотя и было это давно, но для себя принципиально решил - никогда не использовать в сборке геометрию одних деталей для формирования геометрии других. ДЛя моей области проенктирования это вполне реализуемо и никаких проблем не создает. Что касается
Цитата
Александр Спиглазов пишет:
в чем принципиальное отличие от операции "Деталировка"?
поясняю. В приницпе я применяю своего рода деталировку но с одновременным подставлением деталировочного фрагмента в сборку. При этом фрагмент я уже через перемнные в сборке не могу изменить. И это позволяет мне контролировать соответствие изделий с их чертежами сборочной модели. И если я увеличил высоту конструкции, то сразу увижу, что высота стойки не изменилась и ее надо менять. И чертеж в файле фрагмента всегда соответствует сборке - по корайней мере в сборке визуально это видно. Если бы была в TF команда, позволяющая производить подобные манипуляции было бы здорово. Но меня это особо не напрягает. Все равно проект формируется из сборок и чертежей деталей и сборочных единиц. На каждую сборочную единицу или деталь с чертежом создается свой файл. Так что проблем не вижу. Тем более этот подход применяется толкок изделиям с чертежа. А процент их в сборке для сложных проектов может быть и не слишком большим. Основную массу составляют типовые изделия по ГОСТам, сериям и т.п.
Сборка сверху вниз оправдана когда создается деталь впервые, и как правило нетиповая. ее геометрия полностью зависит от окружения в сборке. Поменялась сборка, поменяется и деталь. Если деталь применяется вторично, то она вставляется снизу вверх и не зависима от окружения в сборке. Её геометрия определена первичной сборкой. Как правило такие детали не параметрические, из них сложно создать типоряд. Замечу, что ассоциативные связи таких моделей требуют иногда особой внимательности и скурпулезности в переназначении родителей в сборке. Иногда сыпется так, что проще перестроить все заново не тратя время на "разбор полета".
Подскажите,как в 3д модели, например полученной путем вращения избавиться от ребра которое остается в месте где начерчен 3д профиль, просто когда только одна операция вращения ребра нет, а если есть еще какие то операции после вращения, то появляется это ребро?