Nikolay_Po (12.03.2025 18:35, просмотров: 43) ответил AlexBi на Конец ответа скорее всего определяется по паузе, я не видел других
вариантов. Т.е. пауза между ответом и запросом будет.-
- Тут может быть засада. RTU-ная пауза для определения
окончания/начала фрейма в реализации разных слейвом может
формироваться не очень точно. Кроме того, по дороге могут стоять
репитеры или хуже того - радиомодемы, которые также дают (могут
давать) задержку при переходе на прием следующего фрейма. Так что,
задержка нового запроса после окончания приема ответа у мастера
должна быть настриваемым параметром и настроена на самый
"тормозной" в этой цепочке слейв. - reZident(12.03.2025 18:40)
- Для [радио]модемов придуман Modbus-ASCII. - Cкpипaч(12.03.2025 18:46)
- Изначально - для проводных модемов. ASCII RTU с ограничением перечня используемых кодов был задуман так, чтобы произвольные коды из RTU не вводили модем в режим настройки. reZident(266 знак., 12.03.2025 18:52)
- У меня в факультативной разработке модем для RTU. Принимает кадры. Передаёт по радио, восстанавливает кадры и транслирует дальше. С учётом относительно высокой скорости радио, задержка преимущественно на длину самого кадра. В типовые таймауты укладывается (по результатам моего анализа). Но ещё не реализовал до конца. - Nikolay_Po(12.03.2025 18:50)
- Так и есть. Этот параметр, интервала между последним ответом и новым запросом - настраиваемый параметр мастера. - Nikolay_Po(12.03.2025 18:42)
- Для [радио]модемов придуман Modbus-ASCII. - Cкpипaч(12.03.2025 18:46)
- Тут может быть засада. RTU-ная пауза для определения
окончания/начала фрейма в реализации разных слейвом может
формироваться не очень точно. Кроме того, по дороге могут стоять
репитеры или хуже того - радиомодемы, которые также дают (могут
давать) задержку при переходе на прием следующего фрейма. Так что,
задержка нового запроса после окончания приема ответа у мастера
должна быть настриваемым параметром и настроена на самый
"тормозной" в этой цепочке слейв. - reZident(12.03.2025 18:40)