Промышленный протокол ModBus. Сеть приборов, протокол MODBUS

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

В российской википедии существует довольно обширная , в которой рассказывается история протокола, его основные достоинства и недостатки, терминология, модель данных и функционал. Не претендуя на полноту изложения, но в то же время, не боясь повториться, рассмотрим некоторые базовые вещи для тех, кому надо всего-то «два байта переслать».

Прежде всего, как представлены данные в устройстве поддерживающем ModBus. Это четыре таблицы с данными:

В реальной практике чаще всего встречаются устройства, в которых есть только таблица Holding Registers, иногда объединённая с таблицей Input Registers.

Для доступа к этим таблицам существует ряд стандартный функций ModBus:

• 1 (0x01) - чтение значений из нескольких регистров флагов (Read Coil Status).
• 2 (0x02) - чтение значений из нескольких дискретных входов (Read Discrete Inputs).
• 3 (0x03) - чтение значений из нескольких регистров хранения (Read Holding Registers).
• 4 (0x04) - чтение значений из нескольких регистров ввода (Read Input Registers).

Запись одного значения:

• 5 (0x05) - запись значения одного флага (Force Single Coil).
• 6 (0x06) - запись значения в один регистр хранения (Preset Single Register).

Запись нескольких значений:

• 15 (0x0F) - запись значений в несколько регистров флагов (Force Multiple Coils)
• 16 (0x10) - запись значений в несколько регистров хранения (Preset Multiple Registers)

Из сказанного выше следует, что самые часто используемые функции ModBus это 3, 6 и 16 («Read Holding Registers», «Preset Single Register» и «Preset Multiple Registers» — соответственно).

Что происходит при чтении или записи регистра в ModBus устройство? Рассмотрим, для начала, протокол ModBus RTU. Он применяется для передачи данных по последовательным интерфейсам, таким как RS-232 или RS-485. Большинство современных устройств используют RS-485, так как он, во первых, как правило, двух проводной и во вторых, позволяет подключить несколько устройств в один шлейф.

Важно то, что при подобной топологии на одном шлейфе может быть только один ModBus Master, то есть устройства не могут свободно «общаться» между собой. На каждом шлейфе организуется четкая иерархия Master – Slave («Ведущий» – «Ведомый»). Ведомых, как уже было сказано, может быть несколько, а ведущий только один!

Адресная модель ModBus позволяет использовать адреса устройств с 1 по 247, что иногда вводит в заблуждение некоторых «проектологов», т.к. RS-485 позволяет подключить к одной шине, без усилителей и репитеров, только 32 устройства. На самом деле я рекомендую для стабильной работы, с приемлемым количеством повторных запросов, не превышать значение 20 устройств на одну шину RS-485.

Итак, для чтения одного Holding Register ведущий посылает запрос на адрес ведомого устройства с кодом функции 3 (Read Holding Registers), указанием адреса интересующего регистра и количеством регистров для чтения, в данном случае = 1. На что ведомый отвечает пакетом, в котором повторяет собственный адрес, номер обрабатываемой функции и, в поле данных размещает значение запрашиваемого регистра. Для чтения нескольких последовательных регистров в запросе ведущий просто указывает адрес первого и их количество.

В общем виде, работу функции 3 (Read Holding Registers) протокола ModBus можно представить так:

Теперь рассмотрим, чем отличается ModBus TCP от ModBus RTU. Во первых, нет ограничения на одного ведущего в сети, все устройства могут практически свободно «общаться» между собой. Во вторых используется другой формат пакета, добавился заголовок, что более типично для данной среды передачи.

Так как транспортом для передачи служит протокол TCP, то для адресации устройств ведущему необходимо знать IP адрес ведомого устройства и порт, на котором ведомый ожидает запросов. Стандартный порт для ModBus TCP протокола 502 , но некоторые среды программирования контроллеров, например CODESYS, позволяют его изменить. Тот же самый CODESYS, а точнее контроллеры, запрограммированные в этой среде или средах производных от CODESYS, при работе по протоколу ModBus TCP игнорируют поле «Unit ID» и отвечают на запросы для любого «Unit ID», а не выдают сообщение об ошибке. Это значит, что иногда, достаточно знать IP адрес и порт контроллера.

Довольно часто сталкиваюсь с непониманием модели OSI среди инженеров и проектировщиков АСУ ТП и АСУЗ. Поэтому вот еще одна картинка, разъясняющая то, как пакет ModBus TCP передается по Ethernet сети:

UPD (26.09.2016): Довольно неплохое русскоязычное видео на тему:

Статья посвящена промышленному протоколу ModBus — наиболее простому, а потому широко распространённому цифровому протоколу передачи данных.

Стандарт ModBus был изобретён ещё в 1979 году компанией Modicon (ныне Schneider Electric) и с того времени не утратил своей актуальности, а даже наоборот получил широкое распространение и большую популярность среди разработчиков АСУ ТП.

Преимущества и недостатки протокола ModBus

Преимущества:

• прост в реализации
• отсутствует необходимость установки специальных микросхем для реализации протокола при разработке контроллеров и устройств
• простота диагностики и отладки
• поддерживается большинством устройств, применяемых при построении АСУ ТП
• высокая надёжность и достоверность при передаче данных

Недостатки:

• ModBus сеть построена по принципу «ведущий-ведомый», где ведущее устройство может быть только одно. Поэтому обмен данными происходит только по инициативе ведущего устройства (оно по очереди опрашивает все ведомые). Если ведомому устройству нужно срочно передать данные, оно не может этого сделать, пока его не опросит «ведущий».

Общие сведения о ModBus сети

ModBus сеть объединяет одно ведущее (мастер) и несколько ведомых (слейвов). Обмен данными в сети происходит по инициативе мастера. Он может отправить запрос одному из подчинённых устройств или широковещательное сообщение сразу всем ведомым устройствам сети.

После отправки запроса мастер ожидает ответ в течение заданного времени («время таймаута»). Если в течение этого времени ответ не получен, мастер считает, что связь с ведомым отсутствует. На широковещательное сообщение ответ не предусмотрен.

Слейвы (ведомые устройства) не могут самостоятельно инициировать передачу данных. Они могут передать данные только после запроса мастера (и только те данные, которые мастер запросит).

Существует три разновидности протокола:

• ModBus ASCII — разновидность протокола, в которой сообщения кодируются с помощью ASCII-символов. Сообщения разделяются символами «:» и CR/LF. Не очень удобен, в России используется крайне редко.
• ModBus RTU — разновидность протокола, в которой сообщения кодируются «как есть» (числами). Между собой сообщения разделяются временной паузой в 3,5 символа при заданной скорости передачи.
• ModBus TCP — разновидность протокола для работы поверх TCP/IP стека, требуется при соединении устройств по Ethernet.

Физический уровень протокола ModBus

Для передачи ModBus сообщений используется последовательные асинхронные интерфейсы (RS232, RS485, RS422) в случае использования протоколов ASCII и RTU и Ethernet интерфейс для протокола ModBus TCP.

Использование стандартных интерфейсов делает ModBus удобным для пользователей и разработчиков.

Типы данных ModBus

Любой узел сети ModBus — это интеллектуальное устройство (контроллер, регулятор, датчик и др.). Согласно спецификации узел сети может иметь следующие структуры данных:

• Discrete Inputs — состояния дискретных входов устройства, их можно только прочитать. Однобитовый тип данных.
• Coils — состояния дискретных выходов устройства, их можно прочитать и изменить (записать новое состояние). Однобитовый тип.
• Input Registers — 16-битные регистры, доступные только для чтения.
• Holding Registers — 16-битные регистры свободного назначения, доступны для чтения и записи.

Указанные типы данных необязательны для всех устройств, поддерживающих ModBus. Например, Discrete Inputs и Coils характерны больше для .

Производитель устройства сам решает, какой тип данных сделать доступным для чтения и записи по ModBus, и об этом написано в руководстве устройства. В большинстве случае пользуются типом Holding Registers, поскольку он самый универсальный.

Структура обмена данными по ModBus

Как уже было сказано, обмен данными по ModBus состоит из запросов и ответов. Ведущее устройство посылает запрос одному из подчинённых устройств, указывая в запросе его адрес, или всем устройствам сразу, указывая адрес 0.

Рис. Структура ModBus-пакета

Типовой запрос или ответ состоит из следующих блоков:

• адрес подчинённого устройства
• номер функции — определяет тип запрашиваемых данных и что с ними нужно сделать (прочитать/записать)
• данные — содержит параметры функции («куда», «сколько» и «какие» данные записывать или читать)
• блок контроля подлинности — содержит контрольную сумму для проверки целостности полученных данных.

Состав данных блоков отличается для RTU и TCP реализаций ModBus. Далее мы подробно рассотрим каждый из них.

ModBus ASCII мы не будем подробно рассматривать, поскольку он используется крайне редко. Состав пакета в ModBus ASCII такой же как и ModBus RTU, и отличается только типом кодирования и способом разделения пакетов.

Номер функции определяет тип запрашиваемых данных и что с ними нужно сделать (прочитать/записать).

Функций ModBus достаточно много и они разделены на три категории:

• стандартные — функции, описанные в стандарте протокола. Среди них много устаревших и неиспользуемых.
• пользовательские — диапазон номеров функций (с 65 по 72 и с 100 по 110), которые может использовать любой производитель устройств для реализации своих специфичных функций. При этом вполне возможно, что у устройств различных производителей под одинаковыми номерами будут разные по смыслу функции.
• зарезервированные — функции, не описанные в базовом стандарте, но реализованные в устройствах различных производителей. При этом гарантируется, что данные производители зарезервировали эти номера для себя и другие производители не могут ими воспользоваться.

Однако, это всё лирика… На практике в большинстве случаев используются всего несколько функций, мы подробно поговорим о них в , а в этой будем рассматривать всё на примере функции Read Holding Registers (чтение регистров общего назначения).

Функция Read Holding Registers (0x03)

Функция под номером 3 — одна из самых употребимых функций, предназначена для чтения регистров общего назначения устройства.

В запросе указывается количество регистров, которые нужно прочитать и адрес первого из них.

Ответ содержит количество байт (количество регистров умноженное на 2) и значения запрошенных регистров.

Рис. Запрос от мастера

Рис. Ответ слейва

Количество байт в ответе помогает ведущему устройству по мере получения данных понять, когда все данные уже получены. То есть если мастер получил третий байт с числом 200 — это означает, что ему осталось получить еще 100 байт + 2 байта контроля целостности. Это позволит ему посчитать количество пришедших байт и закончить приём, не дожидаясь, когда закончится время таймаута, отведённое слейву на ответ.

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

