Вопросы по Modbus

[tonyk]

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

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

Причём тут Modbus-TCP если речь идёт о RTU?

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

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

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

[~Dimon~]

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

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

[jcxz]

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

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

Вот тут какие интервалы будут? Ведомый1 может ответить вообще сразу, если он быстрый, через 3,5T.

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

[tonyk]

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

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

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

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

[linux_rulezz]

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