Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

Министерство образования и науки Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

Ульяновский Государственный технический университет

Факультет: Радиотехнический

Кафедра: САПР

Диссертация на соискание степени магистра техники и технологии

Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

Направление: 21020068 "Проектирование и технология электронных средств"

(магистратура) программа "Информационные технологии в проектировании электронных средств"

Кожевников Михаил Олегович

Научный руководитель

к.т.н., профессор А.Ф. Похилько

Ульяновск 2010 г.

УДК 658.512.22

Рецензент

Аннотация

. Название: «Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D»

. Год завершения работы - 2010

. Объем работы: ___ с.

. Количество приложений: 4

. Количество иллюстраций: 44

. Количество таблиц: 6

. Количество источников литературы: 41

Характеристика работы:

1. Цель научной работы:

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

2. Методы проведенных исследований

Теория систем, теория множеств, теория баз данных, формальная логика.

3. Основные результаты научного исследования (научные, практические)

Получен демонстрационный программный модуль реализующий цели научной работы.

4. Наличие документа об использовании научных результатов - нет

Кожевников М.О.

Оглавление

Введение

1. Обзор методов повышения уровня автоматизации проектирования

1.1 Направления развития САПР

1.1.1 Интеллектуализация САПР

1.1.2 Параметризация.

1.1.3 Интеграция САПР

1.1.4 Комплексная автоматизация подготовки производства

1.2 Технологии интеграции инструментальных приложений

1.2.1 От OLE к ActiveX

1.2.2 Понятие COM, принципы работы

1.2.3 Обзор технологий ActiveX и OLE

1.2.4 NET и будущее COM

1.2.5 Универсальный формат обмена XML

1.3 Возможности КОМПАС-3D

1.4 Автоматизация инженерных расчётов

1.5 Выводы

2. Графический процессор ИИС

2.1 Интегрированная Инструментальная Среда

2.2 Технологии интеграции инструментальных приложений

2.2.1 Компас-3D как Графический процессор ИИС

2.2.2 Схема взаимодействия Графического процессора с компонентами интегрированной инструментальной среды

2.2.3 Схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции

2.3 Модель данных и иерархическая структура функций ИИС

2.4 Выводы

3. Программная реализация

3.1 Выбор средств разработки приложений

3.2 Выбор СУБД и разработка структуры базы данных

3.3 Разработка Интерфейсных модулей

3.3.1 Разработка Интерфейсного модуля для КОМПАС-3D

3.3.2 Разработка Интерфейсного модуля для MathCAD

3.3.3 Разработка механизма связывания переменных

3.4 Разработка графического интерфейса пользователя ИИС

3.5 Выводы

4. Апробация программного решения

4.1 Пример проектирования ребристого радиатора в ИИС

4.2 Пример проектирования шпоночной протяжки в ИИС

4.3 Выводы

Заключение

Литература

Приложение 1

Приложение 2

Приложение 3

Приложение 4

Введение

Современные САПР имеют в своем арсенале большое количество средств. В области трехмерного моделирования все приложения обладают примерно одинаковым набором инструментов. Также все САПР имеют поддержку современных стандартов представления моделей (STEP, IGES и т. п.), позволяют использовать сквозной цикл проектирования, отображать дерево построения детали. Что касается инструментов параметризации, здесь тоже все приложения находятся на достаточно высоком уровне, большинство из них могут производить ассоциативные изменения в сборках при изменении одного из компонентов.

Однако до сих пор не решены вопросы комплексной автоматизации производства, когда САПР представляет собой не просто инструмент для инженера, а является частью единого информационного пространства. Зачастую организация использует приложения различных разработчиков, при этом обмен информацией производится в них при помощи файлов различных форматов.[10]

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

Несмотря на огромное число универсальных инструментальных средств автоматизации инженерной деятельности, все они недостаточно эффективны для выполнения комплексной автоматизации конструкторско-технологической подготовки производства конкретного изделия на конкретном заводе. Обязательно найдется круг задач, выпадающих из списка решаемых проблем с использованием той или иной универсальной САПР. Это привело к тому, что разработчики программного обеспечения серьезно взялись за создание программных инструментальных средств, позволяющих на основе базовой САПР программировать модули для решения ряда специфичных задач пользователя.

Наличие инструмента, позволяющего создавать пользовательские программные модули, интегрированные с базовым продуктом, становится все более неотъемлемым условием, выдвигаемым со стороны пользователей САПР.

Также немаловажно формирование системы накопления существующих решений. Давно известно, что гораздо легче создать новый проект на основе готового, чем разрабатывать сложную систему заново. Но это лишь только при условии, что готовый проект понятен разработчику, ему ясны все связи, а это не всегда возможно. Продукты сегодня - это сложные многофункциональные изделия, которые содержат в себе различные электронные и механические узлы, результат труда многих специалистов. Тем более важно, чтобы этот результат мог послужить не единожды, чтобы он мог эффективно развиваться, чтобы на его основе были созданы улучшенные версии и модификации.

Чтобы достичь этого, нужны эффективные способы и инструменты хранения, передачи и модификации этих решений, которые на сегодня не разработаны. В каждой компании существует электронный архив проектов и библиотеки часто используемых элементов, однако модификация их трудоемка. Разработчику проще создать новое, чем разобраться в старом и модифицировать его. Это происходит вследствие отсутствия стандартных методик трехмерного моделирования изделий и деталей, нет четких общепринятых норм, которые касаются внесения элементов параметризации в модель.

Решение вышеперечисленных проблем состоит в построении такой системы, которая, в рамках интегрированной инструментальной среды, обеспечила бы: обработку данных в специализированных приложениях; простые механизмы обмена данными между различными приложениями; поддержку инструментов хранения и передачи готовых проектных решений, а также инструментов для их модификации. Ключевым элементом интегрированной инструментальной среды, безусловно, стоит признать Графический процессор. Именно от свойств этого компонента, его механизмов интеграции во многом будет зависеть возможность построения такой среды. Но не менее важным элементом ИИС является Математический процессор - без полноценной математической поддержки сложно представить себе современный процесс проектирования.

Поэтому цель данной работы можно сформулировать следующим образом:

Повысить эффективность математической поддержки проектирования в системе КОМПАС-3D путём интеграции данного продукта с математическим пакетом MathCAD в рамках интегрированной инструментальной среды.

Достижение поставленной цели потребует решения ряда задач:

·  Исследовать структуру ИИС.

·        Сформулировать требования, предъявляемые к Графическому процессору в интегрированной инструментальной среде.

·        Исследовать возможности и особенности работы систем КОМПАС-3D и MathCAD.

·        Исследовать доступные в КОМПАС-3D и MathCAD механизмы интеграции и инструменты для расширения их возможностей.

·        Исследовать возможные схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции.

·        Разработать структуру базы данных для сохранения результатов проектной деятельности.

·        Разработать Интерфейсные модули для КОМПАС-3D и MathCAD.

·        Разработать программный модуль, реализуйщий основные возможности Управляющего модуля ИИС.

·        Разработать Графический интерфейс пользователя ИИС.

В данной работе, помимо чисто исследовательской части, так же описан процесс разработки CASE-средства, реализующего вышеописанные идеи и задачи. В программной реализации основное внимание уделено интеграции двух важнейших компонентов ИИС - Графического и Математического процессоров, так как основная часть работы пользователя связана именно с ними.

1. Обзор методов повышения уровня автоматизации проектирования

 

.1 Направления развития САПР

 

1.1.1 Интеллектуализация САПР

Стремительное распространение в нашей стране персональных компьютеров сопровождалось не менее стремительным потоком импортных САПР. Все эти системы объединяет одно свойство: крайне низкий уровень их "интеллектуального" развития. Они не способны самостоятельно принять ни одного технического решения и в руках инженера, принимающего все решения, являются не более чем усовершенствованным электронным кульманом. Все богатство инженерных знаний остается в книгах и, по мере способностей и опыта, в человеческих головах [7].

Но люди приходят и уходят, унося из фирм их бесценные сокровища - инженерный опыт.

Квалификацию современных конструкторских САПР можно оценить как уровень техника-чертежника, а должна она в большинстве случаев соответствовать уровню ведущего конструктора.

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

Принципиальное отличие интеллектуальных систем автоматизированного проектирования видится в том, что в качестве исходной информации выступают технические требования к изделию и знания о методах его проектирования, основанные на его функциональном назначении и опыте эксперта. Графический образ изделия появляется (а чаще просто генерируется) позже. Само понятие интеллектуальной САПР говорит о явном присутствии в системе знаний, т.е. о возможности на каком-либо уровне принимать решения без участия проектировщика. Такая возможность может быть обеспечена путем перехода от построения системы проектирования по алгоритмическому принципу работы САПР, на методику объектно-ориентированного подхода. При таком подходе объект проектирования (точнее, его информационная модель) по мере проектирования непрерывно изменяет состояние вплоть до окончания процесса. Объектный подход имеет следующие преимущества [2]:

·   существенно повышается качество разработки в целом и ее фрагментов;

·   системы получаются более компактными и дешевыми;

·   обеспечивается большее удобство в планировании разработок;

·   упрощается процесс внесения изменений;

·   изменение исходных требований не приводит к полной переработке системы;

·   уменьшается риск в разработке сложных систем;

·   подход ориентирован на человеческое восприятие, т.к. для человека более естествен объектный, а не процедурный подход.

·   возможность создания и сопровождения систем специалистами прикладных областей практически без помощи программистов;

·   резкое сокращение за счет вышеупомянутого сроков создания высокоавтоматизированных систем, основанных на знаниях;

·   сокращение трудоемкости программирования за счет автоматической генерации программ на одном из процедурных объектно-ориентированных языков;

·   сокращение трудоемкости адаптации, сопровождения и развития систем силами пользователей.

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

1.1.2 Параметризация

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

Параметрическое моделирование существенно отличается от обычного двухмерного черчения или трёхмерного моделирования <#"607405.files/image001.gif">

Благодаря СОМ, клиентам нет нужды учитывать данные отличия - доступ ко всему осуществляется единообразно. Для доступа к сервисам, предоставляемым любыми типами программного обеспечения, используется одна общая модель.

1.2.3 Обзор технологий ActiveX и OLE

Как OLE, которая теперь снова обозначает только технологии создания составных документов, так и широкий набор технологий под маркой ActiveX, разработаны с использованием СОМ. Многие из этих технологий своими корнями уходят в поддержку составных документов, тогда как другие предназначены совершенно для других целей.

Автоматизация

Электронные таблицы, текстовые процессоры и другие программы предоставляют все виды полезных возможностей. Почему бы не обеспечить доступ к ним и другому программному обеспечению? Чтобы это стало возможным, приложения должны предоставлять свои сервисы не только человеку, но и программам - они должны быть программируемыми. Обеспечение программируемости и является целью Автоматизации (Automation, первоначально называвшейся OLE-автоматизацией).

Приложение можно сделать программируемым, обеспечив доступ к его сервисам через обычный СОМ-интерфейс. Однако так поступают редко. Вместо этого доступ к сервисам приложений осуществляется через диспинтерфейсы (dispinterface). Они очень похожи на интерфейсы, (у него есть методы, клиенты осуществляют к нему доступ через указатель интерфейса и т. д.), но имеют и существенные отличия. В частности, методы диспинтерфейса гораздо проще вызывать клиентам, написанным на простых языках типа Visual Basic. Это очень важно: ведь большинство людей, желающих писать программы, осуществляющие доступ к внутренним сервисам приложений, чаще всего выбирают Visual Basic и аналогичные среды.

Программируемый доступ к внутренним сервисам посредством Автоматизации поддерживается целым рядом различных приложений. Именно эта возможность легкого доступа к мощным средствам существующих приложений делает Автоматизацию одной из наиболее широко используемых технологий на основе СОМ.

Составные документы

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

Для решения этой проблемы предназначена технология OLE (ранее называвшаяся Документы OLE - OLE Documents). Поддерживая нужные СОМ-объекты, каждый с собственным набором интерфейсов, независимые приложения могут совместно работать, чтобы пользователь получил один составной документ. Все эти интерфейсы носят абсолютно общий характер - ни одно приложение не знает, что представляют собой другие. Зачем встраивать в текстовый процессор функции электронной таблицы? OLE поможет просто задействовать в случае необходимости существующее приложение электронной таблицы.

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

При создании составного документа с помощью OLE одно из приложений всегда является контейнером. Как следует из названия, контейнер определяет самый общий документ, в котором содержится все остальное. Другие приложения - серверы - могут размещать свои документы внутри документа-контейнера. При использовании OLE документ сервера может быть либо связан, либо внедрен в документ контейнера.

Управляющие элементы ActiveX

Многим программистам пришлась бы по вкусу возможность построить целое приложение по большей части из готовых компонентов. Именно подобное желание и привело к идее компонентного программного обеспечения - области, где СОМ способен на очень многое. Повторно применимые компоненты можно создавать на основе исключительно самой СОМ, но для этой цели полезно определить и некоторые стандартные интерфейсы, и соглашения. Используя последние, можно создавать компоненты, единообразно выполняющие такие распространенные задачи, как обеспечение пользовательского интерфейса и посылка сообщений клиенту. Эти стандарты и определяет спецификация управляющих элементов ActiveX (ActiveX Controls).

Первоначально управляющие элементы ActiveX были известны под названием управляющие элементы OLE или ОСХ. Microsoft изменила название, чтобы отразить некоторые новые возможности, сделавшие эти элементы более подходящими для Интернета и WWW. Например, управляющий элемент ActiveX может хранить свои данные на странице где-то в WWW либо может быть выкачан с сервера WWW и затем запущен на машине клиента. И контейнер, в котором работает управляющий элемент, не обязан быть средой программирования - вместо этого он может быть средством просмотра WWW.

Управляющие элементы ActiveX - не отдельные приложения. Напротив, они являются серверами, которые подключаются к контейнеру элементов. Как обычно, взаимодействие между управляющим элементом и его контейнером определяется различными интерфейсами, поддерживаемыми СОМ-объектами. Фактически управляющие элементы ActiveX используют многие другие технологии OLE и ActiveX. Например, управляющие элементы обычно поддерживают интерфейсы для внедрения и зачастую предоставляют доступ к своим методам через диспинтерфейсы Автоматизации.[41]

1.2.4 .NET и будущее COM

В 2002 году <#"607405.files/image002.gif">В то время как Maple, MATLAB и Mathematica - это языки программирования. Языки программирования гибкие и мощные, но трудные в использовании и требующие длительного времени на изучение. Поэтому, пользовательский интерфейс сложен, в нем легко допускать ошибки, которые вынуждают проверять и отлаживать весь код. Программирование не визуально и не интерактивно. Невозможно поменять несколько строк в программе и автоматически увидеть результаты. Для этого вам потребуется перекомпилировать и перезапустить программу. Также сложно разделить работу, а потом понять и использовать решения коллег. Не программисты не смогут снова использовать результаты. Даже если вы являетесь программистом, повторное использование чьих-то вычислений требует всестороннего инженерного анализа, чтобы понимать те процессы, которые скрываются за полученными результатами.[8]

Таким образом, благодаря простой и эффективной логике работы, а так же удобному пользовательскому интерфейсу, MathCAD можно признать оптимальным выбором, если речь идет об автоматизации инженерных расчётов. Рассмотрим возможности этого продукта подробнее.является интегрированной системой решения математических, инженерно-технических и научных задач. Он содержит текстовый и формульный редактор, вычислитель, средства научной и деловой графики, а также огромную базу справочной информации, как математической, так и инженерной, оформленной в виде встроенного в Mathcad справочника, комплекта электронных книг <#"607405.files/image003.gif">

1. Принцип работы формульного процессора

Формульный процессор обеспечивает естественный «многоэтажный» набор формул в привычной математической нотации (деление, умножение, квадратный корень, интеграл, сумма и т.д.). Последняя версия Mathcad полностью поддерживает буквы кириллицы в комментариях, формулах и на графиках.

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

В Mathcad встроены средства символьной математики, позволяющие решать задачи через компьютерные аналитические преобразования.

Графический процессор служит для создания графиков и диаграмм. Он сочетает простоту общения с пользователем с большими возможностями средств деловой и научной графики. Графика ориентирована на решение типичных математических задач. Возможно быстрое изменение вида и размера графиков, наложение на них текстовых надписей и перемещение их в любое место документа.является универсальной системой, т.е. может использоваться в любой области науки и техники - везде, где применяются математические методы. Запись команд в системе Mathcad на языке, очень близком к стандартному языку математических расчётов, упрощает постановку и решение задач.

2. Интеграция Mathcad и Pro/ENGINEER

О возможностях интеграции MathCAD говорит тот факт, что начиная с 14-й версии, Mathcad интегрирован с Pro/ENGINEER и с SolidWorks.

В основе интеграции MathCAD и Pro/ENGINEER (см. рис. 1.2) лежит двухсторонняя связь между этими приложениями. Их пользователи могут легко связать любой файл Mathcad с деталью и сборкой Pro/ENGINEER при помощи такой функции системы Pro/ENGINEER, как фичер анализа. Базовые величины, расчитанные в системе Mathcad, могут быть переведены в параметры и размеры CAD-модели для управления геометрическим объектом. Параметры из модели Pro/ENGINEER также можно ввести в Mathcad для последующих инженерно-конструкторских расчётов. При изменении параметров взаимная интеграция двух систем позволяет динамически обновлять вычисления и чертёж объекта.[36]

3. Интеграция Mathcad и SolidWorks

MathCAD Integrator (см. рис. 1.3) представляет собой программный модуль, который позволяет связывать между собой переменные двух продуктов. Он существенно уменьшает усилия пользователей, сокращает цикл разработки изделия, и снижает риск ошибок. Данная технология позволяет автоматически вести параметрическое моделирование в SolidWorks. [35,34]

Ниже приведен список доступных механизмов интеграции:

·   Использование API-интерфейса, который предоставляет доступ к функциям математического ядра. Доступ к этим функциям можно получить из приложений, написанных на различных современных языках программирования. Наиболее важные методы: SetValue (задать значение входных переменных) и GetValue (считать значение выходных переменных).

·   Использование технологии внедренных объектов. Так, например, в рабочий лист можно внедрить объекты Word, Excel, SolidWorks и др.

·   Экспорт/импорт таблицы входных/выходных переменных посредством файла формата табличного редактора Excel - *.xls.

·   Обработка, посредством синтаксического анализа, выходного файла, который c 12 версии представляет собой файл текстового формата - *.xmcd. Запись данных в этот файл производиться на особом «наречии» XML, который основан на собственном словаре. После изучения данного словаря можно получить доступ к обширному списку возможностей.

Из перечисленных механизмов интеграции, наиболее гибким стоит признать синтаксический анализ, а наиболее надежным API-интерфейс.

1.5    Выводы

Анализ современного состояния рынка САПР показывает, что CAD - системы оказывают конструктору слабую помощь с точки зрения всего процесса конструкторского проектирования. Они обеспечивают описание геометрических форм и рутинные операции, такие как образмеривание, генерация спецификаций и т.п. Эти ограничения и чисто геометрический интерфейс оставляет методологию конструкторской работы такой же, какой она была бы при использовании кульмана. Системы автоматизации проектирования технологических процессов и программирования изготовления деталей на станках с ЧПУ подобно CAD - системам, не затронули сам процесс проектирования: САПР ТП - системы могут генерировать технологические процессы, но только при условии предварительного специального описания изделия с помощью конструкторско-технологических элементов. CAM-системой может быть использована геометрическая модель CAD-системы, но все функции САПР ТП - системы перекладываются на конструктора.

Реальные задачи проектирования не сводятся к «электронизации» накопленной инженерной документации. Это серьезный процесс согласованного труда инженеров, управленцев, программистов и т.д. Причем выпуск и передача документации на следующий этап - далеко не определяющая во всем цикле «проектирование - изготовление» составляющая.Главной составляющей автоматизированного проектирования должно являться создание такого информационного описания проектируемого изделия, которое позволяло бы уловить логику каждого проектного решения, оперативно осуществлять изменение проекта, использовать в дальнейшем полученные ранее проектные решения, даже относящиеся к другой области проектирования.

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

С помощью технологий, основанных на спецификации COM, стало возможным создавать программные комплексы, состоящие из множества компонентов, инкапсулирующих методы обработки информации, при этом давая возможность гибко и эффективно пользоваться ими со стороны сторонних приложений, что позволяет «отвязать» несвязанные или слабосвязанные направления проектирования и эффективно решать их по отдельности, не выходя, тем не менее, за рамки общей системы. Это также даёт широкие возможности интеграции узкоспециализированных систем в единый комплекс, решающий эффективно широкий круг задач. Современный уровень построения баз данных позволяет эффективно решать задачи хранения и доступа к данным практически любой сложности. Таким образом, становится возможным создавать сложные программные комплексы, основанные на обработке данных.

2. Графический процессор ИИС

 

2.1    Интегрированная Инструментальная Среда

интеграция компас mathcad

Требования к ИИС

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

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

То, что для эффективной работы проектные процедуры должны быть параметризованны, сегодня не вызывает никаких сомнений, при этом важно, чтобы параметризация не ограничивалась пределами одной системы (одного приложения), т.к. одна система не может удовлетворять всем указанным потребностям.

Конструкторская деятельность предполагает использование различных способов обработки информации, поэтому вопрос интеграции инструментов обработки данных (приложений) и создания интегрированных процедур САПР стоит очень остро.

Решением данного вопроса может стать создании интегрированной инструментальной среды (ИИС), которая бы обеспечивала выполнение следующих требований:

·   возможность интеграции разнородных приложений, удобным для пользователя образом;

·   возможность обработки разнородной информации в специализированных приложениях;

·   работа с содержимым проектного решения, его идейным наполнением;

·   «контекстность» предоставляемой пользователю информации;

·   отказ от конкретных форматов данных и их преобразований.

Для успешного создания ИИС необходимо решить ряд задач:

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

·   необходимо найти как можно более универсальный способ управления различными инструментальными средами САПР без участия программиста;

·   обеспечить возможность включения в проект объектов, построенных в различных средах САПР; Данная задача объясняется невозможностью всесторонней проработки проекта в рамках одной системы проектирования. А именно требования по всесторонней и максимально более тщательной проработке проекта диктует современный уровень задач проектирования.

·   обеспечить параметризацию проектируемых объектов; Без возможности параметризации невозможно сейчас представить себе современную систему проектирования. И это неслучайно - она наиболее точно вписывается в рамки изложенных представлений о процессе автоматизации проектирования. Очень важно и полезно проследить изменение проекта при модификации или подборе ее параметров.

·   обеспечить простое дополнение функциональных возможностей системы; Данную возможность включают в свои системы все разработчики современных САПР. Это объясняется невозможностью приспособить систему для решения всех задач проектирования. Расширить возможности системы позволяет включение новых модулей.

·   разработать формат данных, позволяющий хранить созданные проектные решения в виде отдельных сущностей и связи между ними в пределах имеющихся проектов.

Архитектура ИИС.

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

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

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

Здесь существуют два общих подхода (возможных и в комбинации).

Первый - реализация отдельных модулей обеспечивающих взаимодействие отдельных целевых программ через себя.

Второй - это реализация центрального модуля (ядра), обеспечивающего управление и пересылку данных между вспомогательными модулями, обеспечивающими «приведение» интерфейса целевых программ к интерфейсу ядра. Обе схемы, представленные на рис. 2.1. и рис.2.2.

Рис.2.1.      Схема ИИС с Интерфейсными Модулями

Первая схема хороша при интенсивном обмене данными между двумя отдельно взятыми целевыми программами, т.к. данные, если это вообще необходимо преобразуются напрямую. Недостатком является сильный рост числа промежуточных компонентов приблизительно пропорционально N2/2.

Рис.2.2.      Схема ИИС с Управляющим Модулем

Вторая схема хороша малым числом компонентов N+1, где N-число целевых программ, а также относительно лёгкой масштабируемостью (добавлением новых целевых программ в комплекс). Её недостаток - если между двумя отдельно взятыми целевыми программами идёт интенсивный обмен данными, то процесс разработки может сильно замедлиться из-за непродуктивного двойного преобразования.

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

Рис.2.3.      Общая структура приложения

Структура приложения представлена на рис.2.3. , из которого видно, что приложение будет иметь модульную структуру и включать в себя следующие элементы:

Ядро - основа приложения, осуществляющее всю основную логику. В его "обязанности" будет входить: взаимодействие с базой данных; предоставление универсального интерфейса взаимодействия с Интерфейсными модулями, обеспечение гибкого интерфейса пользователя.

База данных - основное хранилище данных и мета-данных (данных о данных). Должна иметь структуру способную хранить проектные решения и информацию об их связях.

Интерфейсные модули - их основная задача приведение интерфейса взаимодействия с «внешними» САПР («внешние» САПР - существующие системы автоматизированного проектирования, предназначенные для решения специфичного круга задач), к универсальному интерфейсу ядра.

Данная архитектура позволит обеспечить достаточную гибкость и масштабируемость ИИС. После создания ядра реализующего всю логику работы системы, необходимо будет создать интерфейсные модули для взаимодействия с внешними САПР, причем количество модулей будет зависеть от количества используемых в работе внешних САПР. Таким образом, уникальные программные решения требуется создавать лишь для отдельных приложений, а не для отдельных операций, а сами операции выполняются тем приложением из числа присутствующих на рынке ПО, которое более всего подходит для решения требуемой задачи. Необходимость создания нового компонента возникает лишь при введении в процесс проектирования нового типа операций.

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

2.2    Графический процессор в структуре ИИС

Требования, предъявляемые к архитектуре ИИС, в свою очередь, диктуют общие требования к графическому процессору ИИС:

·   Поддержка современных технологий трехмерного твердотельного моделирования.

·   Поддержка современных технологий интеграции.

·   Возможность параметризации проектируемых объектов.

·   Возможность фиксации промежуточных и конечных результатов работы.

Предварительный обзор в первой главе показал, что Компас-3D в целом удовлетворяет этим требованиям. Проведем более глубокий анализ данного программного продукта.

2.2.1 
Компас-3D как Графический процессор ИИС.

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

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

Поэтому важнейшей характеристикой любой современной CAD-системы, наряду с инструментальными средствами моделирования, является возможность автоматизации с помощью различных вспомогательных средств процессов создания типовых элементов, пользовательских модулей, библиотек и их последующего применения.

Это, во-первых, предполагает наличие подсистем, расширяющих стандартные возможности программы, которые позволяют ускорить проектирование собственно объекта (агрегата, механизма, здания), а не отдельно взятой его детали или составляющей. Чаще всего такие подсистемы представляют собой подключаемые модули (библиотеки), функционирующие только в среде «родительского» графического редактора и позволяющие на основе его базовых функций быстро создавать и использовать различные стандартные элементы.

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

Очевидно, что качество любой программы для трехмерного инженерного моделирования определяют отнюдь не только базовые инструментальные средства. Зачастую как раз наоборот: чем больше возможностей для расширения списка доступных средств, тем выше система котируется предприятиями-заказчиками.[11]

Огромный перечень областей применения САПР - первая причина, по которой любая из современных CAD-систем должна быть максимально открытой и обязательно содержать инструменты для создания пакета пользовательских модулей (прикладных библиотек, приложений и т.д.). Второй причиной является ориентация на заказчика. Если, например, подавляющее большинство предприятий, использующих ту или иную систему, работают в машиностроении, а единицы - в области производства медицинского оборудования, то разработчики прикладных приложений вынуждены подстраиваться под первую категорию. Но для заказчиков КОМПАС никаких проблем не возникнет - они могут создать пользовательские модули самостоятельно.

Рассмотрим основные способы создания таких модулей:

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

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

·   использование специальной макросреды КОМПАС-Макро для подготовки пользовательского приложения;

·   применение инструментальных средств КОМПАС-Мастер, то есть собственно написание (программирование) библиотек и приложений.

Создание библиотек фрагментов и моделей

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

Главное преимущество библиотек фрагментов - простота их создания и применения. Большим плюсом таких приложений является также то, что при появлении новых версий КОМПАС не нужно подгонять или изменять их структуру под только что выпущенный релиз. Достаточно загрузить старый файл библиотеки в Менеджер библиотек, и можете не сомневаться - всё будет работать.

Рис.2.4.      Пример пользовательской библиотеки, содержащей модели шпонок, и ее применение

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

Создание библиотек шаблонов

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

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

Рис.2.5.      Пример пользовательской библиотеки шаблонов для создания трехмерной модели гайки

Когда все три рассмотренных выше компонента подготовлены, их нужно собрать в единое приложение. Для этого, пользуясь командой Новая библиотека, следует указать название будущей библиотеки и папку, где она будет размещена. Далее необходимо оформить внутреннюю древовидную структуру библиотеки, то есть разделы и подразделы, в которых будут находиться подготовленные вами шаблоны.

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

Создание пользовательских библиотек с помощью КОМПАС-Макро

КОМПАС-Макро - это интегрированная в систему КОМПАС-3D среда разработки конструкторских приложений на основе языка программирования Python. Почему за основу выбран именно Python? Во-первых, Python распространяется бесплатно и, как следствие, не налагает никаких ограничений на использование и распространение написанных на нем программ. Во-вторых, сегодня Python - один из самых простых и понятных языков программирования, однако при всей своей простоте он мало в чем уступает таким «китам» объектно-ориентированного программирования, как C++ и Object Pascal (Delphi).

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

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

Для того, чтобы на практике убедиться в возможностях данной библиотеки, был проведен небольшой эксперимент: были «зафиксированы» действия пользователя, при выполнение ряда простейших задач - создание эскиза, создание прямоугольника в эскизе, задание размеров сторон прямоугольника, операция выдавливания. Для большей наглядности результаты были сравнены с результатами, которые были получены с помощью подобных средств фиксации действий пользователя (панель для создания макросов и файл протокола) системы SolidWorks. Листинг полученных скриптов приведён в Приложении 1.

Анализ скриптов, полученных в результате эксперимента привел к следующим выводам.

Для скриптов SolidWorks характерно:

·   наличие «мусора» - строк скрипта, которые не принципиальны для сохранения сценария работы пользователя ( изменение вида, выделение объектов, изменение масштаба и т.д.)

·   наличие автоматической генерации имен объектов - наличие «имен» у объектов позволяет обращаться напрямую к ним, минуя координаты. Тоесть позволяет в дальнейшем произвести параметризацию переменных.

Для скрипта КОМПАС-3D характерно:

·   отсутствие «мусора» - каждая строка скрипта необходима для корректного выполнения всего скрипта в целом. Присутствуют на первый взгляд «ненужные» строки, но они полностью описывают свойства создаваемых объектов и без этих строк объекты просто не будут созданы.

·   отсутствие автоматической генерации имен объектов - мы имеем дело только с геометрическими координатами, мы лишены возможности напрямую обращаться к объектам. Произвести параметризацию переменных не представляется возможным

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

КОМПАС-Мастер

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

Доступ к внутренним функциям КОМПАС-График и КОМПАС-3D обеспечивается двумя путями:

·   через экспортные функции, оформленные в виде dll-модулей, которые разработчик подключает к своей программе, - при создании плоских чертежей; через использование СОМ-объектов - при программном формировании твердотельных моделей;

·   с помощью технологии Automation (Автоматизации), реализованной через API (Application Programming Interface - программный интерфейс приложения) системы КОМПАС. Управление и взаимодействие с системой при этом оформлено через интерфейсы IDispatch.

Рис.2.6.      Создание прикладных библиотек с помощью API

Использование интерфейсов IDispatch возможно в любой из наиболее распространенных сегодня сред программирования (Visual C++, Delphi, C++Builder, Visual Basic). Интеграция с такими мощными программными пакетами позволяет, помимо применения графического инструментария КОМПАС, использовать в создаваемых модулях все преимущества современного объектно-ориентированного программирования.

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

Рис.2.7.      Муфты, сгенерированные с помощью приложения, разработанного в среде КОМПАС-Мастер

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

Зато, преодолев все эти трудности, можно получить удобное и гибкое приложение, обладающее функциональностью и интерфейсом, которые полностью удовлетворяют вашим требованиям. Программу можно заставить «думать» - самостоятельно выбирать, анализировать и обрабатывать необходимые данные, производить определенные действия в зависимости от прочитанных значений, делать сложные расчеты и выводы по их результатам и пр. И всё это для того, чтобы максимально облегчить работу инженера, избавить его от выполнения рутинных операций.[12]

Таким образом, если подвести итог всему вышесказанному, можно сделать вывод о том, что система трехмерного твердотельного проектирования КОМПАС-3D действительно соответствует требованиям, предъявляемым к Графическому процессору интегрированной инструментальной среды:

·   Поддерживается большинство современных технологий трехмерного моделирования.

·   КОМПАС-Мастер предоставляет все необходимые инструменты для организации связи с внешними приложениями.

·   Параметризация обеспечивается через присвоение ключевым переменным псевдонимов в панели «Переменные».

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

2.2.2 Схема взаимодействия Графического процессора с компонентами интегрированной инструментальной среды

Такие компоненты ИИС как Ядро, Интерфейс пользователя, Интерфейс взаимодействия с БД, БД являются принципиально важными элементами, без которых невозможно решение проблемы комплексной автоматизации проектирования. Но нельзя не отметить и тот факт, что все вышеперечисленные компоненты выполняют лишь сервисные функции, в своей совокупности облегчая и ускоряя процессор проектирования. В то время как основной объём работ выполняется в Графическом и Математическом процессорах. Следовательно, можно сделать вывод о том, что построение полноценной ИИС без организации продуктивного обмена данными между этими двумя компонентами невозможно.

Поэтому, для того, чтобы исследовать механизмы построения ИИС на базе Компас-3D и однозначно ответить на вопрос, подходит ли данная система трехмерного твердотельного моделирования на роль Графического процессора, необходимо и достаточно уделить основное внимание цепочке, приведенной на рис.2.8.

Рис.2.8.      Цепочка взаимодействия Графического и Математического

процессоров

Именно эта цепочка во многом определяет возможности ИИС и логику её работы. Без полноценного обмена данными между Графическим и Математическим процессором невозможно будет организовать параметризацию, связывание, хранение в БД переменных на уровне всей ИИС.

Как было показано в первой главе, на роль Математического процессора вполне подходит хорошо зарекомендовавший себя MathCAD. Данный выбор обусловлен, прежде всего, двумя особенностями продукта:

·   Поддержка современных механизмов интеграции (API-интефейс, XML-рабочий файл).

·   Необходимый уровень абстракции (иными словами, удобный интерфейс и логика работы: мы просто набираем формулы и получаем результат, подобно расчёту на бумаге; это выгодно отличает MathCAD от других математических пакетов, присутствующих на рынке, со сложным синтаксисом команд)

Благодаря наличию в MathCAD текстового редактора, от отдельного Текстового процессора в структуре ИИС можно на время отказаться, так как это не является принципиально важным для организации её работы.

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

Рис.2.9.      Структура приложения

2.2.3 Схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции.

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

Для MathCAD:

·   API-интерфейс.

·   Технология составных документов.

·   Экспорт/импорт таблицы входных/выходных переменных в Excel.

·   Синтаксический анализ выходного файла.

Для КОМПАС-3D:

·   API-интерфейс.

·   Экспорт/импорт таблицы внешних переменных в Excel.

·   Синтаксический анализ скрипта макроса.

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

Использование только API-интерфейса можно назвать классическим подходом, неоднократно проверенным в различных приложениях. Но данный способ ограничен только тем набором функций и методов, к которым разработчики программного обеспечения открыли доступ.

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

Обе схемы будут апробированы в ходе программной реализации.

Рис. 2.10. Схема взаимодействия MathCAD и КОМПАС-3D на основе API-интерфейса

Рис. 2.11. Схема взаимодействия MathCAD и КОМПАС-3D на основе API-интерфейса и Синтаксического анализатора.

2.3    Модель данных и иерархическая структура функций ИИС

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

Проект (Пр) - наибольшая абстракция, которая хранит в себе все действия пользователя и всю сопутствующую информацию.

Проектная операция (ПО) - некоторый набор действий, выполняемых пользователем и выделяемых им в отдельную смысловую единицу, являющиеся выполнением некоторых действий, которые лишь в совокупности обладают смыслом для пользователя.

Переменная (П) - неотъемлемая часть параметризированной проектной операции и являющиеся следствием параметризации проектных операций. Переменные сами по себе значения не имеют.

Связь (С) - cвязь между переменными операций (П).

Таким образом, модель данных определяется следующими множествами объектов:

1) Множество проектов, Пр

{Прi <Project_ID, Project_Name, Project_Description> }_ID - уникальное число-идентификатор проекта;

Project_Name - имя проекта;

Project_Description - подробное описание содержания проекта.

2) Множество проектных операций, ПО

{ПОi <Operation_ID, Operation_Name, Project_ID, Operation_Type, Operation_Description > }_ID - уникальное число-идентификатор проектной операции;

Operation_Name - имя проектной операции,;

Project_ID - идентификатор проекта, которому принадлежит операция;

Operation_Type - тип проектной операции;

Operation_Description - подробное описание проектной операции.

3) Множество переменных операциям, П

{Пi <Variable_ID, Variable_ID, Operation_ID, Variable_Type, Variable_Value, Variable_Description >}_ID - уникальное число-идентификатор переменной;

Variable_Name - имя переменной, отображающее смысловое наполнение;

Operation_ID - идентификатор операции, которой принадлежит переменная;

Variable_Type - тип переменной;

Variable_Value - значение переменной;

Variable_Description - описание переменной;

) Множество связей между переменными операций С

{Сi<VariableConnection_ID, Variable_ID, VariableConnected_ID >}_ID - уникальное число-идентификатор связи;

Variable_ID - идентификатор переменной;

VariableConnected_ID - идентификатор связанной переменной;

Опираясь на модель данных, можно сформировать иерархическую структуру функций ИИС:

·  Создание проекта

o Вызов диалогового окна с вводомназвания проекта

o   Создание проектной операции. Это Функция вызывается каждый раз, когда создаётся новая проектная операция.

o   Связывания проектных операций

·  Создание проектной операции

o Выбор типа проектной операции

§ Математическая (MathCAD)

§  Графическая (КОМПАС-3D)

o Вызов процессора (Математического или Графического).

o   Создание Расчёта (Геометрической модели) в процессоре.

o   Параметризация Расчёта (Геометрической модели).

o   Сохранения Расчёта (Геометрической модели).

o   Автоматическое создание переменных проектной операции и связывание их с параметрами Расчёта(Геометрической модели).

2.4    Выводы

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

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

Следующие шаги в решении задачи:

1. Разработка Интерфейсного модуля для КОМПАС-3D;

2.      Разработка Интерфейсного модуля для MathCAD;

.        Разработка Модуля взаимодействия КОМПАС-3D и MathCAD;

.        Разработка структуры базы данных;

.        Создание БД на основе выбранной СУБД или драйверов БД;

.        Разработка пользовательского интерфейса для Управляющего модуля ИИС

3. Программная реализация

 

3.1    Выбор средств разработки приложений

Рассматривая современные средства разработки приложений, можно заметить, что их развитие подчиняется определённым закономерностям и тенденциям.

Первой из таких тенденций является использование в программировании объектно-ориентированного подхода, позволившее осуществлять повторное использование кода с большей эффективностью, нежели при применении так называемого модульного программирования. Зачатки объектного подхода появились во многих популярных в 80-х годах средствах разработки, таких, например, как Clipper. Однако расцвет объектно-ориентированного программирования начался с появления языка C++.

Второй немаловажной тенденцией развития средств разработки являлось создание высокопроизводительных компиляторов и стремление использовать скомпилированный код. Известно, что последний обладает существенно более высокой производительностью, чем код интерпретируемый. Отметим, что наличие исполняемого файла как результата создания приложения не гарантирует, что созданный код не является интерпретируемым (типичные примеры средств разработки, создающих исполняемый файл с интерпретируемым кодом - Centura SQLWindows, Visual FoxPro, Clipper, Visual Basic, Developer-2000).

Третьей тенденцией развития инструментальных средств являлось создание визуальных средств проектирования пользовательских интерфейсов, что позволило ускорить работу над проектами, облегчить повторное использование кода и в определенной степени привлечь к созданию приложений начинающих программистов. Наиболее ярким примером такого средства явилось появление в середине 90-х годов Visual Basic, имеющего в своем составе элементы VBX, из которых можно было строить интерфейс приложения, просто размещая их на форме, а также различных средств редактирования ресурсов типа Borland Resource Workshop. Отметим, однако, что в случае Visual Basic пользователь вынужден был довольствоваться готовыми VBX элементами либо создавать их на языке С с помощью других средств разработки.

И наконец, еще одним немаловажным фактором развития инструментальных средств явилась необходимость масштабируемой поддержки баз данных, так как, во-первых, именно информационные системы стали наиболее часто встречающимся типом разрабатываемых приложений и, во-вторых, именно в конце 90-х годов начался массовый переход от настольных СУБД к архитектуре клиент/сервер. Отметим, однако, что далеко не все средства разработки одинаково хорошо поддерживают все СУБД - нередко имеется явная ориентация на поддержку SQL-сервера того же производителя, что и производитель средства разработки (типичный пример - средства разработки Oracle).C# представляет собой следствие влияния всех этих тенденций, так как сочетает в себе удобства визуальной среды разработки, объектно-ориентированный подход, разнообразные возможности повторного использования кода, открытую архитектуру, а также масштабируемый доступ к данным, хранящимся в различных СУБД, как настольных, так и серверных.

Visual C# - объектно-ориентированный <#"607405.files/image017.gif">

Рис.3.1.      Структура Базы Данных

Данная структура БД позволяет описывать множество проектов, проектных операций, переменных и связей между ними.

Исходя из модели данных, имеем множество проектов, каждый из которых имеет свои проектные операции. Каждая проектная операция имеет свои переменные, и характеризуется идентификатором типа операции, из множества типов операций, и т.д.

3.3    Разработка Интерфейсных модулей

3.3.1 Разработка Интерфейсного модуля для КОМПАС-3D

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

Рис.3.2.      Вид панели «Переменные» Компас-3D

Компас-3D поддерживает автоматическую генерацию имен объектов - каждый вновь созданный объект автоматически получает уникальное имя. Но эти имена предназначены лишь для внутреннего использования. Невозможно напрямую обратиться к объекту с уникальным именем из внешнего приложения (возможно только создание итератора и последовательного перехода по объектам определенного типа). Это является следствием особенностей работы графического ядра и налагает некоторые ограничения: доступ из внешних приложений возможен только к тем переменным, которые были заранее созданы пользователем.

Создание переменных, к которым разрешен доступ из внешних приложений через API-интерфейс, происходит с помощью панели «Переменные» изображенной на рис.3.2.

Рис.3.3.      Назначение свойства «Внешняя» для переменной в панели «Переменные» КОМПАС-3D

Рис.3.4.      Пользовательский интерфейс Интерфейсного модуля ExVarCompass3D

Для того, что бы переменная стала доступна для внешних приложений необходимо указать в её свойствах «Внешняя» (см. рис.3.3.), цвет ячейки изменится на синий, сигнализируя нам об изменениях.

Теперь воспользуемся небольшим программным модулем ExVarCompass3D, выполняющего роль Интерфейсного модуля для КОМПАС-3D, что бы на практике убедиться в возможности обмена данными с внешними приложениями (Листинги программного кода для этого и остальных модулей приведены в Приложении 4). Пользовательский интерфейс ExVarCompass3D представлен на рис.3.4.

Как видно из вышеупомянутого рисунка данный Интерфейсный модуль позволяет запускать Компас-3D, открывать в нём файл сборки, считывать внешние переменные в таблицу (имя, значение, комментарий), изменять значения переменных и перестраивать сборку согласно новым данным. Ниже на рис. 3.5. и рис.3.6. показаны этапы работы.

Рис.3.5.      Считывание внешних переменных сборки КОМПАС-3D с помощью Интерфейсного модуля ExVarCompass3D

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

Не имеет смысла приводить полный код программы, но стоит указать основные объекты и методы, которые позволяют работать с переменными, созданными в панели «Переменные» Компас-3D:

// Работа с массивом внешних переменныхvarCol = (ksVariableCollection)part.VariableCollection();(int j = 0; j < varCol.GetCount(); j++)

{

// Считывание переменных с записью в таблицу= (ksVariable)varCol.GetByIndex(j);.TableCompassEV.Rows.Add(var.name, var.value, var.note);

// Запись переменных из таблицы в сборку.value = this.TableCompassEV.Rows[i].Cells[1].Value.ToString();

}

//Перестроение сборки.RebuildModel();

- коллекция, содержащая массив внешних переменных, созданных в Компас-3D.

var - конкретная внешняя переменная, содержащая необходимые нам данные: имя, значение, комментарий.() - метод, позволяющий перестраивать сборку.

По результатам работы в ExVarCompass3D можно сделать вывод о том, что к необходимым нам функциям Компас-3D можно получить доступ через API-интерфейс. Это, в свою очередь, на практике подтверждает, что Компас-3D вполне удовлетворяет требованиям, предъявляемым к графическому процессору в рамках разрабатываемой ИИС.

3.3.2 Разработка Интерфейсного модуля для MathCAD

Хотя в Компас-3D присутствует некоторая математическая поддержка, которая реализована в панели «Переменные», где можно задать различные выражения с участием переменных (см. рис.3.7.), её возможностей явно не хватает при необходимости произвести более сложные расчёты.

Рис.3.7.      Математическая поддержка, реализованная в панели «Переменные» КОМПАС-3D: значение H3 равно значению H1, значение Step вычисляеться согласно выражению (W1+W2)*2

Для решения этой проблемы было принято решение об использовании математического процессора, в роли которого будет выступать известный и хорошо зарекомендовавший себя MathCad.

После анализа функций математического ядра, к которым можно получить доступ через API-интерфейс, было установлено, что для работы с переменными доступны лишь два метода:

objMC.SetValue(Name As String, Value As Variant) - метод используется для того, чтобы задать значение входной переменной с известным именем.

VT_DISPATCH = objMC.GetValue(Name As String) - метод используется для того, чтобы считать значение выходной переменной с известным именем.

Причем для использования этих методов, расчёт в MathCad’е должен быть оформлен определенным образом (см. рис.3.8.)

Рис.3.8.      Оформление расчёта в MathCAD для успешного использования методов SetValue и GetValue.

Для входных переменных необходимо зарезервировать имена, начинающиеся на in с номерами от 0 до 9 (именно это количество входных переменных инициализируется в момент создания, им изначально присваивается значение 0; использование входной переменной in10 уже не допускается, так как она не инициализируется по умолчанию). Эти переменные должны располагаться справа от знака равенства в начале расчета и встречаться лишь один раз.

Для выходных переменных необходимо зарезервировать имена, начинающиеся на out с произвольными номерами. Эти переменные должны располагаться слева от знака равенства в конце расчета и встречаться также лишь один раз.

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

Таким образом, можно сделать вывод, хотя и с некоторыми оговорками, что в MathCad’е имеются инструменты для доступа к входным и выходным переменным через API-интерфейс.

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

Рис.3.9.      Пример простейшего расчёта в рабочем листе MathCAD.

Ниже приведена немного упрощенная структура этого файла:

<regions>

<region region-id="1">

<ml:define>

<ml:id >x</ml:id>

<ml:real>1</ml:real>

</ml:define>

</region>

<region region-id="3">

<ml:define>

<ml:id >y</ml:id>

<ml:real>1</ml:real>

</ml:define>

</region>

<region region-id="7">

<ml:define>

<ml:id >z</ml:id>

<ml:apply>

<ml:plus/>

<ml:id>y</ml:id>

<ml:id>x</ml:id>

</ml:apply>

</ml:define>

</region>

<region region-id="8">

<ml:eval>

<ml:id >z</ml:id>

<result>

<ml:real>2</ml:real>

</result>

</ml:eval>

</region>

<region region-id="29">

<ml:eval>

<ml:id>x</ml:id>

<result>

<ml:real>1</ml:real>

</result>

</ml:eval>

</region>

<region region-id="27">

<ml:eval>

<ml:id >y</ml:id>

<result>

<ml:real>1</ml:real>

</result>

</ml:eval>

</region>

</regions>

После сравнения рабочего листа и структуры файла можно сделать следующие выводы:

Тег <regions> содержит в себе перечень всех регионов рабочего листа.

Тег <region region-id="27"> содержит описание нумерованного региона.

Тег <ml:define> заключает в себе операцию присвоения (:=).

Тег <ml:eval> заключает в себе операцию вычисления (=).

И так далее: понять значение каждого тега не составляет особого труда.

После более подробного анализа можно составить словарь используемого в данном файле «наречия» языка XML и создать синтаксический анализатор для обработки данного файла. Это, в свою очередь, позволит организовать обмен переменными с внешним приложением. Причем мы сможем обращаться к переменным с любым именем - даже если это имя будет не уникально и будет встречаться несколько раз за время расчёта, мы все равно сможем отличить переменные друг от друга по уникальному номеру региона. Применение синтаксического анализатора так же снимает требование на специальное оформление рабочего файла расчёта и ограничение на количество переменных.

Для того, чтобы на практике убедиться в возможности обмена данными с внешними приложениями и сравнить механизмы интеграции (API-интерфейс и XML-анализатора) воспользуемся небольшими программными модулями VarMathCAD_API и VarMathCAD_XML, которые будут выполнять роль Интерфейсного модуля для MAthCAD.

Пользовательский интерфейс VarMathCAD_API и VarMathCAD_XML представлен на рис.3.10. и рис.3.11.

Рис.3.10.    Пользовательский интерфейс Интерфейсного модуля VarMathCAD_API

Рис.3.11.    Пользовательский интерфейс Интерфейсного модуля VarMathCAD_XML

Этапы работы с VarMathCAD_API:

Рис.3.12.    Открытие файла расчета с помощью Интерфейсного модуля VarMathCAD_API.

Как видно из вышеупомянутых рисунков Интерфейсные модули позволяют запускать MathCAD, открывать в нём файл расчёта, считывать входные и выходные переменные в таблицы (имя, значение, тип), изменять значения переменных и пересчитывать расчёт согласно новым данным. Ниже на рис. 3.12., 3.13., 3.14., 3.15., 3.16. показаны этапы работы с данными модулями.

Рис.3.13.    Присваивание значений входным переменным расчета с помощью Интерфейсного модуля VarMathCAD_API

Рис.3.14.    Пересчет расчёта и считывание значений выходных переменных расчета с помощью Интерфейсного модуля VarMathCAD_API.

Этапы работы с VarMathCAD_XML:

Рис.3.15.    Открытие файла расчета, считывание всех переменных с помощью Интерфейсного модуля VarMathCAD_XML.

Рис.3.16.    Изменение значений входных переменных расчета, пересчет расчета, считывание значений выходных переменных расчета с помощью Интерфейсного модуля VarMathCAD_XML

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

Но данный подход представляется малоэффективным. Это, прежде всего, связано с логикой работы MathCad и скудостью функций математического ядра, которые доступны через API-интерфейс.

Особенности работы MathCAD через API-интерфейс:

·   Специальные жесткие требования к оформлению расчёта, которые усложняют работу и снижают эргономичность.

·   Из внешних приложений возможна работа только с обезличенными переменными с префиксами in и out, которые невозможно автоматически , без участия пользователя, сопоставить с реальными именами переменных в расчёте.

·   Нельзя задать значения по умолчанию для входных переменных in в самом теле расчёта, иначе изменение значений этих переменных из внешних приложений станет невозможным.

·   В момент создания инициализируются лишь 10 входных переменных in0-in9 (по умолчанию им присваивается значение ноль). Большее количество входных переменных, не используя матричной формы представления, задействовать невозможно.

Возможности, не реализованные в функциях математического ядра MathCad, которые были бы полезны при доступе через API-интерфейс :

·   Возможность получить список имен и значений всех переменных, участвующих в операциях присвоения и вычисления ( := и = )

·   Возможность обращаться к переменной по номеру графического региона (или по уникальному номеру), что позволит различать переменные с одинаковым именем, встречающиеся несколько раз по ходу расчёта

Обойти указанные особенности логики работы MathCAD и реализовать недостающие возможности математического ядра можно, с помощью синтаксического анализатора, который способен обрабатывать мета-язык рабочего файла MathCAD. Данные выводы были подтверждены при работе с Интерфейсным модулем VarMathCAD_XML. Решение этой задачи стало возможным благодаря введению, наряду с бинарным форматом файла, текстового формата, начиная с 12 версии MathCad’а.

3.3.3 Разработка механизма связывания переменных

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

Подобный механизм был реализован на базе Интерфейсных модулей ExVarCompass3D и VarMathCAD_API, которые работают через API-интерфейс. На их основе был создан программный модуль IntegratorKM_Lite. Пользовательский интерфейс модуля и этапы работы приведены на рис.3.17.,3.18.,3.19.

Как видно из нижеприведенных рисунков в данном программном модуле были объединены возможности ExVarCompass3D и VarMathCAD_API, а так же добавлены инструменты для связывания переменных MathCAD и КОМПАС-3D.

Связывание переменных производиться с помощью двух рядов выпадающих списков, которые содержат в себе список переменных MathCAD - это довольно простой и удобный способ. Переменной КОМПАС-3D автоматически присваивается значение выбранной из списка переменной MathCAD; связи заноситься в базу данных.

Рис.3.17.    Ввод значений входных переменных MathCAD с помощью программного модуля IntegratorKM_Lite.

Рис.3.18.    Пересчёт расчёта MathCAD по нажатии кнопки «Применить» и считывание выходных переменных MathCAD с помощью программного модуля IntegratorKM_Lite.

Рис.3.19.    Связывание переменных MathCAD и КОМПАС-3D c помощью программного модуля IntegratorKM_Lite.

Как следствие ранее перечисленных особенностей работы MathCAD через API-интерфейс, в IntegratorKM_Lite для того, чтобы правильно задать значение входных переменных и определить связи между переменными MathCAD и КОМПАС-3D, в файле расчёта MathCAD приходиться создавать небольшую памятку как на рис.3.20.

Рис.3.20.    Памятка в теле расчёта MathCAD

Это, в свою очередь, значительно снижает преимущества автоматизированного подхода. Поэтому было принято окончательное решение сохранить реализованный в IntegratorKM_Lite механизм связывания переменных, но отказаться от использования API-интерфейса для связи с MathCAD в пользу Синтаксического анализатора.

Таким образом, в основу ИИС будут положены Интерфейсный модуль для КОМПАС-3D ExVarCompass3D, Интерфейсный модуль для MathCAD VarMathCAD_XML, Механизм связывания переменных из модуля IntegratorKM_Lite.

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

3.4    Разработка графического интерфейса пользователя ИИС.

Общий вид графического интерфейса пользователя представлен на рис.3.21.

Рис.3.21.    Общий вид графического интерфейса пользователя ИИС

На рабочем поле присутствуют четыре вкладки «Проекты», «Операции», «Расчёт», «Переменные» (действия доступные на этих вкладках дублируются в верхнем меню).

Менеджер проектов (Рис.3.21.) содержит список всех созданных проектов, проект содержит список документов проекта, в проект можно добавить любой документ, содержащийся в БД ИИС, и связать его с проектной операцией.

В проект можно добавлять как уже существующие проектные операции, так и создавать их в ходе выполнения проекта (рис.3.22).

Рис.3.22.    Содержимое вкладки «Операции»

ИИС работает с двумя типами документов:

·   Документ, хранящий параметризованную модель или сборку КОМПАС-3D. Он представляет собой инструмент параметрического 3D моделирования (Графический документ). Работа с данным типом документа производиться на вкладке «Модель» (рис.3.23).

Рис.3.23.    Содержимое вкладки «Модель». Кнопки позволяют работать с документами КОМПАС-3D

·   Документ, хранящий расчёт MathCAD. Он представляет собой инструмент для выполнения символьных вычислений (Математический документ). Работа с данным типом документа производиться на вкладке «Расчёт» (рис.3.23).

Рис.3.24.    Содержимое вкладки «Расчёт». Кнопки позволяют работать с документами MathCad

При открытии на вкладках «Модель» и «Расчёт» уже созданных документов соответствующих типов автоматически происходит считывание переменных проектных операций в таблицы (рис.3.25).

Рис.3.25.    Считывание переменных проектных операций в таблицы

Связывание переменных происходит с помощью выпадающих списков как показано на рис.3.25. После выбора переменной в выпадающем списке происходит автоматическая передача её значения. Передача данных возможна как в прямом, так и в обратном направлении.

Рис.3.26.    Связывание переменных проектных операций с помощью выпадающего списка

3.5    Выводы

Результатом разработки системы явилось:

·   Разработана структура БД, позволяющая хранить информацию о проектной деятельности.

·   Разработаны три интерфейсных модуля, которые позволили экспериментально опробовать и выбрать подходящие механизмы интеграции;

·   Разработан графический интерфейс пользователя, позволяющий в удобной форме производить обмен данными между КОМПАС-3D и MathCAD;

К направлениям дальнейшей работы можно отнести следующее:

·   Разработка инструментов, которые позволили бы создавать параметризированные макросы или параметризировать создаваемые с помощью КОМПАС-Макро (для сохранения промежуточных результатов работы в КОМПАС-3D) ;

·   Доработка интерфейса пользователя для более удобного процесса проектирования (внедрение как ActiveX-объектов КОМПАС-3D и MathCAD непосредственно в рабочую область, и т.п.);

4. Апробация программного решения

Ниже приведен типовой пошаговый сценарий работы пользователя:

1. Создание нового проекта в Менеджере проектов с помощью кнопки «Создать» (автоматически присваивается номер, вводиться название и описание проекта)

2.      Создаются новые проектные операции в Менеджере проектных операций с помощью кнопки «Создать» (автоматически присваивается номер и вводиться дата, выбирается тип операции, вводиться название и описание операции)

.        Создаётся новый математический документ с помощью кнопки «Создать» на вкладке «Расчёт». Запускается MathCAD, выполняется расчёт. После сохранения расчёта переменные и их значения автоматически заносятся в таблицу «Переменные MathCAD». С этой таблицей можно работать далее, изменяя значение присвоенных переменных и считывая значение вычисленных переменных. Пересчёт расчёта производится с помощью кнопки «Применить» на вкладке «Расчёт».

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

.        Выполняется операция связывания переменных в таблице «Переменные КОМПАС-3D» - значения переменных MathCAD присваиваются внешним переменным КОМПАС-3D с помощью выпадающих списков (столбец таблицы «Перем. MathCAD»).

.        Выполняется перестроение модели по новым данным с помощью кнопки «Применить» на вкладке «Модель».

4.1    Пример проектирования ребристого радиатора в ИИС

          

4.2    Пример проектирования шпоночной протяжки в ИИС

                  

4.3    Выводы

 

В данной главе описан сценарий работы пользователя в программном модуле (в котором реализована значительная часть функций Управляющего модуля ИИС) «Kompas-MathCad Integrator» и проведена апробация данного модуля на двух примерах: Ребристый односторонний радиатор и Шпоночная протяжка (материалы для расчётов приведены в Приложении 2 и 3).

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

К достоинствам разработанного модуля, можно отнести следующее:

·   Простота и понятность интерфейса;

·   Автоматическое считывание переменных и возможность контекстного связывания переменных в момент их создания;

·   Возможность использования ранее накопленных проектных решений целиком или частично;

К направлениям для дальнейшей работы можно отнести следующее:

·   Добавление возможностей параметризации макросов, созданных с помощью библиотеки КОМПАС-Макро или других инструментов (для организации сохранения промежуточных результатов работы);

·   Оптимизация взаимодействия с пользователем;

·   Расширение набора служебных модулей для взаимодействия с другими приложениями (в частности в данной работе не был разработан модуль для интеграции текстового процессора).

 

Заключение

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

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

Практическая часть работы была реализована в виде программного компонента «Kompas-MathCad Integrator», который, являясь связующим звеном, интегрирует возможности графического процессор КОМПАС-3D, математического процессора MathCAD и СУБД MS Access. На практике было доказано, что КОМПАС-3D соответствует требованиям, предъявляемым к графическому процессору. Так же была повышена эффективность математической поддержки в системе КОМПАС-3D.

Завершающим этапом работы стал эксперимент, в ходе которого была доказана работоспособность созданной программы.

 

Литература

1.     Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем, статья - #"607405.files/image047.gif">

. Диаметр отверстия заготовки D.

. Длина отверстия L .

. Ширина b и глубина шпоночного паза t1 .

. Материал заготовок и протяжки.

Последовательность расчета:

. Рассчитывается величина стрелки C по формуле:

С=0,5(D-)

.

. Устанавливается припуск А, который срезается протяжкой

A=t1 - D + C,

. Конструктивная подача или подъем на зуб на сторону Sz выбирается по таблице 1 (Сначала вибирают максимальную подачу из диапазона).

Таблица 1 Величина подъема Sz на сторону, мм

№ п.п	Материал, который обрабатывается	, МПаПодъем на зуб Sz, мм
1	Сталь	< 750	0,05-0,20
2	Сталь	>= 750	0,05-0,12
3	Чугун	-	0,06-0,20
4	Алюминий	-	0,05-0,08
5	Латунь, бронза	-	0,08-0,20

. Глубина впадины зуба протяжки (высота первого зуба)

,

где k - коэффициент заполнения стружечной канавки (табл.2).- длина обрабатываемой поверхности, мм- величина подъема на зуб.

Таблица 2 Коэффициенты заполнения стружечной канавки при обработке металлов

Sz, мм      СТАЛЬ до 400 МПаСТАЛЬ

от. 400 до 700 МПаСТАЛЬ

более

МПаМедь,

латунь,

алюминийЧугун,

Бронза
о 0,03	3,0	2,5	3,0	2,5	2,5
от 0,03 до 0,07	4,0	3,0	3,5	3,0	2,5
более 0,07	4,5	3,5	4,0	3,5	2,0

. Предварительно определяется шаг режущих и калибрующих зубьев

,

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

4, 5, 6, 8, 10, 12, 14, 18, 20, 22, 25.

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

=.

У полученной при расчете величины Zmax дробная часть отбрасывается, но в любом случае необходимо, чтобы Zmax 3. В противном случае шаг уменьшают, рассчитывая по формуле:

,

а потом опять округляют к стандартному меньшему значению.

. Проверка соотношения между шагом и глубиной стружечной канавки:

;

в случае, когда это неравенство не выпонляется, умельшают величину Sz с шагом 0,01мм до меншего значения из диапазона, указанного в табл.1, и повторяют расчет, начиная с п.п.4. Если м при этом решение не найдено, увеличивают шаг , выбирая следующее большее значение из стандартного ряда.

. Определяется высота направляющей части. У шпонковой протяжки она равна высоте хвостовика H1 (таблица 3). По этой таблице определяются и все остальные размеры хвостовика.

. Площадь опасного сечения хвостовика необходимо также выбрать из таблицы 3 в зависимости от размера шпонкового паза.

Таблица 3 Размеры хвостовиков под кулачковые патроны для шпонковых протяжек

Размеры хвостовика, мм								Площадь опасного сечения
b	l1	B1	H1	a1	a	f	b1		Fхв. мм2
6	70	10	15	15	20	4	6		49,4
8	70	12	18	15	20	6	8		143,6
10	70	15	22	15	20	6	10		219,6
12	80	-	28	18	20	6	8		224

Примечание. l1 - длина захода хвостовика в тяговый патрон. Dотв. - диаметр отверстия.

. Площадь опасного сечения по канавке первого зуба рассчитывается согласно формул (табл.3):

. Подсчитывается наибольшая сила протягивания в Н по формуле

,

где , х=0,85

. Проверка протяжки на прочность. На проочность протяжки проверяются по впадине первого зуба по формуле

;

и по хвостовику

;

где - допустимое напряжение на разрыв (для быстрорежущей стали =200 МПа, для легированной стали =150 МПа).

У протяжек с хвостовиками под клиновой зажим (табл.3) выполняют еще проверочный расчет на смятие клина по формуле:

.

Тут площадь смятия

где b1 - ширина паза под клин, мм;- ширина шпоночного паза, мм.

Допустимое напряжение смятия :

для легированной стали - =(400-450) МПа ;

для быстрорежущей стали - =600 МПа;

В случае, когда какое-либо условие прочности не выполняется, уменьшают величину Sz с шагом 0,01мм до меншего значения из диапазона, указанного в табл.1 и повторяют расчет, начиная с п.п.4. Если и в этом случае решение не найдено, увеличивают шаг , выбирая следующее большее значение из стандартного ряда и повторяют расчет, начиная з п.п.№6.

. Определяется высота калибрующих зубьев

к = Hхв +A ,

где Hхв - высота хвостовика, мм;- припуск на протягивание, мм.

. Определяется число режущих зубьев

. Рассчитываются размеры режущих зубьев. Высота первого режущего зуба H1 принимается равной высоте хвостовика:

=Hхв

H2=H1+Sz ; H3=H2+ Sz ; H4=H3+ Sz i т.д.

Последние два режущих зуба рассматриваются как переходные, а их высота определяется суммироваанием 0,6 Sz i 0,4 Sz

Необходимо проверить, чтобы высота последнего режущего зуба равнялась высоте калибровочных:

=Hк=Нхв+А

Если это условие не выполняется, корректируют высоту последнего режщего зуба.

. Формируется таблица размеров режущих зубьев по форме:

Тип зубьев	Режущие					Калибрующие
Допуск, мм0,01мм0,005мм
Высота зуба H, мм
Номер зуба	1	2	3	4

. Число каалибрующих зубьев принимают=4

. Суммарная длина протяжки

,

где l - расстояние от торца хвостовика до первого зуба, которая составляет 160мм и выбирается в зависимости от длины передней направляющей, длины направляющей втулки (адаптера), длины хвостовика, который входит в патрон и толщины упорной плиты станка;-длина рабочей части протяжки. Она равна сумме длин режущей и калибрующей частей:

l1=lр+lk .

Длина режущей части

,

а калибрующей

У шпоночных протяжек задней направляющей части не делают. Ее функцию выполняет последний калибрующий зуб с шагом 1,5 Рк . Поэтому

Тут Рк - шаг калибровочных зубьев.

. Выполняется проверка на то, чтобы суммарная длина протяжки была не больше допустимой величины, которая приведена в таблице 5.

Таблица 5 Наибольшая допустимая величина шпоночных протяжек

Площадь сечения хвостовика , мм2L доп., мм
35	500
50	700
190	900
240	1000

Если общая длина шпоночной протяжки превышает длину Lдоп., тогда припуск A делится на принятое число проходов n. При этом расчет протяжки проводится для припуска А/n.

Рис. 1. Форма и размеры стружечных канавок черновых зубьев протяжки

. Определяются элементы профиля зубьев протяжки в осевом сечении (рис.1):

ширина спинки ; радиус дна впадины r= 0,50X h; радиус спинки .

. Определяем величины углов: переднего и заднего согласно табл.6.

Таблица 6 Величины переднего угла у протяжек

Обрабатываемый материал	Угол g , град.
Сталь в МПа 60016
Сталь в МПа 600 до 100014
Сталь в МПа > 100010
Чугун НВ 15010
Чугун НВ > 150	6
Алюминий	13
Бронза	3

Выбирается задний угол :

для режущих зубьев ;

для калибрующих зубьев .

Величина фаски f на режущих зубьях не более 0,05мм, на калибрующих - 0,2-1мм.

. Ширина режущей части протяжки равна:

. Выводятся на экран (по запросу) все рассчитанные результаты, которые относятся к параметрам протяжки.

3.РАЗРАБОТКА РАБОЧЕГО ЧЕРТЕЖА ШПОНОЧНОЙ ПРОТЯЖКИ:

Вычерчивается профиль стружечной впадины между двумя соседними зубьями (рис.1), который состоит из:

·  задней поверхности предыдущего зуба шириной С;

·        передней поверхности следующего зуба, размещенной под углом , вершина которого находится выше предыдущего на величину подъема на зуб Sz.

·        дуги окружности, касательной к передней поверхности и линии, которая определяет глубину канавки h.

·        дуги окружности спинки зуба, которая проходит через конец линии задней оверхности, касательно к дуге впадины стружечной канавки.

Проводится копирование этого профиля в количестве, равном числу режущих и калибровочных зубьев. При этом обеспечивается сдвиг каждого профиля по отношению к предыдущему на величину шага в горизонтальном направлении и на заданную величину подъема на зуб - в вертикальном (для переходных подъем уменьшенный, а для калибровочных - равен нулю). Дочерчивается хвостовик, на расстоянии 160мм от первого зуба до левого торца хвостовика. Линия нижней поверхности хвостовика продолжается на полную длину протяжки и оформляется задняя часть, как показано на рис.2.

Рис.2.Протяжка шпоночная обыкновенная: 1 - для протяжек, работающих в один проход; 2 - для протяжек, работающих в несколько проходов.

 

Приложение 3

РАСЧЕТ РАДИАТОРА ПОЛУПРОВОДНИКОВОГО ПРИБОРА

(по материалам [3,21])

Исходные данные

tп.max - максимальная температура перехода;

Rвн - внутреннее тепловое сопротивление прибора;

Ррас - мощность рассеиваемая прибором;

tc - температура окружающей среды;

Rкт - контактное сопротивление прибор - теплосток (величина Rкт лежит в пределах 0,1-1,0 град/Вт).

Последовательность расчета

. Мощность рассеяния прибора при заданных условиях

,

где Rтс - тепловое сопротивление теплосток (радиатор)-среда. Необходимо выполнить условие Рmax > Ррас.

. Тепловое сопротивление теплосток - среда

,

где q - коэффициент, учитывающий неравномерность распределения температуры по радиатору (q » 0,9).

. Среднеповерхностная температура перегрева радиатора (рис. 2.8)

- tc =Ppac · Rтс

. По D t (рис. 2.9) находят минимальную высоту радиатора Lmin.

. Задаются габаритами радиатора: l - ширина радиатора, b - расстояние между ребрами, h - высота ребра, d - толщина основания. Рекомендуется придерживаться следующих соотношений: при основании радиатора 90´ 90 мм; d = 3мм; d = 5 мм; h = 20 мм; b = 12 мм (естественная конвекция) и b = 6 мм (принудительное движение воздуха).

. Расстояние между ребрами

,

где n и d - число и толщина ребра.

Расстояние между ребрами определяют из условия b ³ А, где А толщина пограничного слоя (при естественной конвекции А = 8-10 мм, вынужденной - А » 2,5 мм).

Толщина и высота ребра выбираются из условия

,

где h - высота ребра; a - суммарный коэффициент теплоотвода; l - теплопроводность материала радиатора. Ширину радиатора l определяют из конструктивных соображений, считая l » 0,9 Lmin:

 = n (b + d ) - b.

Материалы для радиаторов

	g , кг/м3	l , Вт/(м· ° С)
Медь Сплавы алюминия Сплавы магния Сталь Нержавеющая сталь	8960 2660 1760 7840 7840	370 160 170 55 14

Степень черноты поверхностей некоторых материалов

Алюминиевый сплав с шероховатой поверхностью Алюминиевый сплав окисленный Алюминиевый сплав анодированный (черный) Медь окисленная

0,06-0,07 0,20-0,30 0,80-0,85 0,80-0,88

. Целесообразность оребрения радиатора определяется по критерию Био

i = 0,5ad/l,

< 1 (ребро охлаждается), Bi >1 (ребро изолятор), Bi = 1 (ребро не влияет).

. Всю поверхность радиатора разбивают на части:

S1 - поверхность между ребрами;

S2 - поверхность ребер, обращенная друг к другу;

S3 - поверхность крайних ребер;

S4 - поверхность торцов ребер;

S5 - неоребренная поверхность.

Неоребренная поверхность S5 = l· L

Оребренная поверхность

 

Sореб= S1+ S2+ S3+ S4=(n-1)· (bLmin)+ 2hl(n-1)+2(h +d)Lmin+ n[ 2hd +d Lmin] .

. Полные коэффициенты теплоотдачи оребренной и неоребренной поверхностей

a гл = a л.гл + a к.гл; a ореб = a л.ореб + a к.ореб; a л = e п· j ij· f(tт,tс).

Для поверхностей S1 и S2 коэффициенты взаимной облученности определяются из графика (рис. 2.10) или рассчитываются

.

Конвективный коэффициент теплоотдачи, Вт/(см2·  С)

aк = 5,62A(tм)· B,

где tм = 0,5(tт + tc);

Величина А(tм) учитывает свойства среды и находится по графику (рис. 2.11).

Влияние атмосферного давления на величину А(tм) находят из графика рис. 2.12.

. Мощность, рассеиваемая гладкой поверхностью радиатора, Вт,

гл = aгл · Sгл · (tт - tc).

. Величина теплового сопротивления гладкой поверхности,  C/Вт,

.

. Мощность, рассеиваемая оребренной поверхностью

,

где Рi - мощность, рассеиваемая i-й поверхностью; tic - температура среды между ребрами.

Температура воздуха вблизи поверхностей S3; S4 и S5 равна tc.

Температура воздуха вблизи поверхностей S1 и S2 (между ребрами) равна

 

tic = tт - (tт - tc)· H,

где H - относительный температурный напор, tт - среднеповерхностная температура теплостока.

Если ребра располагаются вертикально, то

 

Н = f(h ),

где h = А4(tм)bC, tм = 0,5(tт + tc), C= (tт - tc)1/4/(L)1/4 (рис. 2.13 и 2.14).

ci = tc для S3, S4, S5. tci = tic для S1 и S2 (конвективный коэффициент торцевых поверхностей ребер принимается равным крайним ребрам).

Тепловое сопротивление оребренной поверхности, ° C/Вт

.

Общее тепловое сопротивление

.

Мощность, рассеиваемая радиатором, Вт

 

Робщ.расч= Ргл + Рореб.

Необходимо выполнить условие Робщ.расч  Рисх (расч).

Приложение 4

ЛИСТИНГИ ПРОГРАММНОГО КОДА (C#)

ОСНОВНЫХ ФУНКЦИЙ РАЗРАБОТАННЫХ МОДУЛЕЙ

D

//Подключение библиотек для работы с КОМПАС-3DKompas6Constants;Kompas6Constants3D;

//В зависимости от установленной версии подключаються разные библиотеки

#if (__LIGHT_VERSION__)Kompas6LTAPI5;

#elseKompas6API5;

#endifKAPITypes;

// Создаём объекты для работы с КОМПАС-3DKompasObject kompas; // Объект КОМПАС-3DksDocument3D doc3D; // 3D-Документ КОМПАС-3Dstring LastPathCompass; Путь к файлу КОМПАС-3D

// Активируем КОМПАС-3Dvoid ActiveCompass()

{(kompas == null)

{

#if __LIGHT_VERSION__t = Type.GetTypeFromProgID("KOMPASLT.Application.5");

#elset = Type.GetTypeFromProgID("KOMPAS.Application.5");

#endif= (KompasObject)Activator.CreateInstance(t);

}

}

// Открываем файл Компас-3Dvoid OpenFileCompass()

{(kompas != null)

{OpenFileDialog = new OpenFileDialog();.Filter = "КОМПАС-3D Документы (*.m3d;*.a3d)|*.m3d;*.a3d";(OpenFileDialog.ShowDialog() == DialogResult.OK)

{.Text = OpenFileDialog.FileName;= CompassPath.Text;D = (ksDocument3D)kompas.Document3D();(doc3D != null) doc3D.Open(OpenFileDialog.FileName, false);

// Делаем Компас-3D видимым.Visible = true;

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Активируем КОМПАС-3D и открываем файлvoid StartCompass_Click(object sender, EventArgs e)

{();();

}

// Закрываем Компас-3D, закрываем формуvoid Exit_Click(object sender, EventArgs e)

{(kompas != null)

{.Quit();.ReleaseComObject(kompas);

}();

}

// Считываем значение внешних переменных КОМПАС-3Dvoid Compass_EV_Read_Click(object sender, EventArgs e)

{(kompas != null)

{.Visible = true;(doc3D != null)

{(doc3D.IsDetail())

{.ksError("Текущий документ должен быть сборкой");;

}

// Выбор компонента -1 главный(сама сборка),0 первый(первая деталь)part = (ksPart)doc3D.GetPart(-1);(part != null)

{

// Работа с массивом внешних переменныхvarCol =

(ksVariableCollection)part.VariableCollection();(varCol != null)

{var = (ksVariable)kompas.GetParamStruct

((short)StructType2DEnum.ko_VariableParam);(var == null) return;.TableCompassEV.Rows.Clear();(int j = 0; j < varCol.GetCount(); j++)

{

// Считывание переменных с записью в таблицу= (ksVariable)varCol.GetByIndex(j);.TableCompassEV.Rows.Add(var.name, var.value, var.note);

}

}

}

}

}

}

// Запись значения внешних переменных в КОМПАС-3Dvoid Compass_EV_Write_Click(object sender, EventArgs e)

{(kompas != null)

{(doc3D != null)

{(doc3D.IsDetail())

{.ksError("Текущий документ должен быть сборкой");;

}

// Выбор компонента -1 главный(сама сборка),0 первый(первая деталь)part = (ksPart)doc3D.GetPart(-1);(part != null)

{

// Работа с массивом внешних переменныхvarCol =

(ksVariableCollection)part.VariableCollection();(varCol != null)

{

// Запись внешних переменных в компасvar = (ksVariable)kompas.GetParamStruct

((short)StructType2DEnum.ko_VariableParam);(var == null) return;d;g;(int i = 0; i < varCol.GetCount(); i++)

{= (ksVariable)varCol.GetByIndex(i);= (string)(this.TableCompassEV.Rows[i].Cells[1].Value.ToString());= Convert.ToDouble(d);.value = g;

}

//Перестроение сборки, почемуто не работает.RebuildModel();

}

}

}

}

}

VarMathCAD_API

//Подключение библиотек для работы с MathCAD

using Mathcad;

//Создание объектов для работы с MathCAD

private string LastMathCadPath = "";Mathcad.Application MC; //Объектов MathCAD

private Mathcad.Worksheets WK; //Объект для списка рабочих листов MathCADMathcad.Worksheet WS; //Объект для рабочего листа MathCAD

// Активируем MathCADvoid InitMathCad()

{(MC == null)

{

{= new Mathcad.Application();

}

{.Show("MathCAD не установлен.", "Ошибка",.OK, MessageBoxIcon.Error);

}

}

}

// Открываем файл MathCADvoid OpenFileMathCad(string filename)

{(MC != null)

{= MC.Worksheets;(int i = 0; i < WK.Count; i++)

{= WK.Item(i);(WS.FullName == filename).Close(MCSaveOption.mcSaveChanges);

}(WK != null) WS = WK.Open(filename);.Visible = true;

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Считываем значение входных и выходных переменных MathCADvoid MathCadRead()

{(MC != null)(WS != null)

{(int j = 0; j < 50; j++)

{

{name;= "in" + j; // Считываем значение входных переменных MathCADvalue;

{= (WS.GetValue(name) as NumericValue).Real.ToString();.TableMathCad_IN.Rows.Add(name, value);

}(Exception)

{;

}

}

}(int j = 0; j < 50; j++)

{name;= "out" + j;//Считываем значение выходных переменныхMathCADvalue;

{= (WS.GetValue(name) as NumericValue).Real.ToString();.TableMathCad_OUT.Rows.Add(name, value);

}(Exception)

{;

}

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Записываем значение входных переменных и считываем новые значения выходных // переменных MathCADvoid MathCadWrite()

{(MC != null)(WS != null)

{(int j = 0; j < this.TableMathCad_IN.Rows.Count; j++)

{

{name;= this.TableMathCad_IN.Rows[j].Cells[0].Value.ToString();value;= this.TableMathCad_IN.Rows[j].Cells[1].Value.ToString();var;= ConverToDouble(value);

// Записываем значение входных переменных MathCAD.SetValue(name, var);

}(Exception)

{;

}

}.Recalculate();.Save();(int i = 0; i < this.TableMathCad_OUT.Rows.Count; i++)

{

{name1;= this.TableMathCad_OUT.Rows[i].Cells[0].Value.ToString();value1;

// Cчитываем новые значения выходных переменных MathCAD= (WS.GetValue(name1) as NumericValue).Real.ToString();.TableMathCad_OUT.Rows[i].Cells[1].Value = value1;

}(Exception)

{;

}

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

VarMathCAD_XML

// Считываем или записываем значения переменных в файл MathCADvoid MathCadParser(string MathPath, bool save)

{

// Обновляем таблицу Маткадаi = 0;region_id;xd = new XmlDocument();{.Load(MathPath); // Открываем файл MathCAD

}

{;

}xnl = xd.DocumentElement.ChildNodes;ml_id, ml_real;(save == false) this.TableMathCad.Rows.Clear();(XmlNode xn in xnl)(xn.Name == "regions")(XmlNode region in xn.ChildNodes)

{_id = region.Attributes[0].Value;(XmlNode math in region.ChildNodes)(XmlNode ml_define in math.ChildNodes)

{(ml_define.Name == "ml:define") // Присвоенные переменные MathCAD

{_id = ml_define.FirstChild;_real = ml_define.LastChild;(ml_real.Name == "ml:real")

{(save == true)_real.InnerText =.TableMathCad.Rows[i].Cells[1].Value.ToString();.TableMathCad.Rows.Add (ml_id.InnerText,_real.InnerText, "Присвоенная", region_id, "define");++;

}

}(ml_define.Name == "ml:eval") // Вычисленные переменные MathCAD

{_id = ml_define.FirstChild;(XmlNode result in ml_define.ChildNodes)(result.Name == "result")

{_real = result.FirstChild;(save == true)ml_real.InnerText = this.TableMathCad.Rows[i].Cells[1].Value.ToString();.TableMathCad.Rows.Add(ml_id.InnerText,_real.InnerText, "Вычисленная", region_id, "eval");

}++;

}

}

}

{(save) xd.Save(MathPath);

}

{.Show("Не могу сохранить! Возможно файл открыт только для чтения!", "Ошибка",MessageBoxButtons.OK, MessageBoxIcon.Error);

}

IntegratorKM_Lite

// Заполняем комбобокс у таблицы MathCAD и выбираем нулевой элементvoid AddMathCadCombo()

{

//заполняем комбобокс у таблицы MathCAD.KompasName_ComboBox.Items.Clear();.KompasName_ComboBox.Items.Add("empty"); (int j = 0; j < TableKompas3D.Rows.Count; j++)

{ .KompasName_ComboBox.Items.Add

}

// Выбираем нулевой элемент для каждой ячейки в комбо-бокс-столбце в таблице внешних переменных Маткада(int i = 0; i < TableMathCad.Rows.Count; i++)

{.KompasName_ComboBox.DataGridView.Rows[i].Cells[5].Value =.KompasName_ComboBox.Items[0];

}

}

// Заполняем комбобокс у таблицы КОМПАС-3D и выбираем нулевой элементvoid AddKompasCombo()

{

//заполняем комбобокс у таблицы КОМПАС-3D.MathCadName_ComboBox.Items.Clear();.MathCadName_ComboBox.Items.Add("empty");(int j = 0; j < TableMathCad.Rows.Count; j++)

{ .MathCadName_ComboBox.Items.Add

(this.TableMathCad.Rows[j].Cells[0].Value.ToString());

}

// Выбираем нулевой элемент для каждой ячейки в комбо-бокс-столбце в таблице внешних переменных КОМПАС-3D(int i = 0; i < TableKompas3D.Rows.Count; i++)

{.MathCadName_ComboBox.DataGridView.Rows[i].Cells[3].Value =.MathCadName_ComboBox.Items[0];

}

}

// Присваиваем переменной КОМПАС-3D значение переменной MathCAD

// выбранной в комбо-бокс-столбцеEndEdit_TableKompas3D(object sender, DataGridViewCellEventArgs e)

{

{(e.ColumnIndex == 3).TableKompas3D.Rows[e.RowIndex].Cells[1].Value =.TableMathCad.Rows[MathCadName_ComboBox.Items.IndexOf

(this.TableKompas3D.Rows[e.RowIndex].Cells[3].Value)

1].Cells[1].Value;

}

{.Show("Error");;

}

{.TableKompas3D.Update();

}

}

// Присваиваем переменной MathCad значение переменной КОМПАС-3D

// выбранной в комбо-бокс-столбцеTableMathCadCellEndEdit(object sender, DataGridViewCellEventArgs e)

{

{(e.ColumnIndex == 5).TableMathCad.Rows[e.RowIndex].Cells[1].Value =.TableKompas3D.Rows[KompasName_ComboBox.Items.IndexOf

(this.TableMathCad.Rows[e.RowIndex].Cells[5].Value)

1].Cells[1].Value;

}

{.Show("Error");;

}

{.TableMathCad.Update();

}

}