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


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

Механизм «эквивалентных ЛСК» позволил бы системе воспринимать эти две ЛСК как одну и ту же, в независимости от исполнения, и в результате обойтись одним фрагментом на все исполнения.
Но до этого еще очень далеко, так как случай редкий…
Вы натолкнули меня на мысль о возможности простой реализации своей задачи... Большое спасибо. Не такой уж это редкий случай... Вообще стоит подумать о понятии эквивалентных построений. Фактически это построения имеющие разных родителей, но по логическому условию переключающие на себя какую либо ветку построений.
 
Цитата
Diso пишет:

вооще даже не понял суть возраж
Просто мне показаалось что вы имели в виду что надо для каждого исполнения иметь свою 3Д модель и соответственно свой чертеж, т.е. на 50 исполнений - 50 моделей и столько чертежей.
Кстати некоторые фирмачи именно так и предлагают работать, а для удобства купить документооборот.
 
Цитата
Diso пишет:

Дерево сборки это состав изделия или дерево модели или не то и не другое. Какова "сермяжная правда" дерева сборки. Для чего ее использовать

Я не совсем точно выразился имелось в виду состав изделия
 
Цитата
kls пишет:

имелось в виду состав изделия
У меня на памяти TF v.5, с которой собственно и началось моё знакомство с возможностью автоматического формирования состава изделия. Как сильно били TF за использование фрагментов (аналог ссылок ACADa). Просто с этим тогда не умели работать, а теперь без состава изделия CAD и не система. Вообще хочу сказать, что есть у меня подозрения, что автоматическое формирование состава в TF появилось раньше чем где либо.... Во всяком случае в 1998-99 году возможность автоматически формировать состав была открытием, которое подвергалось сильной критике. В основном из-за неумения работать со ссылочными моделями. Тогда и гиперссылки не всеми понимались.
На сегодня, у меня формируется состав не только по компонентам, но и рассчитывается количество материалов (клея) в зависимости от сочетания входящих. Т.е. TF CAD способен автоматически формировать состав со сложными зависимостями входящих. Причем может формироваться состав в любом формате. Я использую Эксел... Так пожелали "местные" программисты ERP системы Аксапта.
 
Цитата
Сергей Максимов пишет:

Нет ничего хуже поднятой геометрии - это "связывает" руки.

Абсолютно согласен.


Цитата
Сергей Максимов пишет:

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

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

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

Вы натолкнули меня на мысль о возможности простой реализации своей задачи... Большое спасибо.

Очень рад :). Сергей Максимов тоже навел меня на мысль… Почему бы не сделать возможность создания рабочей плоскости из другой рабочей плоскости? Представьте, что вместо «плоскости построения» указанным мною способом создается рабочая плоскость. Думаю, это могло бы быть хорошим подспорьем «рисованию» на гранях.

На мой взгляд, существование такого инструмента, как «плоскость построения» абсолютно логично, оправданно и удобно (так как за рабочей плоскостью видны контуры детали). Конечно, должен существовать инструмент, позволяющий отключать видимость для выбранной рабочей плоскости «плоскостей построения», созданных в другой конкретной плоскости (например, отключение видимости для вида «слева», «плоскостей построения» созданных на виде «справа»). А также отключение конкретных «плоскостей построения». В добавок, для «плоскостей построения» должна существовать возможность переназначения родительской рабочей плоскости.
Изменено: Brom25 - 02.09.2008 18:13:01
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Вспомним, как осуществляется построение 3-х видов в 2D. На главном виде при помощи вертикальных и горизонтальных линий построения строится видимые контуры детали. Для получения видимых контуров детали на виде «сверху» правильно использовать существующие вертикальные линии построения «главного» вида. Аналогично с видом «слева», только здесь участвуют горизонтальные линии построения. Таким образом, за счет установления проекционных связей мы «дёргая» за линии построения главного вида изменяем сразу и изображения на других видах.
Цитата
Brom25 пишет:

Начиная строить 3D модель на рабочих плоскостях, мы теряем возможность так просто и удобно изменять содержимое различных рабочих плоскостей (например, виде «спереди» и виде «сверху»), так как они получаются несвязанными.
К слову, простые модели вы также можете создавать от 2D к 3D. Точно также строите три вида на 2D, затем три РП (можно включить параметр "Показать в 3D"), затем профили. После создания тел также можно редактировать, перемещая линии построения. Кстати, в 5-й версии только так и можно было создавать 3D.
Так вот может тогда не "Плоскости построения", а предусмотреть параметр для линий построения, которые вы создаете непосредственно на активизированной РП при привычном сейчас способе моделирования, типа "Показывать на других РП" и список для выбора РП. Теперь перемещая указанные линии построения вы получаете тот же эффект, что и в 2D.
Изменено: Сергей Максимов - 02.09.2008 19:42:01
 
Цитата
Diso пишет:

TF CAD способен автоматически формировать состав со сложными зависимостями входящих

Разве TF может сам определить по дереву построений при генерации спецификации является ли 3Д_фрагмент деталью или сборочной единицей.
SW на это способен.

PS. Я сильно симпатизирую TF, но это не значит что не стоит использовать лучшие стороны других CAD. :applanse:
 
Цитата
kls пишет:

Разве TF может сам определить по дереву построений при генерации спецификации является ли 3Д_фрагмент деталью или сборочной единицей.SW на это способен.

За всё нужно платить. SW платит тем, что у него есть файл .sldprt, а есть .sldasm. В таком случае различать их очень просто.
 
Цитата
kls пишет:

TF может сам определить по дереву построений при генерации спецификации является ли 3Д_фрагмент деталью или сборочной единицей.
Этим занимается DOCs. Но по опыту скажу, что работа с составом не тревиальна. В моем случае например, каждая вставленная деталь приносит еще несколько сопутствующих деталей (крепления, накладки, прокладки и т.п.) и DOCs тупо определяет все это сборкой. Приходится каждый раз ручками водить, дерево DOC-са сортировать. А штатный TF CAD-овский механизм эту задачу легко переваривает. Хотя согласен, что перед этим нужно правильно расставить все флажки. Но ввиду специфики мне это приходится делать один раз при создании определенного типа детали или изделия и затем использовать это многократно.
 
Цитата
kls пишет:

Разве TF может сам определить по дереву построений при генерации спецификации является ли 3Д_фрагмент деталью или сборочной единицей.
Если перед вставкой фрагментов для них определены данные для спецификации, то все делается автоматически.
 
Цитата
Сергей Максимов пишет:

Так вот может тогда не "Плоскости построения", а предусмотреть параметр для линий построения, которые вы создаете непосредственно на активизированной РП при привычном сейчас способе моделирования, типа "Показывать на других РП" и список для выбора РП. Теперь перемещая указанные линии построения вы получаете тот же эффект, что и в 2D.
Голосую за! Парадигма построений из 2D к 3D часто дает значительные преимущества. И если предлагаемый инструмент упростит и визуализирует задачу ортогональных преобразований, это обогатит TF потенциалом классической начертательной геометрии. Пока по сути сказать ничего не могу... Кроме :applanse:
 
Цитата
Сергей Максимов пишет:

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

В общем, это я и имел ввиду. Название "плоскость построения" я дал не случайно. Предлогаемый инструмент должен в умах пользователей восприниматься именно как плоскость, иначе возникнет непонимание - как вертикальная линия построения, созданная на виде "спереди" может отображаться на виде "сверху"? Т.е. допускаю, реализация - как предлагает Сергей Максимов, но абстрактно должно восприниматься как плоскость.
Единственное, что хочу добавить - различие в отображении линий построений и "плоскостей построений" должно иметь место.
Забегая вперед, могу отметить, что введение "плоскостей построений" должно породить еще один способ построения 3D узла - на пересечении "плоскостей".
Изменено: Brom25 - 03.09.2008 14:05:01
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

иначе возникнет непонимание - как вертикальная линия построения, созданная на виде "спереди" может отображаться на виде "сверху"? Т.е. допускаю, реализация - как предлагает Сергей Максимов, но абстрактно должно восприниматься как плоскость.
Но ведь вертикальная линия которая отображается как единая прямая на виде сверху и виде спереди и есть абстракция плоскости.
Хотелось бы чтобы плоскость построения визуально складывалась и раскладывалась как книжка на целевую плоскость. Как раз для того, чтобы визуализировать абстракцию ортогональных преобразований и предоставить возможность связать два или несколько видов едиными линиями построений.
Таким образом, в моем понимании, плоскость построений должна получиться в результате ортогонально преобразованных (совмещенных) нескольких рабочих плоскостей в одну плоскость.
И этот процесс доступен для визуализации, когда визуализируются линии "разгиба" и ортогональные рабочие плоскости разгибаются в одну плоскость.
Это несколько отличается от тезиса приведенного в цитате, потому как там подразумеваются линии видовых связей, которые также необходимы в данном инструменте, поскольку эти линии перпендикулярны линиям "разгиба" (линиям преобразований). Следовательно имеют целевое значение и принадлежность двум видам.
 
Цитата
Diso пишет:

предоставить возможность связать два или несколько видов едиными линиями построений.
Здесь я имею ввиду линии видовых связей.
 
В контексте разговора о плоскости построений хотелось бы чтобы рабочие плоскости на ней отображались отдельными видами. И здесь становится очень важной "прозрачная" активизация чертежных видов.
 
В контексте разговора о чертежных видах хотелось бы поправить понятийный аппарат и выстроить его в соответствии со следующей логической цепочкой:
1. В файле помимо всего прочего содержится лист (страница), которая не имеет масштаба (поскольку бумага плохо тянется ;) ).
2. Н алисте располагается один или несколько видов со свойством "масштаб".
3. На листе располагаются элементы оформления не имеющие свойства масштаба, но привязанные к элементам изображения.
4. Линии построения принадлежат только одному виду и визуализируются при активизации данного вида.
5. Видовые связи устанавливаются специальным типом линий между видами с равными масштабами.
Изменено: Diso - 03.09.2008 18:26:35
 
Цитата
Alisa пишет:

SW платит тем, что у него есть файл .sldprt, а есть .sldasm.

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

Если перед вставкой фрагментов для них определены данные для спецификации, то все делается автоматически.
Цитата
Diso пишет:

Этим занимается DOCs и т.д.

Со всеми согласен.
Но если если 3Д_фрагмент состоит из вложенных 3Д_фрагментов, то что мешает системе определить его как сборочную единицу.

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

Приходится каждый раз ручками водить, дерево DOC-са сортировать

Тогда уже лучше в TF интегрировать документооборот как в CATIA.
 
Ну, Diso, Вы блин даете. :oops: :( - Мне в Ваших сообщениях похоже без бутылки не разобраться... ~~:-
 
Цитата
Diso пишет:

Но ведь вертикальная линия которая отображается как единая прямая на виде сверху и виде спереди и есть абстракция плоскости.

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

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

Хотелось бы чтобы плоскость построения визуально складывалась и раскладывалась как книжка на целевую плоскость.

Не нужно ничего визуализировать (анимировать). Достаточно того, что «плоскости построения» будут видны из активной рабочей плоскости.

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

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

Не понимаю, зачем складывать плоскости?... Я думаю, нет смысла гадать, как это предложение будут реализовывать сотрудники Топ Систем. Все равно реализация у них будет своя, причем, уверен, даже лучше, так как к «нашим головам прибавятся их головы». Важно то, что при разработке функционала они будут учитывать наши пожелания (если вообще примут это предложение).
Изменено: Brom25 - 03.09.2008 22:19:39
Кто ищет - тот всегда найдет!
 
Цитата
B_S_V пишет:

Если перед вставкой фрагментов для них определены данные для спецификации, то все делается автоматически.
Это уже не автоматически. Задаёт пользователь. Но в целом, Вы правы. Если мы задаём параметры фрагмента для спецификации, почему бы не внести туда и раздел, в который она попадёт. Всего за два клика
Страницы: Пред. 1 2 3 4 5 6 ... 26 След.