Среда разработки CODESYS V3.5 используется для программирования контроллеров ОВЕН ПЛК2хх и СПК1хх. Одной из наиболее важных задач контроллеров является обмен данными с другими устройствами. В качестве основного коммуникационного протокола применяется Modbus. Среда CODESYS включает в себя компоненты для настройки обмена по этому протоколу. Они являются простыми в использовании, но имеют ряд ограничений, которые в некоторых случаях мешают их применению. Чтобы предоставить клиентам расширенный функционал для настройки обмена, компания ОВЕН разработала библиотеку OwenCommunication.
Стандартные средства конфигурирования CODESYS
Стандартные средства CODESYS позволяют настраивать обмен через дерево проекта (рис. 1). Удобство использования этих средств заключается в том, что пользователю не требуется обладать навыками программирования – достаточно добавить требуемые компоненты и задать их параметры. Чтобы еще больше упростить процесс настройки обмена, специалисты ОВЕН разработали шаблоны для опроса модулей ввода-вывода Mx110/Mx210 и других приборов ОВЕН. Шаблоны включают в себя настроенные каналы опроса для основных параметров устройства. Все, что нужно сделать для опроса прибора через шаблон – добавить его в проект, указать адрес и привязать к нужным каналам переменные программы.
Стандартные средства конфигурирования имеют ряд ограничений, которые в некоторых случаях затрудняют их использование. Эти ограничения можно разделить на три основные группы.
Первое ограничение связано со сложностью изменения настроек обмена из кода программы. Изменение настроек может потребоваться в тех случаях, когда настройки опрашиваемых устройств (например, их адреса) заранее неизвестны, и оператор должен задать их через визуализацию. Стандартные средства CODESYS позволяют менять только ряд настроек, и пользователю придется самостоятельно организовывать их применение после каждой перезагрузки (по умолчанию будут применяться настройки из дерева проекта).
Второе ограничение – количественное. Например, существует ограничение на количество добавляемых slave-устройств, каналов slave-устройств, регистров в режиме Slave и т.д.
Третье ограничение – функциональное. Например, в режиме Slave нельзя изменить значения holding регистров ПЛК из его программы – то есть отсутствует область памяти, которая могла бы изменяться как со стороны ПЛК, так и со стороны опрашивающего его master-устройства.
Библиотека OwenCommunication лишена всех этих ограничений и предоставляет пользователю дополнительный функционал по настройке обмена. Сравнение библиотеки и стандартных средств конфигурирования приведено в табл. 1.
Библиотека OwenCommunication
Библиотека OwenCommunication содержит 4 группы функциональных блоков:
- Блоки управления интерфейсами (COM_Control, TCP_Client).
- Блоки для реализации обмена по Modbus (MB_SerialRequest, MB_SerialSlave, MB_TcpRequest, MB_TcpSlave).
- Блоки для реализации нестандартных протоколов (UNM_SerialRequest, UNM_TcpRequest, UNM_UdpRequest).
- Блоки и функции конвертации данных (REAL_TO_WORD2, WORD2_TO_REAL и т.д.).
Все функциональные блоки имеют единообразный интерфейс (аналогичный CAA-библиотекам), что упрощает их использование (рис. 2). Так как стандарт Modbus не специфицирует никаких типов данных (вся информация передается в виде последовательностей 16-битных регистров; в CODESYS такому регистру соответствует тип WORD), то библиотека содержит готовые блоки для конвертации данных типов REAL, DWORD и т.д. Эти блоки могут также использоваться в сочетании со стандартными компонентами Modbus.
Помимо отсутствия ограничений, присущих стандартным компонентам CODESYS, библиотека OwenCommunication включает в себя дополнительный функционал.
Блок MB_TcpRequest, помимо протокола Modbus TCP, позволяет использовать протокол Modbus RTU over TCP. Этот протокол может потребоваться в тех случаях, когда slave-устройство подключается через конвертер интерфейсов Ethernet/RS-485 или, например, GPRS-модем с интерфейсом RS-485.
Блок MB_TcpSlave поддерживает функцию Modbus 20 (0x16) Read File Record, которая используется для считывания файлов, и позволяет, в частности, Modbus TCP-клиенту загружать файлы архивов. OPC-cервер компании ИнСАТ MasterOPC Universal Modbus Server содержит готовый скрипт, который считывает архивные данные с контроллера и предоставляет SCADA-системе доступ к ним через интерфейс OPC HDA. Таким образом, в случае разрыва и восстановления связи с контроллером SCADA сможет выгрузить сохраненные в нем исторические данные и скопировать их в свою базу данных, сохранив «бесшовность» архива.
Блок MB_SerialSlave поддерживает работу по протоколу Modbus ASCII. При этом блок автоматически определяет протокол запроса (RTU или ASCII) и отправляет ответ в нужном формате. Кроме того, если блоку задан адрес 255, то он отвечает на запросы по любому адресу. Это удобно на этапе тестирования, когда требуется сэмулировать наличие в сети нескольких slave-устройств с разными адресами.
Блоки MB_SerialSlave и MB_TcpSlave предоставляют пользователю информацию о получаемых запросах, что дает возможность в программе определить момент получения новой команды записи (и, например, однократно проверить корректность полученных значений). Также можно запретить обработку определенных запросов – например, заблокировать возможность записи или чтения определенных диапазонов регистров. Кроме того, блоки позволяют установить начальный адрес регистров slave’a и изменить порядок байт в буфере данных (это удобно в ситуациях, когда поменять порядок байт в master-устройстве невозможно – например, его уже нельзя перепрограммировать).
Реализация нестандартных протоколов
Несмотря на распространенность протокола Modbus, некоторые производители вместо его поддержки разрабатывают собственные протоколы обмена. На рынке представлено достаточно устройств (тепло- и электросчетчиков, газоанализаторов, весоизмерительных преобразователей и т.д.), для опроса которых потребуется реализовать в программе контроллера поддержку нестандартного протокола. Библиотека OwenCommunication предоставляет пользователю готовые блоки (рис. 3) для отправки произвольного запроса и получения ответа по интерфейсу RS-485/RS-232 или Ethernet (TCP, UDP). Это позволяет программисту абстрагироваться от «коммуникационных» аспектов задачи и сосредоточиться на написании блоков формирования запросов и разбора ответов.
В будущем планируется разработка отдельной библиотеки OwenVendorProtocols, которая будет содержать блоки опроса наиболее используемых тепло- и электросчетчиков.
Особенности реализации библиотеки
Блоки библиотеки выполняются асинхронно по отношению к циклу контроллера – то есть их вызовы не являются блокирующими. Выполнение одного блока занимает несколько циклов контроллера, что позволяет снизить влияние работы библиотеки на время цикла и не создает непредвиденных задержек. По этой же причине библиотека не позволяет «ускорить» обмен – частота опроса при использовании ее блоков не превышает возможности стандартных средств CODESYS и в отдельных ситуациях даже может быть несколько ниже.
Примеры и документация
Библиотека OwenCommunication доступна для загрузки на сайте ОВЕН в разделе CODESYS V3/Библиотеки и компоненты. Описание и примеры использования библиотеки приведены в документе CODESYS V3.5. Настройка обмена по протоколу Modbus. На YouTube-канале ОВЕН доступны видеоуроки по работе с библиотекой.
|
Характеристика |
Стандартные средства |
OwenCommunication |
|
Общие характеристики |
||
|
Управление обменом из кода программы |
С существенными ограничениями |
Без ограничений |
|
Modbus Serial Master |
||
|
Широковещательная рассылка (на адрес 0) |
- |
+ |
|
Макс. число каналов опроса для одного slave-устройства |
100 |
Без ограничений |
|
Modbus Serial Slave |
||
|
Модель памяти |
Две независимых области памяти: Coils/Holding-регистры и Discrete Inputs/Input-регистры |
Одна область памяти (как в ПЛК1хх) |
|
Изменение значений holding регистров из кода программы |
- |
+ |
|
Макс. число регистров |
500 Input + 500 Holding |
65536 |
|
Modbus TCP Master |
||
|
Макс. число опрашиваемых slave-устройств |
64 |
Без ограничений |
|
Макс. число каналов опроса для одного slave-устройства |
100 |
Без ограничений |
|
Modbus TCP Slave |
||
|
Модель памяти |
Две независимых области памяти: Coils/Holding-регистры и Discrete Inputs/Input-регистры |
Одна область памяти (как в ПЛК1хх) |
|
Изменение значений holding-регистров из кода программы |
- |
+ |
|
Макс. число регистров |
4096 Input + 4096 Holding |
65536 |