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


Поиск  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
T-Flex 12, Что мы хотим от TF 12 (предложения)
 
Ввести возможность применения сопряжений к элементам построений :love:
Страницы: Пред. 1 2 3 4 5 6 ... 26 След.
Ответы
 
2 B_S_V.

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

P.S. Однако в споре родилась полезная истина :).
Изменено: Brom25 - 10.08.2008 14:20:42
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Архив так и не сумел открыть
Открывается и winrar 3.00 и Zip -ом. Если еще актуально, могу перзапаковать winrar.
 
Цитата
B_S_V пишет:

Если еще актуально, могу перзапаковать winrar.

Не стоит, ошибки же не происходит...
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Все-таки параллельная структура нагляднее для исполнений, когда есть различия в формах деталей.
В случае когда каждое исполнение предполагает на чертеже свой вид эта задача решается достаточно просто. Хуже когда на каждое исполнение нужно выполнить отдельный чертеж. Про второй вариант я писал ранее.
В первом случае достаточно в дереве где нужно создать паралельную модель создать копию и на ней делать паралельные построения, а с помощью уровня управлять видимостью исполнения при вставке фрагмента.
Т.е. задача решается методически без доп функций.
PS. кстати, я с этой задачей столкнулся в 2001 году и успешно решил ее в TF 7.0.
Изменено: Diso - 25.08.2008 14:04:59
 
Цитата
Diso пишет:

Т.е. задача решается методически без доп функций.

Цитата
Diso пишет:

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

Это и есть дополнительная функция, "утяжеляющая" модель.

Цитата
Brom25 пишет:

Все-таки параллельная структура нагляднее...
Кто ищет - тот всегда найдет!
 
Цитата
Diso пишет:

когда на каждое исполнение нужно выполнить отдельный чертеж.

Когда-то я с этим столкнулся 5 лет назад на SW2003.
Там это решалось так:
1 Строилась модель с исполнением -00.
2 В дереве исполнений (находилась оно в том же окне что основное дерево исполнений) создавались номера дополнительных исполнений.
3 Потом выбирали необходимое исполнение например -201 и изменяли дерево построений и так для каждого исполнения (что-то из операций добавлялось или удалялось или менялись параметры операций.
4 Потом при выборе нужного исполнения SW пересчитывала модель и перестраивала чертежи.

Никаких сложностей не было и было очень удобно и просто. Это гораздо удобнее чем создавать таблицы переменных.
 
Цитата
Brom25 пишет:

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


Это и есть дополнительная функция, "утяжеляющая" модель.
Она утяжеляет равно на столько насколько утяжелит паралельная структура. И в дереве модели выгладит все также паралельно. Проименуйте копию исполнение 201 и далее все как описано в предыдущем случае.
Только управление уровнями даст возможность не пересчитывать групповой чертеж.
Вообще я придерживаюсь правила.
Один файл - один чертеж.
Если нужны разные чертежи на разные исполнения лучше перекидывать промежуточную геометрию в другой файл и там добивать до чертежа.
 
Цитата
Diso пишет:

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

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

Цитата
Diso пишет:

Она утяжеляет равно на столько насколько утяжелит паралельная структура.

Пересчет фрагментов все равно периодически приходится производить. И тут как ни крути, дополнительная операция («Копия») увеличит время пересчета, поэтому я сомневаюсь в правильности Вашего утверждения.

Ко всему прочему могу добавить, что параллельная структура будет способствовать реализации автоматического заполнения раздела спецификации «Переменные данные для исполнений».
Изменено: Brom25 - 27.08.2008 23:42:58
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Ко всему прочему могу добавить, что параллельная структура будет способствовать реализации автоматического заполнения раздела спецификации «Переменные данные для исполнений».
Я думаю, что это главное, ради чего стоит затевать "штатный механизм работы с исполнениями. Все остальное с той или иной степенью сложности можно реализовать существующими инструментами.
 
Цитата
Brom25 пишет:

я сомневаюсь, что управление уровнями предотвратит пересчет в сборке, так как для управления уровнями необходимо менять значения параметров, а в этом случае системе просто логично произвести пересчет. От персчета спасают конфигурации,
Вы сами ответили на свои сомнения. Конфигурации. Достаточно на копию наложить переменную в поле Подавить. Одно но... Сейчас эту переменную придется назначать всем потомкам. Иначе они "окрестятся красным" и система всё равно будет парится с геометрическим поиском. Создание "штатного" инструмента для работы с исполнениями может решить эту проблему, автоматически создав конфигурацию и переменную, прописав ее в конфигурации (возможно даже не видимо для пользователя, т.е. что операция принадлежит такому-то исполнению он видеть должен конечно же).
 
Цитата


Diso пишет:

Она утяжеляет равно на столько насколько утяжелит паралельная структура.

Brom25 пишет:
Пересчет фрагментов все равно периодически приходится производить. И тут как ни крути, дополнительная операция («Копия») увеличит время пересчета
По сути, любая паралельная структура в месте ветвления опирается на копию. Кстати Копия одна из самых "лёгких" операций. Все остальные операции паралельно паралельны. ;)
 
Цитата
Diso пишет:

По сути, любая паралельная структура в месте ветвления опирается на копию.

Это не верно. Никаких копий. В месте ветвления у всех исполнений один и тот же родитель, с одной и той же геометрией. Зачем делать копию, если каждая параллельная ветка не влияет на остальные? Просто, переключая ключ на соответствующую ветку, будет изменяться очередность операций. Все остальные ветки при этом могут быть «мертвыми» и даже не пересчитываться. Поэтому копия вообще не нужна.

Цитата
Diso пишет:

Все остальное с той или иной степенью сложности можно реализовать существующими инструментами.

Все правильно. Продвинутые пользователи сумеют выйти из положения. Другое дело простота в понимании и использовании. На мой взгляд, ничего проще параллельной структуры при работе с исполнениями для понимания и не придумаешь. Да и для переключения с одного исполнения на другое нужно всего то переключить ключ…
Совсем недавно в разговоре с одной очень уважаемой коллегой, которая в 3D работает очень давно, я попытался рассказать вкратце, как параметризовать модель с исполнениями. В итоге услышал приблизительно такую фразу: «Это больно сложно –выражения в параметрах, базы данных… Мне уже скоро на пенсию. Не буду я в этом разбираться. Это ты молодой – разбирайся, а мне бы доработать своё.» Причем, эта женщина в своих моделях использует параметризацию. Конфигурации для нее оказались простыми, но они не всегда подходят. После я подумал над сказанным и согласился с ней. После этого случая на форуме появилось обсуждаемое сейчас предложение.
Вообще, не знаю какие еще операции (из числа тех, без которых нельзя обойтись) нужно добавить в T-Flex, поэтому думаю самое время сосредоточить внимание на доработке существующих функциональностей и удобстве (упрощении) при работе с системой.

Забегая вперед в вопросе параллельной структуры хочу дополнить. Если данное предложение дойдет до осуществления, то однажды может потребоваться дополнить предлагаемую функциональность механизмом так называемых «эквивалентных ЛСК». Что я под этим подразумеваю: представьте, что деталь с исполнениями имеет 2-е ЛСК. При вставке в сборку одного исполнения для привязки должна использоваться первая ЛСК, а для привязки другого исполнения – вторая. При существующих возможностях T-Flex мы должны вставить 2 раза один и тот же фрагмент с базами на разных ЛСК. Механизм «эквивалентных ЛСК» позволил бы системе воспринимать эти две ЛСК как одну и ту же, в независимости от исполнения, и в результате обойтись одним фрагментом на все исполнения.
Но до этого еще очень далеко, так как случай редкий…
Кто ищет - тот всегда найдет!
 
Есть у меня еще пара идей, без которых можно обойтись, но которые могли бы упростить труд инженера-конструктора:
1. «Плоскость построения».
Очень часто приходится на разных рабочих плоскостях строить линии построения, параметр «Расстояние» которых связан (например, для задания положения 3D узла в пространстве). Сейчас для этого используется параметризация. Особенность «Плоскости построения» в том, что при пересечении рабочей плоскости она должна оставлять в ней след в виде линии построения. Такую линию можно передвигать из любой рабочей плоскости, в которой она оставляет след. За счет такого механизма можно обходить параметризацию, не запоминая имена переменных. Этот механизм может быть для многих пользователей более простым и понятным. Положительным моментом будет так же наличие в только что созданной рабочей плоскости линий построения, полученных по «плоскостям построения».
Пока предполагаю, что «Плоскость построения» должна быть перпендикулярна той рабочей плоскости, в которой была создана.
2. «Кривая по движению мыши».
Не менее часто приходится строить местные разрезы на проекциях. Для этого нужно нанести штриховку, предварительно ограничив ее кривой. Процесс ограничивания кривой может оказаться очень трудоемким и результат не всегда выглядит подобающим образом: где-то амплитуда волнистой линии нормальная, где-то на столько маленькая, что больше похожа на прямую тонкую… Сплайном тоже неудобно, да и прожорлив он к ресурсам ПК… Поэтому было бы неплохо иметь механизм запоминания движения мыши для получения ограничивающей кривой. Кстати, подобный механизм существует во многих программах по созданию музыки и вроде бы в программах обработки видео.
Важной особенностью такого механизма должно быть то, что начало и конец кривой должен определяться автоматически, если кривая не замкнутая. Первая пересечённая линия при движении мыши даст начало, последняя – конец. Также кривая должна быть редактируемой и уметь «деформироваться» при изменениях размеров на проекции модели. Естественно, хотелось чтобы такая кривая была «легче» сплайна, т.е. аппроксимированной, но так чтобы это было незаметно.
Кто ищет - тот всегда найдет!
 
Цитата
Diso пишет:

Вообще я придерживаюсь правила.
Один файл - один чертеж.

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

Кстати в SW есть модуль SW-спецификация, которая по конфигурациям дерева автоматически гененрирует групповую спецификацию.

От себя добавлю что желательно в TF встроить документооборот по принципу CATIA. Т.е. когда ты работаешь в CAD и незаметно для себя строишь дерево сборки.
 
Цитата
Brom25 пишет:

«Плоскость построения».
Да, это действительно нужно. Но предлагаю не отдельную операцию, а расширить возможности существующих рабочих плоскостей. Тогда построение моделей существенно упростится. Но только одно НО - линия построения должна строиться на пересечении выбранных РП, но НЕ ПРОЕЦИРОВАТЬСЯ как в случае с 3D узлами. Нет ничего хуже поднятой геометрии - это "связывает" руки. А так представьте вы создаете новый документ - 3D с рабочими плоскостями, указываете те РП с которых и на которые необходимо построить линии построения. Затем при активизации любой РП вы видите уже созданные базовые линии проходящие через начало координат - в данном случае через пересечение трех РП, при начальном значении 0, 0, 0.
 
Цитата
Сергей Максимов пишет:

это действительно нужно

1 Может лучше доработать команды построения 3Д узла или 3Д пути на пересечении.
2 Можно построить Плоскость используя элементы 3Д профиля.

Кстати Плоскость построения напомнила предлагаемое мной на стр. 1 - применение сопряжений (отношений) к элементам построений - только с точностью наоборот.
 
Цитата
kls пишет:

Кстати Плоскость построения напомнила предлагаемое мной на стр. 1 - применение сопряжений (отношений) к элементам построений - только с точностью наоборот

Точнее частный случай использования сопряжений (отношений) к элементам построений да и то с более жесткой привязкой.
 
Цитата
kls пишет:

Сколько файлов надо иметь если сборка имеет несколько сотен исполнений и состоит из сборочных единий (до пары десятков исполнений)? И каждую из них образмеривать.
Если на сотню исполнений у вас один чертеж нужно иметь один файл.
Когда у вас на каждое исполнение свой чертеж, то образмеривать каждый чертеж это ..... не знать TF.
Я вооще даже не понял суть возражений.
Да хоть тысяча файлов. Образмеривать я буду только отличие от прототипа. И размеры у меня будут без заморочек с конфигурациями. Что проще и быстрее.
 
Цитата
kls пишет:

От себя добавлю что желательно в TF встроить документооборот по принципу CATIA. Т.е. когда ты работаешь в CAD и незаметно для себя строишь дерево сборки.
Дерево сборки это состав изделия или дерево модели или не то и не другое. Какова "сермяжная правда" дерева сборки. Для чего ее использовать?
 
Цитата
Сергей Максимов пишет:

Нет ничего хуже поднятой геометрии - это "связывает" руки.
Насколько я понял под поднятой геометрией подразумевается ассоциативная геометрия. Тада получите коламбур: не ничего хуже валяющейся геометрии - она путает ноги.
Вообще, если серьезно, то иногда хочется получить временную ассоциативность (на момент редактирования) в других системах она называется "Выровнить". Если кто-нибудь мне подскажет, что такое есть в TF буду благодарен.
Изменено: Diso - 01.09.2008 10:58:17
Страницы: Пред. 1 2 3 4 5 6 ... 26 След.