Связь modbus – Modbus RTU для Чайников / Блог им. khomin / Сообщество EasyElectronics.ru — диспротект.рф

25.01.2020| alexxlab| Нет комментариев

Связь modbus – Modbus RTU для Чайников / Блог им. khomin / Сообщество EasyElectronics.ru

Содержание

Modbus

В данной статье будут рассматриваться основные характеристики протокола Modbus.

Рассмотрим некоторые особенности из широкого спектра различий между протоколами Modbus RTU и Modbus TCP, реализуемыми через последовательный интерфейс и через Ethernet.

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

Далее мы рассмотрим прохождение пакетов Modbus в качестве Мастера и Слейва сети через последовательный интерфейс и в качестве Клиента и Сервера через Ethernet.

Углубимся в особенности адресации данных в протоколе Modbus.

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

Для начала немного истории.

Modbus представляет собой последовательный коммуникационный протокол, разработанный компанией Modicon в 1979 (Schneider Electric) .

Он был создан специально для использования в ПЛК, производимых этой компанией для промышленного применения.

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

Modbus может использоваться как для передачи данных через Ethernet, так и через последовательный интерфейс.

Существуют три основных разновидности протокола Modbus: Modbus ASCII, Modbus RTU и Modbus TCP/IP.

Первоначально Modbus был разработан с использованием ASCII-символов для кодирования сообщений и эта версия протокола все еще используется.

Modbus RTU является самой распространенной реализацией данного протокола, использующей двоичное кодирование и CRC проверку ошибок.

Эти два режима – ASCII и RTU – несовместимы. Поэтому устройство, сконфигурированное для режима ASCII, не может взаимодействовать с другим устройством при помощи Modbus RTU.

Устройства, поддерживающие Modbus RTU, обычно используют один из трех интерфейсов: RS232, RS485, и RS422.

Топология сети «точка – точка» используется для подключения устройств по Интерфейсу RS232.

Если вам требуется подключить друг к другу только два устройства, и расстояние между этими ними составляет менее 15 метров, то стоит использовать RS232.

Для подключения до 32 устройств на одной линии и/или на расстояние большее, чем 100 метров, необходимо использовать RS485 или RS422.

Для Мастера, сообщающегося с несколькими Слейвами, на сегодняшний день наиболее популярным интерфейсом является RS485.

Этот стандарт может поддерживать до 32 узлов в диапазоне до 4000 футов или примерно 1200 метров без повторителей.

Единицей измерения передачи сообщений через Modbus является скорость передачи бит в секунду.

Все устройства в сети RTU должны использовать одинаковую скорость передачи данных.

Различные устройства поддерживают различные скорости передачи, но диапазон между 9600 и 19200 битами является типичным.

Через протокол Modbus модули ввода-вывода могут иметь количество сигналов более 10 000.

В последовательной сети Modbus есть одно устройство-Мастер, который передает команды подчиненным устройствам-Слейвам.

Сами Слейвы информацию не передают, за исключением случаев, когда они получают такую команду от Мастера.

Допустимое максимальное количество Слейв-устройств на одной шине Modbus в последовательной сети составляет 247 единиц, каждое из которых имеет свой уникальный ID-адрес от 1 до 247.

Однако интерфейс RS485 не может управлять более чем 32 узлами в одном сегменте; поэтому если в сети более 32 узлов, то потребуется повторитель.

Мастер может выдавать команды Слейв-устройствам, а также считывать с них данные.

СКАДА-система/человеко-машинный интерфейс обычно являются Мастерами, взаимодействующими с несколькими Слейв-устройствами. Устройства должны быть подключены последовательным соединением; они не могут быть соединены по топологии «звезда».

Modbus через Ethernet работает следующим образом: для связи друг с другом устройства Modbus используют постоянные кабели Ethernet и сетевые свитчи.

Главной отличительной особенностью Modbus TCP/IP является то, что протокол прикладного уровня (MBAP) добавляет сообщение для каждого устройства, подключенного по сети.

ID Слейв-устройства в начале сообщения удаляется так же, как циклический контроль конца сообщения.

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

Modbus использует порт 502 для связи через TCP/IP.

Это важно, если данные должны пройти через систему сетевой защиты.

Большое количество пользователей использует этот порт для передачи данных через протокол прикладного уровня (MBAP).

Последовательные сообщения Modbus также могут быть отправлены как обычные сообщения RTU в рамках передачи данных внутри и пакета Ethernet TCP/IP (инкапсуляция).

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

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

Сообщения протокола прикладного уровня (MBAP) на сегодняшний день являются самым популярным способом связи через Modbus TCP/IP.

В данной статье мы сделаем упор на рассмотрение Modbus RTU и Modbus TCP/IP с использованием протокола прикладного уровня (MBAP).

Modbus TCP/IP использует понятия «Клиент» и «Сервер» вместо «Мастер» и «Слейв».

Сеть TCP/IP состоит из Клиента, подключенного к сетевому коммутатору (коммутаторам), к которому также подключены все Серверы в сети.

Устройства, поддерживающие Modbus TCP/IP, используют межсетевой протокол для сети Интернет и требуют маску подсети.

IP-адрес и маска подсети представлены упорядоченным набором из 8 бит или иначе – октетом.

IP-адреса местоположения конкретного устройства в сети и Серверов маски подсети упрощают задачу маршрутизации трафика в сети.

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

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

По этому вопросу вы также сможете проконсультироваться у вашей IT-группы или администратора сети.

А теперь давайте поговорим о нецентровой системе адресации Modbus и разнице между строками в данной таблице.

Здесь представлены 4 строки, в которых хранится информация.

Две строки хранят простые дискретные значения, называемые ячейками, и цифровые 16-битные значения, известные как регистры.

Для каждого типа данных имеется одна строка только для чтения и одна строка для чтения и записи.

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

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

Каждая строка имеет максимум 9999 адресов.

Адреса от 1 до 9999 предназначены для чтения и записи, адреса с 10001 по 19999 предназначены только для чтения для дискретных входов.

Адреса от 30001 до39 999 предназначены только для чтения входных регистров, адреса от 40 001 до 49 999 используются для чтения и записи для регистров временного хранения.

На данный момент эта информация пригодится, чтобы объяснить термины, используемые для типов данных в Modbus.

Ячейки в дискретных входах Modbus, как правило, используются для передачи 1-битных данных или булевых данных. Состояние бита: либо поднят, либо опущен.

Регистром обозначается 1 слово (word) или 16 бит или 2 байта или переменная INTEGER.

Нет регистров для плавающих и двойных целочисленых значений, хотя они могут быть посланы, разделившись при этом на два регистра (WORD).

Значение плавающей переменной выражается в любом числе с десятичной точкой, которое представлено 32-битовым регистром.

Двойные целые числа, или DINTы являются просто двумя 16-битными значениями, сложенными вместе. Также представлены 32 битами.

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

Решение данной проблемы представляется очевидным: 32 + -битовое значение разбивается на 2 отдельных 16-битных регистра, а затем преобразовывается в 32-битное реальное значение (REAL).

Это достигается путем копирования двух 16-битных регистров в 1 переменную типа REAL. Функциональные коды Modbus представляют собой простые цифровые коды, которые указывают слейв-устройствам на то, какие таблицы данных используются для доступа и какую функцию необходимо выполнить в этой таблице – чтение или запись.

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

Например, функциональный код 1 является это кодом для чтения и индивидуальным битом состояния.

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

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

Modbus не определяет, как именно данные должны храниться в регистрах.

Различные производители средств автоматизации используют разные способы хранения и передачи данных.

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

Другие же устройства будут делать это с точностью до наоборот.

К тому же, когда регистры объединяются, чтобы представлять 32 + – реальные битовый значения, некоторые устройства будут передавать более высокий 16-бит в первом регистре и младшие 16-бит во втором регистре.

Другие производители делают это с точностью до наоборот.

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

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

И в завершении рассмотрим сообщения по Modbus RTU, которые отправляются от Мастера к Слейв-устройствам.

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

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

Мы надеемся, что эта статья даст лучшее понимание Modbus и TCP/IP.

#Modbus, #protocol, #features, #модбас, #особенности, #протокола

Если Вы не нашли то, что искали, сообщите об этом в комментарии

lapshinvr.ru

Modbus — это… Что такое Modbus?

Modbus — открытый коммуникационный протокол, основанный на архитектуре «клиент-сервер». Широко применяется в промышленности для организации связи между электронными устройствами. Может использоваться для передачи данных через последовательные линии связи RS-485, RS-422, RS-232, а также сети TCP/IP (Modbus TCP).

Не следует путать MODBUS и MODBUS Plus. MODBUS Plus — проприетарный протокол принадлежащий Schneider Electric. Физический уровень уникальный, похож на Ethernet 10BASE-T, полудуплекс по одной витой паре, скорость 1Мбит/с. Транспортный протокол — HDLC, поверх которого специфицировано расширение для передачи MODBUS PDU.

История

Modbus был разработан компанией Modicon (в настоящее время принадлежит Schneider Electric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году.^[1] Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети, состоящей из различных электронных устройств.

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232.^[1] Позднее стал применяться интерфейс RS-485, так как он обеспечивает более высокую надёжность, позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

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

Стандарт MODBUS

В настоящее время развитием Modbus занимается некоммерческая организация Modbus-IDA^[2].

Специфическая терминология

PDU (Protocol Data Unit) — общая для всех физических уровней часть пакета MODBUS. Включает в себя код функции и данные пакета.
ADU (Application Data Unit) — полный пакет MODBUS. Включает в себя специфичную для физического уровня часть пакета и PDU.

MODBUS специфицирует 4 типа данных:

Discrete Inputs — однобитовый тип, доступен только на чтение.
Coils — однобитовый тип, доступен на чтение и на запись.
Input Registers — 16-битовый знаковый или беззнаковый тип, доступен только на чтение.
Holding Registers — 16-битовый знаковый или беззнаковый тип, доступен на чтение и на запись.

Состав стандарта

Стандарты MODBUS состоят из 3 частей:

Документ Modbus Application Protocol содержит спецификацию прикладного уровня сетевой модели OSI:
- Элементарный пакет протокола, так называемый PDU (Protocol Data Unit), он един для всех физических уровней. PDU упаковывается в индивидуальный для каждого транспорта application data unit (ADU).
- Коды функций и состав PDU для каждого кода.
Документ Modbus over serial line содержит спецификацию канального и физического уровней сетевой модели OSI для физических уровней RS485 и RS232. В принципе может использоваться любой физический уровень основанный на асинхронном приемопередатчике.
Документ MODBUS Messaging on TCP/IP Implementation Guide содержит спецификацию ADU для транспорта через TCP/IP стек.

Достоинства стандарта

Основные достоинства стандарта — открытость и массовость. Огромное количество датчиков и исполнительных устройств выпущено промышленностью. Практически все промышленные системы контроля и управления имеют программные драйвера для работы с MODBUS сетями.

Недостатки стандарта

Стандарт в своей основе был разработан в 1979 году компанией Modicon (в данное время владелец Schneider Electric) ^[3], с учетом потребностей и вычислительных возможностей того времени, и многие актуальные для современных промышленных сетей вопросы не были учтены ^{[источник не указан 203 дня]}.

Стандарт специфицирует метод передачи только двух типов данных. Отсутствие четкого указания в стандарте привело к тому, что с другими типами данных сторонние производители MODBUS-решений поступали по своему усмотрению. Разброд де-факто в этом вопросе не позволил впоследствии сделать уточнения в официальном документе: это вызвало бы всплеск недовольства производителей и возможную войну форматов.
Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени.
Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени.
Стандарт не предлагает никаких решений по начальной инициализации системы. Назначение сетевых адресов и прописывание в системе параметров каждого конкретного устройства выполняются вручную.

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

Введение

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

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

Спецификация Modbus описывает структуру запросов и ответов. Их основа — элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1…127. Диапазон значений 128…255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Modbus PDU
код функции	данные
1 байт	N < 253 (байт)

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи. Существуют три варианта ADU, два для передачи данных через асинхронный интерфейс и один — через TCP/IP сети:

Modbus ASCII — для обмена используются только ASCII символы. Для проверки целостности используется однобайтовая контрольная сумма. Начало и конец сообщения помечаются специальными символами (начало сообщения «: «, конец сообщения CR/LF).
Modbus RTU — компактный двоичный вариант. Сообщения разделяются по паузе в линии, контроль целостности с помощью CRC.
Modbus TCP — для передачи данных через TCP/IP соединение.

Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):

адрес ведомого устройства	код функции	данные	блок обнаружения ошибок

где

адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы;
код функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;
данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;
блок обнаружения ошибок — контрольная сумма для проверки отсутствия ошибок в кадре.

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

Для Modbus TCP ADU выглядит следующим образом:

ID транзакции	ID протокола	длина пакета	адрес ведомого устройства	код функции	данные

где

ID транзакции — два байта, обычно нули
ID протокола — два байта, нули
длина пакета — два байта, старший затем младший, длина следующей за этим полем части пакета
адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с мостом, который выводит нас, например, в сеть RS485.

