Расшифровка пакета modbus ascii. Подробное описание протокола Modbus TCP с примерами команд

Данная статья описывает основы работы с протоколом Modbus. В статье вы можете найти:

  • Описание Modbus
  • Пример применения
  • Описание программы Onitex Modbus Terminal

Основные принципы Modbus

Modbus — коммуникационный протокол, основанный на клиент-серверной архитектуре. В данной статье мы рассмотрим основы протокола и базовые принципы работы. Кроме того, вы можете ознакомиться с конкретными примерами работы протокола Modbus, изучив описания контроллеров, использующих этот протокол, к примеру, OSM-17RA, а так же скачав программу Modbus Terminal, позволяющую удобно работать с различными регистрами Modbus.

Протокол Modbus разработан для использования в программируемых логических контроллерах, таких, как управление электроприводом. В настоящее время является очень распространенным протоколом, используемых в различных промышленных системах. К примеру, данный протокол используется в контроллерах шаговых двигателей Онитекс. Широко используется для передачи данных последовательные линии связи, основанных на интерфейсах RS-485, RS-422, RS-232. В начале развития применялся интерфейс RS-232, как один из наиболее простых промышленных интерфейсов для последовательной передачи данных. В настоящее время протокол часто используется поверх интерфейса RS-485, что позволяет добиться высокой скорости передачи, больших расстояний и объединения нескольких устройств в единую сеть, тем более что протокол Modbus поддерживает адресацию. Широкая распространенность протокола Modbus, обусловленная его простотой и надежностью, позволяет легко интегрировать устройства, поддерживающие Modbus, в единую сеть.

Основной особенностью протокола является наличие в сети одного ведущего устройства - master. Только ведущее устройство может опрашивать остальные устройства сети, которые являются ведомыми (slave). Подчиненное устройство не может самостоятельно инициировать передачу данных или запрашивать какие-либо данные у других устройств, работа сети строится только по принципу "запрос-ответ". Мастер может так же выдать широковещательный запрос, адресованный всем устройствам в сети, в таком случае ответное сообщение не посылается.

Существует три типа протокола Modbus: Modbus ASCII, Modbus RTU и Modbus TCP. Устройства Onitex поддерживают протокол Modbus RTU, поэтому мы в дальнейшем будем иметь в виду прежде всего этот протокол.

Пакет данных в Modbus выглядит следующим образом:

Адрес | Код функции | Данные | Контрольная сумма.

Адрес - это поле, содержащее номер устройства, которому адресован запрос. Каждое устройство в сети должно иметь уникальный адрес. Устройство отвечает только на те запросы, которые поступают по его адресу, во избежание конфликтов. При этом, ведомое устройство в своем ответе так же посылает поле Адрес , кроме широковещательного запроса (когда ответа от ведомого быть вообще не должно).

Код функции содержит номер функции модбаса (о функциях будет сказано ниже). Функция может запрашивать данные или давать команду на определенные действия. Коды функций являются числами в диапазоне от 1 до 127. Функции с номерами от 128 до являются зарезервированными для пересылки в ответном сообщении информации об ошибках.

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

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

Максимальный размер пакета для сетей RS232/RS485 — 256 байт, для сетей TCP — 260 байт.

Существует три типа функций:

  1. Стандартные. Описание этих функций опубликовано и утверждено Modbus-IDA. Эта категория включает в себя как опубликованные, так и свободные в настоящее время коды.
  2. Пользовательские. Два диапазона кодов (от 65 до 72 и от 100 до 110), для которых пользователь может создать произвольную функцию.
  3. Зарезервированные. В эту категорию входят коды функций, не являющиеся стандартными, но уже используемые в устройствах, производимых различными компаниями. К этим кодам относятся 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 и 127.

Modbus RTU

При использовании режима Modbus RTU сообщение начинается с так называемого интервала тишины, равного времени передачи 3.5 символов, при заданной скорости обмена. Первым полем передается адрес устройства. Вслед за последним передаваемым символом также следует интервал тишины продолжительностью не менее 3.5 символов. Новое сообщение может начинаться после этого интервала. Фрейм сообщения передаётся непрерывно. Если интервал тишины продолжительностью 1.5 возник во время передачи фрейма, принимающее устройство должно игнорировать этот фрейм как неполный. Если новое сообщение начнется раньше интервала 3.5 символа, принимающее устройство воспримет его как продолжение предыдущего сообщения. В этом случае устанавливается ошибка CRC (несовпадение контрольной суммы).

Типы данных и стандартные функции Modbus

Типы данных протокола Modbus представлены в таблице:

Для чтения значений из этих выше таблиц данных используются функции с кодами 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-битными числами, старший байт каждого из них передается первым.
В ответе передаются запрошенные данные. Количество байт данных зависит от количества запрошенных элементов. Перед данными передается один байт, значение которого равно количеству байт данных.

Запись одного значения происходит при помощи следующих функций:
5 (0x05) — запись значения одного флага (Force Single Coil)
6 (0x06) — запись значения в один регистр хранения (Preset Single Register)

Команда состоит из адреса элемента (2 байта) и устанавливаемого значения (2 байта). Если команда выполнена успешно, ведомое устройство возвращает копию запроса.

Запись нескольких значений задается функциями:
15 (0x0F) — запись значений в несколько регистров флагов (Force Multiple Coils)
16 (0x10) — запись значений в несколько регистров хранения (Preset Multiple Registers)

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

Пример устройства Modbus

Рассмотрим работу протокола на примере контроллера шагового двигателя. В документации на контроллер описано назначение регистров Modbus, которые в нем использованы. Для управления двигателем необходимо задать параметры контроллера, параметры вращения и непосредственно команду. Вся работа с контроллером при использовании протокола Модбас сводится к работе с регистрами, то есть чтению и записи. Наш контроллер имеет всего один тип регистров: Holding Registers. Этот тип регистров предназначен как для чтения, так и для записи параметров. В контроллере использовано три типа регистров: 8, 16 и 32 бита. Таким образом, для работы с ним нам понадобится использование всего лишь нескольких функций: Read Holding Registers для чтения, Preset Single Register для записи регистров размерностью 8 и 16 бит, и Preset Multiple Registers для записи дначений в регистры длиной 32 бита.

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

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

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

Для отладки устройств с протоколом Modbus нами разработана программа OSM Modbus Terminal. Данная программа позволяет быстро освоить основные принципы управления устройствами OSM MB по протоколу Modbus RTU, проверить корректную работу устройства и быст-рее написать собственное программное обеспечение. Скачать программу можно в разделе Программное обеспечение на нашем сайте.

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

Для начала работы с программой необходимо установить адрес порта ПК и адрес устройства, и нажать кнопку «Connect». После этого можно производить чтение и запись в требуемые регистры. При необходимости можно сохранить названия и адреса используемых регистров кнопкой «Save». Программа написана с использованием OsmModbusDriver_SDK и может служить примером использования SDK.

Все права защищены. Перепечатка материалов с сайта возможно только с разрешения администрации

6.3. MODBUS Serial

Первые сети MODBUS базировались на асинхронных последовательных линиях связи и получили название MODBUS RTU и MODBUS ASCII . На физическом уровне они используют стандартные последовательные интерфейсы с символьным режимом передачи (см. рис.6.1).

В настоящее время в MODBUS-IDA эти сети получили название MODBUS over Serial Line и описаны в соответствующем стандарте. В нем указываются правила и рекомендации использования на канальном и физическом уровне.

Поскольку сеть MODBUS RTU/ASCII может иметь шинную топологию, определен метод доступа к шине - это модель Ведущий/Ведомый. В сетях MODBUS RTU и MODBUS ASCII Процесс Ведущего всегда является Клиентом, а Процессы Ведомых - Серверами. Это значит, что Ведущий отсылает запросы, а Ведомые их обрабатывают. Этот запрос может быть адресован как индивидуальному узлу так и всем Ведомым на шине (broadcast).

На канальном уровне MODBUS RTU/ASCII используется адресация, ориентированная на идентификаторы узлов. Каждый Ведомый должен иметь свой уникальный адрес (1-247), Ведущий не адресуется. При индивидуальных запросах, Ведущий (с клиентским Процессом) формирует кадр с сообщением-запросом и отправляет его по указанному адресу. Ведомый (с серверным Процессом) получает этот кадр и обрабатывает сообщение. После его обработки, Ведомый формирует кадр с сообщением-ответом, и отправляет его обратно Ведущему. Кадр с сообщением-ответом носит также функции кадра подтверждения, которого Ведущий будет ждать от Ведомого течение времени, определенного тайм-аутом.

При широковещательных запросах (broadcast) используется 0-вой адрес. Широковещательные запросы не требуют подтверждения, поэтому после отправки широковещательного кадра, Ведущий не ожидает ответного кадра.

6.3.1. Канальный уровень

На рис.6.11 показан общий вид кадра MODBUS Serial. Обратите внимание, что разграничение между кадрами и тип контрольной суммы здесь не указаны, поскольку это зависит от режима передачи ASCII или RTU. В поле адреса устройства Ведущий (при запросе) указывает адрес получателя, а Ведомый (при ответе) - свой адрес. Поля MODBUS PDU описаны выше.

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

6.3.2. MODBUS RTU

