О том, как легко мастеровому человеку мечтать с 3D-ядром

    Как используется геометрическое 3D-ядро при разработке приложений для САПР, рассказывает Валерий Голованёв, инженер-аналитик и программист, разработчик приложений для КОМПАС-3D. С лирическим вступлением и глубоким погружением в мир механических передач.

    image

    Мастеровыми были мой прапрадед Ефим Степанович (пахарь, бондарь и столяр), мой прадед Трифон Ефимович (пахарь и плотник) и мой дед Михаил Трифонович (кузнец, плотник, столяр, бондарь). И я мастеровой человек. Инженер и столяр-плотник-любитель.

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

    Когда шесть лет назад, летом 2012 года, я вернулся к своему детищу — библиотеке проектирования тел вращения КОМПАС-Shaft (сейчас приложение «Валы и механические передачи 3D» для КОМПАС-3D), то на печати своего ИП я изобразил пару коничек с круговым зубом. В тот момент я только мечтал о том, что когда-нибудь смогу сделать их в 3D — это был скорее некий символ. С возрастом к знакам и символам судьбы относишься более внимательно… Цель была материализована!

    От червячного колеса к гипоидной передаче в КОМПАС-3D


    С чего все началось? С желания! Очень хотелось дать конструктору настоящие 3D-модели механических передач, а не некие «подобия», чтобы можно было:

    1. Изготовить по 3D-модели зубчатое или червячное колесо, или звездочку. Или коничку с круговым зубом, или (о мечты...) гипоидную пару.
    2. Увидеть в 3D-сборке не условные «кракозюбры», а реальные модели.
    3. И далее… А почему, собственно, надо ориентироваться в механических передачах на возможности (ограничения) привычной технологии? Неправильно ущемлять конструкцию технологией. Надо делать правильные передачи с оптимальной 3D-геометрией активных рабочих поверхностей с точки зрения эксплуатации, а технология должна обеспечивать их изготовление. И такая технология, названная аддитивной, уже есть! Современные промышленные 3D-принтеры позволяют печатать металлом вполне нагруженные изделия, и эксперименты заходят далеко: уже скоро созданные аддитивным способом детали будут обыкновенным явлением в машиностроительном изделии, если не массовом, то в мелкосерийном – точно.

    Прошло примерно три года и весной 2015-го я решился сделать средствами API КОМПАС настоящее червячное колесо. Принцип реализации в этой задаче мне был понятен давно: необходимо заметание инструментом тела заготовки, т. е. имитация механообработки в КОМПАС-3D. Не скажу, что это было легко. Делать вырез набором из многочисленных положений инструмента неверно и долго. Необходимо сформировать совокупность поверхностей положений инструмента и создать по ним огибающую поверхность выреза. Что в общем-то и получилось, но работало очень медленно.

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

    image

    image

    Идем дальше! Осенью 2015 года с подачи (или с пинка) Владимира Панченко, руководителя подразделения Приложения КОМПАС-3D, и под опекой Алексея Султанова я начал изучать программирование на ядре C3D, на математике которого построен КОМПАС-3D. Цель — получить свободу! И я ее получил. Меня больше не ограничивало количество выполняемых операций и процедур. Все происходило достаточно быстро. На выходе я имел тело – массив вырезов из заготовки червячного колеса. Ну а дальше все просто: булева операция и червячное колесо готово.


    Николай Голованов, руководитель разработки C3D Labs
    Некоторые приложения системы КОМПАС-3D, в том числе и приложение «Валы и механические передачи 3D», работают напрямую с геометрическим ядром C3D. Это позволяет разработчикам приложений более гибко подойти к решению своих задач за счет расширения функционала (работы с низкоуровневыми функциями) и приемов построения геометрических объектов.

    Если вы пишите приложение для КОМПАС-3D и хотите использовать возможности C3D напрямую, имеет смысл обращаться к ядру, встроенному в сам КОМПАС-3D. У этого способа есть единственное ограничение: надо использовать только C++, так как именно на этом языке написан сам КОМПАС. Если же вы решили работать с отдельной копией ядра внутри собственного приложения, то вам будут доступны и C#, и, в некоторых случаях, JavaScript.

    Далее последовали цилиндрички внешнего зацепления. Казалось бы, просто, а между тем в случае с косозубым колесом и операцией выреза по винту в КОМПАС-3D на API тоже строилось достаточно долго. Сейчас эти шестерни могут быть сформированы и с настоящей затыловкой.

    Ну и в конце 2015 года стартовал процесс работы над коничками с круговым зубом.
    Алгоритм к тому времени был проработан на API КОМПАС. Первые модели с не очень хорошей геометрией формировались до суток чистого времени. Здесь одним заметанием поверхностей не обошлось. Создавались обкатные конические передачи, и необходимо было сформировать колесо, обработав его прототипом зуборезной головки. Потом по полученной 3D-геометрии сформировать и сохранить прототип инструмента для шестерни, со всего этого снять контролируемые размеры и передать в чертеж. Далее уже на шестерне, учитывая, что она получалась идеально обкатная, необходимо было локализовать контакт, т. е. обеспечить правильное положение и размер пятна контакта в передаче.

    Сложная и очень интересная задача. Изредка и Николай Голованов со своей командой правили по моим замечаниям функционал C3D. Таким образом, мои конички оказались еще и хорошим тестом для ядра.


    Николай Голованов, руководитель разработки C3D Labs
    Недавно в геометрическом ядре C3D подверглись существенной переработке Loft-поверхности, построенные по сечениям. Именно они и были использованы для моделирования мест контакта зубчатых колес.

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

    image

    Но сложно остановиться было и на этом. Не устраивала меня такая локализация. Слишком сложно было ее обеспечивать. И уже весной 2018 года пришла мысль о более «простом» способе локализации. Собственно идея не моя, я подсмотрел ее в материалах фирмы Klingelnberg — у них это называется profile and lengthwise crowning.

    image

    Я это назвал «сделать зуб с холмиком», что и получилось. В каждом сечении профиля выреза был сделан его пересчет, и холмик удался. Коэффициенты локализации стали более простыми и понятными.

    image

    Кратко о результате: пятно контакта, а это совокупность мгновенных площадок контакта на зубе шестерни за один цикл ее поворота = 360/число зубьев шестерни, ТЕПЕРЬ ВСЕГДА находится по середине активной поверхности зуба (на вершине «холмика»), его размер составляет более 60% всей поверхности.

    Что это дает:

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

    Изготовить их, правда, пока получится только на ЧПУ, но в будущем подтянутся и аддитивные технологии.

    Ну и под занавес… В этом году реализована передача-мечта, моя самая сложная на сегодня мечта-задача — гипоидные передачи. Многое, что пришлось сделать для этого… Шесть лет пути после возвращения к разработке САПР. Хотя на самом деле путь начался еще в 1991 году с заказного проекта по созданию ПО для расчета конических передач с круговым зубом.

    image

    Естественно, что зуб «холмиком» реализован и в них.

    image


    Владимир Панченко, руководитель дивизиона Приложения КОМПАС-3D, АСКОН
    К использованию ядра в приложении «Валы и механические передачи» подтолкнул отзыв «Казцинкмаша». Для меня было очевидно, что строить можно быстрее, оставалось только убедить в этом Валерия. Отягчающем обстоятельством было то, что Валерий не любил C++, а использовать функции C3D в контексте КОМПАС-3D можно только на этом языке программирования. Пришлось делать макет, спасибо Алексею Султанову.

    Простой перевод кода в лоб сразу дал ощутимый выигрыш по скорости: точная модель зуба червячного колеса построилась за 10 секунд. Червячное колесо строилось на API около часа.

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

    Как работает 3D-ядро в моделировании механических передач


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

    Для примера рассмотрим последовательность операций, необходимых для формирования 3D-модели выреза конического колеса с круговыми зубьями (именно колеса, а не шестерни):

    1. Формируем поверхности конусов — делительного конуса, конуса вершин и конуса впадин. Для этого на соответствующих расчетных расстояниях создаются плоскости и на них строятся эскизы окружностей расчетных диаметров, и уже по ним конусы.
    2. Строим точки центров делительного конуса и конуса впадин.
    3. Далее формируются касательная плоскость к конусу впадин (1) и плоскость по средней точке колеса во впадине (2). По пересечению плоскости (1) и плоскости XOY формируется ось пересечения (3), а по пересечению плоскости (2) и плоскости (1) формируется ось пересечения (4).
    4. На пересечении этих осей будет точка, через которую проходит вершина зуборезной головки.

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

      image
    7. Далее, имея процедуру для выполнения подобной операции под разными углами качания зуборезной головки при обработке колеса, мы получаем массив поверхностей вырезов (6).

      image
    8. После этого в достаточном количестве сечений (не менее 20) в нормальных плоскостях к направляющей (проекция полудуги зуборезной головки на делительный конус) будут получены совокупности линий пересечений массива поверхностей.

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

      image
    10. По совокупности этих сечений вырезов и будет построен окончательный лофт — вырез зуба колеса.

      image

      image

      image
    11. С полученной геометрии будут автоматически сняты (построен зуб, секущей плоскостью сделано сечение и по нему посчитано) контрольные размеры, сам профиль зуба, и все это передано в чертеж.

      image

      image
    12. Всё достаточно просто, правда в этом конкретном случае и без рассмотрения «небольших» скрытых от глаз читателей нюансов математических расчётов.


    Что необходимо еще мастеровому в данном случае? Пространственное воображение, фантазия и умение мечтать в конце концов!


    Владимир Панченко, руководитель дивизиона Приложения КОМПАС-3D, АСКОН
    Что быстрее API КОМПАС-3D или C3D? Вопрос звучит парадоксально. C3D – это же геометрическое ядро КОМПАС-3D! Как работает ядро, так работает и КОМПАС-3D. Но при ближайшем рассмотрении, особенно в контексте прикладного разработчика, все встает на свои места.

    Стандартная схема для разработчика выглядит так. Вызов функции API КОМПАС-3D приводит к добавлению объекта в модель документа, а дальше для создания геометрии идет обращение к C3D. Потом по цепочке, в обратном порядке, данные возвращаются обратно в API, и вот в руках разработчика интерфейс созданного объекта.

    При этом на каждом шаге с данными что-то происходит: в API их пакуют в COM, в модели документа проверяют на правильность в текущем контексте, добавляют атрибуты и данные по отрисовке. Конечно, все эти действия оптимизированы и занимают очень мало времени. Если разработчику нужно получить цилиндрическую ступень вала, то он создает эскиз и операцию выдавливания в КОМПАС-3D – всего два объекта и два обращения по цепочке. Но ситуация в корне меняется в случае с геометрией для конической передачи с круговым зубом. Для этого нужно создать множество вспомогательных кривых, поверхностей (и все это не аналитические цилиндры и конусы, а NURBS-ы), их пересечений. Прокачивание данных начинает занимать уже существенное время. Ядро при этом будет в основном простаивать. Чтобы избежать временных потерь, взаимодействие с API и моделью документа сводится к минимуму – добавь операцию с телом и прими тело, которое смоделировано в C3D. Получаем один заход в C3D и оптимально на стеке создаем всю вспомогательную геометрию, пересекаем, что нужно, и получаем результат. Работает только ядро и работает очень быстро.


    Валерий Голованёв, инженер-аналитик и программист, г. Курган, пос. Тёплый Стан.
    • +13
    • 3,1k
    • 3
    АСКОН
    85,00
    Крупнейший российский разработчик инженерного ПО
    Поделиться публикацией

    Комментарии 3

      0

      Красивая работа. А время работы алгоритма можно оптимизировать, или час — это не критично? Кажется, что на 6 шаге, когда есть поверхность (5), её вращением можно сразу получить профили с шага 11 не высчитывая пересечения. Не смотрели в эту сторону? Не знаком с компасом, так что может быть и нельзя.

        0
        отвечает Валерий Голованёв:
        Спасибо за интерес к статье. Наши алгоритмы постоянно оптимизируются. Последовательность алгоритма, о котором Вы спрашиваете, абсолютна верна. Вы несколько упрощенно представляете себе эту задачу.
          0

          Я ни в коем случае не критикую, вижу, что задача сложная. Мой не слишком долгий опыт компьютерного моделирования ограничивается Ansys. Больше интересовало именно время работы алгоритма: можно ли его сократить, к примеру, распараллелив? Или эта активность (запуски алгоритма) не настолько часто случается, чтобы её оптимизировать? Скажем, ждали условный час, получили готовую модель, поняли, что надо что-то подправить, поправили, ждём ещё час. Интересно, сколько может быть таких итераций в условную неделю? Несколько лет занимался параллельной обработкой, от этого и вопросы — моя профессиональная область.

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

      Самое читаемое