Содержание
Изучая оборудование систем Умный Дом и вообще почти любой автоматики и диспетчеризации мы постоянно сталкиваемся с упоминанием протокола 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 — это стандарт физического уровня. Что это означает? Он определяет следующие параметры общения устройств:
То есть, стандарт подразумевает, что на 2-проводную шину (одну витую пару) можно подключить множество устройств. Он не описывает никакой язык общения оборудования.
Другой стандарт, тоже по кабелю «витая пара». Не буду перечислять все параметры стандарта, он используется достаточно мало сейчас. В частности, все помнят мышки, которые подключались к компьютеру через широкий COM-порт, вот это как раз была связь по RS-232. К контроллерам EasyHomePLC и Beckhoff подключается GSM модем для приёма и отправки смс как раз через порт RS-232. Длина кабеля совсем небольшая.
Существуют переходники с RS-232 на RS-485 и обратно. Мы получаем возможность подключить на порт RS-232 что-то, что подключается по RS-485 или сделать длинную линию связи для устройств RS-232, поставив в начале линии переходник на 485, а в конце обратно.
Переходим к более интересной вещи. 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_Зима/~Лето
var1=3801#bool#SCo_Дист/~Мест
var2=3802#bool#SCo_Таймер
var3=3803#bool#SCo_Блокировка
var4=3804#bool#SCo_Пуск/~Стоп
var5=3805#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.
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 в системах Умного Дома.
349,353 просмотров всего, 36 просмотров сегодня
Контроллеры серии «Синком-Д» поддерживают считывание значений ТС и ТИ с регистров устройств, а также запись в регистры устройств данных из памяти контроллера в протоколе MODBUS RTU.
На одном канале COM можно настроить до 50 отдельных запросов считывания и записи данных различных устройств с использованием разных протоколов. Рекомендуемое ограничение — количество устройств, подключаемых к одному СОМ-порту, не должно превышать 8.
После включения контроллер непрерывно последовательно выдает сконфигурированные запросы и полученные от устройств данные (в ответах на запросы) складываются в общий массив контроллера.
Чтобы настроить работу COM-портов контроллера по протоколу MODBUS RTU необходимо выполнить следующие действия:
Внимание: Порты 3 и 4 контроллеров серии «Синком-Д» могут работать только по интерфейсу RS-485.
Допустимые значения: от 50 до 115200 бод для порта 1 и от 1200 до 115200 бод для портов 2, 3 и 4.
Рекомендуемые значения параметра «Стоповый бит»: 2 бита без контроля чётности и 1 бит с контролем чётности.
Внимание: Каждая строка описания соответствует одному запросу протокола обмена.
Задать параметр «Адрес устройства».
Параметр задаётся в диапазоне от 1 до 65535. Также адрес можно задать в шестнадцатиричной кодировке – для этого перед адресом необходимо поставить один из знаков: $, &, x, X (должна использоваться латинская раскладка).
Задать параметр «Код функции».
Контроллеры серии «Синком-Д» поддерживают несколько стандартных кодов функций, согласно протоколу MODBUS, и несколько специальных – для поддержки конкретных устройств и реализаций протокола. Поддерживаемые стандартные коды функций:
Код функции | Функция |
1 | Read Coil Status |
2 | Read Input Status |
3 | Read Holding Registers |
4 | Read Input Registers |
6 | Preset Single Register |
Поддерживаемые специальные коды функций:
Внимание: так как специальные функции предназначены для поддержки конкретных протоколов и устройств, могут потребоваться специфичные настройки каналов связи и параметров запроса.
Код функции | Устройство/реализация |
90 | МВ110-8А |
111 | Тэкон-19 |
100 | Щит S2000 |
200 | DCON чтение |
202 | DCON запись |
205 | ЭЛЕМЕР |
Каждый из кодов функций имеет собственный набор поддерживаемых типов данных.
Чтобы настроить запрос необходимо выполнить следующие действия:
Число задающее адрес первого считываемого запросом регистра.
Адрес регистра можно задать в шестнадцатиричной кодировке – для этого перед адресом необходимо поставить один из знаков: $, &, x, X (должна использоваться латинская раскладка).
Внимание: Первые 10 адресов в массиве ТИ, как правило, используются в сервисных целях. В разных описаниях наблюдается разная система адресации «прямая» или с «0» и относительная с «1». В настройке контроллера необходимо указывать «прямой» адрес, т.е. указанное число переносится в запрос без изменений.
Параметр описывает количество считываемых запросом регистров.
Внимание: Назначение параметра при работе по коду функции 6 отличается. Вопрос рассмотрен более детально в соответствующем разделе.
Задать параметр «Тип данных».
если указан тип данных ТС – ответные данные будут декодированы как 16 значений ТС для каждого полученного регистра, а общее количество полученных ТС = 16*количество
регистров.
если указан тип данных 16 бит без знака – каждый принятый регистр будет декодирован как целое число без знака (значение ТИ) 16 бит (диапазон 0 — 65535)
если указан тип данных 16 бит со знаком – каждый принятый регистр будет декодирован как целое число со знаком (значение ТИ) 16 бит в дополнительном коде (диапазон -32767 +32767)
если указан тип данных 32 бит – каждые подряд принятые 2 регистра будут декодированы как целое число без знака (значение ТИ) 32 бит (порядок следования байтов в принятых регистрах можно выбрать)
если указан тип данных пл, точка – каждые подряд принятые 2 регистра будут декодированы как число (значение ТИ) в кодировке IEEE Standard Binary Floating-Poin (порядок следования байтов в принятых регистрах можно выбрать).
Каждому выбранному ‘Коду функции’ соответствует свой актуальный набор ‘Типа данных’.
Этот параметр устанавливает паузу после передачи запроса, в течении которой оживляется прием ответа от устройства. Задается в мсек. В идеальном случае время ответа должно быть равно времени передачи ответного пакета + время передачи 3.5 байт. Время передачи 1 байта на скорости 9600 примерно 1 мс. Однако встречаются устройства, отвечающие на запрос с дополнительной паузой, не описанной в документации.
Рекомендация: При первичном конфигурировании для неизвестного ранее устройства установите паузу как минимум равную 1000 мс. После наблюдения реального обмена можно будет уменьшить до фактически необходимого. Этот же параметр можно использовать для “замедления” темпа опроса данных. Например, при малом количестве устройств на шине или при наблюдении медленно изменяющихся данных можно выставить время больше необходимого для ответа.
Этот параметр позволяет задать адрес в массиве ТС/ТИ контроллера, начиная с которого будут записываться принимаемые или считываться, записываемые в устройство нижнего уровня, ТС/ТИ .
Внимание: Заданные для запроса адреса в массиве ТС/ТИ не должны пресекаться с адресами ТС/ТИ полученных из других источников.
Задать параметр «Доп.».
Поле «Доп.» предназначено для задания маски обработки ТС по протоколу ModBUS (когда нужно обработать только часть битов из пакета). Маска задается в поле «Доп.» в шестнадцатеричном виде (в том порядке как идут биты в пакете). Максимально можно задать маску для четырех принятых байтов.
Например 03000000 (можно просто 03) означает что обработаны будут только первые два ТС.
Electronic Team, Inc. использует файлы cookie, чтобы персонализировать ваш опыт на нашем веб-сайте. Продолжая использовать этот сайт, вы соглашаетесь с нашей политикой в отношении файлов cookie. Кликните сюда, чтобы узнать больше.
Ольга Вайс 27 сент.
В современном мире Интернета и сетевых коммуникаций существует множество крошечных, но важных деталей, которые помогают каждому получить безграничную информацию под рукой.
Многие вещи должны работать вместе, чтобы сделать возможным даже самый простой поисковый запрос — будь то тип сети на стороне клиента или используемые интернет-протоколы для баз данных.
Одним из элементов, способствующих беспрепятственному и эффективному обмену информацией, являются протоколы MODBUS и RS485.
Протоколы RS485/MODBUS, часто вызывающие у многих путаницу, предоставляют две уникальные (но связанные) концепции. В этой статье мы расскажем, что читателям нужно знать об этих протоколах, почему они важны и как их использовать.
Поскольку RS485 и RS232 несовместимы напрямую, нет необходимости использовать правильные интерфейсы для обеспечения успешной передачи сигнала. Хотя пользователи могут использовать шлюзы с RS232 на RS485, для пользователей гораздо более распространенным является прямой переход с RS485 на USB, GSM или Ethernet.
Этот метод менее затратный, а также позволяет избежать необходимости в дополнительных компонентах.
Данные, передаваемые через интерфейс RS485, обычно используют протокол MODBUS. В качестве альтернативы устройство RS232 использует текстовые (ASCII) протоколы. Основное отличие состоит в том, что Modbus определяет тип протокола, тогда как RS485 определяет уровень сигнала протокола.
При использовании коммуникационного устройства RS485 вышеупомянутое различие означает, что пользователям потребуется некоторое время, чтобы немного разобраться в протоколе MODBUS.
Протокол MODBUS RS485 обеспечивает связь между хостами (также известными как «ведущие») и устройствами (также известными как «подчиненные»), позволяя запрашивать мониторинг и настройку устройств.
Сообщения, передаваемые по протоколу MODBUS, обеспечивают основные операции чтения и записи через двоичные реестры (известные как «катушки») и 16-битные слова. Ведомые устройства отвечают исключительно на запросы хоста/мастера. Мастер/хост всегда инициирует любую связь.
Если у пользователей есть несколько устройств, подключенных к шине RS485 (параллельно), каждому отдельному устройству требуется определенный идентификатор ведомого устройства MODBUS.
Каждый запрос MODBUS начинается с того, что хост связывается с идентификатором ведомого устройства желаемого устройства, а ответ отвечает идентификатором ведомого устройства передающего ведомого устройства.
Таким образом, протоколы Modbus буквально определяют структуру обмена сообщениями, используемую при обмене данными между ведущим и ведомым(и) (или устройствами).
Однако его никогда не следует путать со средством связи. MODBUS только формирует структуру обмена сообщениями, но не является физической средой передачи данных.
В наиболее распространенных случаях обмена промышленными данными (или связи во время автоматизации процессов) обычно задействован мастер BAS. BAS (Building Automation System) — это коммуникационный шлюз и ПЛК, или это программное приложение, работающее на компьютере.
Для обмена данными хосту требуется среда, которая не только облегчает обмен, но и определяет скорость.
Программное обеспечение для тестирования Modbus — это инструмент, который позволяет анализировать интерфейсы RS232/RS422/RS485, передающие сообщения MODBUS. Отличные функциональные возможности SPM позволяют легко обнаруживать и устранять проблемы, возникающие при тестировании и отладке MODBUS. Отличительной особенностью этого инструмента является то, как он может отображать и регистрировать все данные, проходящие через COM-порт вашей системы.
Используя возможности расширенного поиска и фильтрации этого программного обеспечения сниффера MODBUS, вы можете отобразить только необходимое подмножество данных, которое вам нужно. SPM также содержит встроенный терминал для выполнения текстовых команд. Это удобное приложение поддерживает экспорт данных в различных форматах и имеет множество настраиваемых параметров.
Анализатор Modbus предназначен для регистрации, отладки и отображения последовательных данных Modbus RTU и ASCII, передаваемых через порты RS485 системы.
Монитор последовательного порта
Регистрация и анализ активности последовательного порта
4,8 Рейтинг основан на 41+ пользователях, отзывах (75)
Скачать 14-дневный полнофункциональный пробный период
Нет, MODBUS и RS485 — это не одно и то же. Причина в том, что оба протокола являются связанными концепциями и работают вместе для успешного функционирования.
Существуют два варианта протокола MODBUS:
Чтобы говорить с устройством MODBUS, пользователи всегда должны использовать один и тот же режим, настроенный в устройстве. Все устройства, которые действительно следуют стандарту, будут поддерживать режим MODBUS RTU.
На самом деле всегда используется режим MODBUS RTU. В основном это связано с тем, что MODBUS ASCII не дает никаких преимуществ, поскольку все сообщения в любом случае сложно закодировать вручную.
Обзор протоколаModbus RTU — это открытый последовательный протокол, основанный на архитектуре ведущий/подчиненный (теперь клиент/сервер), изначально разработанной Modicon (теперь Schneider Electric). Это широко распространенный протокол последовательного уровня из-за простоты использования и надежности. Modbus RTU широко используется в системах управления зданием (BMS) и системах промышленной автоматизации (IAS).
Сообщения Modbus RTU представляют собой простую 16-битную структуру с циклически избыточной контрольной суммой. Простота этих сообщений обеспечивает надежность. Благодаря этой простоте базовая 16-битная структура регистров Modbus RTU может использоваться для упаковки данных с плавающей запятой, таблиц, текста ASCII, очередей и других несвязанных данных.
Этот протокол в основном использует последовательные интерфейсы RS-232 или RS-485 для связи и поддерживается всеми коммерческими SCADA, HMI, серверами OPC и программами сбора данных на рынке. Это позволяет очень легко интегрировать совместимое с Modbus оборудование в новые или существующие приложения мониторинга и управления.
Подпишитесь на нашу серию электронных писем по обучению автоматизации, чтобы узнавать все о Modbus и основных промышленных протоколах в недельном формате!
RTA является гордым членом организации Modbus. Для получения дополнительной информации посетите их сайт: modbus.org
Протокол Modbus можно назвать дедушкой промышленных сетей. Это действительно так же старо, как мир, и есть усы, чтобы доказать это. В нынешнюю эпоху подключения к Интернету и веб-сервисов неподключенные сообщения Modbus и простая структура связи запрос-ответ являются почти причудливыми. Первоначальный протокол почти так же стар, как и первый программируемый логический контроллер Modicon 084, который в те дни назывался ПК, от Programmable Controller (PLC).
Версия RTU является открытым стандартом, что означает, что производители могут встраивать ее в свое оборудование без уплаты роялти. Это наиболее распространенный коммуникационный протокол в промышленной автоматизации, и в настоящее время он является наиболее доступным средством подключения промышленных электронных устройств.
Modbus широко используется многими производителями во многих отраслях. Обычно он используется для передачи данных от контрольно-измерительных приборов к логическому контроллеру или системе архивации данных. Например, в автоматизации зданий температура и влажность часто передаются на компьютер для долгосрочного хранения. Протокол часто используется для подключения управляющего компьютера к удаленному терминалу (RTU) в Supervisory Control 9. 0125 и системы сбора данных (SCADA).
Простота является причиной столь широкого распространения Modbus. Не помешало и то, что Modbus был создан одним из крупнейших на тот момент производителей ПЛК и сделал его широкодоступным открытым стандартом. Он также требует очень мало места для кода процессора или ОЗУ. Хотя сегодня это не так важно, учитывая доступные нам мощные процессоры и технологии, это было очень важно в первые годы промышленной автоматизации, когда процессоры использовали 8-битную технологию, а такие ресурсы, как ОЗУ и ПЗУ, были чрезвычайно дорогими и дефицитными.
Проверка сообщений — еще одна причина популярности протокола. Циклически-избыточные контрольные суммы и продольные проверки избыточности означают, что ошибки передачи проверяются с точностью до 99%.
Версия RTU использует технологию клиент/сервер для связи между устройствами. Это означает, что любое приложение, использующее протокол RTU, будет иметь клиента и как минимум один сервер. Клиент обычно представляет собой управляющий хост-компьютер, на котором запущено программное обеспечение, которое взаимодействует с одним или несколькими серверными устройствами.
Modbus обеспечивает связь клиент/сервер между устройствами, подключенными через шины или сети. В модели OSI Modbus находится на уровне 7. Он предназначен для использования в качестве протокола запроса/ответа и предоставляет услуги, определяемые функциональными кодами. Функциональные коды протокола являются элементами блока данных протокола запроса/ответа.
Для создания блока данных приложения Modbus клиент должен инициировать транзакцию Modbus. Это функция, которая информирует сервер о том, какой тип действия следует выполнить. Формат запроса, инициированного клиентом, устанавливается протоколом приложения. Затем поле функционального кода кодируется одним байтом. Действительными считаются только коды в диапазоне от 1 до 255, а коды 128–255 зарезервированы для ответов на исключения. Когда клиент отправляет сообщение на сервер, это поле кода функции информирует сервер о том, какой тип действия необходимо выполнить.
Чтобы определить несколько действий, к некоторым функциям будут добавлены коды подфункций. Например, клиент может прочитать состояния включения/выключения группы дискретных выходов или входов. Он также может читать/записывать содержимое данных группы регистров. Когда клиент получает ответ сервера, поле кода функции используется сервером для указания либо безошибочного ответа, либо ответа исключения. Сервер откликается на запрос начального кода функции в случае нормального ответа.
Как и все остальное в Modbus, представление данных простое. На самом деле данные в Modbus представляются проще, чем в любом другом промышленном протоколе, который вы когда-либо встречали. Бит наименьшей важности отправляется и принимается первым. Все устройства в сети должны аналогичным образом интерпретировать каждый передаваемый байт.
Нет методов автоматического распознавания скорости передачи данных. Сервер(ы) и клиент, подключенные к шине, должны использовать одинаковую скорость передачи данных. В протоколе не указана конкретная скорость передачи данных: типичная скорость передачи данных составляет 9600 или 19200.
В Modbus существует только два типа данных: катушки и регистры. Катушки — это просто отдельные биты. Биты могут быть включены (1) или выключены (0). Некоторые катушки представляют собой входы, то есть они содержат состояние некоторого физического дискретного входа. Или они представляют выходы, что означает, что они содержат состояние некоторого физического дискретного выходного сигнала. Регистры — это просто 16-битные беззнаковые регистровые данные. Регистры могут иметь значение от 0 до 65535 (от 0 до FFFF в шестнадцатеричном формате). Нет представления для отрицательных значений, нет представления для значений больше 65535 и нет представления для реальных данных, таких как 200,125.
Регистры сгруппированы в регистры ввода и регистры хранения. Как и входные катушки, входные регистры сообщают о состоянии некоторого внешнего входа как значение от 0 до 65535. Первоначальное назначение входного регистра заключалось в том, чтобы отражать значение некоторого аналогового входа. Это цифровое представление аналогового сигнала, такого как напряжение или ток. Большинство современных устройств Modbus не являются устройствами ввода-вывода, и входные регистры просто функционируют идентично регистрам временного хранения.
Регистры хранения изначально были разработаны как временное хранилище программ для таких устройств, как контроллеры. Сегодня регистры хранения функционируют как хранилище данных для устройств.
Пакеты Modbus RTU предназначены только для отправки данных; у них нет возможности отправлять такие параметры, как имя точки, разрешение, единицы измерения и т. д. Если возможность отправки таких параметров необходима, следует изучить BACnet, EtherNet/IP или другие современные протоколы.
Подпишитесь на нашу серию электронных писем по обучению автоматизации, чтобы узнавать все тонкости ведущих промышленных протоколов в виде фрагментов размером в байт, которые раз в две недели отправляются на ваш почтовый ящик!
Стандартные адреса узлов RTU: 1–255, где 0 зарезервирован для широковещательных сообщений и только для записи. Однако адрес 0 используется редко, так как нет подтверждения того, что сообщение было правильно получено на узле сервера. Это не имеет большого эффекта, если ваш физический уровень — RS-232, так как в любом случае может быть реализован только один узел. RS-485 ограничивает количество узлов до 32, хотя некоторые драйверы позволяют увеличить это количество.
Последовательные серверные устройства Modbus идентифицируются по номеру станции, который предшествует общей структуре сообщения. Как правило, поддерживается до 32 станций, поскольку это предел, установленный большинством последовательных драйверов RS-485. Программное ограничение на количество поддерживаемых станций отсутствует. Действительные адреса серверов назначаются в диапазоне от 1 до 255 с номером станции 0, зарезервированным для широковещательных сообщений, сообщений, обрабатываемых всеми серверами.
Существует несколько стандартных транспортных уровней, используемых для перемещения сообщений протокола Modbus: RS-232 и RS-485. Можно использовать и другие, но эти самые распространенные.
RS-485 является преемником RS-232. Он работает аналогичным образом в отношении битов синхронизации, которые координируют передачу битов от отправляющей станции к принимающей. Однако есть две определяющие характеристики, которые отличают RS-485 от RS-232. Во-первых, это возможность управлять несколькими пунктами назначения. Передатчики RS-485 могут передавать электрические сигналы до 32 устройств назначения. Это делает RS-485 предпочтительным способом последовательной передачи сообщений Modbus.
Другой определяющей характеристикой RS-485 является повышенная помехоустойчивость. RS-485 не использует общую электрическую сеть в качестве эталона для своего электрического сигнала. Вместо этого RS-485 использует пару проводов и передает сигнал, устанавливая потенциал напряжения на паре. При этом любой электрический шум окружающей среды влияет на оба провода в равной степени, и потенциал на двух проводах не изменяется.
Механизм кодирования описывает, как формируются битовые комбинации из значений управления и данных, закодированных в пакете. И отправитель, и получатель должны использовать одну и ту же кодировку, чтобы правильно понять содержимое данных. Существует два механизма кодирования сообщений Modbus: ASCII и RTU.
Кодирование RTU является гораздо более распространенным механизмом кодирования, используемым в Modbus. RTU просто означает, что значения закодированы как стандартный двоичный код с обратным порядком байтов. Это означает, что в случае 16-битных значений старший значащий байт (MSB) кодируется перед младшим значащим байтом (LSB). 8-битное значение, такое как десятичное число 41 (29hex) кодируется просто как 0010 1001. Тогда как 16-битное значение, такое как десятичное число 300 (12C hex), кодируется как 0000 0001 0010 1100. MSB 01 кодируется и передается перед LSB 2C.
Modbus RTU Data Type | Common Name | Starting Address |
Modbus Coils | Bits, binary values, flags | 00001 |
Цифровые входы | Binary inputs | 10001 |
Analog Inputs | Binary inputs | 30001 |
Modbus Registers | Analog values, variables | 40001 |
Основное различие между Modbus RTU и Modbus TCP (также известными как Modbus IP, Modbus EtherNet и Modbus TCP/IP) заключается в том, что TCP работает на физическом уровне Ethernet, а RTU — это протокол последовательного уровня.