Вопросы по Modbus

tonyk

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

Я знаю Стандрты на Модбас и много лет успешно их применяю на практике.
Вопрос был про различение двух фреймов, поэтому я кратко описал принцип отправки фреймов в сеть, чтобы думающие люди поняли, что разница в 3.4 и 3.5 символа ни какой роли для распознавания фреймов не играет, и что один узел, ни ведущий, ни ведомый, слать в сеть несколько фреймов подряд не будет. По этой причине стабильно работают реализации Модбас на STM32, использующие IDLE вместо RTO.

jcxz писал(а):Причём тут Modbus-TCP если речь идёт о RTU?

При том, что после отправки ведущим фрейма он ждёт ответ или отрабатывает паузу, а не шлёт тупо следующий фрейм через 3.5 символа.

jcxz писал(а):Вы уж определитесь, отключите одну из голов и ответьте: Есть запросы не требующие ответа или нет? И в случае, если "ответ не требуется" (широковещательный запрос), что может идти после такого кадра? И через какое время?

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

Реклама

~Dimon~

Ведущий -> Ведомый1 (запрос)
Ведомый1 -> Ведущий (ответ)
Ведущий -> Ведомый2 (запрос)

Вот тут какие интервалы будут?
Ведомый1 может ответить вообще сразу, если он быстрый, через 3,5T.
Дальше ведущий то же вроде бы имеет право, обратится к Ведомый2 через 3,5T после окончания ответа от Ведомый1. Если вы ему в настройках что то другое не поставили.

Реклама

jcxz

tonyk писал(а): Пт сен 11, 2026 16:09:25 При том, что после отправки ведущим фрейма он ждёт ответ или отрабатывает паузу, а не шлёт тупо следующий фрейм через 3.5 символа.

Именно, что тупо шлёт. Широковещательные кадры. Опциональная задержка может быть добавлена на время обработки кадров ведомыми. Но она именно - опциональная. Если слэйвы быстрые, то никакой дополнительной задержки мастер вставлять не обязан. А может слать с интервалами = 3.5T.

~Dimon~ писал(а): Пт сен 11, 2026 17:03:43Вот тут какие интервалы будут? Ведомый1 может ответить вообще сразу, если он быстрый, через 3,5T.

Не менее 3.5T. Может конечно ответить сразу через 3.5T.

tonyk

jcxz писал(а):Именно, что тупо шлёт. Широковещательные кадры.

Судя по сентенциям, вы только сейчас узнали о Модбас от ТС на этом форуме. И практики его применения у вас точно нет.
Широковещательные команды встречаются весьма редко. Из своей практики могу припомнить буквально пару случаев, когда они мне встречались. Один раз это была команда синхронизации входных данных во всех модулях ввода, второй раз для перевода системы в исходное состояние, когда все модули выдавали на выходы сигналы по умолчанию. Поэтому никто не долбит в сеть широковещательными фреймами. Более того, далеко не всё оборудование поддерживает такие команды из соображений логики своей работы.

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

Имеет, но не должен. Изучите спецификации на оборудование. Правильные производители указывают для своего оборудования максимальное время на ответ. Например, встречались вольтметры, для которого это время достигало 600мс вне зависимости от скорости опроса.

Реклама

linux_rulezz

Широковещательные команды очень даже нужны. Вот управлялся у нас купол телескопа по нормальной CAN шине. Но пришла пора апгрейда. И внезапно оказалось, что все вокруг - тридварасы... И нормальных частотников купить невозможно. Купили китайское говно. Оно на модбасе. Но зато, внезапно, поддерживает широковещательные команды. И то хорошо... Ведь для поворота тысячетонного купола нужно хотя бы четыре тележки одновременно запускать, поочередно тут никак не сработает, особенно на убогой скорости 19200! ХЗ, что за идиот разрабатывал частотники, но даже несчастные 115200 они никак не могут ☹

Реклама

tonyk

linux_rulezz писал(а): но даже несчастные 115200 они никак не могут ☹

Это проблема китайских частотников.Технических ограничений со стороны протокола на скорость нет, хоть 10Мбит/с, лишь бы трансиверы могли качать линию на такой скорости.

Реклама

~Dimon~

Вот что ещё непонятно.
Если соблюдать стандарт точно, то кадры с 1,5T < пауза < 3,5T должны быть признаны битыми и отброшены. Пауза "не менее 3,5T" означает конец кадра.
Но не сказано, сколько у меня в запасе, после 3,5T, если я не могу отследить точно 3,5.

Ставить 1,5T < порог конца кадра < 3,5T, единственное решение?
Битый по 1,5T < пауза < 3,5T кадр, при этом превращается в два битых по CRC, но границы кадров точно не будут пропущены.

~Dimon~

Даже если я могу отметить 3,5 точно, мне нужно ещё посчитать CRC, и проверить адрес ведомого. На это нужно время.

После 1,5T начинаем считать CRC, но если до 3,5T прилетает ещё один байт - Галя, отмена?
При этом нужно успеть рассчитать CRC до истечения 3,5T, так как следующий пакет может пойти.

tonyk

~Dimon~ писал(а):После 1,5T начинаем считать CRC, но если до 3,5T прилетает ещё один байт - Галя, отмена?
При этом нужно успеть рассчитать CRC до истечения 3,5T, так как следующий пакет может пойти.

Нет, всё не так.
CRC вычисляется после паузы 3.5Т.
Если при приёме между байтами была пауза больше 1.5Т, то для кадра выставляется флаг ошибки. После обнаружения тишины в линии в 3.5Т, начинается обработка кадра. По Стандарту, кадр с ошибкой приёма нужно отбросить.
Я ведь не зря говорил про таймаут на ожидание ответа от ведомого. Ведомому нужно время на обработку принятого кадра. И пример с вольтметрами привёл не просто так. МК, установленный в вольтметре, на время измерения отключает всю бортовую периферию, кроме АЦП и UART. Вот почему у него такое большое время ответа, хотя скорость обмена 115200.

~Dimon~

MODBUS over Serial Line Specification and Implementation Guide V1.02
Стр. 14, Фига 14, как раз указывает на обратное.
- Ожидание тишины 1,5T
- проверка CRC и адреса ведомого
- ожидание пока тишина достигнет 3,5T
- отбос кадра, если он не мне, или влетели ещё какие то байты между 1,5T и 3,5T, в противном случае обработка и ответ.

Что не показано явно, но я должен догадаться.
Таймер 3,5T должен перезапускаьмя после каждого байта.
Если после 1,5T что то прилетело - перезапускаем таймер! Ждём еще 3,5T.

И ещё, я должен успеть рассчитать CRC между событиями 1,5T и 3,5T, по тому что до проверки CRC, адрес ведомого в пакете, нельзя считать достоверным.

~Dimon~

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

tonyk

~Dimon~ писал(а):- Ожидание тишины 1,5T
- проверка CRC и адреса ведомого
- ожидание пока тишина достигнет 3,5T

Да, есть такое, но Стандарт писался во времена, когда не было UART с аппаратной поддержкой Modbus и производительность ЦП была низкой. Вот и запускали расчёт CRC с упреждением. Но что это даст сейчас при использовании DMA и RTO? Я не вижу в этом смысла в нынешние времена. Проще по прерыванию 3.5Т проверить адрес, потом CRC и при совпадении обоих перейти к обработке фрейма.

~Dimon~

Я пока под AVR пилю.
С кварцем 18,432МГц, расчёт CRC 256 байт - около 0,4мс.
Это слишком много, что бы считать внутри прерывания, а вытесняющей многозадачности у меня там нет.
Но можно внутри прерывания по принятому байту, проводить раунд расчёта CRC для него. Это около 24 инструкции, приемлемо.