Modbus — коммуникационный протокол, основанный на клиент-серверной архитектуре. Разработан фирмой Modicon для использования в контроллерах с программируемой логикой (PLC). Стал стандартом де-факто в промышленности и широко применяется для организации связи промышленного электронного оборудования. Использует для передачи данных последовательные линии связи RS-485, RS-422, RS-232, а также сети TCP/IP. В настоящее время поддерживается некоммерческой организацией Modbus-IDA.

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

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

    Протокол Modbus описывает единый простой формат передачи данных PDU, который в свою очередь входит в полный пакет ADU. Формат ADU меняется в зависимости от типа линии связи. Существуют три режима протокола: Modbus RTU, Modbus ASCII, Modbus TCP. Первые два используют последовательные линии связи (в основном RS-485, реже RS-422/RS-232), последний использует для передачи данных по сетям TCP/IP.

    Протокол Modbus RTU предполагает одно ведущее (запрашивающее) устройство в линии (master), которое может передавать команды одному или нескольким ведомым устройствам (slave), обращаясь к ним по уникальному в линии адресу. Синтаксис команд протокола позволяет адресовать 247 устройств на одной линии связи стандарта RS-485 (реже RS-422 или RS-232).

    Инициатива проведения обмена всегда исходит от ведущего устройства. Ведомые устройства прослушивают линию связи. Мастер подаёт запрос (посылка, последовательность байт) в линию и переходит в состояние прослушивания линии связи. Ведомое устройство отвечает на запрос, пришедший в его адрес. Окончание ответной посылки мастер определяет, по временному интервалу между окончанием приёма предыдущего байта и началом приёма следующего. Если этот интервал превысил время, необходимое для приёма двух байт на заданной скорости передачи, приём кадра ответа считается завершённым. Кадры запроса и ответа по протоколу modbus имеют фиксированный формат, приведённый в (Таблица 1-1).

Таблица 1-1. Кадр посылки Modbus RTU

где:

• адрес ведомого устройства — первое однобайтное поле кадра. Оно содержит адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 254. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство;

• номер функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;

• данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;

• CRC — (контрольная сумма) заключительное двухбайтное поле кадра. Контрольная сумма завершает кадры запроса и ответа и применяется для проверки отсутствия ошибок в кадре посылки Modbus RTU.

Следует отметить, что поле CRC записывается младшим байтом вперёд. Алгоритм расчёта CRC может отличаться для разных устройств.

    Адресация данных в протоколе Modbus RTU

    Все операции с данными привязаны к нулю, каждый вид данных (регистр, выходное/входное значение) начинаются с адреса 0000.

Адресация к ячейке начинается с 1.

Например: Флаг номер 1 программируемого контроллера имеет адрес 0000 (указывается в поле "Адрес").

Флаг номер 127 (DEC) имеет адрес 0x007E hex (126 dec) (указывается в поле "Адрес").

Запоминающий регистр 40001 будет иметь адрес 0000 в поле "Адрес" команды. Потому что код операции уже содержит в себе необходимую информацию об адресе. Операции с этими регистрами имеют смещение Адрес_регистра - 40000 = Значение Используемое В Поле "Адрес". Тип адресации команд в дальнейшем будем помечать т.о.

Запоминающий регистр 40108 будет иметь адрес 006B hex (107 dec)

    Контроль ошибок в протоколе Modbus RTU

Во время обмена данными могут возникать ошибки двух типов:

• ошибки, связанные с искажениями при передаче данных;

• логические ошибки.

Ошибки первого типа обнаруживаются при помощи фреймов символов, контроля чётности и циклической контрольной суммы CRC-16-IBM (используется число-полином = 0xA001).

RTU фрейм

    В RTU режиме сообщение начинается с интервала тишины равного времени передачи 3.5 символов при данной скорости передачи в сети. Первым полем затем передается адрес устройства.

    Вслед за последним передаваемым символом также следует интервал тишины продолжительностью не менее 3.5 символов. Новое сообщение может начинаться после этого интервала.

    Фрейм сообщения передается непрерывно. Если интервал тишины продолжительностью 1.5 возник во время передачи фрейма, принимающее устройство заканчивает прием сообщения и следующий байт будет воспринят как начало следующего сообщения.

    Таким образом, если новое сообщение начнется раньше 3.5 интервала, принимающее устройство воспримет его как продолжение предыдущего сообщения. В этом случае устанавливается ошибка, так как будет несовпадение контрольных сумм.

Подробнее на сайте некоммерческой организации поддерживающей протокол шины Modbus: www.modbus.org

Краткое описание OPC

    Технология связывания и внедрения объектов для систем промышленной автоматизации OPC (OLE for Process Control) предназначена для обеспечения универсального механизма обмена данными между датчиками, исполнительными механизмами, контроллерами, устройствами связи с объектом и системами представления технологической информации, оперативного диспетчерского управления, а также системами управления базами данных.

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

    Структура взаимодействия между приложениями-клиентами и серверами OPC различных производителей показана ниже.

    Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.

    Базовым понятием этой модели является элемент данных (Item). Каждый элемент данных имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа булево, целое, с плавающей точкой и т.п. или строкой (так называемый OLE VARIANT). Время представляется с 100-наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случая, зависит от реализации сервера и аппаратуры. Качество это код, содержащий в себе грубую оценку UNCERTAIN, GOOD и BAD (неопределено, хорошее и плохое), а на случай плохой еще и расшифровку, например QUAL_SENSOR_FAILURE ошибка датчика.

    Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавлять в группу элементы (Items). Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Для каждого клиента всегда создается своя группа (кроме так называемых публичных групп), даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению группы.

    Наконец, на верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех

перечисленных (OPC-группа, OPC-элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту.

    Программа ModBus OPC Server - далее «сервер», разработанная предприятием “МИКРОЛ” предназначена для автоматизации обмена информациией между приборами, производимыми предприятием “МИКРОЛ” и приложениями – клиентами на ЭВМ. «Сервер» реализует стандартный интерфейс доступа к данным ОРС Data Access 2.0 в соответствии со спецификацией OPC Data Access Custom Interface Specification 2.0.

    Для конфигурирования «сервера» предоставляется отдельная программа MOPC.EXE, посредством которой пользователь имеет возможность визуально спланировать конфигурацию «сервера», которая представляет собой двухуровневою структуру. Первый уровень – это конфигурация последовательных портов RS-232 установленных в ЭВМ, «сервером» поддерживается до 14 шт. (СОМ1-СОМ14). Второй уровень – конфигурация контроллеров подключенных через преобразователь интерфейсов RS-485↔RS-232 к портам ЭВМ. Пример конфигурации «сервера» представлен на рисунке.

    Исходя из топологии сети RS-485 имеется возможность подключить до 32 приборов к одному блоку преобразования интерфейсов БПИ-485 (количество подключенных приборов к одному блоку преобразования интерфейсов может изменяться в зависимости от технических характеристик, самого преобразователя, но не более 255).

    Также данной программой производится конфигурация пространства имен «сервера» в виде свободно конфигурируемой многоуровневой структуры.

Подробнее на сайте разработчика: www.microl.com.ua