Сосонкин В.Л. 2005 Системы числового программного управления (841803), страница 25
Текст из файла (страница 25)
Объектно-ориентированный подход при организацииматематического обеспечения виртуальных контроллеровВ основе технологии создания программного обеспечения электроавтоматики лежат обычные для объектно-ориентированного программирования понятия класса и объекта. При этом класс описывает тип оборудования, а объект - конкретный экземпляр. Таким образом, при объявлениикласса, согласно принципу инкапсуляции, создаются шаблоны структурданных и методы, которые будут работать с этими данными.
В объектекласса по шаблону выстраиваются конкретные данные и приводится ссылкана обслуживающий их процесс.Глава 3. Задачи управления-| 4 3При появлении нового типа оборудования, благодаря механизму наследования, разработчик не нуждается в том, чтобы заново разрабатывать новый класс - достаточно выбрать наиболее близкий и реализовать отличияв новом классе. Тем самым обеспечивается простота модификаций, сокращаются затраты времени на разработку, снижается общая стоимость разработки.Наиболее важен тот факт, что объектный подход позволяет создаватьхорошо структурированные сложные системы управления электроавтоматикой. Основные преимущества, приобретаемые при этом, состоят в следующем:• повышается уровень унификации разработки; для повторного использования пригодны не только управляющие программы, но и проектыв целом, что служит хорошей основой для построения среды разработки.Снижаются затраты времени и средств на создание нового проекта;• возникает возможность повторного использования собственныхфункциональных модулей и готовых модулей других разработчиков, чтоделает систему управления открытой.
Уменьшается вероятность ошибокпри разработке сложных систем, увеличивается уверенность в правильности принимаемых решений.Все эти достоинства обеспечиваются благодаря лежащим в основеобъектно-ориентированной технологии принципам наследования, инкапсуляции и полиморфизма.3.3.2. Архитектура виртуального контроллераВ системе ЧПУ виртуальный контроллер работает в среде операционной системы Windows NT с расширением реального времени RTX фирмыVentureCom [4]. Проектирование контроллера предполагает последовательное рассмотрение его модели на трех уровнях абстракции: уровне моделипотоков (структуры потоков), уровне функциональных модулей и уровнепрограммной реализации (рис. 86).Сначала рассмотрим структуру потоков.
Основная задача контроллерасостоит в одновременном выполнении нескольких команд и параллельнойобработке внешних сигналов. Каждый процесс контроллера, который нуждается в выделении отдельного потока, выполняется в рамках основногопроцесса виртуального контроллера, запущенного под RTX. Процессорное время, выделяемое операционной системой основному процессу, должно быть распределено между потоками.Далее воспользуемся идеей псевдомногопоточности на основе механизма выделения квантов (разделения времени).
Процессорное время выделяется потокам отдельными квантами с помощью внутренних механизмов виртуального контроллера. В каждом кванте может выполняться толь-144В.Л. Сосонкин, Г.М. Мартинов. Системы числового программного управленияУровень модели потоковОпределяет зависимости ипорядок взаимодействия междупроцессами, протекающими вSoftPLCУровень функциональныхмодулейОписывает архитектуру SoftPLCна уровне отдельно функционирующих, но связанных во временимодулей.Уровень программнойреализацииПредставляет функциональныемодули в виде классов, а способыпередачи данных - в видеметодов.Рис. 86.
Последовательная трансформация моделивиртуального контроллера SoftPLCко один поток. Все потоки разделены на группы по приоритетам, причемуправление группой осуществляется отдельным программным таймером.Программный таймер аналогичен системному, реализованному в операционной системе, но не генерирует прерывания, и его обработчик запускается планировщиком (в нашем случае - модулем синхронизации). Выделение нескольких групп потоков в виртуальном контроллере связано с тем,что различные его задачи требуют разного времени реакции на внешнеевоздействие: чем меньше время реакции, тем выше приоритет потока, обслуживающего задачу.Более высокий приоритет потока означает более высокую частоту выделения квантов времени. Различные частоты поддерживаются в системенесколькими таймерами, каждый из которых активизируется на своей частоте и выделяет кванты времени своим потокам. Модуль синхронизацииосуществляет синхронную активизацию таймеров.На временной диаграмме потоков, представленной на рис.
87, рассмотрен случай, когда виртуальный контроллер работает с тремя группами псевдопотоков.Каждая группа получает кванты времени на выделенной частоте, чтосоответствует трем приоритетам. Таймер опорной частоты запускается намаксимальной частоте сканирования входных регистров. Частоты программных таймеров формируются путем деления опорной частоты в обработчике событий таймера опорной частоты.На временной диаграмме опорная частота равна 100 Гц, модуль синхронизации настроен на использование частот 100,50 и 20 Гц.
Для каждойГлава 3. Задачи управления145ОмеОпорнаячастотаЮме20 м :30 мсV,ч1(50 мс40 мсA1100 Гц . I V « - -1 Оме—»50 Гц \20 Гц1 Vi20 мсvЛ"1Анализатор IPD кодаС инхрониэатор' 1|Программный таймер 11|Программный таймер 3шин II /ШИНГI/Client!->OnProcessTimeSlice0щiY11Программный таймер 2i|Hii\NiiUiiiiiiiiSi••{••щиClie ntN->OnPro cessT imeS iice()Время, выполнения функции OnProcessTimeSliceOкаждого таймераВремя работы анализатора IPO кодаВремя работы системыВремя работы синхронизатораВремя работы SoftPIc- Вызов программных таймеровРис. 87. Временная диаграмма потоков виртуального контроллерачастоты назначен программный таймер.
Интервалы времени выделены дляанализатора IPD-кода (Interpolator Data, данные на входе интерполятора),синхронизатора, каждого таймера в отдельности. Таким образом, в интервалах времени, кратных 10 мс, будут работать все три таймера.С целью более равномерного распределения нагрузки в интервалах времени, задачи второго и третьего программных таймеров разделены, соответственно, на две и четыре подгруппы. Это позволяет запускать подгруппы поочередно в каждом интервале времени.Модель контроллера на уровне функциональных модулей показана нарис.88.Виртуальный контроллер имеет пять составных частей (модулей):В.П. Сосонкин, Г.М. Мартинов.
Системы числового программного управления146• анализатор, читающий IPD-данные из входного буфера и преобразующий эти данные во внутренний формат виртуального контроллера сучетом входных и выходных регистров электроавтоматики;• синхронизатор, поддерживающий механизм назначения квантов времени и генерирующий синхросигналы для всех процессов виртуальногоконтроллера;• исполняемые модули, служащие для отработки команд, поступающих в виртуальный контроллер, таких как опрос датчиков аварийного останова и конечных выключателей, включение/выключение подачи охлаждающей жидкости, зажим/разжим патрона, запуск/останов шпинделя, опрос датчиков температуры и т.д;• регистр, используемый для обмена информацией между системойЧПУ и виртуальным контроллером;• шлюз, предназначенный для отображения информации, передаваемой по CAN-магистрали в регистр.ISO-7 bitИнтерп ретаторIPD-кодIPD-коддля приводовИнтерполятор—isMIIPD-KOfl(H1004)Анализатор IPD-кодаМодульсинхронизацииИсполняемыемодулиРегистрШлюз Can-PicКонтроллер SoftPLCПриводьCANРис.
88. Архитектура виртуального контроллера на уровнефункциональных модулейГлава 3. Задачи управления-) 4 7Взаимодействие модулей осуществляется следующим образом. В результате интерпретации управляющей программы ЧПУ формируется промежуточный IPD-код [21], представляющий собой универсальный бинарный код, не зависящий от используемой платформы. IPD-код содержиттраекторную информацию об относительных перемещениях инструментаи детали, а также информацию о вспомогательных М-командах. Модульинтерполятора читает IPD-код, отделяя те данные, которые относятся ккомандам контроллера. Выделенная команда направляется соответствующему исполняемому модулю, внутри которого есть все необходимое длявыполнения контроллером команды.
Исполняемый модуль представлен ввиртуальном контроллере в виде отдельной задачи.Допускается параллельное выполнение нескольких М-команд. Механизм назначения квантов времени, генерирующий синхросигналы для всехпроцессов контроллера, обеспечивает синхронное выполнение команд.После отработки внутреннего алгоритма контроллер передает интерполятору информацию о своем состоянии.Обмен данными между контроллером и системой ЧПУ осуществляется через разделяемую память, называемую в нашем проекте «регистром».В регистре выделены три блока: специальных маркеров SM (SpecialMarker), входных данных виртуального контроллера; выходных данных контроллера.
Маркер SM используется для оповещения о нерегулярных ситуациях, возникающих в системе ЧПУ и контроллере. В каждом кванте времени блок SM анализируется на наличие в нем признаков сбоев (отказоваппаратуры и механизмов и др.) или признаков особо важных сигналов(при воздействии оператора на внешние органы управления). Например,аварийный останов принудительно прекращает работу всей системы. Информация о поступлении аварийного сигнала (при нажатии на кнопку аварийного останова) распространяется по всем объектам контроллера черезопределенную ячейку в блоке SM.Блоки входных и выходных данных предназначены для организациидвустороннего обмена с объектом управления: контроллер считывает информацию из блока входных данных и записывает ее в блок выходных данных.
Передача информации между регистром и CAN-магистралью осуществляется посредством шлюза. Модель виртуального контроллера на уровнепрограммной реализации рассмотрим в отдельном разделе.3.3.3. Программная реализация виртуального контроллераВиртуальный контроллер представляет собой некоторую систему с DLLинтерфейсом, работающую в отдельном RT-процессе реального времени (RealTime). Система имеет единственный экспортируемый класс CNcMParser, содержащий набор базовых функций управления и общедоступные экземпля-148В.Л. Сосонкин, Г.М. Мартинов.
Системы числового программного управленияры входных и выходных данных. Остальные механизмы системы защищеныот совместного доступа и не контролируются пользователем.Объекты представляют собой экземпляры классов, описывающих электроавтоматику системы ЧПУ. В рамках модульной архитектуры виртуального контроллера каждый отдельный класс отвечает за свой объект управления на станке (рис. 89). Так, класс CNcSpindle отвечает за управлениешпинделем, класс CNcClnt - за управление механизмом подачи смазочноохлаждающей жидкости и т.д.Благодаря модульной архитектуре виртуальный контроллер обладаетвысокой степенью гибкости, позволяющей использовать его на станках различных групп и типов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