Обратимся к предыдущему примеру. Там подчинённое устройство ответило без ошибки и второй байт в ответе был 0х03. Если бы ответ содержал код ошибки, то к номеру функции подчинённое устройство добавило бы 0х80 и получилось бы 0х83. Вот так:

Рис. Ответ слейва с признаком ошибки

В этом примере код ошибки 02 — это один из стандартных кодов. Вот какие они бывают:

01 — функция не поддерживается. Это значит, что, возможно, функция не стандартная или просто не реализована конкретно в этом устройстве.

02 — запрошенная область памяти не доступна. Каждое устройство содержит определённое количество данных определённого типа. Например, в устройстве доступно 100 регистров общего назначения. Если при этом запросить чтение 101 регистров — возникнет ошибка 02.

03 — функция не поддержит запрошенное количество данных. Например, функция №3 «Read Holding Registers» позволяет читать от 1 до 2000 регистров общего назначения. Поэтому, даже если в подчинённом устройстве доступно для чтения 10 000 регистров, при запросе более 2000 с помощью функции №3 — возникнет эта ошибка.

04 — функция выполнена с ошибкой. Такой код ошибки будет возвращён, если есть какое-то иное препятствие для нормального выполнения команды, не охваченное тремя предыдущими кодами ошибки. Проще говоря, это такая заглушка «на всякий случай», если что-то пошло не так, но в протоколе специального кода для такой ошибки не предусмотрено.

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

ModBus RTU

Как уже говорилось, в протоколе ModBus RTU данные передаются в виде сообщений, разделённых между собой временными паузами длиной в 3,5 символа при заданной скорости передачи.

В сообщении обязательно указывается адрес получателя (или 0, если сообщение широковещательное) и номер функции.Номер функции определяет какие данные содержит сообщение и как их интерпретировать.

За номером функции идут данные. Регистры данных в ModBus 32-битные, а передаются ввиде двух 16-битных сло. Сначала идёт старший байт, затем младший.

Пример. Допустим, мы хотим прочитать из удалённого модуля сбора данных 2 регистра, начиная с первого. Адрес удалённого модуля в сети ModBus «4». Для этого воспользуемся функцией №3 Read Holding Registers.

Рис. Запрос на чтение 2-х регистров, начиная с 1-го

Рис. Ответ от слейва на запрос

В ответе подчинённое устройство повторяет свой адрес и номер функции, далее следует количество полезных байт в ответе. Каждый регистр состоит из двух байт (сначала идёт старший, затем младший). Значение запрошенных регистров оказались равны 11 и 22 в десятичной системе исчисления (0B и 16 в шестнадцатеричной соответственно).

О том, как использовать другие ModBus функции мы выпустим отдельную статью.

Контроль целостности пакета в ModBus RTU (CRC-16)

В предыдущем примере за байтами данных идут два байта проверки целостности пакета. Они являются результатом вычисления кода CRC-16 для всего сообщения.

Мастер, передавая запрос, вычисляет CRC-код и добавляет его в конец сообщения. Слейв, получив сообщение, проверяет сообщение на целостность согласно алгоритму CRC-16. Затем подчинённое устройство составляет ответ, точно так же вычисляет для него CRC и добавляет в конец пакета.

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

Заключение

В данной статье мы рассмотрели общую структуру протокола ModBus и его классическую разновидность ModBus RTU. Вообще говоря, ModBus RTU — это и есть «истинный Modbus» (если отбросить ModBus ASCII, который уже устарел).

В мы поговорим о разновидности протокола ModBus TCP, который является «притягиванием за уши» классического ModBus с целью использования его в Ethernet-сетях, что, конечно же, накладывает определённые ограничения. Но об этом в следующей статье. Следите за обновлениями на LAZY SMART .

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

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

Для хранения информации в ведомых устройствах (slave device ) используются 4 таблицы (или массива). Каждая таблица хранит информацию для схожих переменных в регистрах. Каждый регистр имеет свой размер и адрес. Так же регистры могут быть только для чтения, или для чтения – записи. Давайте рассмотрим эти 4 типа данных, которые можно хранить в регистрах:

COILS

Это цифровые выходы (Digital Outputs ). Каждый coil можно записать или считать. Его размер – 1 бит (т.е. 0 или 1). Исторически эти регистры связаны с реальными цифровыми выходами на сенсорах или терминальных устройствах. Цифровые выходы используются для управления, например светодиодами, реле или моторами. Т.е. записывая в такой регистр 1 мы можем включить светодиод, а записав 0 – выключить его (это условно, на самом деле 0 может включать, а 1 – выключать).

При чтении данного регистра мы можем узнать состояние выхода (т.е. включен он или выключен). Результат чтения так же 1 бит, т.е. 1 или 0.

CONTACTS

Это цифровые входы (Digital Inputs ). Цифровой вход можно только читать, т.е считывая данный регистр мы узнаем состояние реального цифрового входа на сенсоре или устройстве. Цифровые входы используются для контроля состояние – например, включен свет или выключен, достигла жидкость нужного уровня или нет, включено реле или нет, и т.д.

ANALOG INPUT REGISTERS

Под этим обычно имеются в виду аналоговые входы (Analog Inputs ). Аналоговые входы можно только читать, т.е их нельзя записывать, а можно только считать текущее состояние налогового входа. Обычно аналоговые входы применяются на сенсорах для измерение некоторых значений: входного тока или входного напряжения. Затем, полученное значение можно конвертировать в некоторую реальную величину, например в температуру, влажность воздуха, давление или еще что то. Для этого используются специальные формулы, которые идут вместе с сенсором. Но чаще сенсор сразу возвращает реальное значение. Например, сенсор измеряющий температуру, может возвращать измеренное значение как градусы по Цельсию умноженные на 10. Т.е. 253 означает 25.3°С. Этот прием часто используется, если нужно вернуть дробные значения через целочисленный регистр.

ANALOG OUTPUT HOLDING REGISTERS

Под этим обычно имеются в виду аналоговые выходы (Analog Outputs ) но так же часто просто регистры, которые хранят некоторые значения, которые можно как записывать, так и считывать. Т.е. эти регистры можно как читать, так и писать. Наиболее часто используются для записи DAC устройств (Digital to Analog Converter) или просто как регистры, хранящие некоторые значения. DAC часто используются для управления чем либо, например: яркостью свечения светодиода, или громкостью сирены, или скоростью вращения двигателя.

Эти регистры 16 битные, т.е. каждый регистр может хранить всего 2 байта.

Вот эти четыре типа регистров поддерживаются в стандартном Modbus . И используя только их, нужно строить систему. Если взглянуть с точки зрения конечного устройства (slave device), то регистры логичнее всего использовать для следующих нужд:

Coils – для управления устройствами через цифровые порты вывода или булевыми флагами типа включен/выключен, открыт / закрыт и т.д.

Contacts – для хранения значений булевых флагов или для отображения информации с цифровых входов.

Inputs –для значений, которые нужно только читать на стороне мастера, и которые могут быть представлены как 16 битные целые числа. Например, входы ADC, или какие о значения, генерируемые системой которые нужно читать (например количество запущенных процессов или внутренняя температура устройства может быть считана через некий Input регистр)

Holding – эти регистры можно использовать для хранения конфигурации устройства, для управления DAC устройствами, для хранения некоторой служебной информации. В принципе, эти регистры можно использовать для чего угодно, на что хватит фантазии разработчика системы.

Кроме того, каждый регистр в схеме Modbus может иметь уникальный адрес, который определяется типом регистра. Посмотрите таблицу ниже:

Как видно из таблицы, каждый тип регистров может вмещать максимум 9999 регистров. Но все они начинаются с некоторого смещения: 0, 10000, 30000, 40000.

На самом деле, внутри команд протокола Modbus , используется не полный адрес, а только его смещение относительно базового адреса. Т.е. для всех типов регистров реальный адрес внутри команды будет 0 -9998. А команда определяет какой именно базовый адрес может быть использован.

Проще всего представить себе, что устройство хранит 4 массива элементов по 9999 элементов в каждом. Индекс внутри массива – это и есть адрес, который задается внутри команды. А команда определяет, какой массив нужно использовать.

Если внимательно посмотреть на таблицу, то видно, что при желании можно использовать больше адресов для Holding регистров: 40001 – 105537, т.е. всего 65535 регистров. То же самое для Contacts : 10001 – 29999, т.е. всего 19999. Это так называемые расширенные регистры. Они не поддерживаются стандартными Modbus устройствами. Поэтому, если вы хотите, что бы ваше устройство могло работать со стандартными клиентами, то не нужно использовать расширенные регистры.

Но если вы уверены, что ваше устройство будет работать с вашим мастером, который знает как работать с расширенными регистрами, или вы точно знаете, что мастер устройство, которое будет использоваться для вашего продукта знает о расширенных регистрах, тогда используйте их.

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

Адресация Modbus устройств

Для адресации устройств используется специальный идентификатор, который называется Slave Id . Это однобайтное значение, которое определяет уникальный адрес устройства на всей сети Modbus . По стандарту Modbus это может быть число от 1 до 247. Т.е. всего в сети может находиться 247 конечных устройств (slave device) с уникальными адресами.

Когда мастер посылает команду в сеть, первый байт – это Slave Id . Это позволяет устройствам уже после первого байта определить, должны они обрабатывать команду, или могут ее проигнорировать. Это справедливо для Modbus RTU . Для Modbus TCP протокола используется Unit Id значение. Хотя если разобраться, это просто другое название Slave Id . Unit Id – это так же однобайтный адрес устройства, от 1 до 247.

Это очень сильно ограничивает количество устройств, которые одновременно могут находиться в сети. Поэтому есть вариант, когда используется 2 байта для адресации устройств. В таком случае количество устройств увеличивается до 65535. Этого более чем достаточно. Но есть одно условие. Мастер и Конечное устройство должны использовать 2 байте для адресации. Т.е. они должны быть настроены, что бы использовать одинаковую схему адресации устройств: 1 или 2 байта. Так же, все устройства в сети должны использовать ту же самую схему адресации – 1 или 2 байта. Не может быть в сети устройств с разной схемой адресации.

Функции Modbus

Для того, что бы запросить данные или записать их, мастер должен указать функции, которую он хочет исполнить на конечном устройстве. Все доступные функции в стандартном Modbus протоколе приведены ниже:

Каждая функция будет рассмотрена позже, подробно и с примерами.

