По всем вопросам звоните:

+7 495 274-22-22

О вариативности сборок — нужно ли программировать в САПР

Стремнев А.Ю. канд. техн. наук, доцент кафедры информационных технологий, Белгородский государственный технологический университет им. В.Г. Шухова

Широкие функциональные возможности современных САПР ориентируют пользователей на использование штатных инструментальных средств. В статье рассмотрен пример задачи, связанной с многовариантным конструированием, и задействование на ее примере механизмов скриптового программирования, таких как iLogic системы Autodesk Inventor.

Литература:

1. Online‑справка по использованию iLogic в Autodesk Inventor // https:// knowledge.autodesk.com/ru/support/ inventor/learn‑explore/caas/CloudHelp/ cloudhelp/2017/RUS/Inventor‑Help/ files/GUID‑AB9EE660‑299E‑408FBBE1‑AFE44C723F59‑htm. html

2. Архив рассматриваемого в статье проекта (Autodesk Inventor 2018) // https://yadi. sk/d/gNwd8Y2FNXtQWA

Современные системы автоматизированного проектирования уже довольно далеко ушли вперед от концепции классического «электронного кульмана».

В арсенале САПР: параметризация, библиотеки стандартных деталей и узлов, ассоциативность чертежных видов и 3D-моделей, кинематические и динамические анализы сборок. Причем не только вышеперечисленные, но и многие другие возможности доступны на самом высоком (пользовательском) уровне. Это означает, что для задействования широкого функционала САПР достаточно руководствоваться принципом: «нажал кнопку — программа выполнила». Имеет ли смысл «забираться под капот» — адаптировать существующие инструменты или создавать новые? Ответ на этот вопрос даст только практика.

Рассмотрим задачу подготовки многовариантной сборки в системе Autodesk Inventor. Объект проектирования — условный автотягач, представляющий собой универсальный модуль с кабиной управления и различными типами ходовой части и грузовой платформы (рис. 1).

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

Для реализации различных типов шасси и кузова создадим отдельные файлы, в которые в качестве подосновы (командой Derive (Производный компонент) из вкладки Manage (Управление)) вставим уже спроектированный базовый универсальный модуль. Образующие его тела будут служить источником ссылочной геометрии (рис. 3).

Например, элементы модуля-основы можно спроецировать в эскизы модели грузовой платформы с помощью инструмента Project Geometry (рис. 4). Относительно проекций удобно проставлять размеры. Кроме того, при изменении модели-прототипа (кабины) будет происходить ассоциативное перестроение производного узла (кузова).

Используя модуль-основу, подготовим в отдельных файлах несколько версий кузова и шасси (рис. 5).

Для сборки готовых компонентов необходимо предусмотреть их соединение по унифицированной схеме — идентичным геометрическим элементам. Для реализации этой концепции в Autodesk Inventor имеется механизм iMate, когда для будущей сборочной зависимости в каждом из соединяемых узлов определяются однотипные и одноименные конструктивные пары. Сначала набор таких связей мы создадим в универсальном модуле (кабине), указывая объекты геометрии для будущего соединения (рис. 6).

Для Цитирования:
Стремнев А.Ю., О вариативности сборок — нужно ли программировать в САПР. Конструкторское Бюро. 2020;1.
Полная версия статьи доступна подписчикам журнала
Язык статьи:
Действия с выбранными: