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