Nikolay_Po (12.03.2025 10:20, просмотров: 119) ответил LordN на нет обычный RS485 с modbus rtu-
- это значит, что после строба на входе ^ розового ящичка "отправить запрос" на выходе rdy появляется нулик и он там висит пока от слейва не придёт ответ с валидными данными LordN(1 знак., 13.03.2025 05:10, картинка)
- Возможно тут разделены линии передачи и приема, поэтому можно
одновременно и передавать запрос следующему и получать ответ от
текущего. - AlexBi(12.03.2025 15:28)
- Наверное, ТС имел ввиду, что передача следующего запроса
формируется не по таймеру, а сразу после получения ответа на
предыдущий запрос - для увеличения скорости опроса. Так я понимаю
его молчание. - Nikolay_Po(12.03.2025 15:43)
- Конец ответа скорее всего определяется по паузе, я не видел других
вариантов. Т.е. пауза между ответом и запросом будет. - AlexBi(12.03.2025 16:04)
- Ну, пауза на канальном уровне обязательна, это не обсуждается. Речь
о том, что опрос идёт максимальным темпом. Сразу по завершению
предыдущей транзакции на шине, начинается следующая. Без ожидания
иных пауз, кроме межкадрового промежутка. - Nikolay_Po(12.03.2025 18:35)
- Тут может быть засада. 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)
- Ну, пауза на канальном уровне обязательна, это не обсуждается. Речь
о том, что опрос идёт максимальным темпом. Сразу по завершению
предыдущей транзакции на шине, начинается следующая. Без ожидания
иных пауз, кроме межкадрового промежутка. - Nikolay_Po(12.03.2025 18:35)
- Конец ответа скорее всего определяется по паузе, я не видел других
вариантов. Т.е. пауза между ответом и запросом будет. - AlexBi(12.03.2025 16:04)
- Наверное, ТС имел ввиду, что передача следующего запроса
формируется не по таймеру, а сразу после получения ответа на
предыдущий запрос - для увеличения скорости опроса. Так я понимаю
его молчание. - Nikolay_Po(12.03.2025 15:43)