CRC 16 как способ избежать ошибок

Каждая команда в Modbus RTU протоколе заканчивается двумя байтами, которые содержать CRC16 значение всех байт команды. Добавление CRC16 позволяет найти поврежденные запросы и игнорировать их. Так как для вычисления контрольной суммы используется каждый байт в команде, то даже изменение одного бита в любом байте вызовет расхождение в переданной контрольной сумме и вычисленной на основе полученных байт. Это достаточно надежный способ обезопасить передаваемые данные от повреждений (имеется в виду, найти поврежденные данные). Клиент, как и мастер, должны проверять CRC16 из полученной команды с CRC16 сгенерированным на основе полученных байт. Если контрольные суммы не совпадают, значит полученный запрос содержит поврежденные байты, что искажает смысл посланной команды. Такая команда должна быть проигнорирована.

Нужно заметить, CRC16 не используется в Modbus TCP протоколе. Так как TCP пакеты уже имеют свою встроенную контрольную сумму и проверяются на целостность данных, нет никакой необходимости для вычисления CRC16.

Еще в одной разновидности Modbus протокола, Modbus ASCII , используется LRC (Longitudinal Redundancy Check) вместо CRC16. LRC намного проще чем CRC16 и результатом является 1 байт. LRC менее надежно для детектирования ошибок повреждения данных, но исторически так сложилось что Modbus ASCII использует именно этот метод.

О том, как вычислять CRC16 для Modbus RTU протокола и LRC для Modbus ASCII протокола, я напишу отдельно.

Типы данных, которые хранятся в регистрах.

Поговорим о том, какие данные могут храниться в регистрах. Самый простой случай – это Coil и Contac регистры. В этих регистрах может храниться 1 бит информации – 0 или 1. Когда мастер читает эти регистры, он получает в результате 0 или 1. Для записи регистров используются специальные константы:

0xFF00 – означает логическую 1

0x0000 – означает логический 0

Если используется команда для записи нескольких регистров, то каждый регистр будет записан при помощи 1 бита: 0 или 1.

Все остальные регистры – это 16 битные данные (2 байта)

И вот тут самое интересное.

Интерпретация данных должна быть задана в описании Modbus регистров (так называемом Modbus Map документе). В этом документе нужно точно прописать, какой регистр хранит какие джанные, и какие значение для него приемлемы.

Начнём с простых случаев.

Если мы считываем 1 Input или Holding регистр, то мы получаем 16 бит данных. Например, это может быть значение 0x8D05 – два байта 0x8D и 0x05 .

В самом простом случае это может быть без знаковое целое значение: 36101

Но это может быть целое число со знаком: -29435

Другой пример. Мы прочитали значение 0x4D4F

Это может быть как целое без знака, целое со знаком, так и 2 символа в кодировке ASCII:

0x4D = M

0x4F = O

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

К примеру, мы прочитали 2 регистра, и получили следующие данные: 0xAE53 0x544D

Это может быть:

32 битное целое без знака

0xAE53 0x544D = 2924696653

32 битное целое со знаком

0xAE53 0x544D = -1370270643

32 битный float – число с плавающей точкой

0xAE53 0x544D = -4.80507e-11

Или хранить 4 символа в кодировке ASCII

0xAE53 0x544D = 0xAE 0x53 0x54 0x4D = ®STM

Если продолжать, то комбинируя больше регистров, можно хранить 64 битные значения, 128 битные значения, строки и в принципе любые типы данных.

Но, комбинируя регистры, у нас встает следующий вопрос:

Порядок байт и слов

К сожалению протокол Modbus не определяет как должны храниться байты внутри регистра. Т.е. различные устройства от различных производителей могут хранить байты в произвольном порядке.

Например, читая регистр, мы получили значение 0xA543

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

Если использовался Big Endian формат (старший байт первый), то у нас будет значение 42307

Но если использовался Little Endian формат (младший байт первым), то у нас будет значение 17317

Еще интереснее, когда мы формируем 32 битное значение из двух регистров.

Вариантов комбинации байтов становится 4. К примеру 32 битное число 4014323619 (0xEF45B7A3 ) может быть передано 4 следующими последовательностями байтов:

0xEF45 0xB7A3

0x45EF 0x A3B7

0xB7A3 0xEF45

0x A3B7 0x45EF

На самом деле это не важно, какой порядок байт / слов реализован на конечном устройстве. Главное, мастер должен знать этот порядок, и уметь формировать правильные значения из полученных байтов. Зная точный формат данных на конечном устройстве, мастер всегда будет правильно формировать значения регистров. И именно для этого существует такое понятие как Modbus Map (Карта Modbus ).

Modbus Map

Modbus Map – это документация, которая полностью описывает все возможные Modbus регистры на устройстве, их адреса, назначение, доступные значения, значения по умолчанию, способ доступа.

Некоторые устройства поставляются с фиксированным описанием регистров. Т.е. список регистров, их адресов, хранимых данных и т.д. жестко задан производителем и описан в документации.

А есть настраиваемая конфигурация. Т.е. на устройстве нет фиксированных адресов для регистров. Пользователь может сконфигурировать Modbus Map так, как ему нужно (например соединив некоторые регистры в непрерывную последовательность адресов, что бы считывать их одной командой).

Пример фиксированного Modbus Map , который имеет смысл применять для своих устройств, может выглядеть так, как в таблице ниже.

Чего не может Modbus

Modbus очень простой протокол, поэтому он поддерживает далеко не все, что может потребоваться.

Modbus не поддерживает сообщения (events). Т.е. конечное устройство не может послать сообщение мастеру. Только мастер может опросить конечное устройство.

Modbus не поддерживает чтение исторических данных (накопленных за некоторый промежуток времени). Хотя это ограничение можно легко обойти, создав командные регистры, регистры адреса и перегружаемые регистры. Это будет обсуждаться в одной из следующих статей.

Стандартный Modbus не может хранить сложные структурированные данные (по крайней мере это не так просто реализовать).

Кроме того, Modbus не поддерживает идентификации и шифрования. Т.е вся коммуникация идет в незащищённом режиме. Хотя, при некотором желании можно реализовать некоторое подобие идентификации в Modbus TCP в большинстве случаев это сделать невозможно. Есть некоторые варианты как защитить данные от несанкционированного доступа и изменения, но они все не очень надежные (хотя и могут применятся). Я опишу их в следующих статьях.

И кажется, это все явные недостатки для этого протокола. В остальном он очень прост и отлично подходит для простых систем мониторинга, которые должны следить за некоторыми показателями системы и предоставлять доступ к ним через чтение регистров.

В следующей статье мы рассмотрим все основные функции, которые поддерживаются протоколом Modbus .

В уроке 48 я показал пример нестандартного протокола обмена данными через интерфейс UART. Как всегда все нестандартное позволяет оптимизировать выполнение задачи, а все универсальное упрощает разработку задачи.

Существует простой универсальный протокол обмена ModBus, в котором избыточность данных и функций сведена к минимуму. Наверное, это самый распространенный протокол для организации малых распределенных систем. В последующих уроках обмен данными между устройствами я буду реализовывать по этому протоколу.

Общее описание протокола.

ModBus – открытый протокол обмена данными в малых локальных сетях. Как правило, используется для передачи данных через интерфейсы RS-232, RS-485, RS-422, в сетях TCP/IP, UDP. Благодаря своей простоте и универсальности ModBus получил широкое распространение и стал де факто стандартом в малых распределенных вычислительных системах. Практически все современные контроллеры поддерживают работу в сетях ModBus.

В сети ModBus контроллеры, как правило, соединены по топологии ”Общая шина”. Взаимодействие контроллеров происходит в соответствии с моделью master-slave (ведущий-ведомый).

В сети есть главное устройство - ведущее. А также несколько подчиненных устройств – ведомые. Обмен может быть инициирован только ведущим устройством.

Транзакция (последовательность операций при обмене данными) состоит из запроса и ответа.

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

Ведомое устройство, определив свой адрес в запросе, формирует ответ.

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

Существуют 3 варианта протокола ModBus.

• ModBus ASCII – текстовый протокол. В нем используются только ASCII символы. Каждый байт передается как два шестнадцатеричных символа.
• ModBus RTU – числовой протокол. Данные передаются в двоичном виде. Байт, передаваемый по сети это число протокола.
• ModBus TCP – протокол для передачи данных в TCP/IP сетях.

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

Протокол ModBus RTU.

В сети по топологии ”Общая шина” подключены устройства (контроллеры). Стандарт ModBus допускает совместную работу до 247 контроллеров.

В каждом контроллере есть данные, собственно говоря, которыми и обмениваются устройства.

Стандарт ModBus определяет 4 типа данных.

Такое функциональное разделение данных стерлось и практически не используется. Все данные в итоге считываются из памяти контроллера и не так важно, откуда они попали в нее со входов или из регистров ввода.

На практике используются только данные Регистры хранения (Holding Registers). Доступ к данным осуществляется через 16 битный адрес. В итоге:

• данные в каждом контроллере представляют собой таблицу 16 битных регистров;
• в таблице данных может быть до 65536 элементов;
• нумерация элементов начинается с 0.

Ведущее устройство инициирует транзакцию – обмен данными. Транзакция может быть индивидуальной (запрос-ответ) или широковещательной (адресуются одновременно все ведомые устройства). Транзакция состоит из одного кадра запроса и одного кадра ответа. При широковещательной транзакции используется только кадр запроса.

Данные кадра передаются сплошным потоком. Пауза между передачей данных не должна превышать время передачи 1,5 символа. Признаком нового кадра является отсутствие обмена в сети (молчание) в течение времени необходимого на передачу 3,5 символов. Если в течение этого времени линия сети находилась в неактивном состоянии, то ведомые устройства воспринимают первое принятое данное как начало кадра.

В общем случае кадр запроса имеет следующий формат.

Адрес (8 бит).

Кадр начинается с поля адреса, которое состоит из 8 разрядов. Содержит адрес ведомого устройства, которому предназначено сообщение от ведущего. Каждое ведомое устройство должно иметь уникальный адрес от 1 до 247. И только адресуемое ведомое устройство должно ответить на запрос ведущего. В ответе сообщается ведущему устройству, с каким из ведомых установлена связь.

Адрес 0 используется в широковещательном режиме. Все ведомые устройства выполняют заданную в запросе функцию, но подтверждение не посылают.

Функция (8 бит).

Поле функции сообщает адресуемому ведомому устройству, какую операцию выполнить.

