Rs 485 modbus rtu что это

Modbus RTU для Чайников

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

И так, в основе интерфейса RS-485 лежит принцип дифференциальной (балансной) передачи данных. Суть его заключается в передаче одного сигнала по двум проводам. Причем по одному проводу (условно A) идет оригинальный сигнал, а по другому (условно B) — его инверсная копия. Другими словами, если на одном проводе «1», то на другом «0» и наоборот. Таким образом, между двумя проводами витой пары всегда есть разность потенциалов: при «1» она положительна, при «0» — отрицательна.

Именно этой разностью потенциалов и передается сигнал. Такой способ передачи обеспечивает высокую устойчивость к синфазной помехе. Синфазной называют помеху, действующую на оба провода линии одинаково. К примеру, электромагнитная волна, проходя через участок линии связи, наводит в обоих проводах потенциал. Если сигнал передается потенциалом в одном проводе относительно общего, как в RS-232, то наводка на этот провод может исказить сигнал относительно хорошо поглощающего наводки общего («земли»). Кроме того, на сопротивлении длинного общего провода будет падать разность потенциалов земель — дополнительный источник искажений. А при дифференциальной передаче искажения не происходит. В самом деле, если два провода пролегают близко друг к другу, да еще перевиты, то наводка на оба провода одинакова. Потенциал в обоих одинаково нагруженных проводах изменяется одинаково, при этом информативная разность потенциалов остается без изменений.

Воплощение
Есть несколько вариантов.
— Подешевле на известной MAX-ADM485.
Без изоляции, развязки, изолированного источника питания. Зато стоит не более 25 рублей.
— Подороже, сюда можно отнести монстра ADM2587, ADM2483 и пр.
Разводить пп желательно очень вдумчиво.
Узел RS-485 хорошо вынести подальше от точных и измерительных цепей, узлов и т.п.
На обычную сигнальную линию проложенную вдоль силовых установок и мощных потребителей, воздействует огромное количество наводок и помех.
В некоторых случаях, их потенциал может достигнуть нескольких тысяч вольт!

Так выглядит типичная посылка, от Ведущего — Ведомому.

Так выглядит ответ Ведомого — Ведущему

ID — Адрес ведомого устройства. Он может иметь значения от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы.
Команда(код функции):
в данном примере одна, на чтение 0x03.
Но в действительности их намного больше.
Все коды функций делятся на:
— Публичные коды, описанные в стандарте MODBUS-IDA. Их список включает уже назначенные и используемые коды, а также коды для будущего использования;
— User-Defined Function Codes (65-72, 100-110) — коды, которые могут использоваться компаниями для собственных функций, и не описаны в спецификации;
— Reserved Function Codes (9, 10, 13, 14, 41, 42, 43, 90, 91, 125, 126 и 127) — зарезервированы коды, которые не доступны для общего использования.
(0x02) — чтение значений из нескольких дискретных входов (Read Discrete Inputs).
(0x03) — чтение значений из нескольких регистров хранения (Read Holding Registers).
(0x04) — чтение значений из нескольких регистров ввода (Read Input Registers).
(0x05) — запись значения одного флага (Force Single Coil).
(0x06) — запись значения в один регистр хранения (Preset Single Register).
(0x07) — Чтение сигналов состояния (Read Exception Status)
(0x0F) — запись значений в несколько регистров флагов (Force Multiple Coils)
(0x10) — запись значений в несколько регистров хранения (Preset Multiple Registers)
(0x16) — запись в один регистр хранения с использованием маски «И» и маски «ИЛИ» (Mask Write Register).
(0x18) — Чтение данных из очереди (Read FIFO Queue)
(0x14) — Чтение из файла (Read File Record)
(0x15) — Запись в файл (Write File Record)
(0x08) — Диагностика (Diagnostic)
(0x0B) — Чтение счетчика событий (Get Com Event Counter)
(0x0C) — Чтение журнала событий (Get Com Event Log)
(0x11) — Чтение информации об устройстве (Report Slave ID)
(0x2B) — Encapsulated Interface Transport
Обработка ошибок
Ведущий отправляет запрос к Ведомому, в котором в поле «код функции» указывает ему на необходимое действие.
Байты данных содержат информацию, необходимую для выполнения данной функции.
Ведомый, в случае удачного выполнения этой функции, повторяет код функции в ответе.
При возникновении ошибки, код функции в ответе модифицируется — старший бит выставляется в 1.
В байтах данных передается причина ошибки. Например при исполнении Ведомым функции 0x0F возникла ошибка, тогда он ответит Ведущему полем функции равным 0x8F.
В дополнении к изменению кода функции, Ведомый размещает в поле данных уникальный код, который указывает на тип и причину ошибки.

CRC-16, циклически избыточный код.
Полином:

Для расчета есть два метода:
Простой

и Табличный

Использование табличной функции
unsigned char mess[3] = <1,108,8>;
volatile unsigned short res1 = CRC16(&mess,3);
res1 будет равен 0x0СС6 при подстановке в конце команды менять местами
старший и младший байты не надо. Эта функция при занесении значения в
res1 автоматически меняет местами старший и младший байты.

Как указано в даташите на ADM485, для работы на прием выводы RE-DE-DI должны быть в 0,
тогда на выводе RO появляются принятые данные.
Для работы на передачу — все противоположно, но данные следует слать на DI.
Простая функция приема

Ответ выглядит примерно так

Все интервалы организованы на прерываниях.
Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов.
Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов.
Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно.

Для отладки удобно использовать что-то вроде Modbus_Poll.

К сожалению он не бесплатный, триальная версия работает 25 дней, ограничивает работу 10 минутами и всячески достает сообщениями…

Файл логанализатора, с общением по Modbus Яндекс диск

Рекомендуется к прочтению:
Спецификация Modbus Link
RS-485 для чайников — Link
Modbus в Википедии Link
Modbus протокол Link

Отдельное спасибо товарищу Papandopala, за функцию табличного расчета CRC.

Источник

Что такое Modbus и RS-485 — максимально просто

Изучая оборудование систем Умный Дом мы постоянно сталкиваемся с упоминанием протокола Modbus и порта RS-485.

Например, у контроллера EasyHomePLC есть два порта RS-485 и два порта RS-232, у контроллера Wiren Board есть два порта RS-485, у контроллера Beckhoff CX-8080 есть порт RS-485 и порт RS-232. У различного оборудования есть возможность управления по протоколу Modbus: кондиционеры, вентустановки, модули ввода-вывода. А ещё программное обеспечение EasyHome связывается с контроллером по протоколу Modbus TCP. Что всё это означает? Значит ли это, что если у контроллера есть интерфейс Modbus, и у устройства есть такой интерфейс, они сразу заработают вместе? Многие так считают, но это неверно. Объясню максимально просто и понятно.

Что такое RS-485

RS-485 — это стандарт физического уровня. Что это означает? Он определяет следующие параметры общения устройств:

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

Что такое RS-232

Другой стандарт, тоже по кабелю «витая пара». Не буду перечислять все параметры стандарта, он используется достаточно мало сейчас. В частности, все помнят мышки, которые подключались к компьютеру через широкий COM-порт, вот это как раз была связь по RS-232. К контроллерам EasyHomePLC и Beckhoff подключается GSM модем для приёма и отправки смс как раз через порт RS-232. Длина кабеля совсем небольшая.

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

Что такое Modbus

Переходим к более интересной вещи. Modbus — это уже протокол. Он определяет правила общения устройств. Например, он говорит, что одно устройство должно быть ведущим (master), а остальные ведомыми (slave). Ведущее посылает в шину связи сообщение определённого формата, в котором либо указан адрес нужного slave устройства, либо сообщение предназначено для всех устройств. Устройство slave, на которое отправлено сообщение, может ответить мастеру. Протокол регламентирует формат сообщения, его длину, возможные значения элементов сообщения. Есть также контрольная сумма, которая нужна для проверки того, что сообщение дошло неискажённым.

Но протокол Modbus не регламентирует, какими могут быть сами команды и какая среда передачи данных используется. Есть Modbus serial — это работа по RS-485 или RS-232, то есть, по одной перевитой паре кабелей. Есть Modbus TCP — это работа в компьютерной сети TCP/IP, где у каждого устройства есть IP адрес и порт.

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

Протокол общения — это ещё не язык, нет. Протокол даёт нам такие понятия как то, что сообщение состоит из слов, разделяемых тишиной. Слова состоят из слогов. А ещё то, что в начале общения надо здороваться, а в конце прощаться. Говорить может только один в один момент времени. Как-то так.

И вот мы подошли к главному вопросу. У нас контроллер имеет порт (он же разъём, он же шлюз) RS-485 и в него программно заложена возможность общения по Modbus. Также у нас есть кондиционер, у которого также есть физический разъём RS-485 и в паспорте указана возможность работы по Modbus. Что это для нас значит? Это значит, что устройства теоретически могут работать совместно.
Как люди, имеющие возможность говорить, теоретически могут общаться. Для нас такая возможность подразумевает полноценное управление и контроль обратной связи. Но заставить их работать вместе не так просто. Нужно в контроллере написать драйвер для работы именно с этим устройством. Для этого в инструкции к устройству надо найти карту регистров, то есть, описание возможных команд устройства. Вот пример некоторых регистров для вентмашины:

[Request0]
Direction=read
Type=bit
Baudrate=115200
Address=1
Period=100
var0=3800#bool#SCo_Зима/

Мест
var2=3802#bool#SCo_Таймер
var3=3803#bool#SCo_Блокировка
var4=3804#bool#SCo_Пуск/

Пуск/Стоп var6=3806#bool#SCoРежимR2 var7=3807#bool#SCoРежимR3 var8=3808#bool#SCoРежимR4 var9=3809#bool#SCoРежимR5 var10=380a#bool#SCoРежим_R6

Чем сложнее устройство, тем вариантов команд больше. В вентмашине или кондиционере их может быть до сотни. Также по протоколу RS-485 мы можем общаться с инфракрасными приёмопередатчиками, генераторами, конвекторами, электрокарнизами, кондиционерами, термостатами, датчиками и различными элементами расширения контроллера на DIN рейку: модулями входов и выходов, диммерами.

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

Например, в программном обеспечении EasyHome есть поддержка ИК-передатчиков ICPDas и Insyte, модулей связи с кондиционерами Mitsubishi и Daikin, конвекторов Varmann, счётчиков электричества Delta, блоков расширения Овен, Razumdom, Bolid, вентмашин Komfovent и ещё много чего. Нужно смотреть конкретные поддерживаемые модели, у разных моделей разные спецификации команд.

Есть устройства с поддержкой Modbus TCP, там нужно, чтобы оно было включено в локальную сеть, отдельный порт RS-485 контроллера не нужен.

К системам на Z-Wave напрямую ничего по Modbus не подключить, там нет такой возможности. Только используя промежуточный контроллер, который поддерживает и Modbus, и Z-Wave, например, Wiren Board.

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

Что произойдёт, если на вход Овен МВ пришёл сигнал о сработке датчика, а потом датчик изменил состояние на первоначальное, а контроллер не успел его опросить? В программе модуля МВ есть счётчики количества сработок каждого входа, вот их-то контроллер и считывает, и видит, что было изменение.

Скорость опроса модулей контроллером ограничена, поэтому контроллер не мгновенно узнаёт о событии, это зависит от того, какая скорость опроса, насколько она оптимизирована, и сколько модулей расширения подключено к контроллеру. Если у нас очень много модулей, которых контроллер по очереди опрашивает, то весь цикл опроса занимает некоторое время, пока очередь нужного нам модуля не подойдёт, об изменении состояния мы не узнаем. А потом контроллер должен будет отправить нужную команду соответствующему модулю реле для изменения его состояния. У EasyHomePLC при количестве модулей расширения не более 5 максимальная задержка отрабатывания события не превышает 1.5 секунды, что достаточно быстро. Зависит от того, что опрашивалось в момент изменения состояния входа. У контроллеров Beckhoff связь между модулями расширения происходит по собственному протоколу связи, там независимо от количества модулей всё отрабатывает мгновенно.

Версии Modbus — TCP и RTU

Ещё раз обозначим разницу между версиями связи по ModBus.

Modbus RTU, он же Modbus Serial — работа по RS-485 или RS-232. Подключение устройств по витой паре, где контроллер мастер, а остальные устройства — слейвы, которые не могут сами инициировать связь. Самый распространённый вариант связи.

Modbus TCP или Modbus TCP/IP — общение устройств происходит по обычной компьютерной сети TCP/IP, включающей работу через интернет и через Wi-Fi. То есть, возможна связь между устройствами на любом расстоянии, когда оба подключены к интернет.

Есть ещё несколько разновидностей: Modbus RTU/IP (отличается от TCP наличием контрольной суммы), Modbus over UDP, Modbus Plus (собственный протокол фирмы Schneider Electric, в сети могут быть несколько мастеров).

Ещё небольшая статья про работу устройств по протоколу Modbus в системах Умный Дом: RS-485 Modbus в системах Умного Дома.

300,149 просмотров всего, 140 просмотров сегодня

Источник

Modbus: простыми словами о популярном протоколе для M2M-взаимодействия

Modbus — это сетевой протокол прикладного уровня, широко используемый в промышленном производстве для обмена данными между устройствами (Machine-to-Machine, M2M).

С момента разработки в 1979 году он не теряет своей популярности. Согласно статистике HMS Industrial Networks в 2021 году Modbus занимает 10% мирового рынка промышленных сетей (по 5% приходится на Modbus RTU и Modbus TCP).

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

Базовые принципы работы Modbus

Modbus использует архитектуру Master-Slave, которая относительно недавно была переименована разработчиком в Client-Server. Согласно этому подходу в сети выделяется клиентское (ведущее) устройство, которое периодически отправляет запросы на серверные (ведомые) устройства с целью чтения или записи их параметров.

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

Архитектура Client-Server (ранее Master-Slave), лежащая в основе протокола Modbus

Пакет данных Modbus включает в себя постоянную часть PDU (Protocol Data Unit), общую для всех реализаций протокола и состоящую из кода функции и данных. Кроме этого, возможен ряд специфических полей, которые будут различаться в зависимости от физического уровня сети — чаще всего это адрес серверного устройства и контрольная сумма для выявления ошибок. С учетом дополнительных полей полный пакет Modbus носит название ADU (Application Data Unit). Рассмотрим более подробно каждое поле пакета ADU в обобщенном виде. Особенности, присущие различным вариантам протокола, будут описаны в следующем разделе.

Структура пакета данных Modbus в обобщенном виде

Рассмотрим передачу пакетов в Modbus. Протокол обеспечивает клиент-серверное взаимодействие в режиме Request/Response. Клиент инициирует запрос в серверное устройство, передавая в PDU код функции и данные. В зависимости от физического уровня сети в пакете могут быть дополнительные поля, рассмотренные выше.

Если обработка запроса проходит без ошибок, то сервер возвращает пакет, содержащий исходный код функции и запрошенные данные.

Схема работы Modbus в случае отсутствия ошибок на серверном устройстве

При возникновении ошибки серверное устройство возвращает в качестве данных код исключения, а вместо исходного кода функции — его значение, увеличенное на 128 (0x80 в шестнадцатеричной системе HEX).

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

Схема работы Modbus в случае ошибок на серверном устройстве

Разновидности Modbus: ASCII, TCP и RTU

Modbus — это протокол прикладного (седьмого) уровня модели OSI (Open Systems Interconnection model). Он не зависит от нижележащих уровней и может использоваться совместно с другими протоколами, например Ethernet TCP/IP или UDP/IP, а в качестве физической среды для передачи сигналов применять последовательные интерфейсы RS-232, RS-422, RS-485, оптоволокно, радиоканалы и другое.

Разновидности протокола Modbus

Опишем отличия наиболее известных реализаций протокола Modbus: RTU, ASCII и TCP.

Modbus RTU (Remote Terminal Unit). Это разновидность протокола, которая в качестве физического уровня сети чаще всего использует последовательный интерфейс RS-485, реже — RS-232 и RS-422. По сути, все эти интерфейсы определяют связь с помощью витых пар, но различаются характеристиками вида максимальной длины кабеля, количества узлов и так далее.

Формат пакета Modbus RTU в целом совпадает с обобщенной формой, описанной ранее: дополнительные поля не используются. Контроль целостности пакетов ведется с помощью алгоритма CRC-16.

Важная особенность Modbus RTU в том, что для разделения пакетов должны использоваться временные паузы продолжительностью не менее чем произведение 3,5*t, где t — время передачи одного байта в текущей сети. А передача байтов данных в пределах одного пакета производится последовательно с промежутком времени между соседними байтами не более 1,5*t, иначе передача будет считаться ложной. Эти правила не дают использовать Modbus RTU в медленных, например модемных, сетях.

Структура пакета данных в Modbus RTU

Modbus ASCII. Это разновидность протокола, также работающая поверх интерфейсов RS-232/RS-485, но для кодирования сообщений использующая ASCII-символы.

По сравнению с Modbus RTU в формате пакета добавляются еще два поля — специальные символы для отметки начала и конца сообщения: двоеточие и символы возврата каретки / перевода строки. Временные паузы между пакетами не нужны. Для проверки целостности применяется алгоритм LRC-8.

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

Структура пакета данных в Modbus ASCII

Modbus TCP. Это реализация ModBus в сетях Ethernet. Работает поверх TCP/IP стека.

В отличие от Modbus RTU и ASCII, в Modbus TCP соединение устанавливается с конкретным устройством средствами TCP/IP. Поэтому адрес в пакете Modbus чаще всего игнорируется, а широковещательная рассылка сообщений не используется. Однако адрес может потребоваться, если соединение устанавливается со шлюзом, который, в свою очередь, выводит на сеть RS485 — чтобы далее общаться с устройствами уже на языке Modbus.

Контроль целостности пакетов также обеспечивается средствами протокола TCP/IP, поэтому нет необходимости в его Modbus-реализации.

Наряду с адресом в заголовке пакета Modbus TCP присутствует ряд дополнительных полей:

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

Всегда заполняется нулями, зарезервирован для будущего использования.

Длина оставшейся части пакета: адреса и PDU (кода функции и данных).

Структура пакета данных в Modbus TCP

Мы рассмотрели только открытые и самые распространенные реализации протокола Modbus. Но их гораздо больше, например MODBUS Plus — проприетарный протокол от Schneider Electric, поддерживающий режим Multi-Master.

Регистры и функции Modbus

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

Доступ к регистрам осуществляется с помощью 16-битного адреса. Первому элементу в каждой группе регистров соответствует адрес 0. То есть адрес любого регистра может принимать значения из диапазона 0-65535 (0x0000-0xFFFF в HEX-формате). При этом спецификация протокола не определяет, что физически из себя представляют адресные пространства и по каким внутренним адресам устройства должны быть доступны регистры. В общем случае значения регистров с одинаковым адресом, но разными типами отличаются друг от друга.

В документации ряда производителей на некоторые, особенно старые устройства адреса регистров могут быть указаны в других форматах — где адресация начинается не с нуля и первая цифра адреса определяет тип регистра. Например, Input Register с адресом 0 может быть описан как 30001, а Holding Register — как 40001. В таких случаях в пакетах данных следует передавать адреса в стандартном формате Modbus независимо от способа представления их в документации. Для получения верного адреса достаточно вычесть смещение, соответствующее типу регистра. В некоторые программные пакеты заложена автоматическая корректировка адресов.

Для работы с каждым типом регистров определены функции чтения и записи. Наиболее часто используемые функции описаны ниже.

Для каждой функции в спецификации протокола Modbus определена структура PDU: какие данные и в каком порядке должны использоваться в запросах и ответах. Рассмотрим формирование пакетов Modbus RTU на примере функции Read Coils с кодом 1. Эта функция, кроме передачи собственного кода, требует наличия в запросе адреса первого Coil-регистра и количества регистров, которые необходимо прочитать. В случае успешного выполнения запроса в ответе будут возвращены код функции, число байт, необходимое для вывода запрошенных Coil-регистров, и статус всех этих регистров.

Предположим, нам нужно обратиться к серверному устройству с адресом 1 и прочитать 19 его Coil-регистров с номерами 20–38. Адресация регистров ведется с 0, поэтому адрес первого нужного нам регистра будет 0x13 (это 19 в HEX-системе). Требуемое для чтения количество регистров также будет равно 0x13 (для чтения запрошено 19). В качестве адреса и кода функции указываем 01. Контрольная сумма формируется по алгоритму CRC-16 на основе других полей пакета.

В случае отсутствия ошибок в ответе вернутся без изменений адрес серверного устройства и код функции. Для расчета числа байтов, которые потребуются для возврата состояния регистров, нужно разделить запрошенное количество регистров на 8 и к результату прибавить 1, если остаток от деления не равен 0. В нашем случае результат деления 19 на 8 равен 2, но остаток положительный — поэтому для вывода регистров потребуется 2+1=3 байта. Это значение будет указано в ответе после кода функции. И далее будут следовать 3 байта, описывающие состояние выбранных регистров. Например, первый байт будет описывать состояние 8 Coil-регистров с номерами 27-20. Если в поле, к примеру, содержится HEX-значение CD — статус соответствующих 8 регистров такой: 1100 1101.

Пример успешного выполнения функции Read Coils

Если в процессе обработки запроса на серверном устройстве возникнет ошибка (например, обнаружен несуществующий адрес регистра), то в ответе будет содержаться измененный код функции, равный исходному коду плюс смещение 0x80 — в нашем примере 0x81, и код исключения — в нашем примере 03, что значит неверный формат запроса. С полным перечнем возможных исключений можно ознакомиться в документации.

Пример возврата исключения для функции Read Coils

Источник