Вопросы по Modbus

~Dimon~

Приплыли.
Структура ADU и PDU запросов и ответов в режиме RTU - одинакова.
Адрес ведомого и код функции в запросе и ответе одинаковы.
CRC конечно же на месте.
Отличается только поле данных.
Или что то из этого неверно?

Реклама

~Dimon~

Пролетает пакет с адресом какого то другого ведомого, но я не могу определить, запрос это или ответ.
Если это ответ - я должен быть готов начать принимать запрос ведущего к себе через 3,5T.
Вы конечно можете настроить ведущему минимальный интервал между опросами ведомых, и я могу потормозить, но если вы этого не сделали - я могу не успеть к 3,5T, и провороню запрос к себе.

Реклама

linux_rulezz

Какие обработчики в прерывании? Только флаг выставить, что пакет закончился (по IDLE). А в суперлупе, увидев этот флаг, МК разбирает пакет и принимает решение, что дальше делать.
Кстати, я очень редко на мастере CRC проверяю, т.к. это вообще никакого смысла не имеет, покуда я свой МК не засуну в щиток с пускателями на 10кВ… А я так никогда не делаю.
Но во мне все-таки еще теплится надежда, что больные в конце-концов сдохнут, и модбас никто не будет использовать вообще нигде, хотя бы лет через пять.

jcxz

linux_rulezz писал(а): Пн сен 14, 2026 22:27:33Кстати, я очень редко на мастере CRC проверяю, т.к. это вообще никакого смысла не имеет

Да уж... Этой фразой всё сказано о стиле кодопейсания адептов линуха и CAN-а. Ни добавить ни прибавить нечего.

Реклама

~Dimon~

Про Ардуино еще забыли

Будет жить еще долго.
Недавно попросили собрать несколько плат, разработка моя, 19 лет назад.
Сама система, куда их прикрутили, тянется вообще с 1965г., и там много людей поучаствовало.
Промышленность - она такая.

UPD:
У кого то есть объяснение, почему все данные в пакете Big-endian, а CRC почему то Little-endian?
Или после водки, там пили еще и портвейн?

Реклама

linux_rulezz писал(а): Пн сен 14, 2026 22:27:33(по IDLE)

На высоких скоростях в Modbus RTU, по IDLE, будешь постоянно ловить таймаут после первого байта. Если общаешься с устройством, для которого разработчики придерживались стандарту.

Реклама

tonyk

Аlex писал(а):На высоких скоростях в Modbus RTU, по IDLE, будешь постоянно ловить таймаут после первого байта. Если общаешься с устройством, для которого разработчики придерживались стандарту.

Враньё. По IDLE принимает без ошибок. IDLE взводится не через 1, и даже не через 2 бита, поэтому STM32 прекрасно принимает фреймы даже от старых восьмибиток, которые выдают байты в линию через не одинаковые интервалы.

tonyk

~Dimon~ писал(а):Вы конечно можете настроить ведущему минимальный интервал между опросами ведомых, и я могу потормозить, но если вы этого не сделали - я могу не успеть к 3,5T, и провороню запрос к себе.

На практике ни кто не ставит миллисекундые периоды опроса ведомых, в этом просто нет смысла. И слушать начинать разумно не через 3.5Т, а, например, через 3.0Т. Тут даже намёк на это есть, 3.5=2*1.5+0.5. Вроде, в Стандарте даже алгоритм приёма был разрисован.

~Dimon~

Будет зависеть от реализации программы на компе/ПЛК.
У меня первый опрос идет всегда подряд, всех ведомых, с теми промежутками, которые там libmodbus сделает. Даже не смотрел и не настраивал, работает по умолчанию все. Но поток опроса второго ведомого, реально там стоит и ждет, пока опрос первого не закончится.
Далее каждые 5 минут, но реализация программы такова, что опросы ведомых могут постепенно разойтись по времени, даже на секунды, или снова собраться в кучу, мне это не критично.

tonyk

~Dimon~ писал(а):Будет зависеть от реализации программы на компе/ПЛК.

Не должен зависить. Есть Стандарт, который все программы тем или иным образом соблюдают. Поставьте демо-версии нескольких ОРС-серверов для Модбас и посмотрите, как в них настраивается опрос, может, тогда станет понятней, что критично, а что нет для стабильной работы.

~Dimon~ писал(а):У меня первый опрос идет всегда подряд, всех ведомых, с теми промежутками, которые там libmodbus сделает. Даже не смотрел и не настраивал, работает по умолчанию все

Не правильный подход. Попадётся другое оборудование- и не заработает. Да, потом восстановится опрос, но такой кривой запуск опроса может заставить усомнится в правильности работы вашего оборудования и сформировать предвзятое отношение к нему.

linux_rulezz

Аlex писал(а): Вт сен 15, 2026 00:35:52На высоких скоростях в Modbus RTU, по IDLE, будешь постоянно ловить таймаут после первого байта. Если общаешься с устройством, для которого разработчики придерживались стандарту.

Чушь полная. Даже китайские релюшки и "ПЛК", где разработчики вообще ни о каком стандарте не слыхали, нормально работают. А "высоких скоростей" в модбасе не бывает: там редко встретишь шустрей 115200… Убогая дрянь, одним словом.
P.S. По поводу "ПЛК": в китайском клоне FX3U прошивка была настолько убогой, что я свою написал. И теперь кто угодно может там что угодно напрограммировать, не привязываясь к недоЯПу "ПЛК", а просто дописав код на С!

jcxz

tonyk писал(а): Вт сен 15, 2026 07:34:30 Враньё. По IDLE принимает без ошибок. IDLE взводится не через 1, и даже не через 2 бита, поэтому STM32 прекрасно принимает фреймы даже от старых восьмибиток, которые выдают байты в линию через не одинаковые интервалы.

Ну вобщем - как всегда... Сначала самоуверенно обвиняете всех, что они не знают протокола, а потом выясняется что вы сами его не знаете и стандарт видимо никогда не открывали даже...

Итак - читаем стандарт Modbus-RTU:

To ensure frame integrity during the transmission, the time interval between two frames must be at least the transmission time of 3.5 characters, and the time interval between two consecutive characters must be no more than the transmission time of 1.5 characters.[25] For example, with the default data rate of 19200 bit/s, the transmission times of 3.5 (t3.5) and 1.5 (t1.5) 11-bit characters are:
2.005 ms
859.375 μs
For higher data rates, Modbus RTU recommends to use the fixed values 750 μs for t1.5 and 1.750 ms for t3.5.[25]

Внимательно вчитываемся в выделенный жирным текст, затем достаём калькулятор и считаем время передачи одного символа для 115200бод:
1/(115200/11) = ~95 мкс.
Итого: Если передатчик будет посылать символы на 115200бод с интервалами между ними скажем по 500мкс, то это будет вполне себе честный Modbus-RTU, но IDLE прерывания внутри кадра будут гарантированно срабатывать.

Чушь полная.

Враньё.

Поизучайте протокол, товарищи.

~Dimon~

https://libmodbus.org/
Libmodbus is a C library designed to provide a fast and robust implementation of the Modbus protocol. It runs on Linux, Mac OS X, FreeBSD, QNX and Windows.

Если есть данные о кривости их библиотеки, что она может отправить следующий пакет ранее 3,5T, то надо открывать там тикет.
Если не может, то нарушения стандарта нет.
С Макаронами и QNX не работал, остальное в списке - точно имеет средства измерения мелких интервалов и таймеры высокого разрешения, только работают они по принципу "не менее запрошенного", что тут вполне подходит.

linux_rulezz писал(а): Вт сен 15, 2026 09:47:47Даже китайские релюшки и "ПЛК", где разработчики вообще ни о каком стандарте не слыхали, нормально работают.
А "высоких скоростей" в модбасе не бывает: там редко встретишь шустрей 115200…

Если ты не встречался с такими устройствами, это не означает, что их не существует.
Я, например, встречался с двумя такими устройствами. Китайскими, кстати. Их разрабы любезно придерживались стандарту и делали межбайтовые паузы согласно нему. И были правы. Идея ловли окончания кадра по IDLE, даже на стандартной скорости в 115200, шла по пи*де.

~Dimon~

Межбайтных пауз по стандарту быть не должно, но они допускаются (по стандарту), длительностью менее 1,5T.
Если кто то втыкает их умышленно, ему надо хвост оторвать.

~Dimon~ писал(а): Вт сен 15, 2026 13:37:15 Межбайтных пауз по стандарту быть не должно

Стандартом не запрещены, а значит "хвост откручивать" не за что. И IDLE, на скорости выше 19200 (например, 38400), пролетает "как фанера над Парижем".
Так что, аргументы некоторых тут пользователей, типа "Китайский ПЛК работает нормально" и т.д.. - неконструктивны, чтобы называть это чушью.

tonyk

Аlex писал(а):Поизучайте протокол, товарищи.

Их разрабы любезно придерживались стандарту и делали межбайтовые паузы согласно нему.

В Стандарте сказано, что пауза должна быть не более 1.5Т. Меньше- пожалуйста. Видимо, в китайских девайсах нет DMA, а программа написана так, что между отправками байт возникает пауза больше 10 бит.

jcxz писал(а):Ну вобщем - как всегда... Сначала самоуверенно обвиняете всех, что они не знают протокола, а потом выясняется что вы сами его не знаете и стандарт видимо никогда не открывали даже...

И опять мимо кассы. Человеку не повезло с двумя китайскими поделками. Бывает. Я за 10 лет использования STM32 ещё ни разу не сталкивался с невозможностью приёма по IDLE. Прекрасно понимаю, что использование IDLE вынужденная мера по причине кастрации UART со стороны STM, поэтому старался выбирать МК с полноценным UART, имеющим RTO.
Ещё нюанс. Старые модули удаленного ввода-вывода построены на 8051, но без проблем работают на 115200, из чего я делаю вывод, что многое зависит от того, кто писал ПО.

tonyk

Аlex писал(а):Идея ловли окончания кадра по IDLE, даже на стандартной скорости в 115200, шла по пи*де.

Просто скорость передачи была очень высокая для используемых МК и алгоритма их работы, другими словами, время входа в обработчик по отправке байта было больше длительности байта. Думаю, достаточно было просто понизить скорость, чтобы пауза между байтами стала меньше 10 бит.

~Dimon~

Аlex писал(а): Вт сен 15, 2026 14:06:37 Стандартом не запрещены, а значит "хвост откручивать" не за что.

Если гарантируете, что превышения 1,5T не произойдет, даже если все более высокоприоритетные прерывания наложатся друг на друга.
А на скоростях более 19200, 1,5T заменяется фиксированными 0,75мс.

Если архитектура позволяет, во всех остальных обработчиках, первой инструкцией можно поставить разрешение прерываний.
Тогда прерывания UART будут прерывать обработку любых других прерываний

Получите гарантированную скорость реакции, в пределах нескольких тактов.