Старший бит байта функция устанавливается в 1 в ответе ведомого устройства, чтобы сообщить ведущему, что операция была выполнена с ошибкой. При успешной операции старший бит равен 0.

• Стандартные команды. Коды, определенные стандартом на протокол ModBus.
• Пользовательские команды. Для кодов 65…72 и 100…110 пользователь может сам назначить произвольную функцию.
• Зарезервированные команды. Это коды, которые не были изначально определены стандартом, но уже используются в устройствах разных производителей.

Подавляющее большинство ModBus контроллеров используют только 3 функции.

Формат ответа зависит от функции. Во многих случаях нормальный ответ полностью или частично повторяет запрос.

Данные (N * 8 бит).

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

Каждое данное имеет 16 разрядов (2 байта). Данные передаются старшим байтом вперед. Например, последовательная передача регистров с адресами 0 и 1 должна происходить следующим образом:

• старший байт регистра 0 ->
• младший байт регистра 0 ->
• старший байт регистра 1 ->
• младший байт регистра 1 ->.

При передаче 4х байтового числа, например, с плавающей запятой последовательность та же. Число разбивается на два 16 разрядных регистра и в каждом из них первым передается старший байт (1-> 0-> 3-> 2->).

Контрольная сумма (16 бит).

Поле контроля целостности данных сообщений. Позволяет проверять кадры на наличие ошибок. Речь идет об ошибках, появляющихся при передаче данных.

Я постараюсь в общих чертах рассказать о контрольном коде. Лучше пропустить этот параграф. Может голова треснуть. У меня, когда я затрагиваю эту тему – всегда трещит. В следующем уроке я представлю практическую реализацию вычисления контрольного кода ModBus.

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

Используется полиноминальная арифметика по модулю 2. Это означает, что все действия при вычислении CRC это арифметические операции без переноса. Вычитание и сложение происходят побитно, без учета переноса из-за чего эти операции дают одинаковый результат и могут быть заменены операцией ”исключающее или”. При делении вместо вычитания делителя из делимого также используется операция ”исключающее или”. Это общий принцип вычисления CRC. Практически вычисления производятся с помощью более эффективных алгоритмов.

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

Стандарт ModBus RTU использует стандартный циклический код CRC-16 с порождающим полиномом X 16 +X 15 +X 2 +1. Это 16ти разрядный код, двоичные коэффициенты 1 1000 0000 0000 0101 (8005h в шестнадцатеричном представлении).

Сообщение рассматривается как одно последовательное двоичное число, в котором старший бит передается первым. Это число умножается на X 16 (сдвиг влево на 16 разрядов), и делится на X 16 +X 15 +X 2 +1 (1 1000 0000 0000 0101). 16ти битный остаток (предварительно инициализированный всеми единицами) и есть контрольный код сообщения.

Обработка логических ошибок.

Кроме ошибок, связанных с искажением данных при передаче могут быть логические ошибки, когда запрос принят без ошибок, но не может быть выполнен. Как правило, такие ошибки связаны с недопустимым адресом, данными, кодами и т.п. Большинство ModBus контроллеров поддерживают следующие типы ошибок.

При возникновении ошибки в ответе в поле код функции взводится старший бит и следом вместо обычных данных передается код ошибки.

Детальное рассмотрение функций.

Функция 03 – чтение регистров хранения.

Используется для чтения значений нескольких регистров хранения. В запросе передается адрес первого элемента таблицы регистров, значение которого необходимо прочитать и количество считываемых регистров. Для адреса и количества используются 16ти разрядные числа. Старший байт передается первым.

Запрошенные данные содержатся в ответе. Перед блоком данных передается байт, который содержит число прочитанных данных в байтах.

Формат запроса функции чтения регистров хранения.

Ответ (адрес ведомого, код функции, количество прочитанных байтов, значения регистров).

Функция 06 – запись в один регистр хранения.

Используется для записи в единичный регистр. В запросе передается адрес регистра и значение для него. При успешном выполнении ведомый контроллер в ответе передает копию запроса.

Формат запроса функции записи одного регистра хранения.

Ответ (повторяет запрос).

Функция 16 – запись значений в регистры хранения.

Используется для записи в несколько, последовательно расположенных в таблице, регистров.

В запросе передается адрес первого регистра, количество регистров и значения для них.

В ответе возвращается начальный адрес и количество измененных регистров.

Формат запроса функции записи регистров хранения.

Ответ (адрес ведомого, код функции, начальный адрес и количество регистров).

ModBus и специализированные протоколы.

Теперь можете сравнить протокол ModBus со специализированном протоколом из .

По сравнению со специализированным протоколом:

• ModBus медленнее, его производительность ниже. Для получения такого же количества информации по сети передается намного больше данных.
• Реализация его сложнее. Требуется больше ресурсов микроконтроллера и сети.

Но достоинства во многих случаях весомее.

• За счет более сложной контрольной суммы и избыточности информации ошибки сети определяются в нем надежнее, выше достоверность данных.
• Сеть легко расширяется. Очень просто добавлять новые устройства.
• ModBus – стандартный протокол. Множество контроллеров различных производителей поддерживают его.

Пожалуй, главная причина применения нестандартных протоколов – это недостаточность вычислительных ресурсов системы.

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

В следующем уроке будем реализовывать связь платы Ардуино и компьютера по протоколу ModBus.

Пришло время рассмотреть еще одну вариацию протокола Modbus – Modbus ASCII . Эта версия протокола использует для передачи данных только символы ASCII, которыми кодирует шестнадцатеричное представление бинарных данных. Немного не понятно и запутано? Это ничего, welcome под кат и давайте рассмотрим, с чем же мы имеем дело.

Разделитель пакетов

Первое отличие протокола Modbus ASCII от Modbus RTU – у него есть разделитель между пакетами. Если в Modbus RTU все пакеты шли один за одним (практически, там должна быть небольшая задержка на линии между пакетами, порядка 2-5мс), то в Modbus ASCII каждый новый пакет должен начинаться со специального символа разделителя.

По стандарту Modbus RTU между пакетами нужна задержка в 3.5 символа (это время, которое нужно для передачи 3.5 символов по линии связи, зависит от скорости передачи). Эта задержка используется, что бы детектировать новый запрос от мастера. Т.е. эта задержка указывает начало нового запроса. Но когда стали использовать модемы, это перестало работать. На модеме невозможно выдержать нужное время. Поэтому решили использовать новый вариант протокола — Modbus ASCII . Этот вариант устраняет многие неудобства при работе с модемом: есть специальный символ разделитель пакетов и используются только видимые символы ASCII.

Так вот, таким символом начала пакета служит символ двоеточие с шестнадцатеричным кодом 0x3A . А конец каждого пакета помечается символами новой строки и перевода каретки – 0x0D 0x0A . Таким образом, из протокола полностью убирается зависимость от задержек между байтами. Т.е. если модем задержит байт, это не вызовет недопонимания на стороне клиента. И он будет ждать окончания пакета байтами 0x0D 0x0A . А если встретит символ разделителя 0х3А – сбросит буфер и начнем формировать пакет заново. Кроме того нет необходимости в экранировании спец символов модема, так как данные не используют символы из начальной секции ASCII таблицы.

Представление байтов данных

В Modbus ASCII протоколе каждый байт данных представлен в виде 2 байтов. Каждый байт представляет собой ASCII символ в шестнадцатеричном представлении. Что бы легче было понять, приведем пример:

Немного объяснений для таблицы.

Например, нам нужно передать байт данных, который хранит символ # . Этот символ имеет в таблице ASCII шестнадцатеричный код 0x23 . В протоколе Modbus RTU мы просто передаем байт со значением 0x23 .

Если мы хоти передать тот же символ через протокол Modbus ASCII , нам нужно уже передавать 2 байта. На первом этапе мы получаем шестнадцатеричный код символа, 0x23 . На втором этапе мы кодируем это значение при помощи двух символов ASCII – 2 и 3 . И на третьем этапе мы передаем два байта данных, первый — это шестнадцатеричное значение символа 2 , второй байт — это шестнадцатеричное значение символа 3 .

Таким образом, диапазон значений для байта данных в протоколе Modbus RTU – 0 .. 0xFF

Диапазон значений для байта данных в протоколе Modbus ASCII – только символы, необходимые для отображения шестнадцатеричных цифр, т.е. 0 – 9, A, B, C, D, E, F (все заглавные).

Контрольная сумма для Modbus ASCII

В протоколе Modbus RTU используется 2 байтная контрольная сумма, которая помогает детектировать поврежденные запросы. В протоколе Modbus ASCII так же есть контрольная сумма – LRC (Longitudinal Redundancy Check) .

Вычисление LRC намного проще, чем вычисление CRC . Что бы высчитать LRC вам нужно сделать следующие:

• Сложить вместе все байты в сообщении Modbus ASCII , до того, как они сконвертированы в в символы ASCII. Не включаются в вычисления стартовый символ двоеточия и завершающие символы CR/LF .
• Обнулить все биты больше 8 (т.е. оставить младший байт)
• Сделать результирующий байт отрицательным чтобы получить LRC байт

Таким образом, если затем сложить все байты пакета данных и байт LRC мы получим в результате 0. Это и есть самая быстрая проверка корректности пакета данных.

Ниже приведен пример вычисления LRC для конкретного запроса Modbus ASCII .

Для примера возьмем запрос на чтение регистров #40108 — #40110 с устройства с адресом 17

Теперь посчитаем сумму всех байт

Вот это отрицательное число (-130 или 0x7E ) и есть LRC запроса.

Эта контрольная сумма добавляется к запросу в виде 2 ASCII символов – 7 и E .

Т.е. в конце запроса нужно добавить 2 байта со значением 37 и 45 .

Примеры Modbus RTU и Modbus ASCII запросов

Что бы лучше понять, как все это работает, посмотрите пару простых примеров.

Возьмем наш запрос на чтение регистров #40108 — #40110 с устройства с адресом 17

Это Modbus RTU запрос без последних двух байтов CRC . Теперь преобразуем этот запрос из Modbus RTU в Modbus ASCII . Для этого добавляем в начало запроса символ двоеточия, в конец запроса символ перевода строки и возврата каретки, а каждый байт представим в виде ASCII символов, соответствующих шестнадцатеричному представлению каждого байта запроса. В итоге у нас получиться такой запрос (в виде ASCII символов, или попросту в виде текстовой строки). Так же в конец запроса добавляем LRC .

Теперь просто нужно передать данный запрос в порт, используя коды ASCII символов. В бинарном виде запрос будет выглядеть так: