Как мы ускорили Modbus в нашем контроллере за неделю
Мы в компании Lavritech несколько лет разрабатываем устройства и контроллеры автоматизации. Также разработали программную экосистему, которая может работать с разными интерфейсами, в том числе и Modbus. Изначально не считали его важным, но со временем оказалось, что многим нашим заказчикам Modbus нужен, поэтому стали расширять его поддержку в своих устройствах и решениях.
Как мы допиливали поддержку Modbus
В наших контроллерах на ESP32 изначально есть подсистема работы с шиной Modbus, но в первых реализациях функционал Modbus был ограничен: контроллер поддерживал самые простые устройства, готовых шаблонов не было. Хотя для тех же модулей реле с малым количеством регистров функционала было достаточно.
Каждое устройство Modbus мы прописывали через регистры и шаблон ответа в маленьком окошке, например:
Шаблон ответа (mask) — r1d1, r2d3, r2d1, r2, r1d1, rd2
выдает по порядку: напряжение (1 регистр, 1 знак после запятой), ток (2 регистра, 3 знака после запятой), текущую мощность (2 регистра, 1 знак после запятой), потребленную энергию (2 регистра), частоту сети (1 регистр, 1 знак после запятой), Power Factor (1 регистр, 2 знака после запятой)
Пользователи могли добавить поддержку своих устройств, но нужно было разобраться с нашим синтаксисом. Все это было довольно «больно» для пользователей, они часто добавляли ошибочные шаблоны, которые не работали. Затем пытали нашу поддержку, чтобы найти причину проблем. Надо сделать лучше, поэтому мы перешли на вторую версию Modbus с готовыми шаблонами.
Во второй версии подсистемы Modbus для нашего контроллера мы уже добавили готовые шаблоны в прошивку. Теперь пользователи не могли установить «кривой» шаблон и все испортить. В прошивке были только те шаблоны, которые мы написали сами. Но если нужно добавить поддержку нового шаблона и устройства в клиентский контроллер, приходилось обновлять прошивку.
Список готовых шаблонов, в основном для модулей Wiren Board
Список готовых шаблонов, в основном для модулей Wiren Board
Наша пользовательская база продолжила расти, поэтому и запросов со стороны клиентов стало больше. Во-первых, мы хотели дать пользователям возможность добавлять новые шаблоны к контроллеру без перепрошивки. Во-вторых, пользователям была нужна возможность писать свои шаблоны и добавлять их к контроллеру.
Так и возникла третья нынешняя версия подсистемы Modbus в нашем контроллере, которую мы назвали Modbus FS. Подробнее о ней можно почитать в документации Lavritech. Мы создали файловую систему, чтобы можно было подгружать шаблоны в виде файлов, без обновления всей прошивки. Теперь пользователь может загрузить нужные шаблоны из нашего репозитория и установить их на контроллер. Шаблоны можно писать самому, но затем их нужно отправить нам для проверки, после чего мы их опубликуем.
Менеджер файлов шаблонов в прошивке
Дополнительные фото
Редактор файла шаблона в прошивке контроллера, в данном случае для датчика WB-MSW
Интерфейс опции Modbus FS в нашем контроллере
Медленный Modbus
С шаблонами и добавлением устройств мы разобрались. Но как быть с временем отклика? Пользователи давно жаловались, что устройства Modbus медленно реагируют. Скажем, свет включался через секунду после нажатия кнопки в приложении.
Для систем с датчиками время отклика не так важно, там мы опрашиваем устройства раз в десять секунд. В умном доме время опроса можно сократить до одной секунды. Меньше уже рискованно — вычислительная мощность контроллера ESP32 не такая большая, он будет загружаться большим количеством запросов и не успевать обрабатывать другие задачи. И чем больше устройств на шине, тем эта проблема стоит острее.
Пробовали шину I²C для быстрого дискретного ввода (кнопки, выключатели). Однако она очень короткая, поскольку предназначена для связи компонентов на печатной плате. То есть через I²C не получится разнести те же модули управления и кнопки на большое расстояние. Кроме того, устройства разных вендоров через I²C не «дружат». Наконец, пользователи хотят простой, универсальный и надежный способ соединения внешних модулей с контроллером, а I²C — это «костыль», причем капризный, нужно следить за качеством соединения.
Один из вариантов реализаций I²C модулей — боковые модули Wiren Board, давно их используем. Да, в пределах боковых модулей все работает очень быстро, но такая конфигурация сложна в настройке: ее неудобно расширять, она требует постоянного контроля порядка соединений модулей, а также не везде подходит. Хотелось лучше.
На выставке WBCE 2023 узнали, что компания Wiren Board разработала расширение Быстрый Modbus. Идея была красивой, но будет ли она работать на практике? На выставке договорились с инженерами, чтобы нам отправили оборудование под гарантийное письмо. Все же демонстрация — это хорошо, но всегда хочется пощупать руками. Номенклатуру заказали широкую, почти весь спектр модулей с поддержкой Быстрого Modbus. Разложили устройства на столе программиста, собрали шину, подключили через UART-переходник к ПК и стали гонять и ловить пакеты. Что это за «зверь»? Быстро поняли, как все работает. «Зверь» оказался совсем не страшным. Так родилась идея добавить поддержку Быстрого Modbus в нашу подсистему Modbus FS, которую в то время как раз разрабатывали. Сложно ли было? Поначалу казалось, что будет боль и слезы, но на самом деле, нет.
Стенд тестирования устройств с преобразователем USB-RS485 для первичной отладки протокола Modbus с компьютера
Добавляем поддержку Быстрого Modbus к нашему контроллеру
Сразу отметим два важных момента: чтобы понять работу Быстрого Modbus, нужно иметь под рукой железки. Благо, Wiren Board может бесплатно их прислать под гарантийное письмо. И стартапам-разработчикам не придется нести дополнительные расходы. Кстати, наш программист даже не стал разбираться в работе Быстрого Modbus, пока не получил «железки», так как лень и некогда.
Второй момент — все отлично описано в документации. Мы несколько дней всяко-разно тестировали модули от Wiren Board, смотрели на часто мигающие огоньки. Ощущения были такие, что устройства Modbus находятся прямо в контроллере — связь была (почти) мгновенной. Мы пошагово шли по документации и проверяли работу всех функций. Разобрались в приоритете опросов, в поддержке событий на шине, в сканировании шины. Тогда пришло полное понимание, как все работает. А если есть понимание, то пора реализовать поддержку в наших контроллерах Lavritech.
Мы тестируем нашу программную среду сначала на ПК под Linux, а потом компилируем прошивку. Программист смотрел документацию, примеры, после чего писал код. Всю работу получилось разделить на четыре этапа:
Подписка — мастер отправляет всем устройствам команды, чтобы указать, за какими регистрами будет следить.
Мастер отправляет широковещательный запрос новых данных на все устройства.
Затем по алгоритму устройства передают пакеты, разбираем их.
Последний этап — сканирование шины через Быстрый Modbus. Здесь поначалу были ошибки, но в процессе отладки все быстро решили.
Всего на добавление Быстрого Modbus у одного нашего программиста ушла неделя вечеров, параллельно он решал другие рабочие задачи. То есть всю поддержку можно сделать за один спринт. В итоге добавили в нашу прошивку сканер устройств на шине, поддержку событий, изменение скорости устройств одним запросом и т.д.
В коде все это выглядит как дополнительный поток, который с заданной периодичностью запрашивает данные в шине Modbus, затем по циклу проверяет следующие пакеты. По сути, поток с периодическими запросами, который не пересекается с другими данными.
В итоге мы выставили интервал опроса 100 мс, хотя в документации указана возможность задать 50 мс. Но даже 100 мс — реакция почти мгновенная.
Для включения Быстрого Modbus в контроллере нужно, чтобы была прошивка с его поддержкой, после этого можно активировать опцию галочкой в веб-интерфейсе. В шаблонах есть пометка: если нужно использовать Быстрый Modbus для каких-либо регистров, то ставьте единичку. То есть клиент может сам выбрать, для каких устройств ему нужен Быстрый Modbus. Если Быстрый Modbus не нужен, то связь с такими устройствами и регистрами будет идти традиционно.
Как Быстрый Modbus сказался на нагрузке на контроллер? Все же ресурсов у ESP32 немного. Мы переживали на этот счет, но совершенно напрасно. Нам даже удалось снизить нагрузку. Каким образом? Мы увеличили время опроса обычных устройств до 10 с, а опрос Быстрого Modbus дополнительных ресурсов почти не потребовал. В итоге мы даже ускорили работу с устройствами I²C, так как у контроллера освободились ресурсы.
Интерфейс сканера Быстрого Modbus в нашем контроллере
Дополнительные фото
В веб-интерфейсе платформы Lavritech, если вы сами создаете прошивки, необходимо поставить галочку, после чего в контроллере появляется поддержка быстрого Modbus
Заключение
Изначально Modbus не был для нас основным, но клиентам он оказался нужен, поэтому мы постепенно его «допиливали». Когда работали над третьей версии подсистемы Modbus в нашем контроллере, узнали о Быстром Modbus. Идея показалась интересной, решили добавить поддержку.
Честно говоря, ожидали, что будет сложнее. Но Wiren Board перенесла всю сложность Быстрого Modbus на сторону устройств и прошивок, поэтому времени ушло немного. Добавили буквально за неделю, еще какое-то время ушло на тестирование. В результате удалось даже снизить нагрузку на контроллер, так как медленные устройства часто опрашивать не нужно, а критичные к задержкам — работают через Быстрый Modbus. Освободившиеся ресурсы позволили даже ускорить работу с устройствами I²C. Мы довольны. Надеемся, наши клиенты тоже.
А что вы думаете о Быстром Modbus? Есть ли у вас свои случаи внедрения? Делитесь в комментариях.
