Autodesk inventor api

Концепція структури збірки знайома кожному, хто працював зі складками. Інвентор графічно відображає цю структуру в браузері. Хоча концептуально організація структури збірки проста, є ряд нюансів, важливих при роботі зі складанням через API. Наша мета - отримати користь з розуміння особливостей внутрішнього устрою збірок ІНВЕНТОР. Надалі, в якості ілюстрації ми будемо використовувати наступну збірку всього з трьох деталей: деталі «Вісь» та двох примірників деталі «Колесо».

Обхід ієрархічного дерева складних збірок є необхідним етапом у вирішенні багатьох завдань. Розглянемо приклад складання. Вона має всього два рівні, але даний підхід буде працювати при будь-якій кількості рівнів. В даному прикладі складання верхнього рівня Car.iam складається з двох раніше розглянутих колісних збірок і кузовної деталі. На схемі показано внутрішнє уявлення збірки Car.iam. Зверніть увагу, вона містить інформацію тільки про елементи на своєму верхньому рівні. Немає ніяких даних про склад колісних підзборок. Їх склад визначений в підзборки WheelAssembly.iam.

Що таке проксі-об'єкт. правити

Як уже зазначалося, збірки містять тільки посилання, але не геометрію. На перший погляд, це суперечить досвіду кінцевих користувачів, які в ІНВЕНТОР створюють і редагують збірки. З їх точки зору геометрія деталей реально бере участь в збірках. Наприклад, при накладенні залежності сполучення двох деталей ви вільні вибрати грань деталі, не замислюючись, де в дійсності знаходиться інформація про геометрію цієї деталі. Приблизно так само йде справа і при роботі з API - ви можете переглядати ієрархію збірки, отримуючи доступ до її компонентів і їх вмісту, як якби вони знаходилися на верхньому рівні збірки.

У попередньому прикладі з демонстрацією перебору компонентів збірки ми так і робили. Ми могли переглядати всі гілки збірки і отримувати посилання на будь-який об'єкт ComponentOccurrence в межах збірки. Якщо ми спробуємо з'ясувати становище об'єкта ComponentOccurrence, відповіддю буде положення, як якщо б він знаходився на верхньому рівні збірки. Якщо компонент посилається на деталь, і ми з його допомогою отримаємо посилання на об'єкт B-Rep, інформація про геометрію B-Rep буде повертатися в контексті верхнього рівня збірки.

Щоб побачити, як це працює, повернемося до збірки WheelAssembly. У ній є два примірника деталі Колесо (Wheel). Кожен екземпляр (instance) представлений компонентом ComponentOccurrence. Припустимо, ми хочемо, щоб користувач виділив зовнішні циліндричні поверхні кожного колеса. Перше питання: яким чином користувач зможе це зробити, якщо геометрія деталей не присутній в збірці? Друге питання: якщо припустити, що ми якимось чином можемо виділити геометрію, як відрізнити зовнішній циліндр одного колеса від зовнішнього циліндра іншого, якщо в дійсності в деталі Wheel існує лише один зовнішній циліндр?

Відповіддю на обидва питання буде - проксі-об'єкти (proxy). Проксі-об'єкти представляють об'єкти в збірці так, як якщо б ці об'єкти насправді існували в збірці. До ідеї проксі-об'єктів треба звикнути, але як тільки їх концепція стане зрозумілою, працювати з ними буде вже неважко. Повернемося до циліндричних гранях коліс. Коли ви виділяєте в збірці одну з них, ви насправді виділяєте об'єкт FaceProxy. Об'єкт FaceProxy успадковується з об'єкта Face, тому він має ті ж методи і властивості, плюс ще кілька, характерних тільки для проксі-об'єктів. З об'єктом FaceProxy, як спадкоємцем об'єкта Face, ви як правило можете працювати як зі звичайною гранню, і навіть не потрібно особливо замислюватися, що в дійсності ви працюєте з проксі-об'єктом. Для роботи з об'єктом ви використовуєте ті ж методи і властивості, відмінність лише в тому, що отримані результати будуть визначатися положенням об'єкта в збірці.

Проксі-об'єкт влаштований досить просто. Це шлях до об'єкта. Наприклад, шляхи до циліндричних гранях двох наших деталей-коліс будуть мати такий вигляд:

Тут «CylinderFace» представляє реальну циліндричну грань деталі колеса.

Перша частина шляху - компонент, остання частина шляху - дійсний об'єкт. У багаторівневої збірці шлях буде довшим, тому що в ньому буде багато компонентів. У збірці всієї машини з чотирма колесами шлях до циліндричної грані одного з коліс має вид:

Завдяки шляху проксі-об'єкта, Інвентор в стані точно визначити, на який саме об'єкт в збірці ви посилаєтеся.

