Как написать драйвер modbus
Обновлено: 06.07.2024
Простая реализация Модбас-стека на MSP430. Часть первая: Modbus (RTU). Часть вторая здесь
А потом пришла третья часть — с подчищеной библиотекой.
Что бы там ни говорили о «старости» Модбаса, он является очень хорошим и заслуженно популярным протоколом в системах промышленной автоматизации. Поэтому полезно иметь возможность использовать Модбас в МК-девайсах, согласных на скромную роль Слейва. Для такого Слейва я и написал Модбас стек. И хотя мой МК — это достаточно новый и еще не очень популярный ФРАМ-камешек из семейства MSP430FR57xx, программу можно портировать и на другие МК.
Хорошо известна библиотека от Кристиана Вольтера, которую я раньше использовал для проекта на Атмеге168. Тем, кто действительно понимает Си, она может оказаться оптимальной. Я программирую примитивно и все время работы с этой библиотекой ощущал себя туземцем, которому дали мобилку, а он только и умеет, что нажать в ней одну кнопку и ответить на вызов. А потом пришло время для MSP430 — а в библиотеке Вольтера как раз для этих МК варианта нет. Ну, и слава Богу. Ленивым толчок в зад, чтобы сами чьой-то делали.
Еще поделюсь вот этой ссылкой. Она, оказывается, лежала у меня давно, но нашел ее только сейчас, когда начал писать эту заметку. Там есть весьма неплохие реализации (в том числе и Мастера!), спокойное обсуждение… Почитайте. Меня подкупило использование структуры для хранения всех переменных стека — это открывает возможность легко плодить несколько слейвов, если в МК есть более одного УАРТа. Такой же подход я видел в примере от уважаемого коллеги reptile, который как-то прислал мне свою реализацию.
Но я сделал по-своему. Просто подошел с чистого листа, озабоченный именно простотой и понятностью (хотя бы для меня!) реализации.
1. Протокол Модбас
Несколько слов о том, что собой представляет этот Модбас. Кто знаком с протоколом — читайте с п.2. Я изложу все очень нестрого, уделяя внимание простоте и краткости.
Замечу. что я опираюсь на "Руководство по имплементации Модбаса в последовательных каналах передачи данных", а также "Спецификацию приложений, работающих по Модбасу". Я только что был поражен также обилием инфо на русском, дав Гуглю запрос «Введение в Модбас протокол» :) Что там кому понравится — смотрите сами.
Протокол достаточно прост. Он описывает обмен между устройствами, причем реализована система «Мастер-Слейв» (Ведущий-Ведомый, Главный-Подчиненный, Начальник-Дурак). Обмен всегда начинает Мастер: он делает запрос, Слейв отвечает. Нет запроса — нет ответа. Это раз.
Второе: обычно на запрос должен быть ответ. Исключение — широковещательный запрос, но это пока забудем. То есть, если Мастер даже не запросил данные, а наоборот — пихнул их Слейву, то все равно Слейв по получению должен отписаться, мол, все гут, командир, запрос от тебя получен, данные принял, столько-то байт. Не будет такого ответа — Мастер выждет таймаут и посчитает, что Слейв недопонял. Может начать повторами долбить, может вычеркнуть Слейва из числа живущих, может еще чего — стандарт не оговаривает.
Третье: я рассматриваю только один режим работы Модбаса — Modbus RTU. Есть еще и другие режимы, но при работе по RS-232 или RS-485 именно Modbus RTU должен быть в каждом устройстве, как обязательный. Он и является самым популярным.
Итак, запрос-ответ. В ходе такого акта общения данные либо тудЫ, либо сюдЫ. Что за данные? Да простые, цифровые коды. Либо это отдельные биты информации (в далекие времена им отвечали обмотки реле, катушки, потому по-аглицки до сих пор их называют Coils), либо 16-разрядные слова, несущие информацию из т.н. регистров. Как катушки, так и регистры имеют свои адреса, номера. В стандарте много сделано, чтобы запутать православных, но скажу просто: адрес — двухбайтное число. От 0 до сами знаете…
Какова структура запроса и ответа? Общая структура передаваемого от Мастера запроса такова (каждая строка — это один символ):
Ответ от Слейва:
Адрес
03 (код функции)
Количество байт — значений регистров (2N)
Значение регистра с начальным номером (старший байт)
Значение регистра с начальным номером (младший байт)
…
Значение последнего регистра (старший байт)
Значение последнего регистра (младший байт)
Контролька CRC, младший байт
Контролька CRC, старший байт
Несмотря на то, что количество регистров передается двумя байтами, допустимое значение этого параметра — от 1 до 125. Поэтому в ответе число байт 2N (которое вдвое больше числа регистров), передается одним байтом. Что-то они там недопили, когда придумывали эту команду…
Иллюстрация (здесь не показаны ни байт адреса. ни 2 байта контрольной суммы):
Запись в регистры — симметрично команде 03. Тоже блок регистров.
Адрес
16 или 0х10 (код функции)
Начальный номер регистра (старший байт)
Начальный номер регистра (младший байт)
Количество регистров в блоке (старший байт)
Количество регистров в блоке (младший байт)
Количество байт - значений регистров (2N)
Значение регистра с начальным номером (старший байт)
Значение регистра с начальным номером (младший байт)
…
Значение последнего регистра (старший байт)
Значение последнего регистра (младший байт)
Контролька CRC, младший байт
Контролька CRC, старший байт
Ответ от Слейва:
Адрес
16 (код функции)
Начальный номер регистра (старший байт)
Начальный номер регистра (младший байт)
Количество регистров в блоке (старший байт)
Количество регистров в блоке (младший байт)
Контролька CRC, младший байт
Контролька CRC, старший байт
не знаю, с какого бодуна, но здесь максимальное число регистров — 123. Почему не одинаково с командой 03 — х.з.
Иллюстрация:
Вот и все. Вы знаете теперь достаточно об этом протоколе, чтобы рассмотреть программную реализацию работы Слейва.
Подытожу, рассматривая теперь процесс обмена с точки зрения работы Слейва:
— имеем на борту: буфер для размещения принятых и отправляемых фреймов. Его размер — максимум 256 байт. Если хотите работать с числом регистров, существенно меньшим 252, то можете и буфер ограничить. Все равно при приеме проверяем, не переполнился ли буфер;
— ждем первого символа (от Мастера) и по нему начинаем принимать фрейм. Как вариант — сразу фильтруем, наш ли адрес и можем не принимать все что дальше. Но ждать завершающий период тишины t3.5 все равно придется;
— каждый раз, когда символ принят, запускаем таймер для того, чтобы отловить событие: прошло уже t1.5 или t3.5;
— если возникло событие «прошло уже t1.5», а потом пришло начало следующего импульса — фиксируем печальный приговор: «Данный фрейм фтопку», но продолжаем принимать до конца, ибо что ж делать, конец-то должен быть, чтобы было новое начало :)
— если возникло событие «прошло уже t3.5», то заканчиваем принимать фрейм, разбираем его и наполняем (тот же) буфер ответом.
— забрасываем первый байт в буфер передатчика УАРТ, не забыв развернуть драйвер шины RS-485 на передачу;
— когда весь ответ выползет, развернем драйвер шины на прием. В принципе, теперь мы должны отстучать часиками тот же t3.5, но я ставлю программу на прием новых запросов сразу же. Все равно Мастер дождется паузы, потом рассмотрит ответ Слейва, а уж потом что-то может спрашивать.
Как все это реализовано у меня — расскажу во второй части. Сначала посмотрим, как вы покритикуете вступление, подправим все это дело, а к тому времени и программу опишу.
Протокол Modbus довольно распространен как в промышленных системах автоматизации, так и сетях систем типа "Умный дом", автоматизации малых объектов (теплицы и т.п.) и стыковки различного оборудования с домашним компьютером. Появление таких проектов как Arduino и Raspberry Pi значительно повысило интерес к задачам, связанным с робототехникой, автоматикой и автоматизацией. Все это обеспечивает рост популярности Modbus среди любителей и профессионалов. В статье рассмотрен вопрос тестирования и наладки, как отдельных устройств, так и сетей на базе протокола Modbus с позиции требований к программному обеспечению для решения таких задач и обзора существующих инструментов.
Если вы знакомы с архитектурой протокола, то можете смело пролистать пару следующих абзацев и перейти к дальнейшему описанию. Если же нет, то специально для вас ниже приведено небольшое введение в Modbus.
Modbus является довольно распространённым протоколом в системах автоматизации на среднем и нижнем (полевом) уровнях. Средний — это уровень контроллеров — устройств, осуществляющих сбор данных и управление технологическим процессом. Нижний или полевой — это уровень взаимодействия датчиков и контроллеров или датчиков напрямую с сервером. Более подробно об уровнях в системах автоматизации можно посмотреть здесь.
Как правило, структура типовой системы автоматизации, использующей в качестве базового протокола Modbus, выглядит так как показано на рисунке в начале статьи. В качестве ”среды” для протокола Modbus может выступать либо RS-485/422/232 (подробно про RS-485 можно прочитать здесь и здесь), поверх него работает Modbus RTU или Modbus ASCII, либо транспортный протокол TCP в TCP/IP сетях, такая версия носит название Modbus TCP. В данной статье будет рассмотрен Modbus RTU.
Протокол Modbus предполагает наличие одного ведущего устройства в сети (оно называется Master или Client) и от 1 до 247 ведомых (они называются Slave или Server). Полное описание можно найти на официальном сайте или в вики.
Master периодически взаимодействует со Slave-устройствами, считывая или записывая в них какую-либо информацию. Этот процесс осуществляется в форме запрос-ответ. Запрос представляет собой последовательность байт, называемую кадром, в котором время между байтами стандартизировано и зависит от скорости передачи данных (напомним, что речь идет о Modbus RTU) и составляет не более длительности интервала, в течение которого может быть передано 1,5 байта данных. Время между кадрами должно быть не меньше времени передачи 3,5 байт.
Формат запроса имеет следующий вид:
ID — адрес устройства (1 байт),
FN — Modbus функция (1 байт),
[args] — аргументы функции (N байт, зависит от функции),
CRC — контрольная сумма CRC-16 (2 байта).
Ответ имеет схожий формат:
Почти все поля ответного кадра аналогичны кадру запроса, за исключением поля DATA, оно имеет различное наполнение, в зависимости от функции.
Если устройством не поддерживается запрашиваемая функция или аргументы в поле [args] запроса являются некорректными для данного Slave-устройства, то в ответе, в поле FN старший бит будет выставлен в 1 (т.е. на FN наложится маска 0x80), а в поле DATA будет помещена дополнительная информация об ошибке.
Каждое Slave-устройство может иметь определенные области данных и содержать дополнительную специфическую информацию.
Возможные области данных представлены в таблице ниже:
| Поле | Доступ | Размер | Описание |
|---|---|---|---|
| Discrete Inputs | Только чтение | Один бит | Данные от системы ввода/вывода |
| Coils | Чтение/Запись | Один бит | Ячейки могут использоваться по своему усмотрению |
| Input registers | Только чтение | 16 бит | Данные от системы ввода/вывода |
| Holding registers | Чтение/Запись | 16 бит | Регистры могут использоваться по своему усмотрению |
За более подробной информацией следует обратиться к полному описанию Modbus RTU, доступному в виде спецификации.
Как при разработке, так и при наладке устройств с поддержкой протокола Modbus RTU, вам необходимо иметь специализированное программное обеспечение и технические средства. Из технических средств наиболее простой вариант — это преобразователь RS-485/USB, из всех устройств такого типа, по нашему мнению, наилучшим выбором является MOXA UPORT 1130/UPORT 1150, цена вопроса которого составит 5000 — 6000 руб. Существуют различные отечественные решения, например, преобразователи фирмы Fractal или ОВЕН. Конструкция этих устройств достаточно проста, и при определенной сноровке такой преобразователь можно собрать самостоятельно. Более сложными являются решения типа Ethernet/RS-485 (например, NPORT от MOXA).
При разработке устройств с поддержкой Modbus RTU, чаще всего требуется реализовать функцию Slave, так как в основном это различные датчики, управляемые реле, модули ввода/вывода и т.п., Master-устройства создаются реже. В сетях автоматизации в качестве мастера, обычно выступает контроллер, а он, как правило, уже имеет реализацию Modbus-стека, либо OPC Server/SCADA система, укомплектованные Modbus-драйвером.
Вопрос разработки непосредственно Modbus-стека мы не будем рассматривать в этой статье. Единственное, стоит отметить библиотеку FreeMODBUS, на базе которой достаточно просто построить устройство с поддержкой функций Modbus Slave. Пример реализации описан в статье на Хабре.
Вторым важным моментом при разработке Modbus-устройств является тестирование. Здесь всё зависит от стадии разработки и цели тестирования.
На начальных этапах полезным инструментом является Modbus-терминал. С помощью него мы можем вручную сконструировать запрос, послать его и проанализировать ответ. Существуют терминалы в чистом виде, например, SmartTerminal, Access Port, терминалы с поддержкой Modbus RTU — Termite от S2-Team или Pic18 Terminal от Fractal (не обновлялась с 2006 года) и т.п. Последний заточен под оборудование компании Fractal, но позволяет “общаться” с любыми устройствами, у которых в настойках порта выставлена четность None, с другими вариантами он не работает.
В процессе разработки нередко возникает ситуация, когда устройство принимает запрос и отвечает на него (это можно понять либо по светодиодам приема/передачи пакетов, если вы их предусмотрели в конструкции, либо через отладчик, поставив breakpoint в нужном месте), а в терминале или какой-то другой специализированной программе, данные не отображаются. В таком случае вам пригодится сниффер для последовательного порта, желательно, с поддержкой протокола Modbus. В качестве примера можно привести Free Serial Analyzer, COM Port Toolkit. Последний в настоящее время, похоже, прекратил свое развитие.
Следует учитывать, что собранные логи нужно будет анализировать, то есть определять количество запросов, на которые устройство не ответило, обнаруживать сбои, например, самопроизвольное изменение данных в ячейках и т.п. Конечно, можно использовать полноценную SCADA-систему, либо самому разработать и написать систему анализа и визуализации логов. Как вариант, рекомендуем обратить внимание на MasterSCADA от Insat. Она имеет встроенный Modbus-драйвер и версия до 32 точек является бесплатной, довольно проста в освоении (на сайте производителя есть хорошая документация и видео уроки).
В конце данной статьи мы определим список функций “идеального” инструмента для тестирования и наладки устройств/систем на базе протокола Modbus, а также сделаем небольшой обзор существующих инструментов.
Людей, занимающихся наладкой систем автоматизации и просто пытающихся “подружиться” с каким-либо устройством, на борту которого находится Modbus, в разы больше чем, тех, кто эти устройства разрабатывает. Исходя из специфики задачи, требования к соответствующему ПО будут немного отличаться.
Если необходимо соединить контроллер и одиночное Slave-устройство, то прежде всего, нужно установить с ним связь с помощью преобразователя интерфейсов RS-485/USB, ПК и специализированного программного обеспечения либо терминала. В таком случае, логика работы и набор инструментов ничем не отличается от тех, что применяются при разработке Slave-устройства на стадии тестирования. На этом этапе не требуется длительное тестирование с последующим анализом большого количества лог-файлов.
В случае, когда у вас уже есть готовая сеть устройств, можно выделить следующие задачи:
В этом случае, понадобится либо терминал с возможностью создания списка запросов, либо специализированный инструмент типа Modbus Poll, который позволяет опрашивать несколько устройств в рамках одного проекта.
Modbus-устройства могут иметь определенные настройки интерфейса RS-485: количество бит данных, четность и количество стоп бит. Устройства с различными настройками не могут работать в одной сети с одним и тем же мастером. Тестирование и конфигурирование таких устройств удобно проводить, применяя терминальные программы, имеющие возможность быстрого переключения между предустановленными профилями настроек портов или работающие с несколькими линиями одновременно.
Реже возникает задача организации обмена данными с устройством, протокол которого отличается от стандартной спецификации Modbus RTU. Нам приходилось встречаться с ситуацией, когда протокол Slave-устройства логически повторяет Modbus (структура пакета, таймауты и т.п.), но использует функции вне стандарта. В таком случаем возможна работа с использованием Modbus Poll, он позволяет строить произвольные запросы, или терминала, обладающего сходным функционалом. Стандартная SCADA-система, обычно, в такой ситуации бессильна, и работа с подобным оборудованием осуществляется через специальный OPC сервер.
Описав различные задачи, которые возникают при разработке, настройке и наладке устройств с протоколом Modbus, составим список требований к специализированному программному обеспечению.
- Поддержка настроек COM-порта (номер, скорость, четность, количество бит данных и стоп бит)
- Настройка таймаутов (время ожидания приема ответа на запрос, время между символами и кадрами)
- Поддержка стандартного Modbus
- Поддержка нестандартного Modbus
- Авто-опрос одного/нескольких устройств
- Настройка авто-опроса
- Логирование сессии / настройка логирования
- Создание профилей для быстрого переключения между настройками порта
- Работа в режиме сниффер
- Лицензия продукта
- Сопровождение продукта разработчиком
Modbus Poll
Начнем с классического приложения и довольно известного в наших “узких” кругах — Modbus Poll от Witte Software.
Эта программа является симулятором мастера в Modbus-сети. Интерфейс Modbus Poll интуитивно понятен. Если вы представляете себе логику работы протокола, то разобраться с программой труда не составит.
| Функция | Наличие | Комментарий |
|---|---|---|
| Поддержка настроек COM-порта | + | |
| Настройка таймаутов | + | Доступны: время ожидания ответа |
| Поддержка стандартного Modbus | + | Список функций ограничен |
| Поддержка нестандартного Modbus | + | |
| Авто-опрос одного / нескольких устройств | + / + | |
| Настройка авто-опроса | + | Доступно: время между запросами |
| Логирование сессии / настройка логирования | + / + | |
| Создание профилей для быстрого переключения между настройками порта | - | |
| Работа в режиме сниффер | - | |
| Лицензия продукта | ПО платное | Есть пробный период 30 дней |
| Сопровождение продукта | + |
Достоинства: хорошая система логирования, достаточное количество поддерживаемых функций (во всяком случае, наиболее востребованные присутствуют), большое количество настроек внешнего вида.
Недостатки: цена (одна лицензия $ 129.00), нестандартный Modbus поддерживается как опциональная функция, нет профилей для быстрого переключения портов — приходится каждый раз перенастраивать соединение.
Modscan32/64
Следующим ПО в нашем обзоре будет Modscan от WinTECH. Внешне эта программа очень похожа на Modbus Poll, но функционалом она обладает значительно меньшим.
У Modscan есть одна уникальная особенность для программ данного типа — это возможность создания форм (своего рода мнемосхем). Пока ее функционалу далеко до реальных SCADA-систем, но наличие такого бонуса радует. На сегодняшний день это достаточно скудный, по своим возможностям инструмент (имеется ввиду редактор форм), но будем надеяться, что со временем, разработчики доведут его до хорошего уровня.
| Функция | Наличие | Комментарий |
|---|---|---|
| Поддержка настроек COM-порта | + | |
| Настройка таймаутов | + | Доступны: время ожидания ответа |
| Поддержка стандартного Modbus | + | Список функций ограничен |
| Поддержка нестандартного Modbus | - | |
| Авто-опрос одного / нескольких устройств | + / + | |
| Настройка авто-опроса | + | Доступно: время между запросами |
| Логирование сессии / настройка логирования | + / - | |
| Создание профилей для быстрого переключения между настройками порта | - | |
| Работа в режиме сниффер | - | |
| Лицензия продукта | ПО платное | Есть пробный период |
| Сопровождение продукта | + |
Достоинства: возможность создания собственных форм для просмотра данных, поддержка MMI & OLE Automation.
Недостатки: цена (одна лицензия $ 84.95), нет поддержки нестандартного Modbus, нет профилей для быстрого переключения портов, ненастраиваемая система логирования, малое количество поддерживаемых Modbus-функций.
Termite
| Функция | Наличие | Комментарий |
|---|---|---|
| Поддержка настроек COM-порта | + | |
| Настройка таймаутов | + | Доступны: время ожидания ответа, время между символами и кадрами |
| Поддержка стандартного Modbus | + | |
| Поддержка нестандартного Modbus | + | |
| Авто-опрос одного / нескольких устройств | + / + | |
| Настройка авто-опроса | + | Доступно: время между запросами |
| Логирование сессии / настройка логирования | + / - | |
| Создание профилей для быстрого переключения между настройками порта | + | |
| Работа в режиме сниффер | - | |
| Лицензия продукта | Есть платная и бесплатная версии | Бесплатная версия обладает ограниченным функционалом (на количество каналов, одновременно ведомых лог файлов и количество разных запросов в авто-опросе) |
| Сопровождение продукта | + |
Достоинства: поддержка всех Modbus-функций, работа с нестандартным Modbus, удобная система подсказок, возможность настройки внешнего вида ПО, поддержка профилей для быстрого переключения между настройками порта.
Недостатки: PRO версия платная (одна лицензия $ 10), в текущем релизе нет возможности гибко настраивать логирование.
AccessPort
Программа из разряда “чистых” терминалов. Она не поддерживает Modbus, поэтому при её использовании будьте готовы считать CRC для ваших кадров самостоятельно. Несомненным плюсом является то, что в неё встроен сниффер последовательного порта.
| Функция | Наличие | Комментарий |
|---|---|---|
| Поддержка настроек COM-порта | + | |
| Настройка таймаутов | + | |
| Поддержка стандартного Modbus | - | |
| Поддержка нестандартного Modbus | - | |
| Авто-опрос одного / нескольких устройств | + / - | |
| Настройка авто-опроса | + | Доступно: время между запросами |
| Логирование сессии / настройка логирования | + / - | |
| Создание профилей для быстрого переключения между настройками порта | - | |
| Работа в режиме сниффер | + | |
| Лицензия продукта | ПО бесплатное | |
| Сопровождение продукта | Не поддерживается | Крайняя версия продукта была выпущена 2012-04-23 |
Достоинства: наличие сниффера порта, ПО бесплатное, настраиваемое представление данных, возможность передачи файлов.
Недостатки: не поддерживает Modbus вообще, нет возможность создавать профили, в режиме авто-опрос можно работать только с одним устройством, в настоящее время ПО не развивается.
В заключение хотелось бы добавить, что в сети достаточно большое количество программ для работы с последовательным портом, но если есть необходимость работать именно с Modbus протоколом, то его поддержка в таком ПО крайне желательна. Одна из основных причин — это расчет CRC, в ручную это делать накладно, также важно, чтобы программа могла уметь разделять кадры, иначе все превращается в сплошную мешанину байтов, ну и если есть авто-опрос, то это сильно упрощает жизнь.
Давно хотел рассказать про тонкости программирования обмена по протоколу Modbus RTU в случае, когда контроллер (в нашем случае S7-1214) выступает RTU Master'ом. Недавно меня попросили помочь с обменом между ПЛК и частотным преобразователем Sinamics V20, ну и почему бы не написать заодно заметку, постаравшись приблизить решение задачи к боевым условиям.
Собственно говоря, сами немцы эту тему давно осветили:
Смотрите этот пример, он сделан очень толково, с визуализацией, диалогами и квестами и возможностью расширить прикладную программу до опроса множества ПЧ V20 по нескольким интерфейсам (S7-1200 позволяет установить в свою корзину до 4 портов RS-485/422). Пример сделан очень хорошо и очень педантично. Вопросов коммуникаций по протоколу Modbus TCP я уже касался ранее, они есть на Хабре.
Поэтому некоторые нюансы я повторно объяснять не буду, просто сразу напишу, как стоит делать правильно и удобно с моей точки зрения конкретно в случае опроса V20. Первоначальная настройка преобразователя частоты описана в документации, в том числе и в сопутствующей документации к вышеуказанному примеру. Вынесем лишь важные для нас пункты в качестве вводных.
Адрес подчиненного устройства модбас в сети: 1
Регистры хранения подчиненного устройства для чтения:
40110 ZSW «Слово состояния»
40111 HIW «Текущая скорость»
Регистры хранения для записи:
40100 STW «Слово управления»
40101 HSW «Задание скорости»
Параметр частотника «Telegram off time (ms)» P2014[0] рекомендую оставить по умолчанию, равным в 2000 мс (2 секунды), хоть пример и рекомендует снизить эту величину до 130 мс. Конкретно к протоколу Modbus это замечание не относится, разумеется, просто у меня при таймауте в 130 мс, ПЧ терял связь и выдавал ошибку Fault 72.
С частотником разобрались. Теперь о моей конфигурации ПЛК. Это S7-1214 с коммуникационным модулем 1241 под RS-485/422:
Среда программирования Step 7 V15.1 Update 4, версия прошивки CPU — 4.3.
Итак, приступим. Для опроса подчиненных устройств с контроллера Simatic нам необходимо применить два функциональных блока: Modbus_Comm_Load (единовременно, только для конфигурации коммуникационного процессора) и Modbus_Master (циклически для чтения и/или записи регистров/катушек). Поэтому в программе экземпляр FB Modbus_Comm_Load у нас будет встречаться только один раз, а экземпляр Modbus_Master — несколько раз, но с разными входными параметрами, в зависимости от адреса подчиненного устройства, типа читаемых данных и их количества, а так же направления передачи данных (чтение или запись). Обращаю ваше внимание, что для одного коммуникационного процессора (а их в системе может быть очень много) у вас не может быть больше одного экземпляра каждого блока данных.
С моей точки зрения весь обмен удобнее завернуть в один внешний функциональный блок, а сам блок, с учетом необходимости разбирать данные, реализовать на текстовом языке SCL. Поэтому создаем в проекте функциональный блок с именем ModbusMasterV20 на языке SCL. Сразу после создания открываем его свойства и снимаем настройку «оптимизированный доступ», т.е. используем стандартный доступ. Личный опыт показал, что использование оптимизированного доступа рано или поздно приведет к ошибкам работы блока Modbus_Master и невозможности обмена. Это связано с порядком, в котором переменные идут в объявленной структуре данных, при стандартном доступе порядок соответствует заданному в программе, при оптимизированном — система сама «раскидывает» переменные, как сочтет нужным.
Объявляем следующие входные переменные
Init (Bool) — инициализация коммуникационного процессора, ее необходимо выполнить один раз перед началом обмена
PORT (PORT) — аппаратный идентификатор коммуникационного процессора
BAUD (UDINT) — скорость обмена по порту
STOP_BITS (USINT) — количество стоповых бит «кадра»
PARITY (USINT) — четность, где 0 — нет четности, 1 — odd, нечет, 2 — even, чет
В статической области переменных так же прописываем переменную с именем Step и типом UInt, она отвечает за «номер опроса» или «шаг работы алгоритма»
Так же в статической области объявляем экземпляры ФБ для работы по протоколу Modbus RTU
Строки программы, отвечающие за инициализацию обмена.
По флагу инициализации выставляем номер шага 1. Следующие строчки очень важны для работы
Тут мы задаем значения статических переменных экземпляра ФБ Modbus_Comm_Load, которые отвечают за «физику» передачи. Не понимаю, почему немцы поместили эти важные конфигурационные параметры в статическую область, а не в область входов. Дело в том, что они (переменные) все описаны во встроенной справке. Беда лишь в том, что большинство ленивых жоп новичков до этого пункта справку не читает, а потом тратят несколько часов, а то и дней, пока не найдут ответ. А справка-то, вот она:
Переменная MODE отвечает за режим, в котором будет работать коммуникационный процессор. Как видно из справки, для RS-485 надо явно выставить 4. Значение по умолчанию 0, от этого большинство ошибок у программистов.
STOP_BITS — количество стоповых бит.
Далее следует вызов блока настройки коммуникационного интерфейса Modbus_Comm_Load. Про параметр PORT (аппаратный идентификатор) будет рассказано чуть ниже. Параметры BAUD и PARITY — скорость и четность — приходят на вход «внешнего» блока данных, куда мы и завернули весь обмен. А вот параметр MB_DB интересен. На этот вход надо подать структуру типа P2P_MB_BASE, которая находится в области статических переменных экземпляра функционального блока Modbus_Master. Этот экземпляр в нашем «большом» функциональном блоке уже объявлен, привожу скриншот:
Следующая часть: функциональный блок приступает к циклическому обмену.
Я сразу «заворачиваю» обмен в CASE, чтобы не переписывать код в дальнейшем, но пока мы ограничимся чтением слова состояния и скорости ПЧ, т.е. прочитаем два регистра хранения.
Давайте посмотрим на вызов блока Modbus Master повнимательнее:
MB_ADDR — адрес подчиненного устройства Modbus RTU. В моем случае адрес частотника = 1.
MODE — направление передачи данных, 0 — чтение, 1 — запись
DATA_ADDR — адрес интересуемых нас данных. В моем случае необходимо прочитать два регистра хранения (поэтому первая цифра 4), начиная со 110го. В протоколе Modbus (что RTU, что TCP) очень часто возникает путаница в понятиях «адрес» и «номер». И очень часто производитель оборудования эту путаницу добавляет в свою систему. Вот смотрите. Мы должны прочитать 2 регистра, начиная с адреса 40110. Для чтения регистров хранения в протоколе Modbus используется функция с номером 3. Именно 3 будет передаваться в телеграмме Modbus. А в качестве адреса в телеграмме будет передаваться не 40110, а 109. Связано это с тем, что код функции уже содержит описание области данных. А в самой телеграмме мы передаем не адрес, а номер требуемого регистра или катушки. И эта нумерация идет не с единицы, а с нуля. Сейчас я работаю именно с адресами и режимом (чтении или запись), поэтому мне достаточно указать то, что я нашел в документации. Если же в вашем устройстве будет указано «входной регистр номер 0 содержит текущий статус устройства», то вам на вход DATA_ADDR необходимо будет подать 30001. Так же имейте в виду, что из-за частой путаницы с номерами и адресами, иногда эта адресация съезжает на «единицу», поэтому не бойтесь экспериментировать. Если вместо полезных данных по запросу 16ого регистра вам прилетает полная чехарда, не имеющая ничего общего с документацией, прочитайте 15ый регистр. Не помогло? Опрашивайте 17ый. Более подробно с материалом необходимо ознакомиться опять же во встроенной справке.
DATA_LEN — количество читаемых регистров, их 2
DATA_PTR — указатель на область памяти, куда необходимо «положить» результат чтения регистров. Собственно, это те данные, которые мы прочитали и необходимо подсказать функциональному блоку, куда эти данные надо записать. С моей точки зрения самый удобный способ в этом случае — это объявить в области STAT неименованную структуру должного размера. Поля структуры мы объявляем, в зависимости от самих читаемых данных, ведь это могут быть и наборы бит, и вещественные числа (расположенные в двух соседних регистрах). И нам еще повезет, если порядок байт в слове и слов в двойных словах контроллера и подчиненного устройства совпадут, иначе нам еще потребуется осуществить сдвиги байт/слов.
В данном случае я счел уместным объявить структуру из двух слов и скормить ее на вход FB:
ZSW — слово состояния (так оно называется в документации на ПЧ)
HIW — скорость вращения двигателя
После вызова блока мастера, необходимо проанализировать успех или неуспех его выполнения. В принципе, на этом скриншоте в комментариях уже все написано:
В случае успешного чтения необходимо полученные сырые данные как-то разобрать или переложить в другую область, и перейти к следующему опросу (у нас пока только один опрос, так что мы остаемся на шаге №1). При ошибке чтения данных минимальный разумный ход — выставить где-нибудь флаг недостоверности и перейти к другому опросу.
Пока оставляем прием данных без обработки, компилируем и грузим программу, смотрим на результат. Кстати, обращаю еще внимание на один факт. Поскольку мы работаем, завернув системные вызовы в свой функциональный блок, то любое изменение «своего» ФБ с последующей загрузкой ПЛК, будет нарушать обмен в связи с переинициализацией экземпляра нашего ФБ. Например, будет уходить в ноль значение «шага обмена». Да и внутренние статические переменные коммуникационных вызовов тоже пострадают. Самый простой способ — стоп и старт контроллера. В боевом проекте это опасно, поэтому там на вход Init я бы подал еще одну переменную и поднимал ее самостоятельно после изменений в коммуникациях. Пока же боремся с остановом обмена простым стоп-стартом ПЛК.
Добавляем вызов нашего функционального блока в OB1 и грузим CPU:
Переменная FirstScan имеет значение «истина» при первом цикле выполнения программы OB. Она назначается операционной системой ПЛК автоматически, ее применение настраивается в свойствах CPU.
Port. Это значение смотрим в проекте Step 7, аппаратная конфигурация:
Остальные параметры касаются скорости, четности и количества стоповых бит. Загружаем контроллер и смотрим, что нам приходит в ответ на единственный циклический запрос, открыв экземпляр нашего ФБ:
В слове состояния что-то есть, скорость равна нулю. Открываем документацию и смотрим состав слова состояния ZSW:
Low enabled в примечаниях означает инверсию. К примеру, бит №15, перегрузка частотника, возникает, когда этот бит равен 0, а в нормальном состоянии приходит значение 1. Посмотрим на это слово состояния в watch table и посмотрим, какие его биты выставлены, а какие — нет, оценим общее состояние ПЧ:
Тут нам везет, порядок байт в словах совпадают. Если вкратце, то видно, что ПЧ не готов, не включен, и сейчас активен сигнал аварии (fault, бит №3).
Далее я попытался разложить слово состояния в биты состояния, заменив WORD на структуру из бит, но что-то явно пошло не так.
Если посмотреть внимательно, то в таком представлении нулевой и первый байты явно не на своих местах. В общем, вопрос порядка следования информации в зависимости от того или иного представления — он всегда важный и требует вдумчивости. Получил на этом этапе облом, я решаю вернуться к хранению внутри нашего ФБ только сырых данных, а удобочитаемый для человека формат представления информации перенести куда-нибудь во внешний глобальный блок. Добавляю в проект блок данных DataV20:
После чего задумываюсь, убираю из имен переменных окончание Inv и дописываю функциональный блок:
Теперь в глобальном блоке данных у нас находятся статусные биты преобразователя частоты без какой-либо инверсии:
Думаю, что сразу в блок данных надо вписать переменную типа Real, которая будет содержать текущие обороты двигателя. Текущие обороты приходят от ПЧ в виде определенного численного кода, и мы вольны трактовать этот код, как нам удобнее. Допустим, что хочу трактовать этот код, как Герцы, поданные на двигатель.
Пока не будем пересчитывать коды в физические величины и перейдем к следующему шагу — к записи слова управления и задания частоты. Вернемся к обработке текущей скорости чуть позже.
Обратимся к документации и посмотрим состав слова управления частотным преобразователем:
Знаете, мне, откровенно говоря, лень писать все эти переменные в глобальном интерфейсном блоке данных. В моей практике управление простыми технологическими процессами с применением преобразователей частоты ограничивалось командами включить, квитировать аварию и дать задание скорости. Поэтому, пойдем на поводу моей лени и в блоке данных V20Data пропишем всего лишь бит включить, бит квитировать и задание частоты в формате Real.
Изменю алгоритм на шаге №1, при успешном или неуспешном завершении опроса сделаю переход на шаг №2.
Добавим еще локальную структуру ФБ, которая содержит слово управления и слово задания скорости:
Дорабатываю программу обмена. Не забываем, что при изменении переменных функционального блока, после загрузки изменений в ПЛК происходит его переинициализация, посему надо выполнять стоп/старт CPU.
Параметры функционального блока модбас в данном случае отличаются от первого вызова. Разумеется, у нас тут другой адрес регистра. А так же отличается режим (MODE), он равен 1, так как в данном случае данные не читаются с частотника, а записываются в него. Разумеется, указатель на область данных так же другой.
Обратите внимание, что некоторые биты слова управления я принудительно выставляю в истину, другие — в ложь. Всего два бита управления (включить и квитировать) доступны для внешней программы. Необходимое значение бит управления я вычитал в документации примера. Разумеется, это указано и в документации на сам преобразователь частоты. Изучая исходный пример, я обратил внимание, что если частотнику отдавать «пустое» (все биты выставлены в ноль) слово управления, то это подчиненное устройство модбас возвращает ошибку Invalid data. Однако, в этом примере я пробовал слать полностью «пустое» слово управления, и V20 принимал его. Однако, некоторые биты управления, все равно, должны быть установлены. К примеру, если снять бит «Control by PLC», то запускаться ПЧ не будет. RTFM, как говорится!
Теперь пора перейти к регистру, который отвечает за задание скорости (ну и сразу же к регистру, который отображает текущую скорость). Из исходного примера я понял, что этот регистр меняет свое значение в пределах от 0 до 16384. Это же мельком нашел и в документации. Пока не будем делать никаких переводов величин, и зададим ПЧ максимальную скорость жестко прямо в программном коде.
Откроем наш блок данных DataV20 и выставим команду «пуск»:
V20 запустился и работает, судя по индикации своего экранчика, на максимальной скорости, т.е. на 50 Гц. Давайте посмотрим еще сырые данные его скорости, которые приходит по modbus.
Значит, пришло время доработать шаг №1 обмена (перевести коды скорости в герцы), ну и шаг №2 в части обратного преобразования, герцы в численное значение задания скорости. «Математика» самая простая, без проверок на достоверность и выход за диапазон, хотя все это не помешает.
После загрузки изменений откроем блок данных DataV20 и поуправляем частотником из него.
Даем задание 25 Гц, даем пуск и наблюдаем за появлением сигнала Running и текущей скоростью.
Все регистры, которые можно считать с V20, описаны в документе по ссылке.
Судя по описанию регистров, есть и другие способы управления, но нас сейчас интересует не это. В моей практике с преобразователей частоты еще частенько просили считать ток(и), напряжение(я), мощность, детализацию ошибок и т.д. Давайте последуем этой старой-доброй традиции и считаем дополнительно вот эти параметры, а так же переведем их в понятное представление:
Параметры, разумеется, могут быть любыми, но предположим, что заказчику очень хочется именно эти. Я не буду подробно описывать процесс программирования и сразу покажу результат.
В принципе, мотор маленький, крутится без нагрузки, поэтому значения похожи на достоверные. Тем не менее, задача стоит в демонстрации считывания данных, поэтому будем считать наличие хоть каких-либо «цифры» за огромный технологический прорыв. Итак, вы уже заметили, что я добавил читаемые параметры в блок данных DataV20. Дополнительно был доработан функциональный блок коммуникаций:
Читаются (mode = 0) четыре регистра хранения по адресу 40025. Результат помещается во внутренний статический массив [0..4] of WORD. Далее эти слова переводятся в формат Real и помещаются во внешний блок данных в результате несложных преобразований.
Ну, и напоследок остается проанализировать качество связи. Ведь не зря же на каждом шаге после выполнения ФБ Modbus_Master смотрю его флаги DONE или Error (кстати, эти флаги имеют значение «истина» только на протяжении одного вызова после успешного или неуспешного выполнения запросы, в остальное время — ложь). Для этого я объявил массив из булевых переменных
Массив размерностью три, по количеству запросов Modbus. Соответственно, если на шине будет 10 частотников, по три запроса к каждому, то размерность этого массива, как и количество «шагов» алгоритма, будет равно 30. Ну, и в конце каждого опроса, при анализе флагов, наконец, прописываем присвоение флагам значения.
Будем считать, что частотник стабильно обменивается информацией с ПЛК, когда все три запроса к нему выполнены успешно. Поэтому самая последняя строчка нашего функционального блока будет такой (предварительно добавим булевую переменную Connected в блоке данных DataV20):
Читайте также: