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


Поиск  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1 2 3 4 След.
Методика Проектирования
 
Цель темы: Совместными усилиями пользователей TF разработать методику ПРОЕКТИРОВАНИЯ ИЗДЕЛИЯ и добиться от разработчиков TF внести необходимые коррективы в программу для обеспечения процесса проектирования по выработанной методике. Методика должна поддерживать следующие этапы проектирования:
концептуальная компоновка
деление изделия на составные части
проработка детали и ее технологическое уточнение в контексте узла
контрольная сборка изделия (проработка детали и узла в контексте изделия)
оформление рабочей конструкторской документации
У меня есть такая методика. Можно обсудить с заинтересованными людьми.
Хватит спорить кто «румяней и милее». Пора заняться серьезным делом и помочь разработчикам быстрее двигаться правильным путем. А сделать это они смогут, только прислушиваясь к нашим требованиям.

РАЗРАБОТЧИКАМ! Ни одна из систем среднего класса не дает конструктору возможность ПРОЕКТИРОВАТЬ. В последних версиях SE и SW появились задатки для проектирования. В TF это есть и давно. Надо воспользоваться этим преимуществом иначе будет туго.
 
Ну так написали бы сразу для разработчиков, какие Вы видите проблемы! А то всё закамуфлировано ка-то.

И ещё. Я смотрел версию 9.38. Там многие проблемы, которые я видел при редактировании деталей в контексте сборки, ликвидированы.
 
ckal, да вы прям мои мысли читаете.
Но методику которая в конечном итоге получится лучше обкатать через API-функции на своей машине. Так мне ответили разработчики. Тоже есть задумки, можем обменяться и подумать вместе.

А контекст, думаю в любой программе - ерунда по большому счету. То что построено на грани или ребрах, при удалении последних становиться, в лучшем случае "мертвым". И сравнение самоката с автомобилем здесь не уместно! (для IVA_77)
 
Возникающие проблемы я, конечно, отсылаю разработчикам. А одна из целей форума как раз и заключается в том, что бы нам пользователям обращаться к разработчикам с просьбой «единым фронтом» и они оперативнее откликались на нее.
Разговор идет не о каком либо контексте, а о методике коллективного проектирования. Поэтапно она выглядит так:
Компоновочная схема – Составная часть – Конструктивный элемент – Рабочая модель – Контрольная сборка.
 
Цитата

РАЗРАБОТЧИКАМ! Ни одна из систем среднего класса не дает конструктору возможность ПРОЕКТИРОВАТЬ. В последних версиях SE и SW появились задатки для проектирования. В TF это есть и давно. Надо воспользоваться этим преимуществом иначе будет туго.

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

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

Проектировать:
Составлять проект.

В таком понимании действительно, как мне кажется, может получиться интересный разговор. А именно: как, максимально используя возможности T-Flex, создать конструкцию. По какому плану? Какие эвристические методы решения задачи наиболее полно отвечают возможностям TF. Например: я конструировала гидроцилиндр, как многотельную деталь, пересчитывая её переменные через свойства материала (сигма-т, дельта) и требуемые параметры (ход, усилие, рабочее давление). Это удобно тем, что линии построения одни и те же для разных деталей. Потом надо было бы сохранить каждое отдельное тело, как деталь, (к сожалению, эту операцию учебная версия не поддерживает), потом, по идее, можно было бы сделать чертежи. Неплохо было бы обсудить, насколько оптимален такой план. Нет ли лучших способов решения задачи?

Может, попробуем говорить в таком ключе? Это, так сказать, набросок к эскизу.

[quote]
 
Цитата
Разговор идет не о каком либо контексте, а о методике коллективного проектирования. Поэтапно она выглядит так:
Компоновочная схема – Составная часть – Конструктивный элемент – Рабочая модель – Контрольная сборка.

Не вылезал у меня из головы этот вопрос. Давайте поэтапно. Первый этап Компоновочная схема - Составная часть. У меня в виде компоновочной схемы по сути дела габаритная "болванка", которую я передаю конструктору с требованием не вылезать за габариты. Он её вставляет в свою сборку и начинает редактировать "свой" узел (у вас - Составная часть). Вы работаете так же? Поделитесь, если можно.
 
