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

 

Міністерство освіти і науки, молоді та спорту України

Криворізький інститут

Кременчуцького університету економіки, інформаційних технологій та управління

Кафедра технічної кібернетики

Дипломна робота

зі спеціальності: Компютеризовані та робото технічні системи

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

Кривий Ріг, 2012

Завдання на дипломну роботу

. Тема роботи: Прикладні динамічні бібліотеки для системи Компас-3D затверджена наказом по інституту від " 01 " листопада 2011 р. № 55С-01_____________

. Термін здачі студентом закінченої роботи 03.05.12. _

. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, вихідні масиви даних, програмна документація, наукові матеріали.

. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка завдання; Прикладні конструкторські бібліотеки та інструменти для їх створення в системі Компас-3D; Дослідження методів створення динамічних бібліотек системи Компас-3D в середовищі Delphi; Опис функціональних можливостей та програмної реалізації прикладної бібліотеки; Економічне обґрунтування доцільності розробки програмного продукту; Охорона праці.

. Перелік графічного матеріалу (з точними вказівками обов'язкових креслень)

. Структура спеціалізованої САПР;

. Схема створення прикладних динамічних бібліотек за допомогою API;

. Приклад вікна стандартної бібліотеки системи Компас-3D;

4. Логіко-функціональна схема роботи користувача з бібліотекою;

5. Схема взаємодії бібліотеки з системою;

6. Діалогове вікно бібліотеки;

. Вікно редагування значень модулів;

. Загальний вигляд створеної моделі.

Календарний план

№ п/пНайменування етапів дипломної роботиТермін виконання етапів роботиПримітки1. Отримання завдання на дипломну роботу03.11.112. Огляд існуючих рішень20.02.123. Теоретичне дослідження інструментальних засобів реалізації проекту13.03.124. Програмна частина (постановка задачі, створення програмного забезпечення, опис алгоритму рішення задачі, проектування та опис інтерфейсу користувача, опис програми)16.04.125. Оформлення пояснювальної записки20.04.126. Оформлення графічної документації24.04.127. Оформлення електронних додатків до диплому26.04.128. Представлення дипломної роботи до захисту03.05.12Анотація

Метою дипломної роботи є дослідження можливостей створення прикладних динамічних бібліотек для системи Компас-3D в середовищі Delphi з використанням функцій API-інтерфейсу. Результатом виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса.

Аннотация

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

The summary

The purpose of the diploma work is research of the possibilities applied dynamic libraries creation for the system Компас-3D in the environment of Delphi with the use of API-interface functions.result of diploma work implementation is development of CAD-element, which creating the 3D-models of gear-wheels on the least of initial data.

Вступ

В умовах ринку САПР, що динамічно розвивається, знання основ тривимірного моделювання, параметризації, створення креслень в CAD-системі є необхідним для інженера-конструктора. У будь-якій проектно-конструкторській організації, на будь-якому підприємстві і вищому учбовому закладі в останні декілька років велика увага приділяється підготовці розрахунків, креслень і документації саме з використанням персональних комп'ютерів.

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

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

Найважливішою характеристикою будь-якої сучасної CAD-системи, разом з інструментальними засобами моделювання, є можливість автоматизації за допомогою різних допоміжних засобів процесів створення типових елементів і їх подальшого застосування. Це, по-перше, припускає наявність підсистем, що розширюють стандартні можливості програми, які дозволяють прискорити проектування власне об'єкту (агрегату, механізму, будівлі), а не окремо взятої деталі або складової. Найчастіше такі підсистеми є модулями (бібліотеками), що підключаються, функціонують тільки в середовищі «батьківського» графічного редактора і що дозволяють на основі його базових функцій швидко створювати і використовувати різні стандартні елементи.

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

Для розширення можливостей САПР Компас без зміни початкового коду в ній реалізований механізм бібліотек, що динамічно підключаються. Кожна бібліотека - це файл з розширенням rtw. Насправді це найзвичайніша dll- бібліотека, у якої розширення dll замінене на rtw. Таку бібліотеку легко написати, наприклад в середовищі програмування Delphi. Вона підключатиметься до Компас так само, як і всі інші бібліотеки, і матиме повний доступ до API Компас для виконання різних побудов і маніпуляцій з графічними об'єктами і документами.

Бібліотека може мати свою екранну форму, що різко спрощує введення даних - можна використати будь-які компоненти Delphi, підключити бази даних і т.д.

В більшості випадків результатом роботи бібліотеки повинна бути побудова якого-небудь фрагмента креслення або 3D-моделі. Оскільки побудова виконується повністю програмним шляхом, на одержувані моделі не накладається ніяких обмежень.

Метою виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса (як прямозубого, так і косозубого). Розроблена прикладна динамічна бібліотека реалізована у вигляді файлу формату RTW.

1. Постановка завдання

1.1 Найменування та галузь використання

Найменування розробки: прикладні динамічні бібліотеки для системи Компас-3D. Розроблена система динамічних бібліотек може бути використана для автоматизації конструкторської діяльності та пройшла практичну апробацію в умовах підприємства „КВМШ плюс.

1.2 Підстава для створення

Підставою для розробки є наказ № 55С-01 від 1 листопада 2011 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 03.11.11. Закінчення робіт: 03.05.12.

1.3 Характеристика розробленого програмного забезпечення

Система динамічних бібліотек, що призначена для автоматизації конструкторської діяльності, була створена за допомогою середовища прискореної розробки програмного забезпечення Delphi з використанням функцій API-інтерфейсу системи Компас-3D.

Завданням виконання дипломної роботи є розробка елементу САПР, що створює при мінімальній кількості початкових даних 3D-модель зубчатого колеса (як прямозубого, так і косозубого).

Розроблена прикладна динамічна бібліотека реалізована у вигляді файлу Gears3D.rtw. Дані про ряд модулів зубчастих коліс, що відповідають ГОСТ зберігаються у зовнішньому файлі бази даних - gears.mdb.

1.4 Мета й призначення

Метою дипломної роботи є дослідження можливостей створення прикладних динамічних бібліотек для системи Компас-3D в середовищі Delphi.

В результаті експериментальних досліджень була розроблена система, яка виконує наступні функції. Після виклику бібліотеки користувачем з'являється діалогове вікно, в якому він задає модуль (обирає із стандартного ряду), кількість зубів, ширину зубчатого вінця, а також кут нахилу зубів колеса (якщо колесо є косозубим). По введених параметрах бібліотека повинна згенерувати тривимірну модель колеса.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

·робота в середовищі операційних систем Windows 2000/XP/Vista/7;

·простота та зрозумілість інтерфейсу користувача.

Мінімальні вимоги до апаратного забезпечення:

·IBM-сумісний комп'ютер, не нижче Pentium IІІ, RAM-512Mb, SVGA-800*600*16bit;

·вільний простір на жорсткому диску не менш 500 Мб;

·монітор, клавіатура, маніпулятор типу „миша.

Додаткове програмне забезпечення - встановлення системи Компас-3D версії від 10 та вище.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

·технічне завдання на реалізацію проекту;

·довідкова література;

·наукова література;

·технічна література;

·програмна документація.

2. Прикладні конструкторські бібліотеки та інструменти для їх створення в системі компас-3D

2.1 Призначення і основні характеристики систем автоматизації конструкторської документації

Сучасний рівень програмних і технічних засобів електронної обчислювальної техніки дозволяє перейти до нових інформаційних комп'ютерних технологій, створювати системи автоматизації розробки і виконання конструкторської документації (АКД), що задовольняють стандартам ЄСКД як за якістю виконання документів, так і по дотриманню вимог стандартів. На комп'ютері можуть бути створені конструкторські документи (креслення і схеми) як з використанням, наприклад графічних примітивів типу відрізка, кола, полілінії та ін., так і фрагментів раніше створених конструктивних елементів: графічних зображень (ГЗ) стандартних виробів, типових і уніфікованих конструкцій, їх частин і т.д. При цьому моделі вищезгаданих фрагментів можуть бути параметрично заданими. За допомогою завдання різних значень параметрів конструктор може змінити їх розміри і геометричну форму, забезпечуючи багатоваріантність ГЗ і відповідно креслень і схем. При такому підході до конструювання використання комп'ютерної графіки не усуває креслення як основу конструювання, комп'ютер використовується як «електронний кульман», що полегшує працю конструктора. Такий підхід базується на двовимірному геометричному моделюванні.

При розробці КД в цьому випадку ефективність застосування комп'ютерної графіки забезпечується наступними її можливостями:

·наявністю у всіх графічних редакторах засобів перетворень: повороту, перенесення, масштабування, побудови дзеркального зображення і др.;

·використання готових фрагментів креслень з бібліотеки: конструктивних і геометричних елементів, уніфікованих і типових конструкцій, стандартних виробів;

·формуванням креслень з використанням об'єктно-орієнтованих інтерфейсів користувача, ведення діалогу з комп'ютером в звичних для конструктора (у вигляді піктограм) термінах і із звичними для нього об'єктами ГЗ;

·наявністю пакетів програм опису типових моделей-представників креслень об'єктів, коли процес створення конкретного креслення виробу полягає в маніпулюванні розмірами, представленими у вигляді параметрів;

·отриманням креслень високої якості, оформлених за стандартами ЄСКД (формується на етапі конструювання) шляхом виводу на графічні пристрої, принтери і інші пристрої.

Рис. 2.1 Структура системи АКД, заснованої на двовимірному геометричному моделюванні

Для використання цих можливостей застосовуються системи-надбудови над базовою графічною системою (наприклад, над AutoCAD), що містять спеціалізовані для конкретного виробу моделі необхідних фрагментів ГЗ, інтерфейсів користувача, що є об'єктно-орієнтованими «падаючими» і піктографічними меню і відповідними бібліотеками слайду.

Існують і інші підходи до автоматизації конструкторської діяльності, наприклад на основі просторового геометричного моделювання, коли формується просторова модель геометричного об'єкту (ГО), що є наочнішим способом представлення оригіналу і могутнішим і зручнішим інструментом для вирішення геометричних завдань (рис 2.2). Креслення тут грає допоміжну роль, а методи його створення засновані на методах комп'ютерної графіки, методах відображення просторової моделі (у Компас-3D - тривимірне моделювання). При першому підході - традиційному процесі конструювання - обмін інформацією здійснюється на основі конструкторської, нормативно-довідкової і технологічної документації; при другому - на основі внутрішньо-машинного представлення ГО, загальної бази даних, що сприяє ефективному функціонуванню програмного забезпечення систем автоматизованого проектування (САПР) конкретного виробу.

Рис. 2.2 Структура системи АКД, заснованої на використанні просторової моделі геометричного об'єкту

.2 Методи створення графічних зображень і геометричних обєктів

Формування моделі параметрично заданого ГО забезпечується з використанням програм створення моделі або об'єктно-орієнтованих систем-надбудов над САПР. Методи створення моделей, параметрично керованих ГО, характеризуються більшими витратами на формування моделі. Щоб скоротити ці витрати, при описі деяких груп технічних об'єктів можна користуватися одним із двох принципово різних методів: варіантним або генерируючим.

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

Генеруючий метод заснований на розділенні ГО на конструктивні і геометричні елементи і створенні нових ГО з наявних елементів за допомогою вибору різних їх поєднань. На рис. 2.3 приведений приклад розділення деталі на елементи. Системи АКД, що працюють по генеруючому методу, володіють високою гнучкістю і ефективні, оскільки досвід показує, що більшість конструкторських розробок створюються шляхом поєднання елементів, що не використалося, раніше відомих, як за принципом функціонування, так і по виконанню.

.3 Структура й основні принципи побудови систем автоматизації конструкторської документації

Система АКД виконує введення, зберігання, обробку і виведення графічної інформації у вигляді конструкторських документів. Для реалізації системи необхідні: документи, що регламентують роботу системи АКД; початкова інформація для формування інформаційної бази; інформаційна база, що містить моделі ГО, ГЗ, елементи оформлення креслення по ЄСКД; технічні і програмні засоби створення ГО і ГЗ і їх виводу; інтерфейс користувача у вигляді діалогу з комп'ютером.

Рис. 2.3 Структурна схема елементів геометричного обєкту

Всі перераховані складові утворюють методичне, інформаційне, технічне, програмне і організаційне забезпечення системи АКД (рис. 2.4). Основними принципами побудови системи АКД є:

·мобільність - адаптуються системи АКД до різних САПР. Шлях до цього - використання поширених базових графічних систем (наприклад, AutoCAD) і мов програмування;

·інформаційна єдність всіх частин АКД і САПР, яке передбачає єдність бази даних для різних призначень (скажімо, користування моделі ГО і ГЗ як для формування креслень, так і для розрахунків і виготовлення виробу);

·інваріантність - максимальна незалежність складових частин і системи АКД в цілому по відношенню до обєктно-орієнтованих систем АКД і САПР. Наприклад, система електронних пристроїв може бути використана як графічна підсистема в системі управління робототехнічним комплексом і як графічна підсистема в системі управління контрольно-вимірювальним пристроєм;

·можливість розширення системи АКД шляхом доповнення нових складових частин й розвиток старих.

2.4 Основи розробки спеціалізованих САПР

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

Рис. 2.4 Методичне, інформаційне, технічне, програмне та організаційне забезпечення системи АКД

Рис. 2.5 Структура спеціалізованої САПР

Для цього спочатку створюється параметрична збірка проектованого механізму, в якій ряд розмірів винесений в змінні моделі. Розрахунковий модуль (це зовнішній exe-файл або що підключається до САПР dll-бібліотека, написані, наприклад, на Delphi) може розрахувати необхідні значення змінних моделі і автоматично змінити їх, внаслідок чого буде одержаний новий варіант 3D збірки.

Таким чином, відразу ж після розрахунку буде одержана нова геометрія виробу. Зрозуміло, такий спосіб накладає обмеження на функціональність спеціалізованої САПР: можна тільки міняти розміри, але не додавати або видаляти деталі чи їх конструктивні елементи. З іншого боку, в більшості випадків робота конструктора якраз і зводиться до модифікації раніше створеної геометрії вузла відповідно до нових розрахункових даних, і створений в результаті виконання дипломної роботи елемент спеціалізованої САПР повністю виконує завдання автоматизації конструкторської праці, виконуючи і розрахунок, і побудову моделі.

Очевидно, головну складність представляє не стільки виконання розрахунків, скільки організація взаємодії розрахункового модуля і САПР. Історично склалося, що більшість сучасних САПР не підтримують СОМ-технологію, що додатково ускладнює управління ними із зовнішньої програми. Як правило, таке управління здійснюється за допомогою технології API (Application Programming Interface). API-технологія надає програмістові набір процедур і функцій для управління САПР, але не дає прямого доступу до властивостей і методів об'єктів всередині САПР, що робить код програми декілька громіздкішим і менш зрозумілішим.

Для розширення можливостей САПР Компас без зміни початкового коду в ній реалізований механізм бібліотек, що динамічно підключаються. Кожна бібліотека - це файл з розширенням .rtw. Насправді це найзвичайніша dll-бібліотека, у якої розширення dll замінене на rtw. Таку бібліотеку легко написати, наприклад, на Delphi. Вона підключатиметься до Компас так само, як і всі інші бібліотеки, і матиме повний доступ до API Компас для виконання різних побудов і маніпуляцій з графічними об'єктами і документами. Бібліотека може мати свою екранну форму, що різко зпрощує введення даних - можна використати будь-які компоненти Delphi, підключити бази даних і т.д.

В більшості випадків результатом роботи бібліотеки повинна бути побудова якого-небудь фрагмента креслення або 3D моделі. Оскільки побудова виконується повністю програмним шляхом, на одержувані моделі не накладається ніяких обмежень - наприклад, можна створити бібліотеку, що будує зубчате колесо з довільним числом зубів і т.д.

Бібліотеки розділяються по типу документа, в якому вони проводять побудови. Для запуску 3D бібліотеки необхідно, щоб поточним документом була 3D модель або збірка, а для 2D бібліотеки - креслення або фрагмент.

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

Величезний перелік областей застосування САПР - перша причина, по якій будь-яка з сучасних CAD-систем повинна бути максимально відкритою і обов'язково містити інструменти для створення пакету призначених для користувача бібліотек. Другою причиною є орієнтація на замовника. Якщо, наприклад, переважна більшість підприємств, що використовують ту або іншу систему, працюють в машинобудуванні, а одиниці - у області виробництва медичного устаткування, то розробники прикладних бібліотек вимушені підстроюватися під першу категорію. Але для замовників Компас жодних проблем не виникне - вони можуть створити бібліотеки самостійно.

Перерахуємо основні способи створення бібліотек:

·створення бібліотеки фрагментів (ескізів) або моделей на основі базових можливостей системи КОМПАС-3D;

·створення бібліотеки шаблонів за допомогою Менеджера шаблонів;

·використання спеціального макросередовища Компас-Макро для підготовки призначеного для користувача додатку;

·застосування інструментальних засобів Компас-Майстер, тобто власне написання (програмування) бібліотек.

Який з цих варіантів вибрати? Все залежить від поставлених цілей і від нашого уявлення про майбутню бібліотеку: який вона повинна бути, що робитиме (створювати, редагувати, виконувати які-небудь інші дії), наскільки могутніми і гнучкими повинні бути її функції. Велике значення має і рівень підготовки розробника. Прості бібліотеки не вимагають майже ніяких спеціальних знань, але і можливостей надають небагато. Створення складніших модулів неможливе без деяких навиків і досвіду (іноді із зовсім іншої наочної області, зокрема з програмування), при цьому чим складніше проектована бібліотека, тим більше глибокі знання необхідні. Під складністю бібліотеки тут слід розуміти рівень автоматизації тих конструкторських рішень, які будуть реалізовані в створюваному додатку. Але не варто думати, що найбільш автоматизована бібліотека завжди є кращим рішенням. Занадто автоматизовані додатки не залишають місця ініціативі і не дають можливості варіювати рішення.

2.5 Бібліотеки фрагментів і моделей

Для створення бібліотек цього типа нам не буде потрібно ніяких спеціальних навиків, окрім уміння працювати в Компас-Графік або в Компас-3D. За допомогою таких бібліотек кожен проектувальник може систематизувати свій набір найбільш часто використовуваних елементів, щоб полегшити доступ до них при розробці нових креслень або моделей.

Створити свою бібліотеку фрагментів зовсім нескладно. Для цього у вікні Менеджера бібліотек потрібно скористатися командою контекстного меню Додати опис > Бібліотеки документів. У діалоговому вікні відкриття бібліотеки, що з'явилося, слід вибрати тип файлу: Компас-бібліотеки фрагментів (*.lfr), якщо ми створюємо сховище для креслень або ескізів, або Компас-бібліотеки моделей (*.l3d) - для наповнення майбутньої бібліотеки 3D-моделями. У результаті у вікні Менеджера бібліотек повинна з'явитися наша бібліотека, поки що порожня. Після запуску до неї можна додавати фрагменти і моделі за допомогою команд контекстного меню.

Головна перевага бібліотек фрагментів - простота їх створення і застосування. Великим плюсом таких додатків є також те, що при появі нових версій Компас не потрібно підганяти або змінювати їх структуру під тільки що випущений реліз. Досить завантажити старий файл бібліотеки в Менеджер бібліотек, і можемо не сумніватися - все працюватиме.

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

Ширшими можливостями, в порівнянні з бібліотеками фрагментів, володіють бібліотеки шаблонів Компас-3D.

2.6 Створення бібліотек шаблонів

Бібліотека шаблонів це прикладна бібліотека, що складається з базового креслення, що параметризується, або тривимірної моделі, таблиці змінних, набраної відповідно до деяких правил в табличному редакторі MS Excel, і схеми документа Компас-3D або рисунка, що містить імена змінних. Бібліотека є файлом з розширенням *.tlm, за допомогою якого змінним фрагмента, що параметризується, або деталі ставляться у відповідність значення, набрані в Excel-таблиці. Для створення бібліотек шаблонів призначений спеціальний додаток під назвою Менеджер шаблонів.

Розробку шаблону слід починати із створення його прототипу (фрагмента або деталі), користуючись стандартними засобами Компас-Графік або Компас-3D. Потім необхідно параметризувати викреслений фрагмент або ескізи моделі і призначити зовнішніми всі змінні, які ми плануємо вводити (набирати) в таблиці Excel. Наступним кроком є створення таблиці значень. Така таблиця формується в редакторі Excel і включає назви зовнішніх змінних, що параметризуються, прапорці видимості колонок значень в Менеджері шаблонів, конкретні значення або їх інтервал для кожної змінної та інше. Формування ще однієї складової частини шаблону схеми параметрів не викличе особливих утруднень. Схемою може бути будь-який графічний файл системи Компас-3D або файл-рисунок у форматі *.bmp, *.gif або *.jpg.

Коли всі три розглянутих вище компоненти підготовлені, їх потрібно зібрати в єдиний додаток. Для цього, користуючись командою «Новая библиотека», слід вказати назву майбутньої бібліотеки і директорію, де вона буде розміщена. Далі необхідно оформити внутрішню деревовидну структуру бібліотеки, тобто розділи і підрозділи, в яких знаходитимуться підготовлені нами шаблони.

Рис. 2.6 Приклад вікна стандартної бібліотеки системи Компас-3D

Завершує етап підготовки бібліотеки наповнення розділів відповідними шаблонами, для чого слід скористатися командою «Создать шаблон». Після її виклику з'явиться невелике віконце, в якому для кожного шаблону потрібно ввести ім'я, вказати файл з фрагментом, що параметризується, або моделлю, файл таблиці параметрів Excel і заставку (необов'язково). Після закінчення всіх цих дій бібліотека шаблонів повністю готова до роботи. Можна завантажувати певний шаблон, вводити значення змінних і вставляти готову деталь або фрагмент в документ.

Які ж істотні відмінності бібліотек шаблонів від бібліотек фрагментів? Перш за все це можливість вставки в документ не всього фрагмента, а окремих його шарів, а також наявність ряду дискретних значень для змінної, що виключає введення або вибір користувачем помилкових значень. Крім того, змінні шаблонів можуть бути різних типів, зокрема логічних і строкових, а в розмірних написах фрагмента-заготівки нескладно резервувати змінні для текстових підстановок (вони повинні виділятися з обох боків знаком #). Головною ж перевагою бібліотек шаблонів є те, що при використанні шаблону не доводиться змінювати змінні, що уручну параметризуються, як це робилося б при вставці фрагмента або моделі з бібліотеки фрагментів. При вставці об'єкту в активний документ Менеджер шаблонів сам поклопочеться про те, щоб підставити потрібні значення з вибраного користувачем ряду.

Безумовно, на розробку шаблонів йде більше часу і при цьому одних тільки навиків роботи з Компас вже буде недостатньо доведеться вивчити принципи роботи Менеджера бібліотек. Зате застосування шаблонів дає можливість достатньо гнучко автоматизувати створення типових елементів і разом з тим не забороняє динамічно управляти процесом формування бібліотечного елементу.

2.7 Створення прикладних бібліотек за допомогою Компас-Макро

Компас-Макро - це інтегрована в систему Компас-3D середовище розробки конструкторських додатків на основі мови програмування Python. Чому за основу вибраний саме Python? По-перше, Python розповсюджується безкоштовно і, як наслідок, не накладає ніяких обмежень на використання і розповсюдження написаних на ньому програм. По-друге, сьогодні Python - одна з найпростіших і зрозуміліших мов програмування, проте при всій своїй простоті він мало в чому поступається таким «китам» об'єктно-орієнтованого програмування, як C++ і Object Pascal (Delphi).

За своєю суттю Компас-Макро є звичайною бібліотекою, що підключається до Компас, тільки з великими можливостями. При створенні додатків в Компас-Макро можна користуватися як функціями Компас-Майстер, так і спеціальними функціями макросередовища, що полегшують розробку прикладних бібліотек. Серед спеціальних функцій Компас-Макро слід зазначити функції постановки кутових, лінійних і радіальних розмірів, функцію вставки в документ фрагмента, малювання лінії-винесення та ін. Синтаксис перерахованих методів значно простіший за їх аналоги, реалізовані Компас-Майстер (наприклад, замість виклику олнієї функції створення лінійного розміру в Компас-Макро при роботі з API-функціями середовища Компас-Майстер доводиться оголошувати і ініціалізувати цілих три інтерфейси).

2.8 Інструментальні засоби розробки бібліотек

Компас-Майстер - це дуже могутні інструментальні засоби розробки додатків (бібліотек) необмеженої складності, що функціонують в середовищі Компас-3D. З допомогою Компас-Майстер прикладний програміст дістає доступ до всіх без виключення функцій системи.

Тобто абсолютно все, що користувач може робити уручну, будь то створення або редагування графічного документа, відкриття і закриття файлів, робота із специфікаціями, створення таблиць, оформлення креслень, збереження файлів в різних форматах, вставка рисунків і т.п., все це може бути автоматизовано з використанням Компас-Майстер.

Доступ до внутрішніх функцій Компас-Графік і Компас-3D забезпечується двома шляхами:

·через експортні функції, оформлені у вигляді dll-модулів, які розробник підключає до своєї програми, при створенні плоских креслень; через використання об'єктів СОМ при програмному формуванні твердотільних моделей;

·за допомогою технології Automation (Автоматизації), реалізованої через API (Application Programming Interface - програмний інтерфейс додатку) системи Компас. Управління і взаємодія з системою при цьому оформлене через інтерфейси IDispatch.

Використання інтерфейсів IDispatch можливо в будь-якому з найбільш поширених сьогодні середовищ програмування (Visual C++, Delphi, C++Builder, Visual Basic).

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

Рис. 2.7 Схема створення прикладних динамічних бібліотек за допомогою API

3. Дослідження методів створення динамічних бібліотек системи компас-3d в середовищі Delphi

3.1 Технологія COM, автоматизація і інтерфейси IDispatch

З початку 1990 років корпорація Microsoft розробляє технологію, що дозволяє створювати гнучкі модульні програми так, щоб окремі модулі можна було писати на різних мовах програмування, але щоб при цьому забезпечувалася їх повна взаємозамінюваність при використанні в різних програмних пакетах. На сьогодні ця технологія повністю сформована і називається COM (Component Object Model, модель компонентних об'єктів).

Технологія COM описує методологію реалізації компонентів програмного забезпечення: об'єктів, які можуть повторно використовуватися, можуть бути неодноразово підключені до різних додатків. Повторне використання компонентів стало логічним слідством еволюції об'єктно-орієнтованого програмування і одержало назву компонентно-орієнтованого підходу. Концепція компонентно-орієнтованого програмування передбачає повне відділення внутрішніх функцій компоненту від функцій доступу до нього ззовні. Тепер, звертаючись до компоненту, необов'язково знати його внутрішній устрій, для цього досить лише мати інформацію про те, як викликати його функції. Іншими словами, необхідно знати, як взаємодіяти з компонентом і який у нього інтерфейс. Така функціональність в COM досягається за рахунок підтримки одного або декількох інтерфейсів, які використовуються іншими програмами для доступу до внутрішніх членів і методів компоненту.

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

Об'єкт COM - конкретний екземпляр COM-класу, завершений об'єкт з власними членами даних і методами, який може легко вбудовуватися в програми або розповсюджуватися як окремий програмний продукт. COM-об'єкт є або DLL-бібліотекою або ЕХЕ-програмою для Wіndows, які можна створювати в будь-якому середовищі програмування, здатному підтримувати потрібний формат уявлення. COM-об'єкт може мати багато функцій, доступ до яких відбувається через його інтерфейси. Будь-який COM-об'єкт повинен мати принаймні один інтерфейс ІUnknown, хоча насправді має їх значно більше.

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

Саме для цієї мети існує спеціальний інтерфейс, який називається ІUnknown. Він має настільки важливе значення, що основний принцип специфікації СОМ вимагає, щоб всі об'єкти СОМ окрім своїх спеціалізованих інтерфейсів підтримували інтерфейс ІUnknown. Причому кожен визначений для об'єкту інтерфейс повинен походити від ІUnknown або від інтерфейсу, який в свою чергу сам походить від ІUnknown. Даний принцип називається спадкоємством інтерфейсів.

У інтерфейсі ІUnknown реалізовано лише три методи: Queryіnterface(), AddRef() і Release(). Метод Queryіnterface() визначає, чи є одержаний інтерфейс потрібним. Методи AddRef() і Release() використовуються для підрахунку посилань на даний інтерфейс при його застосуванні багатьма програмами. Перед початком використання COM-об'єкту клієнт викликає метод СОМ, тим самим збільшуючи кількість посилань на інтерфейс на одиницю. Після закінчення роботи з інтерфейсом клієнт повинен викликати функцію Release(), щоб зменшити кількість посилань на одиницю. Коли лічильник посилань для всіх інтерфейсів стане рівним нулю, означає, об'єкт більше ніким не використовується і його можна вивантажувати з пам'яті.

На сьогодні технологія СОМ використовується практично у всіх серйозних програмах. Припустимо, що користувачу в якому-небудь звіті потрібно помістити електронну таблицю з розрахунками, які посилаються на певні параметри в тексті. Щоб виконати будь-які обчислення без використання технології СОМ, довелося б постійно перемикатися між двома програмами (Word і Excel), а інформацію копіювати (вирізувати і вставляти). За допомогою технології COM можна застосовувати функції електронної таблиці прямо в текстовому редакторі і автоматично форматувати отриманий результат. Можливість реалізувати операції такого роду називається автоматизацією.

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

Якби кожна програма або додаток-сценарій могли б підтримувати покажчики і процедуру обходу покажчиків, то проблема була б вирішена. Проте в деяких мовах програмування є певна трудність з процедурою обходу таблиці покажчиків. Деякі з них, наприклад Vіsual Basіc, не підтримують покажчики безпосередньо. Для вирішення цієї проблеми був розроблений спеціальний інтерфейс, який дозволяє будь-яким мовам програмування, зокрема таким, як Vіsual Basіc, звертатися до методів COM-компонентів. Цей інтерфейс одержав назву ІDіspatch.

Отже, будь-яка програма, яка надає свої можливості іншим додаткам (підтримує автоматизацію), може робити це через інтерфейс ІDіspatch. Інтерфейс ІDіspatch походить від базового інтерфейсу моделі СОМ ІUnknown, проте, на відміну від інших COM-інтерфейсів ІDіspatch містить метод Іnvoke(). Його можна використовувати для дійсного виконання методів, які підтримує COM-об'єкт. Клієнт може виконати будь-який метод COM-об'єкту, викликавши метод Іnvoke() інтерфейсу ІDіspatch. Цей механізм працює за допомогою інтерфейсу диспетчеризації. Він визначає методи, які будуть доступні завдяки використанню методу Іnvoke() інтерфейсу ІDіspatch.

Інтерфейси IDispatch можна застосовувати в будь-якому з найбільш поширених сьогодні середовищ програмування (Visual C++ Studio, Borland Delphi, Borland C++Builder, Visual Basic). Саме цим Компас-Майстер вигідно відрізняється від Компас-Макро: нам не доведеться вивчати малознайому мову програмування, ми можемо створювати свої додатки в тому середовищі, до якого звикли.

3.2 Склад СОМ-додатку

При створенні СОМ-додатку необхідно забезпечити наступне:

·СОМ-інтерфейс;

·СОМ-сервер;

·СОМ-клієнт.

Розглянемо ці три складові СОМ-додатку.

3.2.1 СОМ - інтерфейс

Клієнти СОМ зв'язуються з об'єктами за допомогою СОМ-інтерфейсів. Інтерфейси - це групи логічно або семантично зв'язаних процедур, які забезпечують зв'язок між постачальником послуги (сервером) і його клієнтом. На рис. 3.1 схематично зображено стандартний СОМ-інтерфейс.

Рис. 3.1 СОМ-інтерфейс

Ключовими аспектами СОМ-інтерфейсів є:

·Одного разу визначені, інтерфейси не можуть бути змінені. Таким чином, на один інтерфейс можна покласти певний набір функцій. Додаткова функціональність реалізовується за допомогою додаткових інтерфейсів.

·За взаємною домовленістю, всі імена інтерфейсів починаються з букви I, наприклад IРersist, IМalloc.

·Кожен інтерфейс гарантовано має свій унікальний ідентифікатор, який називається глобальним унікальним ідентифікатором (Globally Unique Identifier, GUID). Унікальні ідентифікатори інтерфейсів називають ідентифікаторами інтерфейсів (Interface Identifiers, IIDs). Ці ідентифікатори забезпечують усунення конфліктів імен різних версій додатку або різних додатків.

·Інтерфеси не залежать від мови програмування. Для реалізації СОМ-інтерфейсу можна скористатися будь-якою мовою програмування. Мова програмування повинна підтримувати структуру покажчиків, а також мати можливість виклику функції за допомогою покажчика явно або неявно.

·Інтерфейси не є самостійними об'єктами, вони лише забезпечують доступ до об'єктів. Таким чином, клієнти не можуть безпосередньо звертатися до даних, доступ здійснюється за допомогою покажчиків інтерфейсів.

·Всі інтерфейси завжди є потомками базового інтерфейсу IUnknown.

Базовий СОМ-інтерфейс IUnknown

Базовий інтерфейс IUnknown забезпечує механізм обліку посилань (лічильник посилань на СОМ-об'єкт). При передачі покажчика на інтерфейс виконується метод інтерфейсу ІUnknown AddRef. Після закінчення роботи з інтерфейсом додаток-клієнт викликає метод Release, який зменшує лічильник посилань.

Під час виклику методу Querylnterface інтерфейсу ІUnknown в метод передається параметр IID, який має тип TGUID, тобто ідентифікатор інтерфейсу. Параметр методу out повертає або посилання на інтерфейс, що запрошувався, або значення NH.

Покажчики СОМ-інтерфейсу

Покажчик інтерфейсу - це 32-бітовий покажчик на екземпляр об'єкту, який є, у свою чергу, покажчиком на реалізацію кожного методу інтерфейсу. Реалізація методів доступна через масив покажчиків на ці методи, який називається vtable. Використання масиву vtable схоже на механізм підтримки віртуальних функцій в Object Pascal.

Рис. 3.2 Схема роботи покажчика СОМ-інтерфейсу

3.2.2 СОМ-сервери

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

Клієнти не знають як СОМ-об'єкт виконує свої дії. СОМ-об'єкт надає свої послуги за допомогою інтерфейсів. Крім того, додатку-клієнту не потрібно знати, де знаходиться СОМ-об'єкт. Технологія СОМ забезпечує прозорий доступ незалежно від місцезнаходження СОМ-об'єкту.

Коли клієнт запрошує послугу від СОМ-об'єкту, він передає СОМ-об'єкту ідентифікатор класу (CLSID). CLSID - всього лише GUID, який застосовується при зверненні до СОМ-об'єкту. Після передачі CLSID, СОМ-сервер повинен забезпечити так звану фабрику класу, яка створює екземпляри СОМ-об'єктів.

СОМ-сервер повинен виконувати наступне:

·реєструвати дані в системному реєстрі Windows для звязування модуля серверу з ідентифікатором класу (CLSID);

·надавати фабрику СОМ-класу, що створює екземпляри СОМ-об'єктів;

·забезпечувати механізм, який вивантажує з пам'яті сервери СОМ, які у даний момент часу не надають послуг клієнтам.

Фабрика класу

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

Фабрика класу - це спеціальний СОМ-об'єкт, який підтримує інтерфейс IСlassFactory і відповідає за створення екземплярів того класу, з яким асоційована дана фабрика класу.

Інтерфейс IСlassFactory має два методи:

·Createlnstance, який створює екземпляр СОМ-обєкта, асоційованої фабрики класу

·LockServe, який застосовується для зберігання СОМ-сервера в памяті. Якщо параметр метода fLock має значення true, то лічильник посилань сервера збільшується, в іншому випадку - зменшується. Коли лічильник досягає значення 0, сервер вивантажується з памяті.

Кожного разу, коли послуги СОМ-об'єкта запрошуються клієнтом, фабрика класу створює і реєструє екземпляр об'єкту для конкретного користувача. Якщо послуга того ж СОМ-об'єкту запрошує інший клієнт, фабрика класу створює другий екземпляр об'єкту для обслуговування другого клієнта. СoСlass повинен мати фабрику класу і ідентифікатор класу CLSID. Використання CLSID для СoClass має на увазі, що вони можуть бути відкоректовані кожного разу, коли в клас вводяться нові інтерфейси. Таким чином, на відміну від DLL, нові інтерфейси можуть змінювати або додавати методи, не впливаючи на старі версії.

Локальні і віддалені сервери

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

·внутрішній сервер (In-process server);

·локальний сервер (Local server);

·видалений сервер (Remote server).

Внутрішній сервер - це бібліотека DLL, яка запущена в одному процесі разом з клієнтом. Додаток-клієнт зв'язується з сервером усередині процесу за допомогою прямих викликів СОМ-інтерфейсу. На рис. 3.3. представлена схема взаємодії клієнта з внутрішнім сервером.

Рис. 3.3 Схема взаємодії клієнта с внутрішнім сервером

Локальний сервер - це додаток ЕХЕ, який запущено в іншому процесі, але на одному комп'ютері разом з клієнтом. Наприклад, лист електронної таблиці Microsoft Excel пов'язаний з документом Microsoft Word. При цьому два різні додатки працюють на одному комп'ютері. Локальні сервери використовують СОМ для з'єднання з клієнтом.

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

Функції маршалінга:

·приймати покажчик інтерфейсу з процесу серверу і робити покажчик проксі в процесі клієнта доступним;

·передавати аргументи викликів інтерфейсу таким чином, ніби вони відбулися від клієнта і розміщувати аргументи в процесс видаленого об'єкту.

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

Таким чином, маршалінг - це процес пакування інформації, а демаршалінг - процес розпакування інформації.

Тип маршалінга залежить від об'єктної приналежності СОМ. Об'єкти можуть використовувати стандартний механізм маршалінга, що надається інтерфейсом IDispatch. Стандартний маршалінг дозволяє встановлювати зв'язок за допомогою стандартного системного видаленого виклику процедури (Remote Procedure Call, RPC).

На рис. 3.4 зображена схема, що показує методику взаємодії клієнта і серверу у разі, коли додатки працюють на одному комп'ютері, але в різних процесах.

Рис. 3.4 Схема взаємодії клієнта з сервером в різних процесах на одному компютері

Видалений сервер - це бібліотека DLL або інший додаток, запущений на іншому комп'ютері. Тобто клієнт і сервер працюють на різних комп'ютерах в мережі. Видалений сервер використовує розподілені СОМ-інтерфейси (Distributed COM, DCOM) для зв'язку з клієнтом.

Видалений сервер працює також з допомогою проксі. Відмінність в роботі між локальним і видаленим сервером полягає в типі межпроцесного зв'язку, що використовується. У разі локального серверу - це СОМ, а у разі видаленого серверу - DCOM. Схема взаємодії клієнта і видаленого сервера показана на рис. 3.5.

Рис. 3.5 Схема взаємодії клієнта з сервером на різних компютерах

3.2.3 СОМ-клієнти

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

Типовим СОМ-клієнтом є диспетчер автоматизації (Automation Controller). Диспетчер автоматизації - це частина додатка, яка «знає» який тип інформації необхідний йому від різних об'єктів сервера, і вона запрошує дану інформацію у міру потреби.

3.3 Базові інтерфейси API системи Компас

Взаємодія зовнішнього додатку або модуля, що підключається, з системою Компас (з функціями моделювання, математичними функціями ядра системи та ін.) здійснюється за допомогою програмних інтерфейсів, званих API. У КОМПАС на даний момент існують API двох версій: API 5 і API 7. Насправді обидві версії реалізують різні функції системи і взаємно доповнюють один одного. Звідси, очевидно, що обидві версії програмних інтерфейсів в рівній мірі підтримуються і розвиваються з урахуванням самих змін в системі.

В основному, для створення повноцінних модулів, що підключаються, досить методів і властивостей інтерфейсів API 5.

.3.1 Інтерфейс KompasObject

Головним інтерфейсом API системи Компас є KompasObject. Одержати покажчик на цей інтерфейс (якщо бути точним, на інтерфейс додатку API 5) можна за допомогою експортної функції CreateKompasObject(). Методи цього інтерфейсу, головні з яких представлені таблиці 3.1, реалізують найбільш загальні функції роботи з документами системи, системними настройками, файлами, а також дають можливість одержати покажчики на інші інтерфейси (інтерфейси динамічного масиву, роботи з математичними функціями, бібліотек моделей або фрагментів і різних структур параметрів певного типа).

Таблиця 3.1 Деякі методи інтерфейсу KompasObject

МетодОписActiveDocument2DДозволяє одержати покажчик на активний графічний документActiveDocument3DДає можливість одержати покажчик на активний тривимірний документDocument2DДозволяє одержати покажчик на інтерфейс графічного документа (креслення або фрагмента)Document3DДає можливість одержати покажчик на інтерфейс тривимірного документа (деталі або складки)GetDynamicArrayПовертає покажчик на інтерфейс динамічного масивуGetMathematic2DПовертає покажчик на інтерфейс для роботи з математичними функціями в графічному документіGetParamStructОдин з найважливіших методів. Дозволяє одержати інтерфейс структури параметрів об'єкту визначеного типу ksAttachKompasLibraryПідключає бібліотеку (додає її в пункт головного меню Бібліотеки)

3.3.2 Інтерфейс документа моделі ksDocument3D

Інший важливий інтерфейс API 5 - інтерфейс документа моделі ksDocument3D.

Одержати його можна за допомогою методів інтерфейсу KompasObject:

·ActiveDocument3D - для того, що вже існує і активного в даний момент документа;

·Document3D - якщо ми плануємо створювати новий тривимірний документ.

Графічні документи мають власний інтерфейс - ksDocument2D, зі своїми специфічними властивостями і методами. Зображення в ескізах тривимірних операцій створюються саме за допомогою функцій, присутніх ksDocument2D.

Властивості (члени даних) інтерфейсу ksDocument3D дозволяють динамічно управляти настройками будь-якого тривимірного документа системи з нашого модуля. Найбільш використовувані з них приведені таблиці 3.2.

Таблиця 3.2 Властивості інтерфейсу ksDocument3D

ВластивістьТип данихОписauthorWideStringІм'я автора документаdrawModeIntegerТип відображення моделі (каркас, без невидимих ліній, невидимі лінії тонкі, півтонове)fileNameWideStringІм'я файлу документа моделіhideAllAxisWordBoolПриховати показати конструктивні осіhideAllPlaceWordBoolПриховати показати початки координатhideAllPlanesWordBoolПриховати/показати площиниhideAllSketchesWordBoolПриховати показати ескізиhideAllSurfacesWordBoolПриховати показати поверхніhideAllThreadsWordBoolПриховати показати зображення різьбленняinvisibleModeWordBoolРежим редагування документа (видимий або невидимий)perspectiveWordBoolОзнака відображення перспективної проекціїreferenceIntegerПокажчик документа (деталі або збірки)shadedWireframeWordBoolПівтонове зображення з каркасом моделі

Методи цього інтерфейсу дозволяють програмно управляти тривимірним документом, як збіркою і її компонентами, так і окремою деталлю. Звернемо увагу: саме управляти самим документом, але не виконувати в ньому тривимірні операції. Методи, які можуть стати в нагоді нам при програмуванні модулів, що підключаються, наведені в таблиці 3.3.

Таблиця 3.3 Методи інтерфейсу ksDocument3D

МетодОписCloseДозволяє закрити документCreateДає можливість створити порожній документ (деталь або збірку)CreatePartFromFileДозволяє створити деталь в збірціCrealePartInAssemblyПовертає покажчик на інтерфейс деталі, що створюється в збірціDeleteObjectДозволяє видалити тривимірний об'єкт (деталь, операцію, об'єкт допоміжної геометрії, сполучення і ін.)EntityCollectionДає можливість одержати покажчик на масив елементів, вибраних в документі (наприклад, операції або компонентів збірки для їх копіювання по масиву)GetObjParamДозволяє прочитати параметри об'єкту в структуру даних (по певному типу параметрів)ksSetObjParamДозволяє встановити параметри об'єкту в структуру даних (по певному типу параметрів)GetObjectTypeДає можливість одержати тип тривимірного об'єктуGetPartДуже важливий метод, що повертає покажчик на інтерфейс компоненту (деталі або підзбірки) в збірціIsActiveДає можливість перевірити, чи активний документIsDetailПовертає TRUE, якщо тривимірний документ є деталлюOpenДозволяє запустити редагування документа-моделіPartCollectionПовертає покажчик на інтерфейс динамічного масиву

Найважливішим з перерахованих таблиці 3.3 методів є GetPart. Вхідним параметром цієї функції є цілочисельна змінна type_, яка визначає, інтерфейс якого саме компоненту збірки повертати. Дана змінна має декілька зумовлених значень (констант):

·plnPlace_Part (дорівнює -4) - метод повертає покажчик на компонент, який знаходиться в режимі контекстного редагування (тобто редагування «на місці»);

·pNew_Part (-3) - створює в моделі новий компонент і повертає покажчик на нього;

·pEdit_Part (-2) - повертає покажчик на редагований компонент (за допомогою бібліотеки);

·pTop_Part (-1) - верхній компонент, до складу якого входить або новий, або редагований, або вказаний компонент;

·вся решта значень (від 0 і вище) відповідає номеру компоненту в дереві побудови, тобто повертається покажчик на існуючий в збірці компонент.

Метод ksDocument3D.GetPart повертає покажчик на інтерфейс деталі або компоненту збірки - ksPart. Властивості і методи цього інтерфейсу (частина з яких приведена таблиці 3.4 і таблиці 3.5) управляють станом компонентів збірки, вони майже повністю дублюють команди контекстного меню і панелі властивостей, доступні користувачу при роботі з тим або іншим компонентом.

Таблиця 3.4 Властивості інтерфейсу ksPart

ВластивістьТип данихОписexcludedWordBoolВизначає, виключений чи ні компонент з розрахунку (з дерева побудови)fileNameWideStringІм'я файлу, з якого вставлений компонентfixedComponentWordBoolВизначає, чи є компонент зафіксованимhiddenWorbBoolЗадає видимість компоненту (прихований чи ні)nameWideStringІм'я компоненту в дереві побудовstandardComponentWordBoolВизначає, чи є даний компонент стандартним (тобто бібліотечним елементом)

Як бачимо, всі ці методи лише управляють станом компоненту (задають видимість, розміщення, визначають, чи запущено редагування компоненту), але не дають можливість нічого створювати (виконувати операції).

3.3.3 Інтерфейс елементу моделі ksEntity

Для програмної реалізації всіх тривимірних операцій, які користувачі виконують в тривимірних документах системи Компас-3D, в API реалізований єдиний інтерфейс ksEntity - інтерфейс елементу моделі. Цей інтерфейс можна одержати за допомогою методу ksPart.NewEntity, якому необхідно передати тип створюваного елементу. Типів елементів в системі, як і в API системи, велику множину. Кожному з них відповідає своя цілочисельна константа і свій власний інтерфейс параметрів. Саме за допомогою настройок (властивостей і методів) цих інтерфейсів і створюються будь-які можливі об'єкти в деталях і складках КОМПАС-3D. Деякі константи з описом типу елементу і інтерфейсу, до якого вони відносяться, приведені таблиці 3.6.

Таблиця 3.5 Методи інтерфейсу ksPart

МетодОписBeginEditДозволяє запустити режим редагування компонентуColorParamДає можливість одержати покажчик на інтерфейс параметрів кольору і візуальних властивостей компонентуEndEditЗакриває режим редагування компоненту «на місці»EntityCollectionФормує динамічний масив тривимірних об'єктів і повертає покажчик на його інтерфейс (наприклад, операцій для копіювання по масиву)GetDefaultEntityПовертає покажчик на інтерфейс об'єкту, що створюється системою в тривимірному документі за умовчанням. Таких об'єктів всього чотири: початок координат і три ортогональні площиниGetPartДозволяє одержати покажчик на інтерфейс компонентуGetPlacementДає можливість одержати покажчик на інтерфейс місцеположення компоненту в збірціSetPlacementДозволяє встановити нове положення компоненту в збірціIsDetailДозволяє перевірити, чи є компонент деталлюNewEntityНайбільш використовуваний метод: створює інтерфейс нового тривимірного об'єкту і повертає покажчик на нього

Таблиця 3.6 Типи об'єктів тривимірного документа

ІдентифікаторЧислове значенняОписІнтерфейс параметрівo3d_planeXOY1Площина XOYksPlaneParamo3d planeXOZ2Площина XOZksPlaneParamo3d_planeYOZ3Площина YOZksPlaneParam

Члени даних інтерфейсу ksEntity відповідають властивостям тривимірних елементів моделі.

Серед методів найбільш важливими є три наступних:

·Create - створює тривимірну операцію або об'єкт допоміжної геометрії по заданих настройках;

·ColorParam - повертає покажчик на інтерфейс настройок кольору і оптичних властивостей елементу;

·GetDefinition - одержує покажчик на інтерфейс параметрів об'єкту певного типа (параметри даного тривимірного елементу). Саме за допомогою цього методу можна одержати покажчик на будь-який інтерфейс.

Таким чином, створення якої-небудь тривимірної операції призначеною для користувача програмою зводиться до такої послідовності кроків.

. Ініціалізація головного інтерфейсу додатку API - KompasObject. Він ініціалізувався один раз для всього сеансу роботи програми.

. Ініціалізація інтерфейсу тривимірного документу ksDocument3D, з подальшим створенням нового документа або отриманням покажчика на активний документ.

. Створення компоненту і отримання на нього покажчика (інтерфейс ksPart). Для збірки це може бути готовий компонент, компонент, вставлений з файлу або створений «на місці». Для деталі необхідно одержати покажчик на компонент типу pTop_Part.

. Створення за допомогою методу ksPart.NewEntity інтерфейсу потрібної нам операції. При цьому в метод передається відповідний ідентифікатор (наприклад, для витискування - o3d_bossExtrusion).

. Отримання за допомогою методу ksEntity.GetDefinition покажчика на інтерфейс параметрів конкретної операції (для витискування цим інтерфейсом є ksBossExtrusionDefinition). Настройка цих параметрів необхідним користувачу образом.

. Створення операції за допомогою методу ksEntity.Create.

.3.4 Інші інтерфейси IPI Компас

Окрім перерахованих, в API системи КОМПАС існує ще велика безліч різних інтерфейсів, що відповідають за той або інший аспект роботи з програмою. Невелика їх частина описана таблиці 3.7.

компас динамічний бібліотека delphi

Таблиця 3.7 Деякі додаткові інтерфейси API Компас

ІнтерфейсОписksPartCollectionІнтерфейс масиву компонентів збіркиksMacro3DDefinitionІнтерфейс тривимірного макрооб'єктуksMateConstraintCollectionІнтерфейс набору сполучень збіркиksMateConstraintІнтерфейс структури параметрів сполученняksMathematic2DІнтерфейс математичних функцій в графічному документіILibHPObjectІнтерфейс для роботи з характерними точками графічного елементуksDynamicArrayІнтерфейс динамічного масиву параметрівksPhantomІнтерфейс фантомного відображенняksEntityCollectionІнтерфейс масиву об'єктів моделі

4. Опис функціональних можливостей та програмної реалізації прикладної бібліотеки

4.1 Функціональне призначення та технологічні особливості розробки

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

Для спрощення і прискорення розробки креслень, що містять типові і стандартизовані деталі дуже зручно застосовувати готові параметричні бібліотеки.

Прикладна бібліотека може бути створена в одному із стандартних середовищ програмування для Windows з використанням функцій спеціального комплекту розробки додатків Компас-Майстер. По своїй архітектурі бібліотека є стандартним модулем Windows, що динамічно підключається. За умовчанням файли бібліотек мають розширення *.dll або *.rtw.

Компас-3D не накладає ніяких обмежень на розмір і складність функцій бібліотек, а швидкість виконання бібліотечних функцій залежить в основному від характеристик комп'ютера. Після підключення бібліотеки до системи користувач вибирає потрібну функцію з її каталогу і запускає на виконання.

Система динамічних бібліотек, що призначена для автоматизації конструкторської діяльності, була створена за допомогою середовища прискореної розробки програмного забезпечення Delphi з використанням функцій API-інтерфейсу системи Компас-3D.

Завданням виконання дипломної роботи є розробка елементу САПР, що створює при мінімальній кількості початкових даних 3D-модель зубчатого колеса (як прямозубого, так і косозубого).

Розроблена прикладна динамічна бібліотека реалізована у вигляді файлу Gears3D.rtw. Дані про ряд модулів зубчастих коліс, що відповідають ГОСТ 9563-60 зберігаються у зовнішньому файлі бази даних - gears.mdb.

4.2 Розробка логіко-функціональної схеми роботи користувача з бібліотекою та схеми взаємодії бібліотеки з системою

На рис. 4.1 наведена логіко-функціональна схема роботи користувача з бібліотекою.

Рис. 4.1 Логіко-функціональна схема роботи користувача з бібліотекою

Розглянемо схему взаємодії розробленої бібліотеки з системою Компас-3D.

Рис. 4.2 Схема взаємодії бібліотеки з системою

4.3 Конструктивні особливості побудови зубчатих коліс

Рух від однієї ланки механізму до іншої передається за допомогою різних деталей, сукупність яких називається передачею. Одним з основних видів передач є зубчата передача. Зубчата передача між паралельними валами здійснюється циліндровими зубчатими колесами із зовнішнім або внутрішнім зачепленням зубів.

Зубчатими колесами називають деталі, які служать для передачі обертального руху від одного валу до іншого. У зачепленні двох зубчатих коліс одне з коліс називається шестернею. Шестерня - це зубчате колесо передачі з меншим числом зубів.

Основним елементом зубчатих коліс є зубці, а основним параметром зубчатих коліс є модуль. Модуль - це довжина діаметру ділильного кола, що доводиться на один зуб колеса. Стандартом встановлений ряд чисел модулів (ГОСТ 9563-60).

При виборі величини модуля перший ряд віддається перевазі другому. В результаті розрахунку зубчатої передачі конструктор визначає основні параметри коліс: модуль m, число зубців z і ширина зубчатого вінця Lm, по яких розраховуються усі інші розміри зубчатих колес (таблиця 4.1).

Рис. 4.3 Зображення зубчатого колеса

Таблиця 4.1 Розрахунок геометричних параметрів зубчатого колеса

ПозначенняНайменуванняВеличина і залежністьzЧисло зубцівmМодульm= p/p=d/zdДілильний діаметр колесаd=m*z=(p/p)*zpШаг зубцівp=m*pdaДіаметр виступів зубцівda=m*(z+2)dfДіаметр впадинdf=m*(z-2,5)s1Товщина ободаs1=(2,5..4)*ms2Товщина диска, що сполучає маточину з ободомs2=(3..3,5)*mDvДіаметр отвору під валDv=Lm/1,4DmДіаметр маточиниDm=Dv*1,8hВисота зубаh = 2,25*m = da-dfhaВисота головки зубаha = mhfВисота ніжки зубаhf = 1,25*mdoДіаметр отворів в дискуdo=(df-2*s1+Dm)/2

4.4 Опис інтерфейсу користувача бібліотеки

Для того, щоб підключити в системі Компас-3D розроблену прикладну бібліотеку, необхідно обрати в меню підпункт „Сервис - Менеджер библиотек. У вікні „Менеджер библиотек (рис. 4.4) обрати в контекстному меню „Добавить описание - прикладной библиотеки.

Рис. 4.4 Меню підключення прикладної бібліотеки

Після цього на екрані зявиться вікно, в якому необхідно вказати шлях до файлу бібліотеки - gears3D.rtw.

Рис. 4.5 Вікно „Добавить библиотеку

Після завантаження бібліотеки її назва зявиться в переліку доступних бібліотек системи Компас-3D.

Рис. 4.6 Пункт меню для виклику бібліотеки

Після того, як ми виберемо відповідний пункт, на екрані зявиться діалогове вікно бібліотеки.

Рис. 4.7 Діалогове вікно бібліотеки

Для побудови моделі користувачеві необхідно ввести наступні початкові дані:

·модуль;

·кількість зубців;

·ширину зубчатого вінця;

·кут нахилу зубів колеса.

При цьому значення модуля обирається із стандартного ряду згідно ГОСТ 9563-60. Усі ці дані зберігаються у зовнішньому файлі бази даних формату mdb. Якщо ми натиснемо кнопку „ГОСТ, на екрані зявиться вікно (рис. 4.8), в якому ми зможемо продивитися або відредагувати ряд значень.

Рис. 4.8 Вікно редагування значень модулів

Оскільки модулі першого ряду слід використовувати в пріоритетному порядку система передбачає фільтрацію значень модулів згідно обраного ряду.

Після введення усіх необхідних даних (при цьому передбачений захист від некоректного вводу) необхідно натиснути кнопку „Построение. Якщо користувач бібліотеки не введе усіх необхідних початкових даних, він отримає відповідне повідомлення.

Рис. 4.9 Повідомлення системи про некоректний ввід значення модулю

Рис. 4.10 Повідомлення системи про некоректний ввід кількості зубців

Далі система автоматично створює новий документ-деталь та відбувається програмна побудова моделі згідно обраним параметрам.

Рис. 4.11 Загальний вигляд створеної моделі

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

4.5 Програмна реалізація бібліотеки

Дані про ряд модулів зубчастих коліс, що відповідають ГОСТ зберігаються у зовнішньому файлі бази даних - gears.mdb. При цьому повинен зберігатися в каталозі Program Files\ASCON\KOMPAS-3D V10\Bin. Файл бази даних містить лише одну таблицю, структура полів якої наведена на рис. 4.12.

Для доступу до бази даних була використана технологія ADO (компоненти ADOConnection та ADOTable).

Рис. 4.12 Структура полів таблиці, що зберігає дані про значення модулів

Перед початком створення бібліотеки необхідно пов'язати цей файл з бібліотеками типів Компас, щоб можна було користуватися інтерфейсами API. Виконаємо команду Project - Import Type Library, потім із списку Import Type Library вікна, що з'явилося (рис. 4.13), виберемо пункт Kompas6API5 (Version 1.0). При цьому в текстовому полі під списком повинен відобразитися шлях до файлу бібліотек типів Компас. Вибравши вказаний пункт, натиснемо кнопку Create Unit.

Якщо в списку Import Type Library немає необхідного пункту, ми можемо додати його уручну, натиснувши кнопку Add і відшукавши файл kAPI5.TLB (він знаходиться в каталозі Bin директорії, в якій встановлений Компас).

За декілька секунд Delphi згенерує PAS-файл з ім'ям Kompas6API5-TLB, який матиме опис всіх інтерфейсів API 5. Змінимо заголовок скомпільованого модуля (автоматично доданого в проект бібліотеки), з Kompas6API5-TLB на ksTLB і збережемо проект. Після цього закриємо вікно, в якому був відкритий файл Kompas6API5-TLB.pas, у редакторі коду Delphi і змінимо ім'я файлу на ksTLB.pas. Згенерований файл Kompas6API5-TLB.pas з інтерфейсами розміщується в каталозі Imports директорії, в якій встановлений Delphi, наприклад C:\Program Files\Borland\Delphi7\Imports.

Скопіюємо перейменований файл в каталог FirstLib\dcu нашого проекту.

Рис. 4.13 Підключення бібліотеки типів Компас до Delphi

При компіляції прикладної бібліотеки будуть використані безліч різних файлів з описами інтерфейсів, констант та ін. У принципі, вони можуть бути розміщені де завгодно (при цьому в розділі uses слід було б задавати кожен шлях явно), але для зручності роботи з проектом будемо зберігати їх в каталозі dcu, де вже знаходиться файл ksTLB.pas. Де б всі ці файли не знаходилися, в Delphi необхідно вказати шлях до них. Для цього виконаємо команду Project - Options, після чого на вкладці Directories/Conditionals вікна настройок проекту (рис. 4.14), що відкрилося, задамо шляхи до файлів проекту:

·Output directory - шлях, по якому Delphi зберігатиме скомпільований файл прикладної бібліотеки;

·Unit output directory і Search path - повний шлях до каталогу dcu. По цих шляхах система шукатиме необхідні файли бібліотек Компаса, а також зберігати скомпільовані DCU-файли.

Рис. 4.14 Завдання шляхів до файлів проекту прикладної бібліотеки

Розглянемо лістинг створеної нами динамічної прикладної бібліотеки.Gears3D;SysUtils, Classes, ksTLB, ksAuto, Forms, BuildUnit in 'BuildUnit.pas' {GearsForm};

{$E rtw}

{$R *.res}kompas : KompasObject;LibraryName: PChar; pascal;Result := 'Gears3D '; // привласнення імя бібліотеці;LibraryId: integer; pascal;Result := 100; // привласнення ідентифікатору;

Оскільки взаємодію з користувачем планується здійснювати за допомогою діалогового вікна, в проект необхідно додати діалогову форму.

Після створення форми необхідно забезпечити її вивід у вікні Компас. Для виведення діалогового вікна бібліотеки потрібно зробити наступне.

. Одержати дескриптор головного вікна Компас.

. Заборонити доступ користувачу до головного вікна програми.

. Створити об'єкт діалогового вікна і вивести його на екран в модальному режимі.

. Після закриття користувачем вікна бібліотеки знищити вікно і повернути управління головним вікном Компас користувачу.

. Обнулити дескриптор додатку.

Реалізувати цю послідовність дій краще всього в процедурі точки входу в бібліотеку.

LibraryEntry(command: WORD); pascal;GearsForm : TGearsForm;kompas := KompasObject(CreateKompasObject); if (kompas = nil) then exit; //одержуємо дескриптор головного вікна КОМПАС Application.Handle := kompas.ksGetHWindow; // забороняємо доступ до головного вікна kompas.ksEnableTaskAccess(0); // створюємо об'єкт діалогового вікна GearsForm := TGearsForm.Create(Application); GearsForm.ks := kompas; // виводимо діалог на екран GearsForm.ShowModal; // видаляємо об'єкт GearsForm.Free; // повертаємо доступ до вікна kompas.ksEnableTaskAccess(1); Application.Handle := 0; kompas := nil;;

Для того, щоб RTW-бібліотека, написана на Delphi, могла взаємодіяти з Компас, в ній обов'язково повинні бути присутніми як мінімум три функції:- точка входу в бібліотеку;- повертає ім'я бібліотеки, що відображається в менеджері бібліотек;- повертає ідентифікатор бібліотеки (пізніше його можна використовувати при роботі з самою бібліотекою, для підключення списку меню її команд та ін.).

Всі ці функції обов'язково повинні бути експортними, тобто що експортуються з даної DLL, щоб система КОМПАС могла їх бачити і викликати. З цієї причини їх обов'язково потрібно винести в розділ exports прикладної бібліотеки.

LibraryName name 'LIBRARYNAME', LibraryId name 'LIBRARYID', LibraryEntry name 'LIBRARYENTRY';.

Розглянемо процес побудови діалогової форми бібліотеки. Для кнопки „Отмена маємо наступну процедуру.

TGearsForm.Button2Click(Sender: TObject);if CloseQuery then Close;;

Процедура обробки натиснення кнопки „Построение набагато складніше. Умовно її можна розділити на три частини.

. Розрахунок геометричних параметрів зубчатого колеса за введеними початковими даними.

. Створення порожнього документа Компас-Деталь.

. Власне побудова моделі зубчатого колеса.

Програмну побудову моделі колеса реалізуємо такою послідовністю тривимірних операцій.

. Спочатку програмно в площині XOY створюється ескіз, що містить контур половини перетину колеса (рис. 4.15). На підставі цього ескізу виконується операція обертання, що формує заготівку зубчатого колеса.

Рис. 4.15 Ескіз базової операції обертання колеса

. Далі в площині YOZ будується другий ескіз з чотирма колами, над якими виконується операція вирізування в два напрями. Таким чином, ми одержимо отвори в диску.

Рис. 4.16 Ескіз отворів диску

. Наступним кроком є виконання вирізу між зубами у вінці колеса. Цей спосіб полягає в побудові вирізу за допомогою операції „Вырезать по сечениям. При цьому в моделі колеса будується ряд ескізів-перетинів, площини яких віддалені від бічної поверхні колеса на величину l = i · b / (nс - 1) (де b - ширина колеса, nс - кількість перетинів або ескізів, i - порядковий номер ескіза).

Рис. 4.17 Побудова допоміжних площин

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

У кожній з трьох площин (двох допоміжних і ортогональної YOZ) буде створене зображення ескізу вирізу між зубами, повернене щодо вертикальної осі на кут a = 2 · l · tg b / dк, де b - кут нахилу лінії зуба, dк - ділильний діаметр зубчатого колеса. Для першої площини замість l необхідно підставити 0, для другої (YOZ) - b/2, для третьої - b.

Рис. 4.18 Ескіз вирізу між зубами

. У завершенні створюється вісь на перетині площин XOZ і XOY. Щодо цієї осі формується масив по концентричній сітці вирізів між зубами колеса.

Кількість копій встановлюється рівною кількості зубів колеса.

TGearsForm.Button1Click(Sender: TObject);

var ...Hide;

// приховуємо діалогове вікно // прочитуємо параметри, введені користувачем у вікні module := StrToFloat(Edit1.Text); // модуль - обираємо із списку, сформованого на основі ряду ГОСТ z := StrToInt(Edit2.Text); // кількість зубців Lm := StrToFloat(Edit3.Text); // ширина зубчатого вінця beta := StrToFloat(Edit4.Text); // кут нахилу зубів колеса // далі обчислюємо необхідні для побудови параметри Dv := round(Lm/1.4); // діаметр отвору під вал b_k := Lm; // ширина маточини и ширина колеса Dm := 1.8*Dv; // діаметр маточини c := round(0.35*b_k); // товщина диска, що сполучає маточину з ободом delta0 := round(2.5*module/cos(DegToRad(beta))); // товщина обода d_k := module*z;

// ділильний діаметр колеса d_ak := d_k+2*module;

// діаметр виступів d_fk := d_k-2.5*module;

// діаметр впадин Dotv := (d_fk - 2*delta0 + Dm)/2; // діаметр отворів в диску doc3 := ksDocument3D(ks.Document3D()); // одержуємо покажчик на інтерфейс тривимірного документа

// створюємо документ (параметр false означає, що документ у видимому режимі, параметр true - що створюється документ-деталь) if doc3.Create(false, true) then

// заповнюємо параметри документа .author := 'Удовиченко Евгений'; .comment := 'Зубчатое колесо'; .drawMode := 3; .perspective := true; .UpdateDocumentParam(); else exit;

// перевіряємо, як пройшла ініціалізація if (doc3 = nil) then .ksMessage('Не удалось создать документ!'); ; ; iPart := ksPart(doc3.GetPart(pNew_Part)); // одержуємо покажчик на інтерфейс деталі if (iPart <> nil) then begin // інтерфейси ортогональних площин PlaneXOY := ksEntity(iPart.GetDefaultEntity(o3d_planeXOY)); PlaneXOZ := ksEntity(iPart.GetDefaultEntity(o3d_planeXOZ)); PlaneYOZ := ksEntity(iPart.GetDefaultEntity(o3d_planeYOZ)); // інтерфейс ескіза (половина контура перетину колеса) iSketchEntity := ksEntity(iPart.NewEntity(o3d_sketch)); if (iSketchEntity <> nil) then begin

// інтерфейс параметрів ескізу iSketchDef := ksSketchDefinition(iSketchEntity.GetDefinition); if (iSketchDef <> nil) then begin if (PlaneXOY <> nil) then begin

// встановлюємо площину, на якій створюється ескіз iSketchDef.SetPlane(PlaneXOY); iSketchEntity.Create;

// запускаємо процес редагування ескізу, doc - покажчик на інтерфейс ksDocument2D doc := ksDocument2D(iSketchDef.BeginEdit); if (doc <> nil) then begin doc.ksLineSeg(-Lm/2, 0, Lm/2, 0, 3);

doc.ksLineSeg(Lm/2, Dv/2, -Lm/2, Dv/2, 1); r := doc.ksLineSeg(-Lm/2, Dv/2, -Lm/2, Dm/2-0.5*module, 1); doc.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksArcByAngle(-Lm/2+0.5*module, Dm/2-0.5*module, 0.5*module, 180, 90, -1, 1); doc.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksLineSeg(-Lm/2+0.5*module, Dm/2, -c/2-0.5*module, Dm/2, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksArcByAngle(-c/2-0.5*module, Dm/2+0.5*module, 0.5*module, 270, 0, 1, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksLineSeg(-c/2, Dm/2+0.5*module, -c/2, d_fk/2-delta0-0.5*module, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1'); r := doc.ksArcByAngle(-c/2-0.5*module, d_fk/2-delta0-0.5*module, 0.5*module, 0, 90, 1, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksLineSeg(-c/2-0.5*module, d_fk/2-delta0, -b_k/2+0.5*module, d_fk/2-delta0, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksArcByAngle(-b_k/2+0.5*module, d_fk/2-delta0+0.5*module, 0.5*module, 270, 180, -1, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksLineSeg(-b_k/2, d_fk/2-delta0+0.5*module, -b_k/2, d_ak/2-module, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');:= doc.ksLineSeg(-b_k/2, d_ak/2-module, -b_k/2+module, d_ak/2, 1);.ksSymmetryObj(r, 0, 0, 0, 100, '1');.ksLineSeg(-b_k/2+module, d_ak/2, b_k/2-module, d_ak/2, 1); end; iSketchDef.EndEdit; end; end; end; // інтерфейс базової операції обертання iBaseRotatedEntity := ksEntity(iPart.NewEntity(o3d_baseRotated)); // інтерфейс параметрів кольору і візуальних властивостей Color := ksColorParam(iBaseRotatedEntity.ColorParam); Color.specularity := 0.8; Color.shininess := 1; if (iBaseRotatedEntity <> nil) then begin

// інтерфейс параметрів обертання iBaseRotatedDef := (iBaseRotatedEntity.GetDefinition); if (iBaseRotatedDef <> nil) then begin

// настройка параметрів обертання iBaseRotatedDef.SetThinParam(false, dtNormal, 1, 1); iBaseRotatedDef.SetSideParam(true, 360); iBaseRotatedDef.toroidShapeType := false; iBaseRotatedDef.SetSketch(iSketchEntity);

// створюємо операцію обертання

// результат - заготівка зубчатого колеса iBaseRotatedEntity.Create;

end; end; // інтерфейс ескізу (отвори в диску) iSketch1Entity := ksEntity(iPart.NewEntity( o3d_sketch )); if (iSketch1Entity <> nil) then begin iSketch1Def := ksSketchDefinition(iSketch1Entity.GetDefinition); if (iSketch1Def <> nil) then begin if (PlaneYOZ <> nil) then begin

// розміщуємо ескіз на площині YOZ iSketch1Def.SetPlane(PlaneYOZ); iSketch1Entity.Create; doc := ksDocument2D(iSketch1Def.BeginEdit); if (doc <> nil) then begin

// зображення в ескізі - 4 кола створюються викликом методу ksCircle doc.ksCircle(0, Dotv/2, 0.4*(d_fk/2-delta0-Dm/2), 1); doc.ksCircle(0, -Dotv/2, 0.4*(d_fk/2-delta0-Dm/2), 1); doc.ksCircle(Dotv/2, 0, 0.4*(d_fk/2-delta0-Dm/2), 1); doc.ksCircle(-Dotv/2, 0, 0.4*(d_fk/2-delta0-Dm/2), 1); end; iSketch1Def.EndEdit; end; end; end; // інтерфейс операції „Вырезать выдавливанием iCutExtrusion := ksEntity(iPart.NewEntity(o3d_cutExtrusion)); if (iCutExtrusion <> nil) then begin

// інтерфейс параметрів вирізування iCutExtrusionDef := (iCutExtrusion.GetDefinition); if (iCutExtrusionDef <> nil) then begin

// настройка параметрів iCutExtrusionDef.SetSketch(iSketch1Entity);

// напрям iCutExtrusionDef.directionType := dtBoth;

// величина вирізування по кожному з напрямів iCutExtrusionDef.SetSideParam(true, etBlind, c/2, 0 , false); iCutExtrusionDef.SetSideParam(false, etBlind, c/2, 0 , false); iCutExtrusionDef.SetThinParam(false, 0, 0, 0);

// створюємо отвори в диску iCutExtrusion.Create; end; end; // інтерфейс зміщеної площини iOffsetPlaneEntity := ksEntity(iPart.NewEntity(o3d_planeOffset)); if (iOffsetPlaneEntity <> nil) then begin

// інтерфейс параметрів зміщеної площини iOffsetPlaneDef := (iOffsetPlaneEntity.GetDefinition); if (iOffsetPlaneDef <> nil) then begin

// величина, базова площина і інші параметри зсуву iOffsetPlaneDef.Offset := b_k/2; iOffsetPlaneDef.SetPlane(PlaneYOZ); iOffsetPlaneDef.direction := false;

// робимо площину прихованою iOffsetPlaneEntity.Hidden := true;

// створюємо допоміжну площину iOffsetPlaneEntity.Create; end; end; // ескіз першого вирізу між зубами iSketch2Entity := ksEntity(iPart.NewEntity(o3d_sketch)); if (iSketch2Entity <> nil) then begin iSketch2Def := ksSketchDefinition(iSketch2Entity.GetDefinition); if (iSketch2Def <> nil) then begin

// базова площина - допоміжна iOffsetPlaneEntity iSketch2Def.SetPlane(iOffsetPlaneEntity); iSketch2Entity.Create; doc := ksDocument2D(iSketch2Def.BeginEdit); alfa1 := 360/z; doc.ksMtr(0, 0, 90, 1, 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(0)), - (d_ak/2+0.1)*cos(DegToRad(0)), -d_k/2*sin(DegToRad(alfa1/8)), -d_k/2*cos(DegToRad(alfa1/8)), -d_fk/2*sin(DegToRad(alfa1/4)), -d_fk/2*cos(DegToRad(alfa1/4)), 1); doc.ksArcByPoint(0, 0, d_fk/2, -d_fk/2*sin(DegToRad(alfa1/4)),

d_fk/2*cos(DegToRad(alfa1/4)), -d_fk/2*sin(DegToRad(alfa1/2)), -d_fk/2*cos(DegToRad(alfa1/2)), -1, 1); doc.ksArcBy3Points(-d_fk/2*sin(DegToRad(alfa1/2)), -d_fk/2*cos(DegToRad(alfa1/2)), -d_k/2*sin(DegToRad(0.625*alfa1)), -_k/2*cos(DegToRad(0.625*alfa1)), -(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1)), -

(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1)), 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1)), -

(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1)), -(d_ak/2+2)*sin(DegToRad(0.375*alfa1)), -

(d_ak/2+2)*cos(DegToRad(0.375*alfa1)), -(d_ak/2+0.1)*sin(DegToRad(0)), -(d_ak/2+0.1)*cos(DegToRad(0)), 1); doc.ksDeleteMtr; iSketch2Def.EndEdit; end; end; // інтерфейс другого ескізу вирізу між зубами iSketch3Entity := ksEntity(iPart.NewEntity(o3d_sketch)); if (iSketch3Entity <> nil) then begin iSketch3Def := ksSketchDefinition(iSketch3Entity.GetDefinition); if (iSketch3Def <> nil) then begin // будуємо на площині YOZ iSketch3Def.SetPlane(PlaneYOZ); iSketch3Entity.Create; doc := ksDocument2D(iSketch3Def.BeginEdit); alfa2 := -RadToDeg(b_k*tan(DegToRad(beta))/d_k); doc.ksMtr(0, 0, 90, 1, 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(alfa2)), -d_k/2*sin(DegToRad(alfa1/8+alfa2)), -d_k/2*cos(DegToRad(alfa1/8+alfa2)), -d_fk/2*sin(DegToRad(alfa1/4+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/4+alfa2)), 1); doc.ksArcByPoint(0, 0, d_fk/2, -d_fk/2*sin(DegToRad(alfa1/4+alfa2)),

-d_fk/2*cos(DegToRad(alfa1/4+alfa2)), -d_fk/2*sin(DegToRad(alfa1/2+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/2+alfa2)), -1, 1); doc.ksArcBy3Points(-d_fk/2*sin(DegToRad(alfa1/2+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/2+alfa2)), -d_k/2*sin(DegToRad(0.625*alfa1+alfa2)), -

d_k/2*cos(DegToRad(0.625*alfa1+alfa2)), -(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1+alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1+alfa2)), 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1+alfa2)), -(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1+alfa2)), -(d_ak/2+2)*sin(DegToRad(0.375*alfa1+alfa2)), -

(d_ak/2+2)*cos(DegToRad(0.375*alfa1+alfa2)), -(d_ak/2+0.1)*sin(DegToRad(alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(alfa2)), 1); doc.ksDeleteMtr; iSketch3Def.EndEdit; end; end; // друга зміщена площина iOffsetPlane1Entity := ksEntity(iPart.NewEntity(o3d_planeOffset)); if (iOffsetPlane1Entity <> nil) then begin iOffsetPlane1Def := (iOffsetPlane1Entity.GetDefinition); if (iOffsetPlane1Def <> nil) then begin

// величина зсуву та ж iOffsetPlane1Def.Offset := b_k/2;

// напрям протилежний iOffsetPlane1Def.direction := true; iOffsetPlane1Def.SetPlane(PlaneYOZ);

// робимо площину прихованою iOffsetPlane1Entity.Hidden := true;

// створюємо зміщену площину iOffsetPlane1Entity.Create; end; end; // третій ескіз вирізу між зубами iSketch4Entity := ksEntity(iPart.NewEntity(o3d_sketch)); if (iSketch4Entity <> nil) then begin iSketch4Def := ksSketchDefinition(iSketch4Entity.GetDefinition); if (iSketch4Def <> nil) then begin

// базова площина - тільки що створена зміщена iSketch4Def.SetPlane(iOffsetPlane1Entity); iSketch4Entity.Create; doc := ksDocument2D(iSketch4Def.BeginEdit); alfa2 := -RadToDeg(2*b_k*tan(DegToRad(beta))/d_k); doc.ksMtr(0, 0, 90, 1, 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(alfa2)), -d_k/2*sin(DegToRad(alfa1/8+alfa2)), -d_k/2*cos(DegToRad(alfa1/8+alfa2)), -d_fk/2*sin(DegToRad(alfa1/4+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/4+alfa2)), 1); doc.ksArcByPoint(0, 0, d_fk/2, -d_fk/2*sin(DegToRad(alfa1/4+alfa2)), -d_fk/2*cos(DegToRad(alfa1/4+alfa2)), -d_fk/2*sin(DegToRad(alfa1/2+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/2+alfa2)), -1, 1); doc.ksArcBy3Points(-d_fk/2*sin(DegToRad(alfa1/2+alfa2)), -

d_fk/2*cos(DegToRad(alfa1/2+alfa2)), -d_k/2*sin(DegToRad(0.625*alfa1+alfa2)), -

d_k/2*cos(DegToRad(0.625*alfa1+alfa2)), -(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1+alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1+alfa2)), 1); doc.ksArcBy3Points(-(d_ak/2+0.1)*sin(DegToRad(0.75*alfa1+alfa2)), -(d_ak/2+0.1)*cos(DegToRad(0.75*alfa1+alfa2)), -(d_ak/2+2)*sin(DegToRad(0.375*alfa1+alfa2)), -

(d_ak/2+2)*cos(DegToRad(0.375*alfa1+alfa2)), -(d_ak/2+0.1)*sin(DegToRad(alfa2)), -

(d_ak/2+0.1)*cos(DegToRad(alfa2)), 1); doc.ksDeleteMtr; iSketch4Def.EndEdit; end; end; iCutLoftEntity := ksEntity(iPart.NewEntity(o3d_cutLoft)); if (iCutLoftEntity <> nil) then begin // інтерфейс параметрів операції „По сечениям iCutLoftDef := ksCutLoftDefinition(iCutLoftEntity.GetDefinition); if (iCutLoftDef <> nil) then begin

// інтерфейс масиву ksEntityCollection // колекції ескізів для вирізування по перетинах Collect := ksEntityCollection(iCutLoftDef.Sketchs); // додавання ескізів в колекцію Collect.Add(iSketch2Entity); Collect.Add(iSketch3Entity); Collect.Add(iSketch4Entity); // створюємо операцію по перетинах // результат - перший виріз між зубами у вінці колеса iCutLoftEntity.Create; end; end; // інтерфейс допоміжної осі на перетині двох площин iAxis := ksEntity(iPart.NewEntity(o3d_axis2Planes)); if (iAxis <> nil) then begin // інтерфейс параметрів допоміжної осі на перетині площин iAxis2PlDef := ksAxis2PlanesDefinition(iAxis.GetDefinition); if (iAxis2PlDef <> nil) then begin // задаємо площини iAxis2PlDef.SetPlane(1, PlaneXOZ); iAxis2PlDef.SetPlane(2, PlaneXOY); // робимо вісь невидимою iAxis.hidden := true; // створюємо допоміжну вісь iAxis.Create; end; end; // інтерфейс операції Масив по концентричній сітці iCircularCopy := ksEntity(iPart.NewEntity(o3d_circularCopy)); if (iCircularCopy <> nil) then begin

// інтерфейс параметрів операції копіювання по масиву iCirCopyDef := (iCircularCopy.GetDefinition); if (iCirCopyDef <> nil) then begin // колекція операцій для копіювання Collect1 := ksEntityCollection(iCirCopyDef.GetOperationArray); // операція всього лише одна - вирізування зуба Collect1.Add(iCutLoftEntity); // кількість копій рівна числу зубів iCirCopyDef.count2 := z; iCirCopyDef.factor2 := true; // вісь копіювання iCirCopyDef.SetAxis(iAxis); // створюємо концентричний масив iCircularCopy.Create; end; end; end; Close;;

Розглянемо процедури, за допомогою яких був створений інтерфейс користувача бібліотеки. При появі форми відбувається формування списку модулів згідно обраного ряду (за замовченням це перший).TGearsForm.FormShow(Sender: TObject);RadioGroup1Click(Sender);;

Процедура вибору номера ряду.TGearsForm.RadioGroup1Click(Sender: TObject);if RadioGroup1.ItemIndex=0 then // якщо обраний перший ряд ADOTable1.Filter:='ryad=1' // встановлюємо значення фільтру else ADOTable1.Filter:='ryad=2' ; ADOTable1.Filtered:=true; // фільтр включений ADOTable1.First; // перехід на перший запис edit1.Clear; // очищення списку while not ADOTable1.Eof do // перебираємо усі записи таблиці begin edit1.Items.Add(floattostr(ADOTable1modul.AsFloat)); // додаємо значення модулю до списку ADOTable1.Next; // перехід на наступний запис end;;

З а допомогою цієї процедури був реалізований контроль за коректністю вводу даних.TGearsForm.Edit2KeyPress(Sender: TObject; var Key: Char);if not (key in ['0'..'9',#8,'.']) then key:=#0;;

Наступна процедура дозволяє перейти в режим редагування бази даних.

procedure TGearsForm.BitBtn1Click(Sender: TObject);panel2.Visible:=false; panel1.Visible:=true; ADOTable1.Filtered:=false;// відключаємо фільтрацію

end;

Процедура, яка повертає вікно в режим вводу початкових даних моделі.

procedure TGearsForm.BitBtn2Click(Sender: TObject);panel1.Visible:=false; panel2.Visible:=true; RadioGroup1Click(Sender); // оновлюємо список

end;

За допомогою наступних фрагментів коду здійснюється вивід повідомлень для користувача у разі некоректного вводу вхідних даних.

if edit1.Text='' then

// якщо не обрано значення модулю begin ShowMessage('Выберите из списка значение модуля!'); exit; end;

// якщо не введена кількість зубців if edit2.Text='' then begin ShowMessage('Введите число зубьев!'); exit; end;

5. Економічне обґрунтування доцільності розробки програмного продукту

Метою дипломної роботи є дослідження можливостей створення прикладних динамічних бібліотек для системи Компас-3D в середовищі Delphi з використанням функцій API-інтерфейсу. Результатом виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса.

Економічна доцільність розробки полягає в економії витрат порівняно з придбанням комерційних програмних продуктів, здатних виконувати аналогічні функції.

В ході розробки програмного продукту було використане програмне забезпечення Turbo Delphi 2006 Explorer, яке є безкоштовним.

Визначення витрат на створення програмного продукту

Оскільки середа розробки є безкоштовною, витрати на створення програмного продукту складаються з витрат по оплаті праці розробника програми і витрат по оплаті машинного часу при відладці програми:

Зспп=Ззпспп +Змвспп

де: Зспп - витрати на створення програмного продукту; Ззпспп - витрати на оплату праці розробника програми; Змвспп - витрати на оплату машинного часу.

Витрати на оплату праці розробника програми (Ззпспп) визначаються шляхом множення трудомісткості створення програмного продукту на середню годинну оплату програміста (з урахуванням коефіцієнта відрахувань на соціальні потреби):

Ззпспп=tTчас

Розрахунок трудомісткості створення програмного продукту

Трудомісткість розробки програмного продукту можна визначити таким чином:

= to+ tа+ tб+ tп+ tд+ tвід,

де: - витрати праці на підготовку опису завдання;а - витрати праці на розробку алгоритму рішення задачі;б - витрати праці на розробку блок-схеми алгоритму рішення задачі;п - витрати праці на складання програми по готовій блок-схемі;д - витрати праці на підготовку документації завдання;від - витрати праці на відладку програми на ЕОМ при комплексній відладці завдання.

Складові витрат можна виразити через умовне число операторів Q. У нашому випадку число операторів у відлагодженій програмі Q=2500.

Розрахунок витрат праці на підготовку опису завдань

Оцінити витрати праці на підготовку опису завдання не можливо, оскільки це пов'язано з творчим характером роботи, натомість оцінимо витрати праці на вивчення опису завдання з урахуванням уточнення опису і кваліфікації програміста:

= QB/(75…85K),

де:- коефіцієнт збільшення витрат праці унаслідок недостатнього опису завдання, уточнень і деякої недоробки, B=1,2…5;- коефіцієнт кваліфікації розробника, для тих, що працюють до 2 років K=0.8;

Коефіцієнт В приймаємо рівним 3.

Таким чином отримаємо:

= 25003/(780,8) = 120,19 (люд-год).

Розрахунок витрат праці на розробку алгоритму

Витрати праці на розробку алгоритму рішення задачі:

а = Q/(60…75K) а = 2500/(700,8)=44,64 (люд-год).

Розрахунок витрат праці на розробку блок-схеми Витрати праці на розробку блок-схеми алгоритму рішення задачі обчислимо таким чином:

б= Q/(60…75K)б = 2500/(710,8)=44,01 (люд-год).

Розрахунок витрат праці на складання програми Витрати праці на складання програми по готовій блок-схемі обчислимо таким чином:

п= Q/(60…75K)п = 2500/(720,8)=43,40 (люд-год).

Розрахунок витрат праці на відладку програми Витрати праці на відладку програми на ЕОМ при комплексній відладці завдання:

від=1.5 tAвід,

де tAвід - витрати праці на відладку програми на ЕОМ при автономній відладці одного завдання;

tAвід= Q/(40…50K)від = 2500/(480,8)=65,10 (люд-год).

Звідси tвід=1,565,10=97,65 (люд-год).

Розрахунок витрат праці на підготовку документації

Витрати праці на підготовку документації по завданню визначаються:

д= tдр+ tдо,

де:др - витрати праці на підготовку матеріалів в рукопису;до - витрати на редагування, друк і оформлення документації;

др= Q/(150…200K)др = 2500/(1800,8) = 17,36 (люд-год)до=0,75tдрдо =0,7517,36=13,02 (люд-год)

Звідси:

д=17,36+13,02=30,38 (люд-год).

Отже, загальну трудомісткість розробки програмного продукту можна розрахувати:

= to+ tа+ tб+ tп+ tд+ tвід,= 120,19 +44,64 +44,01+43,40 +30,38 +97,65 = 380,27 (люд-год).

Розрахунок середньої зарплати програміста Середня зарплата програміста в сучасних ринкових умовах може варіюватися в широкому діапазоні. Для розрахунку візьмемо середню годинну оплату праці програміста - розробника елементів САПР, яка складає Тчас=18 грн/година. Це означає, що вартість розробки буде становитиму 6 844,86 грн.

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

Єдине соціальне нарахування становить 36,77%.

Тобто 6 844,86 грн36,77%= 2516,86 грн.

Звідси витрати на оплату праці програміста складають:

Ззпспп= 6 844,86+2 516,86 = 9361,72 грн.

Витрати на оплату машинного час

Витрати на оплату машинного часу при відладці програми визначаються шляхом множення фактичного часу відладки програми на ціну машино-години орендного часу: Змвспп =Счас tеом,

де: Счас - ціна машино-години, грн/год; tеом - фактичний час відладки програми на ЕОМ.

Розрахунок фактичного часу відладки Фактичний час відладки обчислимо за формулою:

еом = tп + tдо + tвід ;еом = 43,40 +13,02+97,65 = 154,07 години

Розрахунок ціни машино-години

Ціну машино-години знайдемо по формулі:

Сгод = Зеом/Теом,

де:

Зеом - повні витрати на експлуатацію ЕОМ на протязі року;

Теом - дійсний річний фонд часу ЕОМ, год/рік.

Розрахунок річного фонду часу роботи ПЕОМ

Загальна кількість днів в році - 365. Число святкових і вихідних днів - 114 (10 святкових і 522- вихідні).

Час простою в профілактичних роботах визначається як щотижнева профілактика по 3 години.

Разом річний фонд робочого часу ПЕОМ складає:

Теом = 8(365-114)-523=1852 год.

Розрахунок повних витрат на експлуатацію ЕОМ

Повні витрати на експлуатацію можна визначити по формулі:

Зеом = (Ззп+ Зам+ Зел+ Здм+ Зпр+ Зін),

де:

Ззп - річні витрати на заробітну плату обслуговуючого персоналу, грн/рік;

Зам - річні витрати на амортизацію, грн/рік;

Зел - річні витрати на електроенергію, споживану ЕОМ, грн/рік;

Здм - річні витрати на допоміжні матеріали, грн/рік;

Зпр - витрати на поточний ремонт комп'ютера, грн/рік;

Зін - річні витрати на інші і накладні витрати, грн/рік.

Амортизаційні відрахування

Річні амортизаційні відрахування визначаються по формулі:

Зам=СбалНам,

де: Сбал - балансова вартість компютера, грн/шт.; Нам - норма амортизації, %; Нам =25%.

Балансова вартість ПЕОМ включає відпускну ціну, витрати на транспортування, монтаж устаткування і його відладку:

Сбал = Срин +Зуст ;

де:

Срин - ринкова вартість компютеру, грн/шт.,

Зуст - витрати на доставку і установку комп'ютера, грн/шт;

Комп'ютер, на якому велася робота, був придбаний за ціною Срин =5000 грн, витрати на установку і наладку склали приблизно 10% від вартості комп'ютера.

Зуст = 10% Срин

Зуст =0.15000=500 грн.

Звідси,

Сбал = 5000 +500 =5500 грн./шт., а Зам=55000,25= 1375 грн/год.

Розрахунок витрат на електроенергію Вартість електроенергії, споживаної за рік, визначається по формулі: Зел = Реом Теом Сел А,

де: Реом - сумарна потужність ЕОМ, Теом - дійсний річний фонд часу ЕОМ, год/рік; Сел - вартість 1кВтгод електроенергії; А - коефіцієнт інтенсивного використання потужності машини. Згідно технічному паспорту ЕОМ Реом =0.22 кВт, вартість 1кВтгод електроенергії для споживачів Сел = 0,9302 грн., інтенсивність використання машини А=0,98.

Тоді розрахункове значення витрат на електроенергію:

Зел = 0,22 1852 0,9302 0,98 = 371,42 грн.

Розрахунок витрат на поточний ремонт Витрати на поточний і профілактичний ремонт приймаються рівними 5% від вартості ЕОМ:

Зпр = 0.05 Сбал

Зпр = 0,05 5500 = 275 грн.

Розрахунок витрат на допоміжні матеріали Витрати на матеріали, необхідні для забезпечення нормальної роботи ПЕОМ, складають близько 1 % від вартості ЕОМ:

Звм =0,01 5500 =55 грн.

Інші витрати по експлуатації ПЕОМ

Інші непрямі витрати, пов'язані з експлуатацією ПЕОМ, складаються з вартості послуг сторонніх організацій і складають 5% від вартості ЕОМ:

Зпр = 0.05 5500 =275 грн.

Річні витрати на заробітну плату обслуговуючого персоналу

Витрати на заробітну плату обслуговуючого персоналу складаються з основної заробітної плати, додаткової і відрахувань на заробітну плату:

Ззп = Зоснзп +Здодзп +Звідзп.

Основна заробітна плата визначається, виходячи із загальної чисельності тих, що працюють в штаті:

Зоснзп =12 ?Зіокл,

де: Зіокл - тарифна ставка і-го працівника в місяць, грн; 12 - кількість місяців.

У штат обслуговуючого персоналу повинні входити інженер-електронщик з місячним окладом 2000 грн. і електрослюсар з окладом 1800 грн. Тоді, враховуючи, що даний персонал обслуговує 20 машин, маємо витрати на основну заробітну плату обслуговуючого персоналу, які складуть:

Зоснзп = 12(2000+1800)/20=2280 грн.

Додаткова заробітна плата складає 60 % від основної заробітної плати:

Здодзп = 0,6 2280 = 1368 грн.

Відрахування на соціальні потреби складають 37,6% від суми додаткової і основної заробітних плат:

Звідзп = 0,376(2280 + 1368) = 1371,65 грн.

Тоді річні витрати на заробітну плату обслуговуючого персоналу складуть:

Ззп = 2280 + 1368 +1371,65 = 5019,65 грн.

Повні витрати на експлуатацію ЕОМ в перебігу року складуть:

Зеом = 5019,65 +1375+371,42+55+275+275 = 7 371,07 грн.

Тоді ціна машино-години часу, що орендується, складе

Сгод = 7 371,07 /1852 = 3,98 грн.

А витрати на оплату машинного часу складуть:

Змвспп =Сгодtеом

Змвспп = 3,98 154,07= 613,19 грн.

Розрахунок економічного ефекту

Зспп=Ззпспп +Змвспп

Зспп =9361,72+ 613,19 = 9 974,91 грн.

Тобто собівартість програмного продукту 9 974,91 грн.

А зараз визначимо ціну програмного продукту:

Ц = Зспп + Р,

Где Ц - ціна програмного продукту;

Р - 15% від витрат на створення програмного продукту.

Ц = 9 974,91+ 1496,24 = 11 471,15 грн.

Ціна розробки програмного продукту дорівнює 11 471,15 грн.

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

Аналіз аналогічних розробок, що здатні виконувати схожі функції та мають вартість біля 5 000 руб дозволяє зробити висновок, що розроблене програмне забезпечення за умови тиражування обійдеться значно дешевше, ніж аналоги.

Якщо буде реалізовано 50 копій розробленого програмного продукту, економічний прибуток становитиме:

ЕК = 5 000 * 0,245 * 50 - 11 471,15 = 49 778,85 грн.,

де 0,245 - курс російського рубля Національного банку України.

6. Охорона праці

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

Одна з найважливіших задач охорони праці - забезпечення безпеки працюючих, тобто забезпечення такого стану умов праці, при якому виключено дію на працюючих небезпечних і шкідливих виробничих чинників.

Законодавство України про охорону праці складається із загальних законів України та спеціальних законодавчих актів. Загальними законами України, що визначають основні положення з охорони праці є Конституція України, Закон України «Про охорону праці», Кодекс законів про працю (КЗпП), Закон України «Про загальнообов'язкове державне соціальне страхування від нещасного випадку на виробництві та професійного захворювання, які спричинили втрату працездатності», Закон України „Про забезпечення санітарного та епідемічного благополуччя населення де вказані основні вимоги гігієни та санітарії, параметри мікроклімату на робочих місцях регламентовані ДОСТ 12.1.005-88 і СанПіН 2.24.548-96. Норми штучного та природного освітлення визначені БНіП ІІ-4-79/85. Пожежна безпека викладена в законі України „Про пожежну безпеку і „Правила про пожежну безпеку в Україні.

Крім загальних законів України, правові відносини у сфері охорони праці регулюються спеціальними законодавчими актами, указами і розпорядженнями Президента України, рішеннями уряду України, нормативними актами міністерств та інших центральних органів державної виконавчої влади. Сьогодні проводиться значна робота з питань вдосконалення законодавчої бази з питань охорони праці, адаптації українського законодавства з охорони праці до вимог Європейського Союзу.

6.1 Аналіз небезпечних та шкідливих факторів на робочому місці

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

Небезпечні й шкідливі виробничі фактори підрозділяються за природою дії на наступні групи: фізичні, хімічні, біологічні, психофізіологічні. Перші три групи включають вплив виробничою технікою й робітничим середовищем. Психофізіологічні фактори характеризують зміни стану людини під впливом напруженості праці. Включення їх у систему факторів виробничої небезпеки обумовлене тим, що надмірні трудові навантаження в підсумку можуть також привести до захворювань.

Оператор ЕОМ може зіткнутися з наступними фізично небезпечними й шкідливими факторами:

·несприятливі мікрокліматичні умови;

·підвищений рівень шуму;

·недостатнє або надмірне освітлення.

·підвищений рівень рентгенівських випромінювань;

·підвищенні значення електричного струму та підвищений рівень електромагнітних випромінювань;

·психофізіологічні шкідливі і небезпечні виробничі чинники.

Відповідно діючим нормативним документам (СН 512-78 та ДСанПіН 3.3.2.007-98) площа на одне робоче місце становить 13,0 мІ; обєм - 32,5 мі. Стіна, стеля, підлога приміщення виготовляються з матеріалів, дозволених для оформлення приміщень санітарно-епідеміологічним наглядом. Підлога приміщення вкрита діелектричним килимком, випробуваним на електричну міцність.

Висота робочої поверхні столу для оператора ПЕОМ - 690 мм, ширина повинна забезпечувати можливість виконання операцій в зоні досягнення моторного ходу; висота столу 725 мм, ширина 800 мм, глибина 900 мм. Простір для ніг: висота 600 мм, ширина 500 мм, глибина на рівні колін 500 мм, на рівні витягнутої ноги 650мм.

Ширина й глибина сидіння 400 мм, висота поверхні сидіння 450 мм, кут нахилу поверхні від 15є вперед до 5є назад. Поверхня сидіння плоска, передній край закруглений.

Мікроклімат виробничих приміщень і стан повітряної середи в робочій зоні - головні чинники, які визначають умови праці. Основні параметри мікрокліматичних умов - температура, вологість, швидкість руху повітря і барометричний тиск впливають на теплообмін і загальний стан організму людини. Норми виробничого мікроклімату встановлені системою стандартів безпеки праці ГОСТ 12.1.005-88 та СанПіН 2.24.548-96.

За інтенсивністю праці, виходячи з загальних енергозатрат організму, робота оператора ПК відноситься до категорії Іа (затрати енергії до 139 Вт), яка характеризується роботами, що виконуються в положенні сидячи чи стоячи і не потребують систематичного фізичного навантаження.

В холодні періоди року температура повітря, швидкість його руху і відносна вологість повітря відповідно складають: 22-24 С°; 0,1 м/с; 40-60%; в теплі періоди року температура повітря - 23-25 Сє; відносна вологість 40-60 %; швидкість руху повітря - 0,1 м/с.

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

На організм людини і обладнання ПЕОМ великий вплив виявляє відносна вологість. При відносній вологості повітря більш 75-80% знижується опір ізоляції, змінюються робочі характеристики елементів, зростає інтенсивність відмов елементів ПЕОМ. Швидкість руху повітря виявляє вплив на функціональну діяльність людини і роботу приладів ПЕОМ.

Несприятливий мікроклімат в процесі роботи викликає недомагання і втому організму, порушує нервову і розумову діяльність, сприяє зниженню спостережливості і швидкості реакції.

При роботі на ПЕОМ людина наражається на шумовий вплив з боку багатьох джерел, наприклад, шум, викликаний роботою принтера (70 дБА). Діючи на слуховий аналізатор, шум змінює функціональний стан багатьох систем органів людини внаслідок взаємодії між ними через центральну нервову систему. Це виявляє вплив на органи зору людини, вестибулярний апарат і рухові функції, а також призводить до зниження мускульної дієздатності. При роботі в умовах шуму спостерігається підвищена втомлюваність і зниження дієздатності, погіршується увага і мовна комутація, створюються передумови до помилкових дій працюючих. Згідно з вимогами СанПіН 2.2.2.542-96 гранично допустимий рівень шуму становить 50 дБА.

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

Електронно-променеві трубки, які працюють при напрузі понад 10 кВ є джерелами рентгенівського випромінювання. Шкідливий вплив рентгенівських променів повязаний з тим, що, проходячи через біологічну тканину, вони викликають в тканині іонізацію молекул тканинної речовини, що може призвести до порушення міжмолекулярних звязків, що в свою чергу, призводить до порушення нормальної течії біохімічних процесів і обміну речовин.

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

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

6.2 Заходи щодо нормалізації шкідливих та небезпечних факторів

Згідно БНіП 2.04.05-91 система вентиляції, кондиціювання повітря й повітряного опалення передбачена для суспільних, адміністративно-побутових і виробничих категорій. Витяжні отвори розташовані у стелі. Для забезпечення безпеки життєдіяльності працівників у приміщенні підтримується необхідна якість повітря, тобто оптимальні параметри мікроклімату, сталість газового складу й відсутність шкідливих домішок у повітрі. Для цього в ці приміщення подається певна кількість чистого зовнішнього повітря. Для підтримки температури та інших параметрів мікроклімату використовується опалення, вентиляція, кондиціювання, що є найважливішою частиною інженерного спорудження.

Ефективне рішення проблеми захисту від впливу шуму досягається проведенням комплексу заходів, в які входить ослаблення інтенсивності цього шкідливого виробничого чинника в джерелах і на шляху розповсюдження звукових хвиль. Зниження виробничого шуму в приміщеннях, де розміщені ПЕОМ, досягається за рахунок акустичної обробки приміщення - зменшення енергії відбитих хвиль, збільшення еквівалентної площі звукопоглинаючих поверхонь, наявність в приміщеннях штучних звукопоглиначів. З метою зниження шуму в самих джерелах встановлюються шумогасячі прокладки або амортизатори. В якості засобів звукопоглинання застосовуються не горючі або тяжко горючі спеціальні перфоровані плити, панелі, мінеральна вата з максимальним коефіцієнтом поглинання в межах частот 31,5-8000 Гц.

При правильно розрахованому і виконаному освітленні очі працюючого за компютером протягом тривалого часу зберігають здатність добре розрізняти предмети не втомлюючись. Це сприяє зниженню професійного захворювання очей, підвищується працездатність. Штучне освітлення в приміщеннях експлуатації ПЕОМ реалізується системою загального рівномірного освітлення. У виробничих і адміністративно-суспільних приміщеннях, у випадках переважної роботи з документами, допускається застосування системи комбінованого освітлення (до загального освітлення додатково встановлюються світильники місцевого освітлення, призначені для освітлення зони розташування документів).

Освітленість на поверхні стола в зоні розміщення робочого документа повинна бути 300 - 500 лк, також допускається установка світильників місцевого освітлення для підсвічування документів, але з такою умовою, щоб воно не створювало відблисків на поверхні екрана й не збільшувало освітленість екрана більш ніж на 300 лк. Як джерела світла при штучному висвітленні повинні застосовуватися переважно люмінесцентні лампи типу ЛБ. Допускається застосування ламп накалювання у світильниках місцевого освітлення.

Для розрахунку штучного освітлення використовують метод світлового потоку. Розрахунок за даним способом зводитися до визначення необхідної кількості світильників N для установки в приміщеннях, що визначається по формулі:

(6.1)

Де: Ф - світловий потік лампи, люмен; Е - нормована освітленість, люкс; kз - коефіцієнт запасу (для люмінесцентних ламп kз = 1,1); S - площа освітлювального приміщення, м2; Z - коефіцієнт мінімальної освітленості (для люмінесцентних ламп Z = 1,1); N - кількість електричних ламп; ? - коефіцієнт використання світлового потоку.

Значення коефіцієнта використання освітлювальної установки ? визначають залежно від типу світильника, коефіцієнтів відбиття стелі, стін і підлоги, а також від індексу приміщення і, що характеризує співвідношення розмірів освітлюваного приміщення. Показник приміщення обчислюють по формулі:

(6.2)

Де: L і b - довжина та ширина приміщення, м; hn - висота підвісу світильника над робітничою поверхнею, м.

В приміщенні з розмірами L = 6 м, b = 4 м, h = 3 м робітнича поверхня знаходиться на рівні 0,8 м від полу, тому hn = 2,2 м. Отже, показник приміщення рівний:

По довіднику визначаємо величину коефіцієнту використання світлового потоку ? = 0,45 для і = 1,1 та коефіцієнтів відбивання світла - 70%, 50%, 30%.

Для освітлення використовується люмінесцентна лампа типу ЛБ, потужністю 40 Вт, світловий потік лампи 3000 лм. При загальному типі освітлення значення Е = 300 лк.

Підставимо всі отримані дані в формулу і визначимо необхідну кількість світильників:

(штук)

Отже, за результатами проведених розрахунків можна зробити висновок, що для оптимального освітлення у приміщенні площею 24 м2, необхідно встановити 7 світильників з люмінесцентними лампами потужністю 40 Вт.

Електронно-променеві трубки, магнетрони, тиратрони та інші електровакуумні прилади, що працюють при напрузі вище 6 кВ, є джерелами „мякого рентгенівського випромінювання. При технічній експлуатації апаратури, в якій напруга вище 15 кВ, використовують засоби захисту для відвертання рентгенівського опромінення операторів і інженерно-технічних робітників, бо при такій напрузі рентгенівське випромінювання розсіюється в навколишньому просторі виробничого приміщення. Засобами захисту від „мякого рентгенівського випромінювання є застосування поляризаційних екранів, а також використання в роботі моніторів, що мають біокерамічне покриття і низький рівень радіації.

В якості засобів захисту від чинності мяких рентгенівських променів застосовуються екрани з сталевого листа (0,5-1 мм) або алюмінію (3 мм), спеціальної гуми. Для відвертання розсіювання рентгенівського випромінювання по виробничому приміщенню встановлюють захисні огорожі з різноманітних захисних матеріалів, наприклад, свинцю або бетону.

На сьогоднішній день основним засобом захисту від електромагнітних випромінювань, що застосовуються в обчислювальній техніці є екранування джерел випромінювання. Сьогодні всі монітори, що випускаються, а також блоки живлення мають корпус, виконаний зі спеціального матеріалу, що практично повністю затримує проходження електромагнітного випромінювання. Застосовуються також спеціальні екрани, що зменшують ступінь впливу електромагнітних і рентгенівських променів на оператора. Для зниження електромагнітного впливу на людину-оператора використовуються також раціональні режими роботи, при яких норма роботи на ПЕОМ не повинна перевищувати 50 % робочого часу.

Захист від небезпечних впливів електричного струму при експлуатації обчислювальних комплексів забезпечені:

·застосування захисного заземлення або обнуління;

·ізоляцією струмопровідних частин;

·дотриманням умов безпеки при настанові і заміні агрегатів;

·надійним контактним сполученням з урахуванням перепаду мікрокліматичних параметрів.

Для усунення причин утворення статичного заряду застосовуються провідні матеріали для покриття підлоги, панелей, робочих столів, стільців. Для зниження ступеня електризації і підвищення провідності діелектричних поверхонь підтримується відносна вологість повітря на рівні максимально допустимого значення.

6.3 Пожежна безпека

По класифікації приміщень з ПЕОМ по пожежній небезпеці відносяться до категорії В (БНіП 2.09.02-85), що характеризуються наявністю твердих горючих і важко горючих речовин і матеріалів, а також легкозаймистих матеріалів. Технологічні обємні підлоги виконуються з негорючих або тяжко горючих матеріалів з межею вогнестійкості не менше 0,5. Підпільні простори під обємними підлогами відділяють негорючими перегородками з межею вогнестійкості не менше 0,75 на ділянки площею не більш 250 м2.

Причинами пожежі можуть бути:

паління;

використання нагрівальні прилади в приміщеннях з ПЕОМ;

усування несправності за наявності напруги в мережі;

визначання наявність напруги в ланцюзі, замиканням клем;

використання електроприладів у важко провітрених приміщень.

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

Для гасіння пожеж передбачена наявність первинних засобів пожежегасіння, (згідно «Правил пожежної безпеки в Україні») так і пожежні крани із брезентовими рукавами, пожежні щити (1 щит на 5000м2). В кімнаті знаходиться вогнегасник (ВВ-5). При розміщенні вогнегасників виключений безпосередній вплив на них сонячних променів, опалювальних і нагрівальних пристроїв. За конструкцією, матеріалами, методами контролю, умовами змісту, обслуговуванням вогнегасник відповідає вимогам Правил пристрою і безпечної експлуатації судин, що працюють під тиском.

Для успішного гасіння пожежі велике значення має швидке виявлення пожежі та своєчасний виклик пожежних підрозділів до місця пожежі. Пожежний звязок і сигналізація можуть бути спеціального або загального призначення, радіозвязком, електричною пожежною сигналізацією (ЕПС), сиренами. ЕПС є найбільш швидким та надійним засобом сповіщення про виникнення пожежі. В залежності від схеми зєднання розрізнюють променеві (радіальні) та шлейфні (кільцеві) системи ЕПС. В кімнаті з ПЕОМ розміщений сповіщувач (датчик) тепловий легкоплавкий. При збільшенні температури легкоплавкий сплав розплавляється і пружинячі пластинки, розмикаючись, вмикають ланцюг сигналізації.

У приміщенні знаходиться розроблений і розміщений на видному місці план евакуації людей і матеріальних цінностей при пожежі, з яким ознайомлені працівники підприємства.

Висновки

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

Переворотом в промисловому проектуванні стало застосування в конструюванні тривимірної графіки. Спочатку в будівництві, потім у важкому машинобудуванні, а за ними і в інших галузях почали активно шукати застосування можливостям об'ємної комп'ютерної графіки.

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

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

Для розширення можливостей САПР Компас без зміни початкового коду в ній реалізований механізм бібліотек, що динамічно підключаються. Кожна бібліотека - це файл з розширенням rtw. Насправді це найзвичайніша dll- бібліотека, у якої розширення dll замінене на rtw. Таку бібліотеку легко написати, наприклад в середовищі програмування Delphi. Вона підключатиметься до Компас так само, як і всі інші бібліотеки, і матиме повний доступ до API Компас для виконання різних побудов і маніпуляцій з графічними об'єктами і документами.

Результатом виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса.

Система динамічних бібліотек, що призначена для автоматизації конструкторської діяльності, була створена за допомогою середовища прискореної розробки програмного забезпечення Delphi з використанням функцій API-інтерфейсу системи Компас-3D.

Використання інтерфейсів IDispatch можливо в будь-якому з найбільш поширених сьогодні середовищ програмування (Visual C++, Delphi, C++Builder, Visual Basic). Інтеграція з такими могутніми програмними пакетами дозволяє, крім застосування графічного інструментарію Компас, використовувати в створюваних модулях всі переваги сучасного об'єктно-орієнтованого програмування.

Міністерство освіти і науки, молоді та спорту України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій та управління

Больше работ по теме: