У контроллера EasyHomePLC есть два порта RS485 и два порта RS232. У некоторого оборудования есть возможность управления по протоколу ModBus. Программное обеспечение EasyHome связывается с контроллером по протоколу Modbus TCP. Что всё это означает? Значит ли это, что если у контроллера есть интерфейс Modbus, и у устройства есть такой интерфейс, они сразу заработают вместе? Объясню максимально просто и понятно.
Содержание
RS-485
RS-485 — это стандарт физического уровня. Что это означает? Он определяет следующие параметры общения устройств:
- связь кабелем «витая пара» по двум жилам
- максимальная длина кабеля 1200 метров
- дискретные сигналы (либо 1, либо 0)
- если напряжение жилы А больше напряжения жилы В более, чем на 200 милливольт, то передаётся единица. Если наоборот, то ноль
- скорость общения может быть до 1 мегабита в секунду по одной витой паре и до 10 мегабит по двум витым парам
- максимальный ток 250 миллиампер
- напряжение от -7 до +12 вольт постоянного тока
- в один момент времени может передавать информацию только одно устройство в сети
То есть, стандарт подразумевает, что на 2-проводную шину (одну витую пару) можно подключить множество устройств. Он не описывает никакой язык общения оборудования.
RS-232
Другой стандарт, тоже по кабелю «витая пара». Не буду перечислять все параметры стандарта, он используется достаточно мало сейчас. В частности, все помнят мышки, которые подключались к компьютеру через широкий COM-порт, вот это как раз была связь по RS-232. К контроллерам EasyHomePLC и Beckhoff подключается GSM модем для приёма и отправки смс как раз через COM порт. Длина кабеля 1-2 метра.
Существуют переходники с RS-232 на RS-485 и обратно. Мы получаем возможность подключить на порт RS-232 что-то, что подключается по RS-485 или сделать длинную линию связи для устройств RS-232, поставив в начале линии переходник на 485, а в конце обратно.
ModBus
Переходим к более интересной вещи. Modbus — это уже протокол. Он определяет правила общения устройств. Например, он говорит, что одно устройство должно быть ведущим (master), а остальные ведомыми (slave). Ведущее посылает в шину связи сообщение определённого формата, в котором либо указан адрес нужного slave устройства, либо сообщение предназначено для всех устройств. Устройство slave, на которое отправлено сообщение, может ответить мастеру. Протокол регламентирует формат сообщения, его длину, возможные значения элементов сообщения. Есть также контрольная сумма, которая нужна для проверки того, что сообщение дошло неискажённым.
Но протокол ModBus не регламентирует, какими могут быть сами команды и какая среда передачи данных используется. Есть Modbus serial — это работа по RS485 или RS232. Есть Modbus TCP — это работа в компьютерной сети TCP/IP, где у каждого устройства есть IP адрес и порт.
Можно привести аналогию с человеческим общением. Среда передачи данных — это обычно звук. Стандарт подразумевает, что есть минимальная громкость и максимальная громкость, и громкость речи находится в этом диапазоне. Можно говорить по очереди, а можно одновременно. Есть некий диапазон скоростей передачи звуков, который может использоваться. Есть также диапазон частот звуков. Есть максимальное расстояние, на которое можно передавать звук. А можно общаться не звуком, а световыми вспышками, текстом, хлопками в ладоши или жестами. На каждый способ общения есть некий набор правил. Вот что определяет стандарт.
Протокол общения — это ещё не язык, нет. Протокол даёт нам такие понятия как то, что сообщение состоит из слов, разделяемых тишиной. Слова состоят из слогов. А ещё то, что в начале общения надо здороваться, а в конце прощаться. Говорить может только один в один момент времени. Как-то так.
И вот мы подошли к главному вопросу. У нас контроллер имеет порт (он же разъём, он же шлюз) RS485 и в него программно заложена возможность общения по Modbus. Также у нас есть кондиционер, у которого также есть физический разъём RS485 и в паспорте указана возможность работы по 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
Чем сложнее устройство, тем вариантов команд больше. В вентмашине или кондиционере их может быть до сотни. Также по протоколу RS485 мы можем общаться с инфракрасными приёмопередатчиками, генераторами, конвекторами, электрокарнизами, кондиционерами, термостатами, датчиками и различными элементами расширения контроллера на DIN рейку: модулями входов и выходов, диммерами.
Написать драйвер связи теоретически несложно, но это большая работа. Нужно предусмотреть нюансы работы техники, придумать удобный интерфейс управления и получения обратной связи, прописать в драйвере возможные коды ошибок. После подключения реального устройства может потребоваться доналадка, если не всё было учтено в инструкции или в драйвере. Стоимость этой работы может быть достаточно высокой, поэтому стоит обращать внимание на то, какие драйверы уже присутствуют в программном обеспечении, прилагаемом к контроллеру.
Например, в программном обеспечении EasyHome есть поддержка ИК-передатчиков ICPDas и Insyte, модулей связи с кондиционерами Mitsubishi и Daikin, конвекторов Varmann, счётчиков электричества Delta, блоков расширения Овен, Noolite, Razumdom, Bolid, вентмашин Komfovent и ещё много чего. Нужно смотреть конкретные поддерживаемые модели, у разных моделей разные спецификации команд.
Есть устройства с поддержкой Modbus TCP, там нужно, чтобы оно было включено в локальную сеть, отдельный порт RS485 контроллера не нужен.
К системам на Z-Wave напрямую ничего по Modbus не подключить, там нет такой возможности. Только используя промежуточный контроллер, который поддерживает и Modbus, и Z-Wave, например, Wiren Board.
Есть важная особенность работы устройств по Modbus. У Modbus есть устройство-мастер (это контроллер) и устройство-слейв (то, что к нему подключается). Слейв не может сам инициировать передачу данных, поэтому мастер постоянно опрашивает все подключенные к нему слейвы на предмет их состояния. Если у нас датчик подключен к дискретному входу устройства Овен МВ, то при изменении состояния датчика меняется состояние входа, но модуль не может сразу же сообщить об этом контроллеру, так как не может сам инициировать связь. Нужно дождаться, пока контроллер опросит этот модуль, тогда модуль отправит ему в ответ своё состояние и контроллер поймёт, что датчик изменил состояние и что-то сделает.
Что произойдёт, если на вход Овен МВ пришёл сигнал о сработке датчика, а потом датчик изменил состояние на первоначальное, а контроллер не успел его опросить? В программе модуля МВ есть счётчики количества сработок каждого входа, вот их-то контроллер и считывает, и видит, что было изменение.
Скорость опроса модулей контроллером ограничена, поэтому контроллер не мгновенно узнаёт о событии, это зависит от того, какая скорость опроса, насколько она оптимизирована, и сколько модулей расширения подключено к контроллеру. Если у нас очень много модулей, которых контроллер по очереди опрашивает, то весь цикл опроса занимает некоторое время, пока очередь нужного нам модуля не подойдёт, об изменении состояния мы не узнаем. А потом контроллер должен будет отправить нужную команду соответствующему модулю реле для изменения его состояния. У EasyHomePLC при количестве модулей расширения не более 5 максимальная задержка отрабатывания события не превышает 1.5 секунды, что достаточно быстро. Зависит от того, что опрашивалось в момент изменения состояния входа. У контроллеров Beckhoff связь между модулями расширения происходит по собственному протоколу связи, там независимо от количества модулей всё отрабатывает мгновенно.
Версии Modbus — TCP и RTU
Ещё раз обозначим разницу между версиями связи по ModBus.
Modbus RTU, он же Modbus Serial — работа по RS485 или RS232. Подключение устройств по витой паре, где контроллер мастер, а остальные устройства — слейвы, которые не могут сами инициировать связь. Самый распространённый вариант связи.
Modbus TCP или Modbus TCP/IP — общение устройств происходит по обычной компьютерной сети TCP/IP, включающей работу через интернет и через Wi-Fi. То есть, возможна связь между устройствами на любом расстоянии, когда оба подключены к интернет.
Есть ещё несколько разновидностей: Modbus RTU/IP (отличается от TCP наличием контрольной суммы), Modbus over UDP, Modbus Plus (собственный протокол фирмы Schneider Electric, в сети могут быть несколько мастеров).
18,918 просмотров всего, 20 просмотров сегодня
В данной статье будут рассматриваться основные характеристики протокола 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, #модбас, #особенности, #протокола
Если Вы не нашли то, что искали, сообщите об этом в комментарии
Благодаря универсальности и открытости, стандарт позволяет интегрировать оборудование разных производителей. Modbus используется для сбора показания с датчиков, управления реле и контроллерами, мониторинга, и т.д.
В статье разберем реализации протокола Modbus, форматы данных, программное обеспечение для работы с протоколом. Попробуем на практике прочитать данные из устройства.
История Modbus
Modbus был представлен в 1979 году компанией Modicon (ныне Schneider Electric). Это был открытый стандарт, работающий по интерфейсу RS-232. Позже появилась реализации протокола для интерфейсов RS-485 и Modbus TCP. Протокол быстро набрал популярность, и многие производители стали внедрять его в своих устройствах.
Позже права на протокол были переданы некоммерческой организации Modbus Organization, которая до сегодняшнего дня владеет стандартом.
В описании стандарта Modbus используются терминология, унаследованная от языков релейной логики. Так, например, некоторые регистры называются катушками (англ. coil).
Физический уровень
- RS-232/422/485 — последовательные интерфейсы, широко распространенные в промышленности. Интерфейсы RS-422/485 обеспечивают дальность сигнала до 1200 метров. Используются протоколы Modbus RTU/ASCII
- Сети TCP/IP — физическим каналом передачи данных могут любые ethernet-интерфейсы. Используется протокол Modbus TCP
Логический уровень
Различия протоколов Modbus
Modbus ASCII
Данные кодируются символами из таблицы ASCII и передаются в шестнадцатеричном формате. Начало каждого пакета обозначается символом двоеточия, а конец — символами возврата каретки и переноса строки. Это позволяет использовать протокол на линиях с большими задержками и оборудовании с менее точными таймерами.
Modbus RTU
В протоколе Modbus RTU данные кодируются в двоичный формат, и разделителем пакетов служит временной интервал. Этот протокол критичен к задержкам и не может работать, например, на модемных линиях. При этом, накладные расходы на передачу данных меньше, чем в Modbus ASCII, так как длина сообщений меньше.
Modbus TCP
Структура пакетов схожа с Modbus RTU, данные также кодируются в двоичный формат, и упаковываются в обычный TCP-пакет, для передачи по IP-сетям. Проверка целостности, используемая в Modbus RTU, не применяется, так как TCP уже имеет собственный механизм контроля целостности.
Формат пакета
Форматы пакета разных реализаций Modbus
Все устройства Modbus взаимодействуют, следуя модели master-slave. Запросы может инициировать только master-устройство, slave-устройства могут только отвечать на запросы, и не могут самостоятельно начинать передачу данных. В зависимости от реализации протокола, заголовки пакета различаются. Вот основные составляющие пакета, которые важно знать:
ADU (Application Data Unit) — пакет Modbus целиком, со всеми заголовками, PDU, контрольной суммой, адресом и маркерами. Отличается, в зависимости от реализации протокола.
PDU (protocol data unit) — основная часть пакета, одинаковая для всех реализаций протокола. Содержит сам payload.
Адрес устройства — адрес получателя, то есть slave-устройства. В одном сегменте Modbus-сети могут находится до 247 устройств. Только slave-устройства имеют различающиеся адреса, master-устройство не имеет адреса. Адрес «0» используется для широковещательных запросов от master, при этом, slave-устройства не могут отвечать на эти широковещательные пакеты.
Контрольная сумма — алгоритмы проверки целостности пакетов. В Мodbus RTU и ASCII используется 2 байта контрольной суммы. В Modbus RTU применяется алгоритм CRC16, в Modbus ASCII — более простой и менее надежный LRC8. В Modbus TCP контрольная сумма не добавляется в ADU, так как целостность проверяется на уровне TCP.
Мы не будем разбирать дополнительные заголовки, специфичные для каждой отдельной реализации протокола, так как это не имеет существенного значения при работе с протоколом на прикладном уровне.
Регистры и функции Modbus
В упрощенном виде, структура запросов Modbus состоит из кода функции (чтение/запись), и данных, которые нужно считать или записать. При этом, коды функции различаются для разных типов данных. Разберем, какие бывают регистры, и функции для работы с ними.
- Discrete Inputs — дискретные входы устройства, доступны только для чтения. Диапазон адресов регистров: с 10001 по 19999. Имеют функцию «02» — чтение группы регистров
- Coils — дискретные выходы устройства, или внутренние значения. Доступны для чтения и записи. Диапазон адресов регистров: с 20001 по 29999. Имеет функции: «01» — чтения группы регистров, «05» — запись одного регистра, «15» — запись группы регистров
- Input Registers — 16-битные входы устройства. Доступны только для чтения. Диапазон адресов регистров: с 30001 по 39999. Имеют функцию: «04» — чтение группы регистров
- Holding Registers — 16-битные выходы устройства, либо внутренние значения. Доступны для чтения и записи. Диапазон адресов регистров: с 40001 по 49999. Имеют
Несмотря на названия, входы и выходы могут на самом деле являться внутренними переменными, хранить счетчики, флаги, или быть управляющими триггерами. Существуют также и другие диапазоны регистров, но в подавляющем большинстве устройств они не используется, поэтому мы рассмотрим четыре основных типа регистров. В разных устройствах могут быть задействованы разные диапазоны регистров, или же все сразу.
Примеры работы
Для примера работы с протоколом Modbus TCP воспользуемся максимально простой консольной утилитой modbus-cli, написанной на языке Ruby. Она позволяет легко читать и писать данные в регистры Modbus.
Попробуем прочесть состояние счетчиков переданных пакетов на промышленном коммутаторе Advantech EKI-5524SSI. Для начала необходимо определить адреса регистров, хранящие нужную информацию, для этого заглянем в документацию устройства. Описание регистров находятся в разделе «Modbus Mapping Table»:
Описание значений регистров в документации коммутаторов EKI
Видно, что значение переданных пакетов для одного порта хранится в четырех регистрах, и для первого порта это регистры с 38193 по 38197. Также дано описание формата хранения данных, из которого следует, что целое число переданных пакетов хранится шестнадцатеричном формате, и значение 11223344 пакетов будет записано как 0xAB4130, справа налево.
read — команда чтения. Программа сама понимает, какую конкретно команду чтения использовать в зависимости от адреса регистра, в нашем случае будет использована команда «04», для чтения 16-битных регистров.
192.168.0.17 — IP-адрес устройства.
38193 — начальный адрес регистра.
4 — смещение относительно начального адреса. Мы читаем четыре регистра для порта 1, как следует из даташита.
Получаем ответ, содержащий значения четырех регистров. Видим, что число пакетов невелико: 0x3459, то есть 13401, — коммутатор был включен недавно.
Недостатки протокола Modbus
Справедливости ради, стоит упомянуть и о недостатках протокола. Так как он разрабатывался более 40 лет назад, когда производительность процессоров была существенно ниже и протоколы разрабатывались без учета защиты данных, он имеет рад минусов:
- Протокол не предусматривает аутентификацию и шифрование передаваемых данных. Поэтому, при использовании Modbus TCP необходимо использовать дополнительные VPN-тоннели.
- Slave-устройство не может инициировать передачу данных, поэтому master должен постоянно опрашивать ведомые устройства
- Slave-устройство не может обнаружить потерю связи с Master. Эта проблема напрямую следует из предыдущей.
Однако, несмотря на все недостатки, Modbus по-прежнему остается самым распространенным промышленным протоколом, и благодаря открытости, позволяет легко объединять устройства разных производителей. Нетребовательность к ресурсам позволяет интегрировать протокол в самые маломощные устройства.
Оборудование с поддержкой Modbus
Advantech предлагает широкий спектр промышленного оборудования с поддержкой протокола Modbus для любых задач: автоматизации, управления, сбора и передачи данных.
ADAM-6000 и WISE-4000 — модули удаленного ввода-вывода
Модули серии ADAM-6000 и WISE-4000 позволяют удаленно управлять цифровыми и аналоговыми входами/выходами по протоколу Modbus TCP. Используются для управления периферийными устройствами и сбора данных в режиме slave. Могут работать в паре с программируемым логическим контроллером, или подключаться напрямую к SCADA-серверу.⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
EKI-1200 — Modbus-шлюзы для преобразования интерфейсов
Для преобразования протоколов Modbus RTU/ASCII в Modbus TCP, используются Modbus шлюзы. Устройства серии EKI-1200 имеют на борту до четырех последовательных интерфейсов RS-232/422/485, и два Ethernet-порта. Они позволяют объединить в одну сеть устройства с разными протоколами. Например, подключить slave устройство, поддерживающее только Modbus RTU, по интерфейсу RS-485 к сегменту сети Modbus TCP.
APAX-5000, ADAM-3600, WISE-5000 — контроллеры автоматизации
Контроллеры поддерживают функции Modbus RTU в качестве slave/master и клиента/сервера Modbus TCP.
Примеры применения
Система мониторинга теплиц
Решение Advantech для мониторинга интегрирует устройства TPC-1070H, ADAM-6024, ADAM-6050, ADAM-6060 и программное обеспечение WebAccess в машинном шкафу рядом с сельскохозяйственными угодьями. Соединяясь с различными чувствительными устройствами, модули ADAM-6000 могут в режиме реального времени получать данные об окружающей среде и контролировать переключение оборудования, чтобы гарантировать, что теплица находится в оптимальной среде для роста растений. Благодаря особой функции Advantech — графической логике условий (GCL), пользователи могут определять свои собственные правила логики управления и загружать эти правила в модули ввода / вывода Ethernet ADAM-6000, а затем модули автоматически выполняют логические правила, как автономные модули. контроллер. Еще одна особенность — Peer-to-Peer (P2P) использует наиболее открытую и гибкую сеть Ethernet, чтобы не только упростить процесс внедрения без контроллера, но и сэкономить затраты на аппаратное оборудование.
Все полученные данные затем передаются через Ethernet на компьютер с сенсорной панелью TPC-1070H. Благодаря системе охлаждения без вентилятора и передней панели, соответствующей стандарту IP65, TPC-1070H представляет собой прочную и компактную конструкцию, подходящую для изменяемой операционной среды, а его мощные вычислительные возможности способны обрабатывать большие объемы данных. Для управления устройствами Advantech WebAccess позволяет инженерам или менеджерам просматривать, контролировать и настраивать систему мониторинга через интрасеть или Интернет с помощью обычного веб-браузера с любого устройства, включая планшеты и смартфоны.
Мониторинг системы нагрева воды солнечной энергией
Инжиниринговая компания должна была иметь возможность контролировать количество солнечной энергии, температуры и расход воды в системе нагрева воды на солнечной энергии для бассейна олимпийских размеров, обеспечиваемого их недавно разработанной солнечной панелью. Они также должны были иметь возможность непосредственно отслеживать эти значения и их аварийные сигналы на ЖК-панелях и сохранять эти значения для дальнейшего использования.
Модули Adam от Advantech предоставили заказчику решение, в котором использовались модули сбора данных, подключенные через RS485, и двухпроводная шина для передачи данных со всех датчиков. Эта системная архитектура имеет два основных преимущества: во-первых, она позволяет в любое время добавлять в систему большее количество датчиков модулей сбора данных, и, во-вторых, очень легко добавлять дополнительные метки в программное обеспечение для мониторинга и записи этих значений на ПК.
