Управление современным электроприводом с персонального компьютера

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

Специализированные решения на базе OPC-серверов

OPC (OLE for Process Control, где OLE — Object Linking and Embedding) — набор стандартов, описывающих универсальный фиксированный интерфейс обмена данными с промышленными устройствами. Использование OPC позволяет работать с оборудованием не на уровне конкретного протокола или драйвера устройства, а на уровне фиксированного и описанного в стандарте набора функций. Это позволяет, например, заменить оборудование без изменения программного обеспечения (ПО) — главное, чтобы новое оборудование поддерживало соответствующую версию OPC. Конкретная реализация протокола или драйвера устройства в данном случае не важна, так как задача преобразования команд OPC в непосредственную работу с устройством решается с помощью OPC-драйвера, предоставляемого компанией — производителем устройства в случае поддержки данного стандарта.

Примером системы с поддержкой стандарта OPC могут служить решения компании Siemens на базе WinCC-сервера. В качестве SCADA-системы предлагается Simatic WinCC, в качестве OPC-сервера — WinCC-Server для операционных систем (ОС) Windows. Система позволяет решить задачи мониторинга и управления, а также реализовать возможность визуализации техпроцесса, используя специальный редактор.

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

Таким образом, несмотря на очевидные плюсы управления приводом через OPC с точки зрения архитектуры и стандартизации, у данного подхода есть свои минусы с потребительской точки зрения:

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

Решение на базе реализации протокола, поддерживаемого конкретным устройством

Одним из наиболее часто используемых вариантов (и, зачастую, единственно возможным) при организации управления служит реализация на ПК протокола, используемого контроллером привода. Как правило, производитель старается использовать стандартные промышленные протоколы, такие как CANopen, Device NET (шина CAN), Modbus (линии связи с последовательной передачей данных RS-485, RS-422, RS-232, Ethernet), Profibus (RS-485, оптическая сеть). В этом случае задача сопряжения привода с ПК сводится к трем подзадачам:

Сопряжение с ПК на уровне интерфейса. Данная задача решается покупкой соответствующего преобразователя интерфейса в виде платы расширения или отдельного устройства.

Реализация на стороне ПК протокола обмена устройства. Решение этой задачи облегчается тем, что, как правило, для всех популярных промышленных протоколов существуют готовые реализации. Это существенно упрощает задачу. Например, реализация протокола Modbus в виде бесплатных бибилиотек OsmModbusController или LibModbus.

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

Решение на базе SDK, поставляемого производителем

В случае, когда производитель озаботился выпуском SDK (Software Development Kit) для организации управления приводом (либо другим устройством), задача интеграции с ПО решается проще и дешевле — SDK обычно прилагается к оборудованию бесплатно, чтобы побудить разработчиков использовать данную платформу. Как правило, такие SDK содержат высокоуровневые функции управления. В качестве примера рассмотрим бесплатный SDK для контроллеров шаговых двигателей семейства OSM производства Onitex, который работает поверх промышленного протокола Modbus RTU.

Данные контроллеры могут общаться с ПК посредством интерфейсов USB, RS-232 либо RS-485. В случае использования RS-485 контроллеры могут быть объединены в сеть до 32 устройств. Для управления с ПК в этом случае применяется преобразователь интерфейсов, например USB<–>RS-485.

SDK рассчитан на работу в среде .NET, работает под ОС Windows, Linux и MacOS, а также полностью совместим со средой разработки и выполнения программ LabView, часто используемой в лабораториях. Все управляющие команды перечислены в документации и позволяют полностью контролировать работу электропривода в реальном времени:

• Контроль скорости: стартовая, конечная, требуемая скорость, ускорение/замедление, количество шагов ускорения/замедления, обновляемые в реальном времени данные о текущей скорости.
• Контроль положения: текущая позиция по внутреннему счетчику, установка конечной позиции, текущая позиция по данным энкодера (при режиме работы с энкодером).
• Смена направления вращения «на лету».
• Контроль тока.
• Контроль времени перехода в спящий режим и установка значения тока в спящем режиме.
• Установка режимов микрошага: смена режима микрошага «на лету».
• Установка ограничений на число шагов в командах движения.
• Работа со входами и выходами устройства: счетчик по прерываниям на входе EN (возможно чтение значения счетчиков из программы), раздельная установка разрешений прерываний по входам.
• Управление сменой режимов входов. Например, для входа в реверс: режим смены направления вращения по сигналу, режим счетчика прерываний, режим счетчика с защитой от дребезга контактов, режим энкодера.

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

public void SetSpeed (byte slaveAddress, ushort speed),

где slaveAddress — адрес конкретного устройства, speed — скорость в герцах.

Таким образом, конечному пользователю совершенно необязательно вникать не только в реализацию протокола, по которому происходит передача данных, но и в струк-туру регистров самого устройства. Необходимо лишь выполнить физическое соединение устройства с компьютером посредством интерфейса USB, RS-232 или RS-485 и подключить SDK к своему проекту.

Использование SDK производителя имеет также свои минусы:

• привязка к конкретному поставщику оборудования;
• необходимость использования языка программирования, выбранного поставщиком, либо привязки к этому языку.

Решение на базе специализированного программного обеспечения для станков с ЧПУ

Часто задача управления приводом с ПК является частью более общей задачи — управление с ПК станком с числовым программным управлением (ЧПУ). В этом случае оправданно использование специализированных программных решений для станков с ЧПУ. Например, для управления приводами координатного стола в качестве бюджетного решения подходит такое ПО, как Mach3 (также работает с токарным станком), AlfaCAM, KCam. Движение приводов в этом ПО задается с помощью языка G-code, в котором записаны все параметры движения приводов. Как правило, G-code не пишутся вручную, а генерируются управляющим ПО по двух- или трехмерной модели изделия, которое необходимо изготовить. Также такое ПО может управлять дополнительным оборудованием через реле. Для cвязи контроллеров приводов с ПК применяются специальные платы расширения, такие как MC4.

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

В WireBender последовательность выполняемых операций задается вручную, с помощью простых текстовых команд, например: двигатель «a»: направо на 3000 шагов, разгон c ускорением 3000 шаг/с², остановка с замедлением 2000 шаг/с², скорость 2500 шаг/с:

a:6000 ac:3000 dc:2000 sd:2500.

Двигатель «b»: направо до срабатывания датчика на входе in1, но не более 1000 шагов, ускорение 5000 шаг/с², скорость 2500 шаг/с:

b:in1<1000 ac:5000 sd:2500.

Управление приводами в этом случае осуществляется через интерфейс RS-485.

* * *

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