Проксі-об'єкти підтримуються для великої кількості об'єктів. Ця підтримка необхідна кожному об'єкту, який в збірці повинен бути виділеним. Насправді нам вже доводилося мати справу з проксі-об'єктами ComponentOccurrenceProxy - в програмі перебору компонентів збірки, але це відбувалося неявно, оскільки ми могли обробляти їх як звичайні компоненти ComponentOccurrence. Компоненти на верхньому рівні збірки є звичайними об'єктами ComponentOccurrence. Вони насправді існують на верхньому рівні збірки. Коли ви перебирає компоненти в будь-який з підзборок WheelAssembly, які повертаються об'єкти мають тип ComponentOccurrenceProxy. Це так, тому що ці компоненти входять в збірку нема на верхньому рівні, а належать колісним підзборки. Об'єкт ComponentOccurrenceProxy створює видимість приналежності компонента верхнього рівня збірки. Якщо запитати у ComponentOccurrenceProxy його положення, він поверне його в контексті верхнього рівня збірки.

Зазвичай, при отриманні проксі-об'єкта в результаті перебору збірки або вибору користувачем, вас анітрохи не хвилює, що ви працюєте з проксі-об'єктом, а не з самим об'єктом. Саме в цьому і полягає найчудовіша особливість проксі-об'єктів - вони спрощують роботу з об'єктами з різних файлів, забезпечуючи видимість, ніби всі об'єкти існують безпосередньо в самій збірці, як це і представляється кінцевому користувачеві.

Створення проксі-об'єктів Правити

Бувають випадки, коли необхідно створити проксі-об'єкт для передачі його іншим методам як аргумент. Найчастіше це трапляється при програмному створенні збірки і накладення складальних залежностей. Розглянемо конкретний приклад. Нехай є болт, який ми бажаємо автоматично вставляти в збірку. Кругле ребро, вказане на малюнку справа, буде використовуватися як аргумент при накладенні залежності. Щоб легко знайти це ребро, коли болт буде вже в збірці, до ребру доданий атрибут «AutoBolts».

Розглянемо уважніше, що відбувається в збірці, зображеної на малюнку справа. Збірка складається з двох деталей, між якими ми маємо намір встановити залежність. Припустимо, ми вже отримали компонент-кубик і, використовуючи механіку B-Rep об'єктів, - кругле ребро отвори. Оскільки ми дісталися до ребра через компонент, це буде проксі-об'єкт EdgeProxy, що означає, що він веде себе як якщо б це ребро справді існувало в збірці. Тепер нам слід отримати об'єкт EdgeProxy для ребра в болті. Для пошуку ребра до нього був доданий атрибут, однак цей атрибут існує в деталі Болт, а не в збірці. Якщо спробувати шукати атрибут в збірці, ми його не знайдемо. Насправді шукати атрибут слід в межах документа Болт. Оскільки. ми проводимо пошук в документі Болт, що повертається об'єкт буде дійсним ребром, а не його проксі-об'єктом. API надає нам інструменти для створення проксі-об'єкта. Приклад ілюструє доступ до документа деталі, запит на пошук ребра, створення проксі-об'єкта і, нарешті, накладення складальної залежності. Передбачається, що у ми вже маємо EdgeProxy для ребра на кубику і посилання на компонент Болт.

Як тільки ребро в деталі знайдено, слід створити проксі-об'єкт для подання цього ребра в збірці. Як уже зазначалося, проксі-об'єкт визначає шлях до об'єкта. У файлі деталі ми маємо об'єкт, і тепер нам потрібно додати до нього шлях, щоб визначити той же об'єкт, але вже в збірці. Робиться це за допомогою методу CreateGeometryProxy об'єкта ComponentOccurrence. На вхід методу подається об'єкт, на виході маємо відповідний проксі-об'єкт. Метод всього-на-всього додає компонент до шляху проксі-об'єкта. У підсумку ми маємо об'єкт, який представляє ребро в контексті збірки.

Останній рядок прикладу використовує проксі-об'єкт болта і проксі-об'єкт кубика для накладення залежності вставки.

На вхід методу CreateGeometryProxy можна подати і проксі-об'єкт. Саме так формується багаторівнева збірка. Щоб її отримати, ви починаєте знизу від самого об'єкта і потім викликаєте метод CreateGeometryProxy на кожному рівні збірки, поки не збудуєте повний проксі-шлях.

Робота з проксі-об'єктами Правити

API містить також ряд додаткових інструментів для роботи з проксі-об'єктами. Багато з них корисні не тільки в звичайній роботі, але і для початкового знайомства з проксі-об'єктами і для налагодження програм з проксі-об'єктами.

Як вже зазначалося, різні проксі-об'єкти успадковуються з відповідних їм дійсних об'єктів. З цієї причини вони підтримують всі методи і властивості об'єктів-батьків. Але є у них два додаткових властивості, яких у батьків немає - ContainingOccurrence і NativeObject. Властивість ContainingOccurrence повертає компонент ComponentOccurrence, через який видно проксі-об'єкт. У попередньому прикладі властивість ContainingOccurrence проксі-об'єкта ребра в болті поверне компонент Болт.

Властивість NativeObject повертає справжній об'єкт, представлений проксі-об'єктом. У нашому прикладі, властивість NativeObject об'єкта EdgeProxy поверне дествительно об'єкт Ребро (Edge).