Содержание к диссертации
Введение
1 Анализ существующих решений в области мониторинга и настройки параметров мехатронных устройств 10
1.1 Задачи мониторинга и настройки параметров в системах числового программного управления мехатронным оборудованием 11
1.1.1 Объект и субъект мониторинга и настройки параметров системы управления мехатронным оборудованием 14
1.1.2 Задачи мониторинга и настройки параметров в системе ЧПУ механообрабатывающим оборудованием 16
1.1.3 Задачи мониторинга и настройки параметров в системах на основе ГОЖ 19
1.2 Анализ систем мониторинга и настройки параметров мехатронного оборудования разных производителей 21
1.2.1 Настройка параметров в системах управление Sinumeric фирмы Siemens 21
1.2.2 Система визуализации Siemens SIMATIC WinCC 24
1.2.3 Мониторинг и настройка параметров в системе 3S CoDeSyS 26
1.3 Обзор и выбор технологий разработки 28
1.4 Анализ патентной чистоты проводимых научных разработок 37
1.5 Постановка задач исследования 40
2 Классификация способов представления данных и выявление существующих взаимосвязей в системах мониторинга и настройки параметров 42
2.1 Способы представления информации в системах управления мехатронным оборудованием 42
2.1.1 Отображение текущего значения параметра 42
2.1.2 Отображение значения параметра во времени 43
2.1.3 Мониторинг значения параметра 44
2.1.4 Обобщенный метод представления информации в системах управления мехатронным оборудованием 45
2.2 Выявление набора общих компонентов в системах мониторинга и настройки параметров различных мехатронных систем 47
2.3 Классификация пользовательских приложений мониторинга и настройки параметров 49
2.3.1 Текстовое представление значения параметров 50
2.3.2 Табличное представление параметров 51
2.3.3 Графическое развертка значений параметров во времени 52
2.3.4 Графическая визуализация параметров 53
2.4 Выводы по второй главе 55
3 Разработка обобщенной архитектурной модели и метода построения инструментария мониторинга и настройки параметров разнородных мехатронных систем 57
3.1 Обобщенная архитектурная модель инструментария мониторинга и настройки параметров 57
3.1.1 Агент мониторинга и настройки параметров 58
3.1.2 Терминальный клиент мониторинга и настройки 61
3.1.3 Организация сетевого взаимодействия между агентом мониторинга и настройки и прикладным приложением 62
3.2 Метод построения инструментария мониторинга и настройки параметров 64
3.2.1 Метод и его составляющие 64
3.3 Выводы по третьей главе 69
4 Создание на базе разработанного метода инструментария мониторинга и настройки параметров для системы управления роботом и системы ЧПУ 71
4.1 Разработка инструментария мониторинга и настройки для системы управления промышленным роботом 71
4.1.1 Визуализация параметров в системе управления мехатронным оборудованием 71
4.1.2 Разработка схемы языка описания интерфейса визуализации параметров системы управления промышленным роботом 76
4.1.3 Создание инструментария мониторинга и настройки для системы управления промышленным роботом ТУР 95
4.2 Разработка системы мониторинга и настройки для цифрового привода системы ЧПУ 98
4.2.1 Модель представления данных цифрового осциллографа 99
4.2.2 Реализация механизма хранения данных 106
4.2.3 Построение вычислительной подсистемы 114
4.3 Выводы по четвертой главе 126
Основные выводы и результаты работы 127
Список литературы 128
- Обзор и выбор технологий разработки
- Выявление набора общих компонентов в системах мониторинга и настройки параметров различных мехатронных систем
- Агент мониторинга и настройки параметров
- Разработка схемы языка описания интерфейса визуализации параметров системы управления промышленным роботом
Введение к работе
Актуальность темы. Современный этап развития машиностроительных производств характеризуется широким применением решений комплексной автоматизации. Подобные решения зачастую строятся на базе использования мехатронного оборудования различных производителей, которое, с одной стороны, хорошо подходит для решения поставленных задач, но, с другой стороны, ставит порождает проблему интеграции данных разнородных систем в рамках единого информационного окружения предприятия.
Построение системы мониторинга и настройки параметров мехатронного оборудования для представления множества числовых параметров мехатронной системы в удобной для оператора форме - важный аспект в задаче обеспечения качественного выполнения технологического процесса и снижения времени наладки и ввода оборудования в эксплуатацию.
Анализ подсистем мониторинга и настройки параметров в системах управления мехатронным оборудованием ведущих мировых разработчиков (Siemens, Bosch Rexroth, KUKA, 3S и др.) выявил следующие проблемы их функциональных возможностях, решаемых задачах и в степени открытости решений:
отсутствует единый подход к систематизации прикладных компонентов систем мониторинга и настройки параметров, что усложняет анализ, проектирование и разработку программных компонентов для расширения её возможностей;
отсутствует единый подход к интеграции функциональных компонентов различных производителей в состав системы мониторинга и настройки параметров;
современные системы мониторинга и настройки не предоставляют возможности гибкого конфигурирования набора программных
компонентов для создания проблемно-ориентированных решений и настройки под задачи конкретного пользователя.
В результате исследования было определено, что наиболее перспективным является способ построения системы мониторинга и настройки параметров в виде открытой модульной системы на основе интеграции специализированных программных компонентов как собственной разработки, так и сторонних производителей.
Таким образом, тема диссертации, направленная на расширение возможностей мониторинга и настройки систем числового программного управления мехатронными устройствами, является актуальной.
Цель работы: повышение эффективности процесса разработки систем ЧПУ посредством создания единого инструментария мониторинга и настройки параметров разнородного мехатронного оборудования.
Задачи исследования. Для достижения цели в работе были поставлены следующие задачи:
проанализировать существующие решения в области мониторинга и настройки параметров мехатронных устройств;
классифицировать способы представления данных и выявить существующие взаимосвязи в системах мониторинга и настройки параметров;
разработать обобщенную архитектурную модель и метод построения инструментария мониторинга и настройки параметров разнородных мехатронных систем;
создать на базе разработанного метода инструментарий мониторинга и настройки параметров для системы управления роботом и числового программного управления станком.
Методы исследования. Теоретические исследования в работе
базировались на методах системного анализа, объектно-ориентированного
проектирования (декомпозиции, абстракции, иерархии), концепции
объектно-ориентированного программирования. Использовались
теоретические основы технологий .NET, DCOM (distributed component object model), автоматизация OLE (object linking and embedding), стандарт OPC (OLE for process control), язык описания разметки XML (extensible Markup Language).
Научная новизна. В диссертационной работе получены следующие научные результаты:
выявлены взаимосвязи между параметрами процессов мониторинга и настройки, позволившие выдвинуть единый подход к решению задач мониторинга и настройки разнородных мехатронных систем;
разработана архитектурная модель инструментария для мониторинга и настройки параметров разнородных мехатронных систем на основе выделения общих программных компонентов и спецификации интерфейсов взаимодействия между ними;
предложен метод построения инструментария для мониторинга и настройки параметров, позволяющий формализовать процесс разработки программного обеспечения, выявить набор необходимых компонентов и организовать их взаимодействие в единой программной среде системы управления;
разработан язык описания отображения для графической визуализации параметров, позволяющий представлять параметры функционирования мехатронной системы в понятном оператору графическом виде.
Практическая значимость работы заключается в:
разработанной методике создания инструментария мониторинга и настройки параметров на основе обобщенной архитектурной модели и принципов интеграции компонентов сторонних производителей, позволяющей синтезировать проблемно-ориентированные прикладные приложения;
разработанных программных модулях графической визуализации параметров и подсистеме вычислений с открытой модульной
архитектурой, повышающих эффективность процесса разработки и сокращающих время выпуска программного продукта на рынок.
Апробация работы. Теоретические и практические результаты, полученные автором, докладывались на заседаниях кафедры «Компьютерные системы управления» ФГБОУ ВПО МГТУ «СТАНКИН», семинарах Научно-образовательного центра в области компьютерного моделирования и управления технологическими системами, созданного ФГБОУ ВПО МГТУ «СТАНКИН» совместно с Институтом проблем управления РАН, а также на международных научно-технических конференциях «Информационные средства и технологии» (2008 и 2010 гг.), международной конференции «Системы проектирования, технологической подготовки производства и управления этапами жизненного цикла промышленного продукта (CAD/CAM/PDM - 2009 и 2010 гг.) и международной научно-технической конференции «Автоматизация: проблемы, идеи, решения» (2010 г.).
Разработанный инструментарий мониторинга и настройки для системы управления промышленным роботом серии «ТУР» и системы ЧПУ «АхЮМА Ctrl» используется в учебном процессе по дисциплинам «Мехатронные системы» и «Распределенный мониторинг в корпоративных системах» на кафедре «Компьютерные системы управления» ФГБОУ ВПО МГТУ «СТАНКИН».
Практические разработки по данной теме отмечены дипломами 10-й и 11-й международных специализированных выставок Передовые Технологии Автоматизации «ПТА-2010» и «ПТА-2011», золотой медалью XIV Московского Международного Салона Изобретений и Инновационных технологий «АРХИМЕД-2011».
Реализация результатов работы. Результаты работы использованы при
создании систем управления мехатронными объектами по темам:
«Разработка и освоение производства гаммы отечественных универсальных
технологических роботов для массовых автоматизированных производств
гражданской машиностроительной продукции» (госконтракт
7410.0810000.05.B08 от 11.12.2007) и «Создание многофункционального интеллектуального контроллера движения с открытой архитектурой для управления технологическим оборудованием» (г/б НИР 10-52/р, госконтракт № П926 от 20.08.2009 г.).
На основе результатов работы созданы 5 объектов интеллектуальной собственности в виде свидетельств о государственной регистрации программ для ЭВМ.
Публикации. По теме диссертации опубликовано 9 научных статей (из них 3 в журналах, рекомендованных ВАК), включая тезисы докладов, опубликованных в рамках международных и региональных научно-технических конференций.
Структура и объем диссертации. Диссертационная работа состоит из введения, четырех глав, общих выводов, списка литературы из 70 наименований. Основная часть работы изложена на 135 страницах машинописного текста, содержит 56 рисунков, 15 таблиц.
Обзор и выбор технологий разработки
COM (Component Object Model) — это спецификация, указывающая, как создавать динамически взаимозаменяемые компоненты. СОМ определяет стандарт, которому должны следовать компоненты и клиенты, чтобы гарантировать возможность совместной работы. Компоненты СОМ состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или ЕХЕ-файлов Win32. Но сама по себе динамическая компоновка не обеспечивает компонентной архитектуры. Компоненты СОМ объявляют о своем присутствии стандартным способом. Используя схему объявлений СОМ, клиенты могут динамически находить нужные компоненты.
Интерфейс СОМ состоит из набора функций, которые реализуются компонентами и используются клиентами. Интерфейсом в СОМ является определенная структура в памяти, содержащая массив указателей на функции [20].
Один из наиболее многообещающих аспектов компонентной архитектуры - это быстрая разработка и развитие приложений. Из накапливаемого набора компонентов в библиотеках можно будет выбирать, как из деталей конструктора, требуемые цельные приложения (Рис. 7).
Компонент подобен мини-приложению, он поставляется пользователю как двоичный код, скомпилированный, скомпонованный и готовый к использованию. Модификация или расширение приложения сводится к замене одного из составляющих его компонентов новой версией.
Основное преимущество применения компонентов — их способность подключаться к приложению и отключаться от него. Для этого компоненты должны удовлетворять двум требованиям. Во-первых, они должны компоноваться динамически, а во-вторых, - должны скрывать или инкапсулировать детали своей реализации. Программа или компонент, использующий другой компонент, называется клиентом (client). Клиент подключается к компоненту через интерфейс. Если компонент изменяется без изменения интерфейса, то изменений в клиенте не требуется. Аналогично, если клиент изменяется без изменения интерфейса, то нет необходимости изменять компонент. Чем надежнее интерфейс изолирован от реализации, тем менее вероятно, что он изменится при модификации клиента или компонента.
OLE
В настоящее время OLE — это общее имя для всей группы технологий, в основе которых лежит СОМ.
Приложения с каждым днем становятся все сложнее. В текстовые процессоры добавляются графические возможности, в электронные таблицы средства построения диаграмм, и кажется, все кончится одним большим приложением для решения всех задач. Но в действительности цель как раз не в этом, а в интеграции разных приложений. Например, добавлять поддержку графики в текстовый процессор не потребуется, если внутри него можно будет использовать некоторое уже существующее графическое приложение. Задача — обеспечить гладкую совместную работу приложений. Пользователю должно представляться нечто такое, что выглядит как один документ, хотя на самом деле над разными частями такого документа совместно работают разные приложения.
Для решения этой проблемы предназначена технология OLE (ранее называвшаяся Документы OLE — OLE Documents). Поддерживая нужные СОМ-объекты, каждый с собственным набором интерфейсов, независимые приложения могут совместно работать, чтобы пользователь получил один составной документ. Все эти интерфейсы носят абсолютно общий характер — ни одно приложение не знает, что представляют собой другие. Зачем встраивать в текстовый процессор функции электронной таблицы? OLE поможет просто задействовать в случае необходимости существующее приложение электронной таблицы.
Определенный OLE стандартный интерфейс обеспечивает взаимодействие между приложениями любых типов и любых производителей, а не только между электронными таблицами и текстовыми процессорами Microsoft.
При создании составного документа с помощью OLE одно из приложений всегда является контейнером. Как следует из названия, контейнер определяет самый общий документ, в котором содержится все остальное. Другие приложения — серверы — могут размещать свои документы внутри документа-контейнера.
OLE позволяет увеличить степень интеграции между программными модулями и служит для создания множества взаимозаменяемых компонентов программного обеспечения. Набор услуг, которые предлагает OLE, не постоянен. Microsoft постоянно модернизирует и расширяет операционную систему Windows, и точно также она готова развивать OLE, чтобы адаптировать к широкому диапазону требованию по интеграции приложений.
.NET как средство построения многокомпонентных приложений
В эту новую платформу, или даже скорее концепцию, вкладываются сейчас огромные средства и профессиональный уникальный опыт. Это, возможно, будущее многих технологий. Если говорить вкратце, то .NET — это универсальная платформа, которая объединяет в себе серверные и клиентские продукты, призванные облегчить жизнь, как пользователям, так и разработчикам программного обеспечения.
.NET представляет собой совершенно новый способ создания распределенных, настольных и встроенных приложений. Очень важно сразу осознать, что .NET не имеет ничего общего с СОМ (кроме мощных средств интеграции двух платформ). Для типов .NET не нужны ни фабрики классов, ни поддержка IUnknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты — их просто больше нет.
Специально для новой платформы Microsoft разработала новый язык программирования — С#. Этот язык, как и Java, очень многое позаимствовал из C++ (особенно с точки зрения синтаксиса). Однако на С# сильно повлиял и Visual Basic 6.0. В целом можно сказать, что С# впитал в себя многое из того лучшего, что есть в самых разных языках программирования.
Очень важно отметить, что платформа .NET является полностью независимой от используемых языков программирования. Существует возможность использовать несколько .NET-совместимых языков программирования (скорее всего, вскоре их будет множество) даже в рамках одного проекта.
Преимущества С#
С# - это полнофункциональный объектно-ориентированный язык, который поддерживает все три "столпа" объектно-ориентированного программирования: инкапсуляция, полиморфизм и наследование. Все эти три столпа основываются в ООП на понятие класса. Класс - это пользовательский тип данных, который состоит из данных (часто называемых атрибутами или свойствами) и функций для выполнения над этими данными различных действий (эти функции обычно называют методами). Классы позволяют группировать в единое целое данные и функциональность, моделируя объекты реального мира. Именно это свойство классов и обеспечивает одно из наиболее важных преимуществ объектно-ориентированных языков программирования.
Как упоминалось выше, С# - это фактически гибрид разных языков. При этом С# синтаксически не менее (если не более) чист, чем Java, так же прост, как Visual Basic, и обладает практически той же мощью и гибкостью, что и C++. Можно выделить некоторые из преимуществ:
Управление памятью производится автоматически.
В С# предусмотрены встроенные синтаксические конструкции для работы с перечислениями, структурами и свойствами классов.
В С# осталась возможность перегружать операторы, унаследованные от C++. При этом значительная часть возникавших при этом сложностей ликвидирована.
Предусмотрена полная поддержка использования программных интерфейсов. Однако в отличие от классического СОМ применение интерфейсов - это не единственный способ работы с типами, используя различные двоичные модули. .NET позволяет передавать объекты (как ссылки или как значения) через границы программных модулей.
Также предусмотрена полная поддержка объектно-ориентированных программных технологий (таких как атрибуты). Это позволяет присваивать типам характеристики (что во многом напоминает COM JDL) для описания в будущем поведения данной сущности.
Выявление набора общих компонентов в системах мониторинга и настройки параметров различных мехатронных систем
Анализа способов представления информации о параметрах в системах управления мехатронным оборудованием позволяет обобщенную схему получения и представления данных. В системе мониторинга и настройки можно условно выделить 2 основные части:
агент мониторинга и настройки
терминальная часть мониторинга и настройки
Основной функцией агента мониторинга и настройки является взаимодействие с источниками данных внутри ядра системы управления мехатронным оборудованием. Это взаимодействие заключается в подключении к базе данных представления параметров внутри ядра системы управления для считывания и записи значений параметров и самой структуры их хранения. Далее после первичной обработки эти параметры должны быть переданы в терминальную часть мониторинга и настройки через доступный канал связи.
Терминальная часть системы мониторинга и настройки связывается через доступный канал связи с одним или несколькими агентами мониторинга и настройки и предоставляет клиентскому приложению сервисы по считыванию структуры параметров системы управления мехатронным оборудованием, чтению и записи значений этих параметров.
На основе анализа задач, решаемых системой мониторинга и настройки параметров, можно выделить четыре уровня бизнес-логики:
- уровень доступа к данным - отвечает за взаимодействие с разнородными мехатронными устройствами и маскирует специфику работы с ними;
- уровень передачи данных - отвечает за передачу данных и команд;
- уровень представления и хранения данных - отвечает за хранение данных мониторинга и настройки в терминальной части системы и предоставляет интерфейсы для доступа к данным;
- уровень визуализации - отвечает за формирование компонентов отображения и редактирования данных.
На основе выделения основных задач, решаемых в рамках системы мониторинга и настройки параметров, построена матрица формирования характеристик и функциональности компонентов (рис. 16), которая позволяет:
на этапе разработки программного обеспечения формировать функциональные требования к компонентам на каждом уровне бизнес-логики системы мониторинга и настройки;
определять набор компонентов визуализации данных для решения поставленной задачи мониторинга и настройки;
определять набор протоколов, которые необходимо реализовать;
анализировать набор имеющихся компонентов сторонних производителей и вырабатывать стратегию их интеграции.
Анализ матрицы формирования характеристик и функциональностей компонентов показывает, что решение различных задач мониторинга и настройки требует реализации сходных функциональностей на разных уровнях бизнес-логики, что определяет базис для построения унифицированной системы мониторинга и настройки для разнородных систем управления мехатронным оборудованием.
Анализ инструментов мониторинга и настройки параметров в составе систем управления мехатронным оборудованием разных типов позволяет выделить набор общих компонентов, которые используются при построении систем мониторинга и настройки для различных типов оборудования. Таковыми компонентами являются:
Компонент доступа к источнику данных внутри системы управления
Компонент первичной обработки данных и управления процессом сбора данных внутри системы управления
Компонент передачи данных по каналу связи внутри системы управления (серверная часть)
Компонент передачи данных по каналу связи внутри терминального клиента мониторинга и настройки (клиентская часть)
Сервер данных мониторинга и настройки клиентского приложения
Различные компоненты визуального отображения и ввода данных
Агент мониторинга и настройки параметров
Агент мониторинга и настройки предлагается архитектурно выполнить в виде конвейера обработки данных, состоящего из 3 компонентов с едиными специфицированными интерфейсами. Компонентное дробление внутри агента мониторинга и настройки обусловлено спецификой функций, которые выполняются каждым из 3 видов компонентов:
1. Компонент сбора данных. Компоненты данного вида инкапсулируют в себе конкретику взаимодействия с источниками данных внутри ядра системы управления. Компонент сбора данных создается специфичным под каждый тип системы управления. Он «знает» о том, где внутри, ядра системы управления находятся нужные данные, реализует специфичный для данного ядра способ чтения/записи данных, умеет считывать структуру данных внутри системы.
2. Компонент первичной обработки данных. Этот тип компонентов служит для первичной обработки данных, получаемых от компонента сбора данных. Первичная обработка ограничена некоторым набором несложных алгоритмов, позволяющих в некоторых случаях избежать передачи избыточных данных по каналу связи. Первичная обработка реализует набор алгоритмов, позволяющих снизить трафик по каналу связи посредством:
отслеживания изменения значений параметров и выдачи события об изменении;
реализации алгоритмов синхронных и асинхронных подписок на значения параметров;
организации накопления данных для пакетной передачи при визуализации сигналов во времени (поскольку возможности передачи потоков данных с высокой дискретностью в реальном времени через канал связи ограничены).
3. Компонент связи осуществляет передачу данных между агентом мониторинга и настройки внутри ядра системы управления и терминальной частью системы. Компонент связи инкапсулирует в себе специфику передачи данных по конкретному типу канала связи.
Предусмотрена возможность создания нескольких цепочек компонентов обработки данных соответственно потребностям отслеживаемых параметров. Список компонентов в цепочках задается при помощи конфигурационного файла в формате XML, на основании которого на этапе старта системы менеджер компонентов выбирает нужные модули из библиотеки программных компонентов и выстраивает их взаимодействие в заданном порядке.
Подобное компонентное деление внутри агента мониторинга и настройки позволяет получить ряд преимуществ:
1. Инкапсуляция конкретных методов работы с источниками данных в ядре и способов передачи данных по каналу связи позволяет специфицировать единые интерфейсы взаимодействия модулей.
2. За счет стандартизации интерфейсов взаимодействия между модулями достигается взаимозаменяемость модулей одного типа и возможность гибкой конфигурации агента сбора данных в зависимости от текущих задач мониторинга и настройки. Например, один и тот же агент сбора данных может использоваться как для создания системы отслеживания значения группы параметров, так и для создания цифрового осциллографа в рамках одной системы управления. Один и тот же компонент первичной обработки данных может быть использован для реализации одной и той же логики работы с данными внутри агентов сбора данных в различных системах управления мехатронным оборудованием. В данном случае потребуется только замена модуля сбора данных для отражения специфики структуры данного ядра системы управления. Заменой компонента связи можно обеспечить поддержку разных типов каналов передачи данных для агента сбора данных.
3. Специфицированный интерфейс компонента связи позволяет клиентскому приложению мониторинга и настройки работать с различными системами управления мехатронным оборудованием.
Центральным компонентом в структуре агента сбора данных является компонент управления сбором данных и первичной обработки. В случае необходимости он может одновременно взаимодействовать с несколькими компонентами сбора данных внутри системы управления и несколькими компонентами связи для обслуживания приложений мониторинга подключенных через различные каналы передачи данных.
Разработка схемы языка описания интерфейса визуализации параметров системы управления промышленным роботом
В схеме описания языка определено несколько групп параметров, свойственных нескольким типам графических элементов. Далее для визуальных элементов, имеющих в составе своего описания одну или несколько из этих групп параметров, это будет указано без детального описания самой группы. Параметры из групп LocationAttributes и Size Attributes могут быть заданы, как вычисляемые выражения.
Группа LineAttributes
Группа атрибутов, задающих свойства отображения линий. Являются обязательными для элементов, содержащих эту группу атрибутов.
Группа FontAttributes
Параметры отображения шрифта для примитива Text. Не являются обязательными.
Группа LocationAttributes
Атрибуты расположения графического элемента. Обязательны для описания в каждом содержащем их блоке.
Группа SizeAttributes
Размер визуального элемента. Обязательны для описания в каждом содержащем их блоке.
При описании примитива «Текст» в атрибуте Text задается строка формата, которая может содержать псевдонимы параметров, обрамленные справа и слева знаками "$". Например: «Ток двигателя 1: $Drivel_I$; максимально допустимый ток: $Drivel_I_max$», где "Drivel_F и "Drivel_I_max" псевдонимы для первого и второго параметров. На этапе визуализации текста вместо $Drivel_I$ и $Drivel_I_max$ будут подставлены значения соответствующих параметров. Пример описания:
Text Text=" Ток двигателя 1: $Drivel_I$; максимально допустимый ток: $Drivel_I_max$" Х="5" Y="10" Width="50" Hight="24" fonl-size="24" font-sty italic nont-weight= "bold 7
Примитив «Динамическая картинка» предназначен для отображения одного из изображений в зависимости от условия. Кроме атрибутов положения, размера и фона для описания данного примитива необходимо указать список условий и путь к изображению, которое будет отображаться при выполнении каждого из них.
В качестве условия допускается любое валидное в языке C++ выражение, дающее бинарный результат (булево выражение). Подробнее о выражениях в соответствующей главе концепции. Пример описания динамической картинки:
DynamicPicture Х="5" Y="10" Width="50" Hight="100" Switch Statement II <= I_max " FilcName="l.bmp"/ Switch Statement II > I_max " FileName="2.bmp"/ /DynamicPicture
В данном примере в случае, если значение параметра с псевдонимом II будет меньше или равно значению параметра с псевдонимом I_max, будет отображено изображение из файла l.bmp. Если II Imax, то картинка из файла 2.bmp.
Примитивы могут компоноваться в структуры, называемые блоками. Координаты примитивов и размеры в этом случае задаются от верхнего левого угла содержащего их блока. Блоки призваны облегчить создание новых конфигураций экрана. Структура блока показана на Рис. 35.
Описание каждого блока содержит параметры, относящиеся к его положению и размерам относительно родительского элемента.
В начале каждого блока внутри узла RTM_Parameters должны быть описаны параметры, значения которых будут запрашиваться из агента мониторинга и настройки в ядре системы управления роботом и использоваться для задания свойств графических элементов внутри этого блока.
Узел RTTVMParameters может содержать один или несколько узлов Parameter, описывающих непосредственно запрашиваемый параметр. Описание состоит из двух текстовых атрибутов: Name - имя параметра в списке параметров, Alias - короткий псевдоним, используемый для представления этого параметра в выражениях внутри блока.
Внутри узла Variables блок может содержать набор пользовательских переменных. Более подробно их описание будет рассмотрено ниже.
Блок может содержать набор графических элементов (узел Items), в который помещаются примитивы «Линия», «Окружность», «Прямоугольник», «Текст», «Картинка» и «Динамическая картинка». Описывать примитивы внутри узла Items можно в любой последовательности. Примитивы, описанные позже, будут отображены над примитивами, описанными ранее. Это следует учитывать в случае перекрытия разных примитивов на экране. Также блок может содержать внутри себя дочерние блоки.
Главное окно визуализации представляет собой блок верхнего уровня и описывается тем же набором параметров, что и любой другой блок. Подобная нисходящая схема получается очень гибкой при составлении конфигураций окна визуализации. В окне могут быть расположены несколько ранее сконфигурированных блоков, связанные и дополненные статическими и динамическими элементами.
Атрибуты X и Y при описании главного окна визуализации в рассмотрение не принимаются. Ширина и высота будут использоваться для масштабирования элементов на экране. Меньше этих значений блок не может быть уменьшен.
Атрибут Name представляет собой локализованное имя конфигурации экрана визуализации для отображения его пользователю.
