1. Главная страница » Компьютеры » Modbus ascii rs 485

Modbus ascii rs 485

Автор: | 16.12.2019

У контроллера 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 рейку: модулями входов и выходов, диммерами.

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

Читайте также:  Crysis 2 maximum edition обзор

Например, в программном обеспечении 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 просмотров сегодня

I have to read datas from some devices connected through a RS485-USB serial communication cable. The devices use modbus RTU except for one that uses modbus ASCII.
Can I speak two protocols on the same cable? I think RTU units do not reply to ASCII requests and vice-versa, but may this lead to problems? Does anyone tried this or had any experience?

I don’t have any device here to try and I have to setup everything directly at client’s place.

This would be my ideal configuration

If this doesn’t work I’ll have to switch to a solution like the following

that would be very problematic due to some constraints on hardware, cables and location.

3 Answers 3

the short answer is yes. You can speak as many protocols as you want on RS485 as long the messages doesn’t get ambiguous.

I have many PV inverters on a shared RS485 line and many other sensors which speak a complete different protocol. The two class of devices share the same line with no problem.

This may be a challenge. Get a copy of the spec here

  • according to the spec, Modbus ASCII commonly uses a 7 databits character format whereas Modbus RTU absolutely needs 8 databits. So, unless you can configure the Modbus ASCII devices to switch to an RTU-compatible character format 8 databits you’ll need to continuously switch the PC’s serial port between the two modes.
  • in Modbus ASCII each payload byte is encoded as two ASCII codes, in RTU each byte is send as a byte. This can lead to slaves being triggered by a byte transmitted in the other protocol they mistakenly interpret as their slave address. This can trigger them to reply with an error message, which can effectively knock out your communication. How bad this will be depends on the robustness of the modbus slave implementations and alternating between 7 bits and 8 bits character formats may help mitigating this problem.

I think you’ll have to try it and perform a realistic test that’s long enough to see whether it works well enough for your purposes.

Читайте также:  Dragon age 2 экспедиция на глубинные тропы

YES, this can be done, but it helps if you have the exact equipment to Verify the operation as you are developing the code.

I’ve come up with an "RS_232-485 Slave Simulator" in LabVIEW that will just listen on a Serial Port and capture the Requests, Parse them, and, if desired, provide a Hard-Coded response.

The KEY is that the Serial Parameters must all be the SAME: Baud, Parity, Bits, Stop-bits, etc. My default is 9600, None, 8, 1

This ALSO works for the ‘special’ RS-232 devices that use an ‘=’ and ‘#’ as the first character of the message.

This is very handy when setting up new equipment or software, writing Software Drivers for legacy equipment, and as a troubleshooting tool for existing systems.

= A few issues that can trip you up:

  1. Some RS-485 devices have the + and — identification of the communication lines WRONG,
  2. Not ALL devices need or will use the ‘extra stop bit’ when using No-Parity,
  3. Be aware when some DATA is using HEX codes versus ASCII codes — looks the same at first!

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

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

Читайте также:  Acer aspire switch 10 sw5 011

Примеры работы

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

×