Описание протокола Modbus. Протокол Modbus: структура сообщения
Структура сообщения протокола Modbus имеет следующий вид:
- адрес ведомого устройства – это адрес устройства, которому адресовано данное сообщение протокола Modbus. Устройства отвечают только на те сообщения, которые адресованы именно им. Ответ начинается с адреса ведомого устройства. Адрес изменяется в пределах 1…247. Адрес 0 в сообщении протокола Modbus зарезервирован под широковещательные сообщения, 248..255 – зарезервированные адреса.
- номер функции – 1 байт данных.
- данные – это поле содержит информацию о функции, которую нужно выполнить, либо данные, которые ведомое устройство посылает мастеру протокола Modbus.
- блок обнаружения ошибок (CRC) – контрольная сумма, которая вычисляется со всех предыдущих байт путем алгоритма циклического сдвига и побитового исключения.
Необходимо обратить внимание, что при чтении по протоколу Modbus в одном сообщении можно считывать значение дискретных или аналоговых входов и выходов, расположенных подряд, то есть задать адрес первого значения и их количество.
Рассмотрим основные стандартные функции по их кодам (в десятичном и шестнадцатеричном формате):
1 (0х01) – чтение нескольких дискретных выходов
2 (0х02) - чтение нескольких дискретных входов
3 (0х03) - чтение нескольких промежуточных регистров или аналоговых выходов
4 (0х04) – чтение нескольких аналоговых входов
Если, например, количество дискретных входов, которые сформированы в запросе, не кратно восьми, то количество байт значений округляется в большую сторону и, соответственно, для получения, например, значений 15 дискретных входов, это количество будет равно двум байтам.
Перед данными сообщения Modbus передается один байт, значение которого - количество байт данных.
5 (0x05) - запись значения одного дискретного выхода
6 (0x06) - запись значения одного аналогового выхода или регистра
Команда Modbus состоит из адреса и собственно значения (2 байта). Нормальный ответ – повтор запроса протокола Modbus.
15 (0x0F) - запись значений в нескольких дискретных выходов
16 (0x10) - запись значений нескольких аналоговых выходов или регистров
Ответ состоит из начального адреса регистра и количества измененных значений.
Пример запроса/ответа протокола Modbus:
Ошибки при передаче делятся на 2 типа – искажение при передаче и логические. Искажение отслеживается по времени «тишины». Нормальное время между сообщениями – время, необходимое на передачу 3,5 символов. Если во время передачи сообщения протокола Modbus возникла пауза длинной более 1,5 символа, пакет отбрасывается.
Логические ошибки протокола Modbus возникают, если slave не может принять сообщение вообще, либо принимает его, но выдает ошибку. В таком случае ошибка диагностируется по тайм-ауту. Slave принимает запрос, но не может его обработать (к примеру, обращение к несуществующему адресу) – в таком случае отсылается сообщение об ошибке.
Пример сообщения Modbus об ошибке на запрос:
Стандартные коды ошибок протокола Modbus:
01 -Функция не может быть обработана на slave.
02 - Несуществующий адрес данных.
03 - Значение в поле данных для запроса, является недопустимым для salve.
04 - Произошла необратимая ошибка, пока slave пытался выполнить действие.
05 - Slave принял запрос и начал обрабатывать его, но на это потребуется время. Этот код предохраняет master от выдачи ошибки тайм-аута.
06 - Slave занят обработкой команды.Master должен повторить посылку сообщения позже, когда slave будет свободен.
07 -Slave не может выполнить функцию из запроса. Master должен послать запрос об диагностической информации или получить информацию об ошибках со slave.
08 - Slave пытается считать область памяти, но при этом обнаружена ошибка паритета. Master может повторить запрос, но обычно в таких случаях требуется ремонт.
Структура кадра Modbus TCP:
Где:
ID транзакции - два байта
ID протокола - два байта (четыре нуля)
длина пакета - два байта, размер последующих полей сообщения
адрес ведомого устройства - адрес slave, которому адресован запрос протокола Modbus.
Особенность протокола Modbus TCP – отсутствие контрольной суммы, так как на транспортном уровне протокола TCP происходит проверка CRC. Поэтому проверка контрольной суммы в формате RTU не имеет смысла.
) для использования в её контроллерах с программируемой логикой . Впервые спецификация протокола была опубликована в 1979 году. Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети состоящей из различных электронных устройств.
Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232. Позднее стал применяться интерфейс RS-485, так как он обеспечивает более высокую надёжность, позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.
Многие производители электронного оборудования поддержали стандарт, на рынке появились сотни использующих его изделий. В настоящее время развитием Modbus занимается некоммерческая организация Modbus-IDA , созданная производителями и пользователями электронных приборов .
Введение
Modbus относится к протоколам прикладного уровня сетевой модели OSI . Контроллеры на шине Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях , состоящих из запроса и ответа.
Обычно в сети есть только один клиент, так называемое, «главное» (англ. master ) устройство, и несколько серверов - «подчиненных» (slaves ) устройств. Главное устройство инициирует транзакции (передаёт запросы). Подчиненные устройства передают запрашиваемые главным устройством данные, или производят запрашиваемые действия. Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство формирует сообщение и возвращает его в ответ на запрос, адресованный именно ему. При получении широковещательного запроса ответное сообщение не формируется.
Спецификация Modbus описывает структуру запросов и ответов. Их основа - элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1...127. Диапазон значений 128...255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.
| номер функции | данные |
|---|---|
| 1 байт | N < 253 (байт) |
Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи.
Существуют три основных реализации протокола Modbus, две для передачи данных по последовательным линиям связи, как медным EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485), так и оптическим и радио:
- Modbus ASCII,
и для передачи данных по сетям Ethernet поверх TCP/IP :
- Modbus TCP.
Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):
- адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248...255 - зарезервированы;
- номер функции - это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;
- данные - поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;
- блок обнаружения ошибок - контрольная сумма для проверки отсутствия ошибок в кадре.
Максимальный размер ADU для последовательных сетей RS232/RS485 - 256 байт, для сетей TCP - 260 байт.
Для Modbus TCP ADU выглядит следующим образом:
- ид транзакции - два байта, обычно нули
- ид протокола - два байта, нули
- длина пакета - два байта, старший затем младший, длина следующей за этим полем части пакета
- адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с бриджом, который выводит нас, например, в сеть RS485.
Поле контрольной суммы в Modbus TCP отсутствует.
Категории кодов функций
В действующей в настоящее время спецификации протокола определяются три категории кодов функций:
Стандартные команды Их описание должно быть опубликовано и утверждено Modbus-IDA. Эта категория включает в себя как уже определенные, так и свободные в настоящее время коды. Пользовательские команды Два диапазона кодов (от 65 до 72 и от 100 до 110), для которых пользователь может реализовать произвольную функцию. При этом не гарантируется, что какое-то другое устройство не будет использовать тот же самый код для выполнения другой функции. Зарезервированные В эту категорию входят коды функций, не являющиеся стандартными, но уже используемые в устройствах, производимых различными компаниями. Это коды 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 и 127.
Модель данных
Одно из типичных применений протокола - чтение и запись данных в регистры контроллеров. Спецификация протокола определяет четыре таблицы данных:
Доступ к элементам в каждой таблице осуществляется с помощью 16-битного адреса, первой ячейке соответствует адрес 0. Таким образом, каждая таблица может содержать до 65536 элементов. Спецификация не определяет, что физически должны представлять собой элементы таблиц и по каким внутренним адресам устройства они должны быть доступны. Например, допустимо организовать перекрывающиеся таблицы, В этом случае команды работающие с дискретными данными и с 16-битными регистрами будут фактически обращаться к одним и тем же данным.
Следует отметить, что со способом адресации данных связана определённая путаница. Modbus был первоначально разработан для контроллеров Modicon. В этих контроллерах для каждой из таблиц использовалась специальная нумерация. Например, первому регистру ввода соответствовал номер ячейки 30001, а первому регистру хранения - 40001. Таким образом, регистру хранения с адресом 107 в команде Modbus соответствовал регистр № 40108 контроллера. Хотя такое соответствие адресов больше не является частью стандарта, некоторые программные пакеты могут автоматически «корректировать» вводимые пользователем адреса, например, вычитая 40001 из адреса регистра хранения.
Стандартные функции протокола Modbus
| номер функции |
запрос/ответ | |||||
|---|---|---|---|---|---|---|
| 1 (0x01) | A 1 | A 0 | Q 1 | Q 0 | ||
| N | D (N байт) | |||||
| 2 (0x02) | A 1 | A 0 | Q 1 | Q 0 | ||
| N | D (N байт) | |||||
| 3 (0x03) | A 1 | A 0 | Q 1 | Q 0 | ||
| N | D (N байт) | |||||
| 4 (0x04) | A 1 | A 0 | Q 1 | Q 0 | ||
| N | D (N байт) | |||||
| 5 (0x05) | A 1 | A 0 | D 1 | D 0 | ||
| A 1 | A 0 | D 1 | D 0 | |||
| 6 (0x06) | A 1 | A 0 | D 1 | D 0 | ||
| A 1 | A 0 | D 1 | D 0 | |||
| 15 (0x0F) | A 1 | A 0 | Q 1 | Q 0 | N | D (N байт) |
| A 1 | A 0 | Q 1 | Q 0 | |||
| 16 (0x10) | A 1 | A 0 | Q 1 | Q 0 | N | D (N байт) |
| A 1 | A 0 | Q 1 | Q 0 | |||
- A 1 и A 0 - адрес элемента,
- Q 1 и Q 0 - количество элементов,
- N - количество байт данных
- D - данные
Чтение данных
Для чтения значений из перечисленных выше таблиц данных используются функции с кодами 1-4 (шестнадцатеричные значения 0x01-0x04):
- 1 (0x01) - чтение значений из нескольких регистров флагов (Read Coil Status)
- 2 (0x02) - чтение значений из нескольких дискретных регистров (Read Discrete Inputs)
- 3 (0x03) - чтение значений из нескольких регистров хранения (Read Holding Registers)
- 4 (0x04) - чтение значений из нескольких регистров ввода (Read Input Registers)
Запрос состоит из адреса первого элемента таблицы, значение которого требуется прочитать, и количества считываемых элементов. Адрес и количество данных задаются 16-битными числами, старший байт каждого из них передается первым.
В ответе передаются запрошенные данные. Количество байт данных зависит от количества запрошенных элементов. Перед данными передается один байт, значение которого равно количеству байт данных.
Значения регистров хранения и регистров ввода передаются начиная с указанного адреса, по два байта на регистр, старший байт каждого регистра передаётся первым:
| байт 1 | байт 2 | байт 3 | байт 4 | ... | байт N-1 | байт N |
|---|---|---|---|---|---|---|
| R A,1 | R A,0 | R A+1,1 | R A+1,0 | ... | R A+Q-1,1 | R A+Q-1,0 |
Значения флагов и дискретных входов передаются в упакованном виде: по одному биту на флаг. Единица означает включённое состояние, ноль - выключенное. Значения запрошенных флагов заполняют сначала первый байт, начиная с младшего бита, затем следующие байты, также от младшего бита к старшим. Младший бит первого байта данных содержит значение флага, указанного в поле «адрес». Если запрошено количество флагов, не кратное восьми, то значения лишних битов заполняются нулями:
| байт 1 | ... | байт N | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F A+7 | F A+6 | F A+5 | F A+4 | F A+3 | F A+2 | F A+1 | F A | ... | 0 | ... | 0 | F A+Q-1 | F A+Q-2 | ... | |
Запись одного значения
- 5 (0x05) - запись значения одного флага (Force Single Coil)
- 6 (0x06) - запись значения в один регистр хранения (Preset Single Register)
Команда состоит из адреса элемента (2 байта) и устанавливаемого значения (2 байта).
Для регистра хранения значение является просто 16-битным словом.
Для флагов значение 0xFF00 означает включённое состояние, 0x0000 - выключенное, другие значения недопустимы.
Если команда выполнена успешно, ведомое устройство возвращает копию запроса.
Запись нескольких значений
- 15 (0x0F) - запись значений в несколько регистров флагов (Force Multiple Coils)
- 16 (0x10) - запись значений в несколько регистров хранения (Preset Multiple Registers)
Команда состоит из адреса элемента, количества изменяемых элементов, количества передаваемых байт устанавливаемых значений и самих устанавливаемых значений. Данные упаковываются так же, как в командах чтения данных.
Ответ состоит из начального адреса и количества изменённых элементов.
Ниже приведён пример команды ведущего устройства и ответа ведомого (для Modbus RTU).
Контроль ошибок в протоколе Modbus RTU
Во время обмена данными могут возникать ошибки двух типов:
- ошибки, связанные с искажениями при передаче данных;
- логические ошибки.
Ошибки первого типа обнаруживаются при помощи фреймов символов, контроля чётности и циклической контрольной суммы CRC -16-IBM (используется число-полином = 0xA001).
RTU фрейм
В RTU режиме сообщение должно начинаться и заканчиваться интервалом тишины - временем передачи не менее 3.5 символов при данной скорости в сети. Первым полем затем передаётся адрес устройства.
Вслед за последним передаваемым символом также следует интервал тишины продолжительностью не менее 3.5 символов. Новое сообщение может начинаться после этого интервала.
Фрейм сообщения передаётся непрерывно. Если интервал тишины продолжительностью 1.5 возник во время передачи фрейма, принимающее устройство должно игнорировать этот фрейм как неполный.
Таким образом, новое сообщение должно начинаться не раньше 3.5 интервала, т.к. в этом случае устанавливается ошибка.
Немного об интервалах (речь идёт о Serial Modbus RTU): при скорости 9600 и 11 битах в кадре (стартовый бит + 8 бит данных + бит контроля чётности + стоп-бит): 3.5 * 11 / 9600 = 0,00401041(6), т.е. более 4 мс; 1.5 * 11 / 9600 = 0,00171875, т.е. более 1 мс. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс соответственно.
Логические ошибки
Для сообщений об ошибках второго типа протокол Modbus RTU предусматривает, что устройства могут отсылать ответы, свидетельствующие об ошибочной ситуации. Признаком того, что ответ содержит сообщение об ошибке, является установленный старший бит кода команды. Пример кадра при выявлении ошибки ведомым устройством, в ответ на запрос приведён в (Таблица 2-1).
1. Если Slave принимает корректный запрос и может его нормально обработать, то возвращает нормальный ответ.
2. Если Slave не принимает какого-либо значения, никакого ответа не отправляется. Master диагностирует ошибку по таймауту.
3. Если Slave принимает запрос, но обнаруживает ошибку (parity, LRC, or CRC), никакого ответа не отправляется. Master диагностирует ошибку по таймауту.
4. Если Slave принимает запрос, но не может его обработать (обращение к несуществующему регистру и т.д.), отправляется ответ содержащий в себе данные об ошибке.
| Направление передачи | адрес подчинённого устройства | номер функции | данные (или код ошибки) | CRC |
|---|---|---|---|---|
Мы разобрали общую структуру протокола ModBus. Сегодня мы рассмотрим разновидность этого протокола — ModBus TCP, которая используется для реализации ModBus в сетях Ethernet.
ModBus TCP всегда работает поверх TCP/IP стека, поэтому не может считаться полноценным ModBus протоколом в его классическом виде.
Основное отличие, которое накладывает TCP/IP на ModBus при их совместном использовании — непосредственное подключение к определённому адресу. Протокол TCP/IP устроен по принципу «клиент-сервер». Для обмена данными клиент открывает сеанс связи с сервером, указывая его адрес.
Переходя на терминологию протокола ModBus ведущее устройство (мастер) в TCP-сети становится клиентом (т.к. именно клиент является инициатором обмена данными), а подчинённое устройство (слейв) — сервером.
Таким образом, для того чтобы передать запрос подчинённому устройству в TCP-сети мастер должен сначала открыть сеанс связи с ним. Причём открытие сеанса реализуется не на уровне протокола ModBus, а на уровне TCP/IP. Поэтому ведущее устройство не может средствами ModBus передавать запросы разным устройствам, так же, как это происходит в ModBus RTU или ASCII.
По этой же причине в ModBus TCP отсутствуют широковещательные сообщения (сразу всем подчинённым устройствам).
Однако, Master-устройство может подключаться к необходимому узлу (слейву) средствами протокола TCP/IP, а затем уже общаться с ним на языке ModBus.
На рисунке рабочее место диспетчера под управлением SCADA-системы является сервером сбора данных и одновременно мастером в сети ModBus TCP. Оно последовательно подключается к каждому удалённому контроллеру, открывая сеанс связи в сети TCP/IP и обменивается с ним ModBus-пакетами.
Безусловно, такой обмен происходит дольше, чем в случае ModBus RTU, т.к. дополнительное время уходит на открытие и закрытие сеанса TCP/IP. Однако, это даёт возможность объединить устройства находящиеся на значительном удалении витой парой или даже по WiFi.
Кроме того, протокол ModBus TCP может использоваться в сетях со шлюзом, где шлюз является интеллектуальным устройством и маршрутизирует сообщения остальным устройствам сети ModBus.
При такой конфигурации клиент сети TCP (он же мастер сети ModBus) подключается к шлюзу (серверу) и ведёт общение только с ним. Шлюз же переадресует сообщение внутри шины ModBus (RTU или ASCII) тому устройству, адрес которого указан в ModBus-пакете.
Структура пакета ModBus TCP
Сначала вспомним структуру классического ModBus-пакета (RTU или ASCII):
Он состоит из четырёх блоков: адрес слейва, номер функции, блок данных и блок контроля чётности.
А вот так выглядит структура пакета ModBus TCP:
Как вы можете видеть, в пакете ModBus TCP по сравнению с ModBus RTU добавлены блоки идентификаторов обмена и протокола, а так же от отсутствует блок контроля подлинности пакета. Последнее объясняется тем, что контроль целостности пакета обеспечивается средствами протокола TCP/IP, поэтому отпадает необходимость в его ModBus-реализации.
Рассмотрим что означает каждый из блоков пакета ModBus TCP:
- id обмена — чаще всего два нуля. Применяется только в том случае, если мастер отсылает подчинённому устройству несколько запросов подряд без ожидания ответа. При этом id позволяет затем понять какому из запросов какой ответ соответствует.
- id протокола — всегда нули, не применяется. Поле оставлено в качестве резерва для будующих применений.
- длина пакета — совокупная длина блоков «адрес», «номер функции» и «данные». Длина пакета передаётся двумя байтами, первым из которых идет старший.
- адрес ведомого устройства — аналог такого же блока в структуре пакета ModBus RTU, но обычно не используется, т.к. ,как уже говорилось, в ModBus TCP мастер и так открывает сеанс обмена только с одним слейвом (у которого, конечно, есть и IP адрес в сети TCP/IP). Данное поле используется только в варианте ModBus TCP-сети со шлюзом. Тогда шлюз сам перенаправляет пакет по указанному адресу.
- поля код функции и данные аналогичны соответствующим полям в классическом ModBus-пакете.
Ну что же, пора рассмотреть, чем протокол Modbus TCP
отличается от протокола Modbus RTU
. Так как отличий не очень много, то и статья будет не очень большая.
Итак, в предыдущей стать о функциях Modbus RTU
можно узнать, какие есть функции и их бинарный формат. Теперь стоит рассказать что такое Modbus TCP
, как он применяется и чем отличается от стандартного Modbus RTU
.
Modbus RTU через TCP соединение
Самый простой способ обмена Modbus сообщениями через сеть – просто передавать Modbus RTU пакеты через TCP сокет (соединение). В этом случае формат пакетов такой же, как и для Modbus RTU протокола. В принципе на этом можно и закончить по этому типу протокола.
Modbus TCP
Для обмена Modbsu сообщениями по сети решили использовать модифицированный протокол. Взяли стандартный Modbus RTU и немного его изменили. Во-первых убрали из него последних 2 байта CRC16 . Так как каждый пакет TCP/IP содержит свою контрольную суму, решили что делать проверку еще раз не нужно. Кроме того убрали первый байт Slave ID . В принципе, Как будет видно дальше, Его не убрали, а просто переименовали. Вот эти байты, без Slave ID и CRC16 назвали PDU – Protocol Data Unit .
Например, возьмем запрос Modbus RTU , который читает несколько HOLDING регистров с устройства #17 (Slave ID = 17)
11 03 006B 0003 7687Теперь убираем первый и последних 2 байта. Получаем PDU !
03 006B 0003С этим вроде все ясно. Теперь, что бы получить полноценный пакет Modbus TCP нам нужно добавить впереди MBAP Header — Modbus Application Header . Т.е. нам нужно добавить некий заголовок. Этот заголовок включает в себя Transaction ID , Protocol ID , Length и Unit ID .
Transaction ID – 2 байта, которые устанавливаются клиентом, что бы однозначно идентифицировать каждый запрос. Т.е. это просто число от 0 до 65535 уникальное для каждого запроса.
Protocol ID – 2 байта, которые определяют версию протокола. В текущей реализации всегда должны быть равны 0x00 0x00
Length – 2 байта, которые определяют длину пакета (за исключением байтов Protocol ID , Transaction ID и Length )
Unit ID – уникальный адрес устройства, которое опрашивается данной командой. Идентично Slave ID .
Небольшое отступление по поводу адресации. Может показаться что это излишне, так как TCP соединение может быть установлено только на конкретный IP адрес и порт. Т.е. у нас уже есть конкретный адрес сервера, поэтому назначение Unit ID не совсем понятно.
Но на самом деле вполне обычна ситуация, когда есть некий сервер, который просто маршрутизирует Modbus RTU запросы на другие устройства, которые подсоединены к нему по различным каналам (локальная сеть, последовательный порт, CAN интерфейс). Поэтому клиент может использовать Modbus TCP сервер как шлюз (Gateway ) для общения с устройствами за ним.
Пример Modbus TCP сервера, который используется как шлюз для перенаправления запросов на Modbus RTU устройства
Вот пример из жизни. Есть некое устройство основанное на Linux. Это устройство выступает Modbus TCP сервером. Любой клиент может подсоединиться к публичному IP адресу на порт 502 и инициировать Modbus TCP соединение. К данному Linux устройству подключены сенсоры, которые использую последовательный порт RS485. Сенсоров много, они очень простые и не могут быть подключены к Internet, у них есть только порт RS485 и они понимают только Modbus RTU . Поэтому клиенты посылают Modbus TCP запросы с Unit ID сенсоров на Modbus TCP Сервер. Сервер декодирует Modbus TCP запрос и преобразует его в Modbus RTU и отправляет в порт RS485. После того как сенсор отвечает ему, он преобразует Modbus RTU ответ в Modbus TCP ответ и отсылает его назад, к Modbus TCP клиенту, который инициировал запрос. Таким образом, имея всего один публичный IP адрес можно опрашивать онлайн сотню сенсоров, которые даже не могут быть подсоединены к Интернету или локальной сети.
А теперь наглядная схема, чем отличается Modbus RTU запрос от Modbus TCP запроса.
Посмотрим пример байтов для двух запросов:
Modbus RTU: 11 03 006B 0003 7687 Modbus TCP: 0001 0000 0006 11 03 006B 0003Пример ответа:
Modbus TCP: 0001 0000 0009 11 03 06 AE41 5652 4340 Modbus RTU: 11 03 06 AE41 5652 4340 49ADКак видите, конвертировать запросы между Modbus RTU и Modbus TCP очень просто. Хотя реализация Modbus RTU через TCP может показаться самым простым способом для маршрутизации запросов, на самом деле в Modbus TCP есть несколько положительных моментов:
- Не нужно вычислять CRC16
- Есть возможность идентифицировать пару ответ / запрос используя Transaction ID
- Можно легко добавлять свои версии протоколов, меняя константу Protocol ID
Одним из преимуществ Modbus является отсутствие необходимости в специальных интерфейсных контроллерах (Profibus и CAN требуют для своей реализации заказные микросхемы), простота программной реализации и элегантность принципов функционирования. Все это снижает затраты на освоение стандарта как системными интеграторами, так и разработчиками контроллерного оборудования. Высокая степень открытости протокола обеспечивается также полностью бесплатными текстами стандартов, которые можно скачать с сайта www.modbus.org.
В России Modbus по распространенности конкурирует только с Profibus. Популярность протокола в настоящее время объясняется, прежде всего, совместимостью с большим количеством оборудования, которое имеет протокол Modbus. Кроме того, Modbus имеет высокую достоверность передачи данных, связанную с применением надежного метода контроля ошибок. Modbus позволяет унифицировать команды обмена благодаря стандартизации номеров (адресов) регистров и функций их чтения-записи.
Основным недостатком Modbus является сетевой обмен по типу "ведущий/ведомый", что не позволяет ведомым устройствам передавать данные по мере их появления и поэтому требует интенсивного опроса ведомых устройств ведущим.
Разновидностями Modbus являются протоколы Modbus Plus [Modicon ] - многомастерный протокол с кольцевой передачей маркера и Modbus TCP [Modbus ], рассчитанный на использование в сетях Ethernet и интернет.
Протокол Modbus имеет два режима передачи: RTU (Remote Terminal Unit – «удаленное терминальное устройство») и ASCII. Стандарт предусматривает, что режим RTU в протоколе Modbus должен присутствовать обязательно, а режим ASCII является опционным. Пользователь может выбирать любой из них, но все модули, включенные в сеть Modbus, должны иметь один и тот же режим передачи.
Мы рассмотрим только протокол Modbus RTU, поскольку Modbus ASCII в России практически не используется. Отметим, что Modbus ASCII нельзя путать с частно-фирменным протоколом DCON, который используется в модулях фирм Advantech и ICP DAS и не соответствует стандарту Modbus.
Стандарт Modbus предусматривает применение физического интерфейса RS-485, RS-422 или RS-232. Наиболее распространенным для организации промышленной сети является 2-проводной интерфейс RS-485. Для соединений точка-точка может быть использован интерфейс RS-232 или RS-422.
В стандарте Modbus имеются обязательные требования, рекомендуемые и опционные (необязательные). Существует три степени соответствия стандарту: «полностью соответствует» - когда протокол соответствует всем обязательным и всем рекомендуемым требованиям, «условно соответствует» - когда протокол соответствует только обязательным требованиям и не соответствует рекомендуемым, и «не соответствует».
Модель OSI протокола Modbus содержит три уровня: физический, канальный и прикладной.
|
По умолчанию в RTU режиме бит паритета устанавливают равным 1, если количество двоичных единиц в байте нечетное, и равным 0, если оно четное. Такой паритет называют четным (even parity) и метод контроля называют контролем четности .
При четном количестве двоичных единиц в байте бит паритета может быть равен 1. В этом случае говорят, что паритет является нечетным (odd parity). Контроль четности может отсутствовать вообще. В этом случае вместо бита паритета должен использоваться второй стоповый бит. Для обеспечения максимальной совместимости с другими продуктами рекомендуется использовать возможность замены бита паритета на второй стоповый бит. Ведомые устройства могут воспринимать любой из вариантов: четный, нечетный паритет или его отсутствие. Структура Modbus RTU сообщенияСообщения Modbus RTU передаются в виде кадров, для каждого из которых известно начало и конец. Признаком начала кадра является пауза (тишина) продолжительностью не менее 3,5 шестнадцатеричных символов (14 бит). Кадр должен передаваться непрерывно. Если при передаче кадра обнаруживается пауза продолжительностью более 1,5 шестнадцатеричных символа (6 бит), то считается, что кадр содержит ошибку и должен быть отклонен принимающим модулем. Эти величины пауз должны строго соблюдаться при скоростях ниже 19200 бит/с, однако при более высоких скоростях рекомендуется использовать фиксированные значения паузы, 1,75 мс и 750 мкс соответственно. Контроль ошибокВ режиме RTU имеется два уровня контроля ошибок в сообщении: контроль паритета для каждого байта (опционно); контроль кадра в целом с помощью CRC метода. CRC метод используется независимо от проверки паритета. Значение CRC устанавливается в ведущем устройстве перед передачей. При приеме сообщения вычисляется CRC для всего сообщения и сравнивается с его значением, указанным в поле CRC кадра. Если оба значения совпадают, считается, что сообщение не содержит ошибки. Стартовые, стоповые биты и бит паритета в вычислении CRC не участвуют. 2.8.3. Прикладной уровеньПрикладной уровень Modbus RTU версии 1.1а описан в [Modbus ]. Он обеспечивает коммуникацию между устройствами типа "ведущий/ведомый". Прикладной уровень является независимым от физического и канального, в частности, он может использовать протоколы Ethernet TCP/IP (Modbus TCP/IP), Modbus Plus (многомастерная сеть с передачей маркера), интерфейсы RS-232, RS-422, RS-485, оптоволоконные, радиоканалы и другие физические среды для передачи сигналов. Прикладной уровень Modbus основан на запросах с помощью кодов функций . Код функции указывает ведомому устройству, какую операцию оно должно выполнить. При использовании протокола прикладного уровня с различными протоколами транспортного и канального уровня сохраняется неизменным основной блок Modbus-сообщения, включающий код функции и данные (этот блок называется PDU - "Protocol Data Unit" - "элемент данных протокола"). К блоку PDU могут добавляться дополнительные поля при использовании его в различных промышленных сетях и тогда он называется "ADU " - "Application Data Unit" - "элемент данных приложения". Коды функцийСтандартом Modbus предусмотрены три категории кодов функций: установленные стандартом, задаваемые пользователем и зарезервированные. Коды функций являются числами в диапазоне от 1 до 127. Коды в диапазоне от 65 до 72 и от 100 до 110 относятся к задаваемым пользователем функциям, в диапазоне от 128 до 255 зарезервированы для пересылки кодов ошибок в ответном сообщении. Код «0» не используется. Коды ошибок используются ведомым устройством, чтобы определить, какое действие предпринять для их обработки. Значения кодов и их смысл описаны в стандарте на Modbus RTU [Modbus ].
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
