Мы в компании 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
Наша пользовательская база продолжила расти, поэтому и запросов со стороны клиентов стало больше. Во-первых, мы хотели дать пользователям возможность добавлять новые шаблоны к контроллеру без перепрошивки. Во-вторых, пользователям была нужна возможность писать свои шаблоны и добавлять их к контроллеру.
Так и возникла третья нынешняя версия подсистемы Modbus в нашем контроллере, которую мы назвали Modbus FS. Подробнее о ней можно почитать в документации Lavritech. Мы создали файловую систему, чтобы можно было подгружать шаблоны в виде файлов, без обновления всей прошивки. Теперь пользователь может загрузить нужные шаблоны из нашего репозитория и установить их на контроллер. Шаблоны можно писать самому, но затем их нужно отправить нам для проверки, после чего мы их опубликуем.
Дополнительные фото
Медленный 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, которую в то время как раз разрабатывали. Сложно ли было? Поначалу казалось, что будет боль и слезы, но на самом деле, нет.
Добавляем поддержку Быстрого 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 не был для нас основным, но клиентам он оказался нужен, поэтому мы постепенно его «допиливали». Когда работали над третьей версии подсистемы Modbus в нашем контроллере, узнали о Быстром Modbus. Идея показалась интересной, решили добавить поддержку.
Честно говоря, ожидали, что будет сложнее. Но Wiren Board перенесла всю сложность Быстрого Modbus на сторону устройств и прошивок, поэтому времени ушло немного. Добавили буквально за неделю, еще какое‑то время ушло на тестирование. В результате удалось даже снизить нагрузку на контроллер, так как медленные устройства часто опрашивать не нужно, а критичные к задержкам — работают через Быстрый Modbus. Освободившиеся ресурсы позволили даже ускорить работу с устройствами I²C. Мы довольны. Надеемся, наши клиенты тоже.
А что вы думаете о Быстром Modbus? Есть ли у вас свои случаи внедрения? Делитесь в комментариях.
Комментарии (64)
Sun-ami
01.10.2024 08:15+2Если изначально не было привязки к RS-485, и нужно передавать короткие пакеты вроде нажатий кнопок, почему не использовать более стандартный CAN?
devprodest
01.10.2024 08:15+1С 485 дешевле и проще наклепать кучу датчиков и устройств, CAN не у всех дешевых контроллеров есть.
shtirlitz1945
01.10.2024 08:15+4Алсо под 485 уже наклёпана чёртова прорва датчиков и устройств, а под CAN (1) нет какого-то единого протокола чтобы править всеми, и (2) тупо мало устройств
Sun-ami
01.10.2024 08:15В целом это так, но в этой статье рассуждают, почему для этой задачи не подходит I2C, так что, очевидно, нет стремления подключать сторонние устройства с Modbus по той же шине.
Lavritech Автор
01.10.2024 08:15В этом и суть, что на одной шине живут устройства с быстрым Modbus и другие, медленные Modbus устройства.
buratino
01.10.2024 08:15+1тема быстроты вообще никак не раскрыта. Ни в байтах в секунду, ни во времени отклика устройств по протоколу
Lavritech Автор
01.10.2024 08:15Похоже прийдется писать еще одну статью, делать анализ загрузки шины логическим анализатором и сравнивать оба подхода с цифрами. В данной статье была задача рассказать именно о прикладной пользе быстрого Modbus и о том, что не так сложно его интегрировать в уже существующие решения если нахватает быстродействия шины.
Yuri0128
01.10.2024 08:15+2Ага... Так а сам прикладной "быстрый MODBUS" то и не освещен (вот там и полазить анализатором по загрузке канала) и сравнить его с предыдущей реализацией. Может оно и не все так однозначно?
nikolz
01.10.2024 08:15+2Поясните подробнее о загрузке ESP. Вроде у Вас все медленно. У Вас ESP с двумя ядрами? На сколько загружены и чем?
увеличили время опроса обычных устройств до 10 с...
в шине Modbus ... выставили интервал опроса 100 мс...
Lavritech Автор
01.10.2024 08:15В контроллере много других процессов, помимо работы с Modbus, например работа с сервером по MQTT или работа других опций. При использовании быстрого Modbus мы можем очень часто отправлять запрос к Modbus устройствам по шине, но не читать их в случае если данные не обновились. Такой запрос минимально нагружает контроллер, поэтому можно делать его очень часто. Когда же мы начинаем часто опрашивать много устройств по классическому протоколу Modbus, например раз в секунду, мы сильно нагружаем как шину, так и сам контроллер ESP32, потому вынуждены читать все регистры устройств, даже если данные в них не изменились, и только потом анализируем есть ли изменения в прошивке ESP32, что тоже тратит ресурсы. Таким образом мы разгружаем контроллер и освобождаем ресурсы для других задач без ущерба для работы с шиной Modbus.
nikolz
01.10.2024 08:15+3Ну это все общие рассуждения. Меня интересовали конкретные цифры загрузки ядра. Полагаю, что если используете два ядра, то одно из них делает все что связано с MQTT.
Полагаю, что опрос вы делаете через DMA. Сколько устройств Вы опрашиваете и сколько времени уходит на обработку данных с одного устройства? Кто потребитель данной информации? Если человек, то как быстро он ее обработает?
Lavritech Автор
01.10.2024 08:15Распределением ресурсов процессора ESP32 занимается RTOS, что происходит на низком уровне скрыто в SDK, мы не ставили себе задачи проанализировать нагрузку, RTOS не дает такой информации в явном виде, а писать код для этого, возможно с некоторыми "костыльными" решениями до пока не требовалось. Еще раз повторюсь в контроллере много процессов, MQTT клиент только один из них, есть еще планировщик заданий, опции обработки кода сценариев, подсистема Lora Wan шлюза, так же есть процессы работы с нашим облачным сервером, веб сервер интереса пользователя, может быть включен телеграмм клиент, процесс работы с устройствами на шине I2C, и это далеко не весь список. У нас на шине Modbus обычно не более 10 устройств, хотя теоретически их можно сбыть существенно больше. Ключевое, что при использовании быстрого Modbus вам не важно сколько устройств на шине, хоть 2 хоть 50, они отпрашиваются за один запрос, а в классическом протоколе на опрос 50 устройств требуется в 50 раз больше запросов чем если бы было одно устройство. Информацию конечно обрабатывает облако, пишется статистика метрик в базы данных на сервере и выводится в виде графиков оператору. Опрос делается через SDK, и да скорее всего на низком уровне там это реализовано через DMA, SPI точно работает через SMA, UART не факт. Конкретных цифр к сожалению нет, не решали задачу таких измерений.
Yuri0128
01.10.2024 08:15+3По нагрузке: предположим, что юзаем RAM по spi (ну, если ее мало) + там еще что-то через DMA, ресурсов проца (наверняка 2 ядра) использовано мало, i2s, он низкоскоростной (100кбит/400 кбит, для 32 байтного проца то), он (скорее всего) тоже на DMA - ну тоже копейки, USART (там он) - даже 2 канала по 115 к в прерывании будут занимать проц очень немного при постоянной работе, LORA (wan)- оно ме-е-едленное. Второе ядро отрабатывает MQTT. 5% отжирает RTOS (если много потоков, если мало то заметно меньше). Откудова у вас инфа, что ESP32 загружен по полной?
Я делал опрос 10 MODBUS юнитов на 8-битке на 1 канале на 9600 (пробовал и на более высокой скорости - до 230к на аппаратных портах и до 38400 на программно эмулированных) с передачей вторым каналом наверх. Все успевало. Чего у вас не успевает на несколько более быстром 2-ядернике - большой (и больной) вопрос. Тоже 485 порт.
Lavritech Автор
01.10.2024 08:15+1ESP32 занят опросом шины постоянно, если опрашивать 50 устройств на шине и требуется реакция 1 секунда, нужно за эту секунду прочитать все 50 устройств и обработать данные с них, если взять таки сложные устройства как MAP12E, то это более сотни регистров на одно устройство. Но быстрая реакция требуется не для всех устройств, поэтому включив быстрый Modbus, мы не делаем короткий интервал опроса для всех, быстро опрашиваются только устройства требующие быстрого отклика. Возможно выше была не точность. Точнее было бы сказать, что ESP32 занят избыточными опросами других устройств и мы освобождаем это время на устройства, которым действительно нужен быстрый отклик.
Yuri0128
01.10.2024 08:15Организуйте 2 канала 485 и распределите юниты по ним - или вы привязаны к топографии? Вроде домашнего пользования привязка к топографии не так уж и нужна.
MAP12E займет порядка 19,2 кбит при 100 мс цикле - при канальной скорости в 115,2 кбит у вас есть вполне ресурс на еще что-то там, ну не будет же у вас 4 MAP12E же повешены на канал? Это уже серъезный ПЛК надо. А если растояния небольшие, то и выше канальную скорость поставить можна (если поддерживают юниты).
Lavritech Автор
01.10.2024 08:15Планируем что бы можно было более 4шт MAP12E опрашивать одним контроллером, почему нет?
Yuri0128
01.10.2024 08:15Ну... А где в домашнем пользовании можно применить 4 MAP12E на 1 канале? Вы ведь позиционируете его как маломощный контроллер для домашнего (не промышленного ! - вы это прямым текстом указали) применения. На промке - ну не вопрос.
nikolz
01.10.2024 08:15Благодарю за ответ. Но поясните тогда следующее.
Вы нигде не сказали какая у Вас скорость ModBus. Предположу, что 19 Кбод. это примерно 2 KB/s. Вы сказали что интервал опроса одного устройства 100 ms. Это означает, что все устройства Вы опросите за 100 ms. Но за это время Вы получите максимум 200 байт информации. Если устройств 50, то каждое из них передаст максимум 4 байта.
Все верно?
Yuri0128
01.10.2024 08:15+1Если нету сильно шумящих силовых слейвов - то и на 115,2 кбит/сек норм работает. В бытовом применении настолько шумящих обычно нет. На проме - есть, - там и 9600 бывает.
dephonica
01.10.2024 08:15+2Плюсую, ESP32 без проблем проглатывает и не давится потоковой обработкой данных на 100к семплов в секунду (float32) с помощью FFT фильтров, одним ядром процессора. Второе при этом занято вводом/выводом и управлением потоком и загружено на 3-5%.
engin
01.10.2024 08:15Собственно автор ограничил диапазон применения и дает перечень применений.
ESP32 подходит для создания недорогих IoT-устройств, но не соответствует требованиям к надёжности, безопасности и производительности для использования в промышленности.
Его вычислительная мощность и долговечность не соответствуют требованиям для PLC, где могут быть нужны гораздо более сложные задачи и продолжительная работа без перезагрузки.
Прежде всего низкая, не соответствующая режиму жесткого реального времени реакция к прерываниям, отсутствие ресурсов для резервирования и восстановления данных, уязвимость к кибер атакам. Так же нет поддержки со стороны тех IDE, в которых разрабатывается ПО.Yuri0128
01.10.2024 08:15требованиям к надёжности, безопасности и производительности для использования в промышленности.Его вычислительная мощность и долговечность не соответствуют требованиям для PLC, где могут быть нужны гораздо более сложные задачи и продолжительная работа без перезагрузки
Вы поприкалываться решили? 2 ядра Xtensa LX6 по 240 МГц + по 512 кбайт встроенной флеши/ОЗУ и доступ к 16 Мбайт внешней флеши и 8 Мбайт ОЗУ + куча каналов DMA и однотактовый доступ к встроенной памяти, - и вам мало производительности? Многие ПЛК контроллеры промки имеют много меньшие вычислительные ресурсы и все-ж норм работают на своем месте.
Температурный даипазон указан как для промки (-40/+125 Цельсия) - тоже норм.
Безопасность определяется прошивкой, которую написал программист.
По долговечности - не могу сказать, но все-же думаю, что там все норм.
Вопрос: нафига такое писать не разобравшись? Вы хоть один пример из жизни то приведите, где нормально спроектированный контроллер на ESP32 безбожно глючил и нормально не работал при качественом firmware.
dephonica
01.10.2024 08:15+2В случае ESP32 могу согласиться только с непопаданием в требования безопасности - есть вероятность, что чип полон китайских закладок, в том числе и для простого считывания заблокированной прошивки. Долговечность и надёжность обычная, если сравнивать с чипами потребительского сегмента. Много ли ПЛК сейчас собираются на чипах промышленного класса?
Всё остальное перечисленное не имеет прямого отношения к промышленному применению, так как не указано ни одного требования ни по одному из параметров. Жесткое реальное время в контроллере дизельной электростанции и в контроллере сверхпроводящего магнита БАК - это разное жесткое реальное время, а на ESP32 вполне доступно миллисекундное время реакции на внешнее событие, чего достаточно для 3/4 всех применений.
Сюда же и производительность - это очень мощный двухядерный числогрыз, который без проблем отрисовывает UI в стиле Android (библиотека LVGL) и параллельно обеспечивает ту самую миллисекундную реакцию на своих входах/выходах. И для этого не нужно просчитывать такты каждого разветвления программы, как это требовалось на PIC16F628, мощности с запасом.
Резервирование и восстановление данных - в ESP32 встроенная поддержка разметки flash памяти в виде разделов и встроенная поддержка A/B апдейтов, когда при неудаче обновления запускается прошлая рабочая копия из соседнего раздела. Библиотеки типа EEBOOM позволяют хранить настройки прошивки с избыточностью достаточной для низкого износа памяти по циклам записи. Также эта избыточность обеспечивает надёжность хранения этих десятков/сотен байт параметров. Большие объёмы информации - это уже область внешних, относительно MCU, устройств и их надёжности.
Да, большого смысла пихать ESP32 в промышленное применение нет, но это не потому, что чип плохой и не тянет, с ТТХ у него всё просто отлично, а потому, что это чип универсальный, с компромиссами для уменьшения стоимости и упрощения разработки. Стоимость MCU в стоимости ПЛК это считанные проценты, поэтому имеет смысл использовать более подходящие для этого микроконтроллеры, если к ним есть доступ, что производители в основном и делают.
Yuri0128
01.10.2024 08:15+1как это требовалось на PIC16F628,
ооо, делал я на таком маломощный бесперебойник с синусом и почти 0-ым временем переключения. Таки считал такты....
dephonica
01.10.2024 08:15+1Да, всякие диммеры и другие устройства с синхронизацией с сетью - и здравствуйте ассемблер и подсчёт тактов на маломощных восьмибитках.
Yuri0128
01.10.2024 08:15Так на ассемлере и было.... Давно было... Зато там компаратор неплохой с рефом...
Сейчас уже почти нету ассемблера, даже на 8-битках... И все чаще проц просто спит по 95% времени даже без использования асма.
devprodest
01.10.2024 08:15+4Если коротко по тексту:
Были проблемы..
Wiren Board молодцы, дали железяки
Wiren Board молодцы, есть дока
Интегрировали
Wiren Board молодцы
Так о чем собственно статья, где расследование, выводы, приняти решений?
nartivin
01.10.2024 08:15+3Добрый день, не хочу показаться токсичным, но у меня есть вопросы :
Это вариация ПЛК ? если да то почему на микроконтроллере, это слишком слабо для задач ПЛК, при построении АСУ ТП
На какой сегмент ориентирован контроллер ?
Боковые модули - почему есть сложности, если данный вариант расширения самый популярный среди больших изготовителей ?
В какой среде идёт разработка ПО, какие языки поддерживаются, какие есть библиотеки ?
На счёт midbus, если вы сделали ПЛК то должны были понимать что modbus tcp и modbus rtu самые популярные протоколы в АСУ ТП, тот же ethernet ip или profibus редко где встретишь, почему сразу не уделили внимание данным протоколам...?
Lavritech Автор
01.10.2024 08:15+2Спасибо за ваши вопросы!
Lavritech — это не вариация ПЛК, и не подходят для АСУ ТП, устройства и ПО ориентированные на мониторинг и домашнюю автоматизацию
Контроллеры и платформа Lavritech ориентированы на малый и средний бизнес, проекты умного дома, стартапы и разработчиков прототипов, а также на решения в сфере IoT. Они предлагают гибкость, простоту настройки и доступные решения для автоматизации и мониторинга.
Основные сложности с боковыми модулями, это проблемы адресации I2C и не возможность разносить устройства и контроллеры. А так же ограниченность по сложности устройств I2C, функционал устройств Modbus намного разнообразней, устройства могут быть составными
Создание прошивок Lavritech происходит на платформе конструкторе https://soft.lavritech.com. В прошивке есть возможность построения простых алгоритмов и сценариев, но это не аналог среды для классический ПЛК
На данный момент мы сфокусированы на Modbus потому что эти устройства наиболее популярны у наших клиентов. На поддержку profibus на данный момент запросов у нас не было
SIWRX
01.10.2024 08:15если да то почему на микроконтроллере, это слишком слабо для задач ПЛК, при построении АСУ ТП
А не подскажете, почему микроконтроллер не подходит для ПЛК?
Lavritech Автор
01.10.2024 08:15Критерий подходит устройство для ПЛК или нет , определяется принципом построения его ПО, в контроллерах Lavritech концепция сильно отличается от классических ПЛК. У нас есть что то похожее на каталог приложений, которые можно загружать в контроллер по воздуху, в зависимости от задачи и требуемых функций. Сам же встроенный обработчик сценариев достаточно медленные по меркам ПЛК, зато человек может быстро скачать из каталога нужно приложение, немного его настроить и решить свою задачу. При работе же ПЛК есть среда разработки, которая позволяет в визуальном редакторе строить сложные алгоритмы, задавать задержки и тд. ПЛК очень быстро обрабатывает в реальном времени процессы, там крайне важны тайминги. Наше же ПО заточено под быстрое решение задач мониторинга и домашней автоматизации, сбора данных, обработки простых алгоритмов, Термостаты, планировщики задач, работа по расписанию, но все это алгоритмы достаточно медленные. А так многие современные ПЛК построенные на микроконтроллерах куда медленнее ESP32, все дело в принципе построения их ПО и подхода к разработке самих программ.
NutsUnderline
01.10.2024 08:15+1микроконтроллере, это слишком слабо для задач ПЛК, при построении АСУ ТП
деды наши и прадеды делали на 8051 и 8080 и почему то хватало
MaksMS
01.10.2024 08:15+2Давайте уточним в чем суть статьи и быстрого модбаса:
Быстрый модбас - это надстройка над классическим modbus, она позволяет быстро опрашивать "сухие контакты" и прочие подобно датчикам движения устройства, это не относится к разнообразным датчикам температуры или влажности (например WB-MSW) или счетчикам энергии, типа MAP12E.
Логично, что если требуется прочесть 50 устройств с "сухим контактом", то классический обход регистров устройств займет примерно 5 секунд(т.е. мы узнаем что поменялся вход только через 5 сек худшем случае), при быстром же модбасе, событие измененного входа придет уже через 50мс ! - этим мы конечно же экономим ресурсы контроллера(конечно не значительно, но все же) и уменьшаем трафик по шине RS485.
Конечно же чтение 50 штук MAP12E не даст прироста - у его нет регистров с поддержкой быстрого модбаса.
Быстрый модбас - это не прям мега-супер-крутая штука, которая привела к эволюции modbus, но все же значительно влияет на скорость реакции в системах, задействующих много устройств ввода-вывода(типа WD-MR6C) на одной шине. Далее изменения уже можем отсылать мнгновенно по mqtt или отрабатывать локально на контроллере Lavritech, например подключение подключенных кнопок к WD-MR6C(Пример: Кнопка -> WD-MR6C -> Lavritech-> WD-MR6C -> нагрузка)
fiego
01.10.2024 08:15+1Нифига не мог понять из статьи. Заинтересовался, нашёл предыдущую по теме. Стало заметно понятнее.
ds-c
01.10.2024 08:15Мы тестируем нашу программную среду сначала на ПК под Linux, а потом компилируем прошивку.
Это интересно! Можно подробнее, как это реализовано, какой у вас фреймворк, библиотеки?
MaksMS
01.10.2024 08:15+2Отвечу как разработчик данной прошивки:
Прошивка написана на Си и по этому легко портирована под Linux - приложение легко запускается на x86, на всяких "малинках" и "бананах", а так же на дешевом MILK-V. На х86 можно быстро отлаживать uart опции(этот же модбас), и даже i2c(через USB/VGA/HDMI), а так же программные опции без долгой перепрошивки контроллера. Если на мини компьютере есть вся периферия GPIO(SPI,I2C,UART), то функционал как минимум повторяет возможности ESP32 с большим запасом по ресурсам.
В перспективе, при определенном спросе и повышенных требованиях к задачам, можно будет сделать контроллер и на базе MILK-V вместо ESP32.Sun-ami
01.10.2024 08:15i2c через VGA/HDMI - это как? И как вы отлаживаете i2c через USB, хотелось бы узнать поподробнее.
MaksMS
01.10.2024 08:15+1там выведен i2c для считывания и распознавания монитора, который можно использовать
MaksMS
01.10.2024 08:15А через USB есть проекты usb-i2c, на этом же usbasp.
Yuri0128
01.10.2024 08:15А нафига так уж прямо через анус?
MaksMS
01.10.2024 08:15Чего это ? Очень древний рабочий способ, баловался лет 10 назад. Я не призываю его использовать , просто как вариант , к x86 не особо варианты подключить i2c, это сейчас малинок всяких развелось и х86 гонять не особо смысл есть
Yuri0128
01.10.2024 08:15малинок всяких развелось и х86 гонять не особо смысл есть
ну так и я о том-же.. А на x86 - вполне есть пару i2c (если есть видеокарта, ну или хотя-бы один, если ее нету) и без usb-i2c .
MaksMS
01.10.2024 08:15ну я про VGA и написал как вариант в первом сообщении, но не всегда он доступен, сейчас на новых компах его нет, а к hdmi подключится сложнее, хотя тоже можно. При этом порт может быть занят и колхозить параллельно не хочется..
Yuri0128
01.10.2024 08:15На ОЗУ? PWR SMB? Мультик? Кроме мониторных.
MaksMS
01.10.2024 08:15ну не все полезут туда, тем более на более современном ПК уж очень все мелко там, точки подключения т.е.
плюс не все знают куда там припаиваться, на каждой мамке по разному, ну кроме ОЗУ..Yuri0128
01.10.2024 08:15В целом то да, но если припечет.....
Я тут пристроился интерфейсную часть отлаживать на Python-е с последующим переписыванием на C (C++). Вполне себе вариант.
engin
01.10.2024 08:15Мне удалось реализовать много поточный программный драйвер на базе USB 3.0 RS232 что практически не сказывается на падении скорости (ОС Win 10) при подключении на хаб десятков комплектов с одновременным опросом. Там где внедрили, никаких нареканий нет при соблюдении качественного монтажа.
Это 10-и или 16 канальные ADC 115 115200 бит/с (STM2). Таким образом в моем распоряжении до 100 каналов, хотя теоретически можно и больше. Подключаемая сенсорика в эпицентре до 15 м, но можно и дальше, если применить специальные коммуникационные хитрости в том числе и позаботится о качестве линий и их опорном питании. Проста в подключении и цена такой ход вполне оправдывают в эту пользу.
Конечно не спорю об гарантиях целостности команд при таком интерфейсе в сравнении с модбасами, но в целом нет цели претендовать на индустриальные задачи, запросов полно и за пределами пром стандартов.Yuri0128
01.10.2024 08:15Молодец. Но как это относится к теме, заданной автором? Или хотя-бы к вариантам MODBUS? Или к теме реализации простенького ПЛК на ESP32?
Походу никак. Просто, видать, выдох души?
engin
01.10.2024 08:15Или к теме реализации простенького ПЛК на ESP32?
ПЛК или такой каким он должен быть в соответствии с IEC 61131 все остальное это нечто другое.
Что касается темы об ускорении Modbus то я разделяю это мнение, свой пример привел для сравнения по ряду ключевых параметров в контексте других сообщений подкаста, таких как скорость и количество точек, целесообразность в ограничениях ESP32 по своим возможностям. Ну к примеру автор будет считывать с 40 термодатчиков, а дальше что там у нас по количеству I/O? Отладка каких то задач, да, возможна и прототайпинг.Yuri0128
01.10.2024 08:15ПЛК или такой каким он должен быть в соответствии с IEC 61131
Шикарно. Вы сами весь стандарт прочитали (или хотя-бы IEC 61131-1)? Ибо как микроконтроллер-ядро ПЛК ESP32 проходит по первой части стандарта. А вот по поводу входов/выходов там уже вопросы... Как и к вашему решению, собственно.
А возможностей ESP32 достаточно для ядра ПЛК.
Ну к примеру автор будет считывать с 40 термодатчиков,
И что? На один 485 порт можно повесить 40 датчиков, если не требуется быстроты. А на самом ESP32 вполне 2-3 канала можно реализовать штатно а подключив "боковые блоки" по i2c (2 канала) можно получить еще дофига 485 каналов (ну штук 30, только вот нафига), то есть сам ESP32 вполне потянет все.
Vdm_ro
"Быстрый Modbus" это новый, поддерживаемый только разработчиком протокол, о котором знает только разработчик и название Modbus там только для маскировки и обмана покупателей(такое мнение сложилось после листания ссылок и статьи)?
Или это все же международный стандарт с каким то неупомянутым в статье названием?
shtirlitz1945
Это расширение модбаса, работает в function code 0x46.
Спецификация общедоступна и лежит на гитхабе.
https://github.com/wirenboard/wb-modbus-ext-scanner/blob/main/protocol.md