Про что и говорит Филоненко.
ну так работает. Я же написал. Это и есть ответ
Тролль-наседка, добрый, нежный и ласковый
Валенок по первым заявлениям таймаут у мастера должен быть больше в два раза, на случай, если в этот момент порт RS485 опрашивается вторым мастером и МКОН поставит в очередь запрос первого мастера. А потом вдруг все поменялось...
сообщение https://owen.ru/forum/showthread.php...l=1#post343618У шлюза тоже есть таймаут ожидания ответа по 485. И если таймаут мастера больше чем таймаут шлюза - то мастер будет рвать соединение и конектится снова.
и там же где-то, что таймаут мастера должен быть не менее 300 мс (ТРЕХСОТ так его)
з.ы. да, есть ситуации когда после каждого опроса требуется обрывать соединение между ПК и шлюзом так же как и удерживать соединение. Это не принципиально особенно, а вот если мастер получив ответ ждет оставшееся время таймаута это туши свет, сам так запрограммил один драйвер, не понимая процесса. Потом правда с разработчиком допилили часть кода, где можно было останавливаться раньше и обрывать таймаут. Вообще проблема сидит где-то в работе с портом в Windows, если я правильно понял.
Валенок почему перебор? просто столкнулся с тем, что есть протоколы, где длина ответа НЕИЗВЕСТНА, вот такие пакостные протоколы бывают.
И в коде нет возможности задать четкий размер буфера для принятия байт, только заведомо бОльший по размеру, при этом штатные средства работы с COM в ОС не предполагают динамическое изменение буфера на лету. В некоторых случаях можно посчитать длину, в некоторых нет,и тут вступает в дело timeout, который ждет несчастные несколько байт, которых уже не будет никогда, так как ответ пришел полностью.
з.ы. в Modbus длина ответа известна, так что там проблем нет, timeout работает только при обрыве связи....
Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.
capzap а при чем тут МКОН, когда речь о Мастере, который опрашивает прибор через МКОН ?
Если правильно понимаю, МКОН всего лишь преобразует TCP запросы в RTU и придерживает в очереди запрос, если в этот момент опрашивает другой мастер.