Вообще то само по себе проектирование складывается из ПЯТИ основных этапов (я думаю вы все их знаете):
1. Тех. задание.
2. Тех предложение.
3. Эскизный проект (концептуальная компоновка, проработка детали и ее технологическое уточнение в контексте узла).
4. Технич. проект (деление изделия на составные части).
5.Рабочий проект (оформление рабочей конструкторской документации).

И потом под какой тип производтсва у Вас есть методика. Вы наверно со мной согласитесь, что под, что на разных предприятиях, своя методика. Если речь идет о каких-то общих принципах, то я лично готов Вас поддержать в этом нелегком деле.
 
Вы безусловно правы, это общепринятая схема, причём проверенная. Но уже на стадии эскизного проекта у каждого предприятия, как Вы верно заметили, свои особенности. Моя особенность: я разрабатываю оборудование для металлургии. Двух одинаковых машин не бывает. Сроки проектирования сжаты до предела - 3 машины (с гидроуправлением), в каждой порядка 1,2 тыс. деталей - 4 месяца (разумеется, машины делаются не с нуля, переработки не более 30%). Весьма существенным фактором является коллективная работа. Как организовать её, чтобы она шла с максимальной скоростью (но не в ущерб качеству!)? Для меня, например было бы прекрасно, если бы в компоновочной схеме могло работать одновременно(!) два человека. Отпадает необходимость постоянно корректировать общую сборку. На кульмане это решается просто. А как это сделать на компьютере? Здесь-то и начинаются чисто методические вопросы. Вопросы общей методики. Кульмановские методы непригодны по определению.
 
Алиса права! Умница! Речь идет как раз о методике компьютерного проектирования в коллективе разработчиков. Какое предприятие и что проектируете абсолютно бес разнице. Проектирование в коллективе идет по нарастающей. Вед. констр. (пусть будет так) создает файл «Сборка верхнего уровня» с идеей изделия с элементарными пространственными построениями, эти построения выгружаются в файлы как задание для руководителя бригад конструкторов. Рук. бригады на этих построениях создает более сложные построения (тела или поверхности) и выгружает их в файлы как задание для конструкторов. Конструктор уже делает детальную проработку узла и выгружает в файлы ДЕТАЛИ для оформления чертежа техником. Группа вед. констр. из узлов и деталей собирает «Обзорную сборку» доступную для всех участников проекта а качестве контекстного редактирования своих деталей и узлов.
firsovva@nexcom.ru
 
А в чем проблема ? Что мешает реализовать выше указанную методику ?
 
Доступ к файлу. Редактировать файл может только один человек. У других он открывается только для чтения. Правда, есть возможность редактировать фрагменты, но чтобы эти изменения были видны у других, нужно перезагружаться. Собственно говоря, размножиться нетрудно, но как потом всё собрать в кучу? Строить сборку с самого начала? Вот меня и заинтересовал вопрос, кто как строит такую работу. Для меня это тем более актуально, что мои сотрудники иной раз живут в другом городе.
 
Где находятся сотрудники - в другом городе или за соседним столом без разницы. Маленький колектив, в который мы делали проекты (витражи, зимние садики и т.д. и т.п.) и в которм наша работа строилась на 2 "китах". Изначально велось проектирование "сверху-вниз" (хватало иногда устного обсуждения кто и что делает), а далее наоборот. Да, мы потратили 1 неделю на т.н. "притирание", а дальше все просто. Бери больше - кидай дальше
 
В общем, это пока так и делается. Но моя продукция - машины. Соседи в разных узлах должны, грубо говоря, быть как можно ближе друг к другу и в то же время не пересечься. Плюс узлы надо состыковать. Если это делать простыми средствами, то кто-то третий постоянно должен стоять у них над душой. Они сами должны всё видеть. Иначе корректировки займут 3/4 времени конструирования. Поэтому мне важно, чтобы работа одного из них отражалась на мониторе другого. В принципе, такая возможность, как мне кажется, у TF есть. Только я никак не могу "поймать её за хвост".
Что касается многопользовательской среды, то без PDM (а ещё лучше PLM), похоже, здесь вообще делать нечего.
 
PDM, PLM это игра слов.Я сейчас работаю на Catia16+SmartTeam.Последний это PDM.
Так вот SmartTeam отслеживает только изменения и доступ. А вообще, представте себе: один кульман с ватманом и за ним стоят 3 или 4 конструктора, которые что-то делают.Один чертит, а другой сразу стирает.Вообразили? Вот что хочется - доступ к одному файлу нескольких пользователей одновременно.Теоретически возможно.Да только что это будет?Проведешь одну линию и сразу выставляй ей приоритет или доступ. Иначе Сидоров(Петров) ее удлинит или укоротит.А?
 
Насчёт кульмана могу поделиться опытом, когда один конструктор разрабатывает одну часть механизма, другой другую, потом это склеивается, дорисовываются (кем-то одним, понятно) стыковки и... сборка готова! Разговор не о возможности редактировать, а о возможности видеть чужую редакцию. Сколько раз мне приходилось сталкиваться со случаем, когда я вставляла в свою сборку чужую, привязывалась к ней, а потом всё это рассыпалось, потому что автор подсборки внёс изменения, а я их не видела. И начинается... ну, вы понимаете. В итоге, как ни крути, а параллельная работа не получается. Я делаю габаритную болванку, сижу, жду, пока мои сотрудники разработают узлы, потом они сидят, ждут, пока я всё это состыкую, выдам требования на корректировку, сижу, жду... Порой мне кажется, что одна я бы быстрее с работой управилась. Конечно, многое от того, что у меня нет опыта организации таких работ. Поэтому тема методики мне и интересна.

Кстати, PDM отслеживет доступ к файлу и внесение изменений и не даст просто так кому попало что-то поменять.
 
В этом то и дело. Сам механизм доступа к одному документу, находящегося где-то на сервере возможен только по схеме: 1 редактирует - остальные наблюдают. И реализовать многопользовательский доступ на редактирование одного файла физически не возможен. Попробуйте из того же Windows удалить файл который занят приложением или открыть его, скажем блокнотом и что-нибудь там изменить. Ну как получилось? Тоже самое и здесь. Я считаю надо уличшать саму систему проектирования, чтобы она позволяла изменять контрукцию любой сложности за очень короткий срок и не вылетала с ошибками при изменении положения отверстия (это я к примеру), чтобы не тратить 3/4 времени проектирования на стыковку разных узлов. Каждый зделал свой узел, затем ведущий контруктор, или начальник бюро собрал все эти узлы у себя на машины и дал распоряжения всем или отдельным взятым конструкторам задание на корректировку тех или иных параметров.
 
Немного иформации я работаю на фирме в которой реализован сквозной цикл проектирования.Т.е. CAD+PDM интегрированы в SAP R/3.В течение 2-х лет я наблюдаю(и естественно учавствую) вес процес проектирования и запуска в производство.Так вот чудес не бывает.Вкратце все выгледит так:есть главный конструктор(руководитель проекта) он создает описание объекта проектирования.описывает узлы и т.д. и т.п., а затем проект делится по конструкторам и создается СЕТЕВОЙ ГРАФИК работ.Об этой методике работ почему-то все забыли и требуют (или желают ) от программ коллективного доступа к одному файлу. Чушь какая-то! А PDM-реализует малую толику функций отдела тех. док-ии.Это учет и внесение изменений. А КТО-либо видел программу, которая реализует функцию проведения изменений до дате или еще хлеще по номеру изделия?
 
Алисе.
Работа с одним файлом одновременно (если это не база) - чушь. Один делает сборку, остальные подсборки и детали. Знаете, как организовывается работа группы программистов? Руководителем определяется набор функций (подпрограмм) для разработки (входные данные, алгоритм работы - возможно укрупненный, выходные данные). А тот, кто собирает все это использует обращения к этим функциям. До появления отлаженных функций возможна работа сборщика с иммитаторами функций - т.е имя уже есть и перечень переменных с какими-то значениями, а детального алгоритма еще нет. Я думаю и работу группы разработчиков изделий нужно строить таким же образом. А функция - обновить данные фрагментов в T-Flex имеется.
Страницы: 1 2 3 4 След.