12.07.2015 Views

ОПЫТ ИСПОЛЬЗОВАНИЯ ILOGIC AUTODESK INVENTOR

ОПЫТ ИСПОЛЬЗОВАНИЯ ILOGIC AUTODESK INVENTOR

ОПЫТ ИСПОЛЬЗОВАНИЯ ILOGIC AUTODESK INVENTOR

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>ОПЫТ</strong> <strong>ИСПОЛЬЗОВАНИЯ</strong> <strong>ILOGIC</strong> <strong>AUTODESK</strong> <strong>INVENTOR</strong>Рисунок 1 – Тестовая детальВ своей довольно плотной ежедневной работе с Autodesk Inventor я стараюсь максимальноизучать все стороны продукта, чтобы решать возникающие задачи наиболее эффективным путем.Одной из интереснейших, на мой взгляд, надстроек является iLogic – VB-подобная среда разработки,очень тесно интегрированная в Inventor. Программисту в моей душе она пришлась по нраву, так каквместе со стандартными макросами iLogic открывает обширное поле для творчества. Встроенные жефункции, завязанные на редактирование свойств моделей, управление параметрическими элементамии документами целиком, позволят инженерам сосредоточиться на решаемой задаче, а не вникать вдебри незнакомого синтаксиса (хотя, для желающих - изучение API никто не отменял). В этой статьея приведу некоторые интересные примеры из личной практики.При выполнении сборочных чертежей в Inventor я столкнулся с невозможностью реализоватьтребования ГОСТ 2.109-73. Имеется в виду пункт, согласно которому не следует показывать начертеже мелкие фаски и сопряжения. Поначалу казалось, что ничего страшного в этом нет: можетпрограмма отобразить на чертеже все – пусть рисует. Однако минусы у такого подхода определенноесть. Это нечеткие углы деталей, нечитаемая мешанина из мелких элементов в проточках, а такжевозникающие порой ошибки нанесения размеров вследствие ошибочной привязки выносных линий.Проблема легко решается подавлением нужных элементов в дереве построений деталей вручную, ноесли дерево большое, а деталей много, то данный подход совершенно не применим.Решить проблему можно с помощью внутренних средств Autodesk Inventor, чтобы решениеобладало максимальной гибкостью. В данном случае удобным является использование средствподсистемы iLogic, предоставляющей все необходимое.Итак, задача номер один: быстро и безболезненно подавить все мелкие сопряжения и фаски втестовом файле детали (рис. 1). Создаем новое правило iLogic, и в открывшемся окне, в столбцеслева, раскрываем список «Элементы» и находим в нем строчку «IsActive». Это ключевой элементнашей тактики – строчка кода позволяет подавить/восстановить элемент дерева построения,указанный по имени («Фаска1» и проч.). Остается реализовать перебор всех фасок и сопряжений ипрятать те из них, которые подходят под описание «мелкий элемент».Приведу немного кода с пояснениями. Итак, вот часть работающего правила (тут подавляютсясопряжения с радиусом меньшим 0,5 мм):


Что тут происходит? Все довольно просто.Блок «Try – Catch – End Try» присваивает переменной fillet объект дерева построения«Сопряжение» с порядковым номером, который задается переменной-счетчиком i. Далее получаемдоступ к списку параметров выбранного сопряжения, и если величина радиуса не превышаетзаданную величину (тут 5 мм), то подается команда подавить данный элемент.В конце цикла счетчик увеличивается на 1, и все повторяется для следующего элемента.Естественно, если заменить строку «Сопряжение» на «Фаска» в правиле, то аналогичные действиябудут применены к фаскам.Код работает, однако в нем самом кроется забавная проблема: выход из цикла перебораосуществляется по возникновению ошибки несуществующего имени. Конкретнее, если конструкция(“Сопряжение”+CStr(i)) дает несуществующее имя элемента, цикл прерывается. Непорядок втом, что если в детали нарушена нумерация элементов (скажем, редактировали геометрию, удалялифаски – и после «Фаска4» идет «Фаска7»), то правило обработает деталь ровно до такого разрыва.Получится ситуация, которая приведена на рисунке 2.Рисунок 2 – Ошибка в логике правилаПолистав раздел справки «Информация для программистов», я обнаружил возможностьполучить ссылку на коллекцию фасок/сопряжений текущей детали. Это решает проблему спропусками – нам становится не важно, как называется элемент, если он нужного типа. Слегкаизменяем предыдущий фрагмент кода:


В самом начале мы получаем ссылку на текущий документ детали и его составляющие(первые две строки). Затем следует уже знакомый цикл перебора, только вместо вызова элемента поимени, мы перебираем элементы в коллекции сопряжений (строка между «Try – Catch»).Аналогично можно поступить и для фасок. В таком виде правило начинает беспроблемно работать,но это только деталь. Нашей целью является сборка, то есть требуется выполнить данные действиядля каждой детали в сборке.Такая задача несколько сложнее, так как нужно реализовать «двойной» перебор – обходкаждой детали в дереве сборки, и обход фасок/сопряжений внутри деталей. Также было бы отличнымвариантом спросить у пользователя, требуется скрыть или отобразить мелкие элементы, и размер,который будет считаться критерием «мелкости».Для создания простейших диалоговых окон в редакторе iLogic есть все необходимое – целыйраздел «Сообщения» в списке элементов справа. Два сообщения типа InputBox решают проблему:, а такжеПотребуется конструкция, наподобие этой:Рисунок 3 – Созданные диалоговые окнаЭти строки выведут на экран окна, показанные на рисунке 3. После получения отпользователя нужных данных, следует ввести проверку на тип текущего документа – от этого зависитприменяемый код, а также не помешает отругать оператора, если он попробует применитьописываемый метод, скажем, сразу к чертежу .


Теперь остается написать недостающие участки кода. Для удобства вынесем обработку деталии сборки в отдельные функции, вызываемые из главной процедуры. Для детали имеем:Функция принимает три параметра: в elType передаем тип обрабатываемого элемента (0 длясопряжений, 1 для фасок), action отвечает за тип операции (true – отобразить, false – скрыть), и sizeхранит заданный пользователем размер-критерий «мелкости». Логика работы этого участка кодарассмотрена выше.Для сборки получается практически то же самое, с небольшими отличиями:


Появился новый объект типа ComponentOccurrence (выделено красным), с помощью которогомы перебираем детали, входящие в сборку; доступ к коллекциям сопряжений/фасок осуществляетсячерез описание геометрии этого объекта (выделено синим). В подавлении/восстановлении элементагеометрии теперь участвует имя детали (выделено черным).Данное решение проверено на различных деталях и сборках, работает, как планировалось.Небольшие ограничения все же есть. Если в сборке есть не только детали, но и сборки нижнегоуровня, следует ввести в код проверку на вид текущего объекта ComponentOccurrence (деталь илиподсборка), и рекурсивно вызвать функцию для обработки сборок, если требуется.Наверняка у внимательного читателя возникнет закономерный вопрос – а как быть с массойсборочной единицы? Ведь если подавить множество фасок и сопряжений, то вместе с геометриейизменится и масса! Действительно: масса изменится, и порой весьма значительно. Для решенияданного вопроса проще всего в начало кода, скрывающего элементы, добавить строку видаmass = iProperties.Mass – создать новую переменную с именем mass (имя может быть любымудобным), в которую сохранить текущее значение массы сборочной единицы. После подавлениятребуемых элементов следует воспользоваться обратной строкой: iProperties.Mass = mass, вкоторой восстанавливается исходное значение параметра массы – число в основной надписи чертежаостается неизменным.Следующий вопрос, который хотелось бы рассмотреть – создание чертежей зубчатых колес.В Inventor встроен хороший генератор зубчатых колес – наглядный, функциональный. Однако припопытке создать чертеж все эти красивые зубья естественно отображаются «в полный рост» (рис. 4).


Рисунок 4 – полное отображение зубчатого колеса на видах чертежаОдним из вариантов решения проблемы с помощью iLogic может быть создание«переключателя режимов» - кнопки, скрывающей либо восстанавливающей зубья на модели колеса.К тому же, не помешает включать изображение делительного диаметра, хотя бы вполуавтоматическом режиме. Итак, для начала добавим в новое правило основу для переключателя –простое окно с переключателем типа «RadioButton»:mode = InputRadioBox("Запрос", "3D", "Чертеж", booleanParam,Title := "Зубчатое колесо")If mode ThenFeature.IsActive("Цилиндрическое косозубое колесо") = trueElseFeature.IsActive("Цилиндрическое косозубое колесо") = falseEndРисунок 5 – окно выбора типаотображения колесаПри запуске этот код создаст окно, показанное на рисунке 5. При выборе опции «3D» впеременной mode окажется единица, при выборе «Чертеж» - ноль. На основе этого сделанопростейшее ветвление функции (см. код выше): элемент дерева построений, отвечающий за наличиесобственно зубьев в модели, подавляется либо возвращается.


Если теперь создать в новом эскизе на боковой поверхности колеса окружность с центром наоси, размером da_dw (имя параметра делительной окружности, добавляемого мастеромпроектирования) и выдавить от грани до грани колеса в режиме поверхности, то на чертеже будетприсутствовать линия делительной окружности! Останется ручками сменить тип линии с основнойна штрихпунктирную-тонкую. Результат можно увидеть на рисунке 6.Рисунок 6 – Колесо со скрытыми зубьями в модели (слева) и на чертеже (справа)Теперь остается не забыть прописать в код переключателя скрывание/отображениевыдавленной поверхности – просто подавлять ее по имени элемента, что не раз делалось выше потексту. В итоге имеем несложный в реализации, и тем более в применении способ переключениявида зубчатого колеса в зависимости от текущих потребностей (не забываем о сохранении параметрамассы для основной надписи!).В этой статье я попытался дать решение некоторых практических вопросов, связанных соформлением чертежей. Насколько это получилось – судить читателям. У меня же на очереди –автоматизация создания таблицы с параметрами зубчатого колеса, и исправление штриховки ребержесткости в продольном сечении.© Евгений Грайворонский aka evhenious

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!