
- •1 Особенности проектирования современных систем чпу
- •1.1 Задачи числового программного управления станками
- •1.2 Варианты архитектурной организации современных систем чпу
- •1.3 Варианты реализации открытой архитектуры систем чпу
- •1.4 Организация связей между компонентами системы управления
- •1.5 Особенности реализации стандартов в системах чпу
- •1.6 Реализация интерфейсных opc в системах чпу
- •1.7 Сущность производственных стандартов step
- •1.8 Разработка управляющих программ в стандарте step-nc
- •2 Проектирование информационной модели
- •2.1 Управление процессами операционной системой чпу
- •2.2 Состав информационной модели
- •2.3 Система чпу и объект управления как функциональный автомат
- •2.4 Языки программирования и управление систем чпу
- •2.5 Анализ кадра управляющей программы
- •Операции, выполняемые над входом:
- •Операции над магазинной памятью:
- •Служебные операции:
- •2.6 Пример проектирования управляющей таблицы мп-автомата
- •3 Методы программного управления автоматикой
- •3.1 Применение метода маскирования
- •3.2 Метод бинарных программ (разложение в ряд Шеннона)
- •3.3 Метод адресных переходов
- •3.4 Метод маскирования многоместных логических функций
- •3.5 Формализм описания сложных автоматических циклов
- •3.6 Графическое представление параллельных процессов сетью Петри
- •3.7 Формальное определение сети Петри
- •3.8 Применение сетей Петри для моделирования
- •3.9 Разработка сети Петри для моделирования цикла автоматической смены инструмента
- •3.10 Моделирование процесса управления гибкими производственными модулями (гпм)
- •4 Разработка управляющей программы
- •4.1 Базовые понятия
- •4.2. Координатные оси и координатные системы
- •4.3 Программирование интерполяции
- •4.4 Сплайновая интерполяция
- •4.5 Что дает применение сплайновой интерполяции?
- •5 Модернизация систем чпу
- •5.1 Анализ целей и задач модернизации
- •5.2 Модернизация станков чпу на базе систем чпу sinumerik
- •5.3 Разработка структурной схемы системы чпу станка и её конфигурирование
- •5.4 Разработка алгоритмов программного обеспечения
- •6 Общая характеристика структуры и компонентов simodrive
- •6.1 Общая характеристика двигателей
- •6.2 Обзор датчиков
- •6.3 Обзор приводных модулей simodrive
- •6.4 Модули питания
- •7 Проектирование структуры привода simodrive
- •Модули питания.
- •7.1 Принципы выбора двигателей, датчиков и плат управления
- •7.2 Косвенная регистрация положения с аналоговым и цифровым интерфейсами
- •7.3 Прямая регистрация положения с аналоговым управлением
- •7.4 Прямая регистрация положения с цифровым управлением
- •7.5 Выбор и подключение модулей структуры привода
- •Литература
1.6 Реализация интерфейсных opc в системах чпу
OPC – это набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления. Технология OPC определяет интерфейс между OPC-клиентом и OPC-серверами.
OPC-сервер – программа, получающая данные во внутреннем формате устройства или системы и преобразующая эти данные в формат OPC. OPC-сервер является источником данных для OPC-клиентов. По своей сути OPC-сервер – это некий универсальный драйвер физического оборудования, обеспечивающий взаимодействие с любым OPC-клиентом.
OPC-клиент – программа, принимающая от OPC-серверов данные в формате OPC.
Таким образом, OPC-технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.
Что это дает для производителя оборудования?
Универсальный механизм интеграции производимого им оборудования в любую систему, поддерживающую технологию OPC.
До создания OPC-технологии производителю промышленного оборудования приходилось создавать и поддерживать множество драйверов для наиболее распространенных систем автоматизации (или договариваться с производителями этих систем). Применение OPC-технологии позволяет отказаться от создания драйверов и заменяет их одним универсальным OPC-сервером, многократно сокращая затраты на разработку и дальнейшее сопровождение. При этом обеспечивается возможность подключения любой системы автоматизации, наиболее подходящей клиенту, а не только одной из нескольких наиболее распространенных.
Все функции ОРС-сервера описываются спецификациями этой технологии и соответствующими стандартами.
Существует довольно широкий набор интерфейсных ОРС-стандартов:
общие стандарты для всех ОРС-спецификаций;
для обмена оперативными данными с приложениями на C++ и Visual Basic;
для обслуживания событий (event) и внештатных ситуаций (alarm);
для работы с базами данными;
для обработки прав доступа к данным и др.
Основной стандарт, называемый DA (Data Access), описывает передачу оперативных данных от оборудования или к оборудованию. По этому стандарту ОРС-клиент может взаимодействовать с ОРС-серверами от одного или нескольких производителей. Объекты ОРС-сервера напоминают обычные СОМ-объекты.
ОРС Data Access-сервер необходим для работы со встроенной системой и состоит из нескольких объектов: сервера (рис. 1.11), группы (рис. 1.12) и элемента данных (рис. 1.13).
Рисунок 1.11 - Стандартный OPC-объект - сервер
Рисунок 1.124 - OPC-группа
Рисунок 1.13 - OPC-элемент
Объект-сервер поддерживает информацию о сервере и служит контейнером для объектов-групп.
Объект-группа поддерживает информацию о самой себе и предоставляет механизм для включения и логической организации объектов-элементов. ОРС-группы создают клиентам возможность организовывать данные. Например, группа может выводить элементы на экран монитора оператора или представлять их в сообщении. Группы могут обслуживать разных клиентов. Данные можно читать и писать. ОРС-клиент может сконфигурировать скорость, с которой ОРС-сервер будет обновлять данные клиента.
Существуют два типа групп: public и local (или private). Тип public служит для деления групп между многими клиентами, тип local предназначен для одного клиента. В пределах группы клиент определяет один или больше ОРС-элементов.
Орс-элементы устанавливают связи с источниками данных в пределах сервера. Из позиций специального интерфейса ОРС-элемент недоступный для ОРС-клиента, как объект. Иначе говоря, не существует внешнего интерфейса, который был бы определен для ОРС-элемента. Все виды доступа к ОРС-элементам осуществляются с помощью ОРС-групп, которые содержат ОРС-элементы. Элементы-переменные не служат источниками данных, они представляют собой лишь соединение с ними. ОРС-элемент следует рассматривать не как физический источник данных, на который ссылается адрес, а как что-то специфицирующее адреса данных.
Таким образом, основной единицей данных в OPC служит переменная (item). Переменные могут быть любого типа, допустимого в OLE, – целой, вещественной, логической, строчной, датой и др. Кроме того, переменная может быть массивом.
К обязательным свойствам переменной относятся: значение (Value), тип (Type), качество переменной (Quality), метка времени (Time Stamp), права доступа (чтение, запись), частота опроса ОРС-сервером и описание переменной (назначение).
Качество предполагает, что в источниках данных возможны отказы, поэтому корректное значение переменной не всегда известно ОРС-серверу и поэтому клиент сообщает серверу о качестве переменной – хорошее, плохое, неопределенное.
Метка времени сообщает, когда переменная получила конкретное значение и качество.
Частота опроса определяет интервал чтения переменной.
Описание переменной представляет собой строчное значение, которое содержит информацию для пользователя о назначении переменной.
Существуют три способа получения ОРС-клиентом данных от ОРС-сервера: синхронное чтение, асинхронное чтение и подписка.
При синхронном чтении клиент посылает серверу запрос со списком переменных, которые его интересуют, и ждет, пока сервер его выполнит.
При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает сообщение.
В случае подписки клиент передает серверу список переменных, которые его интересуют, а сервер потом регулярно присылает клиенту информацию об изменениях значений переменных со списка. Эти списки в терминологии ОРС называют группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью восстановления.
Следует учесть, что технология ОРС регламентирует только интерфейс между ОРС-клиентами и ОРС-серверами, но не устанавливает способ получения этих данных от оборудования. Однако существуют некоторые модели взаимодействия с оборудованием, когда, например, можно не обращаться для получения данных к ОРС-серверу прямо, а получить их со своего внутреннего буфера (кэша).
Переменные в ОРС-сервере могут быть сформированы или в простой список, или в «дерево», напоминающее «дерево» файлов на диске. Есть соответствующие интерфейсы для навигации по этому дереву. Предусмотрены также возможности оповещения завершения работы ОРС-сервера, запроса информации о самом сервере и запроса списка зарегистрированных групп.
Соответствующие интерфейсы предлагают ОРС-клиентам некоторые механизмы, которые сообщают о возникновении специфицированных событий или аварийных ситуаций. Они предоставляют ОРС-клиентам услуги, которые позволяют идентифицировать события и условия, а также получать текущий статус.
Кроме серверов, которые осуществляют доступ к данным DA, существуют серверы доставки сообщений типа «alarms» и «events». В ОРС alarm определяют как нерегулярную ситуацию, которая представляет собой особый случай условий. Условие (condition) - это поименованное состояние событийного ОРС-сервера или одного из его вложенных объектов. Примерами условий могут служить HighAlarm, HighHighAlarm, Normal, LowAlarm, и LowLowAlarm.
В отличие от alarm событие (event) является заметной ситуацией, которая имеет значение для ОРС-сервера и заинтересованных ОРС-клиентов. Событие может быть, а может и не быть ассоциировано с условием. Например, переходы с HighAlarm в Normal есть события, ассоциированные с условиями.
Интерфейс ОРС-сервера предлагает методы, которые позволяют ОРС-клиенту задавать следующие сервисы:
устанавливать типы событий, которые поддерживает ОРС-сервер;
подписываться на специфические события для того, чтобы ОРС-клиенты могли получать сообщение об этих событиях;
осуществлять доступ к условиям и управлять условиями, создаваемыми ОРС-сервером.
Спецификации ОРС всегда содержат два набора интерфейсов: интерфейсы пользователя (Custom Interfaces) и интерфейсы автоматизации (Automation Interfaces). Последние имеют доступ к приложениям, написанным на Visual Basic (рис. 1.14).
Рисунок 1.14 - Разновидности OPC-интерфейсов
Спецификации ОРС определяют, что собой представляют интерфейсы, но не как выглядит проект. Поэтому нужно специфицировать ожидаемое поведение интерфейсов, которые используются клиентскими приложениями. При разработке ОРС-сервера следует выбрать частоту передачи данных по выделенному каналу, а также устройства, ответственные за сбор данных.
ОРС-серверы нуждаются в разработке специальных (пользовательских) интерфейсов, а как опцию могут иметь интерфейсы автоматизации. В некоторых случаях интерфейс автоматизации создается с помощью специальной DLL-оболочки интерфейса пользователя (рис. 1.15).
Рисунок
1.15 - Типичная архитектура OPC
Таким образом, клиентское ОРС-приложение взаимодействует с ОРС-сервером через специфицированный разделяемый интерфейс и специальный интерфейс пользователя или интерфейс автоматизации. Эти интерфейсы решают проблему открытого управления, т.е. обеспечивают совместимость и интерактивность разнообразных локальных устройств.