Конфигуратор vs modbus.lib

[rwg]

Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
А не набираем 10 байт - вот он ответ. Возможен мусор на линии.

Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.

[Sergey666]

Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.

Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс . "Торможение" на модбас шине происходит когда 1 или несколько слэйвов не отвечают и мастер вынужден выдерживать тайм-аут , непрерывно вычитывая буфер порта(для очистки мусора и совести).
Считаю что обмен должен быть организован по принципу непрерывно-независимого-асинхронного потока , как писал выше товарищ Егор , это нормально и надежно .

[rwg]

Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс .

Это если ASCII Modbus. Если RTU и скорость 9600 и более, то 3,5 мсек. Но к сожалению многие производители Modbus Slave его не соблюдают и заставляют себя подолгу ждать . А ещё есть таймаут между концом приёма ответа и следующим запросом. Если не выждать паузу (по стандарту - те же 3,5 мсек, по факту - кто во что горазд), то Slave просто не услышит обращённый к нему запрос.