Вариативность сборок и программирование в САПР

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

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

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

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

Рис. 1

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

Рис. 2

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

Рис. 3

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

Рис. 4

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

Рис. 5

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

Рис. 6

«Встречно­ответные» конструктивные пары (iMates) следует предусмотреть также и в каждом из вариантов грузовой платформы (рис. 7).

Рис. 7

Остается сформировать итоговую сборку и вставить в нее нужные модули: во­первых, передний мост с кабиной, а во­вторых, один из вариантов кузова. Одноименные пары iMates соединим командой Constrain (Зависимости) — рис. 8.

Рис. 8

На данном этапе в проекте имеется несколько файлов, соответствующих разным типам кузова и шасси, соединяемых с кабиной (рис. 9). Заменять один вариант на другой можно вручную командой Replace (Замена) из вкладки Assembly (Сборка). Но оперативным такой путь назвать сложно. Тем более если при переконфигурировании требуется заменить не один, а несколько десятков компонентов. Попробуем автоматизировать этот процесс, опираясь на скриптовые возможности САПР Autodesk Inventor.

Рис. 9

Во­первых, в сборке создадим переменную­инициатор события для запуска скрипта. Для этого воспользуемся инструментом iTrigger из вкладки Manage (Управление). Имя и значение переменной­инициатора (iTrigger0) можно найти в таблице параметров модели (рис. 10).

Рис. 10

Далее добавим в сборку новое правило командой Add Rule из той же вкладки Manage (рис. 11). После этого в области браузера открывается секция iLogic, которая предназначена для доступа к пользовательским правилам и формам. Например, выбранное правило­скрипт вызывается на редактирование командой Edit Rule.

Рис. 11

Окно редактора скриптов имеет структуру, показанную на рис. 12. Слева расположена библиотека доступа к наборам стандартных функций и элементам объектной структуры Inventor. Справа находится рабочая область для непосредственного редактирования кода. Над рабочим полем размещен браузер модели, который позволяет выбирать требуемые параметры для их вставки в скрипт. Каждое правило является фактически отдельной процедурой, запуск которой согласуется с определенным событием или изменением переменной­инициатора. В нашей задаче событие­инициатор реализуется строкой:

trigger=iTrigger0.

Затем с помощью функции Parameter мы считываем переменную­инициатор в служебный параметр:

v=Parameter(«iTrigger0»).

Анализируя его значение, например, посредством оператора If, будем осуществлять переконфигурирование сборки сменой варианта конструкции грузовой платформы. Функцию замены (Replace) найдем в объектной структуре окна скрипта (секция Components) и добавим ее в код в следующем виде:

Component.Replace(«Вариант», «Вариант_1.ipt», True)

Заменяемый компонент является первым аргументом функции Replace, и ему целесообразно сразу же дать уникальное имя (например, Вариант), чтобы в качестве него подставлять файлы конфигураций, имеющих конкретные имена (Вариант_1.ipt, Вариант_2.ipt, ...)

Рис. 12

Допустим, что скрипт для смены конфигурации сборки готов. Теперь для его запуска необходимо организовать изменение значения переменной­инициатора. Конечно, можно осуществлять это с помощью окна параметров (см. рис. 10), но гораздо удобнее сгенерировать простую форму пользовательского интерфейса. Для этого перейдем на вкладку Forms (Формы) в панели iLogic и выполним контекстную команду Add Form (Добавить форму) — рис. 13.

Рис. 13

В окне редактора форм перенесем параметр­инициатор из секции Parameters в таблицу­конструктор формы (рис. 14). При этом на форме будет автоматически создан элемент для ввода этого параметра. В качестве типа элемента управления (Edit ControlType) в таблице свойств зададим Slider. Укажем также минимальное и максимальное значение параметра в слайдере (в соответствии с количеством предусмотренных вариантов реализации грузовой платформы).

Рис. 14

Проверим вариацию сборки, запустив пользовательскую форму на выполнение. Для этого в панели iLogic в секции Forms щелкнем по кнопке с именем формы (рис. 15).

Рис. 15

Изменяя в окне формы позицию движка на элементе­слайдере, будем редактировать переменную­инициатор события для запуска скрипта, изменяющего конфигурацию сборки (рис. 16 и 17). Напомним, что переменная­инициатор, в свою очередь, определяет тип конфигурации и вариант для смены компонентов (см. рис. 12).

Рис. 16

Рис. 17

Таким образом, за счет добавления всего нескольких строк программного кода сборка Autodesk Inventor переконфигурируется, что называется, одним движением мыши. Конечно, для написания этих строчек понадобились некоторые навыки владения практически настоящим языком программирования (основой скрипта является небезызвестный Visual Basic), но разве не автоматизацию проектных процедур олицетворяет единственная гласная буква в аббревиатуре САПР (CAD)? 

Полезные ссылки:

1. Online­справка по использованию iLogic в Autodesk Inventor
2. Архив рассматриваемого в статье проекта (Autodesk Inventor 2018)