Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель:
ООО «АСКОН-Системы проектирования»

ИНН 7801619483 ОГРН 1137847501043

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

3 - 2017

Организация доступа к параметрам отдельных деталей из среды сборочной модели в Autodesk Inventor

Роман Герасимов
Ассистент кафедры технологии машиностроения и технологического оборудования Северо­Кавказского федерального университета (СКФУ).
Сергей Сидоренко
К.т.н., доцент кафедры технологии машиностроения и технологического оборудования Северо­Кавказского федерального университета (СКФУ).
Вячеслав Черниговский
К.п.н., доцент кафедры технологии машиностроения и технологического оборудования Северо­Кавказского федерального университета (СКФУ).
Маргарита Мелихова
Старший преподаватель кафедры технологии машиностроения и технологического оборудования Северо­Кавказского федерального университета (СКФУ).

В настоящее время при организации процесса разработки новых изделий с применением систем автоматизированного проектирования (САПР) принято выделять два основных метода проектирования: восходящее (снизу вверх) и нисходящее (сверху вниз) проектирование. Каждый из указанных методов обладает своими достоинствами и недостатками и предназначен для решения определенного круга задач. Например, метод проектирования снизу вверх используется в случае разработки типовых механизмов с заранее известной структурой, не требующей наличия принципиальной схемы будущего изделия в информационном поле модели, в то время как при проектировании сверху вниз включение принципиальной компоновки изделия в информационное поле модели является одной из основных задач [1, 2].

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

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

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

Рис. 1. Схема восходящего проектирования

Рис. 1. Схема восходящего проектирования

В случае наличия сложной структуры связей между конструктивными элементами деталей, например аналогичной схеме, представленной на рис. 2, потребуются существенные временные затраты, а смена исполнителя может и вовсе привести к невозможности внесения изменений за адекватный временной интервал.

Рис. 2. Схема распределения связей между деталями

Рис. 2. Схема распределения связей между деталями

При использовании метода нисходящего проектирования рассматриваемая ситуация несколько упрощена за счет внедрения в информационное поле модели принципиальной схемы изделия [3], являющейся местом сосредоточения основных параметров деталей и правил их расположения, как показано на схеме метода, представленной на рис. 3.

Рис. 3. Схема нисходящего проектирования

Рис. 3. Схема нисходящего проектирования

Как правило, принципиальная схема будущего изделия представляет собой отдельную деталь с эскизной или многотельной компоновкой будущего изделия [4], а следовательно, ее изменение требует выполнения перехода между средами разработки, как и при восходящем проектировании. Кроме того, необходимо отметить факт отсутствия в принципиальной схеме изделия всех параметров, полностью описывающих конструкцию отдельных деталей, что означает возникновение необходимости перехода не только к схеме изделия, но и к деталям, созданным на ее основе.

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

Реализация системы связей между деталями может осуществляться двумя способами: непосредственной передачей значений переменных одной детали или сборочной единицы другим, или же группированием всех необходимых параметров в электронной таблице MS Excel c ее последующей интеграцией в файлы деталей при помощи штатных средств.

Следует отметить, что ни один из описанных выше способов, доступных в САПР Autodesk Inventor по умолчанию, не позволяет в полной мере решить задачу изменения деталей без перехода между средами. Например, непосредственная передача значений переменных от одной детали к другой, в данном случае от сборки к деталям, вызовет появление циклических зависимостей и не позволит применять зависимые детали в рамках среды сборочной модели, из которой транслируются управляющие параметры, из­за возможности создания лишь односторонних связей, пример чего показан на рис. 4.

Рис. 4. Схема построения связей параметров

Рис. 4. Схема построения связей параметров

Использование электронных таблиц в качестве концентраторов переменных позволяет избежать возникновения цикличности, но при необходимости внесения изменений в конструкцию потребует перехода не только между рабочими средами САПР, но и между программными продуктами.

В то же время актуальные версии Inventor содержат модуль управления моделями на основе логических правил iLogic, позволяющий существенно расширить возможности системы и снимающий ряд ограничений при реализации связей параметров. Указанный модуль позволяет избежать цикличности при распределении параметров напрямую между деталями и дает возможность изменения значений переменных, сгруппированных в электронных таблицах без их непосредственного открытия пользователями, то есть как раз и создает возможность организации процесса изменения конструкции изделия без перехода между средами разработки.

В качестве примера организации такой схемы работы можно рассмотреть процесс проектирования корпусной мебели, на начальном этапе которого пользователем создается файл сборочной модели, в котором прописываются основные пользовательские параметры, например ширина, высота, глубина и пр., как показано на рис. 5.

Рис. 5. Создание пользовательских параметров

Рис. 5. Создание пользовательских параметров

Следом за созданием файла сборочной модели создается файл электронной таблицы, в который осуществляется выгрузка необходимых параметров при помощи правила, созданного в модуле iLogic, пример которого представлен на рис. 6.

Рис. 6. Правило трансляции параметров

Рис. 6. Правило трансляции параметров

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

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

Предложенный вариант организации работы с управляющими параметрами обеспечит преобразование схемы проектирования, представленной на рис. 3, путем объединения сборочной модели с принципиальной схемой изделия, пример чего продемонстрирован на рис. 7.

Рис. 7. Модернизированная схема проектирования

Рис. 7. Модернизированная схема проектирования

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

Рис. 8. Пример изменения положения деталей

Рис. 8. Пример изменения положения деталей

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

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

Список литературы:

  1. Димитрюк С. Методы организации работы над сборочными моделями // САПР и графика. 2002. № 11. URL: http://sapr.ru/article/8167 (Дата обращения 03.03.2017 г.).
  2. Фирсов В.А. Проектируем или только моделируем? Критический взгляд на технологию работы в CAD­системах // CAD/CAM/CAE Observer. 2008. № 7. http://www.cadcamcae.lv/hot/Firsov_n43_p42.pdf (Дата обращения 03.03.2017 г.).
  3. Гаршин О., Московченко А. Преимущества нисходящего проектирования на примере использования Pro/ENGINEER WILDFIRE // САПР и графика. 2004. № 11. URL: http://sapr.ru/article/14915#1 (Дата обращения 03.03.2017 г.).
  4. Мастер Модель. Часть 1: Обзор // Очередной блог о САПР. URL: http://www.saprobasni.ru/2010/09/1_13.html (Дата обращения 03.03.2017 г.

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ООО «А-Кор»

ИНН 9731125160 ОГРН 1237700820059

Рекламодатель: ООО «ПЛМ Разработка»

ИНН 6658560933 ОГРН 1236600010690

Рекламодатель: ООО «КЭЛС-центр»

ИНН 7707548179 ОГРН 1057746796436

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557