Поле контроля целостности в Modbus TCP отсутствует, т.к. целостность данных обеспечивает TCP/IP стек.

Категории кодов функций

В действующей в настоящее время спецификации протокола определяются три категории кодов функций:

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

Модель данных

Одно из типичных применений протокола — чтение и запись данных в регистры контроллеров. Спецификация протокола определяет четыре таблицы данных:

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

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

Следует отметить, что со способом адресации данных связана определённая путаница. Modbus был первоначально разработан для контроллеров Modicon. В этих контроллерах для каждой из таблиц использовалась специальная нумерация. Например, первому регистру ввода соответствовал номер ячейки 30001, а первому регистру хранения — 40001. Таким образом, регистру хранения с адресом 107 в команде Modbus соответствовал регистр № 40108 контроллера. Хотя такое соответствие адресов больше не является частью стандарта, некоторые программные пакеты могут автоматически «корректировать» вводимые пользователем адреса, например, вычитая 40001 из адреса регистра хранения.

Стандартные функции протокола Modbus

PDU запроса и ответа для стандартных функций
номер функции	запрос/ответ
1 (0x01)	A₁	A₀	Q₁	Q₀
1 (0x01)	N	D (N байт)
2 (0x02)	A₁	A₀	Q₁	Q₀
2 (0x02)	N	D (N байт)
3 (0x03)	A₁	A₀	Q₁	Q₀
3 (0x03)	N	D (N байт)
4 (0x04)	A₁	A₀	Q₁	Q₀
4 (0x04)	N	D (N байт)
5 (0x05)	A₁	A₀	D₁	D₀
5 (0x05)	A₁	A₀	D₁	D₀
6 (0x06)	A₁	A₀	D₁	D₀
6 (0x06)	A₁	A₀	D₁	D₀
15 (0x0F)	A₁	A₀	Q₁	Q₀	N	D (N байт)
15 (0x0F)	A₁	A₀	Q₁	Q₀
16 (0x10)	A₁	A₀	Q₁	Q₀	N	D (N байт)
16 (0x10)	A₁	A₀	Q₁	Q₀

A₁ и A₀ — адрес элемента,
Q₁ и Q₀ — количество элементов,
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)

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

Значения регистров хранения и регистров ввода передаются начиная с указанного адреса, по два байта на регистр, старший байт каждого регистра передаётся первым:

байт 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).

Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Количество флагов ст. байт	05 Количество флагов мл. байт	06 Количество байт данных	07 Данные ст. байт	08 Данные мл. байт	09 CRC мл. байт	0A CRC ст. байт
Master→Slave	0x01	0x0F	0x00	0x13	0x00	0x0A	0x02	0xCD	0x01	0xCB	0x72

Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Количество флагов ст. байт	05 Количество флагов мл. байт	05 CRC мл. байт	06 CRC ст. байт
Slave→Master	0x01	0x0F	0x00	0x13	0x00	0x0A	0x09	0x24

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

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

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

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

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 принимает запрос, но не может его обработать (обращение к несуществующему регистру и т. д.), отправляется ответ содержащий в себе данные об ошибке.

Таблица 2-1. Кадр ответа (Slave→Master) при возникновении ошибки modbus RTU
Направление передачи	адрес подчинённого устройства	номер функции	данные (или код ошибки)	CRC
Запрос (Master→Slave)	0x01	0x77	0xDD	0xC7 0xA9
Ответ (Slave→Master)	0x01	0xF7	0xEE	0xE6 0x7C

Стандартные коды ошибок

01 — Принятый код функции не может быть обработан на подчиненном.
02 — Адрес данных, указанный в запросе, не доступен данному подчиненному.
03 — Величина, содержащаяся в поле данных запроса, является недопустимой величиной для подчиненного.
04 — Невосстанавливаемая ошибка имела место, пока подчиненный пытался выполнить затребованное действие.
05 — Подчиненный принял запрос и обрабатывает его, но это требует много времени. Этот ответ предохраняет главного от генерации ошибки тайм-аута.
06 — Подчиненный занят обработкой команды. Главный должен повторить сообщение позже, когда подчиненный освободится.
07 — Подчиненный не может выполнить программную функцию, принятую в запросе. Этот код возвращается для неудачного программного запроса, использующего функции с номерами 13 или 14. Главный должен запросить диагностическую информацию или информацию об ошибках с подчиненного.
08 — Подчиненный пытается читать расширенную память, но обнаружил ошибку паритета. Главный может повторить запрос, но обычно в таких случаях требуется ремонт.

Примечания

Ссылки на используемые в статье источники

Учебные материалы

Утилиты

dic.academic.ru

Описание протокола Modbus

Данная статья описывает основы работы с протоколом 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 байт.

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

Стандартные. Описание этих функций опубликовано и утверждено Modbus-IDA. Эта категория включает в себя как опубликованные, так и свободные в настоящее время коды.
Пользовательские. Два диапазона кодов (от 65 до 72 и от 100 до 110), для которых пользователь может создать произвольную функцию.
Зарезервированные. В эту категорию входят коды функций, не являющиеся стандартными, но уже используемые в устройствах, производимых различными компаниями. К этим кодам относятся 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 представлены в таблице:

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

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

onitex.ru

modbus Википедия

Modbus — открытый коммуникационный протокол, основанный на архитектуре ведущий — ведомый (master-slave). Широко применяется в промышленности для организации связи между электронными устройствами. Может использоваться для передачи данных через последовательные линии связи RS-485, RS-422, RS-232, и сети TCP/IP (Modbus TCP). Также существуют нестандартные реализации, использующие UDP^[1]^[2].

Не следует путать MODBUS и MODBUS Plus. MODBUS Plus — проприетарный протокол, принадлежащий Schneider Electric. Физический уровень уникальный, похож на Ethernet 10BASE-T, полудуплекс по одной витой паре, скорость 1 Мбит/с. Транспортный протокол — HDLC, поверх которого специфицировано расширение для передачи MODBUS PDU.

JBUS — подмножество протокола Modbus RTU с небольшими отличиями в способе адресации^[3].

История[ | ]

Modbus был разработан компанией Modicon (в настоящее время принадлежит Schneider Electric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году^[4]. Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети, состоящей из различных электронных устройств.

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232^[4]. Позднее стал применяться интерфейс RS-485, так как он обеспечивает более высокую надёжность, позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

Стандарт MODBUS[ | ]

В настоящее время развитием Modbus занимается некоммерческая организация Modbus-IDA^[5].

Специфическая терминология[ | ]

PDU (Protocol Data Unit) — общая для всех физических уровней часть пакета MODBUS. Включает в себя функции и д

ru-wiki.ru

Программная эмуляция сети Modbus RTU / Habr

Если в качестве инструмента у Вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь.
Абрахам Маслоу

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

Популярность данного протокола обусловлена его открытостью и простотой. Сфера применимости достаточно широка: от профессиональных промышленных систем автоматизации до любительских DIY-проектов распределенных управляющих систем, «умных» домов и так далее. Данный протокол был выбран и мной, когда моя команда занималась создание ПО тренажера электропоезда. Протокол Modbus RTU на физическом интерфейсе RS485 используется на данном тренажере для обеспечения ввода в управляющий компьютер данных с органов управления, смонтированных на пульте машиниста (не стоит думать что Modbus используется на настоящем подвижном составе!).

Не стоит говорить с какими трудностями сопряжена наладка ПО, взаимодействующего с сетью контроллеров, управляющих оборудованием. Особенно когда часть устройств уже существует в железе, а другая часть находится в процессе разработки и изготовления. При этом ПО верхнего уровня требуется писать с учетом его взаимодействия с эти железом. И желательно писать его так, чтобы создавать рабочий вариант системы сразу, без использования «костылей» которые всегда трудно вычищать из кода.

«Надо писать ПО, когда готовы рабочие прототипы всего железа» — скажете вы и будете правы, но… ха-ха-ха, в реальном мире такое случается редко. И вот тут нам на помощь приходят программные эмуляторы.

Подробно рассказывать о протоколе не буду. Те, кого интересуют подробности могут воспользоваться поиском — протокол открыт, в сети доступна его официальная спецификация и масса информации. Скажу лишь, что в Modbus RTU описывает двоичный формат передаваемых данных и в качестве среды передачи использует дифференциальную витую пару стандарта RS485. Может использоваться и RS232, если в сети один передатчик и один приемник, или RS422 для однонаправленной передачи данных.

Нас будет интересовать именно RS485, который является полудуплексным интерфейсом, что допускает лишь одно передающее данные устройство в каждый момент времени. Арбитраж шины в Modbus осуществляется за счет выдержки обязательного интервала тишины длиной 3,5 символа при данной скорости передачи. Каждое сообщение должно начинаться и завершаться интервалом тишины. В сети существует одно ведущее устройство (master) и несколько ведомых устройств (slave) (до 31 в одном сегменте сети, без применения репитеров). Каждое ведомое устройство имеет уникальный идентификатор ID (от 1 до 31). Передача данных ведомым осуществляется лишь в том случае, если мастер послал запрос на получение данных с этого устройства.

Типичный запрос мастера выглядит так

Код функции

Адрес данных

Количество данных (2 байта)

Данные

CRC16

CRC16 используется для контроля целостности передаваемых данных. Modus использует Big Endian нотацию представления данных: для значений размером 2 байта старший байт внутри сообщения идет первым). В протоколе используется четыре типа данных:

Coils — дискретные выходы (1 бит) доступные для чтения/записи
Discrete inputs — дискретные входы (1 бит) доступные для чтения
Holding registers — регистры вывода (2 байта) доступные для чтения/записи
Input registers — регистры ввода (2 байта) доступные для чтения

В ответ на запрос ведомое устройство отдает данные в следующем формате

Код функции

Количество данных в байтах

Данные

CRC16

Сообщение, принятое от мастера попадает в приемный буфер всех устройств. Однако, если первый байт приемного буфера не совпадает с ID устройства, оно игнорирует принятые данные, очищая приемный буфер. Если сообщение предназначено данному устройству, то оно формирует ответ и, выдержав интервал тишины посылает его мастеру.

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

Разрабатывая ПО верхнего уровня (master реализуемый на базе ПК, например) для подобной сети, хорошо бы иметь набор программных средств, позволяющих реализовать такую концепцию

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

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

QSlave — открытый кроссплатформенный эмулятор сети Modbus RTU. Получить его можно по лицензии GPL v2.0 на Github по вышеприведенной ссылке.

Приложение разработано на C++ с использованием фреймворка Qt. Qt, вообще говоря, имеет библиотеки для работы с Modbus, но специфика задачи — имитация сети слейвов а не одного слейва, привела к тому, что встроенные библиотеки Qt для Modbus тут не использовались. Для обработки данных, принимаемых с виртуального последовательного порта была создана самописная библиотека modbus. Код этой библиотеки реализован в виде отдельного проекта, совершенно не зависит от интерфейса пользователя и может быть использован для сознания программных имитаций с более продвинутым функционалом. Из-за того, что эмуляция Modbus отвязана от UI, конфигурирование сети происходит с применением конфигурационных файлов. Был выбран формат XML (мы часто его используем в своих проектах). Пример конфигурации доступен в коде проекта. Комплект конфигов состоит из главного файла с расширением *.net, который выглядит так

example.net

<?xml version="1.0" encoding="UTF-8" ?>
<Config>
	<Slave>
		<!-- Описание слейва, отображаемое в списке устройств -->
		<Description>Traffic light</Description>
		<!-- Идентификатор слейва -->
		<id>1</id>
		<!-- Имя XML-файла конфигурации (без расширения *.xml) -->
		<config>traffic-light</config>
	</Slave>
</Config>

и XML-файлов конфигурации для каждого из слейвов

traffic-light.xml

<?xml version="1.0" encoding="UTF-8" ?>
<Config>
	<!-- Дискретные выходы -->
	<Coil>
		<address>16</address>
		<description>Red signal</description>
		<value>0</value>
	</Coil>
	<Coil>
		<address>17</address>
		<description>Yellow signal</description>
		<value>0</value>
	</Coil>
	<Coil>
		<address>18</address>
		<description>Green signal</description>
		<value>0</value>
	</Coil>
	
	<!-- Дискретные входы -->
	<DiscreteInput>
		<address>0</address>
		<description>Ready</description>
		<value>1</value>
	</DiscreteInput>
	
	<!-- Регистры вывода -->
	<HoldingRegister>
		<address>5</address>
		<description>Signal activity time</description>
		<value>15</value>
	</HoldingRegister>
	
	<!-- Регистры ввода -->
	<InputRegister>
		<address>2</address>
		<description>Signals count</description>
		<value>3</value>
	</InputRegister>
</Config>

Последний файл содержит описание всех данных, доступных в устройстве. Для того, чтобы загрузить конфигурацию необходимо открыть файл *.net из меню программы QSlave (File → Open config). Все файлы конфигурации должны лежать в одном каталоге. Конфигурация примера описывает сеть из одного ведомого устройства, некий виртуальный дорожный светофор, дискретные выходы которого описывают сигналы, дискретный вход обозначает некий бит готовности устройства к работе (Ready), регистр ввода сообщает число сигналов светофора, а регистр вывода задает время, в течение которого горит каждый из сигналов.

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

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

Но никто не говорит, что нельзя создать более продвинутый эмулятор, имитирующий работу устройств виртуальной сети. Для его создания можно использовать код библиотеки modbus, доступный в комплекте поставки QSlave.

Для создания ведомых устройств, отладки их прошивок нужна имитация мастера. Существует ряд открытых эмуляторов, таких как например QModbus. Мы использовали его в своей работе, до тех пор, пока не решили увеличить скорость передачи данных до 250 кБит/с. QModbus этого не позволяет. Его удалось пересобрать из исходников под Linux, но наши электронщики сидят на Windows, а где сборка не пошла по ряду причин. Выяснилось, что это приложение написано на Qt 4, использует сторонную библиотеку libmodbus. Хотелось иметь кроссплатформенное решение на Qt5, тем более что Qt5 уже работает с Modbus «из коробки». Поэтому был написан свой аналог, использующий стек библиотек Qt Modbus — QMaster. Он тоже доступен на Github на тех же условиях.

В заключении скажу, что работаю (на работе) в основном над закрытыми проектами. Однако, описанные инструменты разработаны лично мной в инициативном порядке в свободное время. К тому же они, в Windows-версии, статически линкованы с GPL-кодом Qt, поэтому я обязан передать их сообществу на тех же условиях, что и получил Qt. К тому же, эти инструменты могут быть полезны для читателя.

Благодарю за внимание!

habr.com

Все, что вы боялись спросить о преобразовании протокола Modbus

Протокол Modbus широко используется при автоматизации производства, многие устройства поддерживают протокол передачи данных Modbus RTU, использующий последовательный интерфейс. Обычно устройства имеют интерфейс RS-232 или RS-485 с разъемом DB-9 или клеммной колодкой. Устройства Modbus RTU легко внедрять и недорого обслуживать. Именно поэтому протокол Modbus RTU стал настолько популярным. Сегодня все больше и больше промышленных устройств начинают поддерживать стандарт Ethernet, т.к. сложность и масштабы сетей повышаются. Многие системы уже работают через Modbus TCP с использованием Ethernet, например, SCADA. В результате, возникают проблемы сопряжения между протоколами Modbus RTU и Modbus TCP. Приведенные ниже часто задаваемые вопросы и ответы на них призваны помочь вам выявить и предотвратить частые проблемы преобразования протокола Modbus.

Перечень часто задаваемых вопросов:

Нужен ли мне специальный преобразователь протоколов для подключения устройств с последовательным интерфейсом Modbus RTU к сети Ethernet? Достаточно ли сервера последовательных устройств?
Если к разным последовательным портам шлюза подключено несколько устройств Modbus RTU, какова должна быть архитектура подключения TCP? Можно ли использовать одно подключение или требуется отдельное соединение для каждого последовательного порта?
Как с помощью одного шлюза несколько хостов SCADA могут получить доступ к одним и тем же устройствам Modbus RTU одновременно?
У меня есть два рабочих ведущих устройства Modbus (PLC или HMI). Как мне организовать обмен данными между ними?
У меня есть несколько устройств Modbus RTU, которые нужно опросить. Я могу использовать несколько команд Modbus, чтобы получить данные регистров, но это занимает слишком много времени. Может ли шлюз активно получать данные и объединять их в единый регистр, чтобы я мог получить все данные с помощью одной команды Modbus?

Нужен ли мне специальный преобразователь протоколов для подключения устройств с последовательным интерфейсом Modbus RTU к сети Ethernet? Достаточно ли сервера последовательных устройств?

Прежде всего необходимо определить, какой драйвер Modbus на хосте SCADA вы хотите использовать. Существует четыре возможных варианта:

хост SCADA с драйвером Modbus TCP
хост SCADA с драйвером Modbus RTU — со встроенным последовательным портом
хост SCADA с драйвером Modbus RTU — без встроенного последовательного порта
хост SCADA с драйвером «Инкапсуляция Ethernet»

Вариант 1: Хост SCADA с драйвером Modbus TCP

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

На рынке устройств автоматизации доступно много «шлюзов Modbus», которые обеспечивают подключение через Modbus TCP для ведомых устройств Modbus TCP. Когда шлюз получает запрос Modbus TCP, он преобразует пакет в Modbus RTU и немедленно посылает его к устройствам Modbus RTU.

Вариант 2: Хост SCADA с драйвером Modbus RTU — со встроенным последовательным портом

Этот вариант подходит, если необходимо просто подключить существующий хост SCADA и устройства Modbus RTU к сети Ethernet. Если ваш хост SCADA оборудован последовательным портом, то с помощью пары шлюзов можно решить данную проблему.

Как показано на схеме сети, шлюз может преобразовывать пакет Modbus RTU в Modbus TCP и обратно. Если встроенный последовательный порт отсутствует, данное решение вам не подходит, воспользуйтесь вариантом 3.

Вариант 3: Хост SCADA с драйвером Modbus RTU — без встроенного последовательного порта

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

Для создания «виртуального COM-порта» сервер последовательных устройств установит драйвер виртуального COM-порта на ваш хост SCADA. Чтобы активировать этот порт, установите сервер последовательных устройств в режим виртуального COM-порта. Все данные, передаваемые через него, будут отправляться на удаленный последовательный порт сервера последовательных устройств. Так как с точки зрения ОС и SCADA виртуальный COM идентичен реальному, вы можете отправить запрос Modbus RTU на него напрямую.

Вариант 4: Хост SCADA с драйвером «Инкапсуляция Ethernet»

Если ваш хост SCADA не оснащен последовательным портом, а вы не хотите устанавливать драйвер виртуального COM-порта, то вместо этого вы можете использовать драйвер «Инкапсуляция Ethernet». Обратите внимание, что программное обеспечение SCADA должно поддерживать тип соединения «Инкапсуляция Ethernet». Использование драйверов «Инкапсуляция Ethernet» рекомендуется при наличии углубленных знаний о последовательных протоколах и протоколах TCP/IP.

Сервер последовательных устройств необходимо перевести в режим «Raw Socket» или «туннелирования», в котором при отправке SCADA пакетов Modbus RTU на устройства соединение между хостом и сервером последовательных устройств осуществляется через прозрачный канал TCP/IP или UDP без преобразования протокола. Сервер последовательных устройств необходимо корректно настроить, т.к. протокол Modbus RTU определяет конец пакета на основе пауз в передаче. Если пакет Modbus RTU будет разделён на два или более пакетов TCP/IP или UDP, вы можете столкнуться с некоторыми проблемами. Если вы не можете правильно настроить передачу пакетов между последовательными каналами и сетями Ethernet, рекомендуется использовать вариант со шлюзом (2) или виртуальным COM-портом (3).

Хотя серверы последовательных устройств можно использовать для подключения устройств Modbus RTU к сети Ethernet, вариант со шлюзом (2) наиболее предпочтителен и удовлетворяет практически всем требованиям системы. Ваш хост должен поддерживать протокол Modbus TCP, но это редко вызывает проблемы, т.к. этот протокол очень популярен и широко распространен. Ниже описаны несколько ситуаций, в которых необходимо использовать представленный вариант со шлюзом:

Несколько ведущих устройств или резервирование сети

Подключение через Ethernet позволяет не только пользоваться удаленным доступом, но также поддерживает несколько соединений. Большинство шлюзов поддерживают до 32 соединений, т.е. 32 хоста SCADA могут одновременно запрашивать данные у устройств Modbus RTU. В данной ситуации обеспечить резервирование сети с помощью сервера последовательных устройств довольно сложно, т.к. большинство серверов не поддерживает несколько ведущих устройств, с другой стороны, использование шлюзов не вызовет никаких проблем.

Одно соединение для нескольких устройств Modbus RTU

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

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

Одновременный доступ к устройству со старого контроллера Modbus RTU и новой Modbus TCP SCADA

Хотя протокол Ethernet позволяет легко настроить удаленный доступ, иногда бывает необходимо сохранить существующие локальные соединения с контроллером или HMI. Проблема состоит в том, последовательный порт на устройстве уже подключен к шлюзу, поэтому последовательный порт для подключения HMI отсутствует. Для решения этой проблемы некоторые шлюзы оборудованы функцией «Serial Redirector». Эта система очень похожа на маршрутизатор тем, что шлюз может передавать запрос между различными последовательными портами на основе идентификатора ведомого устройства.

Вывод

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

К списку вопросов

Если к разным последовательным портам шлюза подключено несколько устройств Modbus RTU, какова должна быть архитектура подключения TCP? Можно ли использовать одно подключение или требуется отдельное соединение для каждого последовательного порта?

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

подключение последовательного порта к уникальному TCP-порту
подключение последовательного порта к уникальному IP-адресу
использование таблицы маршрутизации

Метод 1: Подключение последовательного порта к уникальному TCP-порту

Наиболее популярный метод планирования топологии шлюза. В конфигурации шлюза каждый последовательный порт будет подключен к отдельному TCP-порту. Например, 4001 — последовательный порт 1, 4002 — последовательный порт 2 и т.д. Если вы хотите подключить устройства Modbus RTU к последовательному порту 1, установите соединение Modbus TCP с 4001. Шлюз будет передавать пакеты Modbus TCP между TCP-портом 4001 и последовательным портом 1.

В этой топологии драйвер SCADA должен создать несколько соединений Modbus TCP.

Метод 2: Подключение последовательного порта к уникальному IP-адресу

Этот вариант очень похож на вариант 1, но для идентификации последовательных портов шлюз использует различные IP-адреса.

Например, 192.168.2.1 — к последовательному порту 1, 192.168.2.2 — к последовательному порту 2 и т.д. Если вы хотите подключить устройства Modbus RTU к последовательному порту 1, установите соединение Modbus TCP с 502. Шлюз будет передавать пакеты Modbus TCP между 192.168.2.1:502 и последовательным портом 1. В этой топологии драйвер SCADA также должен создать несколько соединений Modbus TCP. Хотя для топологии требуется несколько IP-адресов, некоторые клиенты Modbus TCP позволяют использовать только TCP-порт 502. В этом случае вариант 1 вам не подойдет, и придется использовать вариант 2.

Метод 3: Использование таблицы маршрутизации

В данной топологии для связи с несколькими устройствами используется маршрутизация. Чтобы запрос передавался к правильному последовательному порту, необходимо правильно настроить шлюз и направление маршрутизации. Например, последовательный порт 1 обрабатывает все пакеты Modbus, которые имеют идентификаторы ведомых устройств от 1 до 10, последовательный порт 2 — идентификаторы от 11 до 20 и т.д.

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

Примечание:

Если вы подключите несколько устройств к одному последовательному порту или привяжете несколько последовательных портов к одному TCP-соединению, время опроса Modbus увеличится. Для увеличения скорости опроса требуется больше TCP-соединений, поэтому необходимо учитывать возможности SCADA.

К списку вопросов

Как с помощью одного шлюза несколько хостов SCADA могут получить доступ к одним и тем же устройствам Modbus RTU одновременно?

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

Тем не менее, описанное выше решение не является единственным. Некоторые шлюзы поддерживают режим «агента», активно и постоянно получающего данные от подключенных устройств.

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

Например, если один запрос занимает 100 мс, то 5 подключений вызовут задержку не менее 100 мс х (5-1) = 400 мс перед отправкой следующего запроса. Это означает, что цикл опроса каждого хоста SCADA должен составлять 400 мс (плюс некоторый допуск).

К списку вопросов

У меня есть два рабочих ведущих устройства Modbus (PLC или HMI). Как мне организовать обмен данными между ними?

Для обмена данными между двумя ведущими устройствами Modbus необходим шлюз, который может поддерживать режим ведущее устройство–ведущее устройство (master-master). В этом режиме шлюз будет работать в качестве ведомого устройства для обеих сторон. Одно ведущее устройство может записывать данные во внутреннюю память шлюза, а другое — получать их, тем самым обеспечивая обмен. В зависимости от используемого шлюза вы можете обеспечить поддержку Modbus RTU и Modbus TCP для обеих сторон или поддержку Modbus RTU для одной и Modbus TCP — для другой.

К списку вопросов

У меня есть несколько устройств Modbus RTU, которые нужно опросить. Я могу использовать несколько команд Modbus, чтобы получить данные регистров, но это занимает слишком много времени. Может ли шлюз активно получать данные и объединять их в единый регистр, чтобы я мог получить все данные с помощью одной команды Modbus?

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

К списку вопросов

Глоссарий

Сервер последовательных устройств

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

Современные серверы последовательных устройств также поддерживают функцию «виртуального COM-порта» для компьютеров, у которых нет дополнительного последовательного порта, преобразуя Ethernet-соединение в СОМ-порт. Помимо этих основных функций, более сложные серверы могут даже поддерживать протокол PPP по последовательным линиям связи или Telnet — в сетях Ethernet. Сервер последовательных устройств можно использовать для консольного управления сетевым и серверным оборудованием (поэтому некоторые производители называют его «консольным») или управления удаленными терминалами в старых банковских системах (поэтому иногда его называют «терминальным»).

Виртуальный COM-порт, драйвер виртуального COM-порта

Виртуальный COM-порт — это не реальный (т.е., не физический) COM-порт на компьютере. Вместо этого на компьютер под устанавливается драйвер виртуального COM-порта, полностью эмулирующий поведение локального COM-порта. Драйвер управляет портами на сервере последовательных устройств, который подключен по сети TCP/IP. Последовательный порт на удаленном сервере последовательных устройств будет функционировать так же, как локальный COM-порт. Виртуальный COM-порт привязывается к конкретному порту конкретного сервера последовательных устройств. Например, COM3 — это последовательный порт 1 на удаленном сервере последовательных устройств с IP-адресом 192.168.2.1. Поэтому при прохождении данных через этот порт они будут отправлены драйвером на «192.168.2.1@serial port 1» (192.168.2.1 на последовательный порт 1). Все запросы на этот виртуальный COM-порт будут перенаправлены на «192.168.2.1@serial port 1». Т.к. новые хост-компьютеры часто имеют недостаточное количество встроенных последовательных портов, виртуальные COM-порты являются бесценным инструментом для подключения существующего оборудования промышленной автоматизации.

Прозрачный шлюз

Прозрачный шлюз — это основной метод использования шлюза Modbus. Т.к. протоколы Modbus RTU и Modbus TCP имеют тот же PDU (блок данных), а разница заключается только в заголовке, шлюз может с легкостью передавать данные между такими устройствами. Таким образом, когда шлюз получает пакет Modbus TCP из сети Ethernet, он может просто заменить поле адреса в соответствии с требованиями Modbus RTU и сразу же отправить пакет на последовательный порт. Когда шлюз получает ответ от устройства Modbus RTU, он ответит клиенту Modbus TCP.

Шлюз-агент

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

Два протокола используют разную структуру пакетов. Например, PROFIBUS и Modbus, Ethernet/IP, PROFINET и т.д.
Два протокола используют разное время циклов. Некоторые протоколы, например, PROFIBUS, PROFINET и Ethernet/IP, обмениваются данными в течение очень коротких временных циклов, в которые не может уложиться прозрачный шлюз.

ipc2u.ru

Modbus — Традиция

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

Общее описание протокола Modbus RTU[править]

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

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

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

Таблица 1-1. Кадр посылки Modbus RTU
адрес ведомого устройства	номер функции	данные	CRC
1 байт	1 байт	N < 253 (байт)	2 байта

где:

адрес ведомого устройства — первое однобайтное поле кадра. Оно содержит адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 254. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство;
номер функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;
данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;
CRC — (контрольная сумма) заключительное двухбайтное поле кадра. Контрольная сумма завершает кадры запроса и ответа и применяется для проверки отсутствия ошибок в кадре посылки Modbus RTU.

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

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

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

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

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

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

смещение	обозначение
-40000	4x
-10000	1x

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

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

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

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

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

RTU фрейм[править]

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

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

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

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

Логические ошибки[править]

1. Если Slave принимает корректный запрос и может его нормально обработать, то возвращает нормальный ответ.

2. Если Slave не принимает какого либо значения, никакого ответа не отправляется. Master диагностирует ошибку по таймауту.

3. Если Slave принимает запрос, но обнаруживает ошибку (parity, LRC, or CRC), никакого ответа не отправляется. Master диагностирует ошибку по таймауту.

4. Если Slave принимает запрос, но не может его обработать (обращение к несуществующему регистру и т.д.), отправляется ответ содержащий в себе данные об ошибке.

Таблица 2-1. Кадр ответа (Slave→Master) при возникновении ошибки modbus RTU
Направление передачи	адрес подчинённого устройства	номер функции	данные (или код ошибки)	CRC
Запрос (Master→Slave)	0x01	0x77	0xDD	0xC7 0xA9
Ответ (Slave→Master)	0x01	0xF7	0xEE	0xE6 0x7C

Стандартные коды ошибок[править]

01 Принятый код функции не может быть обработан на подчиненном.
02 Адрес данных указанный в запросе не доступен данному подчиненному.
03 Величина содержащаяся в поле данных запроса является не допустимой
величиной для подчиненного.
04 Невосстанавливаемая ошибка имела место пока подчиненный пытался выполнить
затребованное действие.
05 Подчиненный принял запрос и обрабатывает его, но это требует много времени.
Этот ответ предохраняет главного от генерации ошибки таймаута.
06 Подчиненный занят обработкой команды.
Главный должен повторить сообщение позже, когда подчиненный освободится.
07 Подчиненный не может выполнить программную функцию, принятую в запросе.
Этот код возвращается для неудачного программного запроса, использующего
функции с номерами 13 или 14.
Главный должен запросить диагностическую информацию или информацию об
ошибках с подчиненного.
08 Подчиненный пытается читать расширенную память, но обнаружил ошибку паритета.
Главный может повторить запрос, но обычно в таких случаях требуется ремонт.

Стандартные коды функций протокола Modbus[править]

В протокол Modbus можно выделить несколько подмножеств команд ( Таблица 3-1).

Таблица 3-1
Подмножество команд	Диапазон кодов команд
Стандартные команды	1-21
Резерв для расширенных функций	22-64
Пользовательские	65-119
Резерв для внутренних нужд	120-255

0x10 Preset Multiple Registers (Установка значений в несколько регистров)[править]

Тип адресации 4x

Значения регистров передаются в линию начиная с указанного адреса, следующие значения регистров передаются после него (см. поле «Данные»). Ниже приведены примеры команда ведущего устройства (таблица 3-2) и ответ ведомого (таблица 3-3):

Таблица 3-2. Пример установки значения в один регистр
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Кол. регистров ст. байт	05 Кол. регистров мл. байт	06 Кол. байт	07 Данные ст. байт	08 Данные мл. байт	09 CRC мл. байт	10 CRC ст. байт
Master→Slave	0x01	0x10	0x00	0x01	0x00	0x01	0x02	0xFF	0xFF	0xA6	0x31

Таблица 3-3.Ответ на команду установки значения в один регистр
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Кол. регистров ст. байт	05 Кол. регистров мл. байт	06 CRC мл. байт	07 CRC ст. байт
Slave→Master	0x01	0x10	0x00	0x01	0x00	0x01	0x50	0x09

0x03 Read Holding Registers (Чтение значений из нескольких регистров)[править]

Тип адресации 4x

Ниже приведены примеры команда ведущего устройства (таблица 3-4) и ответ ведомого (таблица 3-5):

Таблица 3-4. Пример чтения значения из одного регистра
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Кол. регистров ст. байт	05 Кол. регистров мл. байт	06 CRC мл. байт	07 CRC ст. байт
Master→Slave	0x01	0x03	0x00	0x01	0x00	0x01	0xD5	0xCA

Значения регистров передаются в линию начиная с указанного адреса, следующие значения регистров передаются после него (см. поле «Данные»).

Таблица 3-5. Ответ на команду чтения значения из одного регистра
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Кол. Байт	03 Данные ст. байт	04 Данные мл. байт	05 CRC мл. байт	06 CRC ст. байт
Slave→Master	0x01	0x03	0x02	0xFF	0xFF	0xB9	0xF4

0x06 Preset Single Register (Установка значения в один регистр)[править]

Тип адресации 4x

Ниже приведены примеры команда ведущего устройства (таблица 3-2) и ответ ведомого (таблица 3-3):

Таблица 3-6. Пример установки значения в один регистр
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Данные ст. байт	05 Данные мл. байт	06 CRC мл. байт	07 CRC ст. байт
Master→Slave	0x01	0x06	0x00	0x01	0xFF	0xFF	0xD9	0xBA

Таблица 3-7. Ответ на команду установки значения в один регистр
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Данные ст. байт	05 Данные мл. байт	06 CRC мл. байт	07 CRC ст. байт
Slave→Master	0x01	0x06	0x00	0x01	0xFF	0xFF	0xD9	0xBA

0x01 Read Coil Status (Чтение значений из нескольких регистров флагов)[править]

Тип адресации 0x

Запрос:

Состоит из адреса флага и количества считываемых флагов. Адресация флагов начинается с 0, количество флагов с 1.

Ответ:

Значение флагов передается в одном бите в поле «Данные». Трактовка флагов: 1 = ON; 0 = OFF. 0-й бит первого байта данных содержит значение флага указанного в поле «Адрес». Если запросить состояние одного флага, то в младшем бите будет возвращено значение флага, а все остальные старшие биты заполнены нулями.

Ниже приведены примеры запроса ведущего устройства (таблица 3-6) и ответ ведомого (таблица 3-7). В примере запрашивается состояние 9 флагов с адреса 1. В ответе содержится 2 байта данных, для большей ясности будем считать что все запрашиваемые флаги находятся в состоянии ON, а все остальные в состоянии OFF.

Таблица 3-8. Пример чтения значения из одного регистра флагов
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Кол. флагов ст. байт	05 Кол. флагов мл. байт	06 CRC мл. байт	07 CRC ст. байт
Master→Slave	0x01	0x01	0x00	0x01	0x00	0x09	0x	0x

Таблица 3-9. Пример ответа на запрос чтения значения из одного регистра флагов
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Количество байт	03 Данные (флаги 0-7)	04 Данные (флаги 8-15)	05 CRC мл. байт	06 CRC ст. байт
Slave→Master	0x01	0x01	0x02	0xFF	0x01	0x	0x

0x0F Force Multiple Coils (Запись значений в несколько регистров флагов)[править]

Тип адресации 0x

Команда:

Состоит из адреса флага, количества изменяемых флагов, количества передаваемых байт устанавливаемых значений. Адресация флагов начинается с 0, количество флагов с 1. Устанавливаемые значения передаются начиная с байта, в котором находится младшим битом значение, устанавливаемое по адресу указываемому в поле «00 адрес подчиненного устройства».

Ответ:

Состоит из начального адреса флага и количества записанных флагов. Адресация флагов начинается с 0, количество флагов с 1.

Ниже приведены примеры команды ведущего устройства (таблица 3-6) и ответ ведомого (таблица 3-7).

Таблица 3-7. Пример команды записи значения в один из регистр флагов
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Количество флагов ст. байт	05 Количество флагов мл. байт	06 Количество байт данных	07 Данные (значения для флагов биты 0-7)	08 Данные (значения для флагов биты 8-15)	09 CRC мл. байт	0A CRC ст. байт
Master→Slave	0x01	0x0F	0x00	0x13	0x00	0x0A	0x02	0xCD	0x01	0x72	0xCB

Таблица 3-7. Пример команды записи значения в один из регистр флагов
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Количество флагов ст. байт	05 Количество флагов мл. байт	05 CRC мл. байт	06 CRC ст. байт
Slave→Master	0x01	0x0F	0x00	0x13	0x00	0x0A	0x24	0x09

0x05 Force Single Coil (Запись значения в один флаг регистра флагов)[править]

Команда:

Состоит из адреса флага и устанавливаемого значения. Поле «Значение флага мл. байт» всегда равно нулю (0x00), поле «Значение флага ст. байт» принимает значения 0xFF если флаг устанавливается в «1»(ON) или 0x00 если флаг устанавливается в «0»(OFF), другие значения недопустимы и не влияют на значение флага. Адресация флагов начинается с 0.

Ответ:

Ниже приведены примеры команды ведущего устройства (таблица 3-6) и ответ ведомого (таблица 3-7).

Таблица 4-4. Пример: команда установки значения в один флаг
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Значение флага ст. байт	05 Значение флага мл. байт	06 CRC мл. байт	07 CRC ст. байт
Master→Slave	0x01	0x05	0x00	0x13	0xFF	0x00	0x7D	0xFF

Таблица 4-4. Пример: Ответ на команду установки значения в один флаг
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Адрес ст. байт	03 Адрес мл. байт	04 Значение флага ст. байт	05 Значение флага мл. байт	06 CRC мл. байт	07 CRC ст. байт
Slave→Master	0x01	0x05	0x00	0x13	0xFF	0x00	0x7D	0xFF

0x50 Set date and time (Установка даты и времени)[править]

Ниже приведены примеры команда ведущего устройства (таблица 5-4) и ответ ведомого (таблица 5-5):

Таблица 5-4. Пример установки даты и времени
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Час [0..23]	03 Минута [0..59]	04 Секунды [0..59]	05 День [1..31]	06 Месяц [1..12]	07 Год [0..99]	08 Столетие [19-20]	09 CRC мл. байт	10 CRC ст. байт
Master→Slave	0x01	0x50	0x0A	0x01	0x00	0x01	0x0A	0x02	0x14	0x89	0x1C

Таблица 5-5. Ответ на команду установки даты и времени
Направление передачи	00 адрес подчиненного устройства	01 номер функции	02 Час [0..23]	03 Минута [0..59]	04 Секунды [0..59]	05 День [1..31]	06 Месяц [1..12]	07 Год [0..99]	08 Столетие [19-20]	09 CRC мл. байт	10 CRC ст. байт
Slave→Master	0x01	0x50	0x0A	0x01	0x00	0x01	0x0A	0x02	0x14	0x89	0x1C

Ссылки на используемые в статье источники[править]

traditio.wiki

"ДИС-Протект"