RT_HW_IO_LINK и Modbus

[ecoins]

RT_HW_IO_LINK vs Modbus
Сравнительный материал: интуитивный прикладной обмен вместо ручной карты регистров

Modbus RTU - распространённый промышленный протокол, полезный для совместимости с большим количеством оборудования. Но в задачах быстрого точка-точка обмена между контроллером и собственным удалённым модулем ввода-вывода он часто заставляет инженера работать с лишним уровнем абстракции: адресами устройств, адресами регистров, картами битов и ручной логикой опроса. RT_HW_IO_LINK решает эту задачу иначе.

Разные задачи
Сравнение не должно звучать как “один протокол всегда лучше другого”. Modbus удобен как универсальный язык совместимости. RT_HW_IO_LINK удобен как прикладной интерфейс внутри собственной распределённой системы FLProg, где важны простота, читаемость, скорость реакции и удобная диагностика.

01_comparison_table_RT_HW_IO_LINK_vs_Modbus.png

Главное отличие: прикладной интерфейс
В Modbus пользователь мыслит регистрами: “прочитать holding register 40001”, “записать coil 17”, “разобрать слово состояния”. В RT_HW_IO_LINK пользователь мыслит функцией: “передать DO1”, “получить AD4”, “проверить OK”, “посмотреть STATUS”. Это ближе к тому, как инженер описывает задачу на схеме управления.

02_box_Modbus_vs_RT_HW_IO_LINK_approach.png

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

Тонкая настройка без усложнения схемы
Простота интерфейса не означает примитивность. Внутри библиотеки предусмотрены настройки, которые важны для промышленного обмена: минимальные периоды отправки, контрольные периоды, приоритеты групп, anti-starvation, фильтры, гистерезис, time limit, OK, RQ и диагностика. Пользователь может оставить значения по умолчанию или настроить канал под конкретную задачу.

03_policy_use_change_force_rq.png

Читаемая отладка
В режиме ASCII_DEBUG обмен читается человеком. Это сильно ускоряет запуск: можно сразу увидеть, что реально отправляет контроллер и что возвращает удалённый модуль. В рабочем режиме ASCII+CRC сохраняется читаемость строк, но добавляется контрольная сумма.

03_policy_use_change_force_rq.png

Когда лучше RT_HW_IO_LINK
собственная связка центрального контроллера и удалённого FLE-модуля;
нужен быстрый обмен точка-точка;
важна простая диагностика и быстрый запуск;
проект делается в FLProg и должен быть понятен без карты регистров;
нужно передавать только используемые и изменившиеся параметры;
нужно развивать не только I/O, но и счётчики, энкодеры, step/servo и локальные исполнительные узлы.

Когда лучше Modbus
нужно подключить стороннее оборудование с готовой Modbus-картой;
требуется совместимость с существующей SCADA или промышленной сетью;
важна универсальность протокола между разными производителями;
скорость реакции не является главным ограничением.

Вывод
Modbus остаётся полезным универсальным стандартом. RT_HW_IO_LINK занимает другую нишу: это комфортная прикладная среда обмена для пользователей FLProg и собственных распределённых систем. Он убирает из проекта адреса устройств и регистров, оставляя инженеру понятные сигналы, готовые блоки, диагностику и тонкую настройку поведения канала.

[Rovki]

А почему не SPI или I2C использовать для этих целей? Тогда любой МК, а не только с кучей UART, подойдет для локального соединения МК

[lfgjikjjyj]

Наверное потому что уарт прост надёжен и прямой переход в мадбасс имеется

А так тоже подумывал сделать мост через i2c между контроллерами но потом потестил уарт в принципе там скорости достаточно чтобы можно было передавать команды на управление

Да и потом на Arduino в SPI нету буферки сейчас переделываю блок и там отчётливо будет видно в тестах как оно отличается от 8266 как я уже рассказывал в блоках чтобы на Arduino передать байт надо пнуть SPI если там какое-то прерывание или длинное действие в лупе то это дело растягивается А на 8266 это проще опять же в размер длины его буфера

А вот при наличии дма возможно что-то получится создать что-то интересное но опять же вопрос Что вы там собрались такого глобального транслировать между контроллерами тот же SPI - это практически 1 мегабайт в секунду

[Rovki]

Для много процессорных систем пойдет. например- Управление LED-матрицами: DMA используется для вывода изображения на дисплей без участия CPU.

[ecoins]

А почему не SPI или I2C использовать для этих целей? Тогда любой МК, а не только с кучей UART, подойдет для локального соединения МК

1.Как идея да - возможно.
2.Достоинства RS232 или UART: поддержка глубокого и управляемого аппаратного буферирования -64,128,256,512,1024байт. Это позволяет в фоновом режиме накапливать в буфере сообщения без опасности их потери при вывода
Например в графический дисплей большого буфера данных. В зависимости от дисплея это может быть 2-3мс (MONO) до 150мс(TFT 320x480).
3.Для RP2040,RP2350 эта проблема может быть решена на уровне FLProg аппаратно-программными методами - второе ядро и разбивка процедуры подготовки буфера на небольшие тайминги <5мс. Сама отправка через DMA работает в фоновом для CPU режиме и на быстродействие не влияет.
4.У RS232 практический потолок на аппаратном уровне 250000кГц.
5.Здесь очень выигрывает прямое соединение через UART - современные CPU(ESP32,RP) - 1.5мГц.
6.У текущих реализаций i2c есть ограничения - интерфейс асинхронный, максимальный размер посылки библиотеки Wire.h 32 байта. Начали появляться чипы i3c - там сильно другие возможности, но это перспектива 1-3лет.
7.SPI - у него нет аппаратного буферирования, надо создавать аппаратный. Интерфейс асинхронный - требуется 3-4 пина. Если делать независимый обмен в обе стороны - это 6-8пинов. В принципе возможно. Особенно для локальных соединений CPU.

С уважением, ecoins.