Данный режим предусматривает использование 8 бит данных в 11-битном символе, который позволяет передавать по байту на символ. Формат символа в RTU режиме: 1 стартовый бит, 8 бит данных (младший бит передается первым), 1 бит паритета + 1 стоповый бит или без паритета + 2 стоповых бита.

Формат кадра MODBUS RTU приведен на рисунке 6.13. Разграничение между кадрами производится с помощью пауз между символами. Новый кадр не должен появляться на шине раньше, чем 3.5 * Тс от предыдущего, где Тс - время передачи одного символа. Если отсутствие сигнала на линии (интервал тишины) будет больше чем 1.5 * Тс приемник идентифицирует окончание кадра. С другой стороны, появление нового кадра ранее 3.5 * Тс, тоже приведет к ошибке.

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


6.3.3. MODBUS ASCII

В данном режиме каждый байт сообщения передается как два ASCII символа их шестнадцатеричного представления, т.е. значение байта 03 16 будет передаваться как ASCII-код символов "0" и "3" (0110000 0110011) Таким образом, байты данных, код функции и байт поля проверки будет передаваться кодами символов 0-9, A-F. Формат символа в ASCII-режиме: 1 стартовый бит, 7 битов данных (младший бит передается первым); 1 бит паритета + 1 стоповый бит или без паритета + 2 стоповых бита.

Формат кадра приведен на рис.6.14. Как видим, для разграничения между кадрами используются стартовый символ ":" и стоповая последовательность "CR LF". Приемники на шине непрерывно отслеживают символ ":" который однозначно указывает на начало кадра. Когда он принят, приемники отлавливают поле адреса и т.д. Это очень простой способ синхронизации, который позволяет некритически относиться к паузам между символами (до 1 сек.). Адрес Ведомого и код функции занимают по два символа, согласно значению одного байта. Далее идут n * 2 символов данных, где n количество байт данных. В ASCII режиме для подсчета контрольной суммы используется алгоритм LRC. Причем контрольная сумма проводится над всеми байтами кадра, кроме стартовой и стоповой последовательности символов.

Режим ASCII накладывает меньшие требования на оборудование, за счет использования стартовой и столбовой последовательности в разграничении кадров, и нечувствительности к значительным паузам между символами. Но эти преимущества отражаются на его недостатках. RTU-режим более требователен к интервалам между кадрами, но значительно продуктивнее чем ASCII .

Пример 6.4. MODBUS. Расчет времени опроса ведомых на MODBUS-RTU.

Задача . Построить кадры форматов сообщений запросов и ответов для MODBUS RTU и рассчитать общее время опроса 10-ти аналоговых 16-битных переменных для 4-х ведомых (рис.6.15). Битовая скорость передачи данных - 19200 бит/с. Клиентский Процесс Ведущего (TSX Premium) и серверные Процессы ведомых (ПЛК TSX Micro) принимают сообщения в начале цикла, а отправляют - в конце цикла. Время цикла Ведущего = 10 мс, Ведомого - 5с .

Выполнения задания. Доступ к внутренним аналоговым переменным TSX Micro проводится через 03 или 04 функцию, поэтому формат кадров будет выглядеть как на рис.6.16.

Учитывая, что структура других кадров - аналогичная, приводить их формат нет смысла.
Аналогично рис.6.12 построим временную диаграмму обмена (рис.6.17).

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

В TSX Micro MODBUS-сервер реализован на уровне операционной системы. Специфика реализации заключается в том, что прием MODBUS-запросов из коммуникационного порта системой проводится в начале цикла, а отправка сообщений-ответов – в конце.

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

На рис.6.17 показано, что поступления кадра приходит где-то внутри цикла. Это значит, что их обработка и генерация ответа пройдет примерно через 1,5 цикла. Следует понимать, что это усредненное значение, для наихудшей оценки лучше резервировать 2 времени цикла (т.е. когда кадр пришел сразу после опроса коммуникационного порта). Таким образом время транзакции для одного ПЛК, например PLC1 (ТТ1), будет равна:

ТТ1=С5+T1.req+2*C1+T1.res+C5*2 (6.1)

ТТ1 рассчитан с учетом 2-х циклов затраченных Ведомым на генерацию ответа на сообщение-запрос. Если бы транзакция проводилась не периодически, как по условию задачи, а по возникновению события, то во время транзакции необходимо было бы включить также еще один цикл Ведущего. Несложно вывести время опроса всех ведомых:

ТТall=C5*9+C1*2+C2*2+C3*2+C4*2+T1.req+T1.res+ T2.req+T2.res+ T3.req+T3.res+ T4.req+T4.res (6.2)

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

ТТall= C5*9 + C1*8 + (T1.req+T2.req)*4(6.3)

Рассчитаем время T1.req и T2.req.

Время передачи кадра (Тframe) можно ориентировочно рассчитать по количеству символов (Nsymb) в кадре и времени передачи одного символа (Tsymb):

Tframe=Nsymb*Tsymb (6.4)

Время передачи одного символа рассчитывается:

время передачи одного символа = количество бит в символе/битовая скорость;
Время передачи кадров будет равна (див.рис.6.16 и рис.6.17):

T1.req=8*(11/19200)=4,58 мс

T1.res=25*(11/19200)=14,33 мс

TTall=90+40+ (4,58+14,33)*4= 206 мс.

Таким образом, для опроса 10-ти переменных из 4-х Ведомых со скоростью 19200 бит/с необходимо затратить примерно 206 мс. Если необходим периодический опрос, желательно зарезервировать определенное время, например еще дополнительно 100 мс.

В ряде случаев, реализация функций MODBUS-Клиента ложится на операционную систему, а доступ к ним в программе ПЛК происходит через интерфейсные коммуникационные функции. В частности, это характерно для большинства ПЛК от Scneider Electric (Momentum, Quantum, TSX Micro, TSX Premium, M340). В ряде других систем - клиентскую сторону на прикладном уровне необходимо полностью прописывать в программе ПЛК, а интерфейс предоставляется только для обмена с коммуникационным портом. В этом случае система предоставляет сервисы отправки и получения сообщений (которые формирует и анализирует сама программа пользователя), и генерации и проверки контрольной суммы. Рассмотрим пример .

Пример 6.5. MODBUS. Реализация MODBUS-клиента на TSX Twido.

Задача . Записать фрагмент программы в ПЛК Twido для считывания 3-х регистров с Ведомого с адресом 1 (рис.6.18).

Решение . В Twido клиентскую сторону MODBUS необходимо реализовывать через универсальную функцию EXCHx, которая отправляет и/или получает данные через коммуникационный порт с номером x. Параметрами функции являются таблица слов (%MW), в которых размещаются данные управления функцией, данные для отправки и буфер для приема. Если обмен будет проходить через коммуникационный порт 2, то вызов функции будет иметь следующий формат :

EXCH2 %MWy:n,

где y - номер первой переменной выделенной таблицы, n - количество слов в таблице.

Формат таблицы, то есть данных, которые необходимо заполнить, и область данных для приема одинаков для всех типов коммуникаций. Для функций 03/04 (чтение N слов) по MODBUS-RTU эта таблица будет иметь вид, приведенный в табл.6.2).

Таблица параметров состоит из 3-х частей-подтаблиц. В таблице управления функцией задаются параметры самой функции. Так в старшем байте 0-го слова указывается, что эта функция работает в обе стороны, т.е. после отправки данных, необходимо ждать ответа. Младший байт этого же слова указывает на длину таблицы передачи (в данном случае 6 байт), для того чтобы система знала о байтах которые необходимо передать (со 2-го слова по 4-е) и откуда начинается буфер приема (с 5-го слова) . Смещение в передаче и приеме необходимо для выравнивания данных в буферах по словам.

Таблица передачи содержит непосредственно сам запрос, т.е. кадр без кода CRC. Таблица приема - это буфер, который система заполнит кадром ответа, при положительном результате. Таким образом, перед использованием этой функции необходимо построить кадр запроса и ответа за исключением поля CRC (рис.6.19)

Таблица 6.2

Таблица параметров

Индекс в таблице

Старший байт

Младший байт

Таблица управления комм. функцией

01 (тип ф-ции отправка+приём)

06 (длина таблицы передачи)

03 (смещение в приёме)

00 (смещение в передаче)

Таблица передачи

адрес Ведомого

03 (номер функции)

адрес начального регистра

количество регистров

Таблица приёма (сообщение-ответ)

адреса Ведомого

03 (номер функции)

00 (байт для смещения)

счнтчик байт

первый регистр

второй регистр

...

N+6

N-ный регистр

Как видим, в запросе 6 байт. Это количество необходимо вписать в младший байт 0-го слова таблицы. В ответе ожидается 9-байт. Если байты кадра ответа разместить в последовательности слов (в ПЛК Schneider Electric память адресуется словами), то старший байт первого принятого регистра (согласно условию это %MW100) будет находиться на младшем байте 2-го слова буфера, а младший байт принятого регистра придется на старший байт 3-го слова в буфере. Таким образом, все принятые слова будут смещены, и прочитать их будет проблематично. Для устранения этой проблемы в таблице параметров функции есть поле смещения приема, в котором указывается номер байта в буфере приема, который будет сдвигать всю последовательность.

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

Во второй цепочке производится непосредственно вызов функции. Переменная %MSG2.D возвращает логическую "1", когда функция EXCH2 обработана и результат получен. Ее использование не дает "затопить" сеть чрезмерным количеством кадров, ведь пока нет ответа на предыдущий запрос или не прошло время тайм-аута, новый запрос отправлять нельзя.

Последний цепочка предназначена для записи результата чтения в переменные %MW0:3 (таблица с 3-х слов начиная с %MW0). Переменная %MSG2.E будет равной 1-це тогда, когда есть место ошибки в вызове функции.

6.3.4. Реализация физического уровня для MODBUS Serial

В отличие от начальной спецификации, которая ограничивалась описанием кадра, в стандарте MODBUS-IDA описываются также правила для реализации сети на физическом уровне. MODBUS over Serial Line базируется на использовании последовательных интерфейсов RS-485, RS-422 и RS-232.

Для RS-485 определена топология - это шина, в которой предусмотрено три способа подключения устройств (рис.6.21):

- Непосредственно к магистральному (trunk) кабелю, без ответвлений;

- Через пассивную коробку подключения и кабель ответвления (Derivation);

- Через активную коробку и специфический кабель ответвления.

Интерфейсы между кабелями и элементами сети имеют следующие обозначения (см. рис.6.21): ITr - интерфейс к магистральному кабелю; IDv - интерфейс между устройством и пассивной коробкой; AUI - интерфейс между устройством и активной коробкой; LT - терминаторы линии.
Битовые скорости определены равными 9600 бит/с и 19200 бит/с (по умолчанию). Другие скорости являются опциональными. Используется метод кодирования NRZ.

При использовании RS-485 стандарт определяет правила подключения устройств по 2-х проводной и 4-х проводной схеме, а также правила совместимости 2-х проводных и 4-х проводных интерфейсов на единственной линии. Ниже рассмотрено только 2-х проводное подключение, поддержка которого является обязательным.

По сути, 2-х проводное подключение на самом деле является 3-х проводным, так как кроме линий A-(D0 ) и B+(D1 ) используется также общая линия C(Common ), которая является обязательной (рис.6.22) .

Общее количество устройств ограничено: 32 устройства на одном сегменте RS-485 без репитеров (использование репитеров разрешается). Максимальная длина кабеля зависит от скорости, типа кабеля, количества нагрузок и конфигурации сети (2-х проводная или 4-х проводная). Для битовой скорости 9600 и кабеля AWG26 максимальная длина ограничена 1000м. Кабель ответвления должен быть короче 20 м. Если используются мультипортовые коробки с n портами, то каждый кабель ответвления ограничен длиной 40/n м.

Общий сигнальный провод (Common) обязательно соединяется с экраном в одной точке шины, как правило возле узла Ведущего, либо его коробки ответвления.

Для погашения отражения волн на концах линии между D1 и D0 выставляется терминаторы линии (LT). Терминаторы разрешается выставлять только на магистральном кабеле. В качестве терминаторов можно использовать:

- Резистор номиналом 150 Ом и мощностью 0.5 Вт;

- Последовательно соединенные конденсатор (1 нФ, 10 В минимум) и резистор номиналом 120 Ом (0.25 Вт) при использовании поляризации линии

В стандарте MODBUS Serial определены правила реализации защитного смещения (поляризации), которые предусматривают подключение питания номиналом 5 В между D1 и D0 через PullUp и PullDown резисторы для поддержания логической "1" на линии при отсутствии передачи. Номинал резисторов выбирается от 450 Ом до 650 Ом в зависимости от количества устройств (650 Ом при большом количестве). Защитное смещение проводится только в одной точке линии, как правило на стороне Ведущего. Максимальное количество устройств с реализованной поляризацией уменьшается на 4 по сравнению с системой без поляризации. Поляризация является необязательной. Однако коммуникации на устройствах могут давать сбой при отсутствии логического сигнала. Если это так, то поляризацию необходимо реализовывать самостоятельно, или использовать существующие схемы, если таковые предусмотрены устройствами.

Стандарт определяет также механический интерфейс, т.е. типы разъемов, вилок и соответствие сигналов на контактах. В качестве механического терминала можно использовать клемную колодку, экранированный RJ-45 (рис.6.23) или экранированный SUB-D9 разъем (рис.6.24).

В таблице 6.3 указано назначение контактов для коннекторов при 2-х проводном подключением по RS-485, а в таблице 6.4 по RS-232

Таблица 6.3

Предназначение контактов конекторов при подключении по RS-485

номера контактов

требования к наличию

цепь IDv

цепь ITr

название RS-485

комментарий

(см. раздел 3)

RJ45

SUB-D9

опционально

PMC

управление режимом ком. порта

обязательно

D1

B/B"

напряж V1, V1>V0 для лог. "1"

обязательно

D0

A/A"

напряж V0, V0>V1 для лог. "0"

желательно

Питание 5…24 VDC

обязательно

Common

Common

C/C"

Питание и сигнальная земля

Таблица 6.4

Предназначение контактов конекторов при подключении по RS-232

DCE (модем)

контур

DTE

номера контактов

требования к наличию

название

комментарий

(см. раздел 3)

источник

RS-232

требования к наличию

номера

контактов

RJ45

SUB-D9

RJ45

SUB-D9

обязательно

TxD

Transmitted Data

<< DTE

обязательно

обязательно

RxD

Received Data

DCE >>

обязательно

опционально

CTS

Clear to Send

DCE >>

опционально

опционально

RTS

Request to Send

<< DTE

опционально

обязательно

Common

Signal Common

обязательно

В качестве кабелей для 2-х проводного типа соединения стандарт определяет двойную экранированную витую пару категорий 4 (до 600м) или 5 (до 1000м), где в одной паре идут сбалансированные сигналы D0 и D1, а во второй - сигнальная земля Common. Рекомендуемые цвета кабелей: D1 желтый; D0 коричновий; Common серый.

Пример 6.6. MODBUS. Схема сетевых соединений MODBUS RTU.

Задача . Нарисовать схему сетевых соединений для 2-х проводной реализации шины MODBUS RTU со следующими узлами:

- PLC1: VIPA CPU 115SER 6BL32 (Ведущий) через встроенный последовательный порт процессорного модуля;

- PLC2: TSX Twido TWDLMDA40DTK (Ведомый) через коммуникационный модуль TWD NOZ 485T

- PLC3: TSX Twido TWDLMDA40DTK (Ведомый) через коммуникационный модуль TWD NOZ 485T

Решение . На рис.6.25 показана схема сетевых соединений для поставленной задачи. Спецификация сетевых средств дана в таб.6.5.

Как видно из рис.6.25, PLC1 подключается к шине через пассивную коробку, а вернее через клеммную колодку, что в принципе равнозначно. Это вызвано тем, что на ПЛК подключения идет с использованием 9-штекерного SUB-D разъема, что требует разработку собственного кабеля, схема подключения (спая) которого к коннектору и к клеммной колодке показан ниже основной схемы.

Таким образом к вилке КК1 провода кабеля КМ2 необходимо припаять. Назначение пинов розетки SER не совпадает со стандартной. Пины 8 и 3 (соответственно А (D0) и В (D1)) идут в одну пару, затем подключаются к ХТ1:1 и ХТ1:2; 5 и 6 (соответственно M5V (-5В) и P5V (+5 В)) идут в другую витую пару кабеля КМ2. Питания 5В необходимо для того, чтобы реализовать защитное смещение (асимметрию) в соответствии со стандартом. Кроме того M5V является сигнальной землей (Common).

Кабель КМ2 подключается к ХТ1 согласно схеме, показанной на рис.6.25. Экран кабеля соединяется с сигнальной землей в соответствии с требованиями стандарта. Следует напомнить, что ПЛК VIPA в этой системе является Ведущим, следовательно и защитное смещение и соединения экрана с землей необходимо реализовывать именно в этом месте. Защитное смещение производится с помощью питания 5В, которое берется из порта SER и двух резисторов.

Таблица 6.5.

Спецификация сетевых средств

Обозначение

Наименование

Референс

Колич

Примечание

PLC1

ПЛК VIPA 100

VIPA CPU 115SER 6BL32

1 шт.

VIPA

PLC2, PLC3

ПЛК Twido

TWDLMDA40DTK

2 шт.

Schneider Electric

MK1, MK2

коммуникационный модуль для реализации интерфейса RS-485, подключение под винт

TWD NOZ 485T

2 шт.

Schneider Electric

KK1

9-пиновий SUB-D коннектор типа вилка

1 шт.

XT1

клеммная колодка на 4 клеммы

1 шт.

TL1,TL2

терминаторы линии

2 шт

изготовляются с поз. 7 и 8

Резистор 120 Ом (0.25 Вт)

2 шт.

в составе поз.6

Конденсатор 1 нФ (>10 В)

2 шт.

в составе поз поз.6

Ru,Rd

Резистор 500 Ом (0.25 Вт)

2 шт

КМ1

AWG26

300 м

КМ2

кабель двойная экранированная витая пара 5-й категории AWG26

2 м

КМ3

кабель двойная экранированная витая пара 5-й категории AWG26

300 м

PLC2 и PLC3 соединяются с шиной с помощью коммуникационного модуля с клеммной колодкой. Это позволяет реализовать подключение без ответвлений. Однако на колодке не предусмотрено место подключения экрана, поэтому кабель экранируется отдельно.

Терминаторы линий реализованы последовательным соединением резисторов и конденсаторов, поскольку на шине задействовано защитное смещение.

В настоящее время MODBUS Serial используется как на уровне контроллеров так и на уровне датчиков (для распределенной периферии). Его использование проблематично при наличии на шине нескольких устройств SCADA / HMI , которые в клиент-серверной архитектуре должны быть Клиентами, ведь на MODBUS RTU/ASCII только Ведущий может быть Клиентом. Но даже в такой ситуации есть возможность организовать доставку данных всем нуждающимся узлам, если они поддерживают такой режим.

Исходя из указанного, на шине MODBUS Serial можно остановить свой выбор в случае, если:

- все устройства-Серверы поддерживают MODBUS RTU / ASCII в режиме Ведомого;

- необходимо только одно устройство-Клиент, которому необходимо инициировать обмены на шине, поддерживающий MODBUS RTU/ASCII как Ведущий;

- скорость восстановления данных - удовлетворяет условию задачи;
нет необходимости в

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

Наиболее широко используемый протокол в промышленной автоматизации (исключение - локальные предприятия). Modbus очень популярен. Это достаточно простое и понятное в использовании устройство со стандартной последовательной связью. В сети Modbus каждое устройство смотрит в сеть как набор катушек (бит) и регистров. Мастер считывает и записывает эти катушки и регистры, используя очень простой и сжатый набор команд. Коммуникация движется только в одном направлении за раз.

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

Modbus — протокол расширенного применения

Преобразователь протоколов широко используется по ряду причин:

  • Modbus — протокол с открытым исходным кодом. Это означает, что он может быть включен в широкий диапазон типов устройств от любого поставщика оборудования.
  • Использует простую структуру сообщений, что делает ее менее сложной для развертывания. Может потребовать всего несколько дней для реализации. Это явное конкурентное преимущество в сравнении с другими протоколами, которые могут потребовать месяцев для изучения и развертывания.
  • Поддерживает последовательные или Ethernet-соединения.
  • Используется с двумя типами последовательных соединений: RS-232 и RS-485. Некоторые версии протокола Modbus tcp также могут быть отправлены через Ethernet или TCP/IP. Эти сообщения Modbus упакованы как однобитовые или 16-битные пакеты слов.

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

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

Как правило, ПК настроен на запуск таких программ, как Wonderware, Intellution или LabVIEW в одном месте для сбора данных из разных процессов по всему предприятию. Другое приложение предназначено для настройки удаленных контроллеров производственных процессов (ПЛК, Allen-Bradley, Siemens, PLCDirect и другие). Для реагирования на различные уровни или режимы, которые передаются с устройства.

Два варианта протокола

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

Второй вариант — Modbus ASCII. Эта версия более подробная, использует шестнадцатеричное кодирование ASCII-данных, которое может быть прочитано операторами. Modbus ASCII является менее защищенным протоколом. Поскольку он менее эффективен, чем Modbus RTU, операторы должны использовать ASCII только для передачи данных на устройства, которые не поддерживают формат RTU. ASCII также может быть полезным, если сообщение RTU не может быть правильно применено.

Протокол Modbus для чайников

Modbus - это протокол последовательной связи, используемый для передачи информации по последовательным линиям между электронными устройствами. То, которое запрашивает информацию, называется ведущим (Master), а информация о поставке устройств — подчиненные устройства (Slaves). В стандартной сети Modbus есть один Master и до 247 Slaves, каждый из которых имеет уникальный подчиненный адрес от 1 до 247. Master может также записывать информацию в Slaves.

Для чего его используют?

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

Modbus обычно используется для передачи сигналов от приборов и устройств управления обратно в главный контроллер или систему сбора данных, например, систему, которая измеряет температуру и влажность, передает результаты на компьютер. Modbus часто используется для подключения контрольного компьютера с удаленным терминальным блоком (RTU) в системах диспетчерского управления и сбора данных (SCADA). Версии протокола Modbus существуют для последовательных линий (RTU и ASCII) и для Ethernet (TCP).

Как это работает?

Modbus передается по последовательным линиям между устройствами. Самой простой установкой был бы один последовательный кабель, соединяющий последовательные порты на двух устройствах: Master и Slave.

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

Протокол Master/Slave

При описании протокола Modbus RTU связь осуществляется между централизованным ведущим оборудованием, 247 подключенными электронными устройствами в одной сети. Конструкцию обычно называют протоколом «ведущий/ведомый», поскольку система Master запрашивает информацию у подключенных устройств, которые называются «подчиненными». Ведомые устройства отправляют информацию только мастеру в ответ на эти запросы, они не работают автономно. Ведущий может также записывать информацию на подчиненные устройства, но подчиненные устройства не могут записывать информацию ведущему устройству.

Когда ведомое устройство передает сообщение Modbus, оно начинает формировать сообщение с уникальным идентификатором адреса. Это число от 1 до 247, что позволяет мастеру определять, какое конкретное устройство отвечает запрошенной информации.

Связь и устройства

Каждому устройству, предназначенному для связи с использованием Modbus, присваивается уникальный адрес. В последовательных сетях только узел, назначенный мастером, может инициировать команду. В Ethernet любое устройство может отправлять команду Modbus, хотя обычно это делает только одно ведущее. Команда содержит адрес устройства, для которого он предназначен (от 1 до 247). Все команды включают информацию контрольной суммы, чтобы позволить получателю обнаруживать ошибки передачи. Базовые команды Modbus указывают RTU на изменение значения в одном из своих регистров, управление или чтение порта ввода-вывода, команду устройству отправить обратно одно или несколько значений, содержащихся в его регистрах.

Существует много модемов и шлюзов, поддерживающих Modbus, поскольку это очень простой протокол и часто копируется. Некоторые из них были специально разработаны для него. Различные реализации используют проводную, беспроводную связь, например, в диапазоне ISM, и даже службу коротких сообщений (SMS), а также услугу общей пакетной радиосвязи (GPRS). Типичные проблемы, с которыми приходится сталкиваться дизайнерам, включают проблемы с высокой задержкой и временем.

Обзор типов регистра Modbus

Типы регистров, на которые ссылаются устройства, включают:

Катушку (дискретный выход); . дискретный вход; . входной регистр; . регистрацию холдинга.

Коды функций

  • Коды общих функций - от 1 до 127, за исключением пользовательских кодов, проверенных сообществом Modbus, публично задокументированы и гарантированно уникальны.
  • Пользовательские коды функций - находятся в двух диапазонах от 65 до 72, от 100 до 110.
  • Коды зарезервированных функций - используются некоторыми компаниями для устаревших продуктов, недоступны для общего пользования.

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

Некоторые преимущества использования протокола Modbus:

  • Если драйвер уже установлен, а пользователь знаком с Ethernet и сокетами TCP/IP, драйвер может работать и обмениваться данными с ПК через несколько часов. Расходы на разработку считаются низкими. Требуется минимальное число оборудования. Драйвер совместим с любой операционной системой.
  • Нет необходимости в «экзотических» наборах микросхем, поэтому система может использовать стандартные ПК-карты Ethernet для общения с недавно реализованным устройством. Поскольку стоимость Ethernet падает, сокращаются затраты на аппаратное обеспечение. Пользователи не привязаны к одному поставщику услуг для поддержки, но могут воспользоваться нынешними разработками.
  • Спецификация доступна бесплатно для скачивания, никаких дополнительных лицензионных сборов, необходимых для использования протоколов Modbus, не требуется.
  • Взаимодействие между устройствами разных производителей и совместимость с установленной базой совместимых устройств.

Стоят преобразователи протоколов Modbus дорого. Цена промышленных шлюзов составляет 1000 долларов.

Ограничения

Поскольку Modbus был разработан в конце 1970-х годов для связи с численность типов данных ограничена теми, которые были поняты ПЛК в то время. Большие двоичные объекты не поддерживаются.

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

Поскольку Modbus является протоколом типа «ведущий/ведомый», для устройства нет возможности «сообщать об исключении» (кроме Ethernet TCP/IP, называемого open-mbus). Главный узел должен регулярно получать данные с дочерних устройств, а также искать изменения в данных. Это нагружает полосу пропускания, увеличивает время подключения к сети в приложениях, где пропускная способность может быть дорогой, например, в каналах с низкой скоростью передачи данных.

Modbus ограничивается адресацией 254 устройств на одной линии передачи данных, что ограничивает число устройств, которые могут быть подключены к мастер-станции (Ethernet TCP/IP является исключением). Передачи должны быть непрерывными, что ограничивает типы удаленных коммуникационных устройств теми, которые могут буферизовать данные, чтобы избежать пробелов в передаче. Сам протокол Modbus не обеспечивает защиту от несанкционированных команд или перехвата данных. Важно понимать, что в процессе передачи информации возникают логические ошибки, а также связанные с искажениями при обмене.

Статья посвящена промышленному протоколу 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.

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

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

Таблица Тип элемента Тип доступа
Дискретные входы (Discrete Inputs) один бит только чтение
Регистры флагов (Coils) один бит чтение и запись
Регистры ввода (Input Registers) 16-битное слово только чтение
Регистры хранения (Holding Registers) 16-битное слово чтение и запись

В реальной практике чаще всего встречаются устройства, в которых есть только таблица 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): Довольно неплохое русскоязычное видео на тему